Ascend 910B3 validation

This report records Noctaya's single-device Ascend 910B3 result. Use the hardware validation requirements for shared evidence and claim rules.

Result

Device	Level	Observed lifecycle	Date
One Ascend 910B3, 64 GB	Scale-to-zero verified	0 → 1 → 0	2026-07-15

The run covered the operator, gateway, Ascend Device Plugin, KEDA, model prewarming and caching, admission, draining, and recovery. The server exposed one device, so this result does not validate multi-replica scaling.

Validated stack

Item	Recorded value
Host	Arm64 Ubuntu 24.04 LTS; 16-core HiSilicon TaiShan-v110
Accelerator	One Ascend 910B3, chip version V1, 64 GB HBM
Ascend stack	Firmware 7.7.0.1.231; driver 26.0.rc1; CANN 9.0.0; MindCluster device plugin v7.3.0
Allocation	Standard non-mixed whole-device mode through huawei.com/Ascend910
Kubernetes	K3s v1.36.2+k3s1; containerd 2.3.2-k3s2; Helm v4.2.3; KEDA 2.20.1
Runtime	quay.io/ascend/vllm-ascend:v0.21.0rc1; vLLM 0.21.0
Noctaya	Operator and gateway 0.2.0-rc.1
Model	Qwen/Qwen2.5-0.5B-Instruct; context limit 2048; eager execution
Cache	NodeLocalPVC on a dedicated 120 GB ext4 data disk; prewarming enabled
Scaling	Maximum one replica; queue target 1; activation timeout 10m; drain timeout 60s

Observed evidence

Check	Result
Device allocation	MindCluster advertised one healthy device and assigned it to the backend.
Prewarm	The Job downloaded 954 MB in 66s without requesting an NPU.
Cold start	A cold stream returned heartbeats, real NPU tokens, [DONE], and HTTP 200 in 230.99s.
Warm path	JSON and streaming requests completed in 0.245s and 0.293s.
Scale-down	KEDA returned the backend to zero and released the NPU; cached readiness took 2m47s.
Admission	Reject mode returned HTTP 503 with Retry-After; a full 100-request queue returned HTTP 429.
Drain	15s aborted generation; 60s completed 129 chunks with [DONE], establishing the profile baseline.
Recovery	No-op apply, gateway replacement, operator restart, Helm upgrade, and host reboot passed.

Reproduce the core path

Prepare the host and device plugin according to the vLLM-Ascend installation guide, vLLM-Ascend support guidance, and Ascend Device Plugin guide. Install KEDA and Noctaya separately by following Getting started.

Capture the host and cluster baseline:

uname -a
cat /etc/os-release
npu-smi info
cat /usr/local/Ascend/driver/version.info
cat /etc/ascend_install.info
kubectl version
kubectl get crd scaledobjects.keda.sh

Confirm device capacity and label the exact product:

kubectl get nodes \
  -o custom-columns='NAME:.metadata.name,ASCEND910:.status.allocatable.huawei\.com/Ascend910'
kubectl label node <npu-node> accelerator=huawei-Ascend910 --overwrite
kubectl label node <npu-node> \
  serving.noctaya.io/ascend-product=ascend-910b3 --overwrite
kubectl get node <npu-node> -L accelerator,serving.noctaya.io/ascend-product

From the repository root, deploy the profile:

export NAMESPACE=noctaya-910b-validation
export SERVICE=qwen-910b-validation

kubectl create namespace "$NAMESPACE" --dry-run=client -o yaml | kubectl apply -f -
kubectl apply -k examples/ascend/910b3 -n "$NAMESPACE"
kubectl get llmservice,pvc,job,deploy,pod,scaledobject -n "$NAMESPACE" -w

Expose the gateway and send a cold streaming request:

kubectl port-forward -n "$NAMESPACE" "service/$SERVICE" 8080:80

curl -N http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d "{\"model\":\"$SERVICE\",\"stream\":true,\"max_tokens\":32,\"messages\":[{\"role\":\"user\",\"content\":\"Reply with: Noctaya 910B3 validation passed\"}]}"

Retain the heartbeat response, [DONE], 0 → 1 → 0, and npu-smi info evidence that the serving process disappears after scale-down. For drain validation, delete the active backend Pod during a long stream and confirm completion before the 60s timeout.

Claim boundary

• The result applies to one whole Ascend 910B3 on the recorded stack.
• It does not validate multiple devices, tensor parallelism, sharing, or another Ascend 910 model.
• A multi-replica claim requires distinct device allocations and an observed 1 → N → 0.