徐中虎-云原生大模型推理平台的企业级实践基于Kubernetes的分布式推理架构设计与优化.pdf

1、云原生大模型推理平台的企业级实践基于Kubernetes的分布式推理架构设计与优化徐中虎|华为云徐中虎CNCF TAG-Infra 技术负责人Istio 治理委员会成员华为云 主任工程师Kthena社区负责人CNCF TAG-Infra技术负责人，致力于帮助网络项目健康发展。Istio治理委员会成员，自2018年以来一直是Istio的核心维护者，也是Istio前三大贡献者。中虎是多个CNCF项目的维护者，包括Istio、Kmesh和Volcano等，也是Kubernetes前100名贡献者。拥有丰富的开源工作经验，主要研究方向有云原生、Kubernetes、容器、服务网格及分布式大模型推理。中

2、虎还是云原生服务网格Istio、Istio权威指南的联合作者。目 录CONTENTSI.LLM推理工作负载编排的痛点II.LLM网关的痛点III.云原生推理开源项目KthenaIV.Kthena的设计及实现V.总结与展望LLM推理工作负载编排的痛点PART 01LLM推理现状1.LLM推理不同于微服务，它是有状态应用。2.多种推理引擎vLLM，SGLang，Triton，TGI并存3.对于超大参数规模的模型，采用TP，PP，DP，EP等多种并行计算组合的方式多机部署4.PD分离架构对于大模型推理能够降低Prefill和Decode的相互干扰，显著提升吞吐和时延SLO5.PD分离架构，Prefi

3、ll和Decode角色需要KV Cache的传输PD分离架构：基于LWS封装LWS Operator 部署形态，顶层Operator+LWS，多组件维护成本高 调度策略配置复杂：顶层Operator需要感知LWS创建的子资源 尤其在PD分离场景下：假设创建两个LWS表示2P4D的部署架构。N个PD组，2*N个LWS表示Gang调度，两LWS协同，缺乏调度支持拓扑感知调度：同PD组的worker尽量部署在同一网络性能域（例如超节点），同一Prefill或者Decode角色组内的Worker，网络要求更严格。多层CR对象 Wrapper-LWS-Statefulset-PodPrefillLWSD

4、ecodeLWSWrapper OperatorLLM网关的痛点PART 02LLM推理与微服务的差异 请求间时延、服务器资源消耗差异不大 微服务一般无状态 GateWay or 负载均衡器不感知服务负载，常用的负载均衡算法：RR，Random、LeastRequest 限流：请求数粒度 推理请求差异巨大：时延、服务器资源消耗与Prompt长度及输出Token的长度息息相关 推理有状态应用，KV Cache命中率对性能影响很大 LLM Gateway需要感知推理引擎负载、KV Cache 限流：Token级限流 高级特性：语义缓存，多模型语义路由开源项目普遍采用Envoy扩展插件实现LLM网关

5、 调度策略必须在请求Header：routing-strategy指定 PD分离的调度方式比较Hack，只支持单xPyD分组调度，因为只能识别Prefill Decode角色，不能识别它们是否属于同一个PD组 支持多模型路由Llm-d infer scheduler多组件依赖，维护成本高不支持PD Group的感知调度不支持多模型路由支持Gateway API，Inference Extension APIEnvoy扩展方式：运维复杂 复用Envoy的流量治理能力=历史债务，依赖过多，运维复杂 LLM扩展插件，实际上是短路了Envoy原有的负载均衡过程 请求、响应均绕行Extension Pr

6、ocessor，链路过长，故障定界复杂 高阶功能，Token限流，公平调度等支持有限云原生推理开源项目KthenaPART 03什么是KthenaRouter分布式推理workload编排KV-cache模型统一管理Gang、超节点拓扑感知调度（volcano）推理运行时Prefill PodsPrefillerDecode podsDecoderRuntimeRuntimePrefill PodsPrefillerDecode podsDecoderRuntimeRuntimePrefill PodsP+DRuntime能力开箱即用内置分布式推理、PD分离等最佳部署范式内置超节点网络拓扑感知