版本管理策略

版本管理策略#

从 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：第一个与 vLLM v0.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.23.0

v0.23.0

>= 3.10, < 3.13

9.1.0

2.10.0 / 2.10.0.post4

3.2.2

v0.3.11.post1

v0.23.0rc1

v0.23.0

>= 3.10, < 3.13

9.0.1

2.10.0 / 2.10.0.post2

3.2.1

v0.3.11.post1

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

不适用

不适用

备注

如果您正在使用 v0.7.3，请不要忘记同时安装 mindie-turbo。

对于 vLLM Ascend 的主分支，我们通常使其与最新的 vLLM 发布版本和更新的 vLLM 提交哈希兼容。请注意，此表格会经常更新，请定期查看。

vLLM Ascend

vLLM

Python

稳定版 CANN

PyTorch/torch_npu

Triton Ascend

main

ee0da84ab9e04ac7610e28580af62c365e898389, v0.23.0

>= 3.10, < 3.13

9.1.0

2.10.0 / 2.10.0.post4

3.2.2

发布节奏#

发布窗口#

日期

事件

2026.08.16

v0.23.0 最终版本，v0.23.0

2026.07.20

候选发布版本，v0.23.0rc1

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 的部分新版本创建。例如，releases/v0.13.0 是 vLLM v0.13.0 版本的开发分支。

提交通常应首先合并到 main 分支，然后再反向移植到 dev 分支，以尽可能降低维护成本。

维护分支与生命周期终止#

下表列出了分支状态。

分支

时间范围

摘要

已维护

大约 2-3 个次要版本

接收错误修复；生成发布版本；CI 承诺

未维护

由社区兴趣驱动

接收错误修复；不生成发布版本；无 CI 承诺

生命周期终止

不适用

分支不再接受变更

分支状态#

请注意，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.23.0

已维护

对 vLLM 0.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：长序列优化 #22693

930

wangxiyuan

  • 分支：特性分支应以 rfc/ 为前缀，后跟特性名称来创建，例如 rfc/feature-name。

  • 状态：特性分支在被合并到 main 分支或删除之前，其状态为 已维护。

  • 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版本兼容。如有破坏性变更，需添加说明注释。

文档分支策略#

为降低维护成本，所有分支的文档内容应保持一致，版本差异可通过docs/source/conf.py中的变量控制。虽然这并非易事，但这是我们应努力遵循的原则。

版本

用途

代码分支

latest

主分支最新RC版本的文档

main分支

rc版本

RC发布版本的文档

vX.Y.ZrcN --> vX.Y.ZrcN标签

版本

历史发布版本的文档

vX.Y.Z --> releases/vX.Y.Z分支

说明：

  • latest文档：始终指向主分支的最新RC版本。

  • rc版本文档：发布后不再更新。

  • 版本文档：持续更新releases/vX.Y.Z分支文档以修复文档缺陷。

软件依赖管理#

  • torch-npu：TorchNPU 每3个月向 PyPI 发布一个稳定版本，每月发布一个开发版本（即POC版本），每天发布一个夜间版本。PyPI 稳定版本可以用于 vLLM Ascend 最终版本，月度开发版本仅可用于 vLLM Ascend RC 版本以进行快速迭代，而夜间版本不能用于任何 vLLM Ascend 版本或分支。