作者 | 玖宇（SGLang 社區(qū) & 阿里云），楊彥波（SGLang 社區(qū) & 科大訊飛），孫偉祥（SGLang 社區(qū) & 小紅書），宋陽 （SGLang 社區(qū) & 小紅書），雨楊 （Mooncake & 阿里云）

背 景

大語言模型（LLM）推理服務正迅速成為企業(yè)級應用的核心基礎(chǔ)設(shè)施。生產(chǎn)級落地的關(guān)鍵在于性能、穩(wěn)定性與成本三者的平衡，而本文聚焦于如何構(gòu)建穩(wěn)定的高性能推理系統(tǒng)。

當前，LLM 推理架構(gòu)正從單體模式向分布式演進，主流路徑包括Prefill-Decode（PD）分離、Attention-FFN（AF）分離以及KVCache 外置。這一演進的根本動因是模型規(guī)模擴張導致的顯存壓力：在長上下文或高并發(fā)場景下，KVCache 顯存占用常超 70%，單純依賴 GPU HBM 與 CPU DRAM 已難以為繼。將 KVCache 解耦外置，不僅能突破存儲容量瓶頸，更能實現(xiàn)跨請求緩存共享、彈性伸縮與故障隔離等關(guān)鍵能力。尤其在 RAG、AI Agent、長文本生成等機器驅(qū)動消費 Token 的場景中，提示詞模板化與可復用性成為常態(tài)，外置 KVCache 已成為保障低延遲、高吞吐與成本效益的必選項。

Mooncake作為業(yè)界主流的分布式 KVCache 存儲引擎，正是為應對這一挑戰(zhàn)而生。它通過專用緩存集群為 SGLang 等推理框架提供高吞吐、低延遲的 KVCache 分布式服務。

然而，在生產(chǎn)環(huán)境中管理 Mooncake 這類分布式 KVCache 系統(tǒng)，以實現(xiàn)穩(wěn)定的高性能仍面臨新挑戰(zhàn)：

1. 部署與運維復雜度高：推理服務不限于單一 Pod，還可能是由 Prefill/Decode 計算節(jié)點與 Mooncake 緩存節(jié)點構(gòu)成的分布式系統(tǒng)。兩者需在拓撲親和、生命周期、擴縮容策略上深度協(xié)同，而 Kubernetes 原生 Workload（Deployment/StatefulSet）難以表達這種多角色強協(xié)同語義，導致配置繁瑣、資源浪費或性能劣化。

2. 滾動升級穩(wěn)定性風險：Prefill 與 Mooncake 實例在升級過程中緩存丟失，迫使活躍會話的Prefill階段需要重新計算，引發(fā) P99 延遲毛刺與吞吐量斷崖，嚴重影響服務穩(wěn)定性。

為根治這些痛點，RoleBasedGroup（RBG）應運而生。作為面向 AI 推理的 Kubernetes 原生 API，RBG 通過多角色協(xié)同編排，將 Mooncake 緩存與 SGLang 推理節(jié)點視為同一服務的不同角色，統(tǒng)一管理其部署、升級與彈性。借助 RBG 的原地升級與拓撲感知能力，既能盡可能避免緩存丟失，又能確保計算與緩存升級、調(diào)度和伸縮策略上的一致性，從而在性能最大化的同時，保障生產(chǎn)環(huán)境的穩(wěn)定性與可運維性。

本文旨在闡明如何將 Mooncake Store 作為 RBG 編排下 SGLang PD 分離推理服務的補充角色，系統(tǒng)化實現(xiàn)生產(chǎn)級 KVCache 外置能力。

Mooncake：面向大模型推理的

分布式 KVCache 存儲引擎

項目地址：

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

Mooncake 是 SGLang HiCache（層級緩存）的高性能分布式 L3 存儲后端，通過 RDMA 實現(xiàn)跨機 KVCache 共享，突破單機 GPU/CPU 緩存容量瓶頸。

核心組件：

• Master Service：管理集群存儲池、元數(shù)據(jù)與節(jié)點生命周期

• Store Service：提供分布式緩存存儲，支持多副本、條帶化傳輸與熱點負載均衡

核心特性：

