LLM 服务化的“最后一公里”困境大语言模型LLM正在以前所未有的速度重塑各行各业但将其高效、经济地部署在生产环境中特别是基于 Kubernetes 的云原生平台上仍然困难重重。开发者们普遍面临以下挑战资源利用率低LLM 推理尤其是其独特的 KV Cache 机制对 GPU、NPU 显存的占用是动态且巨大的。传统的负载均衡一般采用Round-Robin算法无法感知这种负载特性导致 GPU、NPU 资源闲置与请求排队并存成本高昂。延迟与吞吐量难以兼顾LLM 推理分为“Prefill”处理输入提示和“Decode”生成 Token两个阶段前者是计算密集型后者是访存密集型。将两者混合调度常常导致无法针对性优化影响整体服务的响应速度和吞吐能力。因此PD分离的部署已经成为主流但如何高效路由和调度仍是一个难题。多租户与多模型管理复杂在企业环境中通常需要同时提供多个不同模型、不同版本或经过 LoRA 微调的模型。如何实现请求的公平调度、优先级管理以及动态路由是一个复杂的工程难题业界甚至有些方案将AI网关与大模型一一对应。缺乏K8s原生集成许多现有的解决方案要么是外部系统与 Kubernetes 生态割裂要么过于复杂无法满足生产级所需的简单易用性和灵活运维。Kthena云原生 LLM 推理的智能大脑为了攻克上述难题Kthena 应运而生。它并非要取代现有的 LLM 服务框架如 vLLM, sgLang而是作为它们上层的智能“交通枢纽”和“调度中心”深度集成于 Kubernetes 之中。Kthena 架构图Kthena 的核心由两大组件构成1) Kthena Router一个独立、高性能面向多模型的router负责接收所有推理请求并根据 ModelRoute 规则智能地将请求分发到后端的 ModelServer。2) Kthena Controller ManagerKubernetes 控制平面的控制器它主要包含多种控制器负责 LLM 工作负载的编排与生命周期管理。它持续调谐并联动多类 CRD如 ModelBooster、ModelServing、AutoScalingPolicy/AutoScalingPolicyBinding、以及 ModelRoute/ModelServer将声明式API转化为运行时资源ModelServing 控制器编排 ServingGroup 与 Prefill/Decode 角色分组支持网络拓扑亲和调度和Gang调度、滚动升级与故障恢复基于 AutoScalingPolicy 实现弹性扩缩容。这种架构使得 Kthena 成为连接用户请求与 LLM 模型的高度可编程的桥梁。核心特性与优势Kthena 的强大之处在于其专为 LLM 推理场景设计的核心功能1) 生产级推理编排ModelServing-LLM工作负载三层架构设计ModelServing - ServingGroup - Role一个API支持LLM原生部署、PD分离部署乃至大EP部署等多种部署形态简化管理多LWS的负担。例如对于PD分离的大规模部署可用一个ModelServing表示根据负载的大小每个ModelServing可以包含任意数目的 ServingGroupxPyD 分组 每个ServingGroup包含多个角色Prefill Decode他们通常部署在同一个超节点内以提升推理性能相同的角色可以等价为一个LeaderWorkerSet支持TP/PP/EP等多节推理并行计算。-原生支持Prefill-Decode分离部署将计算密集型的 Prefill 实例调度到配备高性能计算卡的节点组而将访存密集型的 Decode 实例调度到配备高带宽显存的节点组实现资源的最佳匹配和极致的端到端延迟优化。另可以独立伸缩动态调整Prefill-Decode的比例更灵活的应对各种复杂的业务场景如长短句混合、实时推理等。-多并行范式支持TP/PP/DP/EP 等并行模式灵活配置最大化提升资源利用率和SLO-内置拓扑感知、Gang 调度支持Gang调度确保ServingGroup/Role“成组原子化”落地避免资源浪费拓扑感知调度通过将Role内的一组Pod调度到网络拓扑更优的节点提升并行计算的数据传输时延。2) 开箱即用的模型上线ModelBooster- 针对主流的大模型提供包括PD分离在内的多种部署范式模板自动生成ModelRoute/ModelServer/ModelServing/Autoscaling等路由策略和生命周期管理资源- 覆盖通用的部署场景至于更灵活的编排可通过ModelServing进行细粒度的控制3)智能、模型感知的路由Kthena Router-多模型路由兼容OpenAI API根据请求头或Body体内容将流量调度到不同的基础模型。-插件化调度算法提供最少请求、最小时延、KV Cache 感知、Prefix Cache 感知、LoRA 亲和、GPU 利用率感知、公平调度等多种负载均衡算法满足用户不同业务场景和部署形态的需求-LoRA 模型热插拔无中断感知推理引擎加载的LoRA 适配器提供无中断的插拔和路由能力-丰富的流量治理策略基于权重的模型路由金丝雀发布、Token级流控、故障转移·-All-in-one实现架构无需部署Envoy Gateway原生支持PD分离的流量调度将多层路由合并成一层易于维护4) 成本驱动的自动扩缩容Autoscaler-同构伸缩支持稳定、突发双模式按业务指标CPU/GPU/内存/自定义精准扩缩-异构部署优化在多推理引擎/异构加速器组合中按“成本-能力”贪心分配最大化性价比5) 主流推理引擎与异构硬件支持- 支持多种主流推理引擎vLLM、SGLang、Triton/TGI 等统一API抽象、标准化指标-支持GPU/NPU 等异构混部配合异构 Autoscaling 实现成本与 SLO 的动态平衡6) 内置流量控制与公平性调度-公平调度支持基于优先级和历史Token消耗的的公平调度既兼顾用户的优先级对高优先级用户提供更好的服务又防止低优先级用户“饿死”-流量控制支持按照用户、模型、token长度进行精细化流量控制极致的性能提升基于 Kthena Router 的调度插件架构在长系统提示词场景如 4096 tokens下采用“KV Cache 感知 最少请求”策略相较随机基线- 吞吐可提升约 2.73 倍- TTFT 降低约 73.5%- 端到端时延降低超过 60%Plugin ConfigurationThroughput (req/s)TTFT (s)E2E Latency (s)Least Request KVCacheAware32.229.220.57Least Request Prefix Cache23.8712.470.83Random11.8125.232.15短提示词场景差距会随提示词长度收敛但在多轮对话、模板化生成、前缀高度相似的业务中KV Cache 感知策略优势显著。实际收益与模型规模、Prompt长短、硬件紧密相关但“按需组合、按场景选型”已被验证有效。社区展望 / Call for ContributionKthena 在项目规划和发展的初期便得到了部分社区用户单位的关注和支持但这只是一个开始。我们计划在未来支持更高效的调度算法、更广泛的大模型最佳部署实践并持续深耕 LLM 推理的大规模部署和性能优化。“开源是技术创新的源头活水也是推动产业标准化的最强引擎。作为Volcano项目的发起单位华为云很荣幸能够与社区其他伙伴一起推出全新的Kthena分布式推理项目。这不仅是Volcano社区技术演进重要里程碑更是华为云在云原生AI领域长期投入与持续创新的有力见证。它将与华为云CCE云容器引擎、CCI云容器实例等基础设施深度结合进一步释放包括昇腾Ascend在内的多元算力价值为客户提供极致的算力性价比。我们希望通过Kthena与全球开发者与伙伴共建、共享一个开放、繁荣的云原生AI生态为千行万业的智能化升级构筑最坚实的算力底座。”—— 祁小波华为云通用计算服务产品部部长“Kthena进一步巩固了Volcano在智能计算调度领域的领先地位。我们的平台利用Volcano的统一调度与资源池化能力一站式满足通用计算与智能计算中训练、推理等多类算力需求。这使得算力资源能够在不同场景间灵活流转有效避免了资源割裂的问题。展望未来我们期待 Kthena结合Volcano的弹性伸缩能力与Volcano Global的跨集群调度特性共同推动算力资源利用率进一步提升”—— 杨磊中电信人工智能公司 PaaS研发总监杨磊“Volcano 项目自诞生之日起便始终与社区以及各类 AI 场景深度共建、同频演进逐步沉淀出一整套面向 AI 工作负载的调度与批处理生态。今天Kthena 的出现不仅将这条共建链路进一步拓展到大模型推理领域把推理这一关键一环真正纳入 Volcano 生态之中更是在统一编排与智能路由层面将 Volcano 在调度、弹性伸缩以及多算力适配上的多年实践凝练成一个令人振奋的里程碑式能力。借助既有的 Kubernetes / Volcano 生态更多团队可以用更低的成本获得更智能的调度决策和更高效的算力利用并在开放协作的基础上持续演进。这不仅为道客解决了在推理场景中遇到的实际问题也是我们所期待的云原生 AI 形态——一个足够开放、足够智能、值得我们长期投入和深度参与的社区方向。”—— 徐俊杰DaoCloud 开源团队负责人、Kubernetes 社区指导委员会成员“自建大模型推理服务的生产级部署和运维难题是一个覆盖推理服务全生命周期管理部署、运维、弹性、故障恢复等GPU集群稳定性资源调度效率、推理服务性能提升推理流量智能调度、AI可观测等领域的系统工程。而这也正是Kthena项目的技术定位。早在Kthena的规划阶段小红书云原生团队就和Volcano贡献者做了深度的沟通在推理流量智能调度方向一起设计了多种流量调度策略和路由实现。未来双方将继续在AI网关方向合作结合小红书内部业务经验一起为社区提供更精细化的AI流量智能调度能力模型API管理能力MCP协议支持等多种生产可用能力。”—— 空古(陈华昌)小红书云原生业务网关负责人“在深入调研并试用Kthena这一云原生AI推理平台后联通云对其展现出的前瞻能力印象深刻。我们尤为看好其与Volcano实现的联合调度特性其网络拓扑感知与Gang Scheduling功能能够有效解决大规模分布式模型推理场景下中关于效率与可靠性的核心诉求为破解复杂调度难题提供了极具潜力的解决方案。我们相信Kthena卓越的低延迟、高吞吐与多模型智能路由能力将为开源社区带来真正具备生产级的AI推理解决方案助力开发者更高效地构建和管理云原生环境下的智能应用。”—— 卢照旭联通云智算能力中心团队长“开放和协作是构建社区的未来、加速技术创新的核心动力。在CNCF我们持续致力于推动基础设施向‘AI Native’演进为整个云原生生态提供标准、中立且可扩展的基础能力。Volcano社区通过孵化Kthena子项目将其在大规模批量计算和调度上积累的拓扑感知、Gang调度等核心经验精准地应用到了LLM在线推理这一关键场景。Kthena的价值在于它提供了一套专为大模型设计、可供业界参考和借鉴的云原生调度原语和抽象如Prefill/Decode分离编排和KV Cache感知路由这有助于将复杂的LLM推理工作负载真正以Kubernetes原生的一等公民身份进行高效管理。这不仅是Volcano项目技术演进的重要一步更是社区生态在解决AI规模化部署挑战中贡献的一份重要实践经验。我们诚挚邀请全球的开发者、研究人员和所有云原生爱好者加入共同贡献智慧完善这些关键AI基础设施加速 AI Native 进程。”
Volcano 社区发布 Kthena 子项目 | 重新定义大模型智能推理
LLM 服务化的“最后一公里”困境大语言模型LLM正在以前所未有的速度重塑各行各业但将其高效、经济地部署在生产环境中特别是基于 Kubernetes 的云原生平台上仍然困难重重。开发者们普遍面临以下挑战资源利用率低LLM 推理尤其是其独特的 KV Cache 机制对 GPU、NPU 显存的占用是动态且巨大的。传统的负载均衡一般采用Round-Robin算法无法感知这种负载特性导致 GPU、NPU 资源闲置与请求排队并存成本高昂。延迟与吞吐量难以兼顾LLM 推理分为“Prefill”处理输入提示和“Decode”生成 Token两个阶段前者是计算密集型后者是访存密集型。将两者混合调度常常导致无法针对性优化影响整体服务的响应速度和吞吐能力。因此PD分离的部署已经成为主流但如何高效路由和调度仍是一个难题。多租户与多模型管理复杂在企业环境中通常需要同时提供多个不同模型、不同版本或经过 LoRA 微调的模型。如何实现请求的公平调度、优先级管理以及动态路由是一个复杂的工程难题业界甚至有些方案将AI网关与大模型一一对应。缺乏K8s原生集成许多现有的解决方案要么是外部系统与 Kubernetes 生态割裂要么过于复杂无法满足生产级所需的简单易用性和灵活运维。Kthena云原生 LLM 推理的智能大脑为了攻克上述难题Kthena 应运而生。它并非要取代现有的 LLM 服务框架如 vLLM, sgLang而是作为它们上层的智能“交通枢纽”和“调度中心”深度集成于 Kubernetes 之中。Kthena 架构图Kthena 的核心由两大组件构成1) Kthena Router一个独立、高性能面向多模型的router负责接收所有推理请求并根据 ModelRoute 规则智能地将请求分发到后端的 ModelServer。2) Kthena Controller ManagerKubernetes 控制平面的控制器它主要包含多种控制器负责 LLM 工作负载的编排与生命周期管理。它持续调谐并联动多类 CRD如 ModelBooster、ModelServing、AutoScalingPolicy/AutoScalingPolicyBinding、以及 ModelRoute/ModelServer将声明式API转化为运行时资源ModelServing 控制器编排 ServingGroup 与 Prefill/Decode 角色分组支持网络拓扑亲和调度和Gang调度、滚动升级与故障恢复基于 AutoScalingPolicy 实现弹性扩缩容。这种架构使得 Kthena 成为连接用户请求与 LLM 模型的高度可编程的桥梁。核心特性与优势Kthena 的强大之处在于其专为 LLM 推理场景设计的核心功能1) 生产级推理编排ModelServing-LLM工作负载三层架构设计ModelServing - ServingGroup - Role一个API支持LLM原生部署、PD分离部署乃至大EP部署等多种部署形态简化管理多LWS的负担。例如对于PD分离的大规模部署可用一个ModelServing表示根据负载的大小每个ModelServing可以包含任意数目的 ServingGroupxPyD 分组 每个ServingGroup包含多个角色Prefill Decode他们通常部署在同一个超节点内以提升推理性能相同的角色可以等价为一个LeaderWorkerSet支持TP/PP/EP等多节推理并行计算。-原生支持Prefill-Decode分离部署将计算密集型的 Prefill 实例调度到配备高性能计算卡的节点组而将访存密集型的 Decode 实例调度到配备高带宽显存的节点组实现资源的最佳匹配和极致的端到端延迟优化。另可以独立伸缩动态调整Prefill-Decode的比例更灵活的应对各种复杂的业务场景如长短句混合、实时推理等。-多并行范式支持TP/PP/DP/EP 等并行模式灵活配置最大化提升资源利用率和SLO-内置拓扑感知、Gang 调度支持Gang调度确保ServingGroup/Role“成组原子化”落地避免资源浪费拓扑感知调度通过将Role内的一组Pod调度到网络拓扑更优的节点提升并行计算的数据传输时延。2) 开箱即用的模型上线ModelBooster- 针对主流的大模型提供包括PD分离在内的多种部署范式模板自动生成ModelRoute/ModelServer/ModelServing/Autoscaling等路由策略和生命周期管理资源- 覆盖通用的部署场景至于更灵活的编排可通过ModelServing进行细粒度的控制3)智能、模型感知的路由Kthena Router-多模型路由兼容OpenAI API根据请求头或Body体内容将流量调度到不同的基础模型。-插件化调度算法提供最少请求、最小时延、KV Cache 感知、Prefix Cache 感知、LoRA 亲和、GPU 利用率感知、公平调度等多种负载均衡算法满足用户不同业务场景和部署形态的需求-LoRA 模型热插拔无中断感知推理引擎加载的LoRA 适配器提供无中断的插拔和路由能力-丰富的流量治理策略基于权重的模型路由金丝雀发布、Token级流控、故障转移·-All-in-one实现架构无需部署Envoy Gateway原生支持PD分离的流量调度将多层路由合并成一层易于维护4) 成本驱动的自动扩缩容Autoscaler-同构伸缩支持稳定、突发双模式按业务指标CPU/GPU/内存/自定义精准扩缩-异构部署优化在多推理引擎/异构加速器组合中按“成本-能力”贪心分配最大化性价比5) 主流推理引擎与异构硬件支持- 支持多种主流推理引擎vLLM、SGLang、Triton/TGI 等统一API抽象、标准化指标-支持GPU/NPU 等异构混部配合异构 Autoscaling 实现成本与 SLO 的动态平衡6) 内置流量控制与公平性调度-公平调度支持基于优先级和历史Token消耗的的公平调度既兼顾用户的优先级对高优先级用户提供更好的服务又防止低优先级用户“饿死”-流量控制支持按照用户、模型、token长度进行精细化流量控制极致的性能提升基于 Kthena Router 的调度插件架构在长系统提示词场景如 4096 tokens下采用“KV Cache 感知 最少请求”策略相较随机基线- 吞吐可提升约 2.73 倍- TTFT 降低约 73.5%- 端到端时延降低超过 60%Plugin ConfigurationThroughput (req/s)TTFT (s)E2E Latency (s)Least Request KVCacheAware32.229.220.57Least Request Prefix Cache23.8712.470.83Random11.8125.232.15短提示词场景差距会随提示词长度收敛但在多轮对话、模板化生成、前缀高度相似的业务中KV Cache 感知策略优势显著。实际收益与模型规模、Prompt长短、硬件紧密相关但“按需组合、按场景选型”已被验证有效。社区展望 / Call for ContributionKthena 在项目规划和发展的初期便得到了部分社区用户单位的关注和支持但这只是一个开始。我们计划在未来支持更高效的调度算法、更广泛的大模型最佳部署实践并持续深耕 LLM 推理的大规模部署和性能优化。“开源是技术创新的源头活水也是推动产业标准化的最强引擎。作为Volcano项目的发起单位华为云很荣幸能够与社区其他伙伴一起推出全新的Kthena分布式推理项目。这不仅是Volcano社区技术演进重要里程碑更是华为云在云原生AI领域长期投入与持续创新的有力见证。它将与华为云CCE云容器引擎、CCI云容器实例等基础设施深度结合进一步释放包括昇腾Ascend在内的多元算力价值为客户提供极致的算力性价比。我们希望通过Kthena与全球开发者与伙伴共建、共享一个开放、繁荣的云原生AI生态为千行万业的智能化升级构筑最坚实的算力底座。”—— 祁小波华为云通用计算服务产品部部长“Kthena进一步巩固了Volcano在智能计算调度领域的领先地位。我们的平台利用Volcano的统一调度与资源池化能力一站式满足通用计算与智能计算中训练、推理等多类算力需求。这使得算力资源能够在不同场景间灵活流转有效避免了资源割裂的问题。展望未来我们期待 Kthena结合Volcano的弹性伸缩能力与Volcano Global的跨集群调度特性共同推动算力资源利用率进一步提升”—— 杨磊中电信人工智能公司 PaaS研发总监杨磊“Volcano 项目自诞生之日起便始终与社区以及各类 AI 场景深度共建、同频演进逐步沉淀出一整套面向 AI 工作负载的调度与批处理生态。今天Kthena 的出现不仅将这条共建链路进一步拓展到大模型推理领域把推理这一关键一环真正纳入 Volcano 生态之中更是在统一编排与智能路由层面将 Volcano 在调度、弹性伸缩以及多算力适配上的多年实践凝练成一个令人振奋的里程碑式能力。借助既有的 Kubernetes / Volcano 生态更多团队可以用更低的成本获得更智能的调度决策和更高效的算力利用并在开放协作的基础上持续演进。这不仅为道客解决了在推理场景中遇到的实际问题也是我们所期待的云原生 AI 形态——一个足够开放、足够智能、值得我们长期投入和深度参与的社区方向。”—— 徐俊杰DaoCloud 开源团队负责人、Kubernetes 社区指导委员会成员“自建大模型推理服务的生产级部署和运维难题是一个覆盖推理服务全生命周期管理部署、运维、弹性、故障恢复等GPU集群稳定性资源调度效率、推理服务性能提升推理流量智能调度、AI可观测等领域的系统工程。而这也正是Kthena项目的技术定位。早在Kthena的规划阶段小红书云原生团队就和Volcano贡献者做了深度的沟通在推理流量智能调度方向一起设计了多种流量调度策略和路由实现。未来双方将继续在AI网关方向合作结合小红书内部业务经验一起为社区提供更精细化的AI流量智能调度能力模型API管理能力MCP协议支持等多种生产可用能力。”—— 空古(陈华昌)小红书云原生业务网关负责人“在深入调研并试用Kthena这一云原生AI推理平台后联通云对其展现出的前瞻能力印象深刻。我们尤为看好其与Volcano实现的联合调度特性其网络拓扑感知与Gang Scheduling功能能够有效解决大规模分布式模型推理场景下中关于效率与可靠性的核心诉求为破解复杂调度难题提供了极具潜力的解决方案。我们相信Kthena卓越的低延迟、高吞吐与多模型智能路由能力将为开源社区带来真正具备生产级的AI推理解决方案助力开发者更高效地构建和管理云原生环境下的智能应用。”—— 卢照旭联通云智算能力中心团队长“开放和协作是构建社区的未来、加速技术创新的核心动力。在CNCF我们持续致力于推动基础设施向‘AI Native’演进为整个云原生生态提供标准、中立且可扩展的基础能力。Volcano社区通过孵化Kthena子项目将其在大规模批量计算和调度上积累的拓扑感知、Gang调度等核心经验精准地应用到了LLM在线推理这一关键场景。Kthena的价值在于它提供了一套专为大模型设计、可供业界参考和借鉴的云原生调度原语和抽象如Prefill/Decode分离编排和KV Cache感知路由这有助于将复杂的LLM推理工作负载真正以Kubernetes原生的一等公民身份进行高效管理。这不仅是Volcano项目技术演进的重要一步更是社区生态在解决AI规模化部署挑战中贡献的一份重要实践经验。我们诚挚邀请全球的开发者、研究人员和所有云原生爱好者加入共同贡献智慧完善这些关键AI基础设施加速 AI Native 进程。”
