The vLLM version must equal the plugin version, and two dependency lists disagree

One prerequisite has no version range at all

The prerequisite list is short and almost every line is an exact pin. Python is the exception, given as greater than or equal to 3.10 and less than 3.13. Everything else is fixed: CANN at exactly 9.1.0, PyTorch at exactly 2.10.0, TorchNPU at exactly 2.10.0.post4. The requirement files continue the same style with transformers pinned to 5.14.1, torchvision to 0.25.0, torchaudio to 2.10.0 and triton-ascend to 3.2.2, while xgrammar, compressed_tensors and fastapi carry lower bounds or upper bounds instead.

The last prerequisite is the one that shapes your operations: vLLM, at the same version as vllm-ascend. Not a compatible range, not a minimum. The host framework and the plugin move in lockstep, so there is no way to take a vLLM security or feature update independently, and every framework upgrade is also a plugin upgrade.

The recommended table entry is older than the newest published tag

The getting started table recommends a release candidate, v0.26.0rc1, and links a versioned quick start for it. The published tags tell a different story. There is a v0.27.1rc1 published 2026-09-29, and there is a v0.23.0.post1 published 2026-09-22, which is a post release on the 0.23 line landing between two newer candidates.

So three reasonable readings of latest give three answers. By version number the newest candidate is v0.27.1rc1. By publication date it is also v0.27.1rc1. By what the project recommends you start from it is v0.26.0rc1, and the news list agrees with the table, since its latest entry is the 2026/09 announcement for v0.26.0rc1 with nothing for the 0.27 line. The branch was pushed on 2026-10-04, so this is a live repository rather than a stale one; the inconsistency is in which version it points you at.

Two dependency lists that are told to mirror each other, and do not

The build configuration opens with the instruction that its contents should be mirrored in requirements.txt, and requirements.txt opens with the same instruction pointing back at pyproject.toml. Neither file actually mirrors the other. The build list carries attrs and googleapis-common-protos, which requirements.txt does not mention. The requirements file carries regex, torchaudio at 2.10.0, and memfabric_hybrid and memcache_hybrid at 1.2.0, none of which appear in the build list.

There is one more mismatch in the same category. torchvision appears in the build list with no version at all and in requirements.txt pinned to 0.25.0, next to a torch pin of exactly 2.10.0. So an environment built from one file and an environment built from the other are not the same environment, and neither is a superset of the other. The build list also carries a section that pins an older setuptools for pandas under the uv builder only, which means the third build path has its own constraints again.

Dockerfiles cover A3, 310P and A5, while the support list names A2, A3 and the 300I Duo

There are eight Dockerfiles at the repository root: a plain one, an openEuler one, and a hardware-suffixed pair each for 310p, a3 and a5, where the second of each pair is the openEuler variant. The prerequisite list names a different set of parts: the Atlas 800I A2 Inference series, the Atlas A2 Training series, the Atlas 800I A3 Inference series, the Atlas A3 Training series, and the Atlas 300I Duo, the last of which is the only entry carrying a stability label, marked Experimental.

So the image matrix and the support matrix overlap on A3 only. The 310P and A5 images have no entry in the prerequisites, and the A2 platforms and the experimental 300I Duo have no image file. The plain Dockerfile is where the defaults live: it takes a CANN base image at quay.io/ascend/cann with the version 9.1.0 tag and a Python 3.12 Ubuntu 22.04 suffix, and it clones vLLM from a tag argument whose default is v0.30.0, falling back to that tag when no commit is given.

The image's default vLLM tag is higher than anything the documentation recommends

That default is worth a second look, because it runs against the prerequisite rule. The supported-starting version in the documentation is v0.26.0rc1 of the plugin, and the prerequisites require the vLLM version to equal the plugin version. The Dockerfile's default vLLM tag is v0.30.0, which is higher than any plugin version the documentation names. A reader who builds the image without passing arguments gets whatever plugin version that Dockerfile pairs with the cloned framework, and nothing in the summary reconciles the two numbers.

The same block of build arguments is otherwise careful about where it fetches from. The PyTorch index argument defaults to the CPU wheel index, the Ascend index argument defaults to a Huawei mirror, and the CANN registry and version are both arguments, so the toolkit can be pointed elsewhere without editing the file. Two more arguments exist for the mooncake transfer engine package tag and the Ascend SoC version, which is the knob that selects the hardware target.

A C++ extension built by a setup.py adapted from vLLM's own

The repository's primary language is C++, and the Python package is only the shell around it. The root holds csrc/, a cmake/ directory and a CMakeLists.txt, pybind11 sits in the build requirements, and setup.py subclasses the setuptools extension and build commands to compile the native part. It also carries two helper functions whose names describe the build's behaviour: one loads a module from a file path at build time, and the other checks for a required environment variable and falls back to a default path, logging a warning that tells you to set the variable if you have customised the installation.

The file's header explains where it came from. It is marked as part of the vllm-ascend project and as adapted from the vLLM repository's setup.py, and it carries a 2025 Huawei Technologies copyright alongside the vLLM team's 2023 one. That is the practical reason the build reads CANN from the environment: the plugin compiles against the toolkit's own libraries, which is why CANN is pinned with an equality operator while almost nothing else in the stack is allowed to float.

Deep questions are routed to a wiki maintained by the community and by AI

The front page gives a whole section to DeepWiki and describes it as a dynamic knowledge base maintained by the community and by AI. It is positioned as the companion to the official documentation, which the same paragraph calls a quick start guide, and it promises architecture and design principles, source code interpretation, technical context and decision-making logic. That is a real division of labour being described: the versioned documentation gets you started, and something else answers why the code does what it does.

The versioned material lives in the repository and on the documentation site. mkdocs.yml and a readthedocs configuration sit at the root, the docs are built from the same repository, and the support matrix page is named twice as the authority for which models and features are covered. The model coverage claim itself is broad, covering Transformer-style, Mixture-of-Experts, Embedding and multi-modal models, but the sentence ends by sending you to the matrix for the detail rather than listing it.

Secret scanning, two markdown linters and five places for agent instructions

The linting and safety configuration is unusually complete for a repository this size. There is a gitleaks configuration at the root, so secrets are scanned, and a pre-commit configuration to run it. C++ formatting is handled by a clang-format file, Python typing by a mypy configuration with its own requirements file, spelling by a typos configuration, and Markdown by a markdownlint file plus a pymarkdown plugin block inside pyproject that switches six individual rules off.

Ruff carries the Python lint rules, selecting the pycodestyle, pyflakes, pyupgrade, bugbear, simplify, isort and logging-format sets and ignoring five specific complaints, including star imports, lambda assignment, zip without a strict argument, and unused loop variables. A line-length setting of 120 carries a TODO comment about it still. Alongside that sit five entries for machine instructions: AGENTS.md, CLAUDE.md, and the .claude/, .agents/ and .gemini/ directories, which suggests the same guidance is maintained in several formats on purpose.

Editorial conclusion

vLLM Ascend is the right choice if you have Ascend NPUs and a vLLM deployment that has to stay on them, and its pins are honest about that: the toolkit, PyTorch, TorchNPU and the host framework are all versioned, with the framework matched exactly. Three things to settle before you commit a cluster to it. Track the plugin version rather than assuming latest means the highest number, because the recommended table entry, the news list and the published tags currently disagree about what newest is. Reconcile the two dependency lists, since each contains packages the other omits. And check the hardware list against the Dockerfiles, because two of the image variants have no entry in the prerequisites and two of the documented platforms have no image. The support matrix page, not the summary, is the authority on which models and features are covered.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. vllm-project/vllm-ascend on GitHub