#Request NPU Resources

After Alauda Build of NPU Operator is installed, workloads request Ascend NPUs through Kubernetes extended resource names.

This page covers direct NPU allocation through Alauda Build of NPU Operator. For HAMi sharing, virtualization, vNPU behavior, or HAMi-specific resource keys on Ascend devices, use the HAMi documentation.

#Resource keys

The resource key must match what the device plugin reports in node allocatable resources. Do not derive the key only from the chip product name. For example, an Ascend 910B node may still report huawei.com/Ascend910.

kubectl get node ${nodeName} -o jsonpath='{.status.allocatable}'

#Workload example

With the default admission webhook enabled, requesting the NPU resource is enough in the submitted manifest. The webhook adds runtimeClassName: ascend before the Pod is created, and the corresponding runtime handler injects the device and Driver files.

If the webhook is disabled, set runtimeClassName: ascend explicitly.

apiVersion: v1
kind: Pod
metadata:
  name: npu-workload
spec:
  restartPolicy: Never
  containers:
  - name: app
    image: <your-npu-image>
    resources:
      limits:
        <huawei.com/Ascend-resource-key>: 1

For example, if the node reports huawei.com/Ascend310P, use:

resources:
  limits:
    huawei.com/Ascend310P: 1

#Quota fields in ACP

If the node reports the resource but ACP quota pages do not show it, configure accelerator resource metadata in ACP. See Accelerator Resource Quota.

#RuntimeClass behavior

After creating a workload, inspect the admitted Pod:

kubectl get pod npu-workload -o jsonpath='{.spec.runtimeClassName}{"\n"}'

The result should be ascend. A manifest that already sets this RuntimeClass remains valid; the webhook leaves an explicitly configured value unchanged.