DGX Spark のパートナー LLM に新王者？ Qwen3.6-35B-A3B-NVFP4 を 2 つの量子化版で比べてみた

はじめに

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

先日、DGX Spark 1 台に常駐させるモデル構成を考える記事を書いたばかりなのですが、その主役だった Qwen3.6-27B とパラメータ違いの Qwen3.6-35B-A3B が、最近話題になっています。Unsloth が新しい NVFP4 量子化版を「2.5 倍速い」と打ち出し、NVIDIA フォーラムでは「いや、実測すると NVIDIA 公式版のほうが速い」という反論が飛び交う。どちらを信じればいいのか気になっている方も多いのではないでしょうか。

https://huggingface.co/unsloth/Qwen3.6-35B-A3B-NVFP4

自分の関心は論争そのものより、この 35B-A3B が「DGX Spark 1 台のパートナー」の座を塗り替えるかどうかです。前回の記事で単体最速だったのは Nemotron Nano と外部 drafter を足した Gemma の 61〜62 tok/s、賢さと画像入力のバランス枠が Qwen3.6-27B の 29 tok/s でした。35B-A3B は MoE で Active 3B、しかも MTP 同梱で画像入力にも対応と、速度枠とバランス枠を一本化しかねないスペックです。ちょうど vLLM の新しい stable v0.25.0 も出たところなので、NVIDIA 版と Unsloth 版の両方をダウンロードして、同じ条件で測り直してみました。

先に結論を書いておくと、自分にとっての単体最速の座が入れ替わりました。NVIDIA 版の 35B-A3B は素で 77 tok/s、同梱 MTP を効かせると single 108 tok/s に到達し、前回の最速勢の 1.75 倍です。そして話題の量子化版対決は、同条件の実測で NVIDIA 版が全構成 12〜17% 速いという結果でした。「2.5 倍」の出どころと、それでも Unsloth 版のベンチ数字が嘘ではなかったからくりも、実測で説明がつきます。

前回の記事はこちらです（2026-07-06 時点の記事です）。今回はこの続編として、同じハーネス・同じ計測条件で 35B-A3B を追加しています。

https://dev.classmethod.jp/articles/dgx-spark-single-node-best-llm-qwen3-6-27b-nvfp4/

この記事では、Qwen3.6-35B-A3B-NVFP4 の 2 つの量子化版を DGX Spark 単体で実測して、速度・品質・画像入力を横断で確認した結果を紹介します。DGX Spark のローカル LLM 選びを更新したい人に刺さるといいなと思っています。

Qwen3.6-35B-A3B はどういうモデルか

まず素性の確認からです。前回の主役 Qwen3.6-27B は「dense 寄りのハイブリッド」で、毎トークン 27B ぶんの重みを読みにいくモデルでした。今回の 35B-A3B は名前のとおり総パラメータ 35B の MoE で、毎トークンに使う Active パラメータは 3B しかありません。256 個のエキスパートから 8 個 + 共有 1 個を選んで動く構成です。DGX Spark の decode 速度は「1 トークンで読み出す重みの量」でほぼ決まるので、この時点で速いことはほぼ約束されています。

うれしいのは、27B の美点がそのまま残っていることです。投機デコード用の MTP モジュールが checkpoint に同梱されていて、画像入力（VL）に対応し、context は 262K まで伸びます。ライセンスも Apache 2.0 です。賢さの公称値も AIME 2025 で 88.8 と、27B の 92.7 に迫る水準を維持しています。

ここで気になるのが、NVFP4 量子化版が 2 系統あることです。中身を覗くと、単なる配布元の違いではなく量子化の方式そのものが違いました。

Unsloth 版は「他の NVFP4 quant より 1.56 倍速い」を掲げていて、これを DGX Spark で試した Mia さんのリポジトリが single 約 80 tok/s を報告しています。一方で NVIDIA フォーラムには「同条件なら NVIDIA 版が 15% 速い」という追試も上がっていて、数字が割れている状態でした。両方ダウンロードして、同じハーネスで測るのが早そうです。

vLLM v0.25.0 で動かすまでに罠が 2 つあった

実行環境は、検証の前日にリリースされたばかりの stable vllm/vllm-openai:v0.25.0-aarch64 を基準にしました。前回の記事は v0.24.0 基準だったので、まずキャッシュに残っていた 27B を v0.25.0 で再測して橋を架けています。base 12.43 / MTP 28.91 tok/s と前回の実測（12.13 / 29.38）から 2.5% 以内に収まったので、ビルドを跨いでも数字はそのまま比べられると判断しました。

その上で 35B-A3B を起動すると、いきなりコケました。詰まりどころが 2 つあったので、先に書いておきます。

