vLLM 用分布式缓存加速 Kimi 模型的多轮 Agent 推理

这项工作涉及三个不同层次。

• vLLM 是部署模型、接收请求并调度 GPU 的推理服务引擎；
• Kimi-2.5 和 Kimi-K3 是它加载的模型；
• AgentX 是压力测试，它按照真实 Coding Agent 会话的长度、轮次、停顿和子 Agent 分叉重放请求，但用合成文本替换用户代码与对话。

因此，实验衡量的是推理服务的吞吐和延迟，不是模型能力或代码任务正确率。

9 月 3 日，SemiAnalysis 汇总了 vLLM 团队围绕 AgentX 完成的两周软件修复。改动集中在服务器怎样保存、查找和搬运模型处理长历史后留下的缓存状态；其披露的 Kimi 模型高并发曲线显示，总体处理能力提高到原来的六倍以上。

六倍不代表单个编码任务缩短到六分之一。这个数字叠加了缓存保留、增量写入、异步查询和传输等多项改动，公开材料没有给出固定配置的完整前后 A/B 与逐项消融。证据更完整的是 vLLM 与 Mooncake 5 月公开的另一组实验：Kimi-2.5 NVFP4、12 张 GB200、1P1D 部署和 610 条 Codex Agent 轨迹下，加入 Mooncake Store 后吞吐提高 3.8 倍。这里的 Kimi-2.5 是被服务的模型，Codex 轨迹提供多轮流量形状，优化对象仍是 vLLM 推理系统。

演进主线： 2023 年 PagedAttention 解决单机显存里的 KV 缓存碎片 → 2025 年 Mooncake 把预填充、解码和跨节点缓存拆开 → 2026 年 AgentX 用真实多轮轨迹暴露“下一轮怎样找回上一轮状态”的系统瓶颈。

核心判断： 多轮 Agent 的推理成本，大量消耗在反复计算旧历史，而不是处理本轮新增内容。vLLM 让不同轮次、不同服务器复用已经算过的缓存，因此同一批 GPU 可以承载更多持续会话。收益大小取决于历史长度、每轮增量和缓存命中率，不能直接套用到短问答或长输出任务。

三代系统分别解决显存碎片、跨节点复用和多轮恢复

要理解这次优化解决了什么，需要先看推理服务怎样保存模型已经读过的上下文。

所谓 KV 缓存，可以先理解为模型读完一段文字后留下的计算中间结果；下一轮前缀相同时，复用缓存就不必把整段历史重新计算一遍。过去三代系统分别补了不同缺口：

PagedAttention 论文在相同延迟条件下，相对 FasterTransformer 和 Orca 报告 2 至 4 倍吞吐。

• Mooncake 的 FAST 论文披露系统已经在数千节点运行，每日处理超过 1000 亿 token；
• Kimi 的 A800 和 H800 集群分别多处理 115% 和 107% 的请求。

• 前两代解决“怎样装下更多中间结果”和“怎样让另一台机器继续使用这些结果”；
• AgentX 则把多轮、暂停和分叉同时放进压力测试，迫使缓存命中、路由和状态正确性一起接受检验。

Kimi K3 又增加了状态类型。它把全注意力与 Kimi Delta Attention 交错使用，后者保存持续更新的循环状态。预填充和解码分开部署时，传统 KV 块、KDA 状态及其块表必须一致到达新实例。vLLM 因此加入混合缓存管理、细粒度前缀命中和状态复制。对这类模型，缓存不再只是性能优化；状态遗漏还可能使下一轮计算不完整。

610 条轨迹说明历史重算为什么会吞掉算力

vLLM 与 Mooncake 分析了 610 条 Codex / SWE-bench Pro 轨迹。

每条轨迹中位数为 33 轮；到第 30 轮时，上下文约 8 万 token，最长超过 18 万。输入与输出 token 约为 131:1，每轮平均只增加 2242 token。

这组比例把浪费的位置说得很清楚：任务后半段送入服务器的绝大多数文本，上一轮已经处理过。理想情况下，服务器只需读取缓存并计算新增的 2242 个 token；缓存没有命中时，它会重新计算前面约 8 万个 token。

Agent 等待工具执行时，原 GPU 会服务其他请求，下一轮也可能被路由到另一台机器。Mooncake Store 把节点主存、SSD 和网络组织成共享缓存池，让新实例找回会话历史。在 vLLM 5 月的固定实验中，缓存命中率从 1.7% 升至 92.2%。这说明高收益来自流量形状与状态复用的匹配，不是给任意请求打开一个缓存开关。

六倍是综合进展，3.8 倍是条件更完整的固定实验

六倍描述软件栈多项修改后的总体高并发结果，包括跳过传输中的重复前缀、只写新增缓存、异步查询与并行跨机器加载。

3.8 倍来自条件更完整且脚本公开的单组实验，更适合进入容量假设。两者测量的都是推理服务吞吐或延迟，没有直接执行和评价代码任务。

吞吐提高也可能伴随更差的单用户体验。系统可以接受更多并发请求，同时让尾延迟上升；如果超时和失败重试增加，表面容量不会转化为更多成功任务。因此，容量规划不能把六倍直接写成“任务速度提高六倍”。

vLLM、SGLang 与 TensorRT-LLM 要在同一轨迹上比较

三套推理引擎都提供前缀复用或 KV 缓存能力，但公开材料尚未在相同模型、硬件和 Agent 轨迹上形成统一排名：

这张表只能说明三套系统在解决同一类问题，不能推出谁的吞吐最高。真正的横向实验必须固定模型版本、硬件、并发、路由和轨迹，并同时记录命中率、状态流量、尾延迟与任务完成率。否则，一套系统可能因为接受更高并发而显得吞吐更高，用户看到的超时和失败却同时增加。

只有长历史、小增量、高复用流量适合套用这组结论

vLLM 官方文档明确指出，自动前缀缓存只减少预填充计算，不会加速新 token 的解码。

历史很长、每轮增量很小且前缀重复率高时，状态复用最有价值；回答很长、历史很短或各请求几乎没有共同前缀时，收益会快速收窄。

外部缓存还要消耗 CPU 查询、主存、SSD 和网络带宽。状态搬运成本高于重新计算时，增加缓存反而会拖慢服务。610 条轨迹的 131:1 输入输出比正好处于最有利区间，不能代表客服短问答、短文生成或低复用工作负载。

• 发布前还缺三类结果：固定配置下逐项拆分六倍提升；
• 企业真实流量中的前缀命中率、P95/P99 和外部缓存流量；
• 加入任务成功率与失败重试后的单位成功任务成本。

如果固定 A/B 后六倍大幅消失，或吞吐收益被尾延迟和失败率抵消，“历史状态主导 Agent 服务经济性”的适用范围就必须收紧。

• 现有证据支持的结论应保持具体：vLLM 在加载 Kimi 模型、处理长上下文和高前缀复用的多轮 Agent 流量时，能通过共享缓存和增量写入提高服务容量；
• 3.8 倍是条件完整的公开结果，六倍仍是需要固定配置复核的综合工程进展。

它说明服务器少做了大量重复计算，不说明 Kimi 模型或 Kimi Agent 更会写代码。