1. 为什么需要PD分离推理架构大模型推理过程中最头疼的问题就是资源利用率低。传统架构下一个GPU实例既要处理完整的prompt预填充Prefill又要负责逐token的解码Decode就像让一个厨师既要做食材预处理又要掌勺炒菜结果两边都顾不好。PD分离架构的精妙之处在于把计算密集型的Prefill阶段和显存敏感的Decode阶段拆分开。实测下来这种拆分能让A100的显存利用率从40%提升到75%以上。但拆分也带来了新问题——在K8s环境下如何确保Prefill Pod先启动如何让Decode Pod自动发现Prefill服务这就是RBG编排框架要解决的核心问题。2. RBG编排框架的设计哲学2.1 多角色服务的一站式管理K8s原生的Deployment有个致命缺陷它假设所有Pod都是无差别的副本。但PD分离架构中Prefill和Decode是两种完全不同的角色。这就好比把厨师和服务员混编在一个部门根本没法精细管理。RBG的解决方案很聪明它定义了RoleTemplate和RoleBasedGroup两个核心资源。我实际部署时是这样用的# 定义Prefill角色模板 apiVersion: rbg.sglang.ai/v1alpha1 kind: RoleTemplate metadata: name: prefill-h100 spec: containers: - name: llm-inference image: sglang/prefill:v1.2 resources: limits: nvidia.com/gpu: 1 # 定义Decode角色模板 apiVersion: rbg.sglang.ai/v1alpha1 kind: RoleTemplate metadata: name: decode-a10g spec: containers: - name: llm-inference image: sglang/decode:v1.2 resources: limits: nvidia.com/gpu: 12.2 启动顺序的DAG控制踩过坑的都知道如果Decode Pod先于Prefill启动整个服务就会报连接错误。RBG通过startupOrder字段实现了拓扑排序apiVersion: rbg.sglang.ai/v1alpha1 kind: RoleBasedGroup spec: startupOrder: - [prefill] # 第一阶段 - [decode] # 第二阶段这个设计让我想起机场的登机流程——必须等廊桥就位才能放乘客登机。RBG控制器会严格按这个顺序创建Pod实测启动成功率从原来的70%提升到了99.9%。3. 生产环境的关键优化策略3.1 智能扩缩容机制传统HPA基于CPU/内存指标根本不适合LLM推理。有次我们的Decode Pod CPU使用率才30%但请求队列已经积压了上百条。后来改用RBG的自定义指标才解决问题# 查看RBG暴露的pending_requests指标 kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/*/rbg_role_pending_requests建议配合KEDA配置这样的自动扩缩规则triggers: - type: kubernetes-workload metadata: podSelector: roledecode metricName: rbg_role_pending_requests targetValue: 53.2 零中断升级方案早期我们用原生Deployment做升级经常引发雪崩。RBG的滚动升级策略有几个实用功能maxUnavailable控制每次升级的Pod数量drainTimeout设置排空请求的超时时间pause支持中途暂停升级这是我常用的安全升级配置updateStrategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 drainTimeoutSeconds: 3004. 故障排查实战经验4.1 典型问题排查流程上周遇到Decode Pod频繁重启的问题我是这样排查的检查RBG事件日志kubectl describe rbg my-llm-service | grep -A 10 Events查看Prefill服务的网络连通性kubectl exec -it decode-pod -- curl -v http://prefill-svc:8080/health分析推理引擎的drain接口日志kubectl logs prefill-pod -c llm-inference | grep drain4.2 监控看板配置建议这几个监控指标必须配置告警prefill_latency 500msdecode_endpoints_available 90%kv_cache_rebuild_count 5/minGrafana看板可以这样配置sum(rate(rbg_role_processing_seconds_sum{roledecode}[1m])) by (pod) / sum(rate(rbg_role_processing_seconds_count{roledecode}[1m])) by (pod)5. 性能调优实战技巧5.1 GPU资源分配策略不同型号GPU的性价比差异很大。经过多次测试我们得出这样的配置原则角色GPU型号每Pod GPU数适用场景PrefillH1001长文本处理(4k tokens)DecodeA10G1高并发短文本(1k)RouterT40纯CPU负载均衡5.2 网络性能优化Prefill和Decode之间的网络延迟直接影响首token时间。我们通过以下手段将跨节点通信延迟从15ms降到3ms使用K8s的PodAffinity让关联Pod尽量同节点affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchLabels: rbg-role: prefill topologyKey: kubernetes.io/hostname启用RDMA网络插件调整内核网络参数sysctl -w net.core.rmem_max167772166. 与生态工具的集成方案6.1 与OME Operator的协作OME负责模型部署的高层抽象RBG处理底层编排这种分层设计特别实用。当我们需要部署新模型时只需要声明apiVersion: ome.ai/v1 kind: InferenceService spec: model: deepseek-v2 deploymentMode: Disaggregated rbgConfig: prefillReplicas: 4 decodeReplicas: 86.2 与KubeRay的对比有团队问过RBG和KubeRay的区别这里分享我的对比结论特性RBGKubeRay多角色支持原生设计需自定义CRD启动顺序控制内置DAG调度需外部协调服务发现自动注入环境变量手动配置扩缩容粒度角色级别整个集群适合场景确定性工作流弹性计算任务7. 实际部署的注意事项在三个不同规模的集群部署后我总结了这些经验资源预留Prefill Pod需要额外预留10%的CPU应对突发长文本版本兼容RBG Controller版本要与K8s版本严格匹配日志收集每个角色的日志要分开收集和分析熔断机制当Prefill延迟超过阈值时应自动拒绝新请求配置示例circuitBreaker: failureThreshold: 5 successThreshold: 2 timeoutSeconds: 308. 未来演进方向社区正在讨论的几个重要特性跨AZ的角色调度让Prefill和Decode可以跨可用区部署混合精度支持自动为不同角色选择FP8/FP16精度动态批处理根据负载自动调整批处理大小这些功能上线后我会第一时间在实际业务中进行验证。目前RBG已经在我们的客服问答系统稳定运行半年支撑日均百万级推理请求。