Ops-nn Development Roadmap (2026 Q1)

Ops-nn Development Roadmap (2026 Q1)

【免费下载链接】community本项目是CANN开源社区的核心管理仓库,包含社区的治理章程、治理组织、通用操作指引及流程规范等基础信息项目地址: https://gitcode.com/cann/community

Ops-nn是CANN社区的核心算子库,本季度重点聚焦于算子覆盖率提升和性能优化。欢迎社区开发者参与贡献和反馈!

Focus

• New feature & function: 新增50+高频算子支持 • Feature compatibility & reliability: 完善算子精度测试和边界条件处理 • Usability: 优化算子API设计,降低使用门槛 • Kernel optimization: 重点算子性能提升20%以上 • Documentation: 完善算子开发指南和API文档

Base Operators

• 新增Transformer类算子支持

  • Goal: 支持MultiHeadAttention、LayerNorm等10个Transformer核心算子
  • Owner: @zhangsan
  • Issue: Transformer算子支持计划 #156

• FlashAttention算子实现 [🙋 Help Wanted]

  • Goal: 实现高效的FlashAttention算子,支持长序列推理场景
  • Owner: TBD
  • Issue: FlashAttention实现 #178

Performance Optimization

• MatMul算子性能优化

  • Goal: 大shape场景下性能提升30%
  • Owner: @lisi
  • Issue: MatMul性能优化 #189
  • PR: MatMul kernel优化实现 #201

• 算子融合框架 ◦ 支持Conv+BN+ReLU融合 ◦ 支持MatMul+Add融合 ◦ 提供自定义融合规则接口

  • Goal: 减少30%的kernel launch开销
  • Owner: @wangwu

Testing & Quality

• 算子精度测试框架完善 [🙋 Help Wanted]

  • Goal: 覆盖所有算子的精度基线测试
  • Owner: TBD
  • Issue: 精度测试框架 #145

Sub-issues

历史 Roadmap

Ops-nn Development Roadmap (2025 Q4) #120

特性子 Issue

FlashAttention详细设计 #180

## 核心结构:标题格式 **格式:** `[项目] Development Roadmap (时间周期)` **示例:** - `Ops-nn Development Roadmap (2026 Q1)` - `catlass Development Roadmap (2025 Q4)` **特点:** - 清晰标示时间周期(季度为主),也支持半年期粒度; - 便于版本管理和历史追踪——历史周期通过"Sub-issues"或编辑记录串联,形成连续的规划档案。 仓库中已有实践可印证这一命名规范:在 [ascendc SIG 主页](https://link.gitcode.com/i/eb07af67ddc07ed2f44d6e8141b82869) 的"项目路标"一节中,Ascend C 项目即采用 `Ascend C Development Roadmap (2026 Q2)`、`Ascend C Development Roadmap (2026 Q3)` 的形式逐季度发布 Roadmap Issue,并在 SIG 主页集中挂出,方便社区开发者随时查看。 ## 内容组织结构:顶层内容 ### 开场描述(可选) 标题之下可以先用一段文字提供项目概述、愿景或总体方向简述,帮助读者(尤其是新贡献者)快速建立上下文。例如完整示例中的 "Ops-nn是CANN社区的核心算子库,本季度重点聚焦于算子覆盖率提升和性能优化"。 ### Focus / 重点聚焦部分 通过 **bullet points**(•)列出本周期最关键的 3~5 个聚焦方向,建议按照项目的**功能领域**或**技术模块**进行分组,涵盖全局视角: ```markdown ## Focus • New feature & function: 新增50+高频算子支持 • Feature compatibility & reliability: 完善算子精度测试和边界条件处理 • Usability: 优化算子API设计,降低使用门槛 • Kernel optimization: 重点算子性能提升20%以上 • Documentation: 完善算子开发指南和API文档

特点:

Focus 部分是对当前周期项目主要发展方向的概括性和整体性描述,不需要详细展开——具体细节放在下方各功能模块的工作项中。

主要功能模块章节

章节划分原则

正文主体按照项目的功能领域或技术模块

进行分组,如完整示例中的:

  • Base Operators- 基础算子
  • Performance Optimization- 性能优化
  • Testing & Quality- 测试与质量

章节划分应覆盖项目的全部主要能力域,并兼顾基础设施、维护性工作与跨功能协作,避免只列"亮点特性"而遗漏日常工程投入。

每个模块的结构:两种常见场景

每个模块下包含多个具体工作项

。根据工作项进展,有以下两种常见场景:

场景1:仅有 Issue(规划/讨论阶段)

——工作项处于需求澄清、方案设计或社区讨论期,只关联追踪 Issue:

## Base Operators • 新增Transformer类算子支持 - Goal: 支持MultiHeadAttention、LayerNorm等10个Transformer核心算子 - Owner: [@zhangsan](https://link.gitcode.com/i/cbae934696f5a3d586dfbaa7b52bafe1) - Issue: [Transformer算子支持计划 #156](https://link.gitcode.com/i/45a3bd5c2835c77c7c94d8aab9341ab1)

场景2:同时有 Issue 和 PR(实现阶段)

——工作项已有代码落地,额外挂上实现 PR,形成"规划 → 实现 → 评审 → 合入"的完整闭环:

## Performance Optimization • MatMul算子性能优化 - Goal: 大shape场景下性能提升30% - Owner: [@lisi](https://link.gitcode.com/i/4fbb2a9015a243d7c1c5c601e96bb83c) - Issue: [MatMul性能优化 #189](https://link.gitcode.com/i/c157f6b565d306bd8e9cd344eff8ec7c) - PR: [MatMul kernel优化实现 #201](https://link.gitcode.com/i/f53c935098bd63a1c35516d7eb2a29ce)

