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

TL;DR: Agentic workloads 会生成大量共享 prefix，而这些 prefix 往往会在多轮交互中被反复重新计算。通过将 Mooncake 的分布式 KV cache store 集成到 vLLM 中，我们在真实的 agentic traces 上实现了 3.8x 更高吞吐量、46x 更低 TTFT 和 8.6x 更低端到端延迟，同时几乎线性扩展到 60 GB200 GPUs。

Agentic workloads 正在重塑 LLM serving

随着 Claude Code 和 OpenClaw 等 LLM agents 的兴起，inference workloads 正在发生根本性变化。正如 Jensen 在 GTC 2026 keynote 中强调的那样，LLMs 正在从简单的 chatbots 走向能够围绕复杂目标进行规划、推理和行动的自主、长时间运行系统。

Agentic workloads 的独特之处在于其结构。它们通常由长周期、多轮循环组成，在 reasoning step 和 action step 之间交替：在 reasoning step 中，模型处理 context 并生成中间思考；在 action step 中，模型发出 tool calls 并接收外部输出。

为量化这种行为，我们收集并分析了 Codex 和 GPT-5.4 在 SWE-bench Pro 数据集上的 traces。我们也已将数据集开源在这里，以鼓励社区更广泛地研究 agentic serving workloads。

Figure 1 总结了 Codex/SWE-bench Pro traces，并展示了一个具有代表性的 agentic session。

Figure 1：Codex/SWE-bench Pro 语料库中一条 agentic trace 的结构。每一行是一次 LLM call；每轮大小使用 610 条 traces 的中位数。cached prefix（system prompt、skills/memory、prior turns' history）会在一轮又一轮中复用，而每轮只有新的 tool output 和模型的 decode 是活跃的。

这种模式非常明显：到第 30 轮时，context length 增长到大约 80K tokens，最长的 contexts 可以超过 180K tokens。然而，每一轮通常只引入几百到几千个新 tokens。其余部分都是模型已经见过的 prefix。在整个数据集中，平均 input-to-output token ratio 约为 131:1。

如果我们能够缓存这些 prefixes，那么 cached 部分的 prefill 基本上就没有成本。真正的每轮成本只有新的 delta。

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

• 94.2% cache hit rate
• 131:1 input-to-output ratio
• 每轮平均 context 增长约 2,242 tokens
• 每条 trace 的 context 中位数从 12K 增长到 80K tokens
• 轮间延迟从 5.2s 中位数到 81.4s P99 不等

然而，对于 agentic workloads，将本地 KV cache offload 到 CPU DRAM 或磁盘会遇到两个主要限制。

• 容量有限与 eviction。 一个 100K-token context 可能占用数 GB 存储（例如，Kimi-2.5 FP8 KV caches 约为 ~3.8 GB）。在一个繁忙实例上服务许多长时间运行的 sessions 时，这些大型 prefix caches 会很快耗尽本地容量并触发 eviction。
• 跨实例 misses。 为了均衡负载，router 可能并不总是将某个 session 的下一轮调度到同一个 vLLM instance。如果 session 被迁移到另一个 instance，该 instance 从未见过该 prefix，就必须从头重新计算。

结论：我们不能再把 inference service 视为一组彼此隔离的 vLLM replicas。对于 agentic workloads，instances 需要共享一个分布式 KV cache pool，以同时提供更大的总容量和跨实例 cache hits。

使用 Mooncake Store 构建分布式 KV cache pool

Mooncake 是一个开源、高性能的 KV cache 传输与分布式存储库。vLLM 已经通过 MooncakeConnector 采用 Mooncake 进行 prefill-decode（PD）disaggregation，使用 Mooncake 的 transfer engine 在 GPUs 之间移动 KV caches。现在，我们在此基础上进一步集成，使用 Mooncake Store 构建分布式 KV cache pool。

Figure 2 展示了整体设计。

Figure 2：vLLM 分布式 KV cache pool 的整体设计。多个 vLLM instances 嵌入 Mooncake clients，并共享一个集群级 Mooncake Store。Mooncake master 管理 KV-block metadata、service discovery 和 client health，而 workers 通过 RDMA 在 GPU HBM 与分布式 DRAM 或 SSD pool 之间传输 KV blocks。

