業界首次：DeepSeek-V4 基于國產AI芯片+SGLang RBG的云原生推理方案在招商銀行落地

作者 | 招商銀行信息技術部 - 架構管理團隊

技術方向 | AI 基礎設施、大模型推理優化

大模型推理正在從單機走向分布式集群和分離式架構，但 Kubernetes 原生的工作負載原語（Deployment、StatefulSet）并不是為"多角色協作、拓撲敏感、快速和可靠升級、故障聯動"的推理場景設計的。本文介紹招商銀行基于 SGLang RBG 組件，在國產 AI 芯片上落地 DeepSeek-V4 Flash 大 EP 推理服務的實踐，重點剖析動態端口分配、服務發現、多級故障自愈與原地升級四個核心機制的設計與實現。

問題：DeepSeek-V4 國產 AI 芯片大 EP 部署的挑戰

當模型參數量達到數百 B 級別，單機已無法承載完整的推理計算。以 DeepSeek-V4 Flash 為例，它采用 MoE（Mixture of Experts）架構，專家參數分布在多張卡上通過 EP（Expert Parallelism）并行計算；同時，為了提升吞吐和降低延遲，業界通常將推理過程拆分為 Prefill（預填充）和 Decode（解碼）兩個階段，分別由不同的實例組承擔，再通過 Router 統一調度請求——這就是所謂的 PD 分離 + 大 EP 架構。

這個架構在算法和系統層面已經成熟，但在基于 Kubernetes 納管異構算力卡時，其部署與運維面臨的工程化挑戰，在復雜度上遠超傳統的無狀態微服務。以下，我們將這些痛點按層次進行系統性剖析。

多角色拓撲的配置復雜度

大 EP 部署本質上是一個三級嵌套的拓撲結構：最外層是角色（Router、Prefill、Decode），中間層是每個角色的多個實例（如 2 個 Prefill 實例組），最內層是每個實例內的多個 Worker Pod（如一個 Prefill 實例跨 16 張 AI 芯片，由 1 個 Leader + 15 個 Worker 組成）。

傳統 Kubernetes 的工作負載原語無法自然表達這種結構：Deployment 是無狀態的，不支持 Pod 間的拓撲關系；StatefulSet 只管理單一角色的有序副本，無法表達跨角色的依賴。因此運維人員不得不手動維護三組獨立的 YAML 配置，并在其中硬編碼角色間的網絡引用關系——Router 的啟動命令里要列出所有 Prefill 和 Decode 的地址，Prefill 的配置里要寫明數據傳輸對端 Decode 的地址。

以一個 2 Prefill + 2 Decode 的部署為例，僅 Router 的啟動參數中就需要寫入 32 個 --prefiller-hosts 和 32 個 --decoder-hosts 條目（每個實例 16 張卡各一個端點）。這些地址一旦寫錯或遺漏，輕則部分專家不可達導致推理精度下降，重則整個服務無法啟動。

hostNetwork 下的端口管理

在大 EP 部署中，Prefill 和 Decode 之間的 KV Cache 傳輸對帶寬和延遲極其敏感，通常需要使用 RDMA 實現高速數據通道。這要求 Pod 以 hostNetwork: true 模式運行，直接使用宿主機網絡棧。

hostNetwork 模式帶來兩個層面的端口管理問題：

第一是同節點端口沖突。每個推理 Pod 至少需要占用 3-4 個端口（HTTP API 端口、gRPC 通信端口、數據傳輸端口、指標暴露端口）。如果調度器將兩個推理 Pod 放在同一節點上，硬編碼的端口號必然沖突。傳統做法是通過 nodeSelector 或反親和性保證每個節點只跑一個推理 Pod，但這犧牲了資源靈活性和彈性伸縮能力。

第二是跨角色的端口發現。即使端口不沖突，Router 也需要知道每個 Prefill/Decode Pod 實際監聽的端口號。在端口硬編碼的方案下這不是問題，但一旦引入動態端口分配（解決沖突后的必然選擇），Router 如何獲知每個下游節點的端口就成了新的挑戰——傳統的 Kubernetes Service 在 hostNetwork 模式下并不能很好地工作。

服務發現的時序依賴

即便不考慮端口問題，大 EP 部署中的服務發現本身也比普通微服務復雜得多。

