#Configure Ascend Slicing Mode

Use this procedure to switch a HAMi-managed Ascend node between fixed-template hard slicing and hami-core soft slicing. Whole-card workloads are selected by a count-only request and can run in either node mode.

#Understand the effective configuration

The v1.4.0 Alauda delivery normally has spec.config.create: false and reuses the HAMi-owned hami-scheduler-device ConfigMap. In this layout, changing only spec.hamiVnpuCore.enabled does not update the shared ConfigMap and therefore does not change the effective node mode.

Use spec.nodeConfig on the HAMiAscendDevicePlugin resource for an explicit per-node setting. The operator renders that string into hami-device-node-config, and the matching node entry overrides the global value.

Check the current owner and effective values:

kubectl get hamiadp -A
kubectl -n <hami-namespace> get hamiadp <instance-name> \
  -o jsonpath='{.spec.config.create}{"\n"}{.spec.config.existingDeviceConfigMapName}{"\n"}{.spec.hamiVnpuCore.enabled}{"\n"}{.spec.nodeConfig}{"\n"}'
kubectl -n <hami-namespace> get configmap hami-scheduler-device -o yaml
kubectl get node <node-name> \
  -o go-template='hami-vnpu-core={{ index .metadata.annotations "hami-vnpu-core" }}{{ "\n" }}'

Interpret the node annotation only for partial-memory requests:

• hami-vnpu-core=false: fixed-template hard slicing;
• hami-vnpu-core=true: hami-core soft slicing;
• whole card: selected by requesting only the count resource, regardless of this annotation.

#Update the custom resource

Edit the existing instance; do not create a second HAMiAscendDevicePlugin instance:

kubectl -n <hami-namespace> edit hamiadp <instance-name>

Set spec.nodeConfig as a multiline string. Preserve entries for other nodes when editing the list.

To enable soft slicing on one node:

spec:
  config:
    create: false
    deviceConfigMapName: hami-scheduler-device
    existingDeviceConfigMapName: hami-scheduler-device
  nodeConfig: |
    nodes:
      - name: "<node-name>"
        hami-vnpu-core: true

To select hard slicing instead, set the node value to false:

spec:
  nodeConfig: |
    nodes:
      - name: "<node-name>"
        hami-vnpu-core: false

Use the exact Kubernetes Node name reported by kubectl get nodes. nodeConfig is a YAML-formatted string, so the nodes list must remain indented under the | block.

For an instance whose nodeConfig contains only this node, the equivalent complete patch commands are:

# Enable soft slicing on the target node.
kubectl -n <hami-namespace> patch hamiadp <instance-name> \
  --type merge \
  --patch '{"spec":{"nodeConfig":"nodes:\n  - name: \"<node-name>\"\n    hami-vnpu-core: true"}}'

# Select hard slicing on the target node.
kubectl -n <hami-namespace> patch hamiadp <instance-name> \
  --type merge \
  --patch '{"spec":{"nodeConfig":"nodes:\n  - name: \"<node-name>\"\n    hami-vnpu-core: false"}}'

These merge patches replace the complete spec.nodeConfig string. When the string already contains other nodes, use kubectl edit and preserve every required entry instead of applying the single-node patch.

#Configure logical scheduling slots

vDeviceCount is the number of logical scheduling slots reported for each physical NPU. It does not split memory into equal pieces and is not a universal soft-slice default.

Leave it unset to use the value derived from the installed device configuration:

memoryAllocatable / memory of the smallest hard-slice template

For example, the v1.4.0 configuration derives 4 slots for Ascend 910B4-1 from 65536 / 16384. Set a different integer only when the capacity plan intentionally permits that many concurrent allocations. The following value 20 is an operator-selected concurrency policy, not the Ascend 910B4-1 default:

spec:
  nodeConfig: |
    nodes:
      - name: "<ascend-910b4-1-node-name>"
        hami-vnpu-core: true
        vDeviceCount: 20

Do not quote vDeviceCount as a string. Each workload remains constrained by its memory and optional core requests.

#Wait for the change to take effect

The operator-managed ConfigMap checksum normally triggers a Device Plugin rollout after spec.nodeConfig changes:

kubectl -n <hami-namespace> rollout status \
  daemonset/hami-ascend-device-plugin --timeout=5m
kubectl -n <hami-namespace> get configmap hami-device-node-config -o yaml
kubectl get node <node-name> \
  -o go-template='hami-vnpu-core={{ index .metadata.annotations "hami-vnpu-core" }}{{ "\n" }}'

If the custom resource and generated ConfigMap contain the intended value but the DaemonSet did not roll out, restart only the operator-managed Device Plugin:

kubectl -n <hami-namespace> rollout restart \
  daemonset/hami-ascend-device-plugin
kubectl -n <hami-namespace> rollout status \
  daemonset/hami-ascend-device-plugin --timeout=5m

Do not restart the HAMi scheduler or application workloads merely to reload hami-device-node-config. Do not edit the generated ConfigMap as the normal update path; change its owning custom resource instead.

#Verify with a workload

• For hard slicing, use the hard-slice manifest.
• For soft slicing, use the soft-slice manifest.
• For whole-card allocation, use the whole-card manifest.