双方向KV転送によりマルチターンエージェントワークロードの遅延を削減

Amazon Web Services（AWS）は、vLLMサービングフレームワーク内で双方向のキー・バリュー（KV）キャッシュ転送を可能にすることで、マルチターンエージェントアプリケーションの遅延を大幅に低減する手法を導入しました。2026年10月19日に公開されたこのアプローチでは、プリフィルノードとデコードノードが両方向でキャッシュ済みコンテキストを共有でき、会話履歴が増加しても冗長な計算を排除します。

何が起きたか

一般的なマルチターンエージェントワークフローでは、エージェントは推論、ツール呼び出し、および過去の結果の取り込みを通じてコンテキストを蓄積します。クライアントは通常、システム指示、以前のプロンプト、ツール出力、モデル応答などを含む完全な会話履歴を、各新しいターンごとに再送信します。Prefill-Decode（P-D）分離型サービングアーキテクチャでは、リクエストは専門化されたノード間で分割されます。プリフィルノードはプロンプトを処理してKVキャッシュを構築し、デコードノードはこれらのブロックを取得して応答を生成します。しかし、標準的な実装では、KVキャッシュはプリフィルからデコードへの一方向のみで転送されていました。

この一方向のフローは非効率性を生み出します。応答生成後、デコードノードは元のプロンプトと新規トークンの両方のKVエントリを保持します。次のターンが到着した際、プリフィルノードはこれらのエントリにアクセスできないため、以前の応答に対するKV射影を再計算する必要があります。さらに、デコードノードはセッション状態を維持しますが、プリフィルノードは維持しないため、プリフィルノード上のアクティブなセッションはキャッシュ退避リスクが高まります。完全なキャッシュミスが発生すると、プリフィルノードは全履歴を再計算する必要があり、アクセラレータ容量を消費し、最初のトークン生成までの時間（TTFT）を増加させます。

この課題に対処するため、AWSのエンジニアはvLLM内のNVIDIA Inference Xfer Library（NIXL）KVコネクタを拡張し、双方向転送をサポートしました。これにより、デコードノードは以前に計算されたKVブロックをプリフィルノードに返し、後続のターンで使用できるようになります。この機能は、AWS Elastic Fabric Adapter（EFA）経由で接続されたAmazon EC2 P5enインスタンスで検証され、マルチターンベンチマークにおいてQwen3-32BモデルでTTFTを最大1.6倍、zai-org/GLM-5-FP8モデルで最大3.3倍削減することが示されました。

仕組み

双方向KV転送は、KVキャッシュ対応ルーターと強化されたブロック保持ポリシーに基づいています。ルーターは、クライアントの会話IDをデコードノードのKV転送パラメータにマッピングする軽量なステートフル制御プレーンとして機能します。実際のテンソルではなく、ブロック位置メタデータのみを保存し、この情報はレスポンスストリームから取得されます。最初のターンではキャッシュミスが発生し、リクエストは標準パスに従います。その後、ルーターはデコードノードのメタデータを保存します。後続のターンでは、ルーターがこのメタデータを取得し、プリフィルノードが再計算代わりにデコードノードからのKVブロックを再利用できるようにします。

デコードノードは、生成直後にメモリを解放するのではなく、設定可能な有効期限（TTL、デフォルト480秒）の間、対象となるKVブロックを保持します。これにより、次のターンでもコンテキストが利用可能になります。短いプレフィックスに対してオーバーヘッドが利点を上回らないよう、kv_recompute_threshold設定が再利用のタイミングを制御します。再利用可能なトークン数がこの閾値（デフォルト64）を下回る場合、プリフィルノードはローカルで再計算を行います。それ以外の場合、NIXL READ操作を介してデコードノードからKVを取得します。

主要な詳細

• 双方向KV転送により、テストされた構成でQwen3-32BのTTFTを最大1.6倍、zai-org/GLM-5-FP8のTTFTを最大3.3倍削減できます。
• この機能には、NixlConnectorを搭載したvLLM v0.21.0以降が必要であり、プリフィルサーバーとデコードサーバーの両方で有効にする必要があります。
• AWS EFAはGPUDirect RDMAとNeuron Direct RDMAをサポートしており、GPUまたはTrainiumデバイス間の直接メモリアクセスを可能にします。
• デコードノードは、ターン間での再利用をサポートするために、設定可能なTTL（デフォルト480秒）の間KVブロックを保持します。
• kv_recompute_threshold（デフォルト64トークン）により、短い再利用可能プレフィックスに対する不要なネットワークオーバーヘッドを防ぎます。
• KVキャッシュ対応ルーターは、テンソルを保存せずに、会話IDからKV転送パラメータへのインメモリマッピングを維持します。

なぜ重要なのか

会話アシスタントやエージェントアプリケーションを開発するエンジニアにとって、増加するコンテキストウィンドウの管理は主要なボトルネックです。インタラクション履歴が長くなるにつれ、繰り返されるプリフィル計算は大量のアクセラレータリソースを消費し、遅延を増加させます。双方向転送により、プリフィルノードがデコードノードによって保持されたKVブロックを再利用できるようになることで、この冗長性が軽減されます。その結果、会話が延長されてもTTFTパフォーマンスがより安定し、ユーザー体験とリソース利用率が向上します。

また、このアーキテクチャは、分散推論におけるAWS EFAなどの効率的な相互接続の重要性も浮き彫りにしています。KVブロック転送に伴うわずかなオーバーヘッド（テストでは30〜130 ms）は、特にGLM-5-FP8のような大規模モデルにおいて、再計算時間の節約によって大きく上回られます。これは、スケーラブルなエージェントシステムにとって、専門化されたノード間のデータ移動の最適化が、モデル実行自体の最適化と同じくらい重要であることを示唆しています。

実施できること

• vLLM v0.21.0以降にアップグレードし、プリフィルサーバーとデコードサーバーの両方でbidirectional_kv_xferを有効にします。
• クライアントとサービングノード間のメタデータフローを管理するために、KVキャッシュ対応ルーターを実装します。
• ユーザーターン間の期待時間を基にdecoder_kv_blocks_ttlパラメータを調整し、メモリ使用量と再利用のバランスを取ります。
• モデルの計算時間と相互接続性能に応じてkv_recompute_thresholdを調整します。
• AWSインフラストラクチャにデプロイする場合、低遅延RDMA転送のためにP5enなどのAWS EFA対応インスタンスを使用します。
• 提供されているガイドを使用してベンチマークを再現し、特定のワークロードとモデルにおけるパフォーマンス向上を検証します。