#HAMi on Ascend NPU (whole-card)

Use this scenario when Ascend workloads need exclusive whole-card allocation but should still use HAMi scheduling and resource management. For direct Ascend allocation without HAMi, use Request Ascend NPU resources directly. For hard or soft slicing, use HAMi on Ascend vNPU.

#Before you create a workload

Confirm that:

• Alauda Build of HAMi is installed with Enable Ascend enabled;
• Alauda Build of HAMi Ascend Device Plugin is installed and selects the target node, commonly with ascend=on;
• the NPU Operator Driver, OCI Runtime, and ascend RuntimeClass remain available, but its native Ascend Device Plugin is disabled for this node pool.

Check the exposed resources:

kubectl get node <node-name> \
  -o jsonpath='{.status.allocatable}'

The node must report the model-specific Ascend count resource. A count-only request selects whole-card allocation regardless of the node's partial-memory mode. Use HAMi on Ascend vNPU and Configure Ascend Slicing Mode when the workload needs hard or soft slicing.

#Run a whole-card workload

The following Pod manifest uses Ascend 310P3 as a concrete example. This hardware model is exposed through the huawei.com/Ascend310P resource key delivered with HAMi v2.9.0 and HAMi Ascend Device Plugin v1.4.0. Replace the image with an ARM64 Ascend image that contains the CANN libraries and npu-smi required by the test application.

apiVersion: v1
kind: Pod
metadata:
  name: hami-ascend310p-whole
spec:
  schedulerName: hami-scheduler
  runtimeClassName: ascend
  restartPolicy: Never
  containers:
    - name: npu-workload
      image: <your-ascend-image>
      command: ["/bin/sh", "-c"]
      args:
        - |
          npu-smi info
          sleep 3600
      resources:
        requests:
          huawei.com/Ascend310P: "1"
        limits:
          huawei.com/Ascend310P: "1"

Do not add a memory resource, core resource, or huawei.com/vnpu-mode annotation to this whole-card request.

Create and inspect the Pod:

kubectl apply -f hami-ascend310p-whole.yaml
kubectl get pod hami-ascend310p-whole -o wide
kubectl get pod hami-ascend310p-whole \
  -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-whole -- /bin/sh -c '
  test -z "$ASCEND_VNPU_SPECS" &&
  test -z "$NPU_MEM_QUOTA" &&
  npu-smi info
'

Interpret the results as follows:

• scheduler=hami-scheduler and runtimeClass=ascend confirm the expected scheduling and Ascend runtime paths.
• A non-empty hami.io/Ascend310P-devices-allocated annotation confirms that HAMi allocated the device.
• The absence of ASCEND_VNPU_SPECS and NPU_MEM_QUOTA, together with the count-only resource request, confirms that the workload did not select hard or soft slicing.
• Successful npu-smi info confirms basic device access. Run a representative CANN or inference workload for end-to-end verification.

For an Ascend 910-series device, obtain the model mapping from hami-scheduler-device, confirm its count resource in node allocatable resources, and replace huawei.com/Ascend310P plus the allocation-annotation suffix with those values.

#Next steps

• HAMi on Ascend vNPU
• Resource Keys
• Troubleshooting