vLLM联手Mooncake：如何让AI Agent的推理成本暴降？

起因：为什么现在必须谈Agent推理的效率？

随着Claude Code、OpenClaw等LLM Agent的兴起，推理工作负载正在发生根本性变化。这些Agent不再是简单的聊天机器人，而是能规划、推理并执行复杂任务的自主系统。黄仁勋在GTC 2026的主题演讲中也强调了这一趋势。然而，这种转变带来了新的工程挑战：Agent工作负载的结构特殊，通常由长周期、多轮循环组成，交替进行“推理步骤”（处理上下文并产生中间思考）和“行动步骤”（发出工具调用并接收外部输出）。

vLLM团队对Codex和GPT-5.4在SWE-bench Pro数据集上的轨迹分析揭示了一个惊人的模式：到第30轮时，上下文长度可增长到约80K token，最长甚至超过180K token。但每轮通常只新增几百到几千个token，其余都是模型已经“见过”的前缀。数据集的平均输入输出token比高达131:1，缓存命中率94.2%。这意味着，如果能有效缓存这些前缀，预填充成本将趋近于零，每轮的真实成本仅限于新增的增量部分。

拆解：本地缓存为何失效？分布式缓存池如何破局？

问题在于，传统的本地KV缓存卸载（到CPU内存或磁盘）在Agent场景下遇到两大瓶颈：

1. 容量有限与驱逐问题：一个100K token的上下文可能占用数GB存储（例如Kimi-2.5 FP8 KV缓存约3.8GB）。在繁忙的实例上服务大量长会话时，这些巨大的前缀缓存会迅速耗尽本地容量并触发缓存驱逐，导致缓存失效。
2. 跨实例缓存未命中：为了负载均衡，路由器可能不会将会话的下一轮调度到同一个vLLM实例。如果会话迁移到新实例，该实例从未见过此前缀，必须从头重新计算，造成巨大的计算浪费。

因此，核心洞见是：对于Agent工作负载，我们不能再将推理服务视为一组孤立的vLLM副本。实例需要共享一个分布式KV缓存池，它既能提供更大的聚合容量，又能实现跨实例的缓存命中。

vLLM的解决方案是与Mooncake深度集成。Mooncake是一个用于KV缓存传输和分布式存储的开源高性能库。vLLM此前已通过MooncakeConnector采用Mooncake进行预填充-解码（PD）分离。现在，它们更进一步，利用Mooncake Store构建了一个分布式KV缓存池。多个vLLM实例嵌入Mooncake客户端，共享一个集群范围的Mooncake Store，由Mooncake主节点管理全局元数据。这使得任何实例产生的KV缓存块都可以被其他实例快速访问，从根本上解决了容量和共享问题。

趋势洞察：从“无状态推理”到“有状态服务”的范式转变

这项工作揭示了一个更深层的趋势：AI推理基础设施正在从处理无状态、独立的请求，转向管理有状态、长生命周期的会话。Agent的“记忆”——即其不断增长的上下文——成为了服务的核心资产和主要成本中心。这要求底层系统必须具备状态管理、共享和高效迁移的能力。

类似于微服务架构从无状态容器发展到需要管理持久化状态和缓存（如Redis集群），LLM推理服务也正在经历类似的演进。分布式KV缓存池就是这个时代的“推理Redis”，它抽象了底层GPU实例的异构性，为上层的Agent应用提供了一个统一、高速、大容量的“记忆体”。

实用价值与反常识点

对于开发者和架构师而言，这意味着在设计和评估LLM推理服务时，必须将“缓存命中率”和“跨实例缓存共享能力”提升到与吞吐量、延迟同等重要的位置。选择推理框架时，不能只看单机性能，更要考察其分布式状态管理能力。vLLM与Mooncake的这次合作，为行业树立了一个标杆：未来的推理引擎必须是“缓存感知”和“集群感知”的。

一个反常识的点是，尽管Agent的上下文可能长达数十万token，但每轮的实际计算增量极小。性能瓶颈不在于解码生成新token的速度，而在于如何避免为庞大的历史前缀反复进行预填充。这项工作通过将瓶颈从“计算”转移到“存储与传输”，实现了数量级的性能提升。这提示我们，在AI系统优化中，识别并重构瓶颈所在的层次，比单纯优化计算核更为关键。

---

原文地址: Serving Agentic Workloads at Scale with vLLM x Mooncake