要点: 持続デコードで 50.5 tok/s が私が得られる最高値です、そして私はそれが SM120 ハードウェアで実際に誰かが得られる最高値だとほぼ確信しています — 130+ tok/s の主張が飛び交っているにもかかわらず。理由は？ NVIDIA 自身の CUTLASS カーネルは自社のワークステーション GPU 上で壊れているからです。
セットアップ
- 4台の RTX PRO 6000 Blackwell ワークステーション エディション（各 96GB GDDR7、合計 384GB）
- SM 12.0 -- これはデスクトップ/ワークステーション用 Blackwell で、データセンター向けの B200 (SM 10.0) ではありません
- PCIe Gen5、NVLinkなし
- Threadripper 24C/48T、512GB DDR5
- Windows 11 + WSL2
- モデル:
nvidia/Qwen3.5-397B-A17B-NVFP4（約 140GB、総パラメータ 397B、トークンあたり 17B のアクティブ）
テストした 16 の構成
利用可能なすべてをテストしました：複数の Docker イメージ、2つの推論フレームワーク、すべての MoE バックエンド、MTP のオン/オフ、異なる CUDA バージョン、EP/PP/TP の組み合わせ、そして十数個のカーネルパッチ。
| 構成 | バックエンド | TP | MTP | tok/s | 判定 |
|---|---|---|---|---|---|
| Marlin TP=4、MTPなし | Marlin W4A16 | 4 | いいえ | 50.5 | 勝者 |
| Marlin TP=2+PP=2 | Marlin W4A16 | 2+PP2 | いいえ | 49 | 僅差の2位 |
| Marlin + MTP=2 | Marlin W4A16 | 4 | はい | 39-40 | MTP によって遅くなる |
| CUTLASS Docker (最良ケース) | FlashInfer CUTLASS | 4 | はい | 41 | 80 個の高速カーネルをスキップ |
| CUTLASS Docker (最悪ケース) | FlashInfer CUTLASS | 4 | はい | 26 | 同じバグ、フォールバックはより悪い |
| vLLM ネイティブ CUTLASS | CUTLASS | 4 | はい | ~5 | ゴミの出力 |
| デフォルト TP=4 (自動バックエンド) | CUTLASS | 4 | いいえ | 6-7 | ゴミの出力 |
| SGLang 0.5.8 | FlashInfer | 4 | -- | NaN | 文字通り NaN |
| エキスパート並列 | Marlin | 2+EP2 | いいえ | 1.4-2.6 | PCIe 上での実行は推奨しません |
| TensorRT-LLM | -- | -- | -- | N/A | アーキテクチャをサポートしていません |
| FlashInfer Sampler | Marlin | 4 | いいえ | 5.9 | デフォルトから 8.6x の低下 |
すべてを阻害している NVIDIA のバグ
以下の点がこの状況を苛立たせます。RTX PRO 6000 には FP4 テンソルコアがあります。NVIDIA はこれらを使う NVFP4 量子化モデルを出荷します。CUTLASS ライブラリには MoE 推論のためにそれらを照らすべきグループ化 GEMM カーネルがあります。
しかし SM120 では、80 個の TMA ワープ専用の grouped GEMM 手法が初期化時にすべて失敗します。 すべてです。エラー:
Failed to initialize cutlass TMA WS grouped gemm. Error: Error Internal (cutlass_kernel_file_gemm_grouped_sm120_M128_BS_group2.generated.cu:60)
したがって native FP4 計算の代わりに Marlin を使うことになり、Marlin は FP4 重みを FP16 にデクオンタイズして標準の GEMM を実行します。理論的スループットの約半分を失います。
CUTLASS の issue #3096 を提出しました。NVIDIA からの返答はありません。
結論として、SM121（DGX Spark、Blackwell のもう一つのバリアント）は NVFP4 MoE を 356 TFLOPS で動作します。つまり SM12x も実現可能です — NVIDIA はまだ SM120 のタイル設定を検証していません。
なぜ MTP は状況を悪化させるのか
これは私を驚かせました。Multi-Token Prediction は役に立つはずですよね？ Marlin を搭載した SM120 では、-22% の後退です：
- MTPなし: 50.5 tok/s
- MTP=2: 39.6 tok/s
MTP のドラフトはネイティブ FP4 活性化で訓練されています。Marlin は W4A16 のデクオンタイズを使用しており、活性化値は若干異なります。その結果、受け入れ率は 61–85% で、予想の 89% に対して低いです。推測と拒否のオーバーヘッドが利益を上回ります。
130 tok/s の主張について
コミュニティフォーラムの誰かが、同じハードウェアでカスタムの SGLang/vLLM フォークを用いて 130–150 tok/s を主張していました。私は両方のリポジトリを入手し、すべてのコミットを検証しました。
カーネルレベルの変更はゼロです。 これらのフォークは Python レベルの量子化設定、アテンションレジストリ、MTP 状態管理を変更します。同じ壊れた CUTLASS フォールバックを使用します。 同じ 80 TMA WS の戦術は失敗します。
50.5 tok/s で動作するコードからどうして 130 tok/s を得られるのでしょうか？最もありそうな説明は、実際の出力トークン数ではなく、推測されたトークン（提案されたものと拒否されたもの）をカウントしていることです。1000 以上のトークンのウォールクロック出力を測定すると、得られるのは 50.5 tok/s です。
もし誰かが SM120 で正しい出力を伴う 130+ tok/s の持続デコードを実際に達成しているなら、私の間違いを示してほしい。タイムスタンプ付きの生成ログを見せてください。
ここに到達するのに必要だったこと
50.5 tok/s に到達するには、FlashInfer と vLLM にまたがる12 のパッチが必要でした：
- 7 件の FlashInfer パッチ: SM バージョンのチェック、計算能力のマッピング、GDC コンパイルフラグ、CuTe DSL アーキテクチャリスト
- 5 件の vLLM パッチ: MoE バックエンド選択における
is_device_capability_family(120)チェック
上流へ提出済み: - FlashInfer PR #2725 - vLLM PR #36453
実用的な意味
397B パラメータのモデルで 50.5 tok/s は実際に素晴らしく、ほとんどの人の Llama 70B セットアップより速いです。モデル品質も優れており、単一ユーザーのワークロードには非常に実用的です。
しかし、実際には 2-3 倍速くあるべきです。NVIDIA はこれを 2万ドル以上のプロ用 AI GPU として販売しています。NVFP4 モデルを提供しています。彼らがそれ向けに設計した推論パスは、それには適用されません。それはソフトウェアの制限ではなく、NVIDIA 自身のカーネルライブラリのバグであり、彼らはそれを認めていません。
このハードウェアを持つ人のための実用的な設定
```bash
重要な部分: Marlin を強制し、MTP を無効化
export VLLM_MOE_FORCE_MARLIN=1
vllm serve nvidia/Qwen3.5-397B-A17B-NVFP4 \ --tensor-parallel-size 4 \ --max-model-len 262144 \ --gpu-memory-utilization 0.95 \ --enable-chunked-prefill \ --enable-prefix-caching \ --kv-cache-dtype fp8_e4m3 \ --calculate-kv-scales
``` Don't use --enforce-eager (CUDA graphs help). Don't enable MTP. Don&apost try expert parallel on PCIe.
未解決の課題
- CUTLASS #3096 -- 根本原因のバグ（NVIDIA の回答なし）
- CUTLASS #2800 -- FP4 は sm_100a に制限
- DeepGEMM #236 -- SM120 はサポート対象外
- vLLM #35566 -- CUDA 不正メモリアクセス MoE SM120
他にも SM120 でこの戦いを戦っている人はいますか？ MoE モデルを実行している他の RTX PRO 6000 / RTX 5090 の所有者の方からの声をぜひ聞かせてほしいです。