提示:同一工作项可以同时挂多个 PR 或多次更新 PR 链接,反映迭代过程中的实现进展。

工作项信息字段

每个工作项应包含以下关键元数据,保证"看了 Roadmap 就知道谁来干、干什么、进展到哪":

Goal / Description
  • 含义:工作目标或简短描述
  • 用途:说明该工作项的目标,让读者(包括潜在的贡献者)能快速判断任务性质
  • 例子:Goal: 支持在代码仓配置流水线
Owner
  • 含义:责任人
  • 格式:Owner: @username
  • 用途:明确谁负责或主导该工作项;尚未确定负责人时可写作Owner: TBD
  • 例子:Owner: [@zhangsan](https://link.gitcode.com/i/cbae934696f5a3d586dfbaa7b52bafe1)
Issue
  • 含义:关联的 Gitcode Issue
  • 格式:Issue: 标题 #编号
  • 用途:追踪详细设计和讨论,承载方案评审、进度更新与遗留问题
  • 例子:Issue: [机器人检视意见优化 #42](https://link.gitcode.com/i/65f8a9c52c91c297728607bb080e65af)
PR(Pull Request)
  • 含义:相关的实现 PR
  • 格式:PR: 标题 #编号
  • 用途:链接实现工作,让 Roadmap 与代码合入记录一一对应
  • 例子:PR: [新增CI指导及FAQ文档 #35](https://link.gitcode.com/i/c909251cc95a357aee65efed21470361)

结构化方式:多层级内容组织

主工作项

顶层是核心工作项,直接以 bullet 形式列出:

• 优化各仓库CI端到端时间,达成30min内完成CI

子工作项 / 相关项

使用◦

表示从属项目,将大目标拆解为可执行的子任务:

• 主工作项 ◦ 支持在代码仓配置流水线 ◦ 数字化看板,实时监控资源利用率情况 ◦ 相关项目 3

多层级组织适合两类典型场景:一是把大型特性(如算子融合框架)拆成多个子能力逐条列出;二是将基础设施类目标(如 CI 时间优化)拆分为流水线、看板等具体交付。

链接信息

每个工作项下方缩进列出相关链接,保持 Roadmap 正文干净、信息可追溯:

- Owner: @name - Issue: #123 - PR: #456

最佳实践

清晰度

  • 每个工作项应该清楚可理解
  • 避免过于宽泛或含糊的描述
  • 使用具体的技术术语

可追踪性

  • 为每个工作项关联 Issue
  • 标明负责人(Owner)

完整性

  • 覆盖所有主要功能领域
  • 包含基础设施和维护工作
  • 考虑跨功能协作

可操作性

  • 工作项应该足够具体可执行
  • 提供目标和优先级指示
  • 链接实现相关资源

开发者协作

  • 明确表述需要征集社区开发者反馈和贡献的工作项
  • 提供定期讨论的渠道和时间(如会议周期和链接等)。CANN 各 SIG 均维护公开的例会与纪要链接,例如 ascendc SIG 的会议组织与纪要信息 中公开了两周一次的例会时间与议题申报地址,Roadmap 中的协作工作项可同步指向此类渠道

🙋 Help Wanted 标记

对于希望社区开发者重点参与贡献的工作项,建议使用[🙋 Help Wanted]

标记进行标识:

## Base Operators • FlashAttention算子实现 [🙋 Help Wanted] - Goal: 实现高效的FlashAttention算子,支持长序列推理场景 - Owner: TBD - Issue: [FlashAttention实现 #178](https://link.gitcode.com/i/a2294e146da9006a78ff43a77c1002db)

这一实践参考自其他开源社区的做法,有助于:

  • 明确标识哪些工作项需要更多社区贡献者参与
  • 降低新贡献者的参与门槛
  • 提高项目的社区活跃度

补充元素

Sub-issues

在 Roadmap Issue 底部列出跨周期关联的 Roadmap Issue 或大型工作项的拆分 Issue。

与工作项 Issue 字段的区别:

  • 工作项中的 Issue 字段:链接的是具体工作项的详细设计、讨论或跟踪 Issue;
  • Sub-issues 章节:用于关联其他周期的 Roadmap Issue(如上一季度未完成的工作),或将大型工作项拆分为多个独立追踪的子 Issue。
## Sub-issues Ops-nn Development Roadmap (2025 Q4) #12780  Feature X Phase 2 #12800 

通过 Sub-issues,Roadmap 形成"季度为周期、跨期可衔接"的连续档案:未完成项在新季度 Roadmap 中明确承接,大型特性通过拆分 Issue 独立追踪。

Assignees

在 Issue 属性中设置多个负责人,便于追踪——适合需要多人协同或跨组协作的工作项,弥补正文中单一 Owner 字段的不足。

时间线修订

  • 通过编辑活动历史记录时间周期变化
  • 保持 Issue title 与实际时间周期同步

简化版模板

如果团队刚开始使用 Roadmap Issue,可以从以下简化版本开始,待流程跑通后再逐步补充字段:

# [项目名] Development Roadmap (20XX QX) 欢迎社区开发者参与贡献和反馈! ## Focus • [重点方向1]: [简要描述] • [重点方向2]: [简要描述] • [重点方向3]: [简要描述] ## [功能模块1] • [工作项1] - Goal: [目标描述] - Owner: @username - Issue: #123 • [工作项2] [🙋 Help Wanted] - Goal: [目标描述] - Owner: TBD ## [功能模块2] • [工作项1] - Goal: [目标描述] - Owner: @username

【免费下载链接】community本项目是CANN开源社区的核心管理仓库,包含社区的治理章程、治理组织、通用操作指引及流程规范等基础信息项目地址: https://gitcode.com/cann/community

创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考