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

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

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

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

背景

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

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

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

在趋境，这已经是一个万亿级规模的问题。趋境的线上推理系统每天需要稳定生产万亿级Token。当系统运行到这个量级时，哪怕几个百分点的算力浪费，都会被放大成巨大的基础设施成本。因此，在万亿级Token工厂中，KV Cache已经不再只是可选的局部优化，而成为影响整体产能和成本的关键基础设施。

如何让KV Cache从单机资源升级为集群级共享资源，在提高命中率和系统吞吐的同时，依然守住严格的SLO，这是趋境研发团队所面临的一个大问题。

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

在智能体和长上下文场景下，KV Cache的价值被进一步放大。但如果只依赖GPU HBM，KV Cache的复用天然存在一个两难：缓存空间分得少，命中率下降，大量历史上下文需要重复计算；缓存空间分得多，又会挤占请求处理所需的显存，降低new token的计算效率。尤其在超长上下文场景下，这一矛盾更加突出。

因此，研究团队首先在生产环境中引入了SGLang HiCache，将容量更大的Host DRAM纳入KV Cache层级。在不显著影响GPU计算效率的情况下，KV Cache的可用容量和命中率都得到明显提升。

但当系统规模进一步扩大到日均万亿级Token后，单机缓存的边界很快显现出来。

一方面，单节点DRAM容量终究有限，分散在不同节点上的重复KV Cache无法共享；另一方面，对于部分结构的KV Cache，在当时的HiCache架构下，同一节点的多个TP Rank会分别保存缓存，单节点就会有最高8倍的数据冗余。这些问题使缓存命中率距离理想状态仍有明显差距。

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

当某段KV Cache只存在于特定Prefill节点上时，为了复用这部分缓存，就需要将请求继续调度到这些节点，导致原本应该由实时负载、请求特征和资源状态决定的调度问题，被缓存所在的位置所约束。

换句话说，如果KV Cache仍然是节点私有资源，那么缓存复用与集群调度就是耦合的：调度器每扩大一步选择空间，都可能以降低缓存命中率、增加重复计算，甚至违反SLO为代价。随着集群规模不断扩大，这种耦合不仅会限制资源池化所能带来的收益，也会压缩调度算法的设计空间：系统很难根据流量波动、节点故障等实时状态灵活迁移请求，也难以进一步结合不同请求的上下文长度、缓存命中情况、计算特征，以及不同计算节点的硬件特性进行更细粒度的调度。

以负载均衡问题为例。如果为了提高命中率，持续将拥有相同前缀的请求路由到少数Prefill节点，会概率性地不时出现热点请求集中的问题，造成该热点节点请求堆积和排队，导致违反TTFT SLO；但如果为了缓解热点而将请求迁移到其他节点，又会因为KV Cache无法跨节点复用而触发大规模重新计算，高峰期甚至可能将压力进一步传导到新的节点。

对于万亿级Token工厂来说，这已经不只是几个百分点缓存命中率的问题，而是一个直接影响集群调度空间、峰值吞吐承载能力、故障应对能力以及SLO保障能力的系统性问题。

因此，研究团队进一步引入Mooncake Store，将原本分散在各个节点上的KV Cache池化为集群级共享资源。

研究团队的目标是同时做到三件事：

• 进一步提升KV Cache命中率；
• 解除KV Cache存储位置对集群调度的约束；
• 对于推理关键路径，不引入额外性能开销和系统风险。

从架构上看，SGLang HiCache+Mooncake Store自然就能解决前两个问题，真正困难的是第三点：一个缓存系统，必须足够快、足够稳定，而且任何时候都不能反过来拖慢甚至拖垮推理系统。这也成为过去半年里，趋境研发团队将Mooncake推向万亿级Token生产环境时最核心的工程挑战。

下面首先介绍整体部署架构，然后介绍研究团队是如何解决上述核心挑战的。

SGLang+Mooncake的生产级架构实践

当KV Cache从单机资源变成集群级共享资源后，问题也随之发生变化：它不再只是一个缓存系统，而需要和计算、网络、调度一起被统一设计。

系统架构总览

