DeepSeek V4ローカル推論にDwarfStar 4（ds4）が選ばれる理由

DeepSeek V4 Flash / PRO や GLM 5.2 のような高性能なオープンウェイトモデルを「自分の Mac やワークステーションで動かしたい」というニーズは、2026 年前半から急速に高まっています。ただし選択肢は llama.cpp・Ollama・vLLM・mlx など複数あり、どれが最適かを短時間で判断するのは容易ではありません。

なかでも Redis の作者として知られる Salvatore Sanfilippo 氏（antirez）が公開した DwarfStar 4（以下 ds4）は、公開から約 3 か月で 21,000 スターを超える注目を集めています（公式リポジトリ: antirez/ds4）。一方で README は 1,600 行を超える情報量があり、初見のエンジニアが「llama.cpp と何が違うのか」「PoC で採用すべきか」を短時間で判断するのは難しいのが実情です。

本記事は、公式 README と公式サイトを一次ソースとしたドキュメントベースの解説記事です。動作検証やインストールは行わず、公開情報のみに基づいて DwarfStar 4 の位置付け・独自機能・競合ツールとの比較・採用判断のポイントを整理します。

具体的には、DwarfStar 4 の設計思想（「narrow C engine」の意味）、対応ハードウェアと公表ベンチマーク、分散推論・DSpark 投機的デコードなどの独自機能、そして llama.cpp / Ollama / vLLM との差分を通じて、初見エンジニアが「自プロジェクトに採用すべきか」を判断できる材料を提供します。

DwarfStar 4（ds4）とは：DeepSeek V4 に特化したローカル推論エンジン

DwarfStar 4（ds4）は、Salvatore Sanfilippo 氏が公開している C 実装のローカル LLM 推論エンジンです。汎用モデルランナーではなく、DeepSeek V4 Flash / PRO と GLM 5.2 に用途を絞って設計されている点が最大の特徴です。

基本情報（開発者・言語・ライセンス・ステータス）

gh api /repos/antirez/ds4 で取得できる主要メタデータは次のとおりです（本記事の執筆時点）。

（出典: GitHub API /repos/antirez/ds4 経由で取得したメタデータ）

このプロジェクトは archived や fork ではなく、現時点で活発に開発が継続しているオリジナルの実装です。最終 push から日数が経っておらず、README にも「very fast changing / beta quality」と明記されている点から、コミット履歴・ドキュメントの変更が頻繁に発生している段階だと判断できます（公式リポジトリ: antirez/ds4）。ライセンスは MIT で、README の LICENSE 記述には依存元である llama.cpp / GGML の著作権表記も併記されています。

対応モデルと対応ハードウェア一覧

DwarfStar 4 が現在サポートするモデルとバックエンドは次のとおりです。README・公式サイト双方に列挙されており、公式サイト側でも「Local DeepSeek V4 and GLM 5.2」というブランド説明が採用されています（公式サイト: dwarfstar.sh）。

• 対応モデル: DeepSeek V4 Flash（ds4f-q2 / ds4f-q2-q4 / ds4f-q4 / ds4f-mxfp4）、DeepSeek V4 PRO（pro-q2-imatrix / 分割 GGUF 版）、GLM 5.2（glm-unsloth-q4 / glm-antirez-iq2xxs / glm-antirez-q2 / glm-antirez-q4）、DSpark support GGUF（Flash 用の投機的デコード補助モデル）
• 対応バックエンド: Metal（Apple Silicon Mac、96GB 以上推奨）、CUDA（NVIDIA GPU・DGX Spark 含む）、ROCm（AMD Strix Halo など）
• 提供する CLI バイナリ: ds4（対話 CLI）、ds4-server（HTTP サーバー、OpenAI / Anthropic 互換 API）、ds4-agent（コーディングエージェント）、ds4-bench（ベンチマーク）、ds4-eval（品質評価）

モデル本体は Hugging Face のミラーリポジトリ antirez/deepseek-v4-gguf から取得する構成で、README では以下のようにダウンロード用のシェルスクリプトを提供しています。

./download_model.sh

（出典: 公式リポジトリ README: antirez/ds4）

「narrow C engine」という設計思想：汎用 GGUF runner ではない理由

