DeepSeek V4 Flash-0731 を llama.cpp で DGX Spark 1 台に載せてみた

はじめに

こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。

DeepSeek V4 Flash の公式版が 7 月 31 日に出ました。preview 版を置き換える 0731 という更新版で、Unsloth の GGUF も同じ日に公開されています。284B のモデルが手元の DGX Spark 1 台で動くのか、気になったので早速複数のアプローチから検証をしてみました。

https://huggingface.co/unsloth/DeepSeek-V4-Flash-0731-GGUF

実は 5 月に、同じ DeepSeek V4 Flash を DGX Spark で動かす記事を書いています。ただしそのときは llama.cpp が V4 に対応しておらず、antirez さんが DeepSeek V4 専用に書いた推論エンジン DwarfStar 4 を使うしかありませんでした。記事の最後は「DeepSeek が V4 Flash の更新版を出したら、また試してみたいところです」で締めています。

https://dev.classmethod.jp/articles/dgx-spark-dwarfstar4-deepseek-v4-flash-bench/

その宿題が、2 つとも片付いてしまいました。更新版が出て、llama.cpp も 6 月末に DeepSeek V4 へ対応していたのです。となると次の疑問は「専用エンジンでしか動かなかったモデルを汎用ランナーで動かすと、どれくらいの差が出るのか」ですね。

先に結論を書いておくと、2-bit も 3-bit も DGX Spark 1 台に載り、速度では llama.cpp が専用エンジンを上回りました。ただし起動時間は逆に llama.cpp が 6 分半、DwarfStar 4 が 17 秒と 22 倍の開きがあります。常駐させるのか、使うときだけ起動するのかで選ぶものが変わる、という結果でした。

この記事では、Unsloth の GGUF を DGX Spark 1 台で動かし、メモリ・速度・長文・品質の 4 方向から専用エンジンと比べた結果を紹介します。128GB クラスのマシンで 284B を動かそうとしている人に刺さるといいなと思っています。

0731 で何が変わったのか

DeepSeek-V4-Flash-0731 は preview 版を置き換える公式リリースで、モデル構造は DeepSeek-V4-Flash-DSpark と同じです。つまり投機デコード用のモジュールが最初から付いています。パラメータは 284B、そのうち稼働するのは 13B です。ライセンスは MIT で、コンテキストは 1M を謳っています。

公式が出しているベンチマークを引用します。これは DeepSeek 側の公表値で、自分が測ったものではありません。

preview からの伸びが極端ですね。DeepSWE は 7.3 から 54.4 へ、Cybergym は 38.7 から 76.7 へ。同じ構造のまま agentic 能力を鍛えた、という主張と辻褄は合っています。GLM-5.2 は多くの項目で上回る一方、Opus-4.8 には全項目で届いていません。

一点、読むときに気をつけたいところがあります。コード系のタスクは「minimal mode of DeepSeek Harness」という評価用フレームワークで測られていて、これがまだ公開されていません。つまり現時点で第三者がこのスコアを再現する手段はありません。自分もここは追いかけず、動作と速度と品質を手元で見ることにしました。

llama.cpp が DeepSeek V4 に対応するまで

5 月の記事では「llama.cpp への統合が難航している」と書きました。その後どうなったかを調べたところ、6 月末に本体へマージされていました。

手元の clone は 6 月 6 日の b9538 で止まっていたので、src/llama-arch.cpp を grep してみると deepseek4 のヒットは 0 件でした。検証時点で最新だった b10216 に上げると 2 件に変わり、LLM_ARCH_DEEPSEEK4 と "deepseek4" の対応表エントリが増えています。専用の実装ファイル src/models/deepseek4.cpp も 1,203 行あり、片手間の対応ではないことがわかります。

気になるのは下 2 行です。マージ待ちではなく、どちらも閉じられています。つまり投機デコードは llama.cpp 本体に入っていません。DwarfStar 4 のほうは標準装備なので、同じモデルなのに使える機能が違うことになります。

ビルド自体はすんなり通りました。aarch64 と CUDA 13.0 の組み合わせで、警告もエラーもなしです。

cmake -B build-cuda -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=121 \
      -DCMAKE_BUILD_TYPE=Release -DLLAMA_CURL=ON
