版本管理策略#
自 vLLM 0.7.x 版本起，vLLM Ascend 插件项目（vllm-project/vllm-ascend）遵循 PEP 440 规范，以匹配 vLLM（vllm-project/vllm）的版本进行发布。
vLLM Ascend 插件版本#
每个 vLLM Ascend 版本均采用 v[主版本号].[次版本号].[修订号][rcN][.postN] 的格式（例如 v0.7.3rc1、v0.7.3、v0.7.3.post1）。
正式版本：通常每三个月计划发布一次，并与 vLLM 上游发行周期和昇腾软件产品路线图保持协调。
预发布版本：通常按需发布，使用
rcN标识以表示第 N 个候选发布版本，旨在支持用户在正式版本发布前进行早期测试。补丁版本：通常按需发布，用于修复正式版本中的小错误。与 PEP-440 关于后续版本的说明 不同，这些版本包含实际的错误修复。因为正式版本号必须严格与 vLLM 的正式版本格式（
v[主版本号].[次版本号].[修订号]）保持一致，任何补丁版本都必须以该正式版本的修订形式发布。
例如：
v0.7.x：首个与 vLLMv0.7.x版本匹配的正式版本。v0.7.3rc1：vLLM Ascend 的第一个预发布版本。v0.7.3.post1：如果v0.7.3版本存在一些小错误，将作为其补丁版本发布。
版本兼容性矩阵#
以下是 vLLM Ascend 版本的兼容性矩阵：
vLLM Ascend |
vLLM |
Python |
Stable CANN |
PyTorch/torch_npu |
Triton Ascend |
|---|---|---|---|---|---|
v0.13.0 |
v0.13.0 |
>= 3.10, < 3.12 |
8.5.0 |
2.8.0 / 2.8.0.post2 |
3.2.0 |
v0.13.0rc2 |
v0.13.0 |
>= 3.10, < 3.12 |
8.5.0 |
2.8.0 / 2.8.0.post1 |
3.2.0 |
v0.13.0rc1 |
v0.13.0 |
>= 3.10, < 3.12 |
8.3.RC2 |
2.8.0 / 2.8.0 |
|
v0.11.0 |
v0.11.0 |
>= 3.9 , < 3.12 |
8.3.RC2 |
2.7.1 / 2.7.1.post1 |
|
v0.12.0rc1 |
v0.12.0 |
>= 3.10, < 3.12 |
8.3.RC2 |
2.8.0 / 2.8.0 |
|
v0.11.0rc3 |
v0.11.0 |
>= 3.9, < 3.12 |
8.3.RC2 |
2.7.1 / 2.7.1.post1 |
|
v0.11.0rc2 |
v0.11.0 |
>= 3.9, < 3.12 |
8.3.RC2 |
2.7.1 / 2.7.1 |
|
v0.11.0rc1 |
v0.11.0 |
>= 3.9, < 3.12 |
8.3.RC1 |
2.7.1 / 2.7.1 |
|
v0.11.0rc0 |
v0.11.0rc3 |
>= 3.9, < 3.12 |
8.2.RC1 |
2.7.1 / 2.7.1.dev20250724 |
|
v0.10.2rc1 |
v0.10.2 |
>= 3.9, < 3.12 |
8.2.RC1 |
2.7.1 / 2.7.1.dev20250724 |
|
v0.10.1rc1 |
v0.10.1/v0.10.1.1 |
>= 3.9, < 3.12 |
8.2.RC1 |
2.7.1 / 2.7.1.dev20250724 |
|
v0.10.0rc1 |
v0.10.0 |
>= 3.9, < 3.12 |
8.2.RC1 |
2.7.1 / 2.7.1.dev20250724 |
|
v0.9.2rc1 |
v0.9.2 |
>= 3.9, < 3.12 |
8.1.RC1 |
2.5.1 / 2.5.1.post1.dev20250619 |
|
v0.9.1 |
v0.9.1 |
>= 3.9, < 3.12 |
8.2.RC1 |
2.5.1 / 2.5.1.post1 |
|
v0.9.1rc3 |
v0.9.1 |
>= 3.9, < 3.12 |
8.2.RC1 |
2.5.1 / 2.5.1.post1 |
|
v0.9.1rc2 |
v0.9.1 |
>= 3.9, < 3.12 |
8.2.RC1 |
2.5.1 / 2.5.1.post1 |
|
v0.9.1rc1 |
v0.9.1 |
>= 3.9, < 3.12 |
8.1.RC1 |
2.5.1 / 2.5.1.post1.dev20250528 |
|
v0.9.0rc2 |
v0.9.0 |
>= 3.9, < 3.12 |
8.1.RC1 |
2.5.1 / 2.5.1 |
|
v0.9.0rc1 |
v0.9.0 |
>= 3.9, < 3.12 |
8.1.RC1 |
2.5.1 / 2.5.1 |
|
v0.8.5rc1 |
v0.8.5.post1 |
>= 3.9, < 3.12 |
8.1.RC1 |
2.5.1 / 2.5.1 |
|
v0.8.4rc2 |
v0.8.4 |
>= 3.9, < 3.12 |
8.0.0 |
2.5.1 / 2.5.1 |
|
v0.7.3.post1 |
v0.7.3 |
>= 3.9, < 3.12 |
8.1.RC1 |
2.5.1 / 2.5.1 |
|
v0.7.3 |
v0.7.3 |
>= 3.9, < 3.12 |
8.1.RC1 |
2.5.1 / 2.5.1 |
备注
如果您使用 v0.7.3，请务必同时安装 mindie-turbo。
对于 vLLM Ascend 的 main 分支，我们通常会使其与最新的 vLLM 发行版以及较新的 vLLM 提交哈希保持兼容。请注意，此表会定期更新，请经常查看。
vLLM Ascend |
vLLM |
Python |
Stable CANN |
PyTorch/torch_npu |
|---|---|---|---|---|
main |
2f4e6548efec402b913ffddc8726230d9311948d，v0.13.0 标签 |
>= 3.10, < 3.12 |
8.3.RC2 |
2.8.0 / 2.8.0 |
发布周期#
发布展示#
日期 |
事件 |
|---|---|
2026.02.06 |
v0.13.0 Final release, 0.13.0 |
2026.01.24 |
Release candidates, v0.13.0rc2 |
2025.12.27 |
Release candidates, v0.13.0rc1 |
2025.12.16 |
v0.11.0 正式版本，v0.11.0 |
2025.12.13 |
候选发布版本，v0.12.0rc1 |
2025.12.03 |
候选发布版本，v0.11.0rc3 |
2025.11.21 |
候选发布版本，v0.11.0rc2 |
2025.11.10 |
候选发布版本，v0.11.0rc1 |
2025.09.30 |
候选发布版本，v0.11.0rc0 |
2025.09.16 |
候选发布版本，v0.10.2rc1 |
2025.09.04 |
候选发布版本，v0.10.1rc1 |
2025.09.03 |
v0.9.1 正式版本，v0.9.1 |
2025.08.22 |
候选发布版本，v0.9.1rc3 |
2025.08.07 |
候选发布版本，v0.10.0rc1 |
2025.08.04 |
候选发布版本，v0.9.1rc2 |
2025.07.11 |
候选发布版本，v0.9.2rc1 |
2025.06.22 |
候选发布版本，v0.9.1rc1 |
2025.06.10 |
候选发布版本，v0.9.0rc2 |
2025.06.09 |
候选发布版本本，v0.9.0rc1 |
2025.05.29 |
v0.7.3 补丁版本，v0.7.3.post1 |
2025.05.08 |
v0.7.3 正式版本，v0.7.3 |
2025.05.06 |
候选发布版本，v0.8.5rc1 |
2025.04.28 |
候选发布版本，v0.8.4rc2 |
2025.04.18 |
候选发布版本，v0.8.4rc1 |
2025.03.28 |
候选发布版本，v0.7.3rc2 |
2025.03.14 |
候选发布版本，v0.7.3rc1 |
2025.02.19 |
候选发布版本，v0.7.1rc1 |
分支策略#
vLLM Ascend 包含两个分支：main 和 dev。
main：对应 vLLM 的 main 分支以及最新的 1 至 2 个发行版本。通过 Ascend CI 持续进行质量监控。
vX.Y.Z-dev：开发分支，随 vLLM 的部分新版本创建。例如，
v0.7.3-dev是 vLLMv0.7.3版本的开发分支。
为了尽可能降低维护成本，提交通常应先合并到 main 分支，然后再反向移植到 dev 分支。
维护分支与生命周期结束（EOL）#
下表列出了分支状态。
分支 |
时间范围 |
摘要 |
|---|---|---|
维护中 |
大约 2-3 个次版本 |
接收错误修复；生成发行版本；承诺提供持续集成（CI） |
未维护 |
由社区兴趣驱动 |
接收错误修复；不生成发行版本；不承诺提供持续集成（CI） |
生命周期结束（EOL） |
不适用 |
该分支不再接受更改 |
分支状态#
请注意，vLLM Ascend 仅针对特定的 vLLM 发行版本发布，而非所有版本。因此，您可能会注意到某些版本有对应的开发分支（例如 0.7.1-dev 和 0.7.3-dev），而其他版本则没有（例如 0.7.2-dev）。
通常，vLLM 的每个次版本（例如 0.7）都会对应一个 vLLM Ascend 版本分支，并支持其最新版本（例如 0.7.3），如下所示：
分支 |
状态 |
备注 |
|---|---|---|
main |
维护中 |
vLLM main 分支和 vLLM 0.12.0 标签的 CI 承诺 |
releases/v0.13.0 |
维护中 |
vLLM 0.13.0 版本的 CI 承诺 |
v0.11.0-dev |
维护中 |
vLLM 0.11.0 版本的 CI 承诺 |
v0.9.1-dev |
维护中 |
vLLM 0.9.1 版本的 CI 承诺 |
v0.7.3-dev |
维护中 |
vLLM 0.7.3 版本的 CI 承诺 |
v0.7.1-dev |
未维护 |
已被 v0.7.3-dev 取代 |
功能分支#
分支 |
状态 |
RFC 链接 |
计划合并时间 |
指导者 |
|---|---|---|---|---|
rfc/long_seq_optimization |
维护中 |
https://github.com/vllm-project/vllm/issues/22693 |
930 |
wangxiyuan |
分支：功能分支应以
rfc/为前缀，后接功能名称创建，例如rfc/feature-name。状态：功能分支的状态为
维护中，直至其被合并到 main 分支或被删除。RFC 链接：功能分支应随对应的 RFC Issue 一同创建。创建功能分支需要一份 RFC 并获得至少两名维护者的批准。
计划合并时间：功能分支的最终目标是被合并到 main 分支。如果超过三个月仍未合并，其指导维护者应评估是否删除该分支。
指导者：指导者应是一名 vLLM Ascend 维护者，负责该功能分支。
向后兼容性#
对于 main 分支，vLLM Ascend 应与 vLLM 的 main 分支以及最新的 1 至 2 个发行版本协同工作。为确保向后兼容性，请遵循以下步骤：
main 分支和目标 vLLM 发行版（例如 vLLM 的 main 分支和 vLLM 0.8.4）均需通过 Ascend E2E CI 测试。
为确保代码变更与最新的 1 至 2 个 vLLM 发行版本兼容，vLLM Ascend 在代码内部引入了版本检查机制。该机制首先检查已安装的 vLLM 软件包版本，以决定使用哪段代码逻辑。如果用户遇到
InvalidVersion错误，可能意味着他们安装了开发版或可编辑版本的 vLLM 软件包。在这种情况下，我们提供了环境变量VLLM_VERSION，供用户指定要使用的 vLLM 软件包版本。文档变更应与最新的 1 至 2 个 vLLM 发行版本兼容。如有任何破坏性变更，应添加备注说明。
文档分支政策#
为了减少维护成本，所有分支的文档内容应保持一致，版本差异可以通过 docs/source/conf.py 中的变量进行控制。尽管这并非易事，但这是我们应当努力遵循的原则。
版本 |
用途 |
代码分支 |
|---|---|---|
最新 |
最新开发分支的文档 |
vX.Y.Z-dev（在第一个正式版本发布后将成为 |
版本 |
历史发行版本的文档 |
Git 标签，例如 vX.Y.Z[rcN] |
稳定版（尚未发布） |
最新正式发布分支的文档 |
首个正式发布后将会是 |
备注：
latest文档：匹配当前维护分支vX.Y.Z-dev（在首次正式发布后将为main）。持续更新，以确保适用于最新发布版本。version文档：对应特定的已发布版本（例如，v0.7.3、v0.7.3rc1）。发布后不再进行更新。stable文档（尚未发布）：官方发布版文档。发布后允许实时更新，通常基于 vX.Y.Z-dev。一旦稳定版文档可用，非稳定版本应显示一个顶部警告：您正在查看最新的开发预览文档。点击此处查看最新稳定版本文档。
软件依赖管理#
torch-npu：Ascend Extension for PyTorch（torch-npu）每 3 个月会在 PyPi 上发布一个稳定版本，每个月发布一个开发版本（即 POC 版本），每天发布一个 nightly 版本。PyPi 上的稳定版本可以用于 vLLM Ascend 的正式版本，月度开发版本只能用于 vLLM Ascend 的 RC（候选发布）版本以便快速迭代，nightly 版本不能用于 vLLM Ascend 的任何版本和分支。