在趋境的线上推理系统中，服务由多个分组组成，每个分组包含多个GPU节点，并通过RDMA承担KV Cache的高速传输。请求首先经过网关层分流，再按照一定策略进入具体分组。下面重点介绍单个分组内部SGLang+Mooncake的部署方式。

分组内部采用Prefill-Decode分离部署，并仅在Prefill节点开启HiCache。这是因为长上下文请求的主要计算开销集中在Prefill阶段，缓存命中后可以直接减少首token生成前的大量重复计算；而Decode阶段更关注token-by-token的稳定、低延迟的生成，因此优先保持Decode链路简单、稳定。

Mooncake Store：把节点内存变成共享KV Cache池

Mooncake Store以独立Store Service的形式部署在所有Prefill和Decode节点上。

其中，Decode节点的Host Memory主要用于Mooncake Store；Prefill节点则由HiCache和Mooncake Store共同使用内存。这样一来，原本分散在不同机器上的DRAM被组织成一个更大的分布式KV Cache池，为跨节点复用提供基础。

Prefill节点HiCache所嵌入的Mooncake client被设置为不持有全局缓存空间，全局缓存空间由单独的Store Service进程所持有，使得推理引擎和缓存系统解耦，方便各自独立升级或扩缩容。考虑到单机NUMA拓扑，每个节点包含两个NUMA Node，再在每个NUMA Node上分别绑定一个Mooncake Store Service，尽量让KV Cache的本地访问和网络传输保持良好的NUMA亲和性，减少跨NUMA访问带来的额外开销，充分利用Mooncake Transfer Engine的拓扑感知传输能力。

在控制面上，Mooncake Master配置为三副本，采用一主两从模式，部署在三个GPU节点上；Mooncake依赖的etcd同样采用三副本，并与集群中的其他管理组件一起部署在独立CPU节点上。

基于SMG的集群调度

只有共享KV Cache还不够。缓存池化扩大了请求的可调度范围，但调度器仍然需要在Cache Locality、实时负载、节点状态和请求特征之间做出合理决策。例如，如果为了减少跨节点网络传输而一味追求Cache Locality，很容易把拥有相同前缀的请求持续打到少数Prefill节点，最终形成热点；如果只追求负载均衡，又可能频繁把请求迁移到缓存较冷的节点，增加远端访问甚至重新计算。

集群分组内请求调度基于SMG（SGLang Model Gateway）来实现，并结合线上实际情况进行了改进。在Prefill侧，调度器会综合HiCache本地命中率、节点实时负载、节点状态以及请求特征等信息进行决策，在满足SLO的前提下，尽可能提升整体系统吞吐、降低请求TTFT。

在Decode侧，由于Decode更关注持续生成阶段的吞吐和尾延迟稳定性，调度器会尽量将生成负载均匀分摊到多个Decode实例。

基于RBG的生产级编排

在Kubernetes层面，线上采用RBG（RoleBasedGroup）统一管理SGLang和Mooncake相关工作负载。RBG提供面向不同应用角色的拓扑定义和协同策略，使Prefill、Decode、Mooncake Store等不同角色能够作为一个整体进行部署和管理；etcd则作为基础元数据组件独立运行，不纳入RBG管理。

把Mooncake推向万亿级Token工厂

要把Mooncake推向日均超一万亿的Token生产环境，研究团队面对的核心问题不只是“能不能共享KV Cache”，而是Mooncake能否跟上Token工厂对性能和稳定性的超高要求。SGLang HiCache+Mooncake Store从架构上解决了缓存命中率和跨节点调度的问题，但前提是这套缓存基础设施必须足够快、足够稳定，不能给推理链路引入新的性能开销和系统风险。

2026年春节以来，趋境平均单台算力的AI Token生产效率提升超过3倍，总Token产能增长超过30倍，KV Cache命中率也有显著提升，稳定在90%以上。这意味着Mooncake不仅需要承载单节点上成倍增长的KV Cache吞吐，还要持续扩大单个集群能够覆盖的推理节点规模。上层Token生产效率每提升一步，底层缓存系统就必须同步向前一步，这成为过去半年Mooncake生产级优化始终悬在趋境研发团队头顶的“达摩克利斯之剑”。

