今天,Volcano社区正式宣布发起全新的子项目——Kthena(其标识由抽象的红色几何图形与黑色英文“KTHENA”组成)。这是一个专为Kubernetes设计的云原生、高性能大语言模型(LLM)推理路由和编排调度系统,旨在攻克在生产环境中大规模部署和服务LLM所面临的核心挑战。
LLM服务化的“最后一公里”困境
大语言模型正在重塑各行各业,但将其高效、经济地部署在基于Kubernetes的云原生平台上,依然困难重重。开发者普遍面临以下挑战:
- 资源利用率低:LLM推理独特的KV Cache机制对GPU/NPU显存占用巨大且动态变化。传统的轮询负载均衡无法感知这种特性,导致资源闲置与请求排队并存,成本高昂。
- 延迟与吞吐难以兼顾:LLM推理分为计算密集的“Prefill”和访存密集的“Decode”阶段。两者混合调度无法针对性优化,影响整体服务性能。虽然Prefill/Decode分离部署已成主流,但高效的路由与调度仍是难题。
- 多租户与多模型管理复杂:企业常需同时提供多个基础模型、版本或LoRA微调模型。实现请求的公平调度、优先级管理和动态路由是一项复杂的系统工程。
- 缺乏K8s原生集成:许多现有方案要么是外部系统,与Kubernetes生态割裂;要么过于复杂,难以满足生产级的易用性和运维灵活性需求。
Kthena:云原生LLM推理的智能大脑
为解决上述难题,Kthena应运而生。它并非取代vLLM、SGLang等推理框架,而是作为它们上层的智能“交通枢纽”和“调度中心”,深度集成于Kubernetes之中。
Kthena的核心架构主要由两大组件构成:
- Kthena-router:一个独立、高性能的模型路由组件。它接收所有推理请求,并根据
ModelRoute规则,智能地将请求分发到后端的ModelServer。其内部包含令牌速率限制、公平性调度和负载均衡等模块。
- Kthena-controller-manager:Kubernetes控制平面的控制器,负责LLM工作负载的编排与生命周期管理。它包含多种控制器,如
model-booster controller、model-autoscaler和model-serving controller,通过持续调谐ModelBooster、AutoScalingPolicy、ModelServing等CRD资源,将声明式API转化为运行时实例。
整个系统的逻辑流程是:请求首先进入Kthena-router,经过调度后,被分发到具体的Prefill Worker或Decode Worker上运行(每个Worker都包含runtime,用于收集指标和KV事件)。同时,Kthena-controller-manager根据定义的策略,管理着下方多个模型实例(如Lora1, Lora2等)的生命周期和扩缩容。
核心特性与优势
Kthena的强大之处在于其专为LLM推理场景设计的核心功能:
1. 生产级推理编排(ModelServing)
该系统采用三层架构设计:ModelServing -> ServingGroup -> Role。通过一个API,即可支持LLM原生部署、PD分离部署乃至大规模弹性并行(EP)部署等多种形态,极大简化了管理复杂度。
例如,一个ModelServing可以包含任意数量的ServingGroup(如xPyD分组),每个ServingGroup包含多个Role(如Prefill、Decode角色,通常部署在同一超节点内以提升性能)。这天然支持了TP/PP/EP等多种模型并行范式。
- 原生支持Prefill-Decode分离部署:可将Prefill实例调度到高性能计算卡节点,将Decode实例调度到高带宽显存节点,实现资源最佳匹配和端到端延迟优化。二者可独立伸缩,灵活应对长短句混合、实时推理等复杂场景。
- 内置拓扑感知与Gang调度:Gang调度确保ServingGroup或Role“成组原子化”落地,避免资源浪费;拓扑感知调度将一组Pod调度到网络拓扑更优的节点,提升并行计算的数据传输效率。
一个典型的ModelServing配置(modelServing.spec.replicas=2)可能创建两个InferGroup(Group 0和Group 1)。每个Group下包含多个Role(如Role A, Role B, Role N),每个Role则由一个entry pod和若干个worker pod组成。
2. 开箱即用的模型上线(ModelBooster)
针对主流大模型,提供包括PD分离在内的多种部署范式模板,可自动生成ModelRoute、ModelServer、ModelServing、AutoscalingPolicy等全套资源配置,简化上线流程。
3. 智能、模型感知的路由(Kthena Router)
- 多模型路由:兼容OpenAI API,可根据请求头或内容将流量调度到不同的基础模型。
- 插件化调度算法:提供最少请求、最小时延、KV Cache感知、Prefix Cache感知、LoRA亲和、GPU利用率感知、公平调度等多种负载均衡算法。
- LoRA模型热插拔无中断:可感知推理引擎加载的LoRA适配器,实现无中断的插拔和路由。
- 丰富的流量治理:支持基于权重的路由、金丝雀发布、Token级流控、故障转移等策略。
- All-in-one架构:原生支持PD分离的流量调度,无需额外部署Envoy等网关,将多层路由合并为一层,易于维护。
4. 成本驱动的自动扩缩容(Autoscaler)
支持按CPU/GPU/内存或自定义业务指标进行同构伸缩。在多推理引擎/异构加速器组合场景中,可按“成本-能力”进行贪心分配,实现性价比最大化。
5. 主流推理引擎与异构硬件支持
支持vLLM、SGLang、Triton/TGI等多种主流人工智能推理引擎,提供统一的API抽象和标准化指标。同时支持GPU/NPU等异构硬件混部,配合异构Autoscaling实现成本与服务等级目标(SLO)的动态平衡。
6. 内置流量控制与公平性调度
支持基于优先级和历史Token消耗的公平调度,在保障高优先级用户服务体验的同时,防止低优先级用户“饿死”。提供按用户、模型、Token长度进行精细化流量控制的能力。
极致的性能提升
基于Kthena Router的插件化调度架构,在长提示词场景(如4096 tokens)下,采用“KV Cache感知 + 最少请求”策略,相较于随机基线策略,性能提升显著:
| Plugin Configuration |
Throughput (req/s) |
TTFT (s) |
E2E Latency (s) |
| Least Request + KVCacheAware |
32.22 |
9.22 |
0.57 |
| Least Request + Prefix Cache |
23.87 |
12.47 |
0.83 |
| Random |
11.81 |
25.23 |
2.15 |
数据显示:
- 吞吐量提升约2.73倍
- 首Token时间(TTFT)降低约73.5%
- 端到端时延降低超过60%
在短提示词场景下,优势会随提示词长度收敛,但在多轮对话、模板化生成等业务中,KV Cache感知策略优势依然显著。实际收益与模型规模、提示词长度、硬件紧密相关,但“按需组合、按场景选型”已被验证有效。
社区展望
Kthena在规划初期便获得了社区部分用户的关注。项目未来将支持更高效的调度算法、更广泛的大模型部署最佳实践,并持续深耕LLM推理的大规模部署和性能优化。
多位业界专家对Kthena给予了高度评价:
- 华为云通用计算服务产品部部长 祁小波 表示,Kthena是Volcano社区技术演进的重要里程碑,将与华为云基础设施深度结合,释放多元算力价值,共建开放繁荣的云原生AI生态。
- 中电信人工智能公司 PaaS研发总监 杨磊 认为,Kthena巩固了Volcano在
智能 & 数据 & 云调度领域的领先地位,期待其结合Volcano的弹性伸缩与跨集群调度能力,进一步提升算力资源利用率。
- DaoCloud开源团队负责人 徐俊杰 指出,Kthena将推理这一关键环节纳入Volcano生态,凝练了其在调度、弹性伸缩及多算力适配上的多年实践,代表了云原生AI的开放、智能方向。
- 小红书云原生业务网关负责人 空古(陈华昌) 提到,双方已在流量智能调度方向深度合作,未来将继续在AI网关、模型API管理、MCP协议支持等方面为社区贡献力量。
- 联通云智算能力中心团队长 卢照旭 看好Kthena的网络拓扑感知与Gang调度能力,认为其为解决大规模分布式模型推理的效率与可靠性难题提供了极具潜力的方案。
- CNCF TOC 副主席 Kevin Wang 强调,Kthena提供了一套专为大模型设计、可借鉴的云原生调度原语和抽象,有助于将LLM推理工作负载以Kubernetes原生的一等公民身份进行管理,是加速AI Native进程的重要实践经验。
立即开始探索 Kthena
- GitHub 仓库:
github.com/volcano-sh/kthena
- 项目官网:
kthena.volcano.sh/
- 社区 Slack:
cloud-native.slack.com/archives/C011GJDQS0N
Volcano是CNCF首个且唯一的云原生批量计算项目,广泛应用于AI、大数据等高性能计算场景。Kthena的出现,标志着Volcano将其在调度领域的深厚积累拓展至大模型推理领域,致力于打造训推一体的完整解决方案。
参考资料
[1] 重新定义大模型智能推理:Volcano社区发起Kthena子项目, 微信公众号:mp.weixin.qq.com/s/rjD370fBKthGOOX83qpJ9g
版权声明:本文由 云栈社区 整理发布,版权归原作者所有。