vLLM Qwen3.5 パフォーマンス最適化

vLLMは、GB200 NVL72システム上でQwen3.5をサービングする際、GPUあたり合計25,000トークン/秒（TPS）を超えるスループットを達成しました。このパフォーマンスの節目は、Qwen3.5のハイブリッド・アテンション・アーキテクチャ向けに、分離型サービング・パスを最適化することで達成されました。具体的には、Gated Delta Network (GDN) の計算と、プリフィル（prefill）およびデコード（decode）ワーカー間の状態転送における課題に対処しました。

Qwen3.5向けの技術的最適化

Qwen3.5は、フル・アテンション・レイヤーとGated Delta Network (GDN) レイヤーを組み合わせたハイブリッド・アーキテクチャを利用しています。スループットを最大化するために、vLLMは主に3つの技術的強化を実施しました。

1. Blackwell向けに最適化されたGDNプリフィル

vLLMは、従来のFLA/Triton実装に代わり、FlashInferからの新しいGDNプリフィル・カーネルを統合しました（PR #3001）。Qwen3.5-397B-A17B-NVFP4を実行する8×B200システムにおいて、この統合により以下の結果が得られました。

GDNカーネル・パフォーマンス: マイクロベンチマークにおいて最大5.92倍の向上。
プリフィル・スループット: プリフィルのみのワークロード（ISL/OSL = 8192/1）において、エンドツーエンドのプリフィル・スループットが1.13倍向上。
レイテンシ: 同一ワークロードにおいて、平均Time to First Token (TTFT) が12%削減。

ユーザーは、GDNバックエンドを auto に設定するか、明示的に --gdn-prefill-backend flashinfer を使用することで、このパスを有効にできます。

2. ハイブリッド・キャッシュおよびGDN状態転送

分離型モードでハイブリッドSSM-attentionモデルをサービングするには、フル・アテンションのKVキャッシュとMambaスタイルのSSM状態の両方を転送する必要があります。vLLMはこれをサポートするために、いくつかの主要な変更を実施しました。

物理メモリ・マッピング: PR #35758により、HMA論理ブロックを物理メモリ領域にマッピングし、転送される記述子（descriptor）を4,284から1,650に削減。これにより、小規模なH100セットアップにおいてスループットが約7%向上しました。
デュアル記述子ビュー: PR #36687により、デュアル記述子ビューとhomogeneous-TPサポートが導入され、プリフィルおよびデコード・ワーカーがNIXLを介して不均一な状態を転送できるようになりました。
GDN拡張: PR #41869により、この分離型パスがQwen3.5のGDNレイヤーをサポートするように具体的に拡張されました。

3. レースフリーな非同期スケジューリング

非同期スケジューリングは、25K tok/s/GPUの閾値を超えるための重要な機能として特定されました。vLLMは、KVブロック転送における2つの重大なレース条件（PR #48481およびPR #45357）を解決しました。これらは以前、非同期スケジューリングを有効にすると精度がゼロに崩壊する原因となっていました。

パフォーマンス・ベンチマーク

環境およびセットアップ

パフォーマンスは、以下の構成を使用して測定されました。

ハードウェア: NVLink72経由で接続されたGB200クラスター。
モデル: Qwen3.5-397B-A17B-NVFP4。
ワークロード: ISL/OSL = 8192/1024、random_range_ratio=0.8 を持つランダム・データセット。
トポロジー: DEP8（8つのGPUにわたるData Parallel + Expert Parallel）を使用する1つのエンドポイントによる固定デコード・サイド、および4から8のエンドポイント（それぞれDEP2を使用）を使用するプリフィル・サイド構成。

結果

精度はGSM8Kベンチマークを使用して検証され、テストされた5つの構成すべてにおいて、集約されたQwen3.5の実行結果と一致する 88% の精度を維持しました。

GPUあたりの合計TPSは、並列実行数（concurrency）を64から5,120まで変化させて測定した結果、25,000 トークン/秒に達しました。5,120という並列実行数の制限は、デコード・サイドのKVキャッシュ容量に起因するものであり、これ以上の増加にはデコード・エンドポイントにさらなるGPUが追加で必要となります。

デプロイメント・レシピとベストプラクティス

これらの結果を達成するために、vLLMは以下の設定を推奨しています。

状態レイアウト: 分離型サービングにおけるconv-state転送には、VLLM_SSM_CONV_STATE_LAYOUT=DS が必須です。
スケジューリング: スループットを最大化するために --async-scheduling を使用してください。
キャッシュ最適化: デコード・エンドポイントにおける実効KVキャッシュ容量を増やすために --mamba-ssm-cache-dtype bfloat16 を使用してください。
モデル・モード: テキストワークロードの場合、マルチモーダル入力を無効化し、アテンション・レイヤーにおける融合された QK-norm + RoPE + gate パスを有効にするために --language-model-only を使用してください。
プリフィル・バッチング: プリフィルがボトルネックにならないよう、プリフィル・サイドに --max-num-batched-tokens 16384 (2× ISL) を設定してください。これにより、高並列実行時においてGPUあたりの合計TPSが約 +8% 向上しました。
フロントエンド・オーバーヘッド: 高並列実行時のフロントエンド・オーバーヘッドを削減するために --stream-interval 100 を設定してください。ただし、これはトークンあたりのレイテンシを増加させます。
モニタリング: ボトルネックの特定とKVキャッシュ利用率のモニタリングのために、デフォルトの統計ログ出力を有効にするため --api-server-count 1 を使用してください。