基于 vLLM x Mooncake 大规模服务 Agentic 工作负载优化

基于 vLLM x Mooncake 大规模服务 Agentic 工作负载

原文：Serving Agentic Workloads at Scale with vLLM x Mooncake

作者：Yifan Qiao, Trong Dao Le, Ao Shen, Zhewen Li, Bowen Wang

发布日期：2026 年 5 月 6 日 · 约 10 分钟阅读

摘要（TL;DR）： Agentic 工作负载会产生大量共享前缀，这些前缀在多轮对话中往往被反复重算。通过将 Mooncake 的分布式 KV 缓存存储（KV cache store）集成到 vLLM 中，我们在真实 agentic 轨迹上实现了 3.8 倍的吞吐量提升、46 倍更低的 TTFT 以及 8.6 倍更低的端到端延迟，并且可扩展至 60 张 GB200 GPU，扩展性近乎线性。

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

随着 Claude Code、OpenClaw 等 LLM 智能体（agent）的兴起，推理工作负载正在经历一场根本性变革。正如 Jensen 在 GTC 2026 主题演讲 中所强调的，LLM 正从简单的聊天机器人向自主、长时间运行的系统演进——这些系统能够针对复杂目标进行规划、推理和行动。

Agentic 工作负载的独特之处在于其结构。它们通常由长时域、多轮交互的循环组成，在两种步骤之间交替：一是推理步骤（reasoning step），模型在此处理上下文并产生中间思考；二是动作步骤（action step），模型在此发出工具调用并接收外部输出。

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

图 1 展示了 Codex/SWE-bench Pro 轨迹的汇总，并呈现了一个典型的 agentic 会话示例。

图 1： 来自 Codex/SWE-bench Pro 语料库的 agentic 轨迹剖析。每一行代表一次 LLM 调用；每轮大小取 610 条轨迹的中位数。缓存前缀（系统提示词、技能/记忆、历史轮次的上下文）在逐轮之间被反复复用，而每轮真正活跃的内容仅有新的工具输出和模型的解码部分。

这一规律十分显著：到第 30 轮时，上下文长度增长到约 8 万 token，最长的上下文甚至可超过 18 万 token。然而每轮通常只引入几百到几千个新 token，其余部分都是模型已经处理过的前缀。在整个数据集中，平均输入输出 token 比约为 131:1。

如果我们能缓存这些前缀，缓存部分的预填充（prefill）开销基本为零，每轮的真实成本仅为新增的增量部分。

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

• 缓存命中率 94.2%
• 输入输出比 131:1
• 每轮上下文平均增长约 2,242 token
• 每条轨迹上下文中位数从 1.2 万 增长到 8 万 token
• 轮间延迟从 5.2 秒（中位数）到 81.4 秒（P99）

然而，将 KV 缓存本地卸载（offload）到 CPU DRAM 或磁盘的方式，在 agentic 工作负载下面临两大局限：

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

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

基于 Mooncake Store 的分布式 KV 缓存池

Mooncake 是一个开源的高性能 KV 缓存传输与分布式存储库。vLLM 此前已通过 MooncakeConnector 采用 Mooncake 实现预填充-解码（PD）分离，利用 Mooncake 的传输引擎在 GPU 之间迁移 KV 缓存。现在，我们进一步深化这一集成，基于 Mooncake Store 构建分布式 KV 缓存池。

图 2 展示了整体设计。

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

从高层架构来看，Mooncake Store 由一个 master 服务和一组客户端组成。master 在集群范围内运行，管理元数据（包括 KV 块哈希、大小等），同时监控客户端健康状态与可用性，提供服务发现和失效节点清理功能。

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

vLLM 的集成接入现有的 KVConnector 接口——这也是 PD 分离所使用的同一抽象层。该连接器承担两个角色：

在调度器侧，当新请求到达时，vLLM 对提示词的 token 块进行哈希，向 Mooncake master 查询匹配的 KV 缓存块，并据此指导调度决策。

在worker 侧，vLLM 在每个 GPU worker 中嵌入一个 Mooncake 客户端，并启动后台线程执行数据搬运。GPU KV 缓存内存被注册为 RDMA 缓冲区，使 Mooncake 客户端能够通过 GPUDirect RDMA 直接读写，无需使用 SM（流式多处理器），也无需经过 CPU 内存中转。

设计要点

基于 GPUDirect RDMA 的零拷贝 KV 传输，无需占用 SM

传统上，GPU 到 CPU 的数据传输有两种方式：一是 cudaMemcpyAsync，使用 GPU 拷贝引擎，但对于大量小批量传输而言吞吐量可能不理想；二是启动专用 GPU 内核，利用 SM 来拷贝数据。基于内核的拷贝在大量小批量传输场景下表现尚可，但会与 GPU 上运行的其他内核产生干扰。

