まとめ

DS4（DwarfStar 4）は、DeepSeek V4 FlashをMacで速く動かすための専用推論エンジンとして見ておけばよかった時期から、少し違う段階に入っている。
現在はDeepSeek V4 Flashを中心にしつつ、GLM 5.2、DeepSeek V4 PRO、SSD streaming、分散推論、OpenAI互換server、Anthropic互換endpoint、disk KV cache、DS4 Agentまでを含む、ローカルLLM運用スタックに近い。

ただし、汎用runnerを目指しているわけではない。
READMEでも、任意のGGUFを読む一般ローダーではなく、model loading、prompt rendering、tool calls、KV state、HTTP server、coding agentを一緒に実装・テストする方針が明記されている。
広がってはいるが、思想は「狭く深い」ままだ。

この変化の中で、DS4 Agentの価値も見え方が変わる。
Claude Codeより高機能なcoding agentだから使う、という話ではない。
DeepSeek V4 Flash、DS4 inference、DSML tool call、KV state、coding-agent harnessを垂直統合し、ローカル推論で重くなりがちなprefillとsession再開のコストを抑えるところに本質がある。

DS4はローカルLLMの実運用スタックになりつつある

DS4の中心は今でもDeepSeek V4 Flashだ。
だが、現在のREADMEを見ると、単なる「V4 Flashを実行するプログラム」とは言いにくい。

対応範囲はかなり広い。

• DeepSeek V4 Flash / PRO、GLM 5.2
• Metal、CUDA、ROCm backend
• SSD streaming、tensor parallelism、分散推論
• OpenAI互換のChat Completions / Responses API
• Anthropic互換の /v1/messages
• DSML tool callの変換とcanonicalization
• disk KV cache
• DS4 Agent、benchmark、evaluation、GGUF tooling

ここで重要なのは、機能が増えたこと自体ではない。
DS4は、推論エンジン、server、tool call処理、agent runtimeを別々の部品として寄せ集めるのではなく、同じモデル向けにまとめて調整している。
このため、llama.cppやOllamaのような汎用ローカルLLM実行環境とは、狙っている最適化の粒度が違う。

2026年7月末から8月上旬にかけての更新も、その方向をよく表している。
Flashの0731 checkpoint対応、0731向けDSpark support、Metal decode最適化、長context時のcorrectness修正、tool call recovery、OpenAI tool schemaのcanonicalizationなどが短期間に入っている。
tokens/secだけでなく、長いagent sessionで壊れにくくする方向へも手が入っている。

0731 Flash更新は高速化だけでは読めない

2026年8月4日の更新で、DeepSeek V4 Flashのdownload targetとDSpark supportが0731 checkpointへ切り替わった。
128GB級のMac Studioであれば、まずは ds4f-q2 residentを検討するのが自然だ。
DS4のQ2は全部を単純に2bit化するのではなく、巨大なrouted MoE expertsを強く量子化しつつ、shared expertsやroutingなどを高精度側に残す非対称な構成になっている。

DSparkも0731専用のsupport modelへ切り替わっている。
これは補助モデルで数tokenを先読みし、target側のV4 Flashが検証するspeculative decodingだ。
codeのように次が予測しやすい生成では効きやすい一方、prefillは速くならず、promptによっては逆に遅くなる。
現時点では、常時ONの設定というより、同じpromptで通常decodeと比較しながら使う実験的な選択肢と見たほうがよい。

一方で、0731更新を「agent性能も全面的に上がった」と読むのは危ない。
8月5日のcommitでは、新しいDS4F checkpointがanchored [upto] editsを苦手にするため、DS4 Agentのedit toolはexact old textからnew textへ置き換える方式をデフォルトに戻している。
[upto] 方式は --edit-upto を指定した場合だけ有効になった。

これはかなり示唆的だ。
モデル更新によって、推論速度や一般性能が良くなる部分はあっても、tool contractとの相性が常に改善するとは限らない。
DS4側は、0731 checkpointの癖に合わせてagent側の編集契約を単純化し、安定性を取りにいっている。

