云原生技术与AI基础设施深度融合，大模型在 Kubernetes 上的生产级部署成为行业当前核心课题。在千亿参数模型普及的今天，单机显存已无法承载，TP（张量并行）与 PP（流水线并行）成为标配。然而，这种分布式范式的转变，使得习惯于处理无状态微服务的 Kubernetes 原生工作负载抽象（如 Deployment/Service）显得力不从心。

在KCD Beijing + vLLM 2026上，华为云架构师 Dan 与vLLM-Ascend Contributor Weijun 分享了《云原生架构下分布式大模型推理的编排与调度实践：从PD分离到拓扑感知的全链路优化》。本文基于会议分享，深度解析 Kthena^[1] 与 Volcano^[2] 协同架构如何解决多角色拓扑依赖、状态感知缺失等难题，构建生产级的大模型推理服务。

   分布式大模型推理的云原生痛点  

当前基于原生 Kubernetes 部署大模型推理，主要面临三大工程挑战：

1. 多维度拓扑约束缺失： TP 并行需要高频的 all-reduce 通信，对网络延迟极度敏感。K8s 原生调度器极易将同一并行组的 Pod 打散到不同物理节点甚至跨越骨干网，高昂的跨交换机通信延迟会直接吞噬模型并行带来的性能红利，拖垮吞吐量等核心 SLA 指标。

2. PD 分离架构下的编排断裂： 为优化长上下文处理，业界普遍采用 Prefill（计算密集型）与 Decode（访存密集型）分离架构。由于 K8s 缺乏多角色原子化编排能力，这两种截然不同负载特性的角色难以实现独立的精细化弹性扩缩。单一角色的配比失衡极易导致整体链路拥塞或服务中断。

3. 流量网关的“状态盲区”： 提升长文本推理效率的核心在于复用 KV Cache。然而，K8s 原生的 Ingress 或 Service 均为无状态设计，无法感知各个 Decode 实例 GPU 显存中的 Cache 分布状况。采用轮询（Round-Robin）等传统策略盲目分发请求，会导致 Cache 命中率骤降，引发大量的重复计算和资源浪费。

  Kthena：声明式 LLM 编排底座  

面对上述挑战，Volcano 社区推出了 Kthena^[3] 项目。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 实例实现联动伸缩。

▲ Kthena Autoscaler 弹性伸缩架构

传统的 Kubernetes HPA（Horizontal 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），将物理数据中心的机架、ToR（Top 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 vllm==0.13.0 vllm-ascend==0.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 Service：

kubectl 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负载的标准工具。

如果你喜欢我们的项目，欢迎Star★，Fork，来 Kthena 社区一起玩转LLM推理！添加社区小助手k8s2222 回复Kthena进入社区交流群。