AWSはvLLMで生成側のKVキャッシュを入力側へ戻す方法を公開しました。会話が続く際の重複計算を減らし、応答開始までの時間を改善する構成です。 長い会話やツール実行を伴うAIでは、キャッシュの保持と破棄の条件が性能を左右します。通信量と保存領域を含めた評価が必要になります。 会話の続きで同じ履歴を読み直す負担 AWSは2026年10月19日、vLLMを使う複数ターンの推論向けに、双方向のKV転送を紹介しました。エージェントは指示、過去の応答、ツールの結果を積み上げながら処理を続けます。次の要求で履歴を再送すると、同じ内容を計算し直す負担が生じます。入力処理と生成処理を分けた構成では、生成側が持つ最新の計算状態を入力側が使えない点も問題になります。今回の仕組みは、その状態を次のターンで逆向きに戻して再利用するものです。単一の要求で転送準備を速める方式とは異なり、ターンをまたいで過去の計算を残す方法を扱っています。会話が長くなるほど増える再計算への対処を示しています。 生成側から戻す状態をルーターが結び付ける 原文では、NIXLの接続部分を拡張し、入力側も遠隔のKVブロックを取得できるようにしています。キャッシュを認識するルーターが、前のターンから残る状態と次の要求を結び付けます。再計算するか転送するかを決めるしきい値も設定できます。AWSはTrainiumで開発・検証した機能をvLLMへ貢献し、GPUでも効果を測定したとしています。測定にはEFAで接続したEC2 P5enを使い、Qwen3-32BとGLM-5-FP8の結果を掲載しました。影響を受けるのは、長い対話を扱うアシスタントや、検索とツール呼び出しを繰り返す業務AIの運用者だと見られます。会話の履歴が増える利用形態では、計算装置の能力に加え、状態がどこに残るかが応答性の判断材料になります。キャッシュの利用率を確認できれば、再計算が残る原因を調べる手掛かりになると見られます。 保存量と再計算の境界を業務ごとに決める 導入時には、再利用で減る計算と、状態を保持して運ぶ負担を合わせて測る必要があると見られます。短い会話や中断の多い利用では、長い会話と同じ設定が有効とは限りません。キャッシュが残る時間、同時セッション数、メモリ不足で破棄される頻度が運用上の論点です。複数の利用者を扱う場合は、セッションの識別と権限の境界を明確にする必要もあると見られます。公開された改善幅は、特定のモデルと測定条件によるものです。まず実際の会話履歴を模した入力で、応答開始までの時間と設備の使用率を比較する考え方が参考になります。障害や再起動でキャッシュが失われても処理を継続できるかを確認すれば、性能の向上とサービスの安定性を同じ判断の中で評価しやすくなります。会話の終了を検知して不要な状態を解放する手順も、限られた保存領域を使う際の検討対象になります。