DGX Spark 1 台をパートナーにする LLM 構成を考えてみた

はじめに

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

NVIDIA が Qwen3.6-27B を NVFP4 で量子化した nvidia/Qwen3.6-27B-NVFP4 を公開しました。X では「DGX Spark で Unsloth 版より単一セッションで 4 割速い」というベンチが流れてきて、気になっている方も多いのではないでしょうか。

https://huggingface.co/nvidia/Qwen3.6-27B-NVFP4

自分は DGX Spark を 1 台、ネットワーク越しにノート PC から叩くサポート機として使っています。LLM 専用にするつもりはなく、RAG 用のベクトル DB や埋め込みモデル、ときどき ComfyUI での画像生成も、同じ箱に同居させたい。つまり、単発のベンチで速いモデルを探すというより、「この 1 台をパートナーとして運用していくなら、どんなモデル構成にするか」を決めたいわけです。速いモデル、賢いモデル、日本語がうまいモデル、それぞれ別々に触ってはきたものの、同じ条件で横に並べて測ったことはありませんでした。今回の Qwen3.6-27B-NVFP4 がちょうどよいきっかけになったので、候補をまとめて測り直して考えてみました。

先に結論を書いておくと、DGX Spark 1 台の生成速度は「1 トークンを作るのに読み込む重みの量」でほぼ決まります。Active パラメータの小さい MoE が有利で、素の速度では Nemotron Nano 30B-A3B が single 61 tok/s で頭一つ抜けました。一方、dense 寄りの Qwen3.6-27B は素の状態だと 12 tok/s どまりです。ただし Qwen には投機デコード用の MTP モジュールが同梱されていて、これを有効にすると 2.4 倍の 29 tok/s まで跳ね上がります。冒頭のベンチの「速い」は、この MTP 込みの数字でした。

DGX Spark でモデルを日本語性能ごと比べた記事を 2026-06-28 に書いています。今回はそこに Qwen3.6-27B-NVFP4 を新しく加えて、速度の軸を中心に測り直す形です。

https://dev.classmethod.jp/articles/ornith-1-0-dgx-spark-japanese-benchmark/

この記事では、Qwen3.6-27B-NVFP4 をきっかけに、DGX Spark 1 台をパートナーとして運用するためのモデル構成を、速度と日本語品質、そしてほかの用途とどこまで同居できるかという軸で考えてみます。ローカル LLM を常駐させたいけれど、どのモデルを選べばいいか迷っている方に刺さるといいなと思っています。

Qwen3.6-27B-NVFP4 はどういうモデルか

まず主役の素性を確認しておきます。ベースは Alibaba の Qwen3.6-27B で、これを NVIDIA が自社の量子化ツール ModelOpt（nvidia-modelopt 0.45.0）で NVFP4 に落としたものです。NVFP4 は 4bit の浮動小数点フォーマットで、16bit から 4bit へ圧縮されるぶんディスクと GPU メモリの使用量がおよそ 2.5 分の 1 になります。実際にダウンロードしたチェックポイントは 3 ファイルで合計 20.4GB でした。

中身を覗くと、いくつか特徴がありました。

まず、純粋な dense ではなくハイブリッド構成です。全 64 層のうち 4 層に 1 層が通常の full attention で、残りは GDN（Gated Delta Net）と呼ばれる線形アテンションになっています。次に、reasoning モデルです。質問を投げると、まず英語で考える過程を出力してから答えにたどり着きます。そして、投機デコード用の MTP（Multi-Token Prediction）モジュールが 1 層ぶん同梱されています。これは DeepSeek V4 Flash の DGX Spark 版でも見た仕組みで、あとで効いてきます。

量子化の中身は単一の NVFP4 ではなく MIXED_PRECISION でした。線形アテンションまわりは FP8、それ以外の線形層は NVFP4 という混在で、KV cache も FP8 です。context は 262K まで対応しています。ライセンスは Apache 2.0 なので、素性としては扱いやすい部類です。

公式が出しているベンチマークのスコアも載せておきます。量子化前の FP8 とほぼ同等の精度を保っている、というのが NVIDIA の主張です。

AIME 2025 で 92.7 というのは、数学の難問をかなり解けるということです。dense 系らしく、1 トークンあたりに詰まっている知能の密度は高いモデルだと言えそうです。

DGX Spark 1 台で動かしてみた

ここからが本題です。実行環境は素の vllm/vllm-openai:v0.24.0-aarch64（stable）を基準にしています。コミュニティ製の特殊イメージは不要で、起動コマンドはこれだけです。