首先是啟動順序依賴。EP 并行要求同一實例內的所有 Worker 必須在通信組建立階段（HCCL/NCCL init）同時就緒；Prefill 和 Decode 節點需要互相發現后才能建立 KV Cache 傳輸通道；Router 則需要等待所有下游節點就緒后才能正確路由。這些依賴關系不是簡單的"先啟動 A 再啟動 B"，而是多層嵌套的拓撲感知。

其次是地址解析的競態問題。若節點間的地址發現依賴啟動腳本執行 DNS 查詢（如 getent hosts），會面臨明顯的時序風險：Kubernetes 中 DNS 記錄的刷新依賴目標 Pod 變為 Ready 狀態。如果查詢發生在目標 Pod 就緒之前，將導致解析失敗或獲取到陳舊（Stale）地址。在 Pod 動態擴縮容或漂移重啟場景下，這種競態條件極易引發節點的級聯啟動失敗。

故障域的級聯效應

大 EP 架構中的故障傳播路徑比單體服務復雜得多，呈現出三級級聯的特征（如：NPU 場景下集合通信庫為 HCCL，GPU 場景下對應 NCCL，下文統稱"集合通信庫"）：

實例內級聯。一個 EP 實例（如 Prefill-0）由多個 Worker Pod 組成，它們通過集合通信庫（HCCL/NCCL）建立 communicator 協同計算。這類集合通信庫本身不具備容錯能力——任何一個 Worker 故障都會導致 collective 操作阻塞或失敗，整個通信組進入不可用狀態，且原生不支持單 rank 的 "hot rejoin"。Kubernetes 原生的 Pod 級重啟只會重啟出問題的那個 Worker，但它重啟后需要與其他 Worker 一起銷毀舊 communicator 并重新建組——如果其他 Worker 不感知到這次中斷并配合重置狀態，通信組將無法恢復，重啟的那個 Worker 也只能空轉。

跨角色級聯。Prefill 和 Decode 之間通過 Bootstrap server 注冊會話、并基于 RDMA 建立 KV Cache 傳輸通道。需要強調的是，這里的對端關系不是靜態 1:1 配對的——Router 按請求維度動態選擇 Prefill/Decode 組合，真正"持有狀態"的是 Bootstrap server 的會話注冊表和 Transfer engine（如 Mooncake、NIXL）的 RDMA QP 緩存。當一個 Decode 實例故障重啟后，即使它自身的推理服務恢復了：

• Bootstrap server 上殘留的舊 worker 注冊記錄、Transfer engine 上殘留的 RDMA QP 握手緩存，不會隨 Pod 重啟而自動清理；

• 其他 Prefill 實例新發起的 KV 傳輸會因為會話 ID 不匹配或 QP 失效而失敗，表現為"對端在線但傳輸始終建立不起來"；

• 更上游的 Router 如果不感知 Decode 的狀態變化，還會繼續將新請求路由到這條已經失效的鏈路上。

這意味著單獨重啟 Decode Pod 并不能真正恢復服務——必須讓相關組件一起清理會話狀態，這也是后文采用"實例級整體重建"而非"Pod 級重啟"的根本原因。

重啟風暴。在上述級聯效應下，如果每個節點都配置了簡單的健康檢查 + 自動重啟策略，理論上存在 A 節點故障 → B 節點通信超時 → B 的健康檢查失敗觸發重啟 → C 節點失去 B 的連接被判定不健康 → C 也被重啟…… 這樣的級聯路徑。實際生產中是否會真的"全集群崩"取決于健康檢查閾值、退避策略、PDB 等配置；更常見的表現形式是"局部反復重啟 + 容量持續抖動"——服務沒有完全死掉，但故障窗口內 SLA 已經塌了，且每一輪重啟都會觸發新一輪的會話狀態殘留與 Router 路由表錯配，使得故障恢復時間被進一步拉長。

Kubernetes 原生的restartPolicy: Always只能重啟單個容器，完全無法應對這種多層級、跨組件的故障傳播。

異構 AI 芯片適配的復雜度高

在異構的國產算力集群上，大 EP 部署也面臨較高的適配復雜度，主要源于兩點：

