8月6日、vLLMが「vLLM Reaches 25K Total TPS/GPU on Qwen3.5」と題した記事を公開した。この記事では、disaggregated serving（分散サービング）とBlackwell向け最適化カーネルを組み合わせることで、Qwen3.5をGB200 NVL72システム上で25,000トークン/秒/GPUという性能に到達させた経緯と再現手順について詳しく紹介されている。この数字が際立つのは、通常のTransformerとは異なるハイブリッドアーキテクチャのモデルをdisaggregated servingで動かすという、複数の技術的難所を同時にクリアした上での達成だからだ。
なぜQwen3.5の高速化が難しいのか
Qwen3.5は2026年初頭にリリースされた大規模MoEモデルで、通常のTransformerとは異なるハイブリッドアテンション構造を持つ。具体的には、通常のFull-Attentionレイヤーに加えてGated Delta Network（GDN）レイヤーを組み合わせたアーキテクチャだ。GDNはMamba（SSM＝State Space Modelの代表的実装）に代表される設計思想に近く、Transformerが持つKVキャッシュとは異なる「畳み込み状態（conv state）」を内部状態として保持する。SSMとは、系列データを固定サイズの「状態ベクトル」として圧縮・更新しながら処理する手法で、長文脈での推論効率に優れる一方、その内部状態の扱いがサービング基盤の設計を複雑にする。
この構造がdisaggregated servingと組み合わさると、二つの大きな問題が生じる。なお、disaggregated servingとは、プロンプト処理（プリフィル）を担うワーカーと、トークン生成（デコード）を担うワーカーを物理的に分離し、それぞれ独立にスケールさせる構成のことだ。異なる性質のワークロードを分離することでリソース効率が上がる反面、ワーカー間のデータ転送が新たなボトルネックになりやすい。
- GDN演算のBlackwell GPU向け高速化
- プリフィルワーカーからデコードワーカーへ、通常のKVキャッシュとSSM状態を正しく・効率的に転送すること
25K TPS/GPUを支えた主要な技術的貢献
Blackwell最適化GDNカーネル
最も性能インパクトが大きかった改善が、FlashInferへのBlackwell向けGDNカーネル追加だ（FlashInfer PR #3001）。
従来のFLA/Triton実装と比較して、モデルサイズ・TP構成・シーケンス長・バッチ形状の組み合わせにわたり1.02×〜5.78×の性能向上を実現。vLLM本体への統合（PR #40717）後、8×B200システムでQwen3.5-397B-A17B-NVFP4を動かすと以下の結果が得られた。
- GDNカーネル単体で最大 5.92× の高速化
- プリフィル専用ワークロード（ISL/OSL = 8192/1）でエンドツーエンドのプリフィルスループットが 1.13× 向上
- 平均TTFTが 12%削減
Blackwell対応環境では--gdn-prefill-backend auto（デフォルト）で自動的にFlashInferパスが選択される。明示的に指定したい場合は：
--gdn-prefill-backend flashinfer
ハイブリッドキャッシュ転送（HMA + NIXL）
disaggregated servingでは、プリフィル完了後にKVキャッシュをデコードワーカーへ転送する必要がある。Qwen3.5の場合、Full-AttentionのKVキャッシュとGDNのSSM状態が混在するため、転送記述子の管理が複雑になる。
ここで登場するNIXLとは、vLLMのdisaggregated servingにおいてワーカー間のテンソル転送を担う通信レイヤーで、各メモリ領域の記述子（何をどこへ転送するかの情報）を管理する役割を持つ。Qwen3.5のようなハイブリッドモデルでは、KVキャッシュとSSM状態という異種のメモリ領域が混在するため、この記述子の数が膨らみやすく、転送オーバーヘッドの増大につながっていた。
PR #35758でHMA（Hybrid Memory Architecture）の論理ブロックを正しい物理メモリ領域にマッピングし、NIXLが各レイヤータイプのキャッシュ領域のみを転送できるようにした。この最適化により転送記述子数が4,284から1,650に削減され、スループットが最大約7%向上した（小規模H100イントラノード環境での計測）。
GDN層のP/D分離サポートはPR #41869で追加された。
非同期スケジューリングのレース条件修正
25K tok/s/GPUを超えるうえで特に決定的だったのがこの修正だ。--async-schedulingはスループット向上に大きく寄与する機能だが、KVブロック転送にレース条件が存在し、有効化すると精度がゼロに崩壊するバグがあった。これを修正したことで非同期スケジューリングが実用可能になり、25K超えの達成につながった。
測定結果
計測環境はNVLink72接続のGB200クラスター。モデルはQwen3.5-397B-A17B-NVFP4（NVFP4量子化）、ISL/OSL = 8192/1024。デコード側は1エンドポイント・DEP8（8 GPU）で固定し、プリフィル側のエンドポイント数を4〜8で変化させた。なお、DEPとはData + Expert Parallelの略で、データ並列とエキスパート並列を組み合わせたMoEモデル向けの並列化戦略を指す。
精度検証としてGSM8K（小学校算数レベルの数学ベンチマーク）を実施。全5構成で精度は**88%**、集約構成と同等の値を確認している。
スループットのPareto曲線を以下に示す。
同時リクエスト数（コンカレンシー）は64から5120まで計測。5120を超えるとデコード側のKVキャッシュ容量が枯渇するため、それ以上は計測していない。
再現のためのレシピと実践的Tips
全レシピはsrt-slurm-recipesで公開されており、以下の1コマンドで起動できる。
srtctl run --file <recipe>.yaml
性能に直結する設定のうち、特に重要なものを挙げる。
VLLM_SSM_CONV_STATE_LAYOUT=DS— disaggregated servingでSSMモデルを動かす際の必須設定。これなしにconv状態転送は動作しない。--async-scheduling— 25K tok/s/GPU達成の鍵。上述のレース条件修正が含まれたビルドが必要。--mamba-ssm-cache-dtype bfloat16— デコードエンドポイントの実効KVキャッシュ容量を大幅に増加させる。--language-model-only— テキストのみのワークロードで指定するフラグ。元記事ではマルチモーダル処理を無効化してテキスト推論に特化させる用途として紹介されている。- **
--max-num-batched-tokens 16384（プリフィル側）— ISLの2倍に設定することで、プリフィルが律速になる構成（4〜6×DEP2）で高コンカレンシー時に約+8%**のスループット向上が得られた。
デバッグ時の実用的なTipsとして、--api-server-count 1を設定するとデータ並列エンドポイントでも10秒ごとのスループット・KVキャッシュ使用率ログが有効になり、ボトルネック特定に役立つとされている。またDYN_LOG=errorを設定することでDynamoの大量ログを大幅に削減できる。
今後の方向性
現在の計測はPareto曲線の左端、つまり総スループット最大化に集中している。次のステップとして、ユーザーあたりのGen TPS（生成スループット）を最大化するPD構成の探索が予定されている。そのためにはDEP（Data + Expert Parallel）トポロジーからTEP（Tensor + Expert Parallel、テンソル並列とエキスパート並列を組み合わせた手法）またはTPへの移行が必要になる見込みだ。TEPはDEPと比べてモデル並列度が高く、レイテンシ改善に有利とされる一方、通信オーバーヘッドの増加が課題となる場合もある。この方向性の進捗は今後の記事で報告される予定だ。
詳細はvLLM Reaches 25K Total TPS/GPU on Qwen3.5を参照していただきたい。