cmake --build build-cuda -j"$(nproc)" --target llama-server llama-cli llama-bench

所要は 150 秒でした。既存の build/ は残したまま build-cuda/ に分けているので、うまくいかなければ元のバイナリに戻せます。

DwarfStar 4 側も 3 か月ぶんの変化がありました。5 月の記事では make 一発でビルドできたと書いたのですが、いまは素の make を叩くとターゲット一覧が出て終わります。

DS4 build targets:
  make cuda-spark          Build CUDA for DGX Spark / GB10
  make cuda-generic        Build CUDA for a generic local CUDA GPU
  make strix-halo          Build ROCm for Strix Halo / gfx1151
  ...
  make dspark-verify-depth Run DSpark speculative verification smoke if support GGUF is present

DGX Spark と GB10 が cuda-spark として専用ターゲットになっていますね。3 か月前は -arch=native の自動検出頼みだったので、地味にありがたい変化です。ビルドは 54 秒、生成されるバイナリも 3 本から 5 本に増えていました。

128GB に 284B は載るのか

Unsloth は執筆時点で 13 種類の量子化を配布しています。ファイルサイズは HF の API から実測したものを載せます。なお Unsloth は「さらに小さい量子化を追加する」ともアナウンスしているので、この一覧は今後増えます。1-bit より下が出てくれば、メモリの少ないマシンでも選択肢が生まれるはずですね。

13 種類を GiB で並べ、121 GiB に破線を引いたもの。青が今回実測した 2 つ、緑がサイズ上は収まるもの、灰色が 1 台では入らないもの。UD-IQ3_S の 108.1 GiB までは線の内側だが、KV とコンテキストを載せる余白が残らない。

ここで一度つまずきました。Unsloth のドキュメントには 3-bit の必要メモリが 110〜135 GB とあり、DGX Spark は 128GB なので厳しいかなと思ったのです。

単位の取り違えでした。この表もファイルサイズも 10^9 バイト単位の GB ですが、free -g が返す 121 は GiB です。GB に直せば約 130 GB あるので、3-bit の 104.2 GB なら収まります。Unsloth 自身、チュートリアルでは UD-IQ3_XXS を 128GB マシン向けとして挙げていました。

そこで 2-bit の UD-IQ2_M と 3-bit の UD-IQ3_XXS を実機で起動してみました。

ロード時間は /health が 200 を返すまでを外から測った値です。ポーリング間隔が 15 秒なので、そのぶんの粗さは含まれます。

どちらも載りました。3-bit でも 18 GB の余白が残ります。ここに KV とコンテキストが乗るので、長文をどこまで伸ばせるかは後の章で見ていきます。

ただ、この表で目を引くのはロード時間のほうですね。6 分半です。5 月に測った DwarfStar 4 は同クラスの重みを 26 秒で立ち上げていたので、14 倍の開きがあります。

原因を探るためロード中のプロセスを追いかけたところ、累計 read が 116 GiB とモデル本体の 1.37 倍に膨らんでいました。読み出し速度は 20 秒あたり 1.7 GB、およそ 86 MB/s です。NVMe の素の帯域からすると遅すぎます。3-bit の UD-IQ3_XXS ではこの倍率がさらに上がって 1.44 倍でした。

GB10 は統合メモリなので、GPU バッファに確保した 84.5 GiB と、mmap したファイルのページキャッシュが同じ物理メモリを取り合います。GPU 側に 84.5 GiB を確保した時点でページキャッシュに残せるのは 30 GiB 前後しかなく、84.7 GiB のファイルを頭から読むと後半に着く頃には前半が落ちている。この往復が read の膨らみとして出ている、と見ています。モデルが大きいほど倍率が上がるのも、この説明と整合しますね。

--no-mmap で回避できる可能性はありますが、今回は対照を取っていません。試した方がいたら結果を知りたいところです。

llama.cpp は専用エンジンより速いのか

同じ端末、同じ日、同じ 0731 世代の重みで、llama.cpp と DwarfStar 4 の速度を突き合わせます。思考モードはどちらも切って揃えました。

