# RBG：面向Kubernetes的LLM推理服务编排框架 > RBG（RoleBasedGroup）是一个Kubernetes API，专门用于编排分布式、有状态的AI推理工作负载，支持多角色协作和内置服务发现，特别适合Prefill/Decode分离等解耦架构的生产部署。 - 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm) - 发布时间: 2026-04-07T06:11:59.000Z - 最近活动: 2026-04-07T08:10:01.664Z - 热度: 143.0 - 关键词: Kubernetes, LLM推理, 云原生, AI基础设施, 分布式系统 - 页面链接: https://www.zingnex.cn/forum/thread/rbg-kubernetesllm - Canonical: https://www.zingnex.cn/forum/thread/rbg-kubernetesllm - Markdown 来源: ingested_event --- # RBG：面向Kubernetes的LLM推理服务编排框架\n\n## 背景：传统Kubernetes原语的局限\n\n随着大型语言模型推理服务规模的扩大，部署架构日益复杂。现代高性能LLM推理系统通常采用解耦架构——将Prefill（预填充）和Decode（解码）阶段分离到不同的GPU实例上，以实现更高的吞吐量和更低的延迟。此外，典型的推理服务还包含网关（Gateway）、路由器（Router）等多个角色，形成一个复杂的多角色拓扑结构。\n\n然而，传统的Kubernetes原生资源（如StatefulSet和Deployment）在设计之初并未考虑到这类工作负载的特殊需求。它们面临以下挑战：\n\n**多角色拓扑管理困难**：一个完整的推理服务由多个相互依赖的角色组成，传统方式需要分别管理多个Deployment或StatefulSet，缺乏统一的编排视图。\n\n**硬件拓扑敏感性**：LLM推理对GPU和网络拓扑极度敏感，NVLink、PCIe、RDMA等不同连接方式对性能影响巨大，传统调度器难以充分利用这些硬件特性。\n\n**原子性操作缺失**：部署、升级、扩缩容、故障转移等操作需要跨多个角色协调进行，传统方式缺乏这种原子性保证，容易导致服务中断或状态不一致。\n\n## RBG的核心理念：角色化组织\n\nRBG（RoleBasedGroup）项目提出了一种全新的抽象方式：将推理服务视为一个**基于角色的组织**（Role-based Group），而非松散的工作负载集合。它将服务建模为一个拓扑化的、有状态的、协调的多角色有机体，并作为单一单元进行管理。\n\n### 核心概念\n\n**Role（角色）**：RBG的基本调度和发布单元。每个角色（如Prefill、Decode、Gateway）拥有独立的规格、生命周期和策略。角色是原子性的调度编排单元，不同角色之间建立可配置的关系。\n\n**RoleBasedGroup（基于角色的组）**：一组共同构成一个逻辑服务的角色。RBG将单个推理服务视为一个拓扑化的、有状态的、协作的"角色有机体"，而不是孤立的Deployment集合。\n\n## SCOPE五大核心能力\n\n基于上述理念，RBG构建了名为SCOPE的五大核心能力：\n\n### Topology-aware Deterministic Operations（拓扑感知确定性操作）\n\nRBG通过唯一的RoleID注入和最小替换域原则，实现拓扑感知的确定性操作。这意味着在升级或扩缩容时，系统能够精确控制哪些Pod会被影响，最大限度地减少对服务可用性的冲击。\n\n### Cross-role Policy Engine（跨角色策略引擎）\n\nRBG内置强大的跨角色策略引擎，支持：\n- **部署配对**：确保不同角色实例之间的正确配对关系\n- **协调升级**：按依赖顺序平滑升级各角色\n- **联动恢复**：一个角色故障时，相关角色能够协同恢复\n- **协调扩缩容**：根据负载情况协调调整各角色规模\n\n### Role Dependency Management（角色依赖管理）\n\nRBG允许在RoleBasedGroup内定义角色依赖关系和精确的启动顺序。例如，可以指定Decode角色必须在Prefill角色就绪后才能启动，Gateway必须在所有后端就绪后才能接收流量。\n\n### Topology Self-aware Service Discovery（拓扑自感知服务发现）\n\nRBG将完整的角色拓扑信息注入到Pod中，消除了对外部服务发现的依赖。每个Pod都能感知到整个服务的拓扑结构，知道如何与其他角色通信，这大大简化了服务配置并提高了可靠性。\n\n### Topology-aware Placement（拓扑感知放置）\n\nRBG实现了智能的拓扑感知放置策略，考虑硬件亲和性（GPU-NVLink > PCIe > RDMA > VPC）和角色亲和性调度。这确保了对性能敏感的角色能够被放置在最合适的硬件上，并与其他相关角色保持最优的网络连接。\n\n## 面向未来的部署抽象\n\nRBG采用声明式API和插件机制，具备面向未来的部署抽象能力。当新的推理架构出现时（如新的解耦模式、新的硬件类型），RBG能够在数周内适配，而无需重构整个系统。这种设计哲学使RBG成为一个可持续演进的平台，能够跟上AI推理技术快速发展的步伐。\n\n## 版本兼容性与生态系统\n\nRBG与Kubernetes生态系统保持良好的兼容性：\n\n| RBG版本 | Kubernetes版本 | LeaderWorkerSet版本 |\n|---------|---------------|---------------------|\n| main | >=v1.28.x | >=v0.7.0 |\n| v0.4.0 | >=v1.28.x | >=v0.7.0 |\n| v0.3.0 | >=v1.28.x | >=v0.6.0 |\n\n项目积极借鉴了Kubernetes社区的优秀实践，并复用了LeaderWorkerSet（LWS）项目的部分代码，体现了开放协作的精神。\n\n## 应用场景\n\nRBG特别适合以下场景：\n\n**大规模生产部署**：需要管理数十甚至数百个GPU实例的LLM推理服务，RBG的统一编排能力能够显著降低运维复杂度。\n\n**解耦架构**：采用Prefill/Decode分离、投机解码（Speculative Decoding）等先进架构的服务，RBG的跨角色协调能力能够确保各组件高效协作。\n\n**多租户环境**：需要为不同模型或不同用户组隔离资源的环境，RBG的角色抽象使得资源划分和隔离更加清晰。\n\n**混合云部署**：跨越多个可用区或云提供商的部署，RBG的拓扑感知能力能够优化跨区域的流量路由和故障转移。\n\n## 社区与贡献\n\nRBG项目采用开放的社区治理模式，欢迎通过Issue和Pull Request参与贡献。项目遵循Kubernetes社区的行为准则，维护者在Slack频道提供支持。这种开放的姿态有助于项目快速迭代，并确保其设计符合广泛的实际需求。\n\n## 结语\n\nRBG代表了Kubernetes上AI推理服务编排的重要进步。通过引入角色化组织的抽象，它解决了传统原语难以应对的多角色协调、拓扑感知、原子性操作等挑战。随着LLM推理服务规模的持续增长和架构的日益复杂，RBG这类专门化的编排工具将成为生产环境的标配。对于正在构建或扩展LLM推理基础设施的团队来说，RBG值得认真评估和采纳。