部署芯片的不確定性：為追求極致的資源利用率，會采取“擇優部署”策略，即根據模型在不同芯片上的性能與精度表現來動態選擇部署目標。這就要求部署方案必須能夠兼容并適配多種國產 AI 芯片。

資源變動引起的遷移：生產環境里的資源經常調整，模型需要能靈活地在不同的國產 AI 芯片之間遷移。這就要求部署方案不再依賴具體的硬件配置，抹平底層差異，讓模型換到某一類卡都能正常跑。

升級的高昂代價

推理框架版本迭代快，特別是對于 DeepSeek V4 的支持依然在收斂過程中，因此不論是 SGLang 還是 vLLM 都在不斷出新版本進行優化，但傳統的 Kubernetes 滾動更新對大模型推理而言代價極高。

一次標準的 Pod 重建（RecreatePod）需要經歷完整的生命周期：刪除舊 Pod → 釋放 AI 芯片資源 → 調度新 Pod → 等待 AI 芯片分配 → 拉取新鏡像 → 加載模型權重到顯存。對于 DeepSeek-V4 Flash 這樣的模型，僅模型加載就需要數分鐘。加上 AI 芯片資源的重新調度存在不確定性（如果節點資源被其他負載占用，新 Pod 可能長時間 Pending），單個實例的更新窗口難以預測。

更麻煩的是跨角色的版本一致性問題。Prefill 和 Decode 之間的數據傳輸協議可能因框架版本不同而不兼容。在滾動更新過程中，如果 Prefill 組已經全部升級到新版本，而 Decode 組還在用舊版本，就可能出現協議不匹配導致的傳輸失敗。傳統的 Deployment 滾動更新策略無法保證兩個獨立工作負載的更新進度同步。

方案選型：為什么是 RBG

SGLang RBG（RoleBasedGroup）是一個 Kubernetes API 擴展，專門為分布式推理工作負載設計。它的核心抽象是"角色組"——將 Router、Prefill、Decode 等角色定義為一個邏輯整體，由統一的控制面進行編排。

在確定方案前，我們做了兩層評估：第一層是"工作負載編排 API"，這類方案和 RBG 處在同一抽象層級，是真正意義上的候選；第二層是更上層的"推理服務平臺"（比如 AIBrix 等）。它們的關注點是"模型 + 路由 + 彈性 + 可觀測"的端到端產品化，此類平臺的代價是與某個推理引擎（如 vLLM）、某套模型管理范式或者硬件深度綁定，定位與 RBG 不同，不適合直接并列比較。

同層方案對比

最終選擇 RBG，我們主要看重了三點：

第一，面向"hostNetwork + 國產 AI 芯片 + PD 分離"場景的工程化封裝最完整。動態端口分配、服務發現 ConfigMap、EngineRuntime（服務注冊和 Metrics 歸一化的 sidecar 抽象）這幾件事，LWS/DisaggregatedSet 和 kthena 都沒有原生覆蓋，需要團隊自行擴展，且實現難度較大；RBG 把這些痛點直接變成了軟件能力。

第二，原地升級語義可用。在國產 AI 芯片資源緊張、模型加載耗時長的生產環境里，"保留調度位置和 AI 芯片的綁定、只換鏡像"是非常實際的需求。LWS / Kthena 目前都還停留在類似 StatefulSet 的重建式滾動更新，RBG 與 OpenKruise 是少數能拿出可用方案的項目。

第三，不侵入推理框架，輕量無依賴。RBG 工作在 Kubernetes 控制面，不修改 SGLang/vLLM 任何代碼，也不依賴額外的外部中間件，部署到已有 K8s 集群的成本幾乎為零。

生產實踐

本章節以在 NPU 生產集群中自動化部署 DeepSeek-V4 Flash 的大 EP 推理服務為例，詳細闡述如何基于 RBG 組件落地國產 AI 芯片的云原生推理方案。整體拓撲架構如下：

• Router 組：1 個實例，負責請求路由和負載均衡

• Prefill 組：2 個實例，每個實例跨 16 張 NPU 做 EP 并行

• Decode 組：2 個實例，每個實例同樣跨 16 張 NPU

三個角色通過一個 RoleBasedGroup CR 統一定義和管理。Controller 自動完成端口分配、服務發現 ConfigMap 生成、以及故障時的自愈重建。

以下為整體部署架構：

