2x RTX PRO 6000 Blackwellで198 tok/sのQwen3.5-122B — 低予算構成、検証済みの結果

Reddit r/LocalLLaMA / 2026/4/10

💬 オピニオンDeveloper Stack & InfrastructureSignals & Early TrendsIdeas & Deep AnalysisTools & Practical Usage

要点

  • 本投稿は、2x RTX PRO 6000 Blackwell を中核に構成した2-GPU推論サーバによる1週間のベンチマークを記録し、SGLang(b12x+NEXTN)とFP4量子化による複数モデルの検証済み・単一ユーザーのデコードスループットを報告している。例としてQwen3.5-122Bは約198 tok/s。
  • 著者は、エンドツーエンドのテスト詳細(生のJSON、起動コマンド、手法)を提示し、デコードスループットがコンテキスト長4K〜150Kの範囲で概ね一定に保たれる一方、TTFTはより長いコンテキストで増加することを報告している。
  • VRAMの見積りから、最大コンテキスト131Kに対応するKVキャッシュに対して十分なヘッドルームがある(KVバジェットは約2.4Mトークン)とされており、高いVRAM使用率が安定した性能を妨げるのではないかという懸念に反論している。
  • 性能の要因は、PCIeスイッチ(PIXトポロジ)を中心とした「秘密のソース(secret sauce)」による低遅延なGPU間通信に加え、SGLangのb12x MoEカーネル、NEXTNの推測デコード、最適化されたoneshot allreduce/融合といった具体的な推論最適化にあるとされる。
  • 運用上の安定性のためには、特定のシステム/パフォーマンス設定(例:pci=noacs、uvm_disable_hmm=1)が必要で、それらがない場合、著者はマルチGPUのP2Pがハングして動けなくなると報告している。

過去1週間、2-GPUの推論サーバを最適化していて、その結果を共有したいと思います。完全なデータは公開されており、生のJSON、起動コマンド、手法(methodology)があります。

**ハードウェア:**

- RTX PRO 6000 Blackwellを2基(各96GB GDDR7)

- EPYC 4564P

- 128GB DDR5 ECC

- c-payne PM50100 Gen5 PCIeスイッチ

- AsRock Rack B650D4U サーバーボード

**結果(C=1、シングルユーザーのデコード、tok/s):**

| モデル | tok/s | エンジン | 設定 |

|---|---|---|---|

| Qwen3.5-122B NVFP4 | 198 | SGLang b12x+NEXTN | modelopt_fp4、speculative decode |

| Qwen3.5-27B FP8 | 170 | vLLM DFlash | 2B drafter、2 GPU |

| MiniMax M2.5 NVFP4 | 148 | vLLM b12x Docker | modelopt_fp4 |

| Qwen3.5-122B NVFP4 | 131 | vLLM MTP=1 | compressed-tensors |

| Qwen3.5-397B GGUF | 79 | llama.cpp | UD-Q3_K_XL、完全にVRAM内 |

**聞かれる前に:**

*"122Bで198 tok/s?そんなのありえない。"*

3回実行で検証済み:197、200、198。さらにcurlでも確認:12.7秒で2000トークン。生のJSONは下にリンクしています。

*"ctx=0の恣意的な選び方だよね。"*

今日、C=1でコンテキストのスケーリングをテストしました:4K=1.8秒、16K=2.3秒、57K=7.1秒、150K=23.3秒のTTFT。どの長さでもクラッシュはありません。デコード速度はコンテキストに関わらず約198のままです——TTFTは増えるが、デコードは増えません。

*"VRAM使用率85%じゃ余裕がない。"*

サーバログからGPUごとのVRAM内訳:重み39.75GB + KVキャッシュ13.9GB + Mamba状態26.4GB + 空き13.5GB。KV予算は2.4Mトークン——モデルがサポートする最大コンテキストは131Kのみです。余裕は十分あります。

*"それならThreadripperを買えばよくない?"*

私も持っています。この構成は(168 tok/sに対して198 tok/sで)18%速いです。理由は、PCIeスイッチがCPUのルート複合部を介さず、P2Pをサブマイクロ秒のレイテンシでシリコン経由にルーティングするためです。MoE TPデコードでは、あらゆるフォワードパスが数十個の小さなallreduce待ちでブロックされます。メッセージは小さいです(アクティブパラメータが10B)ので、帯域幅は重要になりません。同期1回あたりのレイテンシが効きます。PIXトポロジは帯域ではなくレイテンシで勝ちます。

**秘訣(secret sauce):**

  1. PCIeスイッチ(PIXトポロジ)— GPU同士の通信をCPUではなくスイッチファブリック経由で実施

  2. SGLangのb12x MoEカーネル — FlashInfer CUTLASSより26%高速

  3. NEXTNのspeculative decoding — 推測なしより+65%

  4. PCIe oneshot allreduce + fusion — マルチGPU通信を最適化

  5. modelopt_fp4チェックポイント(txn545)— b12xカーネルに必要。compressed-tensorsのチェックポイントではb12xで動きません

  6. パフォーマンス・ガバナー + pci=noacs + uvm_disable_hmm=1 — これらがないとP2Pがハングし、GPUが詰まります

  7. **すべてのデータは公開されています:**

- 結果 & 手法:

[github.com/Visual-Synthesizer/rtx6kpro/benchmarks/results.md](https://github.com/Visual-Synthesizer/rtx6kpro/blob/master/benchmarks/results.md)

- 生のベンチマークJSON:

[github.com/Visual-Synthesizer/rtx6kpro/benchmarks/inference-throughput](https://github.com/Visual-Synthesizer/rtx6kpro/tree/master/benchmarks/inference-throughput)

- 3回実行の検証データ:

[run1](https://github.com/Visual-Synthesizer/rtx6kpro/blob/master/benchmarks/inference-throughput/sglang\_122b\_verify\_run1.json),

[run2](https://github.com/Visual-Synthesizer/rtx6kpro/blob/master/benchmarks/inference-throughput/sglang\_122b\_verify\_run2.json),

[run3](https://github.com/Visual-Synthesizer/rtx6kpro/blob/master/benchmarks/inference-throughput/sglang\_122b\_verify\_run3.json)

質問があれば喜んで答えます。数値が間違っていると思うなら、起動コマンドはリポジトリ内にあります——自分で再現してみてください。

submitted by /u/Visual_Synthesizer
[リンク] [コメント]