Alauda Build of HAMi

Compatibility

Use this page to check the supported backend scope for Alauda Build of HAMi. It is not the full upstream HAMi or vendor hardware matrix.

TOC

Supported backend scopeACP compatibilitySupported combinationsAscend Driver and CANN compatibilityAvoid overlapping device exposure

Supported backend scope

BackendStatusNotes
NVIDIA GPUSupportedUses HAMi resource keys such as nvidia.com/gpualloc, nvidia.com/gpucores, and nvidia.com/gpumem.
Ascend NPUBackend support depends on the product packageUse HAMi on Ascend NPU and the current package or version page for the target ACP release.
Ascend vNPUBackend support depends on the product packageUse HAMi on Ascend vNPU only when the installed package explicitly supports the target hardware and ACP version.
Other community backendsNot listed in the current Alauda support scopeAn upstream backend or a device entry in configuration does not by itself make that backend an Alauda-supported product combination.

ACP compatibility

Check the release package for the supported ACP version, Kubernetes version, backend driver version, runtime integration, and exporter version.

The table below contains only product-supported combinations. Use upstream HAMi or hardware vendor documentation for broader backend details.

Supported combinations

Backend pathComponent combinationArchitectureACP versionsCapability
HAMi Ascend allocation on the NPU Operator baseAlauda Build of NPU Operator v26.6.0, Alauda Build of HAMi v2.9.0, and Alauda Build of HAMi Ascend Device Plugin v1.4.0ARM64v4.0-v4.3Whole-card allocation and Technical Preview hard/soft slicing for Ascend 310P3 and Ascend 910-series devices through model-specific huawei.com/Ascend* resource keys. NPU Operator keeps the Driver and Runtime but disables its native Device Plugin.

Hard and soft slicing in v1.4.0 are Technical Preview capabilities. Hard slicing has a known cleanup race that can reclaim a vNPU before the workload first accesses it. Use whole-card allocation when stable device access is required. HAMi slicing with a KVM or containerized Driver is outside the current supported scope. See the v1.4.0 known limitations.

The installed scheduler configuration provides model-specific mappings for Ascend 310P3 and Ascend 910-series devices, including 910A, 910B2, 910B3, 910B4-1, 910B4, and 910C. The Kubernetes resource key is derived from this mapping rather than directly from the hardware marketing name. Inspect hami-scheduler-device and the target node's allocatable resources to obtain the effective keys for the installed combination.

Ascend Driver and CANN compatibility

HAMi Ascend Device Plugin v1.4.0 requires Ascend Driver 25.5 or later. The Driver version is only one compatibility gate: the CANN libraries in the workload image must also be compatible with the installed Driver and, for soft slicing, with the libvnpu.so injected by HAMi.

For hami-core soft slicing, the CANN runtime in the workload image must provide the symbols required by the injected libvnpu.so. A workload image that does not provide rtStreamGetCaptureInfo cannot use this soft-slice path. This constraint is specific to the soft-slice runtime ABI and does not by itself determine whether the same image can use whole-card allocation.

Do not infer compatibility from a mutable image tag, successful scheduling, or Pod Running alone. Record the workload image digest, confirm the Driver and CANN combination recommended for that image, and run a representative CANN device-open, memory-allocation, or inference operation before accepting the environment.

Avoid overlapping device exposure

Before enabling HAMi-managed Ascend allocation, set NPUOperatorCtl.spec.devicePlugin.enabled to false and wait for the native ascend-device-plugin to leave the target nodes. Keep the NPU Operator Driver, OCI Runtime, RuntimeClass, and other required base components running. Use Choose a HAMi Deployment Scenario for the scenario matrix and Switch the Ascend Device Plugin Owner for the maintenance procedure.