作者 | 玖宇（SGLang 社区 & 阿里云），杨彦波（SGLang 社区 & 科大讯飞），孙伟祥（SGLang 社区 & 小红书），宋阳（SGLang 社区 & 小红书），雨杨（Mooncake & 阿里云）

背景

大语言模型（LLM）推理服务正迅速成为企业级应用的核心基础设施。生产级落地的关键在于性能、稳定性与成本三者的平衡，而本文聚焦于如何构建稳定的高性能推理系统。

当前，LLM 推理架构正从单体模式向分布式演进，主流路径包括 Prefill-Decode（PD）分离、Attention-FFN（AF）分离以及 KVCache 外置。这一演进的根本动因是模型规模扩张导致的显存压力：在长上下文或高并发场景下，KVCache 显存占用常超 70%，单纯依赖 GPU HBM 与 CPU DRAM 已难以为继。将 KVCache 解耦外置，不仅能突破存储容量瓶颈，更能实现跨请求缓存共享、弹性伸缩与故障隔离等关键能力。尤其在 RAG、AI Agent、长文本生成等机器驱动消费 Token 的场景中，提示词模板化与可复用性成为常态，外置 KVCache 已成为保障低延迟、高吞吐与成本效益的必选项。

Mooncake 作为业界主流的分布式 KVCache 存储引擎，正是为应对这一挑战而生。它通过专用缓存集群为 SGLang 等推理框架提供高吞吐、低延迟的 KVCache 分布式服务。

然而，在生产环境中管理 Mooncake 这类分布式 KVCache 系统，以实现稳定的高性能仍面临新挑战：

为根治这些痛点，RoleBasedGroup（RBG） 应运而生。作为面向 AI 推理的 Kubernetes 原生 API，RBG 通过多角色协同编排，将 Mooncake 缓存与 SGLang 推理节点视为同一服务的不同角色，统一管理其部署、升级与弹性。借助 RBG 的原地升级与拓扑感知能力，既能尽可能避免缓存丢失，又能确保计算与缓存升级、调度和伸缩策略上的一致性，从而在性能最大化的同时，保障生产环境的稳定性与可运维性。

本文旨在阐明如何将 Mooncake Store 作为 RBG 编排下 SGLang PD 分离推理服务的补充角色，系统化实现生产级 KVCache 外置能力。

Mooncake：面向大模型推理的分布式 KVCache 存储引擎

项目地址：

Mooncake 是 SGLang HiCache（层级缓存）的高性能分布式 L3 存储后端，通过 RDMA 实现跨机 KVCache 共享，突破单机 GPU/CPU 缓存容量瓶颈。

https://static001.geekbang.org/wechat/images/dd/dd65ea0d9db0d55514786c172df73235.png

核心组件：

Master Service：管理集群存储池、元数据与节点生命周期

Store Service：提供分布式缓存存储，支持多副本、条带化传输与热点负载均衡

核心特性：

RDMA 加速 + 零拷贝机制，实现高带宽、低延迟数据访问

智能预取与 GPU 直传，最大化 I/O 效率

支持 PD 分离架构，提升大规模集群 Token 吞吐量

快速预览：

RoleBasedGroup (RBG)：面向大模型推理的弹性角色编排引擎

项目地址：

3.1 核心问题：大模型推理生产落地的五大挑战

大模型推理正演变为"最昂贵的微服务"——既需 HPC 集群的极致性能，又要求云原生的敏捷弹性。当前生产环境面临五大根本性挑战：

根本矛盾：传统微服务面向无状态、弱拓扑场景，而大模型推理是强状态、拓扑感知、极致性能的有状态应用。

3.2 RBG 设计理念：角色即一等公民，角色协同即核心场景

RBG 源自 SGLang 社区，由小红书，算秩未来，科大讯飞、阿里云和南京大学等联合贡献。其核心目标，是在兼顾性能与稳定性的前提下，以"角色（Role）"作为调度编排的原子单元，构建贴合 LLM 推理特性的管理范式。

RBG 将一次推理服务视为拓扑化、有状态、可协同的"角色有机体"，而非孤立的 Deployment 集合。基于此理念，RBG 提出面向生产环境的 SCOPE 核心能力框架：