ひとつ注意点があります。llama-server は既定でプロンプトキャッシュが効くため、同じプロンプトを繰り返すと 2 回目以降は prefill を飛ばしてしまいます。最初これに気づかず、prefill が 411 tok/s から 41 tok/s へ 10 分の 1 に落ちる一方で wall time は短くなる、という妙な結果を出しました。リクエストに "cache_prompt": false を足して測り直しています。同じ計測をする方はご注意ください。

3 系列とも右肩下がりだが、傾きが違う。DwarfStar 4（オレンジ）は 2,048 から 8,192 の区間で急に落ち、llama.cpp の 2 本はほぼ水平を保ったまま 32,768 まで伸びる。

decode は llama.cpp が全点で上回りました。しかもコンテキストが伸びるほど差が開きます。DwarfStar 4 は 2,048 から 8,192 へ伸ばすと 16.53 から 14.32 へ 13% 落ちるのに対し、llama.cpp は 17.35 から 17.05 へ 2% しか落ちません。減衰の仕方が違うんですね。

prefill も同じ傾向でした。

2-bit と 3-bit の差も見ておくと、decode で 3.6〜5.2% ほど 2-bit が速い程度でした。ファイルサイズの比は 84.7 / 97.1 = 0.872 なので、純粋にメモリ帯域だけで決まるなら 1.15 倍の差が出るはずです。実測が 1.05 倍にとどまるということは、帯域以外の要素、たとえば量子化形式ごとの逆量子化コストが効いているのだと思います。

ただ、DwarfStar 4 が圧勝している軸もあります。

起動が 22 倍速い。これは使い方を分ける差ですね。6 分半の起動を 1 日 1 回払って常駐させるなら llama.cpp の速度が効きますし、使うときだけ立ち上げる運用なら DwarfStar 4 の 17 秒が効きます。

投機デコードを積むと、かえって遅くなった

llama.cpp にない機能で DwarfStar 4 が逆転する可能性を潰しておくため、DSpark 投機デコードを積んでみました。5.6 GiB の support GGUF を追加して、greedy デコードで測ります。DSpark は温度 0 でしか働かないので、この数字は温度 1.0 で測った llama.cpp とは直接比べられません。ここで有効なのは、同じエンジンの中で投機経路だけを切り替えた比較です。

課題は LRU キャッシュの実装と unittest 作成にしました。README が「予測しやすい継続、特にコードが最も恩恵を受ける」と書いているので、DSpark に最も有利な条件です。

左 2 本が灰色（target-only 相当）、右 2 本が青（投機を有効化）。support GGUF を積むだけの 2 本目は点線の基準線とほぼ同じ高さで止まり、投機を入れた 3 本目から明確に落ちる。

投機を有効にすると 22% 遅くなりました。しかも投機を強めるほど遅くなり、常に 5 トークン先読みする設定では半減します。

2 段目の --dspark-strict は support GGUF を読み込みつつ決定は target-only のまま、というモードです。これが −0.4% しか落ちていないので、積むこと自体はほぼ無害で、損しているのは投機そのものとわかります。DwarfStar 4 の README も「low-yield なプロンプトでは速くならないか、むしろ遅くなる」と書いていて、実験的な機能だと明言しています。

ただしこれは、antirez 本家のエンジンに antirez の support GGUF を組み合わせた場合の話でした。この但し書きが要ることは、記事を書いている最中に思い知ります。

組み合わせを変えて測り直してみた

執筆中に、DGX Spark 1 台向けのレシピが公開されているのを教えてもらいました。単発で 26.7 tok/s という数字が出ていて、自分の測った 17 tok/s 台とは開きがあります。

https://github.com/MiaAI-Lab/DeepSeek-v4-Flash-One-DGX-Spark

中身を読むと、ベースの重みは自分が使ったものと同じファイルでした。違うのは 2 つだけです。

変数が 2 つしか違わないなら追試できます。フォークを v0.5.2 でビルドし、drafter を落として、同じエンジン・同じサーバモード・同じプロンプトで投機だけを切り替えました。

ds4-server は timings を返さないので、生成長を 128 と 512 の 2 点測り、その傾きから decode を割り出しました。プロンプトは共通なので、差を取れば prefill が相殺されます。

