版本策略¶
从 vLLM 0.7.x 开始，vLLM Ascend 插件（vllm-project/vllm-ascend）项目遵循 PEP 440 发布与 vLLM（vllm-project/vllm）匹配的版本。
vLLM Ascend 插件版本¶
每个 vLLM Ascend 版本均采用 v[major].[minor].[micro][rcN][.postN] 格式进行版本命名（例如
v0.7.3rc1、v0.7.3、v0.7.3.post1）
- 正式版本：通常每三个月发布一次，并与 vLLM 上游发布周期及 Ascend 软件产品路线图保持严格对齐。
- 预发布版本：通常**按需**发布，以 rcN 标记表示第 N 个候选版本。旨在支持用户在正式版本发布前进行早期测试。
- 补丁版本：通常**按需**发布，用于修复正式版本中的小错误。与 PEP-440 补丁版本说明 的惯例不同，这些版本包含实际的错误修复，因为正式版本必须严格遵循 vLLM 正式版本格式（
v[major].[minor].[micro]）。任何补丁版本都必须作为正式版本的补丁版本发布。
例如：
v0.7.x：首个与 vLLMv0.7.x版本匹配的正式版本。v0.7.3rc1：vLLM Ascend 的首个预发布版本。v0.7.3.post1：针对v0.7.3版本存在小错误时的补丁版本。
版本兼容性矩阵¶
下表为 vLLM Ascend 版本的版本兼容性矩阵。
| vLLM Ascend | vLLM | Python | 稳定 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-turbo。
对于 vLLM Ascend 的 main 分支，我们通常使其与最新的 vLLM 版本以及更新的 vLLM 提交哈希兼容。请注意，此表格会定期更新，请定期查看。
| vLLM Ascend | vLLM | Python | 稳定 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 主分支及最新的 1 或 2 个发布版本。通过 Ascend CI 持续监控其质量。
- releases/vX.Y.Z：开发分支，随 vLLM 的部分新版本创建。例如，
releases/v0.13.0是 vLLMv0.13.0版本的开发分支。
提交通常应首先合并到 main 分支，然后再反向移植到 dev 分支，以尽可能降低维护成本。
维护分支与生命周期终止 (EOL)¶
下表列出了分支状态。
| 分支 | 时间范围 | 摘要 |
|---|---|---|
| 维护中 | 约2-3个次要版本 | 接收错误修复；产生发布版本；有CI承诺 |
| 不再维护 | 由社区兴趣驱动 | 接收错误修复；不产生发布版本；无CI承诺 |
| 生命周期结束 (EOL) | 不适用 | 分支不再接受变更 |
分支状态¶
请注意，vLLM Ascend 仅针对特定的 vLLM 发布版本进行发布，而非每个版本。因此，您可能会注意到某些版本有对应的开发分支（例如 releases/v0.13.0），而其他版本则没有（例如 releases/v0.12.0）。vLLM Ascend 发布分支现在遵循 releases/vX.Y.Z 命名约定，取代了之前的 vX.Y.Z-dev 格式，以与 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 | 维护中 | https://github.com/vllm-project/vllm/issues/22693 | 930 | wangxiyuan |
- 分支：特性分支应以
rfc/为前缀，后跟特性名称，例如rfc/feature-name。 - 状态：特性分支在被合并到主分支或删除之前，其状态为
Maintained。 - RFC 链接：特性分支应创建对应的 RFC 议题。创建特性分支需要一份 RFC 并获得至少两位维护者的批准。
- 计划合并时间：特性分支的最终目标是合并到主分支。如果超过三个月仍未合并，导师维护者应评估是否删除该分支。
- 导师：导师应为 vLLM Ascend 的维护者，负责该特性分支。
向后兼容性¶
对于主分支，vLLM Ascend 应与 vLLM 主分支及最新的 1 到 2 个版本兼容。为确保向后兼容性，请执行以下操作：
- 主分支和目标 vLLM 版本（例如 vLLM 主分支和 vLLM 0.8.4）均需通过 Ascend E2E CI 测试。
- 为确保代码更改与最新的 1 到 2 个 vLLM 版本兼容，vLLM Ascend 在代码中引入了版本检查机制。它首先检查已安装的 vLLM 包版本，以决定使用哪段代码逻辑。如果用户遇到
InvalidVersion错误，可能表示他们安装了开发版或可编辑版的 vLLM 包。在这种情况下，我们提供环境变量VLLM_VERSION，让用户指定要使用的 vLLM 包版本。 - 文档更改应与最新的 1 到 2 个 vLLM 版本兼容。如有任何重大变更，应添加说明。
文档分支策略¶
为降低维护成本，所有分支的文档内容应保持一致，版本差异可通过 mkdocs.ymlextra: 中 块的变量进行控制。虽然这并非易事，但这是我们应努力遵循的原则。
| 版本 | 目的 | 代码分支 |
|---|---|---|
| latest | main 分支最新 rc 版本的文档 | main 分支 |
| rc 版本 | 已发布 RC 版本的文档 | vX.Y.ZrcN → vX.Y.ZrcN 标签 |
| 版本 | 历史发布版本的文档 | vX.Y.Z → releases/vX.Y.Z 分支 |
说明：
latest文档：始终指向主分支的最新 rc 版本。rc version文档：发布后不再更新。version文档：持续更新releases/vX.Y.Z分支的文档以修复文档缺陷。
软件依赖管理¶
torch-npu：Ascend Extension for PyTorch (torch-npu) 每 3 个月向 PyPI 发布一个稳定版本，每月发布一个开发版本（即 POC 版本），每天发布一个夜间版本。 PyPI 稳定版本**可以**用于 vLLM Ascend 最终版本，月度开发版本**仅能**用于 vLLM Ascend RC 版本以进行快速迭代，而夜间版本**不能**用于任何 vLLM Ascend 版本或分支。