配置工作负载
在选择资源键后,配置 NPU 工作负载的运行时行为。启用默认的 admission webhook 后,请让工作负载清单仅关注 NPU 资源请求,由 webhook 自动添加 ascend RuntimeClass。
本页介绍通过 Alauda Build of NPU Operator 直接分配 NPU 的方式。对于 Ascend 设备上的 HAMi 共享、虚拟化、vNPU 行为或 HAMi 专用资源键,请参阅 HAMi 文档。
资源请求
有关工作负载资源字段和示例,请参阅 请求 NPU 资源。请使用目标节点报告的准确资源键。常见示例包括用于 910 系列设备的 huawei.com/Ascend910、huawei.com/Ascend310P,以及其他环境特定的 huawei.com/Ascend* 键。不要仅根据芯片产品名称推导资源键。
RuntimeClass 行为
NPU Operator v26.6.0 使用由 ascend-docker-runtime 提供支持的 ascend RuntimeClass。运行时集成 DaemonSet 会分发 ascend-docker-runtime 负载,并使用 npu-container-toolkit 在每个 NPU 节点上配置相应的 containerd handler。
admission webhook 会为请求 Ascend 资源的 Pod 添加 ascend RuntimeClass。启用 webhook 后,新清单无需设置 runtimeClassName。如果 webhook 已禁用,请显式设置 runtimeClassName: ascend。
在 v26.6.0 中,请将 operator.runtimeClass 保持为 ascend。运行时集成 DaemonSet 会以该名称注册 containerd handler,因此仅修改 Operator 设置会导致 RuntimeClass 与 containerd handler 不匹配。
运行时集成验证提示
当排查一个已请求 NPU 资源但无法看到设备的工作负载时,请确认已接纳的 Pod 使用的是 ascend RuntimeClass,并且运行时集成 DaemonSet 处于 Ready 状态。在预编译 Driver 模式下,Driver 库会从主机运行时 Driver 树 /run/ascend/driver 中分发;在预装 Driver 和普通 OS 管理的安装模式下,组件使用 /usr/local/Ascend/driver。
在工作负载容器内,请检查诸如 /usr/local/bin/npu-smi、/usr/local/Ascend/... 和 /dev/davinci* 等路径。不要将这些工作负载侧路径与主机侧 Driver 树混淆。
调度与配额
如果工作负载一直处于 Pending:
- 检查节点是否报告了请求的资源键。
- 检查 ACP 中的项目和命名空间配额。
- 检查节点是否处于 Driver 升级或恢复状态。
有关 ACP 中的配额字段显示,请参阅 加速器资源配额。