差は +1.8%。ほぼ誤差の範囲でした。 最初は生成長 1 点の wall time をそのまま換算して「+14.4%」という値を出していたのですが、prefill を含んだままの数字で、2 点測り直したら差は消えています。なお wall time のばらつきが大きく（同条件 5 回で 11.6〜28.5 秒）、確度には限界があります。

投機デコードで速くなるかどうかは、エンジンと drafter の組み合わせ次第でした。本家に antirez の support GGUF を足すと 22% 損をし、フォークに bleysg さんの drafter を足すとほぼ差なし。「積めば速くなる」とは言えない、というのが手元の結論です。

12 エージェントを同時に捌く、という主張のほうを測る

ここまでは 1 リクエストの速度しか見ていません。ところがこのレシピが前面に出しているのは、実はそこではないのです。公開されている図には「59 tok/s serving 12 AI agents at once」とあります。

この 59 tok/s は 1 台の合計スループットで、1 リクエストの速度ではありません。 同じ図でも、エージェント 1 つあたりの取り分は右肩下がりに描かれています。単発の数字と並べて「速い・遅い」を語ると、読み違えます。

そこで、図と同じ 1・2・4・8・12 の軸で測ってみました。

4 並列と 8 並列は、公開値と誤差 0.4% 以内で一致しました。 12 並列も 56.89 対 59.0 なので、カーブの形はきれいに再現できています。一方で単発だけが 25% ほど低く出ました。ここは計測条件が公開されていないので、どこで差がついたのかは追えていません。

読み取れることは 2 つあります。ひとつは、合計スループットが 8 並列あたりで頭打ちになること。8 で 57.93、12 に増やしても 56.89 と、むしろ微減しています。もうひとつは、1 リクエストあたりの取り分が 12 並列で 4.79 tok/s まで落ちること。単発の 22.44 に対して 5 分の 1 弱です。

つまりこの構成は、1 人が速く使うためのものではなく、複数のエージェントに同時に働いてもらうためのものですね。バックグラウンドで何本もタスクを回すような使い方なら 1 台で 12 本捌けますが、対話的に 1 本ずつ待つ用途なら体感は変わりません。図の 59 tok/s という数字は、その前提で読む必要があります。

前作の数字と直接比べてはいけなかった

ここまで DwarfStar 4 を 0731 の重みで測り直してきたのには理由があります。5 月の記事で載せた 14.81 tok/s と今回の llama.cpp を並べると、間違った結論になるからです。

DwarfStar 4 自身がこの 3 か月で 14〜25% 速くなっていました。エンジンも重みも動いているので、前作の数値は「3 か月前のスナップショット」としてしか使えません。過去記事の数字を引っ張ってくるときは、こういう再測をひとつ挟んでおくと安全ですね。

長いコンテキストと KV キャッシュ

3-bit で 18 GB の余白が残る、という話の続きです。コンテキストを 32,768 から 131,072 に増やして起動してみました。

こちらも起動しました。ctx を 4 倍にしても増えたのは 2,784 MiB だけです。

b10216 のログは簡潔で KV サイズを出してくれないので、この 2 点の差から逆算します。98,304 トークンぶんで 2,784 MiB なので、1 トークンあたり約 29.0 KB。この係数で分解すると、ctx 32,768 の KV は 928 MiB、モデル本体は 99,542 MiB = 97.2 GiB になります。実ファイルサイズが 97.1 GiB なので、ぴたりと合いました。KV が線形に増えるという仮定は妥当そうです。

DwarfStar 4 のほうは起動時にはっきり教えてくれます。

ds4: memory: KV 0.78 GiB (raw 0.36 + compressed 0.42) + buffers 0.25 GiB = 1.03 GiB context
ds4: memory detail: ctx=32768 prefill_cap=4096 raw_kv_rows=4352 compressed_kv_rows=16418

ctx 32,768 で 0.78 GiB、1 トークンあたり 24.4 KB です。llama.cpp の 29.0 KB より 16% ほど小さいものの、桁は同じですね。DeepSeek V4 の圧縮 KV は llama.cpp 側でもちゃんと効いています。

ちなみに 5 月の記事で「圧縮 KV は 1 トークンあたり約 14KB」と書いたのは compressed 側だけを見た値でした。raw を含めた合計は 24.4 KB になります。この記事では raw 込みで揃えています。

