在 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）：声明角色副本数、启动依赖、扩缩容策略。

yaml 复制代码

apiVersion: rbg.sglang.ai/v1alpha1
kind: RoleBasedGroup
metadata:
  name: deepseek-r1-pd
spec:
  roles:
    - name: prefill
      replicas: 4
      templateRef: prefill-h100
    - name: decode
      replicas: 8
      templateRef: decode-a100
  startupOrder:
    - ["prefill"]   # 第一阶段
    - ["decode"]    # 第二阶段

RBG 控制器按 DAG 顺序创建角色，确保依赖就绪后再启动下游。

关键能力

按角色精细扩缩容

支持单独调整 prefill 或 decode 副本数，RBG 自动更新服务发现。
优雅生命周期管理
- 缩容前调用推理引擎的 /drain 接口，排空请求；
- 滚动升级支持分批、暂停、最大不可用数控制。
自动服务发现

为每个角色创建 Headless Service，并通过环境变量注入对端地址列表，例如：
env 复制代码
```
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 CR
           v
+----------+----------+
|    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 以重建缓存。

恢复策略配置

yaml 复制代码

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 分离架构真正 "跑得稳、管得住、弹得准"。