DS4 Agentの強みはKV stateをsessionとして扱えること

DS4 Agentは、Claude Codeの上位互換ではない。
file edit、bash、MCP、permission、hooks、subagent、外部連携の成熟度では、Claude Codeのほうが明らかに強い。

では、DS4 Agentは何に強いのか。
答えは、agentとinference engineが同じ場所にあることだ。

一般的なcoding agentは、clientが会話履歴とtool resultをAPI serverへ送り、server側がそれをモデル用promptへ変換する。
ローカルLLMでは、この長い履歴の再prefillが重い。
会話が育つほど、毎turnの前処理が効いてくる。

DS4 Agentでは、inferenceをagent内部から制御する。
READMEには、sessionがon-disk KV cacheそのものとして表現されると書かれている。
/save、/list、/switch、/strip といった操作も用意されており、保存済みsessionは ~/.ds4/kvcache に置かれる。

この設計だと、長いcoding sessionを保存し、後日KV stateから再開できる。
text transcriptをもう一度prefillして「同じ文脈に戻る」のではなく、推論エンジン側の状態として戻る。
ローカルLLMでは、この差は大きい。

さらに、DeepSeek V4のtool call形式であるDSMLをnativeに扱える。
Claude Codeなどの汎用clientから使う場合は、Anthropic形式やOpenAI形式のtool callとDSMLを相互変換する必要がある。
DS4 Serverはexact DSML replayやcanonical renderingでKV prefix破壊を避ける工夫を持つが、DS4 Agentならそもそも変換層を薄くできる。

Claude Code + DS4 Serverは現実的だが別物である

DS4 Serverは、Claude Codeのようなclientをつなぐ使い方も明示的に想定している。
/v1/messages はAnthropic互換endpointで、READMEにはClaude Code向けの環境変数例も載っている。
つまり、Claude CodeのUI、workflow、MCP、成熟したagent harnessを使いながら、背後の推論だけをローカルのDeepSeek V4 Flashへ向ける構成は、かなり現実的だ。

ただし、これはDS4 Agentと同じものではない。
Claude Codeは最初に大きなpromptを送ることがあり、READMEではしばしば25k token程度になると注意されている。
DS4 Serverは --kv-disk-dir によるdisk KV cacheで、一度処理したprefixを再利用できる。
それでも初回prefillとtool protocol変換の層は残る。

整理すると、使い分けはこうなる。

Claude Codeの --system-prompt / --append-system-prompt は、公式には --print mode向けの機能として説明されている。
そのため、interactive REPLをそのまま使いながら標準system promptを完全に極小化する、という使い方は確認できていない。
non-interactiveなSDK的利用なら、DS4 Agentとの差を縮める比較実験として面白い。

現時点では「垂直統合の価値」を見るべき

DS4 Agentを評価するとき、「Claude Codeより賢いか」「高機能か」という軸に寄せると見誤る。
Claude Codeは汎用coding-agentとしての完成度が高く、複雑なrepo変更や外部サービス連携では今でも強い。

一方、DS4 AgentはDeepSeek V4 Flashをローカルで使う前提にかなり寄せている。
system prompt、tool call、KV state、session保存、推論エンジンが同じ設計面の上にある。
ローカルLLMで問題になりやすいprefill、長context、tool callの崩れ、session再開を、client側の工夫ではなくruntime側から抑えにいく。

だから現時点の見方はこうだ。
DS4は、V4 Flash専用ランナーから、V4 Flashを中心にしたローカルAgentスタックへ広がっている。
ただし、広がり方は汎用化ではなく垂直統合だ。
Claude Code + DS4 Serverは現実的な中間案だが、V4 Flashをローカルで常用するなら、DS4 Agentの設計には独自の合理性がある。

主要参照先

• DS4 repository / README
• Flash downloads and DSpark support for 0731
• agent: disable upto by default for new DS4F
• metal: port exact M5 decode paths to pre-M5
• server: recover truncated DSML tool calls
• Claude Code SDK documentation