 | 2x RTX PRO 6000 Blackwell 上の MiniMax-M2.7 NVFP4 — 127.7 tok/s（C=1）、2800ピーク（C=128） Luke Alonso の M2.7 NVFP4 量子化モデルで、セットアップ全体をスイープしました。同じ構成を買う人のために書き留めます。 **ハードウェア:** AsRock Rack B650D4U-2L2T、EPYC 4564P、128GB DDR5 ECC、2x RTX PRO 6000 Blackwell（96GB、600W）。C-Payne の C-Payne PM50100 PLX Gen5 スイッチの背後に接続（PIX トポロジ）。 **ソフトウェア:** voipmonitor/sglang:cu130 docker（b12x 0.8.3）経由の SGLang、modelopt_fp4、bf16 KV、TP=2、Luke のデフォルトレシピ。 **デコードスループット（ctx=0、3x 平均、30s/cell）：** | C | agg tok/s | per-req tok/s | |---|-----------|---------------| | 1 | 127.7 | 127.7 | | 8 | 471.6 | 59.0 | | 32 | 1078.9 | 33.7 | | 64 | 1695.4 | 26.5 | | 128 | 2800.2 | 21.9 | **プリフィル（C=1）：** | ctx | TTFT | tok/s | |-----|------|-------| | 8K | 0.50s | 17,286 | | 16K | 0.99s | 16,926 | | 32K | 2.09s | 15,861 | | 64K | 4.94s | 13,319 | | 128K | 13.25s | 9,908 | **推測デコードなし** — M2.7 にはまだ NEXTN drafter がありません。出荷されれば、低い並列度で意味のある向上が期待できるはずです。 長いコンテキストのセルは高い並列度ではスキップします（KV プールは bf16-KV、TP=2 で約 83K トークン）。16K なら、キュー競合が起きるまで per-req あたり C=8 程度までは問題ありません；128K は C=1 のみの領域です。 完全な手法と注意事項: カーネルと量子化を提供してくれた Luke に感謝し、M2.7 NVFP4 重みの最近のキャリブレーションデータ更新をしてくれた Jon に感謝します。 [リンク] [コメント] |
2基のRTX PRO 6000 Blackwell上のMiniMax-M2.7 NVFP4 — ベンチマーク数値
Reddit r/LocalLLaMA / 2026/4/13
💬 オピニオンDeveloper Stack & InfrastructureSignals & Early TrendsTools & Practical Usage
要点
- デュアル構成のRTX PRO 6000 BlackwellセットアップでMiniMax-M2.7 NVFP4を実行すると、C=1で127.7 tok/sを達成し、C=128ではピーク時の合計で約2,800 tok/sまでスケールする。並列度（同時実行数）が上がるにつれて、1リクエストあたりのスループットは低下する。
- プリフィルのスループットはコンテキスト長にわたって測定されており、8Kで約17.3k tok/sから128Kで約9.9k tok/sまで低下している。これはシーケンス長が伸びるにつれて処理が遅くなることを示している。
- ベンチマークは、コンテナ上でSGLangを使用し、modelopt_fp4とbf16のKV（TP=2）で構成している。推論スタックの重要な構成要素として、TP=2と量子化された重みが挙げられる。
- M2.7 NEXTNのdrafterがまだ利用できないため、推測（スペキュレイティブ）デコードは含まれていない。著者は、この機能が提供されれば、低並列時における改善がより大きくなると見込んでいる。
- 実運用上の制約として、長いコンテキスト「セル」は高い並列度では効率が悪化する点が強調されている。理由はKVプールが約83Kトークンであるためで、16KはおおよそC=8までうまく機能し、その後はキュー競合によって性能が伸びにくくなる。
