TL;DR
Blackwellファミリーの最新メンバーとして、GB300 NVL72は長いコンテキストLLM推論の最強プラットフォームです。本記事では、128K/8K ISL/OSL（Input Sequence Length/Output Sequence Length）長いコンテキストサービスにおけるDeepSeek R1-NVFP4の最適化の最新進展を共有します。prefill–decode disaggregation (PD)、chunked pipeline parallelism (PP)による予測充填、wide expert parallelism (Wide-EP)によるデコード、multi-token prediction (MTP)、overlap scheduling、注意力softmaxの特殊機能ユニット（SFU）の2倍のスループット向上による高速化された注意力カーネルを採用しています。
長いコンテキスト負荷では、SGLangはGB300 NVL72上で最高226 TPS/GPU（1.53X GB200比）を実現し、ほぼ同等のGPUスループット下でMTPは1.87Xのユーザースループット（TPS/User）を向上させています。また、同等の遅延条件下でのGB200 NVL72設定と比較して、GB300は典型的なシナリオで持続的に1.4X–1.6XのTPS/GPUを提供します。
再現ガイドは、issue:18703で確認できます。
ハイライト
- 長いコンテキスト（128K/8K）ピークスループット：SGLangはGB300 NVL72上で226.2 TPS/GPUを実現し、GB200比1.53Xの優位性；同等スループット下で、MTPは1.87X TPS/Userを駆動。
- 同等遅延条件下でのGB300 vs GB200：GB300はマッチした負荷下で1.38X-1.58X TPS/GPUを提供。
- EPデコード拡張：GB300の1.5X大容量HBM（288 vs 192 GB）は1.6X高い有効デコードバッチサイズ（40 vs 24 req/GPU）をサポートし、DEP8時は288並行リクエストに拡張、ほぼ回撤なし。
- PP予測充填と最適化注意力カーネル：128K予測充填TTFTは僅か8.6s（動的チャンキング、GB200比1.07X–1.23X低減）、注意力softmaxの特殊機能ユニット（SFU）の2倍スループット向上による1.35X高速FMHAカーネルに起因。
方法
本節では、GB300の長いコンテキスト性能向上を実現する主な技術を紹介します。
1. NVIDIA Dynamoとのデプロイメントと統合
本記事では、DeepSeek-R1のGB300 NVL72上でのデプロイメントはNVIDIA Dynamo（GitHub）を使用して調整されます。これは、クラスター規模のprefill–decode (PD)分離推論のための高性能コントロールプレーンです。Dynamoは、異種の予測充填およびデコードワーカープールの調整の複雑さを処理し、KV-cacheを認識したルーティング、ワーク調整、ライフサイクル管理、および超高スループットを維持するための最適化された前処理・後処理スタックを提供します。
- 低オーバーヘッドオーケストレーション：Dynamoの核心的利点は、軽量なKV-cacheを認識したリクエストガイドと効率的なメタデータ管理にあります。PD調整が頻繁に行われる長いコンテキストシナリオでは、Dynamoはスケジューリング層が近似ゼロの遅延を導入することを保証し、SGLangの最適化カーネルがオーケストレーションロジックのボトルネックに妨げられることなく、GB300のHBM3e帯域幅を飽和させます。
- プロダクションレベルスケーリング：Dynamoは、動的ワークディスカバリー、ヘルストラッキング、異種予測充填/デコードプールのライフサイクル管理を含む、マルチノードPDデプロイメントのための堅牢な調整を提供し、インスタンスのスケール、ローリング、または再起動時にデプロイメントが安定したままであることを保証します。
これらのレシピをプロダクション環境にデプロイするには、Dynamo KubernetesスタックがGB200/GB300をサポートし、推論を認識した自動スケーリングとクラスタートポロジを認識したスケジューリングを備えています。
2. 予測充填パス：PP予測充填、長いコンテキストTTFTと高速カーネル
長いコンテキスト推論（例：128Kトークン）では、特にプレフィックスマッチングがない場合、TTFTが主要な制約となり、TTFTの改善が重要です。我々は、Chunked Pipeline Parallelism (PP)をDynamic Chunkingと組み合わせて採用し、プロンプト計算を分散させ、パイプラインステージのオーバーラップを改善します。
GB200シリーズの最適化に基づき、我々はFP8 Attentionを全面的に有効化し、ネイティブFP8 KV-cacheサポート（予測充填とデコード）を導入しました。主な利点：
- メモリトラフィック削減：BF16と比較してメモリ帯域幅のボトルネックを最小化し、スループットと安定性を向上。
- KV容量の倍増：固定メモリ内でKV-cache容量を倍増させ、より大きなバッチまたはより長いシーケンスをサポート。
我々はまた、GB300専用のハードウェアアクセラレーションによるSoftmax注意力カーネルを活用しています。Blackwell Ultra GPUはSpecial Function Unit (SFU)をアップグレードし、注意力softmaxの重要な操作に対して2倍の加速スループットを提供します。注意力が集中する長いコンテキスト予測充填では、これは計算ボトルネックを直接削減します。ベンチマークは、このアップグレードによりFMHAカーネルがGB200比1.35X加速し、全体のTTFTを低下させることを示しています。
3. デコードパス：長いコンテキスト推論におけるメモリボトルネック
長いコンテキストデコードは迅速にKV主導およびメモリバウンドになります：各新規トークンは完全なKV履歴を繰り返し読み取るため、KV容量（常駐シーケンス数）とHBM帯域幅が主要なボトルネックとなります。
SGLangは専用のランタイムスタックとアーキテクチャ戦略を採用しています：
- Wide-EP拡張：EP（Expert Parallelism）はDP attentionと組み合わせてMoE重みとKV cacheをより多くのGPU（本作業では最大32）に分散させ、GPUあたりのメモリ圧力を低下させ、「回撤」（再計算）なしでより大きなデコードバッチをサポートします。
- CuTe DSL nvfp4カーネル：デコードフェーズの高性能nvfp4 MoE操作に特化。
- DeepEP：効率的なall-to-all通信を実現するための最適化された分散およびマージカーネル。
GB300（Blackwell Ultra）はGPUあたり288 GB HBM3e——GB200の1.5Xです。DEP16を例として最大デコード並行性を評価し、公平な比較のためにmem_fraction_static=0.75を固定します（GB300は実際にはより高く設定可能）。トークンあたりのKVフットプリント（35,136 Bytes）と128K+8K負荷（~136Kキャッシュトークン/リクエスト）に基づいて計算します。
SGLangでは、mem_fraction_staticはモデル重みとKV cacheに割り当てられるGPUメモリの割合を定義し、残りは活性化とランタイムバッファ用です。KVフットプリント計算：(kv_lora_rank + qk_rope_head_dim) × num_layers × num_kv_head * fp8_size = (512 + 64) × 61 × 1 × 1 = 35,136 Bytes/token。| 項目 | 仮定/指標 | GB300 (@ mfs=0.75) | GB200 (@ mfs=0.75) |
|---|---|---|---|
| HBM per GPU | HBM3e総容量 | 288 GB | 192 GB |
| Static budget | HBM × mem_fraction_static | ≈ 216 GB | ≈ 144 GB |
| Model weights per GPU | FP4量子化DeepSeek-R1, EP16/TP16 | ≈ 40 GB | ≈ 40 GB |
| KV pool budget | Static budget – Model weights | ≈ 176 GB | ≈ 104 GB |
| Workload | リクエストあたりキャッシュトークン | 136K (128K+8K) | 136K (128K+8K) |
| KV footprint | トークンあたりcell_size | 35,136 B | 35,136 B |
| KV per req per GPU | 136K × cell_size | ≈ 4.45 GiB | ≈ 4.45 GiB |
| Theoretical cap | KV pool / KV per req | ≈ 40 req/GPU | ≈ 24 req/GPU |
| Practical target | 上限の~85%で回撤減少 | ≈ 36 req/GPU | ≈ 20 req/GPU |
| EP16 mapping | req/GPU × 16 GPUs | ≈ 576並行リクエスト | ≈ 320並行リクエスト |
表は、GB300の大容量HBMがほぼ直接的に高いデコード並行性に変換されることを示しています——理論的上限は40 vs 24 req/GPUです。実際の運用では、KV cacheを完全に占有して回撤を引き起こすのを避けるため、上限の約85％で運用し、GB300は36 req/GPU（576並行）、GB200は20（320並行）を達成します。
4. Overlap Schedulerが推進するMTP
v0.4以降、overlap schedulerはSGLangのデフォルトバッチスケジューリング戦略となり、CPUスケジューリングとGPU計算のオーバーラップによりゼロCPUオーバーヘッドを実現しています。同時に、Multi-token Prediction (MTP)は最も人気のある推測デコード手法の一つであり、DeepSeek R1などの主流モデルで広く採用されています。SGLangでのMTP実装の詳細はこのブログを参照してください。
MTPとoverlap schedulerをシームレスに結合するために、SGLangはSpec-V2を提案し、細かなメッセージパッシングとオーバーラップ戦略によりMTPバッチの同期を緩和します。具体的には、Spec-V2はデュアルストリーム設計を採用します：フォワードストリームはすべてのGPU計算を処理し、スケジューリングストリーム（非同期性を強調）は結果処理、メモリ解放、次のバッチ準備などのCPU操作を処理します。
デバイスからホストへのメタデータテンソル転送による同期障壁を回避するため、Spec-V2はfuture tensor mapを作成します：スケジューリングストリームはまずメタデータテンソル参照を作成し、最終バッチが実現されるまで読み取らないため、CPU操作をオーバーラップさせることができます。
© 2026 Winzheng.com 赢政天下 | 转载请注明来源并附原文链接