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 62 tok/s で頭一つ抜けました。一方、dense 寄りの Qwen3.6-27B は素の状態だと 12 tok/s どまりです。ただし Qwen には投機デコード用の MTP モジュールが同梱されていて、これを有効にすると 3 倍の 38 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 を常駐させたいけれど、どのモデルを選べばいいか迷っている方に刺さるといいなと思っています。

https://dev.classmethod.jp/articles/dgx-spark-use-case-guide/

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:nightly-aarch64 で、この記事の計測は執筆時点（2026-07-05）に pull した nightly（v0.23.1rc1 系）を基準にしています。DGX Spark の NVFP4 まわりは改善のペースが速いので、これから試す方も新しめの nightly を使うのがおすすめです。コミュニティ製の特殊イメージは不要で、起動コマンドはこれだけです。

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

single が 12.47 から 37.69 tok/s へ、3 倍に跳ねました。冒頭のベンチの 26 tok/s を上回っていますが、これは後述する vLLM のビルド差によるもので、少し古いビルドで測ると 28.31 と、ベンチの数字にほぼ一致します。いずれにしても、冒頭の「速い」は素の速度ではなく 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 有効時の値を載せています。

濃い青が素の速度、薄い青が MTP 有効時の上乗せ。Nano 61.8 が頭一つ抜け、MTP を積む Super と Qwen は素の 2.7〜3 倍まで伸びる。

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

MTP は搭載しているモデルだけの上乗せです。Qwen は 12.47 から 37.69 へ 3 倍、Super は 17.07 から 45.95 へ 2.7 倍伸びました。特に Super は、120B を積んでいながら MTP 込みで Qwen より速いという嬉しい誤算です。ただし Super の MTP は並列時の伸びが不安定で、4 並列の合計が 2 並列を下回ることもありました（測るたびに 43〜62 tok/s で振れます）。single の速さは本物ですが、並列で回す用途なら素直にスケールする Nano のほうが扱いやすい印象です。Nano と Gemma と Ornith は MTP モジュールを積んでいないので、素の数字がそのまま実力になります。

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

指示遵守で光った Gemma 4

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

一点だけ前提があり、Gemma 4 の NVFP4 版は新しめの vLLM が必要です。少し古いビルドだと modelopt 量子化パスが Gemma の重み共有（tie_word_embeddings）に未対応で起動できません。今回基準にした nightly なら問題なく動きます。またレシピは他のモデルと少し違い、コミュニティで動作報告のあった設定にならって attention バックエンドを triton_attn、パーサを gemma4 にしています。

ちなみに 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 には効きません。

一方、試しに 2 週間前のビルドで同じ Qwen MTP を測ると、single は 28.31 tok/s と、今回の 37.69 から 3 割近く落ちました。冒頭のベンチの 26 tok/s に近いのはこちらの数字です。素の速度は 12.4 前後でどちらも変わらないので、DGX Spark（GB10）向けの投機デコードまわりのカーネルがこの 2 週間で改善したようです。設定をいじるより、素直にイメージを新しくするほうがよほど効く、というのが実測からの学びでした。

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 62 tok/s に加えて 8 並列で 259 tok/s まで伸びるので、複数リクエストをさばく用途にも向きます。速度重視ならまずこれ、という手応えでした。

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

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

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

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

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

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

まとめ

Qwen3.6-27B-NVFP4 を起点に、DGX Spark 1 台で常用するローカル LLM を横並びで測ってみました。分かったのは、生成速度は Active パラメータの小ささでほぼ決まること、そして Qwen の「速い」という評判は同梱 MTP を有効にした状態の話だったこと。素だと 12 tok/s、MTP で 38 tok/s という差は、知っておかないと評価を見誤ります。

きっかけになった Qwen3.6-27B-NVFP4 自体は素の nightly イメージで素直に動いてくれて、賢さと速度、そして画像入力まで対応するバランスのよさから、自分のパートナー構成の軸に据える予定です。一方で、速度だけ見れば MoE の Nano が頭一つ抜けていて、常駐用途では強い。用途で使い分けるのがよさそうです。NVFP4 まわりは vLLM のビルドで速度も対応モデルも変わるので、常に新しめのバージョンを基準にするのがおすすめです。

参考リンク

• 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
• 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