• RDMA 加速 + 零拷貝機制，實現(xiàn)高帶寬、低延遲數(shù)據(jù)訪問

• 智能預取與 GPU 直傳，最大化 I/O 效率

• 支持 PD 分離架構(gòu)，提升大規(guī)模集群 Token 吞吐量

快速預覽：

    --model-path

RoleBasedGroup (RBG)：

面向大模型推理的彈性角色編排引擎

項目地址：

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

3.1 核心問題：大模型推理生產(chǎn)落地的五大挑戰(zhàn)

大模型推理正演變?yōu)?最昂貴的微服務"——既需 HPC 集群的極致性能，又要求云原生的敏捷彈性。當前生產(chǎn)環(huán)境面臨五大根本性挑戰(zhàn)：

1. 快速架構(gòu)迭代：分離式大模型推理架構(gòu)（如 Prefill/Decode 解耦、多級 Router/Gateway 等）演進極快，傳統(tǒng)依賴固定抽象的平臺難以及時適配新架構(gòu)。

2. 性能敏感：TTFT、TPOT 等關(guān)鍵性能指標對 GPU 拓撲（NVLink / PCIe）、RDMA 親和性等因素有亞毫秒級敏感度，隨意遷移或不當調(diào)度都會放大首響、尾響時延。

3. 組件強依賴：關(guān)鍵角色之間存在強依賴關(guān)系（如 Prefill 與 Decode 等角色需要 1:1、N:1 等強綁定關(guān)系），版本升級、回滾必須在多個角色之間保持原子性，否則容易導致請求失敗或數(shù)據(jù)不一致。

4. 運維效率低：現(xiàn)有平臺在重啟、擴縮容、故障遷移等運維操作上缺乏對多角色整體的統(tǒng)一視角，日均高達 5% 的時間消耗于重啟擴容升級中的手動協(xié)調(diào)，導致 GPU 資源空置浪費。

5. 資源潮汐顯著與利用率不足：線上流量峰谷差常超 10 倍，但靜態(tài)配置的推理服務 GPU 平均利用率長期低于 30%，性能與成本難以兼得。

根本矛盾：傳統(tǒng)微服務面向無狀態(tài)、弱拓撲場景，而大模型推理是強狀態(tài)、拓撲感知、極致性能的有狀態(tài)應用。

3.2 RBG 設(shè)計理念：

角色即一等公民，角色協(xié)同即核心場景

RBG 源自 SGLang 社區(qū)，由小紅書，算秩未來，科大訊飛、阿里云和南京大學等聯(lián)合貢獻。其核心目標，是在兼顧性能與穩(wěn)定性的前提下，以"角色（Role）"作為調(diào)度編排的原子單元，構(gòu)建貼合 LLM 推理特性的管理范式。

RBG 將一次推理服務視為拓撲化、有狀態(tài)、可協(xié)同的"角色有機體"，而非孤立的 Deployment 集合�；诖死砟睿琑BG 提出面向生產(chǎn)環(huán)境的 SCOPE 核心能力框架：

• S – Stable：面向拓撲感知的確定性運維

• C – Coordination：跨角色協(xié)同策略引擎

• O – Orchestration：有編排語義的角色與服務發(fā)現(xiàn)

• P – Performance：拓撲感知的高性能調(diào)度

• E – Extensible：面向未來的聲明式抽象

3.3 SCOPE 核心能力解析

3.3.1 Stable (穩(wěn)定)：面向拓撲感知的確定性運維

穩(wěn)定性是 RBG 的基石。通過為每個 Pod 注入全局唯一 RoleID，并遵循 "最小替換域" 原則，RBG 確保運維操作在原有 GPU-NVLink 域、NUMA 節(jié)點等硬件拓撲范圍內(nèi)完成，盡量避免拓撲漂移導致的性能抖動。

      maxUnavailable: 1

3.3.2 Coordination (協(xié)同)：跨角色協(xié)同策略引擎

RBG 內(nèi)置聲明式協(xié)同引擎，通過Coordination機制精確定義角色間依賴關(guān)系：

• 部署協(xié)同：例如 Prefill 與 Decode 以特定比例成對調(diào)度、成組就緒；

• 升級協(xié)同：支持“比例協(xié)議”式升級，確保多角色版本一致性，避免部分升級導致協(xié)議不兼容；