S – Stable：面向拓扑感知的确定性运维

C – Coordination：跨角色协同策略引擎

O – Orchestration：有编排语义的角色与服务发现

P – Performance：拓扑感知的高性能调度

E – Extensible：面向未来的声明式抽象

3.3 SCOPE 核心能力解析

3.3.1 Stable (稳定)：面向拓扑感知的确定性运维

稳定性是 RBG 的基石。通过为每个 Pod 注入全局唯一 RoleID，并遵循 “最小替换域” 原则，RBG 确保运维操作在原有 GPU-NVLink 域、NUMA 节点等硬件拓扑范围内完成，尽量避免拓扑漂移导致的性能抖动。

3.3.2 Coordination (协同)：跨角色协同策略引擎

RBG 内置声明式协同引擎，通过机制精确定义角色间依赖关系：

部署协同：例如 Prefill 与 Decode 以特定比例成对调度、成组就绪；

升级协同：支持 “比例协议” 式升级，确保多角色版本一致性，避免部分升级导致协议不兼容；

故障协同：预定义联动策略，某个角色故障时触发关联角色的自动补救或迁移；

伸缩协同：在扩缩容时按照角色关系配比成组调整实例，保持吞吐与延迟表现稳定。

这种精细化协同能力，将复杂分布式推理服务作为统一生命周期的整体进行管理，极大降低运维复杂度。

3.3.3 Orchestration (编排)：编排化的角色与服务发现

RBG 显式定义角色依赖与精确启动顺序，实现编排化管理。更关键的是，它提供拓扑自感知的内建服务发现，在 Pod 启动时将完整拓扑信息（各角色 IP、属性、关系等）注入环境变量或配置文件。

推理引擎（SGLang、vLLM 等）可直接从本地配置读取拓扑视图，无需依赖 etcd、Consul 等外部服务发现系统，使服务跨环境迁移更自包含，显著降低集成复杂度。

3.3.4 Performance (性能)：拓扑感知的高性能调度

单次请求的延迟与吞吐高度依赖硬件拓扑与资源亲和性。RBG 引入拓扑感知的装箱策略，支持多维度性能优化：

GPU 拓扑优先级（如）；

角色之间的亲和与反亲和约束；

同角色实例的布局均衡性；

部署完成后的短路读优化。

通过这些约束与策略，RBG 在大规模部署时，能够在不牺牲稳定性的前提下，尽可能贴合最优的硬件拓扑，从而保障 TTFT、TPOT 等关键性能指标。

3.3.5 Extensible (可扩展)：面向变化的部署抽象

RBG 通过声明式 API（、、等）与插件化机制，将 "角色关系定义"与"部署 / 模型管理 / 弹性策略"解耦。

当社区演进出新架构（如新路由层形态、分离式架构等时），无需修改 RBG 核心代码，只需通过 YAML 定义新角色模板与关系，即可快速落地。这种"声明式 API + 插件机制"的平台化设计，将新架构的投产周期显著缩短。

RBG 通过 Kubernetes 原生 API ，为大模型推理服务提供了一套 稳定（Stable）、协同（Coordination）、可编排（Orchestration）、高性能（Performance）、可演进（Extensible） 的统一承载层，是面向现代 LLM 推理工作负载的一种新型部署与运维抽象。

基于 RBG 部署 PD 分离架构 +Mooncake

推理服务

4.1. 部署架构

https://static001.geekbang.org/wechat/images/00/004156b8786cb778a4dd59e76c286e8e.png

通过 RoleBasedGroup 可部署高可用、弹性的 SGLang PD 分离推理系统，核心组件如下：

整个系统由以下核心角色构成：

SGLang Router：作为统一的请求入口与流量调度器，负责接收用户推理请求，根据负载状态、上下文长度和模型配置，智能为请求选择合适的 Prefill 和 Decode 节点进行处理。

Prefill Serving Backend：专用于处理提示词（prompt）的前向计算，生成初始 KVCache；通常为计算密集型，对显存带宽敏感。

Decode Serving Backend：专注于自回归生成阶段的 token 逐个解码，依赖已生成的 KVCache 进行高效推理；对缓存访问延迟极为敏感。

