CANN 9.1.0-beta.1 发布计划解读：版本时间线、特性清单与SuperKernel融合关键特性

• 文档
• CANN

CANN 9.1.0-beta.1 是昇腾 CANN 软件栈 9.1.x 系列的首个预发布（beta）里程碑。本文以 9.1.0-beta.1/release-plan.md 为骨架，完整解析该版本从特性收集到最终发布的八个阶段时间线、特性清单的状态管理机制，并借助同目录 release-note.md 对清单中两项已验收特性（SuperKernel 融合、非连续静态算子执行）进行原理级剖析。读完本文，你将掌握 CANN 社区版本的发布流程规范，理解这两项特性在推理 Decode 性能优化中的技术作用与相互配合关系。

一、release-plan 文档在 CANN 版本管理中的定位

仓库 README.md 明确说明了 release-management 仓库的定位：它"定义CANN版本发布管理方案，旨在统一CANN版本的管控规范，明确版本发布的全流程步骤、版本号定义、变更记录要求与协作规则，提升项目版本管理的规范性与可追溯性"，仓库内容涵盖发布计划和时间表、发布说明（Release Notes）、版本管理策略、发布文档、发布历史记录五类资产。

从仓库根目录的文件组织方式可以直接观察到两条管理约定：

• 每个版本一个独立目录：仓库按版本号分目录组织，正式版本如 8.5.0、9.0.0、9.1.0、9.1.1、9.2.0，预发布版本如 9.0.0-beta.1、9.1.0-beta.1、9.1.0-beta.2、9.1.0-beta.3、9.2.0-beta.1。
• 每个版本目录下配套两类文档：release-plan.md（发布计划：何时做、做什么、谁负责）与release-notes.md/release-note.md（发布说明：交付了什么、配套关系、已知问题等）。以 9.1.0-beta.1 为例，目录内即为 release-plan.md 与 release-note.md 的配套组合。

版本号命名上，CANN 采用"主版本.次版本.补丁"三段式（如 9.1.0），并以-beta.N后缀标识正式发布前的预发布里程碑（如 9.1.0-beta.1），这套命名规则与 README 所述的"版本号定义"规范相互呼应。

二、CANN 9.1.0-beta.1 发布时间线（完整计划表）

原文档的发布计划以表格形式记录了八个阶段的起止日期。下表完整继承并补充各阶段持续天数（按日期区间含首尾计算）：

整个 9.1.0-beta.1 从 2026/03/01 特性收集启动到 2026/05/10 对外发布，全周期约 71 天。从时间表可以看出几个结构特征：

• 特性收集窗口约一个月（03/01–03/30），开发期紧接其后（04/01–04/22），共 22 天。
• 构建（Build）为单日里程碑，与测试第 1 轮同日启动（均为 04/23），可以理解为构建产物当日交付、首轮测试随即启动。
• 测试采用三轮逐轮收敛：Test round 1 为 8 天、Test round 2 为 6 天、Test round 3 收窄至 2 天，测试周期逐步压缩，说明缺陷修复与回归验证在后期趋于收敛。
• QA 报告与发布相邻完成：QA report 于 05/09 当天产出，Release 于次日 05/10 完成。

三、发布流程八个阶段详解

3.1 特性收集（Collect feature）

发布周期起点。此阶段各 SIG（特别兴趣小组）收集、筛选下一版本候选特性，最终沉淀为文档后半部分的"Feature list"特性清单。收集窗口的宽窄直接决定了版本承载特性数量的上限：9.1.0-beta.1 的收集窗口为 2026/03/01–2026/03/30，共 30 天，最终清单中收录了两项已验收特性。

3.2 开发（Develop）

特性清单确定后进入开发实现阶段。各 SIG 按清单推进编码，owner（特性负责人）对交付负责。9.1.0-beta.1 的开发窗口为 04/01–04/22，共 22 天，结束时间与 04/23 的构建日严格衔接。

3.3 构建（Build）

单日完成，生成可供测试的软件包或构建产物。构建是开发与测试之间的闸门：只有构建成功，后续测试轮次才有被测对象。

3.4 测试轮次（Test round 1/2/3）

计划表配置了三轮测试（04/23–04/30、05/01–05/06、05/07–05/08），逐轮执行功能验证、回归与性能测试，时间逐轮缩短体现了"缺陷收敛、质量趋稳"的测试节奏设计。

3.5 QA 报告（QA report）与发布（Release）