vllm serve nvidia/Qwen3.6-27B-NVFP4 \
  --host 0.0.0.0 --port 8000 \
  --quantization modelopt \
  --kv-cache-dtype fp8 \
  --max-model-len 65536 \
  --max-num-seqs 8 \
  --gpu-memory-utilization 0.85 \
  --enable-prefix-caching --trust-remote-code

いくつか環境変数だけは効かせています。DGX Spark では FlashInfer のサンプラー JIT ビルドがこけることがあるので VLLM_USE_FLASHINFER_SAMPLER=0 を渡すのがおすすめです。起動ログを見ると、ハイブリッドの線形アテンションは Triton/FLA のカーネル、FP8 の層は FlashInfer のカーネルがそれぞれ選ばれていて、問題なく動いていました。

日本語も普通に返ってきます。「リンゴを 3 個で 160 円、みかんを 5 個で 200 円買った。合計とみかん 1 個の値段は」といった計算も、Python のコード生成も、考える過程を挟んだうえで正解にたどり着きました。動作そのものは安定しています。

素の速度と MTP でどこまで変わるか

肝心の速度です。同じプロンプトで 256 トークンを強制生成し、TTFT を除いた純粋な decode 速度を測りました。まずは MTP なしの素の状態です。

single で 12.13 tok/s。冒頭のベンチが 26 tok/s だったので、半分しか出ていません。ここで思い当たるのが MTP です。DGX Spark に最適化されたこのチェックポイントには MTP モジュールが同梱されているので、--speculative-config '{"method":"mtp","num_speculative_tokens":3}' を足して測り直しました。

single が 12.13 から 29.38 tok/s へ、2.4 倍に跳ねました。冒頭のベンチの 26 tok/s ともほぼ一致します。「速い」は素の速度ではなく MTP を効かせた状態の数字だった、というのが実機で確認できたことです。

なぜ dense 寄りのモデルは素だと遅いのか。DGX Spark の decode 速度は、ざっくり「メモリ帯域 273 GB/s ÷ 1 トークンで読み出す重みの量」で決まります。dense 系は毎トークンで全パラメータを読みにいくので、27B ぶんを読むと帯域で頭打ちになります。MTP は 1 回の forward で複数トークンを先読みして当てにいく仕組みなので、当たったぶんだけ実効速度が上がる、というわけです。

常用候補と横並びで測ってみた

Qwen 単体だと速いのか遅いのか判断がつきません。DGX Spark 1 台で動く他の候補を、同じハーネスで測って並べてみました。比較したのは NVIDIA の Nemotron が 2 種類（速度枠の Nano と精度枠の Super）、日本語にも強い Ornith、そして万能型の Gemma です。single は 1 リクエストだけを流したときの decode 速度、4 並列は 4 本同時に流したときの合計値で、MTP が使えるモデルの 4 並列は MTP 有効時の値を載せています。Gemma だけは後述の対応状況の関係で nightly ビルドでの計測です。

濃い青が素の速度、薄い青が MTP 有効時の上乗せ。外部 drafter を足した Gemma 62.4 と素の Nano 61.2 がほぼ同着で頭一つ抜ける。

素の速度で一番速かったのは Nemotron Nano でした。30B と大きめですが、MoE で毎トークンに使う Active パラメータが 3B しかなく、素で 61 tok/s。速度を分けているのは総パラメータ数ではなく、1 トークンで実際に読み出す重みの量でした。素の速度で見ると、Active が小さい MoE の Nano と Gemma が上位に来て、Active 12B の Super、dense の Ornith と Qwen が続きます。Ornith が 9B の割に伸びないのは bf16 のまま量子化していないからで、パラメータあたりのバイト数が NVFP4 の 4 倍ある点が効いています。

ちなみに Ornith には MoE の 35B-FP8 版（Active 3B）もあり、前回の記事の計測では 37.5 tok/s と 9B の 3 倍速く走りました。ただし日本語自由記述の評価は 9B のほうが上だったので、この記事では品質枠として 9B を載せています。「Active パラメータ × 量子化」で速度が決まる法則は、同じファミリー内のバリアント選びでもそのまま効くわけです。

MTP は使えるモデルだけの上乗せです。checkpoint に MTP モジュールを同梱しているのは Qwen と Super で、Qwen は 12.1 から 29.4 へ 2.4 倍、Super は 15.8 から 24.0 へ 1.5 倍伸びました。120B を積んだ Super が MTP 込みで 24 tok/s まで来るのは、精度枠としては十分実用の速度です。

