版本管理策略#
从 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)
正式版本:通常每3个月发布一次,将综合考虑 vLLM 上游发行计划和昇腾软件产品发行计划。
预发布版本:通常会按需发布,以 rcN 结尾,表示第N个候选发布版本,旨在支持用户在正式发布前进行早期测试。
后续版本:通常会根据需要发布,以支持解决正式发布中的小错误。这与 PEP-440 的后续版本说明 建议不同,它将包含实际的 bug 修复,因为最终发布版本应严格与 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 |
MindIE Turbo |
|---|---|---|---|---|---|
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.1.RC1 |
2.5.1 / 2.5.1.post1 |
|
v0.9.1rc2 |
v0.9.1 |
>= 3.9, < 3.12 |
8.1.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.7.3.post1 |
v0.7.3 |
>= 3.9, < 3.12 |
8.1.RC1 |
2.5.1 / 2.5.1 |
2.0候选版本1 |
v0.7.3 |
v0.7.3 |
>= 3.9, < 3.12 |
8.1.RC1 |
2.5.1 / 2.5.1 |
2.0候选版本1 |
发布节奏#
发布窗口#
日期 |
事件 |
|---|---|
2025.09.03 |
v0.9.1 Final release |
2025.08.22 |
Release candidates, v0.9.1rc3 |
2025.08.06 |
Release candidates, 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.x 补丁版,v0.7.3.post1 |
2025.05.08 |
v0.7.x 正式版,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:main 分支,对应 vLLM 的主分支和最新的 1 或 2 个发布版本。该分支通过 Ascend CI 持续监控质量。
vX.Y.Z-dev:开发分支,是随着 vLLM 新版本的一部分一起创建的。例如,
v0.7.3-dev是 vLLMv0.7.3版本的开发分支。
通常,提交应该只先合并到主分支,然后再回溯合并到开发分支,以尽可能降低维护成本。
维护分支与生命周期结束(EOL):#
分支状态将处于以下几种状态之一:
分支 |
时间范围 |
摘要 |
|---|---|---|
维护中 |
大约 2-3 个小版本 |
所有的错误修复都是合适的。正常发布版本,持续集成承诺。 |
无人维护 |
社区兴趣驱动 |
所有的 bug 修复都是合适的。没有发布版本,不承诺持续集成(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 主分支和 vLLM 0.9.2 分支的 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 替代 |
向后兼容性#
对于主分支,vLLM Ascend 应该与 vLLM 主分支以及最新的 1 或 2 个发布版本兼容。因此,为了确保向后兼容性,我们将执行以下操作:
主分支和目标 vLLM 发行版都经过了 Ascend E2E CI 的测试。例如,目前正在测试 vLLM 主分支和 vLLM 0.8.4。
对于代码更改,我们也会确保这些更改与最新的 1 或 2 个 vLLM 发行版本兼容。在这种情况下,vLLM Ascend 在代码中引入了版本检查机制。它会先检查已安装的 vLLM 包的版本,然后决定使用哪段代码逻辑。如果用户遇到
InvalidVersion错误,这有时意味着他们安装了 dev/可编辑版本的 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 的任何版本和分支。