从高层看，Mooncake Store 提供一个 master server 和一组 clients。master server 在集群范围内运行，并管理 metadata，包括 KV block hashes、sizes 等。它还监控 client health 和 availability，提供 service discovery 和 dead-node cleanup。

Mooncake clients 运行在 GPU nodes 上，负责管理本地 CPU/DRAM/SSD 资源。Clients 通过 RDMA 互相连接以传输 KV cache。它们共同组成一个分布式 KV cache pool。

vLLM 集成接入现有的 KVConnector interface，这是用于 PD disaggregation 的同一个抽象。该 connector 有两个角色：

在 scheduler side，当新 request 到达时，vLLM 会对 prompt 的 token blocks 进行 hash，向 Mooncake master 查询匹配的 KV cache blocks，并使用结果指导调度决策。

在 worker side，vLLM 在每个 GPU worker 中嵌入一个 Mooncake client，并启动后台线程进行数据移动。GPU KV cache memory 会被注册为 RDMA buffers，从而通过 Mooncake client 实现 GPUDirect RDMA reads 和 writes，不使用 SMs，也不通过 CPU memory 中转。

设计要点

使用 GPUDirect RDMA 实现 SM-free 和 zero-copy KV transfer

传统上，GPU 到 CPU 的数据传输通常由 cudaMemcpyAsync 处理，它使用 GPU copy engines，但在大量小传输场景下吞吐可能不理想；另一种方式是启动专用 GPU kernels，使用 SMs 复制数据。基于 kernel 的复制在大量小传输场景下效果可以不错，但也可能干扰 GPU 上运行的其他 kernels。

我们采用第三种方式：使用 RDMA NIC 和 GPUDirect RDMA，在 GPU HBM 与 CPU memory 之间直接移动 KV blocks。这条路径不需要 staging buffer，也不消耗 SMs。它在大量小 KV block transfers 场景下也表现良好。

得益于 Mooncake Transfer Engine，传输路径还可以通过 multi-NIC pooling 和 topology-aware path selection 利用节点上的多个 RNICs。这使 KV transfers 能够聚合并更充分地利用跨 NICs 的可用网络带宽。

完全异步传输

尽管 RDMA operations 是异步的，但准备 descriptors 并发起 RDMA reads 和 writes 仍需要不可忽视的 CPU 工作。随着 sequence length 增长，这一开销会增加，因为更长的 sequences 包含更多 KV blocks。

为避免阻塞主 CPU 路径，从而延迟 GPU kernel launches，所有 RDMA operations 都运行在专用的后台 I/O thread 上。从 vLLM 的角度看，这使传输路径成为完全异步的。

通过 MultiConnector 启用 PD + 分布式 KV cache pool

该集成也可以自然扩展到通过 MultiConnector interface 进行 PD disaggregation。如 Figure 3 所示，MultiConnector 是一个 wrapper，用于将多个 sub-connectors 串联起来。每个 connector 独立运行，不依赖其他 connector。

Figure 3：通过 MultiConnector 将 PD disaggregation 与分布式 KV cache pool 结合。

Prefill: prefill instance 为 PD connector 准备 KV blocks，同时也通过 store connector 将它们存入分布式 KV cache pool。对于 cache hits，vLLM 会查询所有 connectors，并可从 Mooncake Store connector 恢复匹配的 prefixes。

Decode: 当 decode instance 将 KV blocks 写入分布式 pool 时，它们会立即对 prefill instances 可见。Decode 本身目前不会从 pool 读取：因为 vLLM 会将每个 request 调度到一个 prefill instance 和一个 decode instance，prefill instance 会从 pool 加载任何 prefix KV blocks，并通过 PD connector 将它们转发给 decode。

我们正在推进从 prefill instance 和分布式 pool 同时进行多路径 KV cache loading，以最大化可用网络带宽。

性能

当前实现可在这里获取。我们还在 artifact repository 的这里提供了 benchmark scripts。在本文中，我们重点展示两个结果。

我们在带 PD disaggregation 的 GB200 nodes 上运行 Kimi-2.5 NVFP4 model。prefill instance 使用 TP4，decode instance 使用 DP8 + EP。我们发现该配置提供了最佳的 latency-throughput tradeoff。