• 故障協(xié)同：預定義聯(lián)動策略，某個角色故障時觸發(fā)關(guān)聯(lián)角色的自動補救或遷移；

• 伸縮協(xié)同：在擴縮容時按照角色關(guān)系配比成組調(diào)整實例，保持吞吐與延遲表現(xiàn)穩(wěn)定。

這種精細化協(xié)同能力，將復雜分布式推理服務作為統(tǒng)一生命周期的整體進行管理，極大降低運維復雜度。

  template: ...

3.3.3 Orchestration (編排)：編排化的角色與服務發(fā)現(xiàn)

RBG 顯式定義角色依賴與精確啟動順序，實現(xiàn)編排化管理。更關(guān)鍵的是，它提供拓撲自感知的內(nèi)建服務發(fā)現(xiàn)，在 Pod 啟動時將完整拓撲信息（各角色 IP、屬性、關(guān)系等）注入環(huán)境變量或配置文件。

推理引擎（SGLang、vLLM 等）可直接從本地配置讀取拓撲視圖，無需依賴 etcd、Consul 等外部服務發(fā)現(xiàn)系統(tǒng)，使服務跨環(huán)境遷移更自包含，顯著降低集成復雜度。

3.3.4 Performance (性能)：拓撲感知的高性能調(diào)度

單次請求的延遲與吞吐高度依賴硬件拓撲與資源親和性。RBG 引入拓撲感知的裝箱策略，支持多維度性能優(yōu)化：

• GPU 拓撲優(yōu)先級（如GPU-NVLink > PCIe > RDMA > VPC）；

• 角色之間的親和與反親和約束；

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

• 部署完成后的短路讀優(yōu)化。

通過這些約束與策略，RBG 在大規(guī)模部署時，能夠在不犧牲穩(wěn)定性的前提下，盡可能貼合最優(yōu)的硬件拓撲，從而保障 TTFT、TPOT 等關(guān)鍵性能指標。

3.3.5 Extensible (可擴展)：面向變化的部署抽象

RBG 通過聲明式 API（RBG、RBGs、EngineRuntimeProile等）與插件化機制，將 "角色關(guān)系定義"與"部署 / 模型管理 / 彈性策略"解耦 。

當社區(qū)演進出新架構(gòu)（如新路由層形態(tài)、分離式架構(gòu)等時），無需修改 RBG 核心代碼，只需通過 YAML 定義新角色模板與關(guān)系，即可快速落地。這種"聲明式 API + 插件機制"的平臺化設(shè)計，將新架構(gòu)的投產(chǎn)周期顯著縮短。

  ...

RBG 通過 Kubernetes 原生 API ，為大模型推理服務提供了一套穩(wěn)定（Stable）、協(xié)同（Coordination）、可編排（Orchestration）、高性能（Performance）、可演進（Extensible）的統(tǒng)一承載層，是面向現(xiàn)代 LLM 推理工作負載的一種新型部署與運維抽象。

基于RBG部署PD分離架構(gòu)+Mooncake

推理服務

4.1. 部署架構(gòu)

通過 RoleBasedGroup 可部署高可用、彈性的 SGLang PD 分離推理系統(tǒng)，核心組件如下：

整個系統(tǒng)由以下核心角色構(gòu)成：

• SGLang Router：作為統(tǒng)一的請求入口與流量調(diào)度器，負責接收用戶推理請求，根據(jù)負載狀態(tài)、上下文長度和模型配置，智能為請求選擇合適的Prefill 和 Decode 節(jié)點進行處理。

• Prefill Serving Backend：專用于處理提示詞（prompt）的前向計算，生成初始 KVCache；通常為計算密集型，對顯存帶寬敏感。

• Decode Serving Backend：專注于自回歸生成階段的 token 逐個解碼，依賴已生成的 KVCache 進行高效推理；對緩存訪問延遲極為敏感。

• Mooncake Master/Store：作為獨立的 KVCache 外置存儲角色，提供高吞吐、低延遲的分布式緩存服務，持久化存儲所有推理會話的 Key-Value Cache。它不僅突破了單 GPU HBM 和 CPU DRAM 的容量限制，還支持跨請求緩存復用以及細粒度緩存淘汰策略（如 LRU + 高水位驅(qū)逐）。

