随着智能体从 " 一问一答 " 走向持续规划、工具调用和多轮执行，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 从单机资源变成集群级共享资源后，问题也随之发生变化：它不再只是一个缓存系统，而需要和计算、网络、调度一起被统一设计。
系统架构总览
分组内部采用 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 相关优化和改进已在逐步贡献回开源社区。
一键三连「点赞」「转发」「小心心」
欢迎在评论区留下你的想法！
— 完 —
【学术投稿】请在工作日发送邮件至：ai@qbitai.com，标题注明【投稿】，并告诉我们：你是谁，从哪来，投稿内容附上项目 / 主页链接，以及联系方式。
我们会 ( 尽量 ) 及时回复你 : )
点亮星标
科技前沿进展每日见