部署配置示例（以 SGLang 為例，可支持 vLLM）

                      --host 0.0.0.0

實踐初期，我們通過 getent hosts 解析 IP，并硬編碼端口列表的方式去獲取 IP 和端口。為了簡化運維并支持動態擴縮容，后來我們引入動態端口分配和服務發現機制（見高級特性章節），將所有的地址發現和端口管理都交給 Controller 處理。運維人員只需要關注業務語義層面的配置，例如"幾個 Prefill、幾個 Decode、用什么鏡像"等，極大地降低了運維工作量。

生產中的注意事項

在 NPU 環境下落地這套方案，有幾個實際碰到的問題值得分享：

第一，RDMA 網絡要求。跨機的 Prefill-Decode 數據傳輸依賴 RDMA 網卡。我們通過 hostNetwork: true + 端口動態分配解決了端口沖突問題，但需要確保 RDMA 設備正確掛載到容器中（通過 EngineRuntimeProfile 中的 device plugin 配置）。

第二，健康檢查配置。我們為每個推理 Pod 配置了 readinessProbe 和 livenessProbe。readinessProbe 用于判斷模型是否加載完成（模型加載可能需要數分鐘），livenessProbe 用于檢測推理服務是否卡死。RBG 的自愈機制依賴這些 Probe 來正確判斷 Pod 狀態。

第三，PID 1 與信號傳播。生產中啟動命令若采用sh -c "python3 ..."形式，此時容器內 PID 1 是 shell，推理進程是其子進程。POSIX shell 默認不會主動向子進程轉發 SIGTERM，導致 gracePeriodSeconds（原地升級中用于優雅停流的關鍵參數）期間推理進程實際上收不到優雅退出信號——寬限期一過，kubelet 直接 SIGKILL，長 Prefill 請求被一刀斬斷，原地升級承諾的"優雅停流"形同虛設；與此同時 fork 出的 HCCL/tokenizer 等子孫進程容易成為孤兒，可能仍持有 NPU 設備或 RDMA 端口，導致下一次重建出現 device busy 而啟動失敗，反過來觸發 RBG 的實例級重建，放大故障域。因此建議引入 tini 作為 PID 1，或在啟動腳本中以 exec 替換 shell 進程，確保信號正確轉發并完成孤兒進程回收——這是原地升級機制能否真正成立的前提。

高級特性深入剖析

動態端口分配

如前所述，hostNetwork 模式下的端口沖突和端口發現是大 EP 部署的基礎性難題。傳統做法要么人工規劃端口分配表（運維成本高且容易出錯），要么通過 nodeSelector 保證節點互斥（犧牲資源靈活性，無法彈性伸縮）。RBG 在 Controller 層提供了一套系統化的解決方案。

RBG 在 Controller 層引入了一個全局端口分配器（Port Allocator），采用隨機分配 + 范圍隔離的策略：

      }

分配流程如下：

1. Controller 在創建 RoleInstanceSet 時，從配置的端口范圍 [startPort, startPort + portRange) 中隨機選取端口，寫入 RoleInstanceSet 的 annotation（RoleScoped 端口）。

2. 創建 RoleInstance 時，為每個 Pod 獨立分配 PodScoped 端口，同樣寫入 RoleInstance annotation。

3. Pod 實際創建時，Controller 從 annotation 中讀取端口值，以環境變量的形式注入到容器中。

兩級作用域設計的考慮是：有些端口（如用于角色間通信的 bootstrap 端口）在整個角色內應保持一致，用 RoleScoped；有些端口（如 Pod 自身的 HTTP 服務端口）必須每個 Pod 不同，用 PodScoped。

跨 Pod 端口引用解決了另一個痛點——一個角色如何知道另一個角色分配到了哪個端口？通過 references 字段，Controller 會在創建 Pod 時自動解析 "prefill.leader.grpc" 這樣的引用，找到目標 Pod 的實際端口值并注入為環境變量。

在最初的部署方式中，端口是硬編碼在啟動命令里的：

  --disaggregation-bootstrap-port 34000

使用端口分配器后，啟動命令變為：

  --disaggregation-bootstrap-port ${BOOTSTRAP_PORT}

這個改變看似簡單，但它意味著我們可以安全地在同一節點上調度多個推理副本，支持超分和彈性伸縮，而不再受限于"一個節點只能跑一個推理實例"的約束。