這些角色并非孤立運行，而是通過 RBG 提供的原生多角色協(xié)同能力緊密集成。此外，EngineRuntime 作為 RBG 注入給引擎服務 Pod 的 Sidecar，成為推理引擎與上層編排系統(tǒng)的橋梁，提供了服務注冊與元數(shù)據(jù)上報、動態(tài) LoRA 加載 / 卸載、流量狀態(tài)控制和可觀測性集成的關(guān)鍵的運行時能力。

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 中涉及的環(huán)境變量說明可以參考：https://github.com/kvcache-ai/Mooncake/blob/main/doc/zh/mooncake-store.md

• 查看部署結(jié)果：

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

• 查看 Mooncake Store 角色其中一個實例的網(wǎng)絡(luò)和 location 信息：

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

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

多輪對話場景測試表明，多級緩存架構(gòu)對 KVCache 命中率與推理性能提升至關(guān)重要：

• Baseline（僅 GPU 顯存）：緩存命中率低，平均 TTFT 5.91s，P90 12.16s，系統(tǒng)吞吐受限，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 指標

測試細節(jié)詳見附錄 8.2

通過原地升級能力實現(xiàn)

Mooncake 版本平滑升級

由于 Mooncake 內(nèi)置的 transfer-engine 與 SGLang Serving Backend（Prefill/Decode）中的 transfer-engine 需保持嚴格版本一致，以確保 KVCache 傳輸協(xié)議的兼容性，因此在推理引擎升級時，Mooncake 需要同步進行版本更新。

然而，Mooncake 作為有狀態(tài)的緩存服務，其 KVCache 數(shù)據(jù)通常僅駐留在內(nèi)存中。在傳統(tǒng) Kubernetes 滾動升級（Rolling Update）過程中，舊 Pod 被終止時，其內(nèi)存中的緩存數(shù)據(jù)會立即丟失；而新 Pod 啟動后需要經(jīng)歷重新調(diào)度、重新創(chuàng)建的過程。這導致所有依賴該節(jié)點緩存的活躍推理會話被迫中斷，必須重新執(zhí)行完整的 Prefill 計算——這一過程不僅計算開銷巨大，還會引發(fā)：

• P99 首 Token 延遲顯著毛刺（從秒級飆升至數(shù)十秒）；

• 因大量請求排隊等待 Prefill，導致的系統(tǒng)吞吐量斷崖式下跌；

• 用戶體驗劇烈抖動，破壞生產(chǎn)環(huán)境的服務穩(wěn)定性。

解決方案：Mooncake 緩存本地持久化 + RBG 原地升級：

• Mooncake 緩存本地持久化：在 Mooncake 社區(qū)的 PR 中，mooncake 支持在節(jié)點 ShareMemory 和本地磁盤（或高性能 NVMe）上將 KVCache 元數(shù)據(jù)與熱數(shù)據(jù)快照持久化，確保進程重啟后可快速恢復緩存狀態(tài)，避免緩存失效導致的 Prefill 重計算；

• RBG 原地升級：通過 RBG 的精細化角色控制能力，在升級 Mooncake 角色時避免重建 Pod，而是原地替換容器鏡像并復用節(jié)點的本地盤或共享內(nèi)存，從而保留已持久化的緩存數(shù)據(jù)，實現(xiàn)“無縫”版本切換。

二者結(jié)合，使得在 Serving Backend 與 Mooncake 聯(lián)合升級過程中，KVCache 狀態(tài)得以延續(xù)，活躍會話無需回退到 Prefill 階段，從而有效規(guī)避了延遲毛刺與吞吐下跌，保障了大模型推理服務在版本迭代期間的端到端穩(wěn)定性與高可用性。

換言之，RBG 不僅解決了多角色協(xié)同部署的復雜性，更通過原地升級，將“有狀態(tài)緩存服務的平滑演進”這一行業(yè)難題轉(zhuǎn)化為標準化、可自動化的運維能力，真正實現(xiàn)了 “升級無感、服務不抖” 的生產(chǎn)級目標。

