vLLM：集成Mooncake分布式KV缓存存储，多轮智能体工作负载吞吐量提升3.8倍、P50首token时延降低46倍
vLLM集成了Mooncake分布式KV缓存存储，消除了智能体多轮对话中的前缀重复计算——在12块GB200 GPU上使用真实Codex轨迹测试，吞吐量提升3.8倍，P50首token时延（TTFT）降低46倍，端到端延迟降低8.6倍，缓存命中率从1.7%跃升至92.2%。
本文由人工智能基于一手来源生成。
vLLM团队宣布集成Mooncake——一个用于分布式KV缓存存储的开源库——以应对智能体工作负载的特定痛点：多轮长对话中，每个轮次仅新增数千个Token，却需要复用80K+个已缓存的前缀Token。在没有分布式缓存的情况下，繁忙实例很快耗尽本地内存，而当负载均衡器将下一个轮次路由到另一台机器时，系统将被迫进行完整的重新计算。
在Codex轨迹上的具体收益有多大？
使用SWE-bench Pro基准测试的真实Codex/GPT-5.4轨迹，在12块GB200 GPU上测试，集成后实现了吞吐量提升3.8倍、P50首token时延（TTFT）降低46倍、端到端延迟降低8.6倍。缓存命中率从1.7%跃升至92.2%，证实速度瓶颈主要来自对相同前缀的重复计算。
扩展至60块GPU时，缓存命中率保持在95%以上，使用轮询路由策略时吞吐量呈近线性扩展。KV缓存（键值缓存）是保存前序Token注意力向量的数据结构，无需重复计算；前缀共享是指在实例之间共享公共对话起始部分的缓存。
Mooncake如何在架构层面集成？
系统采用主从设计：主服务器负责管理元数据和健康监控，GPU节点上的客户端通过GPUDirect RDMA构成分布式缓存池，vLLM通过已有的KVConnector接口接入，该接口此前已用于预填充-解码分离。MultiConnector链允许请求从预填充实例或共享池中恢复前缀。
GPUDirect RDMA意味着数据直接在GPU HBM和CPU内存之间传输，无需经过GPU流处理器（SM）或CPU暂存缓冲区，从而避免对GPU计算核心产生干扰。异步后台线程在关键路径之外预先准备RDMA描述符。
这对生产级智能体系统意味着什么？
对610条Codex/GPT-5.4 SWE-bench Pro轨迹的分析显示：潜在缓存命中率94.2%，输入输出比131:1，每条轨迹中位轮次数33轮，P99轮间延迟为5.2秒至81.4秒。这表明智能体工作负载极度偏向于重用——而不具备缓存共享能力的系统在真实生产中将为此付出沉重代价。
实现方案以GitHub PR #40900的形式提供。后续计划包括NVMe SSD卸载、混合架构支持和缓存感知路由。贡献者来自Inferact、蚂蚁集团、Approaching.AI、华为和阿里云等团队。
常见问题
- 什么是KV缓存，为什么对智能体至关重要？
- KV缓存（键值缓存）保存已计算的前序Token的注意力向量，避免每次生成新Token时重复计算。对于拥有长多轮历史的智能体，这至关重要——若无缓存，每个轮次都需重新处理整个上下文。
- 分布式部署中的前缀共享意味着什么？
- 前缀共享是指在多个vLLM实例之间共享对话公共起始部分的KV缓存。若无此机制，当负载均衡器将下一个轮次路由到另一台机器时，必须重新计算所有内容。Mooncake允许整个vLLM集群通过RDMA共享缓存池。
- Mooncake如何实现如此大幅度的性能提升？
- GPUDirect RDMA在不经过内核干预的情况下直接在GPU HBM和CPU内存之间传输数据，异步后台线程预先准备RDMA描述符，MultiConnector链允许从预填充实例或共享池中恢复前缀。