Alauda Build of HAMi

Resource Keys

HAMi resource keys depend on the backend. Use the keys delivered and validated by the installed product package.

Choose the backend path first:

TOC

NVIDIA backendRelated NVIDIA keysNode labelsAscend backendsNode labelsACP quota fields

NVIDIA backend

Resource keyMeaningUnit
nvidia.com/gpuallocNumber of physical GPUs used as the allocation basecount
nvidia.com/gpucoresCompute ratio requested per physical GPUpercent
nvidia.com/gpumemMemory requested per physical GPUMi
nvidia.com/gpumem-percentageMemory ratio requested per physical GPUpercent

Use either nvidia.com/gpumem or nvidia.com/gpumem-percentage in a container, not both.

For NVIDIA backend workload annotations and environment variables, see Workload Controls.

Some environments may also contain resource keys from other NVIDIA sharing technologies, such as MPS or legacy vCUDA resources. Do not mix these keys with HAMi resource keys in the same workload unless the product documentation explicitly supports the combination.

Node labels

LabelPurpose
gpu=onSelects nodes for HAMi components in the common NVIDIA backend installation path.

For physical NVIDIA GPU allocation without HAMi sharing semantics, use Alauda Build of NVIDIA GPU Device Plugin and the nvidia.com/gpu resource key.

Ascend backends

Ascend NPU and Ascend vNPU resource keys are model-specific. They may use the same huawei.com/Ascend* namespace as the direct Ascend NPU path, which is why only one Device Plugin can own a set of Ascend devices.

HAMi v2.9.0 and HAMi Ascend Device Plugin v1.4.0 use the following resource family for Ascend 310P3 hardware:

Resource keyMeaningUnit
huawei.com/Ascend310PNumber of physical devices used as the allocation base. Request this key alone for whole-card allocation.count
huawei.com/Ascend310P-memoryMemory requested per virtual device for hard or soft slicing.Mi
huawei.com/Ascend310P-coreCompute share used only by hami-core soft slicing.percent

Ascend 910-series devices use model-specific families such as huawei.com/Ascend910A, huawei.com/Ascend910B3, and huawei.com/Ascend910B4-1, with corresponding -memory and -core keys defined by the installed scheduler configuration. Obtain the exact count, memory, core, and allocation-annotation names from hami-scheduler-device. Use node allocatable resources to confirm the count capacity; scheduler-only memory and core keys might not appear there.

Hard-slice template names such as vir01 are runtime template values, not Kubernetes resource keys. Available templates and memory sizes are model-specific. See Run a hard-slice workload for the Ascend 310P3 example.

Node labels

LabelPurpose
ascend=onSelects nodes for HAMi Ascend components in common Ascend NPU and Ascend vNPU backend examples.

Do not assume that the chip product name and the Kubernetes resource key are the same string. For example, an Ascend 910-series node may expose huawei.com/Ascend910A, huawei.com/Ascend910B3, or another huawei.com/Ascend* key depending on the installed package.

After installation, inspect the scheduler configuration and confirm the count resource on the selected node:

kubectl -n <hami-namespace> get configmap hami-scheduler-device -o yaml
kubectl get node <node-name> -o jsonpath='{.status.allocatable}'

Use only the resource family that matches the target hardware mapping in hami-scheduler-device, and confirm that the node reports the expected count capacity before creating workloads.

ACP quota fields

If ACP quota pages need to show HAMi resources, configure the matching ACP resource metadata. Register ACP quota metadata with the same keys that users will request in workloads. See Accelerator Resource Quota.