菜单
主题
vLLM Logo

使用 vLLM x Mooncake 大规模服务智能体（Agentic）工作负载

10 分钟阅读
Yifan Qiao, Trong Dao Le, Ao Shen, Zhewen Li, Bowen Wang
#agentic#kv_cache#large-scale-serving#disaggregation

简而言之：代理工作负载会产生大量共享前缀，这些前缀通常会在不同轮次间重复计算。通过将 Mooncake 的分布式 KV 缓存存储集成到 vLLM 中，我们在真实的代理追踪测试中实现了 3.8 倍的吞吐量提升、46 倍的 TTFT 降低 以及 8.6 倍的端到端延迟降低，并实现了近乎线性的规模扩展，支持多达 60 张 GB200 GPU。

代理（Agentic）工作负载正在重塑大模型服务

随着 Claude Code 和 OpenClaw 等 LLM 代理的兴起，推理工作负载正在经历根本性的转变。正如黄仁勋在 GTC 2026 主题演讲中所强调的，LLM 正在超越简单的聊天机器人，向能够规划、推理并朝着复杂目标采取行动的自主、长期运行系统演进。

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

为了量化这种行为，我们收集并分析了 SWE-bench Pro 数据集上 Codex 和 GPT-5.4 的追踪数据。我们已将该数据集开源，以鼓励社区对代理服务工作负载进行更广泛的研究。

图 1 总结了 Codex/SWE-bench Pro 的追踪数据，并展示了一个典型的代理会话。

