在 K8s 上可靠运行 PD 分离推理：RBG 的设计与实现
Prefill-Decode（PD）分离架构通过将大模型推理拆分为两个独立阶段——Prefill（预填充） 和 Decode（解码），实现了计算与显存资源的精细化调度。该架构在性能上优势显著，但其在 Kubernetes 生产环境中的落地，对平台的编排与运维能力提出了新要求。
本文将介绍 RBG（RoleBasedGroup） ——一个专为多角色推理服务设计的 Kubernetes 编排扩展，以及它如何与 OME Operator 协同，解决 PD 分离架构的生产级部署难题。
一、PD 分离带来的平台挑战
在 PD 分离架构中：
- Prefill 阶段：处理完整 prompt，计算密集，适合高算力 GPU（如 A100/H100）；
- Decode 阶段：逐 token 生成，依赖 KV Cache，对显存带宽敏感，通常需要更多实例。
这种拆分虽提升了资源利用率，但也引入了以下平台级问题：
| 问题 | 原因 | 影响 |
|---|---|---|
| 启动顺序不可控 | Prefill 必须先于 Decode 就绪 | Decode 启动后无法连接 Prefill，服务不可用 |
| 服务发现手动维护 | 角色间需直连通信 | 扩缩容后需人工更新地址配置 |
| 缩容中断请求 | 直接删除 Pod | 正在处理的推理失败，客户端需重试 |
| 升级导致缓存重建 | 滚动更新未排空请求 | 首请求延迟飙升，TPS 抖动 |
| 弹性指标失准 | HPA 基于 CPU/内存 | 无法感知推理队列积压，扩缩容滞后 |
这些问题的本质是：PD 分离服务是一个多角色、有状态、强协同的整体，而 Kubernetes 原生工作负载（Deployment/StatefulSet）仅面向单角色设计。
二、RBG：多角色推理服务的编排原语
RBG（RoleBasedGroup）是 SGLang 社区联合阿里云、小红书等团队开源的 Kubernetes CRD 项目（GitHub），目标是将多角色服务提升为 K8s 中的一等公民。
核心抽象
RBG 引入两个核心资源：
RoleTemplate：定义角色的 Pod 模板（容器、GPU、挂载等），支持跨 RBG 复用；RoleBasedGroup（RBG）：声明角色副本数、启动依赖、扩缩容策略。
apiVersion: rbg.sglang.ai/v1alpha1
kind: RoleBasedGroup
metadata:name: deepseek-r1-pd
spec:roles:- name: prefillreplicas: 4templateRef: prefill-h100- name: decodereplicas: 8templateRef: decode-a100startupOrder:- ["prefill"] # 第一阶段- ["decode"] # 第二阶段
RBG 控制器按 DAG 顺序创建角色，确保依赖就绪后再启动下游。
关键能力
-
按角色精细扩缩容
支持单独调整prefill或decode副本数，RBG 自动更新服务发现。 -
优雅生命周期管理
- 缩容前调用推理引擎的
/drain接口，排空请求； - 滚动升级支持分批、暂停、最大不可用数控制。
- 缩容前调用推理引擎的
-
自动服务发现
为每个角色创建 Headless Service，并通过环境变量注入对端地址列表，例如：DECODE_ENDPOINTS=prefill-0.rbg-svc,prefill-1.rbg-svc -
与平台生态集成
- 暴露自定义指标（如
rbg_role_pending_requests），供 KEDA 驱动弹性； - 兼容 Koordinator、OpenKruise 等高级调度器；
- 可作为 OME、AIBrix 等 LLM 平台的底层 workload。
- 暴露自定义指标（如
三、RBG 与 OME Operator 的集成
OME（Open Model Engine）是一个端到端的大模型服务平台，用户只需声明模型和运行时，OME 自动生成部署拓扑。
在 PD 分离场景下，OME 与 RBG 形成分层协作：
+---------------------+
| 用户 (User) |
+----------+----------+|| 提交 InferenceService CRv
+----------+----------+
| OME Operator | ← 高层控制面：模型驱动
+----------+----------+|| 若 deploymentMode == "Disaggregated"v
+----------+----------+
| RoleBasedGroup | ← RBG CR
+----------+----------+|| RBG Controller 创建v
+---------------------+
| Prefill Pods |
| Decode Pods | ← 底层工作负载
| Router Pods (可选) |
+---------------------+
- OME 负责：模型下载、运行时选择、GPU 数量规划、暴露 OpenAI 兼容 API；
- RBG 负责：多角色 Pod 的创建、顺序控制、弹性伸缩、升级策略。
这种分层设计使 OME 无需重复实现多角色编排逻辑，而 RBG 也可被其他平台复用。
四、故障恢复机制
当某个角色 Pod 异常时，RBG 提供两级恢复策略：
场景：Decode Pod 崩溃
- Kubernetes 触发
PodDeleted事件； - RBG Controller 检查
restartPolicy（默认为role）； - 仅重建该 Decode Pod，保留其他角色；
- 新 Pod 启动后，自动注入 Prefill 地址列表；
- 后续请求由 Router 路由到新实例，Prefill 重新发送 KV Cache。
注意：RBG 不负责 KV Cache 迁移（属推理引擎职责），但确保新实例能正确连接 Prefill 以重建缓存。
恢复策略配置
spec:restartPolicy: role # 仅重建故障角色（默认）# restartPolicy: group # 重建整个 RBG（强状态一致性场景）
该机制避免了全组重建带来的大规模缓存失效，将故障影响控制在最小范围。
五、生产实践建议
- 避免全组滚动更新：除非模型版本变更，否则应允许单角色升级；
- 必须实现 drain 接口：推理引擎需提供
/drain接口，确保preStop能真正排空请求； - 监控角色间延迟：Prefill → Decode 的通信延迟是关键 SLO，建议纳入告警；
- 限制 Decode 副本上限：过多实例会导致 Router 负载不均，建议结合动态负载均衡；
- 使用 KEDA 驱动弹性：基于
pending_requests指标扩缩容，比 CPU/内存更准确。
六、总结
RBG 的核心价值，在于为 “多角色、有状态、强协同” 的新型推理服务提供了标准化的 Kubernetes 编排原语。它不替代推理引擎，也不绑定特定平台，而是聚焦解决以下生产痛点：
- 多角色启动顺序不可控 → DAG 启动协调
- 扩缩容中断请求 → 优雅排空 + 按角色扩缩
- 服务发现手动维护 → 自动注入 endpoint
- 升级即雪崩 → 分批滚动 + 流量切换
目前 RBG 已在多个大规模 LLM 推理集群中稳定运行，代码完全开源：
- GitHub: https://github.com/sgl-project/rbg
- 文档: https://github.com/sgl-project/rbg/blob/main/doc/TOC.md
对于正在构建大模型推理平台的团队，RBG 提供了一种轻量、标准、可集成的方式，让 PD 分离架构真正 “跑得稳、管得住、弹得准”。