快速的数据取回：让远端KV Cache读取隐藏在计算之后

KV Cache的复用主要发生在Prefill阶段。对于Prefill请求，HiCache会先检查本地缓存，对未命中的部分通过RPC查询Mooncake Master，获取对应KV Cache的元数据信息，再通过RDMA从多个Mooncake Store节点并行取回命中的数据。数据就绪后，请求才会进入GPU执行剩余的Prefill计算；Prefill完成后，新计算出的、Mooncake中尚未存在的KV Cache再被写回Store，供后续请求复用。由于KV Cache持续写入，Mooncake Master还需要持续维护元数据并执行LRU淘汰。

对线上推理来说，数据取回的速度是关键之处。HiCache会在请求进入调度队列后尽早异步发起远端KV Cache prefetch，使网络传输与GPU正在执行的计算重叠。因此Mooncake需要让KV Cache的取回尽可能被前序请求的执行时间掩盖掉。只要远端数据能够在GPU开始处理当前请求之前准备完成，Mooncake Store对推理引擎带来的额外开销就几乎无感；反之，一旦数据读取落后于调度节奏，GPU就只能等待KV Cache到位，缓存系统反而会制造新的空转和TTFT开销。

Mooncake的批量读取数据链路本身非常简单：一次Master RPC查询定位缓存，随后直接向多个Store节点并行发起RDMA读。因此，读取性能主要取决于两部分：一是Master RPC的查询延迟和吞吐能力，二是RDMA数据传输效率，后者又受到网络带宽以及Transfer Engine性能的共同影响。线上通常采用800Gbps的高性能网卡，再加上Transfer Engine的多网卡池化、拓扑感知的路径选择等优异架构，在当前生产环境的网络配置和负载特征下，没有观察到RDMA数据传输成为主要性能瓶颈。围绕第一点进行优化后，线上平均KV Cache批量读取请求延时小于50毫秒，绝大多数请求可以在100毫秒内完成，从而让远端KV Cache复用尽可能不进入GPU的关键等待路径。

扩展到更大的集群规模

完成KV Cache的集群级池化之后，研究团队希望单个Mooncake集群能够服务尽可能多的Prefill和Decode节点。更大的分组意味着更大的缓存复用范围、更强的流量波动承载能力、以及更大的调度和优化空间：

在扩展过程中，研究团队没有追求一步到位，而是采用逐级放大的方式推进：先在小规模分组上验证稳定性，再在测试集群中扩大规模进行长稳测试，持续观察性能和稳定性瓶颈；问题解决后进入线上灰度，确认稳定后再全面上线，并以此为基础继续扩展到更大的分组规模。通过这种逐级验证、逐步放大的方式，研究团队把集群扩展本身也变成了一套可控、可重复的工程流程。

在这过程中，研究团队也遇到了许多问题和挑战。

第一是Master服务的性能瓶颈。Master中的数据被哈希为1024个shard，每个shard有独立的读写锁作并发访问控制。随着Store缓存容量和并发请求持续增加，Master需要承受更高频率的元数据查询，定期触发的LRU eviction操作也会更耗时。在eviction时，eviction线程会逐个获取shard的写锁，如果元数据数量过多，则会长时间占用shard写锁，导致读和写的请求被阻塞住，eviction期间请求延迟显著升高。

针对这个问题，研究团队围绕提升eviction执行效率、降低eviction与读写请求之间的锁竞争两个方面进行了优化。对于前者，研究团队通过优化大幅减少了字符串拷贝、对象构造和内存分配等额外开销；并增强了数据写入机制，允许推理引擎多个rank写入同一个对象的不同位置，大幅减少了缓存对象的数量。对于后者，研究团队首先将replica的销毁和内存释放等耗时操作移出eviction的写锁临界区，从而缩短写锁持有时间；然后进一步地将shard粒度的锁优化为对象粒度的锁，从而大幅度减少了锁竞争。

