Kthena + vLLM-Ascend：云原生大模型推理的编排与调度实践

本文分享自华为云社区《Kthena vLLM-Ascend云原生大模型推理的编排与调度实践》云原生技术与AI基础设施深度融合大模型在 Kubernetes 上的生产级部署成为行业当前核心课题。在千亿参数模型普及的今天单机显存已无法承载TP张量并行与 PP流水线并行成为标配。然而这种分布式范式的转变使得习惯于处理无状态微服务的 Kubernetes 原生工作负载抽象如 Deployment/Service显得力不从心。在KCD Beijing vLLM 2026上华为云架构师 Dan 与vLLM-Ascend Contributor Weijun 分享了《云原生架构下分布式大模型推理的编排与调度实践从PD分离到拓扑感知的全链路优化》。本文基于会议分享深度解析Kthena与Volcano协同架构如何解决多角色拓扑依赖、状态感知缺失等难题构建生产级的大模型推理服务。分布式大模型推理的云原生痛点当前基于原生 Kubernetes 部署大模型推理主要面临三大工程挑战多维度拓扑约束缺失TP 并行需要高频的 all-reduce 通信对网络延迟极度敏感。K8s 原生调度器极易将同一并行组的 Pod 打散到不同物理节点甚至跨越骨干网高昂的跨交换机通信延迟会直接吞噬模型并行带来的性能红利拖垮吞吐量等核心 SLA 指标。PD分离架构下的编排断裂为优化长上下文处理业界普遍采用 Prefill计算密集型与 Decode访存密集型分离架构。由于 K8s 缺乏多角色原子化编排能力这两种截然不同负载特性的角色难以实现独立的精细化弹性扩缩。单一角色的配比失衡极易导致整体链路拥塞或服务中断。流量网关的“状态盲区”提升长文本推理效率的核心在于复用 KV Cache。然而K8s 原生的 Ingress 或 Service 均为无状态设计无法感知各个 Decode 实例 GPU 显存中的 Cache 分布状况。采用轮询Round-Robin等传统策略盲目分发请求会导致 Cache 命中率骤降引发大量的重复计算和资源浪费。Kthena声明式 LLM 编排底座面对上述挑战Volcano 社区推出了 Kthena 项目。Kthena通过深度集成 Volcano 的批处理调度能力将复杂的分布式推理转化为具备拓扑约束的原子调度单元并结合智能路由框架实现闭环。Kthena Volcano 联合架构ModelServing专为 LLM 设计的负载建模ModelServing 是 Kthena 架构中承载实际推理计算任务的执行单元通常是运行着 vLLM-Ascend 等先进推理引擎的容器化 Pod。其负载建模分为三层这种分层设计充分考虑了分布式大模型推理的复杂性。ModelServing 三层架构ModelServing 层定义整体推理服务管理多个 ServingGroup 实例负责全局拓扑感知调度与 Gang Scheduling。用户只需要声明需要多少个 Prefill 实例和多少个 Decode 实例ModelServing 层会自动处理这些实例的生命周期管理。ServingGroup 层是独立完成一次推理任务的最小单位比如一个完整的推理链路可能包含一个 Prefill 节点和多个 Decode 节点它们共同组成一个 ServingGroup支持平滑重构能够在服务升级或配置变更时降低服务中断风险。Role 层定义具体的功能角色如计算节点和存储节点支持 Entry/Worker 双 Pod 模板这种设计优化了节点内的通信效率。Kthena Router云原生 LLM 推理的智能流量枢纽Kthena Router 是整个系统的智能流量枢纽它的智能化体现在多个方面。首先是智能请求路由Router 支持基于模型名称、自定义 Header 或 URI 模式的精准转发内置多种插件化评分算法如 Least Request最少请求、Random随机等。其次是 PD 分离的原生支持Router 可以将 Prefill 和 Decode 阶段路由到不同的推理实例这种架构极大提升了硬件利用率因为 Prefill 节点可以专注于计算密集型任务Decode 节点可以专注于访存密集型任务。KV Cache 感知是 Router 最核心、最独特的能力。通过 ScorePlugin 机制Router 优先将具有相同前缀的请求路由到存有对应 KV Cache 的节点。具体实现上Router 会收集各个 Decode 实例的 KV Cache 信息构建一个知识图谱。当新请求到来时Router 会对所有可用实例进行评估计算当前请求的 Token 序列与每个实例 Cache 中已存在 Token 序列的重叠度即 block matching。最终选择能够带来最大缓存命中收益的实例。实验证明这种方式可以将吞吐量提升达 2.7 倍首字延迟TTFT降低约 73.5%端到端延迟降低超过 60%。此外Router 还具备多项企业级能力支持 LoRA 适配器热插拔与按需路由这对于需要动态加载不同微调模型的生产环境非常重要具备 Token 级限流能力可以精确控制每个请求的 Token 消耗支持灰度发布可以逐步将流量切换到新版本支持故障自动转移当某个实例出现问题时自动将流量切换到健康实例。Kthena Autoscaler面向大模型推理的智能弹性伸缩架构Kthena Autoscaler 解决了一个核心问题如何让 Prefill 和 Decode 实例实现联动伸缩。thena Autoscaler 弹性伸缩架构传统的 Kubernetes HPAHorizontal Pod Autoscaler只能基于 CPU 或内存使用率进行简单的扩缩容但对于大模型推理服务这种方式远远不够。Kthena Autoscaler 的设计理念是感知推理服务的独特负载模式。它会分别监控 Prefill 实例和 Decode 实例的队列长度、请求延迟等指标然后分别进行扩缩容决策。当 Prefill 实例的请求队列开始积压时说明 Prefill 计算能力不足Autoscaler 会自动扩展 Prefill 实例当 Decode 实例的 GPU 利用率持续升高时说明 Decode 成为瓶颈Autoscaler 会精准扩容 Decode 实例。这种精细化的伸缩策略确保了资源的高效利用。ModelBooster极简一站式部署能力ModelBooster 提供了极简的一站式部署能力它是 Kthena 对用户最友好的入口ModelBooster一站式部署在传统方案中部署一个大模型推理服务需要创建多个 Kubernetes 资源Deployment、Service、ConfigMap、Secret 等还需要手动配置各种参数。这个过程繁琐且容易出错。ModelBooster 极大简化了这个过程用户只需要关心模型信息剩下的事情交给 ModelBooster 来完成。与Volcano的深度集成多级拓扑感知与原子化调度Kthena 声明式意图的落地深度依赖 Volcano 调度器的两大核心能力多级网络拓扑感知Volcano 引入了 HyperNode 自定义资源CRD将物理数据中心的机架、ToRTop of Rack交换机抽象为标准调度资源。调度器借此能够将强通信依赖的推理实例“锁”在同一个 ToR 交换机或机架内将网络延迟控制在 1-2 微秒的极致范围内。原子化 Gang 调度针对多 Pod 启动的“碎片化”问题Volcano 通过 PodGroup 机制将分布式推理集群内的所有 Prefill 与 Decode 实例视为统一实体。调度器严格保障全组实例同时获取资源并拉起杜绝了资源不足导致的“部分启动”和死锁风险。实践基于 vLLM-Ascend 的生产部署以国产化算力生态为例基于 vLLM-Ascend 引擎Kthena 大幅降低了在昇腾芯片上部署复杂模型的工程门槛。vLLM-Ascend让 vLLM 在 Ascend 无缝运行vLLM-Ascend 的安装非常简便只需要两条 pip 命令就可以完成部署环境的准备pip install vllm0.13.0 vllm-ascend0.13.0同时它也支持通过容器一键拉取预构建镜像quay.io/ascend/vllm-ascend:latest项目已经在 GitHub 上开源地址是 https://github.com/vllm-project/vllm-ascend。核心数据表明vLLM-Ascend 能够充分发挥 Ascend 芯片的性能在多项基准测试中取得了优异的成绩。vLLM-Ascend Kthena 生产级架构下图展示了 vLLM-Ascend 结合 Kthena 的生产级架构图vLLM-Ascend Kthena 生产级架构整个架构分为多个层次各层之间职责清晰、协作顺畅。最底层是基础设施层包括 Kubernetes 集群、Volcano 调度器、以及物理或虚拟的计算节点。在基础设施层之上是 Kthena 的核心组件层包括 Kthena Controller、ModelServing Controller、ModelRouter、以及 ModelAutoscaler。最上层是推理引擎层包括 vLLM-Ascend 实例它们负责实际的大模型推理计算。Qwen3-235B 双机推理部署案例以 Qwen3-235B 双机推理部署为例16卡×2机部署分为三个步骤第一步创建启动脚本 ConfigMap。ConfigMap 中包含推理服务的配置文件如模型路径、并行度配置等kubectl apply -f config.yaml -n vllm-project第二步创建 ModelServing 工作负载。这里会包含推理 Pod 模板和 Headless Servicekubectl apply -f model_server.yaml -n vllm-project第三步创建 ModelServer 和 ModelRoute也就是路由层kubectl apply -f router.yaml -n vllm-project整个部署过程体现了 Kthena 声明式编排的优势。用户只需要准备好配置文件执行几条 kubectl apply 命令就能完成复杂的大模型推理服务部署。相比传统方案需要手动创建几十个 Kubernetes 资源这大大简化了运维复杂度。Qwen3-235B 双机推理部署性能总结与展望通过对 Kthena 三大核心组件及其与 Volcano 调度器协同机制的深入分析我们可以看到Kthena 并非简单地将 LLM 推理任务包装成 Kubernetes 作业而是构建了一套完整的、面向生产的工程范式。它将分布式 LLM 推理这一复杂的黑盒应用逐步转化为一门可声明、可预测、可扩展的标准化 Kubernetes 工程。Kthena 的成功实践表明未来的大模型服务平台必然是建立在成熟的云原生技术栈之上的。通过扩展 Kubernetes 的 API 和调度器可以优雅地解决最初设计者未曾预料到的复杂问题。展望未来我们有望看到更多开箱即用的最佳实践被社区沉淀下来例如针对不同模型架构的专用调度策略、更智能的缓存替换算法、以及与服务网格更深度的集成等等Kthena 将成为架构师驾驭下一代AI负载的标准工具。更多信息请访问Volcano GitHubhttps://github.com/volcano-shKthena GitHub: https://github.com/volcano-sh/kthena/Kthena 网址https://kthena.volcano.sh/