vLLM PD ServingによるQwen3.8-2.4TがGPUあたり5K TPSおよびユーザーあたり180生成トークン/秒を達成

TL;DR

vLLMのPD Servingを用いたQwen3.8-2.4Tモデルは、高スループットモードでGPUあたり合計5,000トークン/秒のスループットを、低レイテンシモードでユーザーあたり180生成トークン/秒を達成し、GB300 NVL72クラスター上でのモデルの完全なパレートフロンティアを確立しました。

発表の概要

本ブログ記事では、vLLMが8K/1Kのワークロードを使用してGB300 NVL72クラスター上でどのように報告されたパフォーマンスを達成したかを詳述しています。再現可能なsrt‑slurmレシピ、段階的なチューニング手法、および合計トークンスループット（TPS）とユーザーあたりの対話性（ユーザーあたりの生成TPS）のバランスをとる完全なパレートフロンティアを提供します。この手法は、あらゆるモデルに適用できるため、単なる数値よりも価値があるものとして提示されています。

スループットの最大化：同時実行数とKVキャッシュの制限

結論

GPUあたりの合計トークンスループットは、主にKVキャッシュ容量によって制限され、これはリクエストごとのGDN状態のサイズによって決定されます。

技術的な詳細

  • モデルアーキテクチャ: Qwen3.8-2.4Tは92層（69 GDN、23 Full‑Attn）を持ち、層ごとに512エキスパートのMoEブロックを備えています。
  • 重みのフットプリント: 非エキスパート重み 91 GiB、エキスパート重み 1,242 GiB。
  • KVキャッシュの構成:
    • Full‑Attn状態: トークン/層あたり 2 KiB。
    • GDN状態（リクエストあたり）: 4 MiB (SSM) + 120 KiB (conv) ≈ 4.216 MiB。
  • ブロックサイズ: GDN状態が支配的であり、2,112トークンを保持するブロック（ブロックあたり4.125 MiB）となります。
  • GPUメモリのベースライン: GB300は279 GBを提供します。ドライバー、CUDAコンテキスト、および8%の安全余裕を除くと、重み、アクティベーション、CUDAグラフ、およびKVキャッシュ用に約254 GiBが残ります。
  • ピークアクティベーションメモリ: トポロジーごとに測定（例：20シーケンスのTP8は0.57 GiB、272シーケンスのTP4DP4は最大2.24 GiBを使用）。
  • CUDAグラフの予約: 保守的に見積もられています。実際の使用量はこれより低いことが多いですが、予約によりOOM（メモリ不足）を防ぎます。
  • KVキャッシュの可用性: 重み以外のメモリ（約20 GiB）を考慮した後、残りのメモリが同時実行可能なリクエスト数を決定します。TP4DP4トポロジーは最も多くのKVキャッシュスペースを提供し、最高の同時実行性を可能にします。

プリフィル（Prefill）パフォーマンス測定

結論

低同時実行数では、TP4DP2+EPトポロジーが最高のプリフィルスループットをもたらします。同時実行数が増えると、TP2DP4+EPが優位になります。

結果

プリフィルスループットはISL/OSL = 8192/2で測定されました。曲線は、同時実行数が増加するにつれてTP2DP4+EPがTP4DP2+EPを追い越す明確な交差点を示しています。

デコード（Decode）パフォーマンス測定

結論

MTP（投機的デコード）は、KVキャッシュがボトルネックになるまでデコードスループットを劇的に向上させます。全体として最適なデコードトポロジーはTEP8 with MTPであり、非常に高い同時実行数ではTP4DP4+EPが続きます。

結果

デコードテストはISL/OSL = 1/1000で行われました。3つの投機的トークンでMTPを有効にするとGPUあたりのスループットが向上し、その後はKVキャッシュの制限に達するまでTEP8トポロジー（MTP付き）がリードし、制限に達した後はTP4DP4+EPがリードします。

分散パレートフロンティア

結論

最適なプリフィルおよびデコード構成を組み合わせることで、モデルがGPUあたり5Kの合計トークンスループットとユーザーあたり180の生成トークンを達成する最終的なパレートフロンティアが得られます。

環境と再現性

  • ハードウェア: GB300クラスター、NVLink72インターコネクト。
  • ワークロード: ISL = 8192, OSL = 1024, 同時実行数 1–2560。
  • モデル: HuggingFaceの Inferact/Qwen3.8-2.4T-A95B-NVFP4。
  • ソフトウェアスタック:
    • vLLM Dockerイメージ vllm/vllm-openai:nightly-a9a17 (リビジョン v0.26.1rc1.dev1177+ga9a17e709)。
    • Dynamo 1.2.0.dev20260526。
    • srt‑slurm v1.0.98。
    • AIPerf v0.12.0。
  • レシピ: すべての起動スクリプトは srt‑slurm‑recipes リポジトリの recipes/multi-node/Qwen3.8/GB300/8k1k/vllm/disagg にあります。

精度検証

すべての構成はGSM8Kベンチマークで検証され、全体で95%の精度を達成しました。これにより、パフォーマンスの向上がモデルの品質を犠牲にしていないことが確認されました。

パフォーマンスの視覚化

  • 図3 – 各分散構成のパレート曲線（同時実行数に対する個別のスイープ）。
  • 図4 – 合計TPSとユーザーあたりの生成速度の間の最適なトレードオフを示す結合パレートフロンティア。

実務者への示唆

結論

提示されたチューニングワークフロー（KVキャッシュの見積もり、アクティベーションとCUDAグラフオーバーヘッドの測定、ワークロードごとのトポロジー選択）により、実務者はvLLM上で大規模モデルのフロンティアレベルのパフォーマンスを再現できます。

実践的なポイント

  1. KVキャッシュのサイズ設定が主要な制限要因です。リクエストごとのGDN状態を正確に計算して、最大同時実行数を見積もってください。
  2. 十分なGPUメモリを確保してください（デフォルトで8%の安全マージン）。CUDAグラフの見積もり誤差に対応するためです。
  3. KVキャッシュの余裕に基づいてデコードトポロジーを選択してください。TP4DP4+EPはキャッシュスペースを最大化し、TEP8はキャッシュが豊富な場合に優れています。
  4. デコードワークロードにはMTPを有効にして、KVキャッシュが飽和するまでスループットを向上させてください。
  5. 提供されているsrt‑slurmレシピを使用して、環境を再現し、自身のクラスターで結果を検証してください。

謝辞

Artem Perevedentsev (NVIDIA)、Vadim Gimpelson (NVIDIA)、Xin Li (NVIDIA)、および貢献とレビューをいただいたより広範なvLLMコミュニティに感謝いたします。

Sources