基於 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 系統，以實現穩定的高性能仍面臨新挑戰：

部署與運維複雜度高：推理服務不限於單一 Pod，還可能是由 Prefill/Decode 計算節點與 Mooncake 緩存節點構成的分佈式系統。兩者需在拓撲親和、生命週期、擴縮容策略上深度協同，而 Kubernetes 原生 Workload（Deployment/StatefulSet）難以表達這種多角色強協同語義，導致配置繁瑣、資源浪費或性能劣化。
滾動升級穩定性風險：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 吞吐量

快速預覽：

# 啓動 Master
mooncake_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 集羣的極致性能，又要求雲原生的敏捷彈性。當前生產環境面臨五大根本性挑戰：

快速架構迭代：分離式大模型推理架構（如 Prefill/Decode 解耦、多級 Router/Gateway 等）演進極快，傳統依賴固定抽象的平台難以及時適配新架構。
性能敏感：TTFT、TPOT 等關鍵性能指標對 GPU 拓撲（NVLink / PCIe）、RDMA 親和性等因素有亞毫秒級敏感度，隨意遷移或不當調度都會放大首響、尾響時延。
組件強依賴：關鍵角色之間存在強依賴關係（如 Prefill 與 Decode 等角色需要 1:1、N:1 等強綁定關係），版本升級、回滾必須在多個角色之間保持原子性，否則容易導致請求失敗或數據不一致。
運維效率低：現有平台在重啓、擴縮容、故障遷移等運維操作上缺乏對多角色整體的統一視角，日均高達 5% 的時間消耗於重啓擴容升級中的手動協調，導致 GPU 資源空置浪費。
資源潮汐顯著與利用率不足：線上流量峯谷差常超 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-demo
sglang-pd-with-mooncake-demo-router-0               1/1     Running   0          71s
sglang-pd-with-mooncake-demo-prefill-0              1/1     Running   0          3m42s
sglang-pd-with-mooncake-demo-decode-0               1/1     Running   0          3m42s
sglang-pd-with-mooncake-demo-mooncake-master-0      1/1     Running   0          4m2s
sglang-pd-with-mooncake-demo-mooncake-store-bh9xs   1/1     Running   0          3m42s
sglang-pd-with-mooncake-demo-mooncake-store-dsrv4   1/1     Running   0          3m42s
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='{.spec.nodeName}'
kubectl get pods sglang-pd-with-mooncake-demo-mooncake-store-dsrv4 -o jsonpath='{.status.podIP}'

4.3. Benchmark 測試結果：多級緩存加速顯著

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 -owide
NAME                                                READY   STATUS             RESTARTS   AGE
sglang-pd-with-mooncake-demo-decode-0               1/1     Running            0          7m4s
sglang-pd-with-mooncake-demo-mooncake-master-0      1/1     Running            0          7m24s
sglang-pd-with-mooncake-demo-mooncake-store-bh9xs   1/1     Running            1          7m4s
sglang-pd-with-mooncake-demo-mooncake-store-dsrv4   1/1     Running            1          7m4s
sglang-pd-with-mooncake-demo-mooncake-store-tqjvt   1/1     Running            1          7m4s
sglang-pd-with-mooncake-demo-prefill-0              1/1     Running            0          7m4s
sglang-pd-with-mooncake-demo-router-0               1/1     Running            0          4m33s

可以通過查看 Pod 的事件確認重新原因：

kubectl describe pods sglang-pd-with-mooncake-demo-mooncake-store-dsrv4
Events:
  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

分組記錄：

龍蜥社區博客

龍蜥社區博客

博客 / 詳情