服務發現與 EngineRuntime

前面分析了大 EP 部署中服務發現的兩個核心困難：啟動順序依賴和地址解析的時序競態。在原始方案中，節點間地址通過啟動腳本中的 DNS 查詢獲取：

export decode_0_ip=$(getent hosts decode-0.svc | awk '{print $1}')

這種方式的問題在于：DNS 解析發生在啟動時刻，如果目標 Pod 尚未就緒，解析會失敗或拿到舊地址；同時端口信息完全硬編碼，一旦引入動態端口分配就完全失效。RBG 通過三層遞進的服務發現機制系統性地解決了這些問題。

三層服務發現機制

第一層：環境變量注入。Controller 為每個 Pod 自動注入一組標準化環境變量，包括 RBG_GROUP_NAME、RBG_ROLE_NAME、RBG_ROLE_INDEX 等。對于 LeaderWorker 模式，還會注入 Leader 地址 RBG_LWP_LEADER_ADDRESS 和 Worker 索引。

第二層：拓撲 ConfigMap。Controller 維護一個全局的服務發現 ConfigMap，包含整個角色組的完整拓撲信息，并以 Volume 形式掛載到每個 Pod 的 /etc/rbg/config.yaml：

      # ...

推理引擎只需讀取這個文件就能獲得完整的集群拓撲，不再依賴啟動時的 DNS 解析，也天然適配動態端口。

第三層：組件級發現。對于同一個 RoleInstance 內的多組件場景（比如一個推理實例包含 leader 和多個 worker），RBG 支持通過 annotation 聲明組件間的地址和端口引用：

  }

Controller 會在 Pod 創建時解析這些引用，將實際地址和端口值注入為環境變量。

EngineRuntime 配置解耦：ClusterEngineRuntimeProfile 的作用

在實際部署中，不同的硬件平臺需要不同的運行時配置——驅動初始化腳本、設備掛載方式、監控 sidecar 等。RBG 通過 ClusterEngineRuntimeProfile 這個集群級 CRD 實現了運行時配置的復用：

        path: /usr/local/Ascend

角色定義中只需通過 engineRuntimes 字段引用 Profile 名稱，Controller 會自動完成 sidecar 和 init-container 的注入。當 Profile 更新時（比如升級驅動版本），Controller 可以根據配置的策略（NoUpdate 或 RollingUpdate）決定是否觸發 Pod 滾動更新。

這種設計使得硬件適配層與推理服務定義解耦——同一份推理服務 YAML 可以通過切換不同的 EngineRuntimeProfile 運行在不同的硬件上，而不需要修改業務配置。

EngineRuntime 的能力擴展：統一服務注冊與 Metrics 歸一化

上面介紹了 ClusterEngineRuntimeProfile 在硬件驅動注入方面的作用，但 EngineRuntime 的能力遠不止于此。在分布式推理場景中，不同的推理引擎（SGLang、vLLM 等）在服務注冊和指標暴露上各有一套實現，這給多引擎混合部署帶來了顯著的集成復雜度。RBG 通過 EngineRuntime 機制提供了兩個關鍵的可擴展抽象層：統一服務注冊和 Metrics 歸一化。

統一服務注冊

在前面的服務發現機制中，介紹了 RBG Controller 為每個 Pod 注入環境變量（RBG_GROUP_NAME、RBG_ROLE_NAME、RBG_ROLE_INDEX 等）并掛載服務發現 ConfigMap（/etc/rbg/config.yaml）的機制。這些拓撲信息為服務注冊提供了基礎，但"如何將自己注冊到 Router"這個動作，則由 EngineRuntime 注入的服務注冊 Sidecar 來完成。

具體工作流程是：服務注冊 Sidecar 啟動后，讀取 Controller 注入的環境變量和 ConfigMap，獲取當前 Pod 的角色信息、實例索引和 Router 地址，然后主動調用 Router 提供的 Worker 注冊接口，將自己注冊為可用的推理節點。這種主動注冊模式相比被動發現有幾個顯著優勢：

第一，服務有效性保障更強。Worker 只有在真正就緒（模型加載完成、推理服務可響應）之后才會發起注冊，Router 收到注冊請求時即可確認該節點可以接收流量。不像被動發現模式下，DNS 或 Endpoints 更新可能先于服務實際就緒，導致 Router 將請求路由到未準備好的節點。