DwarfStar 4 の README は、冒頭近くの Motivation セクションで「汎用の GGUF runner にはしない」ことを明言しています。特定モデルに特化する代わりに、モデル読み込み・プロンプトレンダリング・ツール呼び出し・KV state・HTTP サーバー・コーディングエージェントまでを一体設計するアプローチをとっています。この設計判断の背景と分割線を理解しておくと、後述する競合ツールとの使い分けが判断しやすくなります。

「narrow C engine」の意味と分割線

公式サイトでは DwarfStar 4 を「Own your local AI inference」というメッセージのもと、DeepSeek V4 と GLM 5.2 に特化した推論スタックとして紹介しています（公式サイト: dwarfstar.sh）。README 側では次の 3 点が特化の理由として挙げられています。

• 高性能なオープンウェイトモデルが個人向けハイエンド機に収まるようになったこと
• DeepSeek V4 Flash / PRO と GLM 5.2 が、積極的なルーテッドエキスパート量子化に耐える構造を持っていること
• 圧縮 KV キャッシュと高速な SSD の組み合わせで、長文脈が実用時間で扱えるようになったこと

その結果、DwarfStar 4 は「モデル・トークナイザ・KV cache 表現・HTTP サーバー・エージェント」までを共通の high-level session API で貫く構成をとります。CLI・サーバー・エージェントのいずれから呼び出しても、セッションは on-disk KV cache そのものとして扱えるため、socket / API 境界越しの永続化コストが最小化されるとされています（公式リポジトリ README: antirez/ds4）。

また、モデルサポートは「opportunistic（機会主義的）」という表現で説明されており、より良い代替モデルが出れば古いモデルのサポートは削除される可能性がある点も README に明記されています。長期のモデル互換性を前提とする用途では留意が必要な設計方針だといえます。

llama.cpp / GGML への位置付け（何を借り、何を独自実装したか）

README の謝辞セクションでは「would not exist without llama.cpp and GGML」と明言し、以下の要素について llama.cpp / GGML への強い依存を認めています。

• GGUF フォーマットの読み書きレイアウト
• CPU 側の quantization / dot product ロジック
• 一部の GPU カーネル

一方、DeepSeek V4 の MoE 構造に特化した量子化戦略、Metal / CUDA / ROCm 3 バックエンドを跨いだ SSD ストリーミング、Thunderbolt 5 上での RDMA によるテンソル並列などは DwarfStar 4 独自の実装として README に位置付けられています。すなわち「llama.cpp / GGML を土台として尊重しつつ、DeepSeek V4 と GLM 5.2 に絞って踏み込む」というポジションが取られています（公式リポジトリ: antirez/ds4）。

なお、README には AI（GPT / Claude 系）の強力な支援を受けて開発している旨と、人間が最終的なアイデア・テスト・デバッグをリードしている旨を明示する「AI full disclosure」セクションが設けられています。生成 AI を用いたコード貢献の透明性を担保する姿勢が示されています。

対応ハードウェアと速度：Metal / CUDA / ROCm でどこまで動くか

DwarfStar 4 が実運用対象とするのは、Apple Silicon Mac（Metal）、NVIDIA GPU（CUDA）、AMD Strix Halo 系（ROCm）の 3 系統です。ハードウェア別の最小要件と、README の speed-bench セクションに掲載されている公開ベンチ数値を確認しておきましょう。

3 バックエンドと最小要件

README では、3 バックエンドそれぞれについて主要な想定機材と特徴が言及されています。

• Metal: Apple Silicon Mac が主要ターゲット。DeepSeek V4 Flash の 4bit 版を単機で扱うには 96GB 以上（実運用は 128GB Mac が推奨）が目安。SSD ストリーミングを併用すれば 64GB Mac でも動作する構成が README に例示されています
• CUDA: NVIDIA GPU 全般。単体 GPU から、8×L40S のようなマルチ GPU 構成、DGX Spark 上での運用まで検証されているとされています
• ROCm: AMD Strix Halo（Framework Desktop など APU 系）が主要ターゲット。GLM 5.2 の SSD ストリーミング事例が README に挙げられています

3 バックエンドを一級市民として扱う設計は、Apple Silicon Mac を主流の開発機とするローカル LLM 界隈の実情と、CUDA が主流の本番推論との橋渡しを狙う意図が読み取れます（公式リポジトリ README: antirez/ds4）。

