DwarfStar（ds4）とは？DeepSeek V4をローカル実行する専用実行環境と必要メモリを整理

DwarfStar（ds4）は、DeepSeek V4のような巨大MoEをローカルで使いたい人にとって、かなり異色の推論実行環境だ。

OllamaやLM Studio、llama.cppのように多数のGGUFを幅広く扱うことを目指していない。むしろ逆で、DeepSeek V4 Flash / PROと一部のGLM系へ対象を絞り、モデル読み込み、量子化、KVキャッシュ、サーバー、コーディングエージェントまで一体で最適化する方針を取っている。

そのため、DwarfStarを見るときに重要なのは「新しいllama.cpp代替が出た」と考えることではない。

巨大MoEを96〜128GB級のMacやStrix Halo、DGX Spark、複数GPU ワークステーションで現実的に扱うための専用実行環境として見る方が正確だ。

DeepSeek V4目的なら有力。ただし汎用実行環境の置き換えではない

DwarfStarが向いているのは、主に次のようなケースだ。

用途	DwarfStarの相性
DeepSeek V4 Flashを高メモリMacで使いたい	高い
DeepSeek V4をDGX Sparkで使いたい	高い
複数のNVIDIA GPUへ分散したい	高い
Strix Halo / ROCmで巨大モデルを試したい	高い
RAMより大きいモデルをSSDからストリーミングしたい	高い
小型GGUFを何十種類も気軽に切り替えたい	低い
一般的な7B/14B/32BモデルをGUIで使いたい	Ollama / LM Studio系が分かりやすい

DwarfStar公式README自身が、これは汎用 GGUF 読み込み機能ではないと明記している。

対応GGUFはテンソル配置形式、量子化 mix、メタデータ、MTP 状態などをDwarfStar側が想定したものに限定される。つまり「手元のGGUFなら何でもds4で高速化できる」という実行環境ではない。

96GB・128GB・256GBという数字はどう読む？

DwarfStarのモデルダウンロード手順では、DeepSeek V4 Flash向けに次の目安が示されている。

ds4f-q2    : 96 / 128 GB RAM machines
ds4f-q4    : 256 GB RAM以上
ds4f-mxfp4 : 約156 GB
PRO q2     : 512 GB RAM machines

ここはDwarfStarの実用価値が分かりやすい部分だ。

巨大MoEでは「GPU VRAMが32GBあるか」だけではなく、モデル重みをどこへ保持するかが重要になる。Apple SiliconやStrix Haloのような大容量統合メモリ、DGX Sparkの大容量メモリ、複数GPUなどを前提にすると、一般向けGPU単体とは別の選択肢が生まれる。

ただし、96GBや128GBを「絶対最低RAM」と固定的に読むべきではない。

DwarfStarにはSSD ストリーミングがあり、RAMへモデル全体を常駐できない環境でも実行できる。ただしその場合はSSDから重みを読み出すため、常駐実行より速度面で不利になる。

SSD ストリーミングでRAMより大きいモデルを動かせる

DwarfStarの大きな特徴の一つが、重みのSSD ストリーミングを主要機能として扱っていることだ。

通常、巨大GGUFをローカルで動かす場合は、量子化してもモデルファイル自体が100GBを大きく超えることがある。RAMへ収まらなければそこで諦めたくなるが、DwarfStarは必要な重みをSSDからストリーミングする経路を用意している。

これは「SSDがRAMの代わりになる」という意味ではない。

速度差を見ると、DwarfStarが公開しているGLM 5.2の一例では、2台の128GB MacBookでモデルを常駐にしたテンソル-並列構成が生成処理約16.8 t/sだったのに対し、1台MacのSSD ストリーミングは約4.8 t/sだった。

この数字は特定のモデル・量子化・ハードウェア・コンテキストでのプロジェクト測定だが、方向性は分かりやすい。

SSD ストリーミングは容量問題を解決するための機能であり、RAM常駐と同じ速度を得るための機能ではない。

DwarfStarとllama.cppは何が違う？

両者ともGGUF エコシステムと強く関係しているが、設計思想はかなり違う。

llama.cpp

• 多数のアーキテクチャを扱う
• 一般的なGGUF 実行環境として広く使える
• OllamaやLM Studioなど多くのソフトウェアの基盤にもなる
• 対応モデルの幅が広い

DwarfStar

• DeepSeek V4 / 一部の GLMへ対象を絞る
• 対応量子化も実行環境側で強く管理する
• ネイティブコーディングエージェント、サーバー、KV セッションまで一体化する
• SSD ストリーミングやモデル固有のMTP、エキスパート配置を積極的に最適化する
• 複数-マシン / 複数GPUの巨大モデル運用を重視する

DwarfStarはllama.cppの成果、GGML、GGUF エコシステムを明確に言及している。一方で実装自体は「数モデルへ縦に深く最適化する」という別方向を選んでいる。

そのため、普段のローカルLLM環境を全部DwarfStarへ移す必要はない。

DeepSeek V4を使うときだけDwarfStarを試し、それ以外は既存実行環境を使うという併用が自然だ。

2bit量子化でも全部を2bitにしているわけではない

DwarfStarはDeepSeek V4 Flash向けのQ2を96/128GB級マシンの推奨候補にしている。

ただし、「305B級モデルを全部2bitにしている」と単純化すると正確ではない。

公式READMEによると、2bit 量子化はかなり非対称だ。大部分を占めるルーティング対象の MoE エキスパートを強く量子化する一方で、共有エキスパート、投影、ルーティングなど他の構成要素は高い精度を維持する設計になっている。

