Ascend 310P validation
This report records the physical Atlas 300I Duo and Atlas 300I Pro results. Use the hardware validation requirements for shared evidence and claim rules.
Status
| Device | Level | Observed lifecycle | Date |
|---|---|---|---|
| Atlas 300I Duo, two Ascend 310P3 devices | Scale-to-zero verified | 0 → 1 → 2 → 0 | 2026-07-14 |
| Atlas 300I Pro | Scale-to-zero verified | Results consistent with the Duo path | Not separately recorded |
Both results cover the operator, gateway, Ascend Device Plugin, KEDA, model cache, and vLLM-Ascend. The detailed timings and two-device topology below are the Duo evidence; the Pro verification reproduced the same functional checks without a separately retained timing record.
Validated stack
| Item | Recorded value |
|---|---|
| Host | Arm64 Ubuntu 24.04 LTS |
| Accelerators | Two Ascend 310P3 devices, about 44 GB each, in an Atlas 300I Duo |
| Ascend stack | Driver 26.0.rc1; container CANN 9.1.0-beta.1; MindCluster device plugin v7.3.0 |
| Allocation | Standard non-mixed whole-device mode through huawei.com/Ascend310P |
| Kubernetes | K3s v1.36.2+k3s1; containerd 2.3.2-k3s2; KEDA 2.20.1 |
| Runtime | quay.io/ascend/vllm-ascend:v0.22.1rc1-310p |
| Noctaya | Operator and gateway 0.2.0-rc.1 |
| Model | Qwen/Qwen2.5-0.5B-Instruct; float16; context limit 2048; eager execution |
| Cache | NodeLocalPVC on a dedicated 120 GB ext4 data disk; prewarming enabled |
| Scaling | Maximum two replicas; queue target 1; activation timeout 10m; drain timeout 2m |
Observed evidence
| Check | Result |
|---|---|
| Device allocation | A torch_npu tensor operation passed on an allocated 310P3 device. |
| Cold and warm inference | The cold stream completed in 182.04s; the warm request completed in 0.692s. |
| Scale-out | Demand produced 0 → 1 → 2 → 0; two Ready Pods used distinct devices and served requests without restarts. |
| Admission | Reject mode returned HTTP 503 with Retry-After; a full 100-request queue returned HTTP 429 for five additional requests. |
| Drain | A 256-token stream completed with [DONE] after its serving Pods were deleted. |
| Recovery | No-op apply, component replacement, Helm upgrade, two host reboots, cache persistence, and device recovery passed. |
Reproduce the Duo path
Prepare the driver, CANN, and device plugin according to the vLLM-Ascend 310P guide, vLLM-Ascend installation guide, 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 standard 310P capacity and label the verified product:
kubectl get nodes \
-o custom-columns='NAME:.metadata.name,ASCEND310P:.status.allocatable.huawei\.com/Ascend310P'
kubectl label node <duo-node> accelerator=huawei-Ascend310P --overwrite
kubectl label node <duo-node> \
serving.noctaya.io/ascend-product=atlas-300i-duo --overwrite
kubectl get node <duo-node> -L accelerator,serving.noctaya.io/ascend-product
From the repository root, deploy the Duo profile:
export NAMESPACE=noctaya-310p-validation
export SERVICE=qwen-310p-duo-validation
kubectl create namespace "$NAMESPACE" --dry-run=client -o yaml | kubectl apply -f -
kubectl apply -k examples/ascend/310p-duo -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,\"messages\":[{\"role\":\"user\",\"content\":\"Reply with: Noctaya 310P validation passed\"}]}"
Retain the cold response, [DONE], 0 → 1 → 2 → 0, and device-plugin evidence that the two Ready Pods received distinct 310P3 devices.
Device-specific constraints
- Keep
--dtype=float16; the validated 310P3 path failed on the model's default BF16 operator. - Keep
--max-model-len=2048; automatic context sizing can create an excessive quadratic attention mask on this runtime. - Mixed insertion resources such as
huawei.com/Ascend310P-IProare outside this profile. - Keep product-specific node labels so the Duo and Pro runtime profiles cannot be selected interchangeably.