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

作者 | 玖宇（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 系统，以实现稳定的高性能仍面临新挑战：

1. 部署与运维复杂度高：推理服务不限于单一 Pod，还可能是由 Prefill/Decode 计算节点与 Mooncake 缓存节点构成的分布式系统。两者需在拓扑亲和、生命周期、扩缩容策略上深度协同，而 Kubernetes 原生 Workload（Deployment/StatefulSet）难以表达这种多角色强协同语义，导致配置繁琐、资源浪费或性能劣化。

2. 滚动升级稳定性风险：Prefill 与 Mooncake 实例在升级过程中缓存丢失，迫使活跃会话的Prefill阶段需要重新计算，引发 P99 延迟毛刺与吞吐量断崖，严重影响服务稳定性。

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

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

Mooncake：面向大模型推理的

分布式 KVCache 存储引擎

项目地址：

https://github.com/kvcache-ai/Mooncake

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

核心组件：

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

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

核心特性：

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

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

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

快速预览：

    --model-path

RoleBasedGroup (RBG)：

面向大模型推理的弹性角色编排引擎

项目地址：

https://github.com/sgl-project/rbg

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

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

1. 快速架构迭代：分离式大模型推理架构（如 Prefill/Decode 解耦、多级 Router/Gateway 等）演进极快，传统依赖固定抽象的平台难以及时适配新架构。

2. 性能敏感：TTFT、TPOT 等关键性能指标对 GPU 拓扑（NVLink / PCIe）、RDMA 亲和性等因素有亚毫秒级敏感度，随意迁移或不当调度都会放大首响、尾响时延。

3. 组件强依赖：关键角色之间存在强依赖关系（如 Prefill 与 Decode 等角色需要 1:1、N:1 等强绑定关系），版本升级、回滚必须在多个角色之间保持原子性，否则容易导致请求失败或数据不一致。

4. 运维效率低：现有平台在重启、扩缩容、故障迁移等运维操作上缺乏对多角色整体的统一视角，日均高达 5% 的时间消耗于重启扩容升级中的手动协调，导致 GPU 资源空置浪费。

5. 资源潮汐显著与利用率不足：线上流量峰谷差常超 10 倍，但静态配置的推理服务 GPU 平均利用率长期低于 30%，性能与成本难以兼得。

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

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 节点等硬件拓扑范围内完成，尽量避免拓扑漂移导致的性能抖动。

      maxUnavailable: 1

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

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

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

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

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

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

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

  template: ...

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

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

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

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

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

• GPU 拓扑优先级（如GPU-NVLink > PCIe > RDMA > VPC）；

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

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

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

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

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

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

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

  ...

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

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

推理服务

4.1. 部署架构

通过 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 分离推理服务：https://github.com/sgl-project/rbg/blob/main/examples/mooncake/pd-disaggregated-with-mooncake.yaml

yaml 中涉及的环境变量说明可以参考：https://github.com/kvcache-ai/Mooncake/blob/main/doc/zh/mooncake-store.md

• 查看部署结果：

sglang-pd-with-mooncake-demo-mooncake-store-tqjvt   1/1     Running   0          3m42s

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

kubectl get pods sglang-pd-with-mooncake-demo-mooncake-store-dsrv4 -o jsonpath='{.status.podIP}'

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%）

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

多轮对话测试场景下 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 中，mooncake 支持在节点 ShareMemory 和本地磁盘（或高性能 NVMe）上将 KVCache 元数据与热数据快照持久化，确保进程重启后可快速恢复缓存状态，避免缓存失效导致的 Prefill 重计算；

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

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

换言之，RBG 不仅解决了多角色协同部署的复杂性，更通过原地升级，将“有状态缓存服务的平滑演进”这一行业难题转化为标准化、可自动化的运维能力，真正实现了 “升级无感、服务不抖” 的生产级目标。

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

  -p='[{"op": "replace", "path": "/spec/roles/1/template/spec/containers/0/image", "value": "lmsysorg/sglang:v0.5.6"}]'

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

sglang-pd-with-mooncake-demo-router-0               1/1     Running            0          4m33s

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

  Normal   Killing         21m                  kubelet            Container store definition changed, will be restarted

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

 kubectl get pods sglang-pd-with-mooncake-demo-mooncake-store-dsrv4 -o jsonpath='{.status.podIP}'

总结和展望

本文系统阐述了如何通过 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 镜像：https://github.com/sgl-project/rbg/blob/main/examples/mooncake/Dockerfile.mooncake

8.2 Benchmark 测试

8.2.1 环境配置

8.2.2 测试方法

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

• 测试对象

• 测试命令

--enable-round-barrier

• 分组记录：

会议预告

12 月 19～20 日，AICon 2025 年度收官站在北京举办。现已开启 9 折优惠。

两天时间，聊最热的 Agent、上下文工程、AI 产品创新等等话题，与头部企业与创新团队的专家深度交流落地经验与思考。2025 年最后一场，不容错过。

今日荐文

你也「在看」吗？