1 つ目は起動時のアサートです。デフォルト設定のまま起動すると、次のエラーで止まります。

AssertionError: In Mamba cache align mode, block_size (2096) must be <= max_num_batched_tokens (2048).

35B-A3B は線形アテンション（GDN）を持つハイブリッドで、その Mamba 系 cache のブロックサイズ 2096 が、v0.25.0 デフォルトの max_num_batched_tokens 2048 をわずかに超えてしまうのが原因です。対処は起動フラグに --max-num-batched-tokens 4096 を足すだけ。同じ GDN ハイブリッドでも 27B はこのアサートに当たらないので、35B-A3B 固有の詰まりどころです。

2 つ目は Unsloth 版の推奨フラグです。モデルカードには DGX Spark 向けに --moe-backend flashinfer_b12x --linear-backend flashinfer_b12x と書かれているのですが、公式 v0.25.0 イメージで --linear-backend flashinfer_b12x を指定すると起動できません。

ValueError: --linear-backend=flashinfer_b12x was requested but no 'flashinfer_b12x' kernel exists for this layer type.

フォーラムでも同じ報告があり、このフラグが効くのは Mia さんの Docker イメージのような特殊ビルド（vLLM 0.24.1-dev + FlashInfer 0.6.13）だけのようです。ではバックエンド指定でどれだけ変わるのかを、NVIDIA 版の素の状態で 3 通り測ってみました。

差は 1.5% で誤差の範囲です。起動ログを見ると v0.25.0 の auto は内部で MARLIN カーネルを選んでいて、NVIDIA モデルカードの推奨（marlin）と同じ着地になっていました。つまり公式イメージで使うかぎり、バックエンド指定に悩む必要はありません。以降の計測はフラグ指定なしの auto で統一しています。

まとめると、v0.25.0 での起動コマンドはこうなります。NVIDIA 版は --quantization modelopt、compressed-tensors 形式の Unsloth 版は quantization 指定を外して自動認識に任せる点だけが違います。

vllm serve nvidia/Qwen3.6-35B-A3B-NVFP4 \
  --host 0.0.0.0 --port 8000 \
  --quantization modelopt \
  --kv-cache-dtype fp8 \
  --max-model-len 65536 \
  --max-num-seqs 8 \
  --max-num-batched-tokens 4096 \
  --gpu-memory-utilization 0.85 \
  --reasoning-parser qwen3 \
  --speculative-config '{"method":"mtp","num_speculative_tokens":3}' \
  --enable-prefix-caching --trust-remote-code

素の速度で前回の最速勢を超えていた

計測は前回とまったく同じハーネスです。256 トークンを強制生成して TTFT を除いた decode 速度を取り、single は 3 回の中央値、並列は 2/4/8 同時の合計値を見ます。

NVIDIA 版の結果から。素の状態で single 76.7 tok/s が出ました。前回の最速だった Nemotron Nano の 61.2、外部 drafter を足した Gemma の 62.4 を、MTP なしの素の状態で超えています。同じ Active 3B の Nano より 25% 速いのは、NVFP4 の重みが bf16 換算でさらに軽いぶんの上乗せと見てよさそうです。

そして同梱 MTP を有効にすると、spec=2 で 98.0、spec=3 で 108.3 tok/s まで伸びました。投機デコードの受け入れ率は spec=3 で 1 段目から 0.86 / 0.67 / 0.55 と、健全なときに見える下り階段の分布です。前回 Gemma の外部 drafter では先読み 3 に増やしても速度が変わらなかったのですが、35B-A3B の同梱 MTP は 3 段目の受け入れ率 0.55 でも正味プラスに働く、という違いも面白いところでした。

前回の 5 モデルと並べると、王者交代が一目でわかります。

濃い青が素の速度、薄い青が MTP 有効時の上乗せ。新顔の 35B-A3B は素の時点で前回最速勢を超え、MTP 込みで 108.3 tok/s に到達する。

前回の記事で立てた「decode 速度はメモリ帯域 273 GB/s を 1 トークンで読むバイト量で割った値に近づく」という見立てが、新顔でもそのまま成立した形です。footprint も約 23GB と Nano や Gemma と同クラスなので、gpu-memory-utilization を 0.35 前後まで絞って RAG や ComfyUI と同居させる、前回の共有サブ機構成にもそのまま収まります。

NVIDIA 版と Unsloth 版はどちらが速いのか

ここからが本題です。話題の量子化版対決を、同じ vLLM v0.25.0・同じ backend（auto）・同じハーネスで、素・MTP spec=2・spec=3 の 3 構成それぞれ測りました。

青が NVIDIA 版（modelopt）、緑が Unsloth 版（compressed-tensors）。全構成で NVIDIA 版が 12〜17% 上回った。

