앞서 몇몇 글에서도 DeepSeek v4 Flash 에 대해서 좀 기대를 하고 있단 말을 적었습니다만 .. 아직 llama.cpp 쪽에서 deepseek v4 에 대해서 작업이 끝나지 못해서 인지 어떤 이유인지 모르지만 아직 LM Studio 나 Ollama 에 클라우드용 모델외에 직접 다운로드 해서 쓸수 있는 형태로 업데이트가 올라오고 있진 않습니다.
이미 HuggingFace 에 이런저런 양자화 모델로 등장을 하고 있는지도 꽤 지났는데 말이죠 ..
그런 와중에 제 기준으론 꽤 반가운 놈이 출시가 되어서 어제부터 이짓 저짓에 매우 열심히 써보고 있습니다.
일단 아무리 Mac Studio M3 Ultra 512gb 모델을 사용중이라 해도 .. 현실적으로 500b 넘어가는 대형 모델을 양자화 타협을 해서 돌린다해도 대체로 10tps 미만의 속도가 나오는 경우가 많고 클라우드 서비스를 통해서 쓰는 것과 LM Studio 나 Ollama 등을 통해서 로컬 LLM 을 물려 쓰는건 템플릿 차이인지 세부 설정차이 인지 세부적인 어떤 처리에 따른 차이인지 까지는 모르겠지만 동일 모델이라 해도 결과차이가 많이 나는편입니다.
이런 상황에서 이번에 출시된 DeepSeek v4 Flash 하나만 다루겠다며 등장한게 ds4.c 입니다.
DeepSeek 4 Flash 만을 위한 추론 엔진이고 OpenAI, Anthropic 의 API를 전부 지원하고 있습니다.
게다가 이거 개발해서 공개한 사람이 ..
Redis 만든분? 놈? 님? 이십니다? .. Redis 프로젝트에서 떠나고 은퇴한다는 걸로 들었는데 다시 개발을 시작하시려는 듯..
GPT 5.5의 많은 도움을 받아서 뚝딱 하셨다는듯 하는데 뭐 그게 중요한건 아니구요 ..
우선 현재로써는 Metal 기반의 하드웨어를 주력 타겟으로 개발되었다 하구요. 제 환경에는 찰떡 인 상황입죠.
git clone 후 make 만 때리고 바로 ds4-server 로 실행 할 수 있습니다. 모델도 어차피 DeepSeek v4 Flash 딱 하나만 취급하는 놈이라 .. 자체 전용 GGUF 형식을 사용하는 것 같고 2bit, 4bit 2가지 양자화 모델만 존재합니다.
git 저장소에 같이 제공하는 download_model.sh 를 사용해서
모델을 받을 수 있구요.
개발자가 제시한 자료 상에 컨텍스트는 32768, –nothink 를 켠 상태로 테스트한 결과라 합니다. 컨텍스트 크기 좀 조절하면 q2 는 128GB 모델에서 구동 가능하고 q4 부터는 128gb 이상의 메모리가 필요할 것 같습니다.
제가 현재 q4-imatrix 양자화를 사용중인데 180GB 정도 메모리를 사용중입니다. 물론 전 1M 컨텍스트라 그런거고 상황에 따라 컨텍스트 크기 조정을 좀 하면 128GB 맥북 프로나 맥 스튜디오에서도 구동 가능할걸로 보입니다.
일단 Deepseek V4 flash 자체를 기다린 이유는 1M 컨텍스트라는거 .. NVIDIA 의 Nemotron 3 가 1M 컨텍스트를 지원하지만 이놈은 좀 ;; 중간 중간 ㅄ짓을 너무 살벌하게 해대서요 .. 포기했어요.
Pro 모델은 1.6T의 어마무시한 놈이라서 애초에 q1이나 q2 양자화 모델을 512gb 램 안에 우겨 넣어서 돌린다 쳐도 tps 가 말도 안되게 떨어질꺼라 실사용하긴 힘들거로 보여서 Flash 모델에 큰 기대를 하고 있었습니다.
우선 이틀간 돌려본 결과는 매우 만족합니다.
평균적인 디코딩 속도는 2~25tps 사이구요. 기존에 사용하던 minimax m2.7 이 50tps 정도 였고 qwen 3.6 35b 모델이 70tps 였어서 상대적으로 속도가 매우 아쉽다고 보일수도 있는데 이틀간 진짜 수 많은 짓에 동원해본 결과 .. tps 만 놓고 말할 문제가 아닌 것 같습니다.
일단 모델 자체도 잘 나온것 같지만 ds4.c 자체가 개발자가 에이전트 붙여서 개발에 사용할 목적으로 추론 엔진을 만들고 있는거라 자잘한 툴 호출에서 문제라던지 .. 클로드코드나 오픈코드같은 에이전트 cli 와 뭔가 잘 안맞아서 개삽질 해대는 경우가 적어서 그런지 몰라도 ..
꽤 쓸만한 결과를 잘 만들어 내네요.. 특히 저는 하드웨어가 충분하니 1M 컨텍스트를 다 쓸 수 있다보니 여기서 오는 장점이 매우 큽니다. Qwen 3.6의 경우에도 YaRN 설정을 동원하면 1M 컨텍스트 효괄르 얻을수 있다하지만 이건 꼼수를 동원한거고 Nemotron 의 경우 1M 컨텍스트를 다 쓰기도 전에 .. 자기 자신의 답변을 사용자의 프롬프트로 잘못 끌어다 쓰는 등의 이상한 여러 문제들 때문에 .. 언급하기도 솔직히 힘들긴 합니다.
일단 Redis 를 만든 분이 개발한거고 캐시 쪽에는 전문가여서 그런지 몰라도 KV 캐싱 관련해서 맥의 ssd 가 충분히 빠르기 때문에 디스크에 캐싱을 하겠다~~ 라는 점이 특이점 인듯 싶구요.
장점은 다른 분야는 몰라도 개발에 쓸거면 자잘하게 신경쓸게 없다는 점 ..
git clone 하고 make 하고 모델 다운받고 끝 ..
Usage: ds4-server [options]
Model and runtime:
-m, --model FILE
GGUF model path. Default: ds4flash.gguf
--mtp FILE
Optional MTP support GGUF used for draft-token probes.
--mtp-draft N
Maximum autoregressive MTP draft tokens per speculative step. Default: 1
--mtp-margin F
Minimum recursive-draft confidence for the fast N=2 verifier. Default: 3
-c, --ctx N
Context size allocated at startup. Default: 32768
-n, --tokens N
Default max output tokens when the client omits a limit. Default: 393216 (384K)
-t, --threads N
CPU helper threads for lightweight host-side work.
--quality
Prefer exact kernels where faster approximate paths exist; MTP uses strict verification.
--dir-steering-file FILE
Load one f32 direction vector per layer for directional steering.
--dir-steering-ffn F
Apply steering after FFN outputs: y -= F*v*dot(v,y). Default with file: 1
--dir-steering-attn F
Apply steering after attention outputs. Default: 0
--warm-weights
Touch mapped tensor pages before serving. Slower startup, fewer first-use stalls.
--metal | --cuda | --cpu | --backend NAME
Select backend explicitly. Defaults to Metal on macOS and CUDA on CUDA builds.
HTTP API:
--host HOST
Bind address. Default: 127.0.0.1
--port N
Bind port. Default: 8000
--trace FILE
Write a human-readable session trace: prompts, cache decisions, output, tool calls.
Thinking and sampling:
DeepSeek-compatible chat requests default to thinking mode with high effort.
Only reasoning_effort=max or output_config.effort=max requests Think Max.
Think Max is applied only when --ctx is at least 393216 tokens; smaller contexts use high.
thinking={type:disabled}, think=false, or model=deepseek-chat selects non-thinking mode.
API defaults are temperature=1, top_p=1, min_p=0, and no top-k cap.
In thinking mode, client sampling knobs are ignored like the official API.
Disk KV cache:
--kv-disk-dir DIR
Enable disk KV checkpoints in DIR. The directory is created if needed.
--kv-disk-space-mb N
Disk budget for checkpoint files. Default when enabled: 4096
--kv-cache-min-tokens N
Do not save or load checkpoints shorter than N tokens. Default: 512
--kv-cache-cold-max-tokens N
Cold first prompts in [min,N] are saved automatically. 0 disables cold saves. Default: 30000
--kv-cache-continued-interval-tokens N
Save at absolute aligned frontiers spaced about N tokens apart. 0 disables. Default: 10000
--kv-cache-boundary-trim-tokens N
Trim this many tail tokens before cold boundary saves to avoid tokenizer boundary merges. Default: 32
--kv-cache-boundary-align-tokens N
Align cold boundary saves down to this token multiple. 0 disables alignment. Default: 2048
--kv-cache-reject-different-quant
Refuse checkpoints written by the same model with a different routed-expert quantization.
--disable-exact-dsml-tool-replay
Disable the tool-id -> exact sampled DSML map. Tool history falls back to canonical JSON rendering.
--tool-memory-max-ids N
Maximum exact tool-call IDs kept in RAM for replay. Default: 100000
Cache triggers:
cold save a stable prefix of a long first prompt before generation starts
continued save absolute aligned restart frontiers during long prefill or generation
evict save the live conversation before another request replaces it
shutdown save the live conversation when the server exits cleanly
Normal server command:
./ds4-server --ctx 100000 --kv-disk-dir /tmp/ds4-kv --kv-disk-space-mb 8192
Notes:
Use /v1/chat/completions, /v1/completions, or /v1/messages.
Larger --ctx values allocate more KV memory at startup; the startup log prints the estimate.
Disk KV caching is best for agents that resend long prompts with stable prefixes.
-h, --help
Show this help.실행 파라미터도 이게 답니다. 컨텍스트 지정하고 .. 몇가지 옵션들 지정하는 정도.
#!/bin/sh
./ds4-server --warm-weights --host 0.0.0.0 --ctx 1000000 --kv-disk-dir /tmp/ds4-kv --kv-disk-space-mb 81920저는 현재 이정도로 1M 컨텍스트와 .. 조금 넉넉하게 kv 캐시 크기를 잡은 정도..
아! –warm-weights 는 꼭 쓰시는게 좋을 것 같네요. 초기 구동은 좀더 시간을 잡아먹지만 가중치 정보를 매번 로드할 필요 업이 미리 읽어두고 씁니다. 프롬프트 별 응답 시간이 훨씬 쓸만해 집니다.
다른 모든게 다 마음에 들지만 한가지 아쉬운건 아직 병렬 처리는 불가하다는 정도?
근데 이건 Qwen 3.6 같은거 Vision 지원하는 놈들은 mlx 지원 모델들 보면 병렬처리 불가한 경우도 많아서 이걸 단점이라고 하기도 좀 그렇네요. LM Studio 에서 mlx 양자화 모델들은 병렬처리가 안되서 Unsloth 의 일반 GGUF를 사용했었으니 단점이라 하기도 좀 그렇습니다.
현재까지 딱히 실사용에 큰 문제가 없어서 계속 사용을 할 것 같습니다.
이제 공개된지 한달도 안된 정말 따끈 따끈한 놈이고 .. 계속 커밋되고 있는 것 보면 계속 개선 될 것 같네요.
맥 사용자시고 128gb 이상의 통합메모리를 보유중이시라면 한번쯤 시도해보세요.
CUDA 나 AMD ROCm 쪽도 신경은 쓰고 계신것 같으나 .. 개발자께서 맥 스튜디오와 DGX Spark 는 보유중이신 듯 하나 AMD 쪽 장치는 없으신듯 .. (AMD 뭐하냐 하나 보내드려라.. )
여튼간에 LocalLLM의 또 다른 빛을 보았습니다!!
댓글을 달려면 로그인해야 합니다.