vLLMの双方向KV転送がマルチターンエージェントワークロードのTTFTを改善

TL;DR

vLLMに双方向KVキャッシュ転送機能が追加されました。これにより、デコードノードが生成後のKVブロックをプリフィルノードに返却できるようになり、マルチターンエージェントワークロードにおいて、TTFT（Time-to-First-Token）が Qwen3-32Bで最大1.6倍、GLM-5-FP8で最大3.3倍 高速化されます。

なぜ双方向KV転送が重要なのか

マルチターンエージェントアプリケーションでは、ターンごとに会話履歴全体を再送信するため、プリフィルノードは過去に生成されたトークンのKVキャッシュを再計算する必要があります。この冗長な処理は、コンテキストが長くなるにつれてアクセラレータの使用率とTTFTを増大させます。vLLMはターン間でのKV再利用を可能にすることで、この再計算の大部分を排除し、非常に長いプロンプトであってもレイテンシを低く抑えます。

技術的な貢献

双方向KV転送メカニズム

  • 双方向のKVフロー – 従来のプリフィルからデコード（P→D）への NIXL READ に加え、デコードノードは生成後に適切なKVブロックを保持し、そのメタデータをルーターに返却します。ルーターはこのメタデータを次のプリフィルリクエストに付加することで、デコードからプリフィル（D→P）への NIXL READ を可能にします。
  • 設定可能な制御 –
    • decoder_kv_blocks_ttl (デフォルト 480秒): デコードノードがKVブロックを保持する期間を決定します。
    • kv_recompute_threshold (デフォルト 64トークン): 再利用可能なトークン数に基づいて、リモートのKVを取得するか、ローカルで再計算するかを決定します。

NIXL KVコネクタの拡張

  • NVIDIA Inference Xfer Library (NIXL) KVコネクタを拡張し、プリフィルノードがリモートのKVブロックを利用できるようにしました。これは既存のデコード側の機能と同様です。
  • 実際のデータ転送は引き続き単一の NIXL READ です。制御フローのみが P→D と D→P の方向で異なります。

KVキャッシュ対応ルーター

  • 軽量なステートフルプロキシが、conversation_id からデコードノードから受け取った最新の kv_transfer_params へのメモリ内マップを保持します。
  • ルーターは メタデータのみ（ブロックの場所、TTL、有効期限）を保存し、KVテンソル自体は保存しないため、コントロールプレーンは軽量に保たれます。
  • 実装例は vLLM リポジトリ (disagg_proxy_multiturn.py) で提供されています。

パフォーマンスへの影響

ベンチマーク設定

  • ハードウェア – Amazon EC2 P5en (8× NVIDIA H200) 上のプリフィルノード1台 + デコードノード1台。AWS Elastic Fabric Adapter (EFA) で接続。
  • モデル – Qwen3-32B および zai-org/GLM-5-FP8 (FP8)。
  • 設定 – キャッシュエビクションシナリオを模倣するため、プリフィルノードでプレフィックスキャッシュを無効化。kv_recompute_threshold = 64、decoder_kv_blocks_ttl = 480秒。

TTFTの結果

モデル プロンプト長 (トークン) TTFT OFF TTFT ON 高速化
Qwen3-32B 24k 778ms 460ms 1.6倍
GLM-5-FP8 20k 2,334ms 702ms 3.3倍
  • KV再利用が無効な場合（ターンごとに完全再計算）、TTFTは急激に増加します。
  • 双方向転送を使用すると、TTFTはほぼフラットに保たれます。KV転送によるわずかなレイテンシ（約30〜130ms）は、再計算時間の削減によって十分に相殺されます。

プリフィル時間の内訳

  • KV転送時間 – Qwen3-32Bで30〜130ms、GLM-5-FP8で29〜110ms。
  • 削減されたプリフィル計算 – プリフィル工程の大部分が不要になります。特にトークンあたりの再計算コストが高い GLM-5-FP8 で顕著です。
  • 元の記事のチャートは、各プロンプト長における積み上げ棒グラフの比較を示しています。

機能の導入方法

  1. vLLM v0.21.0以降 にアップグレードし、NIXLコネクタをインストールします。
  2. プリフィルサーバーとデコードサーバーの両方のKV転送設定で bidirectional_kv_xfer を有効にします。
  3. KVキャッシュ対応ルーターをデプロイ – 提供されている disagg_proxy_multiturn.py の例を使用するか、同等のロジックを実装します。
  4. パラメータの調整 – 予想されるターン間レイテンシに合わせて decoder_kv_blocks_ttl を、モデルサイズとネットワーク帯域幅に基づいて kv_recompute_threshold を調整します。
  5. ベンチマークの実行 – 再現性ガイド（スクリプト serve_pd_multiturn.sh, run_multiturn_sweep.sh, cleanup.sh）に従って、自身のクラスターでパフォーマンスを検証します。

エージェントAIデプロイメントへの影響

  • スケーラブルなレイテンシ – 自律型アシスタント、ツール使用エージェント、マルチステップ推論パイプラインなどのアプリケーションにおいて、会話履歴が数千トークンに及んでも低レイテンシを維持できます。
  • アクセラレータの効率化 – KVの再計算を回避することで、GPU/TPUのサイクルが他のワークロードに解放され、リクエストあたりのコストが削減されます。
  • ハードウェアに依存しない利点 – この機能は当初 AWS Trainium クラスターで検証されましたが、GPUベースの P5en インスタンスでも同様の利点が得られ、さまざまなアクセラレータタイプで広く適用可能であることが示されています。
  • 将来の拡張 – デコード側のKVブロックに対するリース更新メカニズムによりメモリの無駄をさらに削減できる可能性があり、動的なしきい値はネットワーク状況の変化に適応できる可能性があります。

再現性チェックリスト

  • インスタンス – EFAが有効で同じAZにある2台の p5en.48xlarge (8 × H200)。
  • ソフトウェアスタック – Ubuntu 24.04, NVIDIA driver 580+, CUDA 13.0, EFA 1.50.0, libfabric 2.6.0, NIXL 1.4.1, vLLM 0.29.0 (PR #40186 を適用)。
  • 主要コマンド – EFA、vLLM/NIXLのインストール、モデルのダウンロード、サーバー起動スクリプト、プロキシの起動、ベンチマークスイープスクリプト。
  • トラブルシューティングのヒント – conversation_id が送信されていること、PR #40186 が適用されていること、TTLが十分であること、EFAプロバイダーが正しく検出されていることを確認してください。

結論

双方向KVキャッシュ転送により、デコードノードは次のターンのためにKVブロックをプリフィルノードに返却できるようになり、長く複雑なマルチターンエージェント会話におけるTTFTを劇的に短縮します。AWS P5en GPUとEFAを使用したプリフィル1台＋デコード1台の構成において、この機能は Qwen3-32Bで1.6倍、GLM-5-FP8で3.3倍 のTTFT高速化を実現しました。このアプローチはアクセラレータに依存せず、TTLや再計算しきい値で設定可能であり、vLLMのNIXLコネクタとKVキャッシュ対応ルーターを使用して統合できます。

参考文献:

Sources