vLLMがQwen3.8-2.4TのPDサービングを最適化した方法

概要

Qwen3.8-2.4Tは、大規模MoEとハイブリッドな系列処理構造を組み合わせたモデルです。そのため、単純にモデルのパラメータ数だけを見て推論基盤を設計することは難しくなります。vLLMは今回、GB300 NVL72クラスター上でPrefill-Decode分離、いわゆるPDサービングを評価し、8K入力・1K出力の条件でスループットと低遅延の両方を調べました。

報告されたスループット重視の結果は、GPUあたり約5000総トークンです。一方、対話性を優先する構成では、ユーザーあたり180生成トークンに達しました。重要なのは、これらがすべての用途に適用できる単一の最適値ではなく、目標に応じた性能フロンティア上の測定点だということです。

主なポイント

• 同時実行数はKVキャッシュで制約される。 モデルは92層で構成され、69層がGDN、23層がFull-Attentionです。各層にはMoEブロックがあります。Full-Attentionの状態はトークン数に応じて増加しますが、GDNの状態はリクエスト単位で保持されます。
• ブロックサイズはGDN状態が支配する。 記事の見積もりでは、GDN状態は約4.125MiBで、1ブロックに2112トークンを収容します。8K入力・1K出力のリクエストでは、Full-AttentionとGDNが異なる形でブロックを消費し、合計がリクエスト単位のキャッシュ使用量になります。
• 重み以外のメモリも大きい。 ドライバー、CUDAコンテキスト、NCCLバッファー、アロケーター、ピーク時アクティベーション、CUDA Graphが利用可能なKVキャッシュ容量を減らします。gpu_memory_utilizationも予測不能なピークに備えて余裕を確保します。
• PrefillとDecodeの転送形式を合わせる必要がある。 両エンジンは独立してブロックサイズを計算できますが、KVキャッシュの転送には互換性が必要です。不一致がある場合は--block-sizeを手動指定できますが、キャッシュ領域の一部が無駄になる可能性があります。
• 並列方式は目的に合わせて選ぶ。 テストではTP8とTP4DP4を含む複数の構成を、異なる同時実行数やバッチ上限で比較しています。並列度を上げるだけではなく、アクティベーション、CUDA Graph、キャッシュ容量の制約を同時に満たす必要があります。

意義

この検証で再利用しやすいのは、結果そのものより調整の順序です。まずリクエストごとの状態を見積もり、重みとランタイム予約分を差し引き、アクティベーションのピークを測定します。そのうえで同時実行数、バッチ上限、並列方式を変え、スループットと遅延のフロンティアを作ります。注意機構、再帰状態、MoEを組み合わせたモデルでは、従来のパラメータ数中心の見積もりだけでは不十分になり得ます。

また、PDサービングは単に計算処理を二つに分ける仕組みではありません。PrefillとDecodeのキャッシュ配置、転送互換性、メモリの独立管理が実運用の結果を左右します。vLLMが判断過程まで公開したことで、利用者は特定のベンチマーク設定をそのまま模倣するのではなく、別のモデルやサービス目標に合わせて同じ方法を適用できます。

出典：vLLM Blog