#Ascend vNPU 上的 HAMi

当 Ascend 工作负载需要通过 HAMi 进行固定模板硬切分，或通过 hami-core 进行软切分时，请使用此场景。对于通过 HAMi 进行整卡分配的场景，请使用 HAMi on Ascend NPU。

#选择硬切分或软切分

硬切分和软切分是彼此独立的 node 模式。当一个集群同时需要这两种模式时，请使用独立的 node pool，并确保每个工作负载选择与其模式相匹配的 node pool。

#检查生效的 node 模式

检查写入目标 node 的生效注解：

kubectl get node <node-name> \
  -o go-template='hami-vnpu-core={{ index .metadata.annotations "hami-vnpu-core" }}{{ "\n" }}'

调度会将 node 注解作为生效模式：

• false：该 node 接受整卡请求以及部分内存的硬切分请求；
• true：该 node 接受整卡请求以及设置了 huawei.com/vnpu-mode: hami-core 的部分内存软切分请求。

如果 node 和 Pod 的模式不匹配，Pod 可能会因 ModeNotFit 调度事件而一直处于 Pending。可通过以下命令检查：

kubectl describe pod <pod-name>

请参阅 Configure Ascend Slicing Mode，以检查所属的 Custom Resource 和 ConfigMaps，或更改 node 模式。

#运行 Ascend 工作负载

下面的 Pod 清单以 Ascend 310P3 为具体示例。该硬件型号通过 huawei.com/Ascend310P 资源族暴露。对于 Ascend 910 系列设备，请将数量、内存、可选 core，以及分配注解名称替换为 hami-scheduler-device 中该型号对应的值。对于硬切分，还需要使用该型号定义的模板和内存值，并更新验证命令中预期的 ASCEND_VNPU_SPECS 值。请将镜像替换为包含测试应用所需 CANN libraries 的 ARM64 Ascend 镜像。

#运行硬切分工作负载

硬切分会将请求的内存向上舍入到预定义模板。对于 Ascend 310P3，v1.4.0 配置提供了 3072 MiB 的 vir01、6144 MiB 的 vir02 和 12288 MiB 的 vir04。下面的请求选择 vir01。

apiVersion: v1
kind: Pod
metadata:
  name: hami-ascend310p-hard-slice
spec:
  schedulerName: hami-scheduler
  runtimeClassName: ascend
  restartPolicy: Never
  containers:
    - name: npu-workload
      image: <your-ascend-image>
      command: ["/bin/sh", "-c"]
      args:
        - |
          env | grep -E 'ASCEND_VISIBLE_DEVICES|ASCEND_VNPU_SPECS'
          sleep 3600
      resources:
        requests:
          huawei.com/Ascend310P: "1"
          huawei.com/Ascend310P-memory: "3072"
        limits:
          huawei.com/Ascend310P: "1"
          huawei.com/Ascend310P-memory: "3072"

不要为硬切分工作负载添加 huawei.com/vnpu-mode: hami-core 或 core 资源。

创建并检查 Pod：

kubectl apply -f hami-ascend310p-hard-slice.yaml
kubectl get pod hami-ascend310p-hard-slice -o wide
kubectl get pod hami-ascend310p-hard-slice \
  -o go-template='scheduler={{ .spec.schedulerName }}{{ "\n" }}runtimeClass={{ .spec.runtimeClassName }}{{ "\n" }}allocation={{ index .metadata.annotations "hami.io/Ascend310P-devices-allocated" }}{{ "\n" }}'
kubectl exec hami-ascend310p-hard-slice -- /bin/sh -c '
  test -n "$ASCEND_VISIBLE_DEVICES" &&
  test "$ASCEND_VNPU_SPECS" = vir01 &&
  test -z "$NPU_MEM_QUOTA"
'

预期结果应包含非空的 HAMi 分配注解以及 ASCEND_VNPU_SPECS=vir01。这些信号确认选择了硬切分 runtime 路径。仅凭 Pod Running 和环境变量并不能证明设备访问可用；在接受该环境之前，请运行一个具有代表性的 CANN device-open 或推理工作负载。

#运行软切分工作负载

软切分要求同时满足以下所有设置：

• 目标 node 具有 hami-vnpu-core=true；
• Pod 包含 huawei.com/vnpu-mode: hami-core；
• Pod 设置了 runtimeClassName: ascend；
• 工作负载请求数量加内存，并且可选地请求型号对应的 core 资源；
• 工作负载镜像提供 bash，注入的 PostStart hook 会使用它启动 limiter。

下面的 Ascend 310P3 示例请求 4096 MiB，并提供 core 值 1：

apiVersion: v1
kind: Pod
metadata:
  name: hami-ascend310p-soft-slice
  annotations:
    huawei.com/vnpu-mode: hami-core
spec:
  schedulerName: hami-scheduler
  runtimeClassName: ascend
  restartPolicy: Never
  containers:
    - name: npu-workload
      image: <your-ascend-image>
      command: ["/bin/sh", "-c"]
      args:
        - |
          env | grep -E 'ASCEND_VISIBLE_DEVICES|NPU_MEM_QUOTA|NPU_PRIORITY'
          grep -F /hami-vnpu-core/libvnpu.so /etc/ld.so.preload
          sleep 3600
      resources:
        requests:
          huawei.com/Ascend310P: "1"
          huawei.com/Ascend310P-memory: "4096"
          huawei.com/Ascend310P-core: "1"
        limits:
          huawei.com/Ascend310P: "1"
          huawei.com/Ascend310P-memory: "4096"
          huawei.com/Ascend310P-core: "1"

创建并检查 Pod：

kubectl apply -f hami-ascend310p-soft-slice.yaml
kubectl get pod hami-ascend310p-soft-slice -o wide
kubectl get pod hami-ascend310p-soft-slice \
  -o go-template='scheduler={{ .spec.schedulerName }}{{ "\n" }}runtimeClass={{ .spec.runtimeClassName }}{{ "\n" }}mode={{ index .metadata.annotations "huawei.com/vnpu-mode" }}{{ "\n" }}allocation={{ index .metadata.annotations "hami.io/Ascend310P-devices-allocated" }}{{ "\n" }}'
kubectl get pod hami-ascend310p-soft-slice \
  -o jsonpath='{.spec.containers[0].lifecycle.postStart.exec.command}{"\n"}'
kubectl exec hami-ascend310p-soft-slice -- /bin/sh -c '
  test -n "$ASCEND_VISIBLE_DEVICES" &&
  test "$NPU_MEM_QUOTA" = 4096 &&
  test "$NPU_PRIORITY" = 1 &&
  grep -F /hami-vnpu-core/libvnpu.so /etc/ld.so.preload
'

结果解释如下：

• mode=hami-core 以及非空的分配注解，确认了 HAMi 软切分调度和分配。
• 注入的 PostStart hook 和 libvnpu.so 预加载，确认选择了 HAMi vNPU runtime 路径。
• NPU_MEM_QUOTA=4096 是请求的软件内存配额。
• 可选的 core 资源由调度器以百分比形式表示，并注入为 NPU_PRIORITY。它控制相对计算调度权重；并非专用硬件 AI Core 隔离。

这些检查证明已选择软切分 runtime 路径，但 Pod Running 并不是端到端功能测试。请运行一个 CANN 内存分配或推理工作负载，并确认它可以访问分配的设备并满足请求的配额。

对于其他芯片型号，请从 hami-scheduler-device 获取资源键和分配注解后缀，并在创建工作负载前确认 node allocatable 资源中的容量。

#下一步

• Resource Keys
• Release Notes
• Troubleshooting