第二是扩缩容的性能问题。在Store节点侧，上线时，一个Store节点需要申请数TB的内存并注册到多个RDMA网卡中，下线时，需要将这些内存从RDMA网卡注销并释放。这一过程非常耗时。研究团队针对内存初始化和RDMA注册做了性能优化，获得了数倍性能提升，在此基础上添加了对大页的支持，进一步大幅降低了内存申请、注册、注销和释放的耗时。

在Master侧，当Store节点下线时，需要遍历所有shard，将对应下线节点的数据清理掉，否则后续请求会尝试去读取已下线节点的数据，导致读取失败。元数据量较大时，这一过程会持续很久，大大拖慢节点下线时间。针对这一问题，研究团队将节点下线拆分为“同步失效、异步清理”两个阶段，先将segment移出分配池、并将其标记为正在下线，使得后续请求不再尝试读写该节点数据，再由后台线程完成元数据清理，从而将Master侧的下线请求完成时间降为毫秒级。

第三是KV Cache传输时的网络问题。研究团队的集群大多采用RoCE组网，开启了基于RTT的拥塞控制算法。在基于Mooncake的PD分离和KV Cache复用时，会有大量的KV Cache传输流量。在线上，研究团队观察到存在大量all-to-all的微突发incast流量，可以观测到ECN/CNP报文飙升，也有机内拥塞导致的PFC计数增加。但在长期的监控和测试后，研究团队认为这些现象并不会对KV Cache传输速度以及TTFT等生产指标产生显著影响，不会影响推理集群的吞吐量。

相比于网络性能，在KV cache传输场景下，更值得关注的问题是生产环境下的网络稳定性和抖动问题。研究团队注意到有大量故障与Mooncake TE的实现无关，而更多来自于集群配置。例如OVS配置、route配置、IOMMU配置、网卡固件驱动的不一致、k8s网络故障等，都有可能会导致Mooncake Transfer Engine报错。因此在排查RDMA网络错误时需要排查整个链路上的故障点，而非仅聚焦于nccl-tests等连通性测试。

集群的稳定和安全：控制故障的爆炸半径

对于大规模推理集群来说，性能决定了系统的上限，而稳定性决定了这个上限能不能被放心地用于生产。

当集群规模扩大后，硬件故障、网络抖动、进程异常和配置错误都会从“小概率事件”逐渐变成日常事件。Mooncake Store又处在KV Cache的共享数据路径上：一旦缓存系统的异常向上传导到推理引擎，原本只是某个Store节点、某张网卡或者某条传输链路的问题，就可能进一步演变成请求阻塞、TTFT抖动，甚至影响整个推理集群的可用性。

因此，在Mooncake上线早期，研究团队对稳定性的设计原则比较保守：分布式KV Cache服务可以暂时失效，但不能影响推理服务本身；局部故障可以发生，但不能被放大成集群级故障。

围绕这一原则，研究团队在集群隔离、网络隔离、超时熔断以及数据分配策略上都增加了一层保护。其中一部分措施属于上线初期的“过度防御”，随着Mooncake本身以及集群网络环境逐渐稳定，可以根据实际运行情况酌情简化或撤掉。但在系统规模快速扩张的阶段，这些机制帮助研究团队有效控制了新基础设施引入时的风险和故障爆炸半径。

首先，研究团队没有让所有推理节点共享一个超大Mooncake Store集群，而是沿用推理系统的分组边界，每个分组部署一套彼此独立的Mooncake Store集群。不同分组之间的缓存服务相互隔离，即使某个分组的Mooncake Store整体不可用，影响范围也会被限制在当前分组，不会进一步影响其他分组的KV Cache服务。这样做牺牲了一部分跨分组共享缓存的潜在收益，但换来了更清晰的故障域，也让灰度升级、扩缩容和故障处理变得更加可控。

其次，研究团队对Mooncake使用的网络资源进行了进一步隔离。生产环境中，PD分离本身就需要通过RDMA在Prefill和Decode节点之间传输数据，而Mooncake Store又会引入另一批规模可观的KV Cache读写流量。如果两类流量完全共用相同的网卡和Transfer Engine，一旦某一侧出现异常流量、资源竞争或者Transfer Engine故障，就存在相互影响的可能。因此在上线初期，研究团队单独为Mooncake Store分配网卡，并让Store和PD分离使用两套独立Transfer Engine实例，尽量在数据面和软件实例两个层面切断故障传播路径。

