文章核心观点 - 大模型推理服务（如DeepSeek-V4 Flash）的部署正从单机转向复杂的分布式架构（如PD分离+大EP），但Kubernetes原生工作负载原语无法满足其多角色协作、拓扑敏感、快速可靠升级和故障联动等需求 [2] - 招商银行基于SGLang RBG组件，在国产AI芯片上成功落地了DeepSeek-V4 Flash大EP推理服务，重点解决了动态端口分配、服务发现、多级故障自愈与原地升级四大核心工程挑战 [2] 大EP部署的挑战 - 模型参数量达数百B级别，单机无法承载，需采用MoE架构并通过EP并行计算，同时将推理拆分为Prefill和Decode两个阶段，由Router统一调度，构成PD分离+大EP架构 [4] - 基于Kubernetes纳管异构算力卡时，其部署与运维的工程化复杂度远超传统无状态微服务 [4] 多角色拓扑的配置复杂度 - 大EP部署是三级嵌套拓扑结构：最外层是角色（Router、Prefill、Decode），中间层是每个角色的多个实例组，最内层是每个实例内的多个Worker Pod（如1个Leader + 15个Worker） [6] - Kubernetes原生Deployment和StatefulSet无法表达这种跨角色的拓扑依赖关系，导致需手动维护多组YAML配置并硬编码网络引用，运维复杂且易错 [6] - 以2 Prefill + 2 Decode部署为例，Router启动参数需硬编码32个Prefill和32个Decode端点地址，错误将导致服务异常 [7] hostNetwork下的端口管理 - 为满足Prefill和Decode间KV Cache传输对带宽和延迟的极高要求，需使用RDMA，这要求Pod以hostNetwork模式运行 [9] - hostNetwork模式带来同节点端口冲突问题，传统做法限制每个节点只跑一个推理Pod，牺牲了资源灵活性和弹性伸缩能力 [10] - 引入动态端口分配后，Router如何获知下游节点的实际端口成为新挑战，Kubernetes Service在hostNetwork模式下无法很好工作 [10] 服务发现的时序依赖 - 服务发现存在启动顺序依赖：EP并行要求同一实例内所有Worker必须同时就绪，Prefill和Decode需互相发现，Router需等待所有下游节点就绪 [12] - 地址解析存在竞态问题：若依赖启动时DNS查询，可能因目标Pod未就绪而解析失败或获取陈旧地址，在动态扩缩容场景下易引发级联启动失败 [12] 故障域的级联效应 - 故障传播呈三级级联特征：1) 实例内级联：集合通信库无容错能力，单个Worker故障可导致整个通信组不可用；2) 跨角色级联：Prefill和Decode间通过Bootstrap server和RDMA QP缓存建立连接，单个节点故障重启无法自动清理残留状态，需实例级整体重建；3) 重启风暴：局部故障可能引发连锁重启，导致服务SLA下降和恢复时间延长 [14][15][16] - Kubernetes原生的restartPolicy: Always无法应对这种多层级、跨组件的故障传播 [17] 异构AI芯片适配的复杂度高 - 适配复杂度高源于两点：1) 部署芯片的不确定性：为追求资源利用率，需动态选择部署目标，要求方案能兼容多种国产AI芯片；2) 资源变动引起的迁移：模型需能在不同国产AI芯片间灵活迁移，要求部署方案抹平底层硬件差异 [20] 升级的高昂代价 - 传统Kubernetes滚动更新对大模型推理代价极高：Pod重建需经历完整生命周期，对于DeepSeek-V4 Flash，仅模型加载就需要数分钟，且AI芯片资源重新调度存在不确定性 [21] - 存在跨角色版本一致性问题：Prefill和Decode间的数据传输协议可能因框架版本不同而不兼容，传统Deployment滚动更新无法保证两个独立工作负载的更新进度同步 [21] 方案选型：为什么是RBG - SGLang RBG是专为分布式推理工作负载设计的Kubernetes API扩展，核心抽象是“角色组” [23] - 选择RBG主要基于三点：1) 对“hostNetwork + 国产AI芯片 + PD分离”场景的工程化封装最完整，直接提供了动态端口分配、服务发现ConfigMap等能力；2) 支持原地升级语义，可在资源紧张的生产环境中保留调度位置和AI芯片绑定、只换镜像；3) 不侵入推理框架，轻量无依赖，部署成本低 [25][26] 基于RBG的部署实践 - 整体拓扑通过一个RoleBasedGroup CR统一定义和管理三个角色（Router、Prefill、Decode），Controller自动完成端口分配、服务发现ConfigMap生成及故障自愈重建 [27] - 部署配置示例：Router组1个实例，Prefill组2个实例，Decode组2个实例，每个实例跨16张NPU [30] - 引入动态端口分配和服务发现机制后，运维人员只需关注业务语义配置，极大降低了运维工作量 [31] 生产注意事项 - RDMA网络要求：需确保RDMA设备正确挂载到容器中 [33] - 健康检查配置：为每个推理Pod配置readinessProbe（判断模型加载完成）和livenessProbe（检测服务卡死），RBG自愈机制依赖这些Probe [33] - PID 1与信号传播：建议引入tini或使用exec启动，确保信号正确转发和孤儿进程回收，这是实现原地升级优雅停流的前提 [34][35] 高级特性：动态端口分配 - RBG Controller引入全局端口分配器，采用随机分配+范围隔离策略，解决hostNetwork模式下的端口冲突和发现难题 [37][38] - 采用两级作用域设计：RoleScoped端口（角色内一致）和PodScoped端口（每个Pod不同），Controller将分配的端口以环境变量形式注入容器 [39] - 支持跨Pod端口引用，Controller自动解析引用并注入环境变量，使同一节点可调度多个推理副本，支持超分和弹性伸缩 [40][41] 高级特性：服务发现与EngineRuntime - RBG通过三层递进机制解决服务发现难题：1) 环境变量注入；2) 拓扑ConfigMap（挂载到/etc/rbg/config.yaml）；3) 组件级发现（通过annotation声明引用） [44][45] - 通过ClusterEngineRuntimeProfile CRD实现运行时配置（如驱动初始化、设备挂载）与推理服务定义的解耦，便于硬件适配 [46][47] - EngineRuntime机制提供统一服务注册和Metrics归一化能力，通过注入Sidecar实现，使服务注册不依赖外部中间件，并使不同推理引擎的指标命名标准化，简化监控和弹性伸缩配置 [48][49][50][51][52] 高级特性：多级故障自愈 - RBG在RoleInstance级别实现重启策略，默认策略是当实例中任一Pod故障时，整个实例的所有Pod一起重建，以应对故障的级联传播 [57][60] - 设计防级联保护机制，通过双层守卫（内存LRU缓存和API Server持久化Condition）防止故障引发集群重启风暴 [61] - 通过CoordinatedPolicy CRD管理跨角色协调，确保在滚动更新或扩缩容时，Prefill和Decode保持步调一致，防止版本不兼容 [62] 高级特性：原地升级 - 传统Pod重建升级代价高：模型加载需数分钟，且AI芯片资源调度存在不确定性 [63] - RBG原地升级核心思路是只替换容器镜像，保持Pod的调度位置、IP地址、挂载卷不变，显著缩短升级时间 [64] - 提供三种更新策略：RecreatePod（传统方式）、InPlaceIfPossible（优先尝试原地升级，无法则降级，推荐生产策略）、InPlaceOnly（强制原地升级） [67][68] - 升级流程包含宽限期（Grace Period）用于优雅停流，并通过ImageID变化精确判断完成状态 [69] - 生产收益：将SGLang从0.5.8升级到0.5.9时，单实例升级耗时从5-8分钟缩短至3-4分钟，整体升级时间和服务影响窗口显著缩短 [72] 实践成效与局限性 - 主要改善：部署配置量减少约90%，突破单节点单实例限制，故障恢复时间（MTTR）缩短一个数量级，框架升级耗时缩短约40%且更可预测，引擎/算力卡切换时上层配置零改动 [73] - 局限性：端口分配存在理论冲突风险，服务发现存在短暂不一致窗口，原地升级能力目前仅支持容器镜像变更，跨角色故障联动依赖推理框架自身支持 [78] 行业趋势与展望 - LLM推理基础设施正从“单一框架+单一硬件”向“多框架+多硬件+多拓扑”的异构集群演进 [74] - RBG将“角色”作为基本编排单元，将“角色组”作为服务治理的原子粒度，该抽象足够通用，可适配PD分离、MoE分布式、Pipeline并行等多种推理架构 [74] - 后续工作方向：在RBG基础上增强弹性伸缩能力，以及持续参与上游社区建设 [74]