第二，不依賴任何 Kubernetes 資源或外部中間件。整個注冊過程是 Worker 與 Router 之間的直接通信，不需要 Consul、ZooKeeper、etcd 等服務注冊中心，也不依賴 Kubernetes Service 的 Endpoints 更新機制。這極大簡化了部署架構，減少了故障點。

第三，引擎無關的可擴展性。不同的推理引擎的注冊協議和接口各不相同——SGLang 有自己的 bootstrap 注冊流程，vLLM 通過 gRPC 服務發現。通過 EngineRuntime，用戶可以為每種引擎編寫對應的注冊 Sidecar 實現，封裝為獨立的 ClusterEngineRuntimeProfile。RBG 層面只關心"角色組"的編排語義，而"如何注冊到 Router"的具體實現則完全委托給 EngineRuntime Profile——切換推理引擎時，只需替換 Profile 即可，無需修改 RoleBasedGroup 配置。

Metrics 歸一化

另一個痛點是推理引擎的指標暴露不統一。SGLang、vLLM 等引擎在底層暴露的指標語義是一致的——都會報告吞吐量（tokens/s）、隊列深度、請求延遲、KV Cache 使用率、AI 芯片利用率等核心指標——但它們的 Prometheus Metric 命名卻各不相同。例如同樣是"當前排隊請求數"，SGLang 叫sglang_num_queue_reqs，vLLM 叫vllm:num_requests_waiting，Dynamo 叫dynamo_pending_requests。

這種命名差異帶來的后果是：Prometheus 的告警規則、Grafana Dashboard、以及基于指標的 HPA/Autoscaler 策略，都需要針對每種引擎單獨配置一套。當生產環境中同時運行多種引擎（或頻繁切換引擎版本）時，運維配置的復雜度會線性增長。

因此通過使用 EngineRuntime 注入一個 Metrics 歸一化 Sidecar 來解決這個問題。該 Sidecar 的職責是：從推理引擎的原生 Metrics 端點采集指標，按照統一的命名規范進行轉換，然后通過標準的 Prometheus 端口對外暴露。對上層的監控、告警和彈性伸縮系統而言，無論底層運行的是哪種推理引擎，看到的都是同一套指標名稱和語義。

這種設計同樣具備可擴展性。當需要支持一個新的推理引擎時，只需在 Metrics Sidecar 中增加該引擎的指標映射規則，封裝為對應的 ClusterEngineRuntimeProfile，上層的 Prometheus 配置、告警規則和 Autoscaler 策略完全不需要調整。

以下示例展示了一個典型的 EngineRuntime Profile，同時包含服務注冊和 Metrics 歸一化兩種能力：

          name: metrics      # 統一的 metrics 暴露端口

當需要切換到 vLLM 時，只需創建一個新的 Profile（如 vllm-engine-runtime），將 ENGINE_TYPE 設為 vllm，服務注冊 Sidecar 和 Metrics Sidecar 內部會根據引擎類型選擇對應的注冊協議和指標映射規則。角色定義中只需替換 engineRuntimes 引用的 profileName：

              image: registry.xxx/sglang:0.5.9

這種架構帶來了幾個實際價值：

1. 推理引擎可替換性——從 SGLang 切換到 vLLM 時，上層的監控、告警、彈性伸縮策略完全不受影響，因為它們對接的始終是統一的指標接口。

2. 服務注冊零依賴——不引入任何外部中間件，Worker 與 Router 直接通信完成注冊，架構簡潔、故障點少。

3. 平臺與業務分離——平臺團隊維護 Profile（服務注冊和 Metrics 歸一化的實現），業務團隊只需關注推理服務本身的配置。

多級故障自愈

前面分析了大 EP 架構中故障域的三級級聯特征：實例內的通信組斷裂、跨角色的連接狀態失效、以及全局的重啟風暴。Kubernetes 原生的 restartPolicy: Always 只能重啟單個容器，完全無法應對這種多層級的故障傳播。RBG 針對性地設計了實例級重啟策略和防級聯保護。

下圖對比了無 RBG 保護時的故障級聯傳播與 RBG 自愈機制的處理流程：