我们采用了第三种方案：利用 RDMA 网卡和 GPUDirect RDMA，在 GPU HBM 与 CPU 内存之间直接迁移 KV 块。该路径无需中转缓冲区，也不消耗 SM，同时对大量小 KV 块传输也具备良好的性能表现。

得益于 Mooncake 传输引擎，该传输路径还可以通过多网卡（multi-NIC）聚合和拓扑感知的路径选择，利用节点上的多块 RNIC（RDMA 网卡），从而聚合并更好地利用各网卡的可用网络带宽。

全异步传输

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

为避免阻塞主 CPU 路径（进而延迟 GPU 内核启动），所有 RDMA 操作都在专用的后台 I/O 线程上执行。从 vLLM 的视角来看，整个传输路径完全异步。

基于 MultiConnector 同时实现 PD 分离与分布式 KV 缓存池

该集成还通过 MultiConnector 接口自然地扩展至 PD 分离场景。如图 3 所示，MultiConnector 是一个包装器，将多个子连接器串联在一起。每个连接器独立运行，互不依赖。

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

预填充（Prefill）： 预填充实例为 PD 连接器准备 KV 块，同时通过 store 连接器将其存入分布式 KV 缓存池。在缓存命中时，vLLM 查询所有连接器，可以从 Mooncake Store 连接器中恢复匹配的前缀。

解码（Decode）： 当解码实例将 KV 块写入分布式缓存池时，这些块立即对预填充实例可见。解码本身目前不从缓存池读取：因为 vLLM 将每个请求同时调度到预填充实例和解码实例，预填充实例从缓存池加载前缀 KV 块后，通过 PD 连接器转发给解码端。

我们正在推进支持从预填充实例和分布式缓存池进行多路径 KV 缓存加载，以最大化可用网络带宽利用率。

性能表现

当前实现可在此处查看，基准测试脚本见制品仓库。本文重点展示两组结果。

我们在 GB200 节点上以 PD 分离方式运行 Kimi-2.5 NVFP4 模型。预填充实例使用 TP4，解码实例使用 DP8 + EP。我们发现该配置在延迟与吞吐之间提供了最佳权衡。

加速真实 agentic 轨迹

我们首先使用前述 Codex agentic 轨迹，在真实场景下评估 vLLM。本实验采用 1P1D 部署，共计使用 12 张 GPU。

图 4： 在真实 Codex agentic 轨迹上，vLLM + Mooncake Store 与基线的对比（1P1D，12 张 GB200 GPU）。分布式 KV 缓存池使吞吐量提升 3.8 倍，P50 TTFT 降低 46 倍，端到端延迟降低 8.6 倍，缓存命中率从 1.7% 提升至 92.2%。

分布式 KV 缓存池将 vLLM 吞吐量提升了 3.8 倍，P50 TTFT 和端到端延迟分别降低了 46 倍 和 8.6 倍。这些收益源于缓存命中率的显著提升——从仅缓存系统提示词时的 1.7%，提升到几乎缓存全部前缀时的 92.2%。

多节点扩展

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

实验设置：

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

图 5： 在轮询路由（round-robin routing）下，从 12 到 60 张 GB200 GPU 的 Mooncake Store 扩展吞吐量。系统在所有规模下均实现 >95% 的缓存命中率，且扩展近乎线性。

为了对跨节点流量下的数据通路进行压力测试，我们采用了轮询路由。这意味着请求在不同轮次间可能被调度到不同节点，往往需要从前一个节点拉取 KV 缓存。

如果没有分布式 KV 缓存池，这种路由模式会导致大量缓存未命中和严重的吞吐下降。而借助 Mooncake Store，vLLM 始终保持 95% 以上的缓存命中率，系统扩展至 60 张 GPU 时仍近乎线性。

这一结果表明，分布式 KV 缓存池在显著提升缓存命中率的同时，随着集群规模增长仍能维持高效的数据通路。

下一步计划

我们正在积极推进以下功能与优化：

• 分布式磁盘卸载。 将存储层级从 CPU DRAM 扩展到 NVMe SSD 和分布式文件系统，以提供更大的缓存容量。
• 混合模型的 KV 缓存卸载。 支持采用混合注意力机制的新兴模型架构，这类模型可能在不同层需要不同的缓存策略。
• 缓存感知路由。 将请求路由器与 KV 缓存池协同设计，使各轮请求被定向到已持有相关前缀的实例，优先实现本地缓存命中，再回退到分布式缓存池。
• 进一步的数据通路优化。 在 RDMA 之外利用 NVIDIA 多节点 NVLink 实现更快速的多路径 KV 缓存传输。我们还在探索类似 DualPath 的方案，从预填充实例和解码实例同时加载 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 团队在本项工作中全程的密切协作与讨论。