AWS 给 vLLM 贡献双向 KV 传输，多轮智能体对话的首 token 延迟最多降 3.3 倍
预填充与解码分离部署时，多轮对话会反复重算历史；这个功能让解码端生成的 KV 回传给预填充端复用。
// 要点
- 问题：多轮智能体对话每轮都重发全部历史，单向的预填充到解码传输下，预填充节点无法复用解码节点为之前回复生成的 KV，只能重算，首 token 延迟随对话变长而上升。
- AWS 在 Trainium 上开发验证后，把它作为与加速器无关的能力贡献给 vLLM；需要 vLLM v0.21.0 及以上和 NixlConnector，并在预填充、解码两端开启 bidirectional_kv_xfer，仍需一个感知 KV 缓存的路由。
- 在 P5en 上一个预填充、一个解码节点的测试中，Qwen3-32B 在 24k 提示下首 token 延迟从 778 毫秒降到 460 毫秒；GLM-5-FP8 在 20k 下从 2,334 毫秒降到 702 毫秒，官方称长提示下最多降低 3.3 倍。
- 额外的 KV 传输开销约 30 到 130 毫秒，远小于省下的重算时间。
开发者视角自建推理做智能体的，这是今年最实在的延迟优化之一：智能体对话天然是长历史、多轮次，重算历史正是首 token 慢的主因。前提是已经做了预填充和解码分离；还没分离的团队先别为它改架构，先把会话粘到同一节点、开好前缀缓存，收益更便宜。