そして Gemma です。checkpoint に MTP は同梱されていませんが、Google が drafter（下書き役の軽量モデル）を別リポジトリで公式配布していて、これを指定すると MTP を有効化できます。追加ダウンロードは 832MB だけ。これで素の 30.19 から 62.36 へ 2.1 倍伸び、Nano とほぼ同着の最速タイに躍り出ました。先読みトークン数は 2 で十分で、3 に増やしても速度は変わりません（1 段深い先読みは当たる率が下がって相殺されます）。Nano と Ornith は MTP の仕組みを持たないので、素の数字がそのまま実力になります。

品質面では、コード生成と数値計算はどのモデルも正解を返しました。日本語の自由記述の質は Ornith が頭一つ抜けている印象で、これは前回の記事で ELYZA-tasks のスコアでも確認できていたところです。ただし Ornith は考える過程を常に出力する設定で、これをオフにできません。そのぶんレイテンシは伸びがちで、速度枠というよりは品質枠のモデルです。

指示遵守と外部 drafter で光った Gemma 4

Gemma は面白い立ち位置でした。素で single 30 tok/s、TTFT も 0.05 秒と最速級です。さらに光ったのが指示遵守で、「50 文字以内で説明して」という制約を守れたのは 5 モデル中 Gemma だけでした。ほかは考える過程を長々と出力してしまい、字数を大きく超えます。短く正確に返してほしい用途では、Gemma が頭一つ抜けていました。

MTP の有効化は、起動コマンドに drafter のリポジトリを 1 行足すだけです。

--speculative-config '{"method":"mtp","num_speculative_tokens":2,"model":"google/gemma-4-26B-A4B-it-assistant"}'

この drafter は以前 Gemma 4 MTP の検証記事で使ったものと同じで、当時（5 月時点の vLLM）は 47.9 tok/s でした。同じ組み合わせが今回の nightly では 62.36 tok/s、受け入れ率も 55% から 68% に上がっています。

https://dev.classmethod.jp/articles/dgx-spark-gemma4-mtp-multi-token-prediction-bench/

MTP を有効にしても画像入力は失われません。テキスト専用に切り替わるのは drafter 側だけで、本体は VL のまま動く仕組みです。実際に図形を描いた画像を投げてみると、投機デコードが効いたまま「赤色の円と青色の正方形」と正しく返ってきました。

一点だけ前提があり、Gemma 4 の NVFP4 版は新しめの vLLM が必要です。stable の v0.24.0 では modelopt 量子化パスが Gemma の重み共有（tie_word_embeddings）に未対応で起動できず、執筆時点の nightly なら動きます。この記事の Gemma の計測だけ nightly で行っているのは、そのためです。

ちなみに Gemma には dense の 31B-IT 版もあり、こちらも同じ vLLM で起動しました。ただし dense ぶんを毎トークン読むので single 6.9 tok/s と遅く、DGX Spark で常用するなら MoE の 26B-A4B のほうが素直です。同じファミリーでも、Active パラメータの少ない MoE を選ぶ、という原則がここでも効きます。

設定チューニングより vLLM のビルドが効く。ただし良くも悪くも

もう一つ、速度まわりで覚えておきたい発見がありました。DGX Spark の NVFP4 は vLLM のビルドで挙動がけっこう変わります。そして「新しいほど速い」という単純な話ではありませんでした。

まず、Qwen の MTP を起動フラグで詰められないか試しました。max_num_batched_tokens を増やし、-O3 や --async-scheduling、--enable-chunked-prefill を足す。結果はほぼ変わりませんでした。これらは並列やプリフィルの効率を上げるフラグで、single-stream の decode には効きません。

次にビルドです。Gemma の外部 drafter は素直にビルドの恩恵を受けていて、5 月のビルドで 47.9 tok/s だった組み合わせが執筆時点の nightly では 62.36 tok/s、受け入れ率も 55% から 68% に上がりました。

一方で、同梱 MTP には落とし穴がありました。Qwen と Super の同梱 MTP を執筆時点の最新 nightly で動かすと、見かけの tok/s は伸びる（Qwen 37.7 / Super 46.0）のに、出力が同じトークンを繰り返すだけの壊れた文章になります。投機デコードの受け入れ率を見ると 0% か 100% に張り付いていて、健全なとき（55〜92%、先読み 1 段目ほど高く後段ほど低い階段状）とは明らかに分布が違います。壊れた繰り返し出力は下書き役が完璧に予測できてしまうので、受け入れ率 100% で「速く」見える、というからくりです。throughput ベンチは出力を強制生成して中身を見ないため、数字だけ追いかけると騙されるところでした。