では 1M コンテキストはどうでしょうか。29.0 KB/token を線形に伸ばすと、こうなります。

3-bit で 1M は成立しません。2-bit なら計算上は入りますが、実行時バッファを考えると余裕はほとんどないでしょう。これは外挿値で、実際に ctx 1048576 で起動を試してはいない点はお断りしておきます。

6.6 万トークンの日本語文書を読ませてみる

数字だけだと実感が湧かないので、実際の長文を投げてみました。自分が書いた DGX Spark 連載 9 本を連結して 130,331 文字、そこに「日本語で 1 段落に要約して、繰り返し出てくるテーマを 5 つ挙げて」という指示を付けます。5 月の記事で DwarfStar 4 に投げたのと同じ課題です。

16% 多いトークンを、ほぼ同じ時間で処理しました。

出力の中身も確かめてみます。「メモリ帯域（273 GB/s）」「Qwen3.6-35B-A3B-NVFP4 が MTP 有効時に 108 tok/s で新王者」「量子化方式の比較ではモデルによって優劣が逆転」——どれも元記事の記述と合っています。数値の取り違えは見つかりませんでした。3-bit まで潰した 284B が、6.6 万トークンの日本語技術文書を読んで事実関係を保ったまま要約できています。

この検証中に、prefill の速度について 2 つ気づいたことがあります。ひとつは、起動時に確保するコンテキストが大きいほど prefill が遅くなること。ctx 32,768 で起動したときは 3 万トークン投入で 370.83 tok/s でしたが、ctx 131,072 で起動すると 300 tok/s 前後まで落ちました。

もうひとつは、1 回の prefill の中でも進むほど遅くなることです。

n_tokens = 30720, progress = 0.47, 301.57 tokens per second
n_tokens = 34816, progress = 0.53, 297.36 tokens per second
n_tokens = 38912, progress = 0.59, 292.95 tokens per second
n_tokens = 43008, progress = 0.65, 288.63 tokens per second

単調に落ちていって、6.6 万トークン全体の平均が 266.55 tok/s に着地しました。attention のコストがコンテキスト長に対して線形以上に効いているのでしょう。短いプロンプトで測った prefill 速度を長文に外挿すると、実際より楽観的な見積もりになります。

3-bit まで潰した 284B は使えるのか

速度が出ても中身が壊れていたら意味がありません。Unsloth が公開している品質表には 4-bit と 8-bit の行しかなく、今回使う帯域の品質は載っていないので、手元で確かめる必要があります。

まず、答えが機械的に判定できる 5 問を投げました。2-bit の UD-IQ2_M と 3-bit の UD-IQ3_XXS の両方で 5 問とも正答です。1 から 20 までの列挙、2 の 10 乗、sorted(set(xs)) によるコード生成、日本語の説明、指示どおり PONG だけを返す課題。どれも通りました。

唯一の差は日本語の字数制約でした。「50 文字以内で」という指示に対して、UD-IQ2_M が 51 文字、UD-IQ3_XXS が 40 文字。ただしこれは各 1 回ずつの結果なので、これだけで 3-bit のほうが指示に忠実とは言えません。量子化と指示遵守の関係を主張したいなら、同じ問題を複数回まわす必要があります。

続いて、7 月の Laguna S 2.1 の記事で作ったハーネスをそのまま流用して、tool calling と agentic なコード修正を見ていきます。どちらも標準ライブラリだけで OpenAI 互換のエンドポイントを叩く作りなので、vLLM 向けに書いたものを無改造で llama.cpp に向けられました。

https://dev.classmethod.jp/articles/dgx-spark-laguna-s-2-1-nvfp4/

tool calling は 6 問中 6 問正解でした。

擬似ファイルシステムを操作させる agentic な課題も 5 ターンで解けて、壊れた tool_calls は 0 件。ストリーミング中の tool_calls 検出も動きました。

コード修正のほうは、在庫管理 CLI 風の自作ミニリポジトリを使います。学習データに混ざりようがないコードで、12 個のテストのうち 5 個が失敗する状態から始めます。採点はハーネス側が pytest を回して判定するので、モデルの自己申告は関係ありません。

