版本管理策略¶
自 vLLM 0.7.x 版本起，vLLM Ascend 插件项目（vllm-project/vllm-ascend）遵循 PEP 440 规范，以匹配 vLLM（vllm-project/vllm）的版本进行发布。
vLLM Ascend 插件版本¶
Each vLLM Ascend release is versioned as v[major].[minor].[micro][rcN][.postN] (such as
v0.7.3rc1, v0.7.3, v0.7.3.post1)
- 正式版本：通常每三个月计划发布一次，并与 vLLM 上游发行周期和昇腾软件产品路线图保持协调。
- 预发布版本：通常**按需发布**，使用 ](https://peps.python.org/pep-0440/#post-releases) 标识以表示第 N 个候选发布版本，旨在支持用户在正式版本发布前进行早期测试。
- 补丁版本：通常**按需发布**，用于修复正式版本中的小错误。与 [PEP-440 关于后续版本的说明
v[major].[minor].[micro]不同，这些版本包含实际的错误修复。因为正式版本号必须严格与 vLLM 的正式版本格式（v0.7.x）保持一致，任何补丁版本都必须以该正式版本的修订形式发布。
例如：
v0.7.x：首个与 vLLMv0.7.3rc1版本匹配的正式版本。v0.7.3.post1：vLLM Ascend 的第一个预发布版本。v0.7.3：如果 ](https://pypi.org/project/mindie-turbo) 版本存在一些小错误，将作为其补丁版本发布。
版本兼容性矩阵¶
以下是 vLLM Ascend 版本的兼容性矩阵：
| vLLM Ascend | vLLM | Python | Stable CANN | PyTorch/torch_npu | Triton Ascend | Mooncake |
|---|---|---|---|---|---|---|
| v0.22.1rc1 | v0.22.1 | >= 3.10，< 3.13 | 9.0.0 | 2.10.0 / 2.10.0 | 3.2.1 | v0.3.9 |
| v0.21.0rc1 | v0.21.0 | >= 3.10，< 3.13 | 9.0.0 | 2.10.0 / 2.10.0 | 3.2.1 | v0.3.9 |
| v0.20.2rc1 | v0.20.2 | >= 3.10，< 3.12 | 9.0.0 | 2.10.0 / 2.10.0 | 3.2.1 | v0.3.8.post1 |
| v0.19.1rc1 | v0.19.1 | >= 3.10，< 3.12 | 8.5.1 | 2.9.0 / 2.9.0 | 3.2.0 | v0.3.8.post1 |
| v0.18.0 | v0.18.0 | >= 3.10，< 3.12 | 8.5.1 | 2.9.0 / 2.9.0.post1+git4c901a4 | 3.2.0.dev20260322 | v0.3.9 |
| v0.18.0rc1 | v0.18.0 | >= 3.10，< 3.12 | 8.5.1 | 2.9.0 / 2.9.0 | 3.2.0 | |
| v0.17.0rc1 | v0.17.0 | >= 3.10，< 3.12 | 8.5.1 | 2.9.0 / 2.9.0 | 3.2.0 | |
| v0.16.0rc1 | v0.16.0 | >= 3.10，< 3.12 | 8.5.1 | 2.9.0 / 2.9.0 | 3.2.0 | |
| v0.15.0rc1 | v0.15.0 | >= 3.10，< 3.12 | 8.5.0 | 2.9.0 / 2.9.0 | 3.2.0 | |
| v0.14.0rc1 | v0.14.1 | >= 3.10，< 3.12 | 8.5.0 | 2.9.0 / 2.9.0 | 3.2.0 | |
| v0.13.0rc3 | v0.13.0 | >= 3.10，< 3.12 | 8.5.1 | 2.8.0 / 2.8.0.post2 | 3.2.0 | |
| 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.12.0rc1 | v0.12.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.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 |
Note
如果您使用 v0.7.3，请务必同时安装 [mindie-turboreleases/v0.13.0。
对于 vLLM Ascend 的 main 分支，我们通常会使其与最新的 vLLM 发行版以及较新的 vLLM 提交哈希保持兼容。请注意，此表会定期更新，请经常查看。
| vLLM Ascend | vLLM | Python | Stable CANN | PyTorch/torch_npu | Triton Ascend |
|---|---|---|---|---|---|
| main | 1f486d96a17303ce8db8e02be39545b2be338446, v0.23.0 | >= 3.10, < 3.13 | 9.0.0 | 2.10.0 / 2.10.0 | 3.2.1 |
发布周期¶
发布窗口¶
| 日期 | 事件 |
|---|---|
| 2026.06.30 | 候选发布版本，v0.22.1rc1 |
| 2026.06.16 | 候选发布版本，v0.21.0rc1 |
| 2026.06.03 | 候选发布版本，v0.20.2rc1 |
| 2026.04.30 | 候选发布版本，v0.19.1rc1 |
| 2026.04.24 | 候选发布版本，v0.13.0rc3 |
| 2026.04.01 | 候选发布版本，v0.18.0rc1 |
| 2026.03.15 | 候选发布版本，v0.17.0rc1 |
| 2026.03.10 | 候选发布版本，v0.16.0rc1 |
| 2026.02.27 | 候选发布版本，v0.15.0rc1 |
| 2026.02.06 | v0.13.0 正式版本，v0.13.0 |
| 2026.01.26 | 候选发布版本，v0.14.0rc1 |
| 2026.01.24 | 候选发布版本，v0.13.0rc2 |
| 2025.12.27 | 候选发布版本，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 持续进行质量监控。
- releases/vX.Y.Z：开发分支，随 vLLM 的部分新版本创建。例如，
v0.13.0是 vLLMreleases/v0.13.0版本的开发分支。
为了尽可能降低维护成本，提交通常应先合并到 main 分支，然后再反向移植到 dev 分支。
维护分支与生命周期结束（EOL）¶
下表列出了分支状态。
| 分支 | 时间范围 | 摘要 |
|---|---|---|
| 维护中 | 大约 2-3 个次版本 | 接收错误修复；生成发行版本；承诺提供持续集成（CI） |
| 未维护 | 由社区兴趣驱动 | 接收错误修复；不生成发行版本；不承诺提供持续集成（CI） |
| 生命周期结束 (EOL) | 不适用 | 分支不再接受更改 |
分支状态¶
请注意，vLLM Ascend 仅针对特定的 vLLM 发行版本发布，而非所有版本。因此，您可能会注意到某些版本有对应的开发分支（例如 releases/v0.12.0），而其他版本则没有（例如 releases/vX.Y.Z）。vLLM Ascend 发行分支现在遵循 vX.Y.Z-dev 命名约定，取代了之前的 https://github.com/vllm-project/vllm/issues/22693>|930|wangxiyuan| 格式，以与 vLLM 的分支命名标准保持一致。
通常，vLLM 的每个次版本（例如 0.7）都会对应一个 vLLM Ascend 版本分支，并支持其最新版本（例如 0.7.3），如下所示：
| 分支 | 状态 | 备注 |
|---|---|---|
| main | 维护中 | vLLM main 分支和 vLLM v0.23.0 标签的 CI 承诺 |
| releases/v0.18.0 | 维护中 | vLLM 0.18.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 | 维护中 | <rfc/ |
- 分支：功能分支应以
rfc/feature-name为前缀，后接功能名称创建，例如Maintained。 - 状态：功能分支的状态为
InvalidVersion，直至其被合并到 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 软件包版本，以决定使用哪段代码逻辑。如果用户遇到
VLLM_VERSION错误，可能意味着他们安装了开发版或可编辑版本的 vLLM 软件包。在这种情况下，我们提供了环境变量extra:，供用户指定要使用的 vLLM 软件包版本。 - 文档变更应与最新的 1 至 2 个 vLLM 发行版本兼容。如有任何破坏性变更，应添加备注说明。
文档分支策略¶
为降低维护成本，所有分支的文档内容应保持一致，版本差异可通过 mkdocs.yml 的 main 块中的变量进行控制。尽管这并非易事，但这是我们应努力遵循的原则。
| 版本 | 用途 | 代码分支 |
|---|---|---|
| latest | main 分支最新 RC 版本的文档 | vX.Y.ZrcN 分支 |
| rc 版本 | RC 发行版本的文档 | vX.Y.ZrcN → vX.Y.Z 标签 |
| version | 历史发行版本的文档 | releases/vX.Y.Z → latest 分支 |
备注：
rc version文档：始终指向 main 分支的最新 RC 版本。version文档：发布后不再进行更新。releases/vX.Y.Z文档：持续更新torch-npu分支的文档以修复文档错误。
软件依赖管理¶
- ](https://pypi.org/project/torch-npu): Ascend Extension for PyTorch (torch-npu) releases a stable version to [PyPI