Alauda Ascend NPU
  • English

    • Resource Keys

    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.

    TOC

    Kubernetes extended resourcesCombined with HAMiNode labelsNode annotationsACP quota fields

    Kubernetes extended resources

    Resource keyMeaningUnit
    huawei.com/Ascend910Common Ascend 910-family device count key. A 910B or 910B4 node may still report this key.count
    Other huawei.com/Ascend* keysEnvironment- or package-specific keys reported by the installed device plugincount
    huawei.com/Ascend310PAscend 310P device countcount

    These resource keys are reported by the device plugin and consumed by workload resources.limits. Always confirm the exact key from node allocatable resources in the target workload cluster:

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

    The chip product label and the Kubernetes resource key are not always the same string.

    For example, a node whose chip product is Ascend 910B may expose huawei.com/Ascend910.

    Combined with HAMi

    If NPU Operator prepares the Ascend base for a HAMi deployment, use only the resource keys exposed by the selected device exposure owner for the target nodes.

    A node selected by HAMi Ascend Device Plugin commonly uses the HAMi Ascend selector, such as ascend=on. Keep the NPU Operator Ascend Device Plugin disabled or scoped away from the same devices unless the installed product versions explicitly document and validate that topology.

    The two components can have similar names and may both use huawei.com/Ascend* resource keys, but they serve different product paths:

    ComponentProduct pathPurpose
    NPU Operator Ascend Device PluginAscend NPU vendor base pathReports NPU resources for direct NPU allocation.
    HAMi Ascend Device PluginHAMi Ascend or HAMi Ascend vNPU pathExposes Ascend devices through HAMi-managed allocation or vNPU behavior.

    If you do not use Alauda Build of NPU Operator for full lifecycle management, install the device plugin that matches the workload model yourself. Use Huawei's Ascend Device Plugin when workloads request NPUs directly. Use HAMi Ascend Device Plugin when workloads need HAMi virtualization or slicing semantics.

    Use Huawei MindCluster as the upstream reference for the Huawei path. For HAMi-managed Ascend behavior, continue in the HAMi documentation. In Alauda deployments, use the component versions, images, and installation parameters delivered with the current Alauda package.

    Node labels

    The placement labels below are consumed by NPU component manifests. NPU Feature Discovery normally derives and reconciles them automatically. Add them manually only as a fallback when discovery cannot run on an intended node; manually assigned values can be replaced or removed when discovery later reconciles that node.

    LabelPurpose
    masterselector=dls-master-nodeSelects control nodes used by NPU components. Automatically assigned to nodes with node-role.kubernetes.io/control-plane when NPU Feature Discovery runs on them.
    workerselector=dls-worker-nodeSelects worker nodes that should host NPU components. Automatically assigned to non-control-plane nodes; an NPU-equipped control-plane node can also receive it.
    openfuyao.com/npu.presentIndicates NPU presence after discovery.

    Node annotations

    AnnotationPurpose
    npu.openfuyao.com/approve-reboot=trueApproves an operator-managed node reboot for upgrade or recovery. Use kubectl annotate node, not kubectl label node.

    ACP quota fields

    If ACP quota pages need to show an NPU resource, configure the matching ACP resource metadata. See Accelerator Resource Quota.