2026-05-29 — 回閲覧
Triton の FP8 バイパスが DGX Spark の GB10 から NVFP4 の速度をさらに 17% 引き出す
コミュニティのパッチが NVFP4 の重みを遅い BF16 フォールバックではなく GB10 の FP8 テンソルコアへ通し、DGX Spark 上の Qwen3.6-35B-A3B を 40.8 から 47.6 tok/s へ引き上げる。
NVIDIA は DGX Spark を「FP4 をネイティブに扱える Blackwell マシン」として売り出している——だが今月のコミュニティの実測記事は、その主張に潜む小さな注釈と、マーケティングが示唆するスループットの大半を取り戻す巧妙な 80 行の回避策を明らかにした。要約すると、Spark の GB10 チップのテンソルコアは実際には FP4 演算を直接実行できず、そのため NVFP4 モデルは遅いソフトウェアのフォールバック経路を這っていた。Triton の monkey-patch がそれらをチップの FP8 コアへ通し、Qwen3.6-35B-A3B は 40.8 から 47.6 tok/s へ跳ね上がる。
GB10 は FP4 に対して実際に何をしているのか
NVIDIA DGX Spark の GB10 Superchip（Grace Blackwell、SM121）にはネイティブの FP4 ハードウェアがない。これが重要なのは、vLLM が NVFP4 量子化モデルを渡されたとき、行列乗算をチップの FP8 テンソルコアにまったく触れず、遅い BF16 逆量子化フォールバック（Marlin 経路）へ回していたからだ。4-bit の重みは GEMM 実行前に 16-bit へ展開し直される——これでは量子化の意義の大半が失われる。メモリは節約できても、演算経路はより大きなフォーマットを走らせるのと変わらない速度にとどまる。
この 80 行の Triton バイパス
実測記事（2026 年 4 月 22 日公開、5 月 6 日更新）は、vLLM をフォークせずにこれを解決する約 80 行の Triton monkey-patch を詳述している。モデルのロード時にパッチが NVFP4 の重みを FP8 へ変換し、推論時には torch._scaled_mm を介して GB10 の FP8 テンソルコア上で GEMM を実行する。実行時の monkey-patch であるため、vLLM のソース変更は不要だ——インポートすれば該当カーネルが差し替えられ、既存の NVFP4 チェックポイントが突如として高速経路に乗る。
著者は逆量子化の式における重要な訂正も指摘している。数値オーバーフローを避けるには、グローバルスケールで乗算するのではなく除算しなければならない。これはクリーンなクラッシュではなくゴミ出力や NaN を生む類の「一文字の符号ミス」であり、このパッチを再現しようとする人には特に注意を促す価値がある。
数字
Qwen3.6-35B-A3B（NVFP4）では、単一ストリームの生成が 40.8 tok/s から 47.6 tok/s へ——17% の高速化となった。比較として、同じマシン上のネイティブ FP8 チェックポイントの上限は 53.8 tok/s であり、このパッチは遅いフォールバックと専用に作られた FP8 モデルとの差の大半（ただし全部ではない）を取り戻す。
| 経路 | Qwen3.6-35B-A3B 単一ストリーム |
|---|---|
| NVFP4 を BF16 フォールバックで（Marlin） | 40.8 tok/s |
| NVFP4 を Triton FP8 バイパスで | 47.6 tok/s（+17%） |
| ネイティブ FP8 チェックポイント（上限） | 53.8 tok/s |
この実測は vLLM 0.19.1 と NVIDIA ドライバ 580.142 上で行われた。
実務メモ
Spark でセルフホストしていて、ユニファイドメモリに収まるという理由で NVFP4 チェックポイントを選んできたなら、これは 10 分かける価値がある。正直な判断ツリーはこうだ。モデルのネイティブ FP8 チェックポイントが存在し、かつ収まるなら、53.8 tok/s でそれが依然として最速の経路だ。だが FP8 の重みは FP4 のおよそ 2 倍の大きさで、1 GB のユニファイドメモリも奪い合うマシンでは、大きめのモデルにとってそれは選択肢ですらないかもしれない。その場合、Triton バイパスは小さい FP4 のフットプリントを保ちつつ FP8 上限の約 12% 以内まで到達させてくれる——本当に割に合う取引だ。テスト済みの組み合わせに合わせてスタックを vLLM 0.19.1 とドライバ 580.142 に固定し、出力を信頼する前に「乗算ではなく除算」の訂正を再確認すること。
あまり語られない論点
ここでのより深い教訓は、このハードウェア上での Blackwell マーケティングをどう読むかにある。「ネイティブ NVFP4 の Blackwell」はフォーマットの層では技術的に正しい——チップはこのエンコーディングを理解している——が、GB10 のテンソルコアは FP4 演算を直接実行しないため、この 4-bit フォーマットは、シリコンが実際に高速に走らせられる経路（例えば FP8）へソフトウェアが橋渡しして初めて報われる。tok/s とユニファイドメモリの余裕が勝負のすべてである 3000 ドル級のマシンにおいて、vLLM をフォークせずわずか 80 行のユーザー層パッチがネイティブ FP8 への差の大半を取り戻すという事実は、鋭い注意喚起だ。Spark では、実スループットを決めるのはカーネルとランタイムの層であって、ラベル上の量子化フォーマットではない。フォーマットは重みがどれだけ小さいかを教えてくれるが、それがどれだけ速く走るかは教えてくれない。