vLLM x Mooncake 规模化服务 Agent 工作负载

TL;DR: Agentic 工作负载会产生大量共享前缀，这些前缀在多次轮次中经常被重新计算。通过将 Mooncake 的分布式 KV 缓存存储集成到 vLLM 中，我们在真实的 agentic 轨迹上实现了 3.8 倍更高的吞吐量、46 倍更低的 TTFT 和 8.6 倍更低的端到端延迟，同时几乎线性扩展到 60 块 GB200 GPU。

Agentic 工作负载正在重塑 LLM 服务

随着 Claude Code 和 OpenClaw 等 LLM agent 的兴起，推理工作负载正在经历根本性转变。正如 Jensen 在 GTC 2026 主题演讲中所强调的，LLM 正从简单的聊天机器人转向自主的、长时间运行的系统，这些系统能够规划、推理并采取行动以实现复杂目标。

Agentic 工作负载的独特之处在于其结构。它们通常由长周期、多轮次的循环组成，在 推理步骤（模型处理上下文并产生中间思考）和 行动步骤（模型发出工具调用并接收外部输出）之间交替。

为了量化这种行为，我们收集并分析了 Codex 和 GPT-5.4 在 SWE-bench Pro 数据集上的轨迹。我们还在此处开源了该数据集，以鼓励更广泛的社区研究 agentic 服务工作负载。

图 1 总结了 Codex/SWE-bench Pro 轨迹，并展示了一个代表性的 agentic 会话。

图 1：来自 Codex/SWE-bench Pro 语料库的 agentic 轨迹剖析。每一行是一次 LLM 调用；每轮大小使用 610 条轨迹的中位数。缓存的前缀（系统提示、技能/记忆、先前轮次的历史）被一轮又一轮地重用，而只有新的工具输出和模型的解码在每一轮中是活跃的。

这种模式非常显著：到第 30 轮时，上下文长度增长到大约 80K token，最长的上下文可以增长到 180K token 以上。然而，每一轮通常只引入几百到几千个新 token。其余部分是模型已经见过的前缀。在整个数据集中，平均输入输出 token 比率大约为 131:1。

如果我们能够缓存这些前缀，那么缓存部分的 prefill 基本上就免费了。真正的每轮成本只是新的增量部分。

在包含 610 条轨迹（每条轨迹中位数有 33 轮）的 Codex/SWE-bench Pro 数据集中，我们观察到：

• 94.2% 的缓存命中率
• 131:1 的输入输出比率
• 每轮平均上下文增长约 2,242 个 token
• 每条轨迹上下文增长中位数从 12K 到 80K token
• 轮间延迟中位数为 5.2 秒，P99 为 81.4 秒

然而，对于 agentic 工作负载，将本地 KV 缓存卸载到 CPU DRAM 或磁盘会遇到两个主要限制。

• 容量有限和驱逐。 一个 100K token 的上下文可能占用数 GB 的存储空间（例如，Kimi-2.5 FP8 KV 缓存约 3.8 GB）。在服务于许多长时间运行会话的繁忙实例上，这些大型前缀缓存会迅速饱和本地容量并触发驱逐。
• 跨实例未命中。 为了平衡负载，路由器可能不会总是将会话的下一轮调度到同一个 vLLM 实例上。如果会话被迁移到另一个实例，该实例从未见过该前缀，必须从头开始重新计算。

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

使用 Mooncake Store 的分布式 KV 缓存池

是一个用于 KV 缓存传输和分布式存储的开源高性能库。vLLM 已经通过 MooncakeConnector 采用了 Mooncake 进行 prefill-decode (PD) 分离，使用 Mooncake 的传输引擎在 GPU 之间移动 KV 缓存。现在，我们通过使用 Mooncake Store 构建分布式 KV 缓存池，将这一集成向前推进了一步。

图 2 描绘了整体设计。

图 2：vLLM 分布式 KV 缓存池的整体设计。多个 vLLM 实例嵌入 Mooncake 客户端并共享一个集群范围的 Mooncake Store。Mooncake master 管理 KV 块元数据、服务发现和客户端健康，而 workers 通过 RDMA 在 GPU HBM 和分布式 DRAM 或 SSD 池之间传输 KV 块。

