日均产出万亿Token！Mooncake落地生产，KV Cache命中率稳定突破90% (2026)

转载说明：本文转载自微信公众号「量子位」官方报道（biz_id：MzIzNjc1NzUzMw），原载于 2026 年 9 月 11 日，署名“趋境科技、KVCache.AI 投稿量子位 | 公众号 QbitAI”。原文链接：[量子位微信公众号原文](http://mp.weixin.qq.com/s?__biz=MzIzNjc1NzUzMw&mid=2247921612&idx=3&sn=093fb9795201626263820bf95a370eac)。

随着智能体从“一问一答”走向持续规划、工具调用和多轮执行，Token 需求正在从零散调用转变为持续、规模化的生产需求。

以某头部万亿参数模型的生产实践为例，趋境科技日均高品质 AI Token 产量已稳定突破一万亿；自 2026 年春节以来，平均单台算力的 Token 生产效率提升超过 3 倍，总产能增长超过 30 倍 1。

支撑这一规模化生产的背后，是对推理引擎、调度、缓存和基础设施的一系列系统级优化，而 Mooncake 正是其中关键的一环。

Token 工厂的核心矛盾：在严守 SLO 下追求吞吐极限

Token 工厂的成本相对刚性：硬件采购与租赁、电力、机房和网络等投入基本固定；而收益则取决于“Token 产量 × Token 单价”。其中，Token 单价又与服务质量直接相关，TTFT（首字时延）、TPOT（每字生成时延）、稳定性等指标决定了这些 Token 是否能够被高质量地交付。

因此，研发团队的目标非常明确：在严格满足 SLO 的前提下，尽可能提高系统吞吐和单位算力的 Token 产出。任何性能优化都不能以牺牲 SLO 为代价 1。

Agentic Workload 的快速增长进一步放大了这一矛盾。代码智能体（Coding Agent）、多轮推理和工具调用会反复复用长上下文。KV Cache 命中时能够显著减少 Prefill 计算；而一次 Cache Miss，却可能意味着数十万 Token 的重新计算，既浪费算力，也会显著拖慢请求响应，甚至阻塞其他请求的正常处理。

在万亿级 Token 的线上推理系统中，哪怕几个百分点的算力浪费，都会被放大成巨大的基础设施成本。KV Cache 已经不再只是可选的局部优化，而成为影响整体产能和成本的关键基础设施。

从单机缓存到集群级 KV Cache 池化

在智能体和长上下文场景下，如果只依赖 GPU HBM，KV Cache 的复用天然存在两难：缓存空间分得少，命中率下降，大量历史上下文需要重复计算；缓存空间分得多，又会挤占请求处理所需的显存，降低新 Token 的计算效率。

为此，研发团队首先在生产环境中引入了 SGLang HiCache，将容量更大的主机内存（Host DRAM）纳入缓存层级，在不显著影响计算效率的情况下扩大了缓存容量。

但当系统规模扩大到日均万亿 Token 后，单机缓存的边界很快显现：

一是单节点 DRAM 容量终究有限，分散在不同节点上的重复缓存无法共享；二是同一节点的多个 TP Rank 会分别保存缓存，导致最高 8 倍的数据冗余。

更重要的是，单机缓存将 KV Cache 的位置和请求的执行位置强行绑定在了一起。

当某段缓存只存在于特定 Prefill 节点时，为了复用缓存，调度器只能将请求继续打到这些节点。这种缓存与调度的耦合压缩了调度算法的设计空间：如果为了命中率持续路由到少数节点，容易产生热点堆积而违反 TTFT SLO；如果为了负载均衡而迁移请求，又会因为跨节点无法复用而触发大规模重新计算。

为了彻底解耦缓存位置与调度选择，团队进一步引入 Mooncake Store，将原本分散在各个节点上的 DRAM 内存池化为集群级共享资源 1。

SGLang+Mooncake 的生产级架构实践

当 KV Cache 变成集群级共享资源后，系统需要与计算、网络和调度进行协同设计。

一个 PD Group 内的 HiCache 与 Mooncake Store 架构 — 趋境线上单分组内的 SGLang 与 Mooncake 部署拓扑：客户端请求经网关由 Router 进行缓存感知路由，Prefill 节点开启 HiCache，Decode 节点专用于生成，底层依托 3 副本 etcd、3 副本 Master 与各节点独立 Store Service 构成分布式缓存池。1

在趋境的线上系统中，服务划分为多个分组，每个分组包含多个 GPU 节点并通过 RDMA 承担高速传输。

Prefill-Decode 分离与内存池化

分组内部采用 Prefill-Decode（PD）分离部署，仅在 Prefill 节点开启 HiCache。长上下文的主要计算开销集中在 Prefill 阶段，缓存命中可免去首 Token 生成前的大量重复前缀计算；Decode 阶段则优先保持链路简单稳定。

Mooncake Store 以独立服务形式部署在所有节点上：Decode 节点的主机内存主要划给 Store；Prefill 节点则由 HiCache 和 Store 共同使用。

考虑到单机 NUMA 拓扑，研发团队在每个 NUMA Node 上分别绑定一个 Store Service，尽量让数据本地访问和网络传输保持 NUMA 亲和性，降低跨 NUMA 开销。控制面上，Mooncake Master 配置为三副本（一主两从），部署在 GPU 节点；依赖的 etcd 同样采用三副本，部署在独立 CPU 节点上。

基于 SMG 与 RBG 的调度与编排

分组内请求调度基于改进版 SMG（SGLang Model Gateway） 实现。在 Prefill 侧，调度器综合本地命中率、节点实时负载与请求特征决策，兼顾局部性与负载均衡；在 Decode 侧，调度器尽量将生成负载均匀分摊到多个实例。

在集群管理层面，线上采用 RBG（RoleBasedGroup） 在 Kubernetes 中统一管理工作负载，提供面向不同应用角色的协同策略，使 Prefill、Decode 和 Store 能够作为一个整体进行调度维护。

落地万亿级 Token 工厂的四项工程攻坚

将 Mooncake 真正推向万亿级生产环境，核心挑战在于缓存基础设施必须足够快、足够稳定，不能在关键路径上引入额外开销与系统风险。经过工程调优，线上 KV Cache 命中率稳定在 90% 以上 1。

1. 快速数据取回：将网络传输隐藏在计算之后

HiCache 在请求进入调度队列后尽早异步发起远端 KV Cache 预取，使网络传输与 GPU 正在执行的计算相互重叠。只要远端数据在 GPU 开始处理当前请求前准备完成，远端存储的开销就几乎无感。

Mooncake 的批量读取链路分为两步：一次 Master RPC 查询定位缓存元数据，随后直接向多个 Store 节点并行发起 RDMA 读取。在 800Gbps 高性能网卡与 Transfer Engine 的多网卡池化、拓扑感知路径选择支持下，线上平均批量读取延迟小于 50 毫秒，绝大多数请求在 100 毫秒内完成，成功移出 GPU 关键等待路径。

2. Master 性能与分片锁优化

Master 中的元数据被哈希划分为 1024 个分片（shard），每个分片有独立的读写锁。随着并发增加，定期触发的 LRU eviction 会长时间占用写锁，阻塞正常的读写请求。

研发团队通过减少字符串拷贝与内存分配提升执行效率，并允许推理引擎多个 Rank 写入同一对象的不同位置以缩减对象总数；同时将副本销毁移出临界区，并将锁粒度从分片级进一步细化为对象级，大幅消除锁竞争。

在节点下线管理上，团队将流程拆解为“同步失效、异步清理”两个阶段：先将对应 segment 标记下线并移出分配池，再由后台线程异步清理元数据，将 Master 侧的下线响应耗时降至毫秒级。

3. RoCE 网络环境下的抖动排查

集群普遍采用基于 RTT 拥塞控制的 RoCE 组网。在线上高频传输中，团队观察到存在大量的 all-to-all 微突发 incast 流量，ECN/CNP 报文和 PFC 计数有所增加，但长期监控表明这并未对传输速度和 TTFT 产生显著拖慢。

相较于纯性能，更值得防范的是软硬件配置不一致带来的偶发抖动。例如 OVS 配置、网卡驱动固件差异和 Kubernetes 网络策略等外部因素都会触发报错，排查时需要覆盖端到端的全链路节点。

4. 控制故障爆炸半径的防线设计

为了防止缓存异常向上传导拖垮推理服务，团队确立了“分布式缓存服务可以暂时失效，但不能影响推理服务本身”的原则：

分组物理隔离：每个推理分组独立部署一套 Mooncake Store 集群，限制单点故障域；
网络资源隔离：为 Store 流量与 PD 分离传输流量分别分配独立网卡与 Transfer Engine 实例，切断通信干扰；
超时与集群熔断：HiCache 设定读取超时，若远端取回长尾则仅使用已就绪部分并重算剩余 Token；当 Store 集群持续异常时，自动熔断退化为纯本地缓存模式；
确定性写入顺序：写入数据时优先使用本地 Store，本地不足时按确定性顺序路由至候选节点，使同一请求的 KV Cache 相对集中，避免长前缀分散损坏。

未来演进方向

目前，SGLang HiCache 与 Mooncake 的协同已稳定支撑日均万亿 Token 的生产输出，后续研发团队计划推进三个演进方向：

引入 SSD 作为三级缓存：针对长上下文 Agent 中冷缓存的长尾复用需求，将低频数据从昂贵的 DRAM 异步下沉至 SSD，在控制成本的同时扩大有效容量；
联邦 Mooncake 跨组复用：打破现有分组独立边界，支持跨集群查询与读取，在不放大故障半径的前提下进一步提升全局命中率与调度弹性；
支持异构硬件推理：弱化推理服务对同构硬件的依赖，支持 Prefill 与 Decode 节点采用不同加速卡，根据工作负载特征将不同计算阶段动态调度至最优资源。

研发团队在文末致谢了 Mooncake 与 SGLang 开源社区的支持，并表示本次生产落地中的系统优化成果正逐步回馈至开源生态。

Fuentes de referencia

1
日均产出万亿Token！Mooncake落地生产，KV Cache命中率稳定突破90%
mp.weixin.qq.com