加速真实 agentic traces

我们首先使用前文描述的 Codex agentic traces，在真实场景下评估 vLLM。在该实验中，我们使用 1P1D 部署模型，总计使用 12 GPUs。

Figure 4：在真实 Codex agentic traces 上比较使用 Mooncake Store 的 vLLM 与 baseline（1P1D，12 GB200 GPUs）。分布式 KV cache pool 将吞吐提升 3.8x，将 P50 TTFT 降低 46x，并将 E2E latency 降低 8.6x，其主要原因是 cache hit rate 从 1.7% 提升到 92.2%。

分布式 KV cache pool 将 vLLM 吞吐提升 3.8x，并分别将 P50 TTFT 和 E2E latency 降低 46x 和 8.6x。这些收益来自 cache hit rate 的显著提升：从只缓存 system prompt 时的 1.7%，提升到几乎整个 prefix 都被缓存时的 92.2%。

扩展到多节点

在可扩展性测试中，我们进一步增加节点数量，并使用从 Codex workload 派生的 synthetic dataset，以进行受控的 scaling experiments。

实验设置：

• 20K common tokens（system instructions）
• 10K tokens first input
• 每轮 input length 为 2,048 tokens
• 900 output tokens
• 总计 30 轮
• sessions 数量随 GPUs 数量扩展：75 → 150 → 225 → 300 → 375
• 参数选择大致对齐原始 Codex workload，并保持总 output/input ratio ~1.3%

Figure 5：在 round-robin routing 下，使用 Mooncake Store 将吞吐从 12 扩展到 60 GB200 GPUs。系统在所有规模下均实现 >95% cache hit rate，并几乎线性扩展。

为在跨节点流量下对 datapath 进行压力测试，我们使用 round-robin routing。因此，requests 可能在不同轮次被调度到不同节点，并且经常需要从前一个节点获取 KV caches。

如果没有分布式 KV cache pool，这种 routing pattern 会导致大量 cache misses 和严重吞吐下降。有了 Mooncake Store，vLLM 始终实现高于 95% 的 cache hit rate，并且系统几乎线性扩展到 60 GPUs。

这一结果表明，随着集群增长，分布式 KV cache pool 在显著提升 cache hit rate 的同时，也能保持高效的 datapath。

下一步？

我们正在积极推进以下功能和优化。

• Distributed disk offloading。 将存储层级从 CPU DRAM 扩展到 NVMe SSDs 和分布式文件系统，以支持更大的 cache capacity。
• 面向 hybrid models 的 KV cache offloading。 支持采用混合 attention mechanisms 的新兴 model architectures，这些架构可能需要在不同 layers 采用不同 caching strategies。
• Cache-aware routing。 将 request router 与 KV cache pool 协同设计，使各轮请求被导向已经持有相关 prefix 的 instances，在回退到分布式 pool 之前尽可能提升 local cache hits。
• 进一步优化 datapath。 除 RDMA 外，利用 NVIDIA multi-node NVLink 实现更快的多路径 KV cache transfer。我们也在探索类似 DualPath 的方案，从 prefill 和 decode instances 同时加载 KV，以最大化总带宽。

致谢

vLLM Mooncake Store 集成在很大程度上受到了 vLLM-Ascend 先前工作的启发。我们特别感谢 Ant Group 的 Chao Lei 完成初始实现，也感谢 Inferact 的 Zijing Liu 提供 agentic trace 和分析。

我们还感谢 Approaching.AI 的 Jiahao Lu、Zuoyuan Zhang、Zihan Tang 和 Ke Yang；Huawei 的 Pengbo Zhao、Fuqiao Duan 和 Tianyu Xu；Alibaba Cloud Computing 的 Tianchen Ding、Xuchun Shang、Xingrui Yi 和 Teng Ma；Ant Group 的 Yunxiao Ning、Dejiang Zhu 和 Shoujian Zheng；以及 9#AISoft 的 Feng Ren 提供了宝贵的技术反馈。

感谢更广泛的 vLLM 和 Mooncake 社区提供支持和建议。最后，特别感谢 Inferact 团队在整个工作过程中进行的密切协作与讨论。