版本控制策略#
从 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 |
Stable CANN |
PyTorch/torch_npu |
|---|---|---|---|---|
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 的主分支，我们通常使其与最新的 vLLM 版本以及 vLLM 的一个或两个较新提交哈希兼容。请注意，此表通常会更新，请定期查看。
vLLM Ascend |
vLLM |
Python |
Stable CANN |
PyTorch/torch_npu |
|---|---|---|---|---|
main |
v0.13.0 标签 |
>= 3.10, < 3.12 |
8.3.RC2 |
2.8.0 / 2.8.0 |
发布节奏#
发布窗口#
日期 |
事件 |
|---|---|
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 承诺 |
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 分支或删除之前，功能分支的状态为
Maintained。RFC 链接：功能分支应创建带有相应 RFC 问题。创建功能分支需要 RFC 和至少两名维护者的批准。
计划合并时间：功能分支的最终目标是合并到 main 分支。如果三个月以上未合并，导师维护者应评估是否删除该分支。
导师：导师应该是 vLLM Ascend 的维护者，负责该功能分支。
向后兼容性#
对于 main 分支，vLLM Ascend 应与 vLLM main 分支和最新的 1-2 个发布版本一起工作。为确保向后兼容性，请执行以下操作：
Ascend E2E CI 会测试 main 分支和目标 vLLM 版本（例如 vLLM main 分支和 vLLM 0.8.4）。
为确保代码更改与最新的 1-2 个 vLLM 版本兼容，vLLM Ascend 在代码中引入了版本检查机制。它首先检查已安装 vLLM 包的版本，然后决定使用哪种代码逻辑。如果用户遇到
InvalidVersion错误，这可能表明他们安装了 vLLM 包的开发版或可编辑版。在这种情况下，我们提供环境变量VLLM_VERSION，让用户指定要使用的 vLLM 包版本。文档更改应与最新的 1-2 个 vLLM 版本兼容。如果存在任何破坏性更改，应添加说明。
文档分支策略#
为降低维护成本，**所有分支的文档内容应保持一致，版本差异可以通过 docs/source/conf.py 中的变量来控制**。虽然这不是一项简单的任务，但这是我们应该努力遵循的原则。
版本 |
目的 |
代码分支 |
|---|---|---|
latest |
最新开发分支的文档 |
vX.Y.Z-dev（在第一次正式发布后将变为 |
version |
已发布历史版本的文档 |
Git 标签，如 vX.Y.Z[rcN] |
stable（尚未发布） |
最新正式发布分支的文档 |
在第一次正式发布后将变为 |
注意事项
latest文档：匹配当前维护分支vX.Y.Z-dev（在第一次正式发布后将变为main）。它会持续更新以确保对最新版本的可用性。version文档：对应特定的已发布版本（例如v0.7.3、v0.7.3rc1）。发布后不再更新。stable文档（**尚未发布**）：官方发布文档。发布后允许实时更新，通常基于 vX.Y.Z-dev。一旦提供了 stable 文档，非 stable 版本应显示一个标题警告：您 正在 查看 最新 开发者 预览 文档。 点击 此处 查看 最新 稳定 版本的 文档。。
软件依赖管理#
torch-npu：Ascend PyTorch 扩展 (torch-npu) 每 3 个月在 PyPi 上发布一个稳定版本，每月发布一个开发版本（又名 POC 版本），每天发布一个 nightly 版本。PyPi 稳定版本**可以**在 vLLM Ascend 正式版本中使用，每月开发版本**仅可以**在 vLLM Ascend RC 版本中使用以进行快速迭代，而 nightly 版本**不能**在 vLLM Ascend 的任何版本和分支中使用。