昇腾CANN cann-competitions：办一场算子优化竞赛的完整流程

开源社区的活跃度不只靠日常 PR，还需要有组织的竞赛活动。cann-competitions 是 CANN 社区的竞赛管理仓库：组织开发者围绕具体算子做性能优化，优胜方案合入社区主干。一场竞赛从策划到颁奖，经过赛题设计 → 平台搭建 → 基线模型 → 评测系统 → 开源审查，全套流程标准化。

一场竞赛的五个阶段

赛题设计：选对算子

不是所有算子都适合当赛题。选算子的标准：

选算子 Checklist（赛题设计阶段） 必须： [ ] 有明确的性能优化空间（不是「实现功能」） [ ] 有公认的性能基线（可以对比 CPU/GPU/已有 NPU 实现） [ ] 有清晰的评测指标（TFLOPS、延迟、带宽利用率） [ ] 实现复杂度适中（选手 4-8 周能出结果） 禁止： [ ] 涉及未开源的华为内部算子 [ ] 依赖特定硬件特性（只跑在 950PR，910 跑不了） [ ] 优化空间过于狭窄（改一处 tiling 就到顶）

实战案例：第二届 CANN 竞赛的赛题是ops-transformer/flash_attention。优化空间明确（分块策略、双缓冲、Cube/Vector 并行），基线用社区已有的实现（~40% HBM 带宽利用率），评测指标用 TFLOPS 和延迟。

基线代码和评测 harness

赛题发布时，必须提供可运行的基线代码和自动评测 harness。选手在这个基础上优化，评测系统自动跑分。

# cann-competitions/2025-ops-optimization/baseline/bench_flashattn.pyimporttorchimporttimeimportnumpyasnpdefbenchmark_flash_attention(B,H,N,D,dtype=torch.float16,warmup=10,repeat=100):""" 基线 benchmark：调用 ops-transformer 的 FlashAttention 实现 输出：latency (ms), TFLOPS, HBM 带宽利用率 """q=torch.randn(B,H,N,D,dtype=dtype,device=torch.device("npu"))k=torch.randn(B,H,N,D,dtype=dtype,device=torch.device("npu"))v=torch.randn(B,H,N,D,dtype=dtype,device=torch.device("npu"))# 预热for_inrange(warmup):o=torch_npu.flash_attention(q,k,v)torch.npu.synchronize()# 正式计时start=time.perf_counter()for_inrange(repeat):o=torch_npu.flash_attention(q,k,v)torch.npu.synchronize()end=time.perf_counter()latency_ms=(end-start)/repeat*1000# TFLOPS 计算：FlashAttention 的 FLOPs = 4 * B * H * N * Dflops=4*B*H*N*D tflops=flops/(latency_ms/1000)/1e12# HBM 带宽利用率：理论峰值 1.2 TB/s，实测搬运量 / 时间hbm_accessed=B*H*N*D*2# Q,K 读 + O 写（简化）hbm_bw_util=(hbm_accessed/(latency_ms/1000))/1.2e12return{"latency_ms":latency_ms,"tflops":tflops,"hbm_bw_util":hbm_bw_util,}

评测 harness 自动跑这个脚本，把结果写到排行榜。

提交系统和实时排行榜

选手通过 GitHub PR 提交优化后的算子实现。提交后 CI 自动跑评测 harness，把结果推到实时排行榜。

# .github/workflows/competition-score.ymlname:Competition Scoringon:pull_request:paths:-"submissions/**/*.py"-"submissions/**/*.cpp"jobs:score:runs-on:asc-p6000-8x910# 固定硬件，消除硬件差异steps:-name:Check outuses:actions/checkout@v3-name:Build & Install Candidaterun:|cd submissions/${{ github.actor }} mkdir build && cd build cmake .. && make -j-name:Run Benchmarkrun:|python baseline/bench_flashattn.py \ --candidate=submissions/${{ github.actor }}/build/libfa.so \ --output=result.json-name:Update Leaderboardrun:|python scripts/update_leaderboard.py \ --pr=${{ github.event.number }} \ --result=result.json \ --leaderboard=leaderboard.json-name:Push Leaderboardrun:|git config user.name "competition-bot" git add leaderboard.json git commit -m "Update leaderboard: PR#${{ github.event.number }}" git push

排行榜实时更新，所有选手能看到自己当前的排名。

踩坑一：硬件异构导致成绩不可比

第一届竞赛用公有云上的随机 NPU 实例跑分——不同实例的固件版本不一样，同份代码跑两次结果差 5%。选手投诉「成绩不稳定」。

根因：NPU 固件版本影响算子性能（尤其是 Cube 单元的调度策略）。随机分配实例 → 固件版本随机 → 成绩不可比。

正确做法：竞赛用固定硬件池（同一批 910，同一固件版本），在 CI 的runs-on里写死。

# 错误：runs-on: ubuntu-latest + 动态申请 NPU 实例# 正确：runs-on:asc-p6000-8x910# 固定硬件池，固件版本一致

踩坑二：基线代码有 bug 导致全体成绩无效

基线代码里torch.npu.synchronize()写成了pass——没有等 NPU 算完就计时，所有人的成绩都比实际快 10×。

发现方式：一个选手优化后的代码反而比基线慢——review 代码发现计时不正确。

正确做法：基线代码发布前必须经过「反向验证」——故意写一个慢的基线（加 sleep），验证评测 harness 能正确捕捉到延迟。

# 基线代码发布前的反向验证deftest_benchmark_correctness():# 注入一个人为变慢的版本slow_kernel=make_slow_kernel(base_kernel,slowdown_factor=10)result=benchmark_flash_attention(slow_kernel)assertresult["latency_ms"]>baseline_latency_ms*9# 应该慢 ~10x

踩坑三：优胜方案的 License 不清晰

第二届竞赛第一名的方案里用了 CUDA 代码（作为参考实现）——但竞赛要求「全部代码必须能在 NPU 上运行」。选手辩解说「CUDA 代码只是参考，不影响 NPU 实现」。

正确做法：竞赛报名时要求签署附加条款——「提交代码中的所有源文件必须能在昇腾 NPU 上编译运行，引用第三方代码必须附 License 声明」。

## 参赛条款（报名时勾选） - [ ] 我确认提交代码中的所有源文件均为本人/本人队伍编写， 或已获得原作者的开源授权（附 License 文件）。 - [ ] 我确认提交代码不含任何闭源组件、不含任何只能跑在 GPU/其他厂商硬件上的代码。 - [ ] 我同意优胜方案的代码以 Apache 2.0 协议合入 CANN 社区主干分支。

cann-competitions 的价值不只是办比赛——它把「算子优化」这件门槛很高的事，用标准化赛题 + 自动评测 + 实时排行榜的方式降低了参与门槛。第一届竞赛收到的 60+ 份提交里，有 3 份的性能超过了社区基线——这 3 份后来都合入了 ops-transformer 仓库。