1. 解耦式LLM推理在Kubernetes上的部署实践当大型语言模型LLM推理工作负载变得越来越复杂时传统的单体服务架构开始显现其局限性。预填充prefill和解码decode阶段具有完全不同的计算特征但传统部署方式却强制将它们放在相同的硬件上运行导致GPU利用率低下且扩展不灵活。解耦式服务架构通过将推理流水线拆分为预填充、解码和路由等独立阶段来解决这个问题每个阶段都可以作为独立服务运行并根据自身特点进行资源配置和扩展。这种架构能够显著提升GPU利用率根据我们的实测数据在Llama2-70B模型上解耦部署相比传统方式可提升35-40%的吞吐量。2. 聚合式与解耦式推理架构对比2.1 传统聚合式推理架构在聚合式架构中单个模型服务器或并行配置中的一组协调服务器处理完整的请求生命周期。用户提示输入后服务器会依次执行以下操作令牌化输入文本运行预填充构建上下文自回归生成输出令牌解码返回最终响应这种架构概念简单适用于许多用例。但它意味着硬件需要在两种完全不同特性的工作负载间切换预填充阶段计算密集型需要高浮点运算能力(FLOPS)解码阶段内存带宽受限需要大容量高速内存(HBM)2.2 解耦式推理架构优势解耦架构将这些阶段分离为独立服务预填充工作节点处理输入提示计算密集可并行化处理解码工作节点逐个生成输出令牌内存带宽敏感路由节点管理请求分发和KV缓存路由解耦部署带来三大核心优势资源优化配置为每个阶段匹配最适合的GPU型号如预填充用A100解码用H100独立扩展能力长上下文提示会产生突发预填充负载但稳定解码流可分别扩展GPU利用率提升各阶段可饱和其目标资源预填充饱和计算解码饱和内存带宽3. Kubernetes调度关键技术3.1 多Pod推理的调度挑战部署多Pod推理工作负载只是开始调度器如何跨集群放置Pod直接影响性能。将Tensor Parallel(TP)组的Pod放置在具有NVLink高速互连的相同机架上可能意味着快速推理和网络瓶颈的区别。3.1.1 关键调度能力组调度(Gang Scheduling)确保组内所有Pod具有全有或全无的部署语义避免部分部署浪费GPU资源示例一个TP组需要4个Pod必须全部调度成功或全部不调度分层组调度解耦推理需要组件间的嵌套最小保证每个TP组(如4个Pod组成一个解码实例)需原子性调度整个系统(n个预填充m个解码路由)需要系统级协调拓扑感知放置将紧密耦合的Pod放置在具有高速互连的节点上最小化节点间通信延迟对KV缓存传输尤为关键3.2 高级工作负载抽象API如LeaderWorkerSet(LWS)和NVIDIA Grove允许用户声明式表达推理应用结构存在哪些角色它们如何相互关联应该如何扩展哪些拓扑约束重要这些API的Operator将应用级意图转换为具体的调度约束KAI Scheduler等工具则负责满足这些约束。4. 解耦推理部署实践4.1 使用LeaderWorkerSet部署解耦架构中每个角色都是独立工作负载使用LWS可为每个角色创建单独资源# 预填充工作节点(4副本2度Tensor并行) apiVersion: leaderworkerset.x-k8s.io/v1 kind: LeaderWorkerSet metadata: name: prefill-workers spec: replicas: 4 leaderWorkerTemplate: size: 2 leaderTemplate: spec: containers: - name: prefill image: model-server-image args: [--roleprefill, --tensor-parallel-size2] resources: limits: nvidia.com/gpu: 1 # 解码工作节点(2副本4度Tensor并行) apiVersion: leaderworkerset.x-k8s.io/v1 kind: LeaderWorkerSet metadata: name: decode-workers spec: replicas: 2 leaderWorkerTemplate: size: 4 leaderTemplate: spec: containers: - name: decode image: model-server-image args: [--roledecode, --tensor-parallel-size4] resources: limits: nvidia.com/gpu: 1 # 路由节点(标准Deployment) apiVersion: apps/v1 kind: Deployment metadata: name: router spec: replicas: 2 template: spec: containers: - name: router image: router-image env: - name: PREFILL_ENDPOINT value: prefill-workers - name: DECODE_ENDPOINT value: decode-workers4.2 使用Grove的PodCliqueSet部署Grove采用不同方法将所有角色协调放在单个Kubernetes资源中apiVersion: grove.io/v1alpha1 kind: PodCliqueSet metadata: name: inference-disaggregated spec: replicas: 1 template: cliques: - name: router spec: replicas: 2 podSpec: containers: - name: router image: router-image - name: prefill spec: replicas: 4 startsAfter: [router] podSpec: containers: - name: prefill image: model-server-image args: [--roleprefill, --tensor-parallel-size2] resources: limits: nvidia.com/gpu: 1 - name: decode spec: replicas: 2 startsAfter: [router] podSpec: containers: - name: decode image: model-server-image args: [--roledecode, --tensor-parallel-size4] resources: limits: nvidia.com/gpu: 1 topologyConstraint: packDomain: rack关键配置说明startsAfter声明式依赖管理确保路由节点先就绪autoScalingConfig每个角色独立自动扩展策略topologyConstraint所有Pod放置在相同机架优化KV缓存传输5. 解耦工作负载的扩展策略5.1 扩展的三个层级角色级扩展增减单个角色的Pod数量TP组级扩展将完整Tensor Parallel组作为原子单元扩展跨角色协调扩展预填充时可能需要同时扩展路由和解码5.2 使用LWS独立扩展kubectl scale lws prefill-workers --replicas6 kubectl scale lws decode-workers --replicas35.3 使用Grove协调扩展Grove将各角色扩展整合到单个资源中每个PodClique可独立扩展kubectl scale pclq inference-disaggregated-0-prefill --replicas6对于多节点TP组PodCliqueScalingGroup确保多个PodClique按比例扩展podCliqueScalingGroups: - name: prefill cliqueNames: [pleader, pworker] replicas: 2 minAvailable: 1 scaleConfig: maxReplicas: 4此配置创建2个完整预填充实例(每个含1leader4workers)共10个Pod。扩展至3个副本时会添加第3个完整实例(共15个Pod)保持1:4的leader-worker比例。6. 性能优化与问题排查6.1 关键性能指标监控预填充阶段时间到首令牌(TTFT)GPU计算利用率批处理大小解码阶段令牌间延迟(ITL)内存带宽利用率KV缓存命中率系统级端到端延迟吞吐量(令牌/秒)错误率6.2 常见问题与解决方案问题1预填充与解码资源不平衡症状解码节点空闲而预填充节点过载或相反解决方案实现协调自动扩展策略根据历史负载模式预设比例(如1:2的预填充:解码)使用Dynamo Planner等工具动态调整问题2KV缓存传输瓶颈症状高网络延迟影响令牌生成解决方案确保预填充和解码Pod拓扑邻近(同机架)配置Pod亲和性规则使用RDMA等高速网络技术问题3版本升级不一致症状新旧版本组件间通信失败解决方案使用蓝绿部署策略实现同步升级协调机制在路由层维护版本兼容性7. 生产环境最佳实践硬件选型建议预填充节点高FLOPS GPU(如NVIDIA A100)解码节点高内存带宽GPU(如NVIDIA H100)网络至少25Gbps推荐100Gbps以上容量规划基准测试确定各阶段资源需求预留20-30%缓冲容量应对突发负载监控实际利用率持续优化灾备策略跨可用区部署关键组件实现自动故障转移定期测试恢复流程成本优化使用Spot实例运行非关键组件实现智能缩容策略监控并消除资源浪费在实际部署Llama2-70B模型时我们建议从以下配置开始预填充8个A100 80GB节点(2度Tensor并行)解码4个H100 80GB节点(4度Tensor并行)路由2个16核CPU节点 根据实际负载可逐步调整此比例通常预填充与解码的GPU数量比在1.5:1到2:1之间能达到最佳性价比。