single では NVIDIA 版の全勝です。フォーラムの追試報告（平均 decode で Unsloth 版が 15.2% 低い、single 75 vs 90 tok/s）とも整合する結果で、少なくとも自分の環境の DGX Spark の単一セッションにおいて「Unsloth 版のほうが速い」は再現しませんでした。

興味深いのは、MTP の受け入れ率が両版でほぼ同一だったことです。spec=2 でどちらも 0.87 / 0.69、spec=3 でどちらも 0.86〜0.87 / 0.67〜0.69 / 0.54〜0.55。つまり drafter の予測品質に差はなく、差が出ているのは純粋に量子化形式の実行効率です。Unsloth 版の compressed-tensors はアクティベーションを毎トークン動的に量子化する方式で、その計算が single では丸ごとレイテンシに乗ります。8 並列まで負荷を上げると差がほぼ消える（MTP spec=2 ではむしろ僅差で逆転する）のは、このオーバーヘッドがバッチで薄まるからと考えると辻褄が合います。

なお、話題の「2.5 倍」は B200 での throughput を含む主張で、Mia さんの約 80 tok/s も今回の Unsloth 版 MTP spec=2 の 81.6 tok/s でほぼ再現できます。数字そのものは正しく、同条件の NVIDIA 版という比較対象が欠けていただけ、というのが真相のようです。

品質と画像入力も見ておく

速度だけで乗り換えを決めると事故のもとなので、前回と同じ日本語の品質チェック 4 問（50 文字以内の指示遵守、自由記述、コード生成、数値計算）も両版に通しました。

NVIDIA 版は 4 問すべて期待どおりでした。「日本の首都について句読点含め 50 文字以内で」に 11 文字で答え、コード生成は実行検証まで正解、リンゴとみかんの計算も合っています。Unsloth 版はコード生成と計算は正解でしたが、50 文字指示の 1 問だけ考える過程が長引いて答えにたどり着く前に打ち切られました。1 回きりの試行なので有意な品質差とまでは言えないものの、思考が長引く傾向は数字に出ています。

ここで 1 つ注意点があります。35B-A3B は reasoning モデルで、思考の長さが 27B よりだいぶ長めです。最初 max_tokens 512 で品質チェックを流したところ、全問で思考が枠を使い切って回答が空になりました。品質を見るときは 2048 以上を確保するのがおすすめです。

画像入力も確認しました。MTP を有効にしたまま画像リクエストを投げ、vLLM のメトリクスで投機デコードのカウンタを見る方法です。結果は両版とも、テキストでも画像でも投機デコードが動いたままでした。MTP の 108 tok/s と画像入力は両立します。27B で確認したのと同じ挙動が、35B-A3B でも維持されている形です。

まとめ

Qwen3.6-35B-A3B-NVFP4 を DGX Spark 単体で実測して、2 つの答えが出ました。1 つ目、DGX Spark 1 台のパートナー枠は NVIDIA 版 35B-A3B + 同梱 MTP が新しい本命です。single 108 tok/s で速さは前回最速勢の 1.75 倍、賢さと画像入力も揃って、前回自分が軸に据えると書いた 27B のほぼ上位互換になってしまいました。速度枠の Nano、指示遵守の Gemma と使い分ける前提も、まずは 35B-A3B 一本で始めてみる、に更新しようと思っています。

2 つ目、量子化版対決は DGX Spark の single では NVIDIA 版でした。Unsloth 版も 8 並列ではほぼ互角まで詰めてきますし、公称の数字もそれぞれの条件では正しい。ただ「どの条件の数字か」を確認せずに乗り換えると、単一セッションで 17% 損をします。

次は新王者を常駐構成に組み込んで、Hermes Agent からの tool calling と RAG 同居の実運用を試してみたいところです。Nano や Gemma の最新ビルドでの再測、そして特殊ビルド側の flashinfer_b12x フルパスがどこまで違うのかも、機会があれば続編で扱う予定です。

参考リンク

• nvidia/Qwen3.6-35B-A3B-NVFP4
• unsloth/Qwen3.6-35B-A3B-NVFP4
• MiaAI-Lab/Unsloth-Qwen3.6-35b-NVFP4-DGX-Spark — 検証の起点になった Docker 一式
• New 2.5x Faster Qwen3.6 NVFP4 Unsloth quants — NVIDIA Developer Forums — 量子化版論争のスレッド
• Benchmark Report: Qwen3.6-35B-A3B-NVFP4 — NVIDIA Developer Forums（DGX Spark / Jetson Thor / Blackwell 6000 Pro の横断ベンチ）
• nvidia/Qwen3.6-27B-NVFP4 — 前回の主役
• vLLM Releases