QA 于 05/09 汇总三轮测试结论并输出质量评估报告，05/10 即对外发布。QA 报告是放行发布的关键依据，两者在计划表上设计为连续两天完成。

四、特性清单与状态管理机制

原文档以表格形式给出了特性清单的状态定义与具体条目，两者均完整继承如下。

4.1 特性状态定义

状态机从"方案讨论"→"开发中"→"测试中"→"已验收"层层递进，是发布计划中最核心的进展追踪手段：只有状态为 Accepted（已验收）的特性，才会进入最终版本的交付范围。

4.2 9.1.0-beta.1 特性清单（原文档原表）

4.3 字段语义解读

• no：特性序号，标识清单内条目顺序。
• feature：特性名称，描述该版本要交付的技术能力。
• status：特性状态，两条特性均为 Accepted（已验收），即已通过测试验收、确定进入交付。
• sig：特性所属的兴趣小组标识。本例中两项特性均归属 sig-ops-transformer，该小组负责 Transformer 场景算子（注意力类、MoE 类、GMM 量化类等算子）的规划与实现。
• owner：特性负责人，本例两条特性均由 cc-z 负责推进。

需要说明的是，原文档中两条特性的 feature 链接均为空占位（()），尚未挂接具体 issue 链接；其技术细节与底层合入证据，可在配套的 release-note.md 中找到完整描述（详见第五、六节）。

五、特性深度解析一：npugraph_ex 新增支持 SuperKernel 融合

这是 9.1.0-beta.1 的两项关键特性之首，定位为"推理 Decode 阶段性能优化"。配套 release-note.md 的"关键特性"小节给出了官方描述：

基于 aclgraph 路径，提供了 SuperKernel 算子融合技术，在已编译的二进制代码基础上融合创建一个超级 Kernel 函数（简称 SuperKernel），以调用子函数的方式调用多个其它内核函数，达到缩减调度开销、优化计算任务的目的，可提升推理 Decode 阶段性能。

从该描述可以拆解出其核心技术机制：

1. 融合载体是已编译的二进制代码：SuperKernel 融合发生在算子已编译为二进制之后，在既有二进制基础上融合生成一个新的"超级 Kernel 函数"。
2. 融合形态是子函数调用：SuperKernel 以调用子函数的方式串联多个内核函数，将原本多次独立的内核调度合并为一次整体调度。
3. 收益来源是调度开销缩减：推理 Decode 阶段算子粒度细、调度频繁，内核调度开销占比显著；SuperKernel 通过减少调度次数、优化计算任务组织来提升该阶段性能。

在"新增特性"小节中，图引擎部分进一步明确了该能力的落地范围："支持 aclgraph 场景下开启 SuperKernel 功能"。这解释了特性名称中"npugraph_ex 新增支持"的含义——npugraph_ex 是 aclgraph 图执行路径的组成部分，SuperKernel 能力随该路径一起发布。底层合入证据为 opbase 仓库的 !346 号 PR（release-note.md 中标注）。

六、特性深度解析二：aclgraph 支持非连续静态算子执行

第二项关键特性定位为"aclgraph 场景下算子性能提升"。配套 release-note.md 的描述为：

新增支持非连续输入的静态算子执行。开启开关后将存在非连续输入的动态算子落盘编译为静态算子后执行，该机制可以提升 aclgraph 场景下 Superkernel 算子执行效率。

关键机制可以拆解为三点：

1. 针对非连续输入：动态算子在运行期根据输入 shape 等信息动态确定调度与编译参数，而非连续输入（tensor 数据在内存中不连续排布）会显著拖慢动态算子的执行效率。
2. 落盘编译为静态算子：开启开关后，存在非连续输入的动态算子会被"落盘编译"为静态算子再执行，将原本运行期的动态决策前移为编译期确定，从而获得静态算子更高的执行效率。
3. 服务 SuperKernel 场景：该机制的直接收益是提升 aclgraph 场景下 SuperKernel 算子的执行效率——这与第一项特性形成了明确的技术配合：SuperKernel 负责把多次调度合并为一次，非连续静态算子执行负责把被融合算子的执行方式优化为静态化，两项特性共同作用于 aclgraph 推理路径。

在"新增特性"小节中，opbase 库部分同样收录了该能力："新增支持非连续输入的静态算子执行……该机制可以提升 aclgraph 场景下 Superkernel 算子执行效率"。底层合入证据为 graph-autofusion 仓库的 !64、!99 号 PR（release-note.md 中标注）。