自愈模型

RBG 在 RoleInstance（角色實例）級別實現了重啟策略，默認策略是 RecreateRoleInstanceOnPodRestart——當實例中任何一個 Pod 故障或容器重啟時，整個實例的所有 Pod 會被一起重建。

具體的自愈流程：

└───────────────────────────────────────────────────────┘

防級聯保護是這個機制中最關鍵的設計。在分布式推理集群中，一個節點故障很容易引發連鎖反應——A 節點故障導致 B 節點通信超時，B 節點的健康檢查失敗觸發重啟，B 節點重啟又導致 C 節點異常……如果不加控制，整個集群可能在短時間內陷入重啟風暴。

RBG 通過雙層守衛防止這種情況：內存中的 LRU 緩存提供零延遲的判斷（避免 informer 緩存延遲導致的重復觸發），API Server 上的持久化 Condition 則確保 Controller 自身重啟后也不會重復執行。只有當實例完全恢復到 Ready 狀態后，守衛才會被清除。

組件依賴感知

對于多組件的 RoleInstance（比如 Leader-Worker 模式），重建時還需要尊重組件間的啟動依賴：

• 重建（Scale-out）階段：按依賴順序逐步創建組件，Leader 就緒后才創建 Worker。

• 銷毀（Scale-in）階段：按依賴的逆序刪除，先停 Worker 再停 Leader。

• 環檢測：如果依賴關系中存在環（通過 DFS 三色算法檢測），回退到并行模式避免死鎖。

跨角色協調

單個角色的自愈解決了實例級別的問題，但跨角色的協調同樣重要。RBG 通過 CoordinatedPolicy CRD 來管理跨角色的一致性：

          progression: OrderReady  # 當前批次全部 Ready 后才繼續下一批

這確保了在滾動更新或擴縮容時，Prefill 和 Decode 保持步調一致，不會出現"Prefill 已經全部更新到新版本，但 Decode 還在用舊版本"導致的協議不兼容問題。

原地升級

為什么推理服務需要原地升級

在傳統的 Kubernetes 滾動更新中，更新一個 Pod 意味著：刪除舊 Pod → 釋放 AI 芯片資源 → 重新調度新 Pod → 等待新 Pod 獲得 AI 芯片 → 拉取新鏡像 → 重新加載模型 → 服務就緒。對于大模型推理場景，這個過程的代價遠高于普通的 Web 服務：

首先是模型加載時間長。DeepSeek-V4 Flash 的模型權重超過數百 GB，從存儲加載到 AI 芯片顯存需要數分鐘。在這段時間內，該推理實例完全不可用。

其次是AI 芯片資源調度不確定。高性能計算資源是稀缺資源，刪除舊 Pod 后新 Pod 不一定能立即被調度到合適的節點——如果節點上的 AI 芯片 正好被其他工作負載占用，新 Pod 可能長時間處于 Pending 狀態。

最后是網絡身份變化。在使用 hostNetwork 的場景下，Pod 重建意味著 IP 可能改變，所有與之關聯的服務發現配置都需要更新，其他角色節點需要感知并重建連接。

理想的升級方式是：只替換容器鏡像，保持 Pod 的調度位置、IP 地址、掛載卷不變——這正是 RBG 原地升級的核心思路。

下圖對比了兩種升級方式的時間線差異：

三種更新策略

RBG 在每個角色的 rolloutStrategy 中提供了三種更新策略：

            gracePeriodSeconds: 30          # 流量排空寬限期

• RecreatePod：傳統方式，刪除舊 Pod 后創建新 Pod。適用于需要變更掛載卷、網絡配置等非鏡像字段的場景。

• InPlaceIfPossible：優先嘗試原地升級，如果變更內容超出原地升級的能力范圍（比如修改了 Volume 或新增了容器），自動降級為 RecreatePod。這是推薦的生產策略——兼顧效率與安全。

• InPlaceOnly：強制原地升級，如果變更無法原地執行則直接報錯。適用于對升級停機時間有嚴格要求、且能確保只做鏡像變更的場景。

原地升級的執行流程

當 Controller 檢測到角色模板發生變化時，會進入如下決策和執行流程：

└─────────────────────────────────────────────────────────────┘

這里有幾個設計細節值得關注：