巨大MoEではルーティング対象のエキスパートが重み容量の多くを占めるため、そこを重点的に圧縮すると全体容量を大きく削減できる。

これは一般的な「Q2だから全テンソルがほぼ2bit」という理解とは違う。

GGUFを取得するときは、単にQ2/Q4という名前だけではなく、誰が作った量子化か、どのテンソルをどの精度へ落としているかを確認したい。一般的な確認方法はGGUFモデルをダウンロードする前に確認したい5項目でも整理している。

Macでは96GB以上が主な対象

DwarfStarはMetalを主要対象の一つとしており、READMEでは96GB以上のMacを主な想定に置いている。

例えばDeepSeek V4 Flash Q2は96/128GB級、Q4なら256GB級のメモリを想定する。

さらに2台のMacをThunderboltで接続し、モデルを分散する機能もある。

DwarfStarが公開している2台のM5 Max 128GB MacBookを使ったDeepSeek V4 Flashの例では、長いプロンプトの入力処理は単一プロセスより速くなるケースがある一方、生成処理はネットワーク hopのため遅くなっている。

つまり複数Macをつなげる目的は、必ずしも「トークン生成を2倍速にする」ことではない。

1台では載らないモデルを載せること、長い入力処理を並列化することが主な価値になる。

CUDAではDGX Sparkから複数GPU サーバーまで扱う

DwarfStarはNVIDIA CUDAにも対応している。

READMEではDGX Spark向けビルドに加えて、複数GPUを使うCUDA テンソル並列化も案内している。

8枚のL40Sを使ったプロジェクトテストでは、DeepSeek V4 FlashのQ4をGPUへ分散し、複数セッションをまとめてサーバーとして実行する構成まで検証されている。

これは一般ユーザー向けPCというよりワークステーション/サーバー領域だが、DwarfStarの方向性をよく示している。

一般向けに見るなら重要なのは、GPU枚数を増やせば何でも高速化するのではなく、まずモデルを保持できるメモリトポロジーを作るために複数GPUを使うという点だ。

ROCmではStrix Haloを対象に含む

DwarfStarはROCm バックエンドも持ち、Strix Halo系マシンを具体的な対象として挙げている。

Strix Haloは一般的な独立型 GPUとは異なり、大容量システムメモリをGPU側へ利用できるため、巨大モデルのローカル推論で独特の強みがある。

ただし、READMEにROCm対応と書かれていることから「すべてのRadeonで同じように動く」と一般化するのは危険だ。

DwarfStarは対応ハードウェアをかなり具体的にテストしている実行環境なので、自分のGPU / APUが実際の検証済みパスに入るかを導入前に確認した方がよい。

ネイティブコーディングエージェントも内蔵する

DwarfStarにはds4-agentというネイティブコーディングエージェントもある。

一般的な構成では、LLM サーバーを立て、その上から別のエージェントクライアントがHTTP APIを呼ぶ。しかしDwarfStarはエージェントと推論を同じ実行環境内で強く統合し、KV セッションそのものをディスクへ保存・再開できる設計を取る。

さらにOpenAI互換サーバー経由でOpenCodeなどへ接続したり、Responses API経由でCodex CLIへ接続する例もREADMEに掲載されている。

ただし、これは「DwarfStarを入れれば自動で安全なコーディングエージェントになる」という意味ではない。

シェルやファイル操作を伴うエージェントは、モデルがローカルかどうかとは別に権限管理が必要だ。

ベンチマークはそのまま自分のPCへ当てはめない

DwarfStar リポジトリにはかなり詳しいベンチマークがある。

例えば2台Macの入力処理、SSD ストリーミング、Thunderbolt/Wi-Fi/VPN比較、複数GPU CUDAなどだ。

こうした一次測定は実行環境選択の参考になるが、最低要件表として使うのは避けたい。

速度は次の条件で大きく変わる。

• モデル / チェックポイント
• 量子化配置形式
• RAM容量と帯域
• GPU アーキテクチャ
• SSD速度
• コンテキスト長さ
• KVキャッシュ形式
• バックエンド
• ネットワーク遅延
• 常駐かストリーミングか

DwarfStarを導入するときは、リポジトリの数字を目標値にするのではなく、自分のマシンで短いプロンプトとコンテキストから測る方が安全だ。

どんな人ならDwarfStarを試す価値が高い？

DwarfStarは、普通のローカルLLM初心者向け実行環境ではない。

次の条件に当てはまるほど価値が高い。

• DeepSeek V4 Flash / PROを使うこと自体が目的
• 96GB以上のApple Silicon Macを持っている
• Strix Haloなど大容量統合メモリマシンを持っている
• DGX Sparkを持っている
• 複数のCUDA GPUをまとめたい
• RAM以上のモデルをSSD ストリーミングでも試したい
• 巨大モデルをコーディングエージェントとしてローカル運用したい

逆に、7B〜32B級を普段使いしたいだけなら、OllamaやLM Studioなどの方が導入もモデル切り替えも簡単だ。

導入前に確認する順番

DwarfStarを試すなら、次の順番で確認すると失敗しにくい。

1. 使いたいモデルがDwarfStarの対応一覧にあるか
2. DwarfStarが指定するGGUF / 量子化か
3. RAM / 統合メモリ容量
4. GPU バックエンドがMetal / CUDA / ROCmの検証済みパスに入るか
5. モデルファイルを置くSSD容量
6. 常駐で載るか、SSD ストリーミングが必要か
7. コンテキストを短くして起動
8. 最大メモリ使用量、入力処理、生成処理速度を実測
9. 必要ならコンテキストやエージェント機能を広げる

特にモデルダウンロード前に、100GBを超える配布ファイルとSSDの空き容量を確認したい。