我們對剛剛部署的服務進行引擎版本的更新，由 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 狀態(tài)能發(fā)現(xiàn)，在 Mooncake Store 角色鏡像版本更新后僅發(fā)生了一次容器的重啟。

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 實例狀態(tài)可以發(fā)現(xiàn)，在原地升級后 Pod 的網(wǎng)絡(luò)和拓撲信息并沒有發(fā)生改變，配合 Mooncake 提供的緩存持久化能力，可以保證重啟前的 KVCache 緩存并沒有發(fā)生丟失，在原地升級后預期地完成了恢復。

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

總結(jié)和展望

本文系統(tǒng)闡述了如何通過 RoleBasedGroup（RBG） 與 Mooncake 的協(xié)同設(shè)計，構(gòu)建生產(chǎn)級的穩(wěn)定高性能 PD 分離推理服務。結(jié)論如下：

• RBG 重新定義了 LLM 推理服務的編排范式：通過將多角色協(xié)同（PD 分離、Mooncake 緩存）與拓撲感知調(diào)度作為一等公民，RBG 不僅解決了分布式部署的復雜性，更通過原地升級能力攻克了"有狀態(tài)緩存服務平滑演進"這一行業(yè)難題，實現(xiàn)了升級無感、服務不抖的生產(chǎn)級目標。

• Mooncake 解鎖了 KVCache 的無限可能：作為 L3 緩存層，Mooncake 通過分布式內(nèi)存池與 RDMA 加速，使緩存命中率躍升，TTFT 降低 56.3%，P90 延遲改善 42.7%，同時將 GPU 平均利用率從不足 30% 提升至可持續(xù)彈性伸縮的水平，真正平衡了性能與成本。

• 分級緩存架構(gòu)是長上下文推理的必由之路：從 GPU HBM → DRAM → Mooncake 的三級緩存體系，在 Benchmark 中證明了其有效性，尤其在多輪對話、RAG、AI Agent 等機器驅(qū)動場景中，緩存復用帶來的邊際成本遞減效應將愈發(fā)顯著。

RBG + Mooncake 的實踐表明，只有將高性能系統(tǒng)設(shè)計與云原生運維能力深度融合，才能讓大模型推理真正從"能用"走向"好用"，從"實驗室"走向"生產(chǎn)級"。我們期待與社區(qū)共同推進這一范式，為下一代 AI 基礎(chǔ)設(shè)施奠定基礎(chǔ)。

Acknowledgment

• 小紅書：孫偉祥、宋陽、熊峰
  

• 科大訊飛：楊彥波
  

• 趨境科技：楊珂
  

• Mooncake：馬騰、蔡尚銘
  

• 阿里云：一齋、柏存、東伝

附 錄

8.1 鏡像構(gòu)建

此本文所使用部署樣例中，我們可以直接使用 SGLang社區(qū)的官方容器鏡像 lmsysorg/sglang:v0.5.5（mooncake-transfer-engine >= 0.3.7），該鏡像已經(jīng)默認包含了 Mooncake 相關(guān)依賴。如果有定制化需求，可以參考鏈接中提供的 Dockerfile 自行構(gòu)建特定版本的Mooncake 鏡像：https://github.com/sgl-project/rbg/blob/main/examples/mooncake/Dockerfile.mooncake

8.2 Benchmark 測試

8.2.1 環(huán)境配置

8.2.2 測試方法

通過 HiCache 提供的多輪對話壓測工具模擬多輪對話場景，測試 KVCache 可重用場景下開啟了 L3 Mooncake + L2 Hicache 的推理服務，相對于僅開啟了 L2 Hicache 和不開啟 Hicache 的推理服務，在吞吐指標和 SLO 指標上的收益情況。

• 測試對象

• 測試命令

--enable-round-barrier

• 分組記錄：

會議預告

12 月 19～20 日，AICon 2025 年度收官站在北京舉辦�，F(xiàn)已開啟 9 折優(yōu)惠。

兩天時間，聊最熱的 Agent、上下文工程、AI 產(chǎn)品創(chuàng)新等等話題，與頭部企業(yè)與創(chuàng)新團隊的專家深度交流落地經(jīng)驗與思考。2025 年最后一場，不容錯過。

今日薦文

你也「在看」嗎？