AWS、vLLM（ブイエルエルエム）に双方向KV転送を提供マルチターンのエージェント処理で初回トークンまでの時間をP5enで最大1.6倍・3.3倍短縮と発表

AWSは2026年10月19日（現地）、プレフィルとデコードを別ノードに分けて動かす推論構成で、デコード側が保持したKVキャッシュをプレフィル側へ返す「双方向KV転送」をvLLM（ブイエルエルエム）に提供したと、公式のMachine Learningブログで説明した。ページに記された公開時刻は日本時間10月20日1時台にあたる。AWSによると、Amazon EC2 P5enの1P1D構成（プレフィル1ノード・デコード1ノード）で、初回トークンまでの時間（TTFT）はQwen3-32Bで最大1.6倍、zai-org/GLM-5-FP8で最大3.3倍短くなった。

3行まとめ

1. AWSが、デコード側のKVキャッシュをプレフィル側へ返す「双方向KV転送」をvLLMに提供（vLLM v0.21.0以降で利用）
2. EC2 P5enの1P1D構成で、TTFTはQwen3-32Bが最大1.6倍、GLM-5-FP8が最大3.3倍短縮（AWSの計測）
3. 保持時間の既定は480秒、再計算のしきい値の既定は64トークン。結果はワークロードや構成で変わるとAWSも明記

本記事の内容は、日本時間10月20日1時台に公式ページで確認したものです。

何が変わるのか：2ターン目以降の「計算し直し」を減らす

AWSの説明では、エージェントのように何ターンも続く処理では、クライアントが毎回、システム指示・過去のプロンプト・ツールの結果・モデルの応答といった会話履歴を送り直す。そのため、増えていく文脈を繰り返し処理することになる。

プレフィル・デコード分離（P-D disaggregation）では、1つの要求を役割の違うノードに分ける。プレフィルノードがプロンプトを処理してKVキャッシュを作り、デコードノードがそのブロックを受け取って応答を生成する。AWSによると、従来のKVキャッシュの転送はプレフィルからデコードへの一方向だけで、マルチターンでは次の2つの無駄が出る。

• 応答を作り終えたデコードノードは、プロンプトと新しく生成したトークンの両方のKVを持っている。しかし次のターンでプレフィルノードはそれを受け取れず、前の応答のトークンのKVを計算し直す
• セッションの状態を持つのはデコードノードだけで、プレフィルノードは持たない。そのため、動いているセッションのキャッシュがプレフィルノードから追い出される確率が上がる。キャッシュにまったく当たらない場合、プレフィルノードはシステム指示・過去の要求・ツールの結果・モデルの応答を含む会話履歴の全体を計算し直すことになる

双方向KV転送は、前のターンで作ったKVをデコードノードに残し、次のターンでプレフィルノードへ逆向きに渡すことで、この計算し直しを避ける仕組みだとAWSは説明している。

どう動くのか：NIXL、ルーター、2つの設定値

NIXLコネクターの拡張

AWSは、NVIDIA Inference Xfer Library（NIXL）のKVコネクターを拡張し、プレフィルノードが遠隔のKVブロックを受け取れるようにした。実際の転送（NIXL READ）はプレフィルからデコードへの向きと、デコードからプレフィルへの向きで共通だという。

AWSの記事が示す流れは次のとおり。

1. デコードノードが、条件を満たすKVブロックを生成後も保持する
2. ブロックの位置情報（メタデータ）をストリーミング応答で返す
3. ルーターがそのメタデータを次のプレフィル要求のために保存する
4. プレフィルノードが、ローカルのキャッシュとの照合をしたあとで、遠隔から再利用できるKVを確認する
5. 再利用できるトークン数がしきい値以上なら、非同期の受信を予約する
6. 残りの部分を計算する前に、デコードからプレフィルへのNIXL READを行う

KVキャッシュを意識するルーター

会話の複数ターンにまたがってKVの再利用を調整するには、KVキャッシュを意識するルーターが必要だとAWSは書いている。vLLMにはコネクター側の対応が入っており、記事で使った流れを実装した例のプロキシがvLLMのGitHubにあるとしている。

ルーターはクライアントが渡すconversation_idと、デコード側のkv_transfer_paramsの対応を、メモリ上に持つ。保持するのはブロックの位置情報だけで、KVのテンソルは持たない。メタデータはデコードノードに別途問い合わせず、応答のストリームから得る。

設定値の既定

AWSは、再利用が常に再計算より速いわけではないと書いている。再利用する範囲が短いと、ネットワークや調整のオーバーヘッドが計算時間を上回りうるためで、しきい値はモデルの計算時間・KVの大きさ・ネットワーク性能に合わせて調整できるとしている。TTLは、ターンの間隔の目安に合わせて決め、再利用とアクセラレーターのメモリ使用量のバランスを取る必要があるという。

