阿里云社区介绍了 Mooncake，一种以 KVCache 为中心的分离式 LLM 推理基础设施，旨在通过分层缓存和跨节点复用减少多智能体工作流中的重复预填充计算并降低首 token 延迟和显存瓶颈。文章评估了 Mooncake 的架构、与 SGLang 等生态的集成及测试数据，同时指出缓存一致性、网络带宽和安全隔离等工程挑战与场景限定。
当大型语言模型从一次问答转向多智能体协作，系统需要管理的已经不只是模型参数和 GPU 算力，还包括在多个回合、多个代理和多次工具调用之间反复出现的上下文。阿里云社区 9 月 30 日发表的一篇技术文章，将这一问题指向了 Mooncake：一个以 KVCache 为中心、面向大语言模型推理的分离式基础设施。
文章的重点不是发布新模型，而是讨论如何把已经计算过的上下文保存下来、跨实例传输并重新利用。对于需要长时间运行的智能体系统而言，这可能成为影响首 token 延迟、显存利用率和整体吞吐量的底层因素。
多智能体工作流为何放大 KVCache 问题
在典型的多智能体工作流中，每次模型调用都可能携带系统提示词、工具定义、多轮对话历史，以及上游代理传给下游代理的中间状态。当多个代理持续协作时，这些内容会不断累积。阿里云文章以一个包含 10 个代理、20 轮交互的工作流为例，指出其工作记忆可能达到数百万 token。
传统推理引擎通常把每次调用视为独立请求。即使新请求包含此前已经处理过的上下文，系统仍可能重复进行预填充计算。这会增加显存碎片和首 token 延迟，也会让缓存容量有限的 GPU 更快成为瓶颈。
阿里云社区援引技术分享材料称，在特定测试场景中，没有 KVCache 持久化时，首 token 延迟最高可能恶化 136 倍；当 MCP 工具动态加载、导致请求前缀发生变化时，缓存命中率也可能从 85% 降至 0%。这些数字来自文章所述的技术分享和实践材料，并非适用于所有模型或生产部署的普遍结论。
这类问题与此前围绕长上下文推理出现的调度优化有关。比如，Amazon SageMaker 的前缀感知路由尝试把拥有相同提示词前缀的请求持续送往同一实例，以提高 KV 缓存复用率；其收益同样取决于前缀长度、请求分布和部署配置。对于多智能体系统而言，Mooncake讨论的是更底层的存储、传输和跨节点共享问题。
Mooncake把缓存从显存扩展到分层存储
Mooncake采用分离式架构，主要组件包括 Transfer Engine、KVCache Store 和 Elastic EP。Transfer Engine负责在不同设备和节点之间传输数据；KVCache Store负责缓存对象的分布式存储与管理；Elastic EP则服务于弹性专家并行等推理场景。
其核心思路是把分散在不同层级的资源组织成可供推理系统使用的缓存池。除了 GPU 显存，也可以利用 DRAM、SSD 以及远程存储，将 KVCache 从单一推理实例中分离出来。这样做的目的，是让缓存不再随着某个实例重启、扩缩容或调度变化而立即失效。
Mooncake官方项目资料将其描述为以 KVCache 为中心的分离式 LLM 服务架构，并称该系统已经用于 Moonshot AI 的 Kimi 服务。项目同时开放了 Transfer Engine、Mooncake Store、技术报告和部分测试数据。2025 年发表在 USENIX FAST 的论文则把这一方法概括为“用更多存储换取更少计算”，即通过扩大缓存容量和提高跨节点复用率，减少重复的预填充计算。
在工程实现上，Mooncake Store可提供多级缓存，配合 RDMA、NVMe-oF 等数据传输方式，把缓存对象在显存、主机内存、固态硬盘和远程节点之间移动。与只依赖单机前缀缓存相比，这种设计更适合需要跨会话、跨实例共享上下文的场景，但它也会引入缓存一致性、网络带宽、数据隔离和故障恢复等新的系统问题。
与 SGLang 集成后的性能数据仍需限定场景
阿里云文章介绍称，在与 SGLang 集成并引入 L3 GPU 缓存后，输入 token 吞吐量从每秒 6,576 个提升至每秒 15,022 个，请求吞吐量则从每秒 0.61 个提升至每秒 1.39 个。文章将其描述为实测结果，两个指标均超过两倍增长。
但这些数据属于文章披露的特定测试环境。公开内容没有提供足够信息证明该结果可以代表不同模型、硬件、并发规模和请求分布下的表现，也尚未看到独立第三方复测。因此，更稳妥的理解是：L3 缓存和跨节点 KV 复用在重复上下文较多的工作负载中显示出明显潜力，而不是任何 SGLang 部署都能自动获得相同增益。
Mooncake项目的公开资料还显示，它已经与 SGLang、vLLM、TensorRT-LLM、LMCache 和 LMDeploy 等推理生态发生集成。SGLang的分层 KV 缓存文档也把 Mooncake Store作为远程缓存后端，用来在设备、主机和远程存储层之间管理缓存。不过，能否在生产环境中获得收益，仍取决于工作流是否存在稳定的共享前缀、系统是否有足够网络带宽，以及缓存策略能否避免热点和失效。
缓存命中率不是唯一目标
对于多智能体应用，缓存并不是简单地“保存越多越好”。工具定义、权限、系统指令和任务状态可能随时间变化。如果开发者为了保持高命中率而长期复用旧的工具描述或权限信息，系统可能执行不再适用的操作。因此，缓存版本管理、租户隔离、权限边界和失效机制与传输速度同样重要。
这一点也出现在其他提示词缓存实践中。AIFlux此前报道，OpenAI把长时间运行的智能体缓存进一步纳入监控、未命中诊断和显式缓存断点等工程工具。两者虽然处于不同技术栈：前者更接近模型服务接口，后者更接近分布式推理基础设施，但共同指向一个变化——智能体的性能优化正在从单次请求，转向整个工作流中重复计算的管理。
这也解释了为什么 Mooncake 的价值不只是提高某一次请求的速度。阿里云文章强调，其目标还包括减少偶发的长尾延迟，让多智能体服务在高并发和复杂工作流下表现得更加稳定。对于企业服务而言，稳定的 P95 或 P99 延迟有时比少数请求的最佳速度更重要。
从模型竞争走向推理基础设施竞争
Mooncake所处的技术方向，反映了大模型应用进入生产阶段后的一项变化：模型能力仍然决定系统能做什么，但推理基础设施决定这些能力能否以可接受的成本和延迟持续运行。
在上层，A2A、MCP 等协议让代理能够调用工具并彼此协作；在中间层，工作流感知的调度、前缀索引和缓存复用策略试图决定哪些上下文应该保留；在底层，Mooncake等系统则负责把 KV 数据在不同计算节点和存储层之间移动。只有这几层配合起来，多智能体系统才可能把“计算一次、全局复用”从概念变成稳定的工程能力。
不过，Mooncake目前披露的许多性能数字仍来自项目方、技术分享或特定测试。未来更值得关注的，不只是缓存命中率和吞吐量的峰值，还包括不同模型和工作流之间的可复现性、远程缓存的运营成本、数据隔离方式，以及当工具定义和任务状态频繁变化时，系统能否在缓存效率与安全边界之间取得平衡。
来源：
- 阿里云社区：When AI Transitions from Conversation to Collaboration, Who Will Manage the Working Memory of Millions of Tokens?
- Mooncake GitHub 官方仓库
- Mooncake 官方文档
- USENIX FAST 2025：Mooncake技术论文
- LMCache：Mooncake集成文档
AIFlux此前相关报道：