速度ベンチマーク（Metal / CUDA、Context 2K〜65K）

README の speed-bench セクションでは、代表的な機材ごとの Prefill / Generation 速度が CSV として公開されています。以下は同 README から引用した主要行です。

（出典: 公式リポジトリ README（speed-bench セクション）: antirez/ds4）

MacBook Pro M5 Max 128GB では 2K コンテキストで 39 t/s 前後、65K コンテキストでも 27 t/s 台の生成速度を維持しており、単機のワークステーション用途としては十分に対話可能な水準です。DGX Spark GB10 は Prefill 側で MacBook Pro を上回る一方、Generation は帯域制約もあり抑えめの数値になっています。Mac Studio M3 Ultra 512GB では、DeepSeek V4 PRO Q2 のようなより大きなモデルが 32K コンテキストで動く点が示されています。数値は README 掲載時点のものであり、コミットに伴い更新される可能性があるため、採用判断時は最新の README を参照してください。

SSD ストリーミングで RAM 不足機を救う

DwarfStar 4 の特徴の 1 つが SSD ストリーミングです。DeepSeek V4 の MoE 構造では、常時アクティブな共有部分と、トークンごとにルーティングされるエキスパート部分に重みが分かれます。ds4 は共有部分を RAM に常駐させ、ルーテッドエキスパートを SSD からキャッシュ経由でロードする構成を採ります。

• --ssd-streaming オプションで有効化
• キャッシュバジェットは自動計算（バックエンドが推奨する working set の 80% 相当）
• README には 64GB MacBook で ds4f-q2 を context 32768・cache 32GB で運用する構成例が記述されています

（出典: 公式リポジトリ README（SSD streaming セクション）: antirez/ds4）

高速 NVMe SSD が広く普及したことで、フル常駐が難しい機材でも大きなモデルが扱えるようになった点は、Motivation セクションで挙げられていた「圧縮 KV キャッシュと高速 SSD で長文脈が実用的になった」という設計判断とも整合します。

分散推論・テンソル並列・DSpark：ds4 が独自に踏み込む領域

DwarfStar 4 が「narrow specialized engine」を名乗る本領は、単機の最適化にとどまらず、複数マシン間の分散推論や投機的デコードなどにも踏み込む点にあります。ここは llama.cpp / Ollama がターゲットにしていない領域であり、採用判断のうえで差別化ポイントを把握しておく価値があります。

Pipeline parallelism（キャパシティ拡張）

Pipeline parallelism は、モデルのレイヤーを複数マシンに分割し、単機ではメモリに乗らないモデルを実行できるようにする方式です。README には次の運用例が記載されています。

• 2 台の M5 Max 128GB を Thunderbolt 5 で接続し、4bit の DeepSeek V4 Flash（約 91GB）を分割実行
• 2 台の Mac Studio 512GB で DeepSeek V4 PRO Q4 を実行
• Prefill 側は最大 1.85 倍に高速化される一方、Generation は autoregressive な性質上わずかに遅くなる傾向

（出典: 公式リポジトリ README（distributed inference セクション）: antirez/ds4）

「単機に載せきれない大型モデルを、複数機のメモリを合算して走らせる」という用途に向いた方式で、キャパシティ拡張を主目的とする構成です。

Tensor parallelism over RDMA（レイテンシ削減）

Pipeline parallelism がキャパシティ拡張寄りなのに対し、Tensor parallelism は per-token レイテンシの削減を狙う方式です。ds4 は 2 台の Mac を Thunderbolt 5 で結び、同一トークンの計算を分担して decode する構成を提供しています。

• Thunderbolt 5 上の RDMA を優先し、環境が対応しない場合は TCP へフォールバック
• README の事例では、GLM 5.2 IQ2_XXS（約 188 GiB）で decode 約 16.8 t/s、prefill 約 94 t/s に到達（単機 SSD ストリーミング時の decode 約 4.8 t/s、prefill 約 3〜5 t/s との比較）

（出典: 公式リポジトリ README（tensor parallelism セクション）: antirez/ds4）

「大型モデルを単機の物理制約より速く動かす」ための構成であり、Pipeline parallelism と組み合わせられる場合もあります。ただし README でも「分散プロトコル部分は release-stable ではない」旨が触れられており、本番運用に持ち込む場合は自組織側での安定性検証が前提となります。