寬限期（Grace Period）的意義在于優雅停流。在推理場景中，一個請求（尤其是長文本的 Prefill 階段）可能需要數十秒才能完成。如果不等待當前請求結束就直接重啟容器，用戶會收到中斷錯誤。通過設置合理的 gracePeriodSeconds，Controller 先將 Pod 標記為 Not Ready（不再接收新請求），等待已有請求處理完畢后再執行鏡像替換。

完成檢測不依賴"容器是否啟動"這樣的粗粒度信號，而是通過對比 ImageID 的變化來精確判斷——只有當 Kubelet 確實拉取并啟動了新鏡像后，ImageID 才會改變。這避免了因網絡抖動或鏡像拉取失敗導致的誤判。

防重復更新：Controller 在執行原地升級后會通過 updateExpectations 追蹤該操作，在 API Server 確認變更之前不會推進 CurrentRevision。這防止了因 informer 緩存延遲導致同一個實例被重復升級。

原地升級與跨角色協調

原地升級與前面提到的 CoordinatedPolicy 天然兼容。協調層只控制"多少個實例可以同時更新"，而不關心"用什么方式更新"。這意味著在跨角色協調場景下，Prefill 和 Decode 的原地升級也會受到 maxSkew 的約束——Controller 確保兩個角色的更新進度差異不超過配置的閾值，防止出現版本不兼容的狀態。

實際收益

在生產環境中，將推理框架從 SGLang 0.5.8 升級到 0.5.9 時：

傳統 RecreatePod 方式下，每個 Prefill 實例的更新需要經歷"Pod 刪除 → 重新調度 → 模型加載 → 就緒"的完整周期，單實例更新耗時約 5-8 分鐘。整個集群的滾動更新需要數十分鐘，期間服務容量持續受損。

使用 InPlaceIfPossible 策略后，Pod 的調度位置和 AI 芯片綁定關系保持不變，省去了重新調度的等待時間。雖然模型仍需重新加載（因為推理進程重啟），但消除了資源競爭的不確定性，單實例更新耗時穩定在 3-4 分鐘，整體升級時間和服務影響窗口顯著縮短。

效果與思考

目前，大 EP 推理服務的自動部署與自愈方案已在線上穩定運行，主要改善體現在以下幾個方面：

同時也有一些局限性值得坦誠面對：

• 端口分配存在理論沖突風險：采用隨機策略而非全局注冊，在端口范圍較小或 Pod 密度極高時存在沖突概率（實際中可通過設置足夠大的范圍來規避）。

• 服務發現存在短暫不一致窗口：ConfigMap 的更新依賴 Controller 的 Reconcile 周期，更新期間可能出現短暫的不一致。

• 原地升級能力有限：目前僅支持容器鏡像變更，如需修改 Volume 掛載或網絡配置，仍需走 RecreatePod 路徑。不過 InPlaceIfPossible 策略會自動處理降級，無需人工判斷。

• 跨角色故障聯動依賴框架自身：例如 Decode 故障后 Router 自動摘除對應節點，目前需要推理框架自身支持，RBG 尚未提供開箱即用的流量摘除能力。

從更大的視角看，LLM 推理基礎設施正在從"單一框架 + 單一硬件"演進為"多框架 + 多硬件 + 多拓撲"的異構集群。RBG 提供了一個合理的抽象層——將"角色"作為基本編排單元，將"角色組"作為服務治理的原子粒度——這個抽象足夠通用，可以適配 PD 分離、MoE 分布式、Pipeline 并行等多種推理架構。

我們后續的工作將圍繞兩個方向：一是在 RBG 基礎上增強彈性伸縮能力，根據實時負載自動調整 Prefill 和 Decode 的比例；二是持續參與上游社區建設，將生產中遇到的問題和解決方案回饋給開源項目。

會議推薦

企業級 Agent 落地，繞不開 4 個真實的工程問題！如何在 Agent 安全性和可用性之間找到平衡點？Agent 需要什么樣的記憶系統才能真正理解上下文？如何通過算法壓榨實現智力增量與成本控制的極致平衡？多 Agent 協作，如何做到可觀測、可治理、可控制？6.26-27 AICon 上海站，國內頭部公司的 Agent 實踐，一次說透。

今日薦文

你也「在看」嗎？