NPU 集群调度实战：Kubernetes + Volcano + ktp 如何影响推理服务

大模型部署在集群上时，用户看到的只是一个任务状态，但背后是调度器、节点、镜像缓存、共享存储和通信初始化共同决定结果。

资源层级

一个 NPU 集群可以抽象成：

Cluster -> Node -> NPU -> Queue -> Job -> Pod

节点通常有固定数量的 NPU。请求 8 NPU、16 NPU、32 NPU 对调度器来说是完全不同的资源形态。请求 16 NPU 可能意味着占用一个完整节点；请求 32 NPU 可能需要两个节点同时空闲。

调度流程

任务提交后，Volcano 根据队列配额和节点空闲情况分配资源。用户通常不能直接指定节点。Pod 被创建后会挂载共享存储，等待通信配置就绪，然后启动模型服务。

单节点通信和多节点通信的失败模式不同。单节点主要关注卡内通信和本地资源；多节点还要关注 master 地址、HCCL 初始化、跨节点 RPC 和网络。

Pending 不只是排队

Pod 长时间 Pending 可能来自：

• 没有足够空闲 NPU。
• CPU 或内存请求过高。
• 镜像没有缓存，拉取时间很长。
• 队列配额不足。

因此观察任务时不能只看 NPU 数量，还要看 CPU、memory、queue 和镜像缓存。

部署排障分层

模型服务起不来时，可以按四层排查：

1. 模型和运行时是否兼容。
2. 镜像是否包含需要的代码和 parser。
3. 调度器是否分配到足够资源。
4. 通信和共享存储是否正常。

这比直接重复提交任务更有效。

知识补全：Pending、Running、Failed 分别看什么

集群任务状态不同，排查重点也不同。

Pending 阶段主要看调度。资源是否足够、队列是否有配额、镜像是否需要拉取、CPU/内存请求是否过高，都是 Pending 的常见原因。

Running 阶段主要看运行时。模型是否加载成功、通信是否初始化、端口是否监听、健康检查是否通过。

Failed 阶段要看退出码和日志。是 Python import 失败、模型架构不支持、OOM、通信超时，还是业务进程主动退出。

把这三个阶段混在一起，会导致排查方向错误。

NPU 集群心智模型

NPU 集群并不是“有多少卡就能随便拿多少卡”。调度粒度、节点拓扑、通信库、镜像缓存和共享存储都会影响任务。

部署前应确认：

1. 请求的 NPU 数是否对应半节点、整节点或多节点。
2. 多节点时通信初始化需要哪些环境变量。
3. 镜像是否在目标节点已有缓存。
4. 共享模型路径是否对所有 Pod 可见。
5. CPU 和内存请求是否会阻塞调度。

这能把集群从黑盒变成可分析系统。