AWS在vLLM实现双向KV传输，多轮对话TTFT最高降低 3.3 倍
AWS机器学习博客称，该功能让解码节点把已算好的KV缓存回传给预填充节点，避免下一轮对话重复计算历史上下文；在 1P1D的P5en实例加EFA网络测试中，Qwen3-32B的TTFT降低约 1.6 倍，GLM-5-FP8降低最高 3.3 倍。
AI解读：双向KV传输解决的是多轮agent场景中预填充节点的重复计算：解码节点生成回复后保留本轮KV块，路由器缓存其元数据，下一轮预填充节点通过NIXL READ从解码节点取回，只计算剩余后缀。
适用条件由两个参数决定：解码块保留时长decoder_kv_blocks_ttl默认 480 秒且不续期，过期则回退到常规预填充；kv_recompute_threshold默认 64 token，可复用token数低于阈值时预填充节点选择本地重算，高于阈值才从解码节点拉取。
性能数字有明确边界：测试在Amazon EC2 P5en的 1P1D部署、EFA网络下进行，并关闭了预填充节点的前缀缓存以模拟缓存未命中；Qwen3-32B的TTFT从关闭时的 158–778 毫秒降到 122–460 毫秒，GLM-5-FP8从 500–2334 毫秒降到 358–702 毫秒，AWS称结果随负载和配置变化。
启用方式：需要vLLM v0.21.0或更高版本、NixlConnector，在预填充和解码服务器上开启bidirectional_kv_xfer，并使用能感知KV缓存的路由器；该路由器只存块位置元数据，不存KV张量。
该功能最初在AWS Trainium集群上构建验证，后作为与加速器无关的能力贡献给vLLM；文中GPU数据来自P5en集群，作者称这说明收益也能延续到GPU。
AWS机器学习博客发文介绍vLLM中的双向KV缓存传输：在预填充-解码分离部署中，解码节点在生成回复后保留KV块，下一轮对话把这些块回传给预填充节点复用，避免重新计算整个会话历史。
AWS称，在 1P1D部署、Amazon EC2 P5en实例与EFA网络下，最长提示长度测试中TTFT对Qwen3-32B降低约 1.6 倍，对zai-org/GLM-5-FP8降低最高 3.3 倍，并注明结果随负载和配置变化。
机制：解码节点回传KV，路由器存元数据
常规分离式服务只把KV缓存从预填充节点单向传给解码节点。多轮agent每轮都重发系统指令、历史提示、工具结果和模型回复，预填充节点在缓存未命中时要重算全部历史，推高首token延迟并占用加速器容量。
双向传输的流程是：解码节点生成后保留符合条件的KV块，把块元数据放在流式响应里返回；路由器按客户端提供的conversation_id缓存元数据；下一轮预填充节点在应用本地缓存匹配后检查远端可复用KV，达到阈值就发起异步接收，执行D→P的NIXL READ，再计算剩余后缀。
AWS扩展了NVIDIA Inference Xfer Library（NIXL）KV连接器，使预填充节点能消费远端KV块。文中说明预填充与解码节点架构不同，预填充节点能计算完整提示KV，解码节点只能提供已缓存的KV块，因此两种节点仍各自负责本地与远端KV块的元数据计算，但P→D和D→P两个方向共用同一套NIXL READ传输机制。
路由器是位于客户端、预填充和解码节点之间的有状态控制面组件，只在内存中保存块位置元数据，不保存KV张量，元数据从响应流中获取而不是单独向解码节点查询。
两个控制参数：保留时长与重算阈值
解码实例默认在生成结束后立即释放请求的块；开启双向KV传输后，它按decoder_kv_blocks_ttl保留这些块，默认 480 秒，并公布位置和过期时间。TTL到期前到达的下一轮可复用，晚于TTL则回退到常规预填充。AWS指出该TTL固定且不续期，需要按预期轮次间隔调整，在复用收益与显存占用之间取舍；文中把“由心跳续期的租约延伸到解码侧、让空闲会话尽早回收块”列为后续改进方向。
kv_recompute_threshold默认 64 token，控制预填充节点何时放弃远端拉取、改为本地重算：待计算token数低于阈值时重算，达到或超过阈值时从解码节点拉取KV。AWS称短的可复用前缀下，互连与协调开销可能超过重算时间，部署方应依据模型计算时间、KV大小和互连性能调整该值。
测试数据与启用条件
评测使用Qwen3-32B和GLM-5-FP8，在 1P1D的P5en实例集群上进行。为模拟预填充节点已驱逐本地缓存或路由器选中了没有该会话KV块的其他预填充节点，测试用 --no-enable-prefix-caching关闭了预填充节点的前缀缓存。
关闭该功能时，预填充实例每轮重算增长后的完整上下文：Qwen3-32B的TTFT从 2k提示的 158 毫秒升到 24k的 778 毫秒，GLM-5-FP8从 2k的 500 毫秒升到 20k的 2334 毫秒。开启后，Qwen3-32B在相同区间从 122 毫秒升到 460 毫秒，GLM-5-FP8从 358 毫秒升到 702 毫秒。
AWS拆分了预填充耗时：双向传输新增的KV传输时间约为Qwen3-32B 30–130 毫秒、GLM-5-FP8 29–110 毫秒，但省下的重算时间更大，因此开启后的总预填充耗时仍低于仅重算路径。文中解释GLM-5-FP8差距更大，是因为其单token重算时间更高，KV复用随上下文增长收益更明显。
要复现该配置需按GitHub指南操作；在自有环境启用需vLLM v0.21.0或更高版本、NixlConnector，在预填充和解码服务器上开启bidirectional_kv_xfer，并使用KV缓存感知路由器。该功能最初在AWS Trainium集群上构建和验证，后作为与加速器无关的能力贡献给vLLM社区，GPU结果来自P5en集群。