综合来看，9.1.0-beta.1 特性清单中的两项特性围绕同一技术主线——aclgraph 推理路径优化：SuperKernel 融合解决"调度次数多"的问题，非连续静态算子执行解决"动态算子执行开销大"的问题，两者配合共同支撑推理 Decode 阶段的性能提升。

七、发布计划与发布说明的配套关系

在 CANN 版本管理中，release-plan.md与release-notes.md是"事前计划"与"事后交付"的成对资产：

• release-plan.md（事前）：回答"这个版本什么时候做、做什么、谁负责"。以 9.1.0-beta.1/release-plan.md 为例，它给出八阶段时间线与特性清单，特性状态停留在 Accepted 即代表"计划内已验收"。
• release-notes.md（事后）：回答"这个版本最终交付了什么"。以 9.1.0-beta.1/release-note.md 为例，它记录了版本配套关系（Ascend HDK、组合包、独立升级子包）、关键特性、新增特性、废弃/修复项等。

将两者对照可以验证发布计划的执行结果：计划清单中的两项 Accepted 特性（SuperKernel 融合、非连续静态算子执行），在 release-note.md 的"关键特性"与"新增特性"章节中均有对应条目，且标注了底层合入 PR。这种"计划—交付"的可追溯性，正是 README 所强调的"提升项目版本管理的规范性与可追溯性"的具体体现。读者在查阅任一版本时，建议先读 release-plan 了解版本定位与范围，再读 release-notes 确认交付细节。

八、多版本发布计划的横向观察

从仓库内多份 release-plan.md 的时间线（8.5.0/release-plan.md、9.0.0/release-plan.md、9.0.0-beta.1/release-plan.md、9.0.0-beta.2/release-plan.md、9.1.0/release-plan.md、9.1.0-beta.2/release-plan.md、9.1.0-beta.3/release-plan.md、9.2.0/release-plan.md、9.2.0-beta.1/release-plan.md），可以横向观察到 9.1.0-beta.1 在版本节奏中的位置：

几个从结构上可以直接得出的观察结论：

• beta 版本是主版本开发周期内的中间里程碑：9.1.0-beta.1 的特性收集期（03/01 起）与正式版 9.1.0 同起点，其开发窗口（04/01–04/22）完全落在 9.1.0 的开发窗口（04/01–06/24）之内，且 beta.1 于 05/10 提前对外发布、正式版 9.1.0 于 07/30 发布。可以推断，beta 版本承担着"提前交付中间成果、供社区先行验证"的角色。
• beta 版本特性收集窗口通常更短：9.1.0-beta.1 收集期为 1 个月，而正式版 9.1.0 为 2 个月；9.2.0-beta.1 更是仅 5 天（07/01–07/05），可见预发布版聚焦于窗口内已收敛的成熟特性。
• 测试轮次配置并非固定：9.1.0 系列（含 beta.1–beta.3）均为 3 轮测试，而 9.2.0 系列与 9.0.0 系列的部分 beta 版本为 2 轮测试，轮次数量随版本风险与范围动态调整。
• QA 报告与发布间隔不固定：9.1.0-beta.1 为相邻两天（05/09→05/10），9.1.0 为 10 天（07/20→07/30），发布节奏由各版本的实际质量结论决定。

总结

CANN 9.1.0-beta.1 的发布计划（9.1.0-beta.1/release-plan.md）为社区完整定义了该预发布里程碑的八阶段时间线（2026/03/01 特性收集启动，2026/05/10 对外发布）与特性验收机制（discussion→developing→Testing→Accepted）。清单中的两项已验收特性均围绕 aclgraph 推理路径优化展开：npugraph_ex 新增支持 SuperKernel 融合，以"超级 Kernel 函数 + 子函数调用"的方式缩减内核调度开销，提升推理 Decode 阶段性能；aclgraph 支持非连续静态算子执行，通过将非连续输入的动态算子落盘编译为静态算子，提升 SuperKernel 场景的执行效率。二者相互配合，构成该版本最具代表性的技术交付。结合 release-note.md 的交付记录与仓库内多版本计划（9.1.0/release-plan.md、9.2.0/release-plan.md 等）的横向对比，读者可以完整理解 CANN 社区"计划先行、验收驱动、可追溯交付"的版本管理实践。

• 文档
• CANN