baseline: 5 failed / 7 passed
final:    0 failed / 12 passed  score 5/5  turns=5  wall=72.9s  stop=final_answer

5 ターン、73 秒で全部直しました。stop=final_answer なのでターン上限やタイムアウトによる打ち切りでもありません。同じハーネスで Laguna S 2.1 が 5 ターン・41.7 秒、Qwen3.6-35B-A3B が 10 ターン・23.4 秒だったので、手数は Laguna と並びます。所要時間は今回が最も長いものの、エンジンも量子化も投機の有無も違うので、モデルの優劣として読むべきではありません。

思考モードの制御も期待どおりに動きました。既定では reasoning_content が分離されて返ってきて、リクエストに "chat_template_kwargs": {"enable_thinking": false} を入れると消えます。DwarfStar 4 の --nothink と条件を揃えられたのは、この挙動のおかげです。

まとめると、Unsloth の品質表が触れていない 2-bit と 3-bit の帯域でも、agentic な用途に耐える品質は保たれている、というのが手元での感触です。ただし各タスク 1 回ずつの結果である点は差し引いて読んでください。

まとめ

DeepSeek-V4-Flash-0731 を DGX Spark 1 台で動かして、専用エンジンと比べた結果を整理します。

5 月に「llama.cpp への統合が難航している」と書いた部分は、6 月末の #24162 で解決していました。1,203 行の専用実装が入り、公式版の 0731 も問題なく読めます。速度でも汎用ランナーが専用エンジンを上回っていて、正直これは意外でした。

一方で、起動 6 分半という代償があります。統合メモリで GPU バッファとページキャッシュが取り合う構造なので、モデルが大きいほど不利になる。常駐前提で使うなら気にならない数字ですが、使うたびに立ち上げるなら 17 秒で立ち上がる専用エンジンのほうが快適でしょう。「どちらが速いか」ではなく「どう使うか」で選ぶものが変わる、という結論に落ち着きました。

やり残したこともあります。--no-mmap で起動時間が改善するかは対照を取れていませんし、投機デコードの受理率も測れていません。1M コンテキストは外挿しただけで、実際に起動を試していません。公開されているレシピの 26.7 tok/s も、手元では 19.9 tok/s どまりで再現できませんでした。このあたりは次の機会に確かめてみたいところです。

llama.cpp 側の投機デコードについては、少し気の長い話になりそうです。関連する 2 本の PR はどちらも閉じられたままなので、マージを待つというより、別の実装が出てくるのを待つ形になります。とはいえ 0731 向けのチャットテンプレートを追加する PR は動いていますし、この記事を書いている 2 日のあいだにもタグは b10216 から b10223 まで進みました。投機デコードが本体に入ったら、そのときは条件を揃えて再戦してみたいですね。

参考リンク

• unsloth/DeepSeek-V4-Flash-0731-GGUF
• Unsloth のDeepSeek V4 実行ガイド — 必要メモリ表と推奨設定
• llama.cpp PR #24162 — DeepSeek V4 本体対応（2026-06-29 マージ）
• llama.cpp PR #25871 — K/V cache 型の統一（2026-07-31 マージ）
• llama.cpp PR #25642 — NextN/MTP 投機デコード（マージされずクローズ）
• llama.cpp PR #25683 — DSpark speculator 対応（マージされずクローズ）
• llama.cpp PR #26398 — 0731 向けチャットテンプレート追加（2026-08-02 時点でオープン）
• antirez/ds4（DwarfStar 4）
• antirez/deepseek-v4-gguf — DwarfStar 4 用の専用 GGUF と DSpark support
• MiaAI-Lab/DeepSeek-v4-Flash-One-DGX-Spark — DGX Spark 1 台向けの起動レシピ
• Entrpi/ds4 — 上記が使う DGX Spark 向けフォーク（本記事は v0.5.2 を検証）
• bleysg/DeepSeek-V4-Flash-DSpark-drafter-GGUF — フォーク側で使う DSpark drafter
• DwarfStar 4 で DeepSeek V4 Flash 284B を DGX Spark に載せてみた（2026-05-13 の記事）
• DGX Spark 2 台で DeepSeek V4 Flash-DSpark を動かしてみた（2026-06-30 の記事）