Figure 1: Anatomy of an agentic trace from the Codex/SWE-bench Pro corpus. Each row is one LLM call; per-turn sizes use medians across 610 traces. The cached prefix (system prompt, skills/memory, prior turns' history) is reused turn after turn, while only the new tool output and the model's decode are active each turn.
图 1：Codex/SWE-bench Pro 语料库中代理追踪的解剖结构。每一行代表一次 LLM 调用；每轮的尺寸使用 610 个追踪数据的中位数。缓存的前缀（系统提示词、技能/记忆、过往轮次的历史记录）在每一轮中都被重复利用，而每一轮只有新的工具输出和模型的解码结果是活跃的。

其模式非常显著：到第 30 轮时，上下文长度增长到大约 8 万个 token，最长的上下文甚至可以超过 18 万个 token。然而，每一轮通常仅引入几百到几千个新的 token。其余部分是模型已经见过的“前缀”。在整个数据集中，平均输入到输出的 token 比例约为 131:1。

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

在 Codex/SWE-bench Pro 数据集中（包含 610 个追踪记录，平均每个追踪 33 轮），我们观察到：

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

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

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

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

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

Mooncake 是一个开源的高性能 KV 缓存传输和分布式存储库。vLLM 已经通过 MooncakeConnector 采用了 Mooncake 进行预填充-解码（PD）分离，利用其传输引擎在 GPU 之间移动 KV 缓存。现在，我们通过构建 Mooncake Store 分布式 KV 缓存池，将这一集成推向了新的高度。

图 2 描绘了整体设计。

Figure 2: Overall design of the vLLM distributed KV cache pool. Multiple vLLM instances embed Mooncake clients and share a cluster-wide Mooncake Store. The Mooncake master manages KV-block metadata, service discovery, and client health, while workers transfer KV blocks between GPU HBM and the distributed DRAM or SSD pool over RDMA.
图 2：vLLM 分布式 KV 缓存池的总体设计。多个 vLLM 实例嵌入 Mooncake 客户端并共享一个集群范围的 Mooncake Store。Mooncake 主节点负责管理 KV 块元数据、服务发现和客户端健康状况，而工作节点则通过 RDMA 在 GPU HBM 和分布式 DRAM 或 SSD 池之间传输 KV 块。

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

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

vLLM 的集成接入了现有的 KVConnector 接口，这与 PD 分离所使用的抽象层相同。该连接器具有两个角色：

在 调度侧，当新请求到达时，vLLM 对提示词的 token 块进行哈希处理，查询 Mooncake 主节点以获取匹配的 KV 缓存块，并利用查询结果指导调度决策。

在 工作侧，vLLM 在每个 GPU 工作节点中嵌入一个 Mooncake 客户端，并启动后台线程进行数据迁移。GPU KV 缓存内存被注册为 RDMA 缓冲区，从而实现通过 Mooncake 客户端进行 GPUDirect RDMA 读写，无需占用 SM 或通过 CPU 内存进行中转。

设计亮点

利用 GPUDirect RDMA 实现免 SM 占用和零拷贝的 KV 传输

传统上，GPU 到 CPU 的数据传输要么由 cudaMemcpyAsync 处理（它使用 GPU 拷贝引擎，但对于大量小额传输可能无法提供最佳吞吐量），要么通过启动专门的 GPU 内核（kernel）使用 SM 进行拷贝。基于内核的拷贝对于大量小型传输效果良好，但也可能干扰 GPU 上运行的其他内核。

我们采用了第三种方法：使用 RDMA 网卡和 GPUDirect RDMA 直接在 GPU HBM 和 CPU 内存之间移动 KV 块。此路径无需暂存缓冲区，不消耗 SM 资源，且对于大量小型 KV 块传输表现优异。

得益于 Mooncake 传输引擎，该路径还可以通过多网卡聚合（multi-NIC pooling）和拓扑感知的路径选择，利用节点上的多个 RDMA 网卡。这使得 KV 传输能够有效利用跨网卡的聚合带宽。

完全异步的传输机制

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

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

通过 MultiConnector 实现 PD（Prefill-Decode 分离）+ 分布式 KV 缓存池

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

Figure 3: PD disaggregation combined with the distributed KV cache pool via MultiConnector.
图 3：通过 MultiConnector 将 PD 分离与分布式 KV 缓存池相结合。

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

解码（Decode）：当解码实例将 KV 块写入分布式池时，它们会立即对预填充实例可见。目前解码实例本身不会读取池数据：由于 vLLM 将每个请求同时调度给一个预填充实例和一个解码实例，预填充实例会从池中加载所有前缀 KV 块，并通过 PD 连接器转发给解码实例。

我们正在努力支持从预填充实例和分布式池进行多路径 KV 缓存加载，这将最大限度地利用可用网络带宽。

性能

目前的实现可在 此处 获取。我们在工件仓库中提供了基准测试脚本 此处。在这篇文章中，我们重点展示两个结果。

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

加速真实代理工作负载追踪

我们首先使用前述 Codex 代理追踪数据，在真实场景下评估了 vLLM。在该实验中，我们部署了 1P1D（1 预填充 1 解码）架构，总共使用 12 张 GPU。

Figure 4: vLLM with Mooncake Store vs. baseline on realistic Codex agentic traces (1P1D, 12 GB200 GPUs). The distributed KV cache pool improves throughput by 3.8x, reduces P50 TTFT by 46x, and reduces E2E latency by 8.6x, driven by a cache hit rate increase from 1.7% to 92.2%.
图 4：在真实 Codex 代理追踪上，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 工作负载中导出的合成数据集进行受控扩展实验。

实验设置

  • 20K 公共 token（系统指令）
  • 10K token 初始输入
  • 每轮 2,048 个 token 的输入长度
  • 900 个输出 token
  • 总共 30 轮
  • 会话数量随 GPU 数量扩展：75 → 150 → 225 → 300 → 375
  • 参数选择旨在与原始 Codex 工作负载大致保持一致，并保持总输出/输入比约为 1.3%
Figure 5: Scaling throughput with Mooncake Store from 12 to 60 GB200 GPUs under round-robin routing. The system achieves >95% cache hit rate at all scales and scales nearly linearly.
图 5：在轮询（Round-Robin）路由下，使用 Mooncake Store 从 12 张扩展至 60 张 GB200 GPU 的吞吐量扩展情况。系统在所有规模下均实现 >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 提供的代理追踪数据与分析。

我们还要感谢来自 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 团队在整个工作中开展的密切协作与深入讨论。