どれくらい速くなるのか：AWSの計測結果

計測は、Amazon EC2 P5enをAWS Elastic Fabric Adapter（EFA）でつないだ1P1D構成で、Qwen3-32BとGLM-5-FP8を使って行われた。EFAは、AWSのサーバー間で使う低遅延のRDMAネットワークだと記事は説明している。プレフィルノードがキャッシュを追い出した場合や、ルーターが会話のKVを持たない別のプレフィルノードを選んだ場合を再現するため、プレフィルノードのプレフィックスキャッシュを--no-enable-prefix-cachingで無効にしたという。

※「2k」「24k」「20k」はプロンプトの長さ（トークン数）。Qwen3-32BのON側の値は、AWSによるとOFF側と同じ長さの範囲のもの。GLM-5-FP8のON側の値がどの長さに対応するかは、今回取得したページの本文テキストでは明示されていなかった（図は読めていない）。

転送そのものに時間はかかる。AWSによると、Qwen3-32Bで約30〜130ms、GLM-5-FP8で約29〜110msの転送時間が加わるが、省ける計算のほうが大きいため、プレフィル全体の所要時間はONのほうが短い。

AWSは、GLM-5-FP8のほうが差が大きい理由を、トークンあたりの再計算時間が長いため、再利用の効果がより大きく出るからだと説明している。

誰がどう使えるのか

AWSの結論の節は、導入の条件を次のようにまとめている。

• vLLM v0.21.0以降でNixlConnectorを使う
• プレフィルとデコードの両方のサーバーでbidirectional_kv_xferを有効にする
• KVキャッシュを意識するルーターを使う
• GitHubの再現ガイド（Reproducing our results）に従う

再現ガイドは、環境構築、vLLMのプレフィル・デコードサーバーの起動、ベンチマークの実行、結果の収集をカバーするとAWSは書いている。他の構成でも動かせるが、性能はハードウェア・モデル・ワークロード・ネットワークで変わるという。

前と何が違うのか

従来のP-D分離では、KV転送は一方向（プレフィル→デコード）で、デコード側に残ったKVを次のターンで使う手段がなかった、というのがAWSの説明だ。今回の追加は、その逆向きの転送とそれを調整するルーターの流れである。

AWSはこの機能を、まずAWS Trainiumのクラスター（EFA接続）で作って検証し、アクセラレーターを問わない機能としてvLLMに寄贈したと書いている。今回の結果はP5enのGPUクラスターのものだが、効果はGPUにも及ぶことを示すものだとしている。

関連して、同じAWSがSageMaker AIの推論コンテナでMoEモデルのカーネルを最適化した発表は、AWS、Amazon SageMaker AIの推論コンテナでMoEモデルのカーネルを最適化で扱っている。

筆者が公式ページで確認したこと

日本時間10月20日1時台に公式ページを取得して読んだところ、ページには公開日時が「2026-10-19T08:03:23-08:00」と記されており、これが日本時間の1時台にあたる。取得したページの本文は英語だった。図（Figure 1〜6）は本文テキストの取得では中身が読めず、数字は本文に書かれたものだけを使っている。筆者が自分で動かして計測したものではない。

この発表から読み取れないこと

• 数字はAWS自身の計測で、第三者による検証は今回確認した公式ページにはない。最大値（1.6倍・3.3倍）は、試した中で最も長いプロンプトでの値である。AWS自身も、結果はワークロードや構成で変わると書いている
• 計測条件は限られている。1P1D構成、P5en、モデルは2つ。プレフィルノードのプレフィックスキャッシュを無効にした条件で、キャッシュが効いている通常の運用と同じ数字になるとは限らない
• 料金や提供地域について、今回取得した公式ページには記載がない。日本での提供についての記述もない。vLLMの機能として提供されるものなので、利用の可否はvLLMのバージョンと自分の環境で決まる
• TTLは固定で更新されない。AWSは、デコード側にも更新式のリースを広げ、会話が止まった時点でブロックを解放できるようにするのが今後の改善の方向だと書いている。つまり今は、期限が切れるまでメモリを占有しうる
• vLLMの本体にどの時点でどのように取り込まれたかの詳細は、今回確認した公式ページだけでは追えない（バージョンの条件としてv0.21.0以降が示されているのみ）

出典と確認時刻

• Improve TTFT for multi-turn agentic workloads with bi-directional KV transfer in vLLM — AWS Machine Learning Blog（日本時間2026年10月20日1時台に確認。HTTP 200）

本記事は続報があり次第更新します。