当AI学会“长跑”：vLLM与Mooncake如何让智能体服务成本暴降

起因：智能体时代，推理服务正在“变天”

你可能已经注意到，像Claude Code、OpenClaw这样的AI智能体正变得越来越强大。它们不再是简单的一问一答聊天机器人，而是能够规划、推理、执行复杂任务的自主系统。这种转变对底层的推理服务提出了全新的挑战。传统的推理服务架构是为短对话设计的，但智能体的工作模式截然不同：它们进行长周期、多轮次的循环，交替进行“推理步骤”（处理上下文并产生中间思考）和“行动步骤”（发出工具调用并接收外部输出）。

vLLM团队分析了Codex和GPT-5.4在SWE-bench Pro数据集上的轨迹，发现了一个惊人的模式：到第30轮时，上下文长度增长到约8万token，最长甚至超过18万token。然而，每一轮通常只新增几百到几千个新token，其余绝大部分（平均94.2%）是模型已经“见过”的前缀（如系统提示、技能/记忆、历史对话）。输入与输出的token比例高达131:1。这意味着，如果能把这些前缀缓存起来，每轮推理的真正成本就只剩下处理那一点点新内容。问题在于，现有的本地缓存方案（如卸载到CPU内存或磁盘）在智能体工作负载面前捉襟见肘。

拆解：本地缓存的“天花板”与分布式“缓存池”的崛起

本地缓存面临两大致命限制。第一是容量与淘汰。一个10万token的上下文可能占用数GB存储（例如Kimi-2.5 FP8的KV缓存约占3.8GB）。当服务需要同时处理许多长会话时，这些庞大的前缀缓存会迅速耗尽本地容量，导致频繁的缓存淘汰，命中率暴跌。第二是跨实例失效。为了负载均衡，路由器可能不会将同一个会话的下一轮调度到同一个vLLM实例上。一旦会话被迁移到新实例，该实例从未见过此前缀，就必须从头重新计算，代价高昂。

核心洞察在于：我们不能再将推理服务视为一组孤立的vLLM副本。对于智能体工作负载，实例间需要共享一个分布式KV缓存池，它既能提供更大的聚合容量，又能实现跨实例的缓存命中。这正是vLLM与Mooncake Store集成的用武之地。Mooncake是一个开源的高性能KV缓存传输与分布式存储库。vLLM已通过MooncakeConnector将其用于预填充-解码（PD）分离架构。现在，它们更进一步，利用Mooncake Store构建了一个分布式KV缓存池。其架构包含一个管理元数据的Master服务器和一组运行在GPU节点上的客户端，客户端之间通过RDMA高速网络传输KV块，共同形成一个巨大的共享缓存资源池。

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

这件事揭示了一个更深层的趋势：AI推理服务正在从无状态的请求-响应模式，向有状态的、会话感知的服务范式演进。智能体需要记忆，而记忆就体现在不断增长的KV缓存中。管理这些“状态”（即KV缓存）的成本和效率，将成为决定智能体服务能否规模化、经济化运行的关键。Mooncake与vLLM的集成，本质上是在为AI智能体打造一个外部的、共享的“工作记忆”系统。这类似于人类在进行复杂项目时，不仅依赖大脑，还需要笔记本、白板等外部记忆辅助工具来保持连续性和效率。

实用价值：对开发者和架构师意味着什么？

对于正在构建或考虑部署AI智能体的开发者和架构师而言，这一进展提供了明确的指引。首先，在设计智能体系统时，必须将上下文长度和缓存效率作为核心优化指标，而不仅仅是关注单次推理的延迟。其次，在选择推理框架时，需要评估其是否具备跨实例的缓存共享能力。一个不具备此能力的框架，在智能体负载下可能面临严重的性能衰减和成本飙升。vLLM与Mooncake的方案展示了近乎线性的扩展能力（测试扩展到60个GPU），这意味着通过增加GPU节点，可以线性地提升智能体服务的总吞吐量，为应对用户增长提供了清晰的扩展路径。

反常识/意外：131:1的比例意味着什么？

一个可能被忽视的惊人数据是131:1的输入输出token比。这强烈暗示，在智能体工作负载中，计算资源主要消耗在“阅读”和“回忆”上，而非“生成”上。传统的推理优化往往聚焦于加速解码（生成token），但对于智能体，更关键的优化点在于如何高效地、低成本地“重读”历史上下文。这颠覆了我们对推理服务瓶颈的惯常认知，将优化重心从输出端转移到了输入端，特别是对长历史前缀的复用效率上。vLLM与Mooncake的解决方案，正是抓住了这个核心矛盾，通过分布式缓存将“重读”成本降至近乎为零，从而实现了数量级的性能提升。

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