DSpark 投機的デコード

DSpark は、DeepSeek 公式が配布する draft モデルを利用した投機的デコード（speculative decoding）の実装です。draft モデルが最大 5 トークンを先読み提案し、main モデルで検証する仕組みで、コード生成のように予測しやすい系列で特に効果が出るとされています。

• --dspark オプションで有効化
• --dspark-strict モードでは main モデル単体と完全に同一の出力を優先
• 予測性が低いプロンプト（雑談的な自然文など）では速度メリットが薄いため、無効化が推奨されるケースも README に明記

（出典: 公式リポジトリ README（DSpark セクション）: antirez/ds4）

投機的デコード自体は近年のローカル推論エンジンで一般的になりつつある手法ですが、DeepSeek 公式配布の draft モデルと組み合わせて DSpark として提供されている点が ds4 側の実装ポイントです。

非対称 MoE 量子化と GGUF 生成ツール群

DeepSeek V4 の MoE 構造に対応するため、ds4 は「非対称 MoE 量子化戦略」を採用しています。具体的には次のような割り当てが README に記載されています。

• ルーテッドエキスパートの up / gate は IQ2_XXS、down は Q2_K など 2bit 系
• 共有エキスパート・プロジェクション・ルーティングは高精度を維持
• imatrix を用いた量子化バージョンが推奨。品質検証には 100 ケースの fixture が用意されている

（出典: 公式リポジトリ README（quantization セクション）: antirez/ds4）

さらに、ds4-eval により品質評価を、ds4-bench により速度評価を実施できる構成になっており、GGUF 生成用ツールとの連携も README に整理されています。

llama.cpp / Ollama / vLLM との違いと使い分け

初見エンジニアが最も判断に迷うのは「他のローカル推論エンジンとの違い」です。ここでは、DwarfStar 4 と代表的な 3 競合を「対象モデル・対象ハードウェア・想定ユーザー・強み・弱み」の 5 観点で並べます。表中の各項目は各リポジトリの README・公式ドキュメントおよび第三者比較記事に基づく整理です。

比較テーブル（4 ツール × 5 観点）

（参考: llama.cpp（GitHub）、Ollama vs vLLM vs llama.cpp: Local Inference Server Compari…、vLLM or llama.cpp: Choosing the right LLM inference engine（…）

DwarfStar 4 が最適なケース／他を選ぶべきケース

上記の観点を踏まえて、採用判断に役立つ切り分けを整理します。

• DwarfStar 4 を選ぶのが素直なケース

  • 対象モデルが DeepSeek V4 Flash / PRO または GLM 5.2 で、単機の Mac（Apple Silicon）や 128GB クラスのワークステーションで最速に近い生成速度を求めたい場合
  • 2 台構成での分散推論（Pipeline / Tensor parallelism）を試したい、または SSD ストリーミングで単機 RAM を超えるモデルを走らせたい場合
  • OpenAI 互換 API / Anthropic 互換 API と ds4-agent によるコーディングエージェント連携を、専用サーバ 1 プロセスで完結させたい場合

• llama.cpp を選ぶのが素直なケース

  • 対応モデル数を最優先し、CPU / Vulkan など幅広いハードウェア対応が必要な場合
  • 汎用性を維持しながら、必要に応じて自前で拡張できる小さな依存関係が欲しい場合

• Ollama を選ぶのが素直なケース

  • まず Docker ライクな体験でローカル LLM を試したいチームや、モデル管理を CLI で完結させたい個人開発者
  • 生成速度よりも導入のしやすさ・チームメンバーへの配布容易性を優先したい場合

• vLLM を選ぶのが素直なケース

  • CUDA GPU を用意でき、5 名以上の同時ユーザーに対して高スループットで LLM を配信する本番サーバを構築したい場合
  • PagedAttention や continuous batching に基づく batch 効率を最重要視する場合

DwarfStar 4 は「DeepSeek V4 系に絞って最速を狙う」ポジションであるため、汎用 GGUF ランナーや本番マルチテナントサーバとは競合しません。むしろ llama.cpp と役割分担する関係にあると捉えると、選定の判断がしやすくなります。

DwarfStar 4 の採用を検討する際のチェックリスト

