基于 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 吞吐量

快速预览：

# 启动 Mastermooncake_master --http_metadata_server_port=9080# 启动 Store 服务（配置 RDMA 设备与内存池）python -m mooncake.mooncake_store_service --config=config.json# 启动 SGLang（启用 Mooncake 后端）python -m sglang.launch_server \    --enable-hierarchical-cache \    --hicache-storage-backend mooncake \    --model-path <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 节点等硬件拓扑范围内完成，尽量避免拓扑漂移导致的性能抖动。

roles:- name: prefill  replicas: 3  rolloutStrategy:    rollingUpdate:      type: InplaceIfPossible      maxUnavailable: 1

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

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

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

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

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

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

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

# 示例：PD 分离架构中 Prefill 和 Decode 角色协作升级coordination:- name: prefill-decode-co-update  type: RollingUpdate  roles:  - prefill  - decode  strategy:    maxUnavailable: 5%    maxSkew: 1% # 两个角色在升级的过程中新版本比例的最大偏差    partition: 20%roles:- name: prefill  replicas: 200  template: ...- name: decode  replicas: 100  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 + 插件机制"的平台化设计，将新架构的投产周期显著缩短。

# 示例：PD 分离架构角色定义roles:- name: prefill  replicas: 2  engineRuntimes:  - profileName: custom-engine-runtime  template:  ...- name: decode  replicas: 1  engineRuntimes:  - profileName: custom-engine-runtime  template:  ...

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

• 查看部署结果：

kubectl get pods -l rolebasedgroup.workloads.x-k8s.io/name=sglang-pd-with-mooncake-demosglang-pd-with-mooncake-demo-router-0               1/1     Running   0          71ssglang-pd-with-mooncake-demo-prefill-0              1/1     Running   0          3m42ssglang-pd-with-mooncake-demo-decode-0               1/1     Running   0          3m42ssglang-pd-with-mooncake-demo-mooncake-master-0      1/1     Running   0          4m2ssglang-pd-with-mooncake-demo-mooncake-store-bh9xs   1/1     Running   0          3m42ssglang-pd-with-mooncake-demo-mooncake-store-dsrv4   1/1     Running   0          3m42ssglang-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='{.spec.nodeName}'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#1031 中，mooncake 支持在节点 ShareMemory 和本地磁盘（或高性能 NVMe）上将 KVCache 元数据与热数据快照持久化，确保进程重启后可快速恢复缓存状态，避免缓存失效导致的 Prefill 重计算；

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

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

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

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

kubectl patch rolebasedgroup sglang-pd-with-mooncake-demo \  --type='json' \  -p='[{"op": "replace", "path": "/spec/roles/1/template/spec/containers/0/image", "value": "lmsysorg/sglang:v0.5.6"}]'

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

kubectl get pods -l rolebasedgroup.workloads.x-k8s.io/name=sglang-pd-with-mooncake-demo -owideNAME                                                READY   STATUS             RESTARTS   AGEsglang-pd-with-mooncake-demo-decode-0               1/1     Running            0          7m4ssglang-pd-with-mooncake-demo-mooncake-master-0      1/1     Running            0          7m24ssglang-pd-with-mooncake-demo-mooncake-store-bh9xs   1/1     Running            1          7m4ssglang-pd-with-mooncake-demo-mooncake-store-dsrv4   1/1     Running            1          7m4ssglang-pd-with-mooncake-demo-mooncake-store-tqjvt   1/1     Running            1          7m4ssglang-pd-with-mooncake-demo-prefill-0              1/1     Running            0          7m4ssglang-pd-with-mooncake-demo-router-0               1/1     Running            0          4m33s

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

kubectl describe pods sglang-pd-with-mooncake-demo-mooncake-store-dsrv4Events:  Type     Reason          Age                  From               Message  ----     ------          ----                 ----               -------  Normal   Scheduled       27m                  default-scheduler  Successfully assigned default/sglang-pd-with-mooncake-demo-mooncake-store-dsrv4 to cn-beijing.10.134.xxx.xxx  Normal   AllocIPSucceed  27m                  terway-daemon      Alloc IP 10.134.25.238/16 took 584.019653ms  Normal   Created         27m                  kubelet            Created container: store  Normal   Pulled          27m                  kubelet            Container image "lmsysorg/sglang:v0.5.5" already present on machine  Normal   Started         27m                  kubelet            Started container store  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='{.spec.nodeName}' 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 指标上的收益情况。

• 测试对象

• 测试命令

python3 benchmark/hicache/bench_multiturn.py \--model-path /models/Qwen3-235B/Qwen3-235B-A22B \--dataset-path ShareGPT_V3_unfiltered_cleaned_split.json \--disable-random-sample \--output-length 1 \--request-length 2048 \--num-clients 150 \--num-rounds 10 \--max-parallel 4 \--request-rate 16 \--ready-queue-policy random \--disable-auto-run \--enable-round-barrier

• 分组记录：