Mooncake Master/Store：作为独立的 KVCache 外置存储角色，提供高吞吐、低延迟的分布式缓存服务，持久化存储所有推理会话的 Key-Value Cache。它不仅突破了单 GPU HBM 和 CPU DRAM 的容量限制，还支持跨请求缓存复用以及细粒度缓存淘汰策略（如 LRU + 高水位驱逐）。

这些角色并非孤立运行，而是通过 RBG 提供的原生多角色协同能力紧密集成。此外，EngineRuntime 作为 RBG 注入给引擎服务 Pod 的 Sidecar，成为推理引擎与上层编排系统的桥梁，提供了服务注册与元数据上报、动态 LoRA 加载 / 卸载、流量状态控制和可观测性集成的关键的运行时能力。

4.2. 通过 RBG 部署 Mooncake + SGLang PD 分离推理服务

安装 RBG：

https://github.com/sgl-project/rbg/blob/main/doc/install.md

镜像准备见附录 8.1

服务部署

准备好容器镜像后，使用下面的 yaml，可以基于 RBG 部署带有 KVCache Offloading 能力的 SGLang PD 分离推理服务：

yaml 中涉及的环境变量说明可以参考：

查看部署结果：

查看 Mooncake Store 角色其中一个实例的网络和 location 信息：

4.3. Benchmark 测试结果：多级缓存加速显著

多轮对话场景测试表明，多级缓存架构对 KVCache 命中率与推理性能提升至关重要：

Baseline（仅 GPU 显存）：缓存命中率低，平均 TTFT 5.91s，P90 12.16s，系统吞吐受限，InputToken 吞吐仅为 6576.85 token/s

L2DRAMHiCache：命中率提升至 40.62%，平均 TTFT 降至 3.77s（↓36.2%），P90 降至 10.88s，InputToken 吞吐提升至 10054.21 token/s（↑52.89%）

L3 Mooncake 缓存：命中率进一步跃升，平均 TTFT 降至 2.58s（↓56.3%），P90 大幅改善至 6.97s（↓42.7%），InputToken 吞吐提升至 15022.80 token/s（↑49.41%）

https://static001.geekbang.org/wechat/images/d3/d326af6e0cc7e598f2ccfad950cb842f.png

多轮对话测试场景下服务整体吞吐指标

https://static001.geekbang.org/wechat/images/fe/feeceb94ef783e938e3c1b7d5469c3a5.png

https://static001.geekbang.org/wechat/images/12/12ddbc578afc3fb17286a1646cac7686.png

多轮对话测试场景下 KVCache 命中率及对应 TTFT 指标

测试细节详见附录 8.2

通过原地升级能力实现 Mooncake 版本平滑升级

由于 Mooncake 内置的 transfer-engine 与 SGLang Serving Backend（Prefill/Decode）中的 transfer-engine 需保持严格版本一致，以确保 KVCache 传输协议的兼容性，因此在推理引擎升级时，Mooncake 需要同步进行版本更新。

然而，Mooncake 作为有状态的缓存服务，其 KVCache 数据通常仅驻留在内存中。在传统 Kubernetes 滚动升级（Rolling Update）过程中，旧 Pod 被终止时，其内存中的缓存数据会立即丢失；而新 Pod 启动后需要经历重新调度、重新创建的过程。这导致所有依赖该节点缓存的活跃推理会话被迫中断，必须重新执行完整的 Prefill 计算——这一过程不仅计算开销巨大，还会引发：

P99 首 Token 延迟显著毛刺（从秒级飙升至数十秒）；

因大量请求排队等待 Prefill，导致的系统吞吐量断崖式下跌；

用户体验剧烈抖动，破坏生产环境的服务稳定性。

解决方案：Mooncake 缓存本地持久化 + RBG 原地升级：

Mooncake 缓存本地持久化：在 Mooncake 社区的 PR#1031 中，mooncake 支持在节点 ShareMemory 和本地磁盘（或高性能 NVMe）上将 KVCache 元数据与热数据快照持久化，确保进程重启后可快速恢复缓存状态，避免缓存失效导致的 Prefill 重计算；

