如何编排调度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 信息，构建一个"知识图谱"。