stable の v0.24.0 では、同じ設定で同梱 MTP が健全に動きます。出力はまとも、受け入れ率は階段状、品質チェックも全問正解で、速度も上の表のとおり素の 2 倍前後が安定して出ました。というわけで、この記事の計測は v0.24.0 を基準にしています（v0.24.0 が未対応の Gemma だけ nightly）。教訓は 2 つ。同梱 MTP を使うなら現時点では stable が安全で、nightly を使うときは「出力がまともか」を必ず確認すること。そして tok/s の数字は、受け入れ率の分布と出力の中身をセットで見ないと危ない、ということです。

1 台を RAG や ComfyUI と分け合うなら footprint が効く

ここまでは速度の話でしたが、常用を考えるともう一つの軸が出てきます。メモリの空きです。

自分の想定は、この DGX Spark を LLM 専用にするのではなく、RAG のベクトル DB や埋め込みモデル、ときどき ComfyUI での画像生成と同居させる使い方です。128GB の unified memory を、ざっくり次のように分け合うイメージになります。

ここで効いてくるのが、今回の検証で使った --gpu-memory-utilization です。自分はベンチのために 0.85 まで上げていましたが、この設定だと vLLM が重みと KV cache をあわせて 100GB 超を抱え込みます。実際、Nano を 0.85 で起動したときのログでは KV cache だけで 81.6GiB を確保していました。これでは RAG や ComfyUI の入る余地がありません。共有機として使うなら、0.3〜0.4 まで絞って、残りをほかの用途に空けておくほうが現実的です。

うれしいことに、この値を下げても single-stream の速度は変わりません。減るのは同時にさばけるセッション数と、載せられる context の長さだけです。実際、今回 Gemma 26B-A4B は 0.70、31B-IT は 0.50 で起動して測っていますが、single の速度はどちらも期待どおりの値でした。

この観点で、モデルごとに「共有機として使うなら gpu-util をどこまで下げられるか」を並べてみます。vLLM が確保する量は、GPU から見える約 120GB にこの係数を掛けたものです。重みが載って、ノート PC 1 台から使うぶんの KV が確保できれば十分なので、小型モデルはかなり下げられます。なおこの表は、実測した重みサイズから逆算した机上の目安です。全モデルをこの値で起動し直して詰めたわけではない点はご了承ください。

青が vLLM の確保分、緑がほかに使える分。小型 4 モデルは 80GB 近く空くが、Super だけは逆転して空きが 36GB に細る。

小型の 4 モデルは gpu-util 0.3〜0.35 で収まり、80GB 近くが空きます。ここに RAG のベクトル DB と埋め込みモデルを常駐させて、必要なときだけ ComfyUI で Flux を立ち上げる、という使い方が現実的です。Super だけは重みで 70GB 使うので、gpu-util を 0.7 まで上げないと KV の余裕がなく、空きは 40GB 弱。画像生成を同時にとなると SDXL がぎりぎりで、Flux は厳しくなります。

もちろん、LLM と ComfyUI を同時に走らせれば、GPU の演算を取り合うぶん両方とも遅くなります。埋め込みの呼び出しが挟まれば、そのぶんも乗ります。ただ、個人が自分のノート PC からたまに叩くサブ機、という前提なら、同時実行はそう多くありません。小型モデルを gpu-util 控えめで常駐させておき、LLM は常に応答、画像生成やインデックス更新は空いた枠で回す、という分担が現実的かなと思っています。DGX Spark 1 台を、ノート PC の内蔵 GPU の代わりになる何でも屋として使う、という方向です。

用途で最適解は割れる

ここまでの結果を、用途別に整理しておきます。DGX Spark 1 台での「最適なモデル」は一つに決まらず、何をさせたいかで割れます。

エージェントを常駐させたり、対話をサクサク回したいなら Nemotron Nano 30B-A3B です。single 61 tok/s に加えて 8 並列で 254 tok/s まで伸びるので、複数リクエストをさばく用途にも向きます。drafter もフラグも何も足さずに素でこの速度が出る手軽さは、5 モデルで唯一です。

短く正確な応答が欲しいなら Gemma 4 26B-A4B です。ツール呼び出しや定型的な返答のように、余計な前置きなしで指示どおり返してほしい場面で、5 モデルの中でいちばん素直でした。外部 drafter を足せば速度も 62 tok/s と Nano 並みになり、指示遵守と速度を両取りできます。ただし先ほど触れたとおり、そこそこ新しい vLLM が要ります。