RBG 原地升级：通过 RBG 的精细化角色控制能力，在升级 Mooncake 角色时避免重建 Pod，而是原地替换容器镜像并复用节点的本地盘或共享内存，从而保留已持久化的缓存数据，实现 “无缝” 版本切换。

二者结合，使得在 Serving Backend 与 Mooncake 联合升级过程中，KVCache 状态得以延续，活跃会话无需回退到 Prefill 阶段，从而有效规避了延迟毛刺与吞吐下跌，保障了大模型推理服务在版本迭代期间的端到端稳定性与高可用性。

https://static001.geekbang.org/wechat/images/97/976b5a0c8353e77676ac18d45ed5dedd.png

我们对刚刚部署的服务进行引擎版本的更新，由 v0.5.5 版本更新至 v0.5.6，

通过查看 Pod 状态能发现，在 Mooncake Store 角色镜像版本更新后仅发生了一次容器的重启。

可以通过查看 Pod 的事件确认重新原因：

确认重启的 Mooncake 实例状态可以发现，在原地升级后 Pod 的网络和拓扑信息并没有发生改变，配合 Mooncake 提供的缓存持久化能力，可以保证重启前的 KVCache 缓存并没有发生丢失，在原地升级后预期地完成了恢复。

总结和展望

本文系统阐述了如何通过 RoleBasedGroup（RBG）与 Mooncake 的协同设计，构建生产级的稳定高性能 PD 分离推理服务。结论如下：

RBG 重新定义了 LLM 推理服务的编排范式：通过将多角色协同（PD 分离、Mooncake 缓存）与拓扑感知调度作为一等公民，RBG 不仅解决了分布式部署的复杂性，更通过原地升级能力攻克了"有状态缓存服务平滑演进"这一行业难题，实现了升级无感、服务不抖的生产级目标。

Mooncake 解锁了 KVCache 的无限可能：作为 L3 缓存层，Mooncake 通过分布式内存池与 RDMA 加速，使缓存命中率跃升，TTFT 降低 56.3%，P90 延迟改善 42.7%，同时将 GPU 平均利用率从不足 30% 提升至可持续弹性伸缩的水平，真正平衡了性能与成本。

分级缓存架构是长上下文推理的必由之路：从 GPU HBM → DRAM → Mooncake 的三级缓存体系，在 Benchmark 中证明了其有效性，尤其在多轮对话、RAG、AI Agent 等机器驱动场景中，缓存复用带来的边际成本递减效应将愈发显著。

RBG + Mooncake 的实践表明，只有将高性能系统设计与云原生运维能力深度融合，才能让大模型推理真正从"能用"走向"好用"，从"实验室"走向"生产级"。 我们期待与社区共同推进这一范式，为下一代 AI 基础设施奠定基础。

Acknowledgment

小红书：孙伟祥、宋阳、熊峰

科大讯飞：杨彦波

趋境科技：杨珂

Mooncake：马腾、蔡尚铭

阿里云：一斋、柏存、东伝

附录

8.1 镜像构建

此本文所使用部署样例中，我们可以直接使用 SGLang 社区的官方容器镜像 lmsysorg/sglang:v0.5.5（mooncake-transfer-engine >= 0.3.7），该镜像已经默认包含了 Mooncake 相关依赖。如果有定制化需求，可以参考链接中提供的 Dockerfile 自行构建特定版本的 Mooncake 镜像：

8.2 Benchmark 测试

8.2.1 环境配置

https://static001.geekbang.org/wechat/images/bb/bb8c59398986f4a562839168ae59b7b4.png

8.2.2 测试方法

通过 HiCache 提供的多轮对话压测工具模拟多轮对话场景，测试 KVCache 可重用场景下开启了 L3 Mooncake + L2 Hicache 的推理服务，相对于仅开启了 L2 Hicache 和不开启 Hicache 的推理服务，在吞吐指标和 SLO 指标上的收益情况。

测试对象

https://static001.geekbang.org/wechat/images/a3/a313fcabaff6d24845051ea8aa0a8815.png

测试命令

分组记录：

https://static001.geekbang.org/wechat/images/5c/5cc8fb0f81df0999cda99e931b3d07f9.png

背 景

基于 SGlang RBG + Mooncake 打造生产级云原生大模型推理平台