在高层次上，Mooncake Store 提供一个 master 服务器和一组客户端。master 服务器在集群范围内运行，管理元数据，包括 KV 块哈希、大小等。它还监控客户端的健康和可用性，提供服务发现和死节点清理。

Mooncake 客户端运行在 GPU 节点上，管理本地 CPU/DRAM/SSD 资源。客户端通过 RDMA 相互连接以进行 KV 缓存传输。它们共同形成一个分布式 KV 缓存池。

vLLM 集成插入到现有的 KVConnector 接口中，该接口与用于 PD 分离的抽象相同。该连接器有两个角色：

在 调度器端，当新请求到达时，vLLM 对 prompt 的 token 块进行哈希处理，向 Mooncake master 查询匹配的 KV 缓存块，并使用结果来指导调度决策。

在 worker 端，vLLM 在每个 GPU worker 中嵌入一个 Mooncake 客户端，并启动后台线程进行数据移动。GPU KV 缓存内存被注册为 RDMA 缓冲区，从而能够通过 Mooncake 客户端进行 GPUDirect RDMA 读写，而无需使用 SM 或通过 CPU 内存暂存。

设计亮点

使用 GPUDirect RDMA 实现无 SM 和零拷贝的 KV 传输

传统上，GPU 到 CPU 的数据传输要么由 cudaMemcpyAsync 处理（它使用 GPU 拷贝引擎，但对于许多小传输可能提供次优的吞吐量），要么通过启动专用的 GPU kernel 来使用 SM 拷贝数据。基于 kernel 的拷贝对于大量小传输可能效果很好，但它也可能干扰 GPU 上运行的其他 kernel。

我们采用第三种方法：使用 RDMA NIC 和 GPUDirect RDMA 直接在 GPU HBM 和 CPU 内存之间移动 KV 块。此路径不需要暂存缓冲区，也不消耗 SM。对于大量小 KV 块传输，它也表现良好。

得益于 Mooncake 传输引擎，传输路径还可以通过多 NIC 池化和拓扑感知路径选择，利用节点上的多个 RNIC。这使得 KV 传输能够聚合并更好地利用跨 NIC 的可用网络带宽。

完全异步传输

尽管 RDMA 操作是异步的，但准备描述符和发起 RDMA 读写仍然需要大量的 CPU 工作。这种开销随着序列长度而增长，因为更长的序列包含更多的 KV 块。

为了避免阻塞主 CPU 路径（这可能会延迟 GPU kernel 启动），所有 RDMA 操作都在专用的后台 I/O 线程上运行。从 vLLM 的角度来看，这使得传输路径完全异步。

使用 MultiConnector 实现 PD + 分布式 KV 缓存池

该集成还通过 MultiConnector 接口自然地扩展到 PD 分离。如图 3 所示，MultiConnector 是一个包装器，它将多个子连接器链接在一起。每个连接器独立运行，不依赖于其他连接器。

图 3：通过 MultiConnector 将 PD 分离与分布式 KV 缓存池相结合。

Prefill： Prefill 实例为 PD 连接器准备 KV 块，并通过存储连接器将它们存储在分布式 KV 缓存池中。对于缓存命中，vLLM 查询所有连接器，并可以从 Mooncake Store 连接器恢复匹配的前缀。

Decode： 当 decode 实例将 KV 块写入分布式池时，它们立即对 prefill 实例可见。Decode 本身目前不从池中读取：因为 vLLM 将每个请求调度到 prefill 和 decode 实例，prefill 实例从池中加载任何前缀 KV 块，并通过 PD 连接器将它们转发给 decode。

我们正在努力实现从 prefill 实例和分布式池同时进行多路径 KV 缓存加载，这将最大化可用的网络带宽。

性能

当前实现可在此处获取。我们还在制品仓库中提供了基准测试脚本此处。在这篇文章中，我们重点介绍两个结果。

