RFC: Add Ascend NPU hardware support

[robellliu-dev]

Proposal

Add Huawei Ascend NPU as a first-class hardware family in the vLLM recipes site so recipes can explicitly declare validated Ascend profiles and render Ascend-specific install / Docker commands.

This is RFC-style because Ascend support touches the shared recipe vocabulary and command builder rather than a single model recipe.

Motivation

vLLM Ascend now publishes a dedicated backend and prebuilt containers, and its docs include Atlas A2/A3 deployment paths:

• vLLM Ascend installation docs: https://docs.vllm.ai/projects/ascend/en/latest/installation.html
• vLLM Ascend repo: https://github.com/vllm-project/vllm-ascend

Recipes currently model NVIDIA, AMD, Google TPU, and Intel CPU hardware. Ascend recipes need a similar way to express:

• hardware profiles such as Atlas 800I A2 / A3
• meta.hardware.<id>: verified | unsupported status
• brand-filtered dependencies via dependencies[].brand
• default vLLM Ascend install and container hints
• Ascend device mounts for Docker command rendering

Proposed shape

1. Add restricted hardware profiles for Ascend so they only appear when a recipe opts in via meta.hardware.
2. Add an ascend Docker/image brand key alongside nvidia, amd, tpu, and intel.
3. Render Ascend install hints using the vLLM Ascend backend:
   • vllm==0.19.1
   • vllm-ascend==0.19.1rc1
   • quay.io/ascend/vllm-ascend:v0.19.1rc1 for Atlas A2
   • quay.io/ascend/vllm-ascend:v0.19.1rc1-a3 for Atlas A3
4. Keep Ascend out of default hardware selection until a recipe is explicitly validated.

Open questions

• Should the taxonomy use brand: Ascend or Ascend NPU for recipe dependency filtering?
• Are Atlas 800I A2 and Atlas 800I A3 the right initial profile names for this site, or should the profiles be named around Ascend 910B / 910C instead?
• Should memory values be shown as aggregate NPU memory in the same vram_gb field, or should taxonomy eventually rename this to a more general accelerator-memory field?
• Which model recipe should be the first verified Ascend recipe? Candidate smoke tests could start with a small Qwen dense model, then expand to Qwen3 MoE / DeepSeek after validation.

Initial PR

I am preparing a small PR that adds the shared taxonomy and command-builder plumbing only. It does not mark any model as verified on Ascend yet.