密度の高い知能を 1 台に載せたいなら Qwen3.6-27B-NVFP4 + MTP です。AIME 2025 で 92.7 という dense 系の賢さを、MTP で 29 tok/s の実用速度まで引き上げられます。単一ユーザーで重めの推論を回す用途に合いそうです。

120B ぶんの精度が欲しいなら Super です。MTP を効かせると 24 tok/s まで出て、精度枠としては十分実用の速度でした。ただし先ほど見たとおり、メモリは 1 台をほぼ専有します。日本語の文章の質を最優先するなら Ornith。この 2 つは狙いがはっきりしているときの選択肢です。

速度と品質のほかにも、選ぶ軸はあります。画像も見せたいなら、今回の候補では Qwen と Gemma が画像入力に対応する VL 構成です。うれしいことに、MTP を有効にしても画像入力は失われません。両モデルとも MTP 有効のまま画像リクエストに投機デコードが効いて、正しく応答が返ることを確認しています（速度の計測はテキストで行っています）。Nano と Super はテキスト専用なので、マルチモーダルが要件に入ると選択肢が変わります。使い方でも変わります。OpenWebUI のようなチャット UI で対話するだけなら single の速度と文章の質が効きますし、エージェント（自分の場合は Hermes Agent）から tool calling 込みで叩くなら、指示遵守と並列性能のほうが支配的になります。

そして正直なところ、この使い分けは用途や人によって大きく変わります。自分の場合、本格的なコーディングは Claude Code や Codex CLI に任せていて、ローカル LLM に全部を背負わせるつもりはありません。エージェント側も LLM ルーティングを挟んで、軽いタスクはローカル、中規模以上は OpenRouter 経由でクラウドの複数モデルへ、という振り分けにしています。ローカル 1 台の役割は、軽い定型処理や下ごしらえ、外に出したくないデータの処理の受け皿です。この記事の数字は、その「ローカル枠」に何を置くかを決める材料として使ってもらえたらと思います。

そのうえで、自分の個人ユースでの有力候補は Qwen です。1 台のパートナーには結局あれこれ頼みたくなるので、MTP で 29 tok/s 出て、画像入力にも対応して、AIME 92.7 の賢さを持つバランスのよさが効いてきます。そこに、速度が欲しい常駐枠の Nano、指示遵守が要る定型処理の Gemma を組み合わせる、という構成で運用を始めてみるつもりです。

まとめ

Qwen3.6-27B-NVFP4 を起点に、DGX Spark 1 台で常用するローカル LLM を横並びで測ってみました。分かったのは、生成速度は Active パラメータの小ささでほぼ決まること、そして Qwen の「速い」という評判は同梱 MTP を有効にした状態の話だったこと。素だと 12 tok/s、MTP で 29 tok/s という差は、知っておかないと評価を見誤ります。MTP は checkpoint 同梱の Qwen / Super だけの特権ではなく、Gemma も公式配布の外部 drafter を足せば 30 → 62 tok/s まで伸びます。追加 832MB でこの上乗せなら、試さない手はありません。

きっかけになった Qwen3.6-27B-NVFP4 自体は素の stable イメージで素直に動いてくれて、賢さと速度、そして画像入力まで対応するバランスのよさから、自分のパートナー構成の軸に据える予定です。一方で、速度で見ると素の Nano と drafter を足した Gemma がほぼ同着で頭一つ抜けていて、常駐用途ではこの 2 つが強い。用途で使い分けるのがよさそうです。NVFP4 まわりは vLLM のビルドで速度も挙動も変わります。当面は「同梱 MTP を使うなら stable、Gemma を使うなら nightly」とモデルで基準を分けつつ、ビルドを変えたら tok/s の数字だけでなく出力の中身まで見て確かめるのがおすすめです。

参考リンク

• nvidia/Qwen3.6-27B-NVFP4
• nvidia/NVIDIA-Nemotron-3-Nano-30B-A3B-NVFP4
• nvidia/NVIDIA-Nemotron-3-Super-120B-A12B-NVFP4
• deepreinforce-ai/Ornith-1.0-9B
• nvidia/Gemma-4-26B-A4B-NVFP4
• google/gemma-4-26B-A4B-it-assistant — Gemma 4 26B-A4B 用の公式 MTP drafter
• nvidia/Gemma-4-31B-IT-NVFP4
• MiaAI-Lab/Gemma-4-26B-A4B-DGX-Spark-18-concurrencies — Gemma 4 26B-A4B を DGX Spark で回した並列ベンチ
• vLLM on the DGX Spark
• NVIDIA TensorRT Model Optimizer