DwarfStar 4 を PoC・自社案件で採用するかどうかを判断する際、README・公式サイトから読み取れる条件をチェックリスト形式で並べます。ドキュメントベースの整理であり、実際の採用可否は各組織の要件で最終判断してください。

• 対象モデルが DeepSeek V4 Flash / PRO または GLM 5.2 に含まれているか
• 手元のハードウェアが Metal / CUDA / ROCm のいずれかに合致するか（Metal は 96GB 以上、または SSD ストリーミング前提）
• README に明示された beta quality / very fast changing ステータスと、破壊的変更の可能性を受け入れられるか（公式リポジトリ: antirez/ds4）
• 「opportunistic なモデルサポート方針」（新しい代替モデルが出れば古いモデルの対応は削除される可能性）を許容できるか
• OpenAI 互換 API / Anthropic 互換 API と ds4-agent（コーディングエージェント）を活用する計画があるか、または ds4-server の単一プロセスで完結させたい要件があるか
• ライセンス（MIT）が組織のポリシーに適合するか。派生物を配布する場合、依存元の llama.cpp / GGML の権利表記を含める運用ができるか
• 分散推論を採用する場合、README でも触れられているとおり 分散プロトコル部分は release-stable ではない点を踏まえた検証工程を挟めるか
• AI 支援によるコード生成（README「AI full disclosure」）を前提とした開発モデルを受け入れ、自社側のレビュー・監査体制と整合させられるか

いずれかで No が出た場合、必ずしも見送りが必要とは限りませんが、リスクの引き受け方針や代替策（例: 一部を llama.cpp に寄せる、vLLM で本番運用を組む等）を事前に決めておくと安全です。

まとめ：DeepSeek V4 ローカル運用の第一候補として押さえる価値

DwarfStar 4（ds4）は、DeepSeek V4 Flash / PRO と GLM 5.2 に用途を絞り、モデル読み込みから HTTP サーバー・コーディングエージェントまでを一体設計した narrow C engine です。SSD ストリーミング・Pipeline parallelism・Tensor parallelism over RDMA・DSpark 投機的デコード・非対称 MoE 量子化といった独自要素は、汎用 GGUF runner である llama.cpp との補完関係のなかで意味を持ちます。

そのため、「DeepSeek V4 を単機の Mac やワークステーションで最速に近い速度で走らせたい」「128GB クラスの Apple Silicon や DGX Spark で本格運用したい」「2 台構成での分散推論を試したい」といった要件に対しては、DwarfStar 4 は 2026 年時点の第一候補として押さえておく価値があります。一方で、「幅広いモデルを扱いたい」「本番でマルチユーザーに配信したい」といった要件では llama.cpp / Ollama / vLLM のほうが素直に適合します。

README が明示するとおり Beta 品質・急速に変更中のステータスにあるため、いきなり本番投入するのではなく、PoC からの段階採用が現実的な選び方です。継続的な README ウォッチと合わせて、自社のローカル LLM 基盤戦略における位置付けを検討してみてください。

関連情報：ローカル LLM 基盤の設計・開発をご検討中の方へ

DeepSeek V4 系や GLM 5.2 のような大型オープンウェイトモデルを自社インフラで運用したいものの、ハードウェア選定・分散推論設計・API 連携の設計をどこから始めるか悩ましいという方は、お問い合わせフォームからご相談ください。要件整理の段階からのご相談も歓迎しています。

関連情報：フリーランス案件をお探しのエンジニアの方へ

ローカル LLM 推論・MoE 量子化・GPU カーネル最適化などの領域でフリーランス案件をお探しの方は、Workee でフリーランス案件を探すからご覧ください。技術ブログ記事と親和性の高い案件情報を掲載しています。

参考リンク

• DwarfStar 4（ds4）公式リポジトリ（GitHub）
• DwarfStar 4 公式サイト（dwarfstar.sh）
• About DwarfStar 4（dwarfstar.sh/about）
• llama.cpp 公式リポジトリ（GitHub）
• Ollama 公式リポジトリ（GitHub）
• vLLM 公式リポジトリ（GitHub）
• vLLM or llama.cpp: Choosing the right LLM inference engine（…
• Ollama vs vLLM vs llama.cpp: Local Inference Server Compari…