基于 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 年最后一場，不容錯過。

今日薦文

你也「在看」嗎？