我们在配备 PD 分离的 GB200 节点上运行了 Kimi-2.5 NVFP4 模型。Prefill 实例使用 TP4，而 decode 实例使用 DP8 + EP。我们发现这种配置提供了最佳的延迟-吞吐量权衡。

加速真实的 agentic 轨迹

我们首先使用前面描述的 Codex agentic 轨迹，在真实环境中评估了 vLLM。在此实验中，我们使用 1P1D 部署了模型，总共使用 12 块 GPU。

图 4：在真实的 Codex agentic 轨迹上，带 Mooncake Store 的 vLLM 与基线对比（1P1D，12 块 GB200 GPU）。分布式 KV 缓存池将 vLLM 吞吐量提升了 3.8 倍，并将 P50 TTFT 和端到端延迟分别降低了 46 倍 和 8.6 倍。这些收益源于缓存命中率的显著提升：从仅缓存系统提示的 1.7% 提高到几乎缓存整个前缀的 92.2%。

扩展到多个节点

对于可扩展性测试，我们进一步增加了节点数量，并使用源自 Codex 工作负载的合成数据集进行受控的扩展实验。

实验设置：

• 20K 公共 token（系统指令）
• 10K token 首次输入
• 每轮输入长度 2,048 token
• 900 个输出 token
• 总共 30 轮
• 会话数量随 GPU 数量扩展：75 → 150 → 225 → 300 → 375
• 参数选择大致与原始 Codex 工作负载对齐，并保持总输出/输入比率约为 1.3%

图 5：在轮询路由下，使用 Mooncake Store 从 12 块扩展到 60 块 GB200 GPU 的吞吐量。系统在所有规模下均实现 >95% 的缓存命中率，并且几乎线性扩展。

为了在跨节点流量下对数据路径进行压力测试，我们使用了轮询路由。因此，请求可能会在不同轮次被调度到不同节点，并且通常需要从先前节点获取 KV 缓存。

如果没有分布式 KV 缓存池，这种路由模式将导致大量缓存未命中和严重的吞吐量下降。借助 Mooncake Store，vLLM 始终实现 95% 以上的缓存命中率，并且系统几乎线性扩展到 60 块 GPU。

这个结果表明，分布式 KV 缓存池在保持高效数据路径的同时，随着集群规模的增长，显著提高了缓存命中率。

下一步计划？

我们正在积极开发以下功能和优化。

• 分布式磁盘卸载。 将存储层次结构从 CPU DRAM 扩展到 NVMe SSD 和分布式文件系统，从而实现更大的缓存容量。
• 混合模型的 KV 缓存卸载。 支持具有混合 attention 机制的新兴模型架构，这些架构可能在不同层需要不同的缓存策略。
• 缓存感知路由。 将请求路由器与 KV 缓存池协同设计，以便将轮次引导到已持有相关前缀的实例，在回退到分布式池之前最大化本地缓存命中。
• 进一步的数据路径优化。 除了 RDMA 之外，利用 NVIDIA 多节点 NVLink 实现更快、多路径的 KV 缓存传输。我们还在探索类似 DualPath 的方式，从 prefill 和 decode 实例同时加载 KV，以最大化聚合带宽。

致谢

vLLM Mooncake Store 的集成很大程度上受到了 vLLM-Ascend 先前工作的启发。我们特别感谢蚂蚁集团的 Chao Lei 提供的初始实现，以及 Inferact 的 Zijing Liu 提供的 agentic 轨迹和分析。

我们还感谢 Approaching.AI 的 Jiahao Lu、Zuoyuan Zhang、Zihan Tang 和 Ke Yang；华为的 Pengbo Zhao、Fuqiao Duan 和 Tianyu Xu；阿里云计算的 Tianchen Ding、Xuchun Shang、Xingrui Yi 和 Teng Ma；蚂蚁集团的 Yunxiao Ning、Dejiang Zhu 和 Shoujian Zheng；以及 9#AISoft 的 Feng Ren 提供的宝贵技术反馈。

我们感谢更广泛的 vLLM 和 Mooncake 社区的支持和建议。最后，特别感谢 Inferact 团队在整个工作中的密切合作和讨论。