更重要的一层保护来自超时和熔断机制。HiCache本身已经提供了读取超时机制：当从Mooncake读取KV Cache的时间超过可配置阈值后，HiCache会停止等待尚未传输完成的数据，仅利用已经成功取回的部分缓存，剩余部分重新计算。这样即使某次远端读取发生长尾，也不会导致Prefill计算被阻塞。

在此基础上，研究团队又增加了一层Mooncake Store集群级熔断机制。当系统检测到Store集群出现持续异常或服务不可用时，可以自动切断HiCache与Mooncake Store的协作，让HiCache临时退化为只使用本地KV Cache的模式，保证推理服务仍然能够继续工作。

此外，研究团队还专门优化了KV Cache的数据分配策略，以减少单节点故障的爆炸半径。在Mooncake的默认分配策略中，KV Cache会被随机分配到一个Store节点上，导致一个长请求的KV Cache被分散到几乎所有节点。一旦任意节点故障，中间某块KV Cache丢失，后续缓存即使仍然存在，也无法继续用于Prefix Reuse，从而放大故障影响范围。同时，随机远程写入还会增加跨机器访问的网络开销和延迟。为此，研究团队实现了一个新的分配策略：写入KV Cache时，Mooncake会优先选择本地Store；本地空间不足时，再按确定性顺序尝试其他节点。对于同一个写入节点，尝试顺序保持一致，从而让同一请求的KV Cache尽可能集中在前几个候选节点上；而不同写入节点使用不同顺序，以兼顾负载均衡。

未来展望

目前，SGLang HiCache+Mooncake已经能够稳定支撑趋境科技日均万亿级Token生产，但从缓存容量、复用范围到硬件形态，仍然有进一步优化的空间。

后续趋境研发团队计划重点沿着下面几个方向继续推进：

引入SSD作为三级缓存：在Agentic workload中，KV Cache的生命周期存在长尾现象：大部分缓存很快失效，但仍有一小部分缓存会在较长时间后被再次复用，用昂贵的DRAM存储这部分数据性价比较低。后续研究团队计划引入SSD作为下一级缓存，将冷KV Cache从DRAM异步下沉到SSD，在控制成本的同时扩大有效缓存容量，进一步提升KV Cache命中率。

联邦Mooncake：支持跨分组的KV Cache复用。当前研究团队的Mooncake Store按分组独立部署，这种架构能够清晰地隔离故障域，但也人为划定了KV Cache的复用边界：同一个前缀即使已经存在于其他分组，只要请求进入新的分组，仍然无法直接复用。后续一方面会继续扩大单个分组的规模，另一方面也要打破分组边界，在保留现有的独立集群的同时支持Mooncake Client在必要时跨集群查询和读取KV Cache。这样不仅可以进一步提高全局缓存命中率，也能够让Router拥有更大的调度空间，请求不再需要在“缓存命中”和“跨分组调度”之间做严格二选一。当然，跨分组共享也会带来更复杂的元数据管理和网络流量控制，以及更大的故障传播风险，因此在持续扩大KV Cache复用范围的同时，也需要进一步完善跨集群的故障隔离和容错机制，让共享范围的扩大不以放大故障爆炸半径为代价。

支持异构推理集群。随着推理基础设施不断演进，一个Token工厂不会只由完全同构的GPU节点组成。后续研究团队计划支持更加灵活的异构部署，例如让Prefill和Decode节点使用不同的加速卡。Mooncake作为连接不同计算节点的共享KV Cache基础设施，可以进一步弱化推理服务对于具体计算设备的绑定，让计算、传输和缓存进一步解耦，根据workload的特征，把不同阶段的任务动态放到最合适的计算资源上。

致谢

感谢Mooncake社区和SGLang社区在趋境科技生产落地和持续优化过程中给予的倾情帮助与支持。

本文中涉及的Mooncake相关优化和改进已在逐步贡献回开源社区。

文章来自于微信公众号 “量子位”，作者 “量子位”