#Request HAMi Resources

HAMi resources are requested through Kubernetes resource requests and limits. The resource names depend on the backend and product configuration.

Start with Backend Paths if you need to confirm whether the workload should use HAMi on NVIDIA GPU, HAMi on Ascend NPU, or HAMi on Ascend vNPU.

Before creating a workload, confirm the actual resource keys from the current delivery package and backend configuration. Node allocatable resources confirm the count capacity; scheduler-only memory and core keys might appear only in the backend configuration.

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

Use the same keys in workload requests, limits, and ACP quota metadata. For extended resources, set the same value in requests and limits.

#Choose a workload manifest

Each backend scenario owns its runnable Pod structure and result interpretation:

Use Resource Keys for key meanings and units. Use Workload Controls for optional NVIDIA annotations, scheduling policies, and HAMi-Core debug settings. For HAMi-managed dynamic MIG, see Configure Dynamic MIG.

#ACP quota and application pages

ACP can show HAMi resource fields in project, namespace, and workload pages after the corresponding resource metadata is registered in the cluster. See Accelerator Resource Quota.

#Avoid mixed allocation paths

Do not mix resource names from different accelerator sharing or direct-allocation paths in one workload unless the current product version explicitly supports the combination. If a node exposes both direct and HAMi resource names for the same physical devices, resolve the Device Plugin ownership conflict before creating workloads.