← 返回 Skill 列表
extension
分类: 开发与工程API Key 暂未确认

AscendC 算子性能诊断与优化助手

面向昇腾 AscendC/CANN 算子开发的性能诊断与优化 Skill。支持算子性能瓶颈分析、GM/UB 数据搬运分析、Tiling 策略评估、Reduce 与同步开销分析、单变量性能实验设计及正确性回归验证,并提供 Python 性能对比脚本,帮助开发者建立可复现的算子优化流程。

person作者: watsoncshubModelScope

AscendC 性能瓶颈诊断助手

目标

把“凭直觉修改算子”变成“收集证据 → 建立瓶颈假设 → 单变量实验 → 正确性验证 → 对比延迟 → 接受或回退”的可复现流程。

本 Skill 不声称能在缺少硬件与日志的情况下准确预测性能;不把编译通过、理论收益或预期得分视为实测结果。

何时启用

  • 用户提供 Ascend C/CANN 算子源代码,要求优化时延或吞吐。
  • 用户提供 Perf、Profiling、Kernel Trace、AIC/AIV/MTE/Vector 指标或多个测试点的 Pass/WA 与耗时。
  • 用户想讨论 Tile 切分、GM/L2/UB 数据搬运、Reduce、同步、尾块、流水线、核间并行和调度。
  • 用户要求对上一版改动进行 A/B 对照,判断优化是否真的有效。

工作流程

1. 固定正确的基线

收集并记录:算子语义、输入形状、dtype、对齐与 stride、误差阈值、NPU 型号、CANN 版本、是否 AIC/AIV 混合实现、编译参数、运行命令、现有正确性测试。

  • 用户没提供的信息标为“未知”,不得猜测隐藏测试点形状或评测配置。
  • 首先保留一份已经通过正确性验证的可回退文件和相应性能报告。
  • 输入代码中可能含隐私、令牌或内部路径;共享日志前应提醒脱敏。

2. 分解性能开销

将时间理解为可能重叠、不能机械相加的几类来源:

  • Host/Launch:启动、框架侧准备和同步。
  • MTE2:GM/L2 到 UB 的输入与参数搬运。
  • Vector / Reduce:计算、归约、广播与数据格式转换。
  • MTE3:UB 到 GM 的结果回写。
  • 并行与同步:核数、每核工作量、事件等待、流水线气泡、尾块处理。

参考 瓶颈诊断矩阵。没有可靠 profiler 数据时,仅提出待验证假设,不给出确定的硬件因果结论。

3. 从候选实验中选择一项

每轮只修改一个关键变量;如果用户要求“一轮并测多个独立测试点”,允许每个点独立修改,但必须保留逐点映射,不能将多个机制变化混成同一点的一个实验。

优先级参考:

  1. 修正明显的重复 GM 访问和不必要的数据搬运。
  2. 检查 UB 使用量、Tile 大小、向量对齐与尾块。
  3. 检查核数、行/列划分、工作量均衡以及 GQA/Reduce 类特殊负载的并行度。
  4. 在依赖合法的前提下安排 DataCopy 与 Vector 的流水重叠。
  5. 在有测量依据时尝试 C API、指令级布局或特殊路径。

对任何改动都说明:假设、作用路径、预期影响、潜在正确性风险、回退办法。

4. 用诊断实验隔离瓶颈(只限诊断)

可以临时构造去除 Reduce、跳过部分仿射、固定比例因子等“故意输出不正确”的微实验,以观察某个阶段是否可能产生大幅开销。

必须将这些文件和结果显著标记为 DIAGNOSTIC / WA,不得作为可提交的正确解。 测出的时间差只是包含编译器重新调度与资源变化的对照效果,不等于“单个指令耗时”。

5. 运行、归档与接受标准

顺序为:编译检查 → 正确性全覆盖 → 性能测量 → 与原基线对照。

  • 如果存在正确性失败:标记 FAIL,不以性能更快为理由接受。
  • 对短 Kernel,建议交错测试 A/B 多次;记录测量次数、聚合方式及波动范围。
  • 不将模拟器结果直接等同于实卡结果。
  • 每次只保留通过全部必要正确性测试且具备可重复收益的候选。

对于具有 case,status,latency_us 列的 CSV,可运行:

python3 scripts/compare_runs.py examples/baseline.csv examples/candidate.csv

若日志为其它格式,先将测量单位与列名规范化,再使用脚本。

6. 输出格式(必须包含)

  1. 现状:正确性、工作负载、基线数据、尚不清楚的条件。
  2. 瓶颈假设:证据和不确定性;区分“实测事实”和“推断”。
  3. 本轮改动:被修改的函数/路径及变更点;单变量原则。
  4. 验证计划:完整可执行命令或需要用户提供的实际命令。
  5. 结果与结论:每测试点 Pass/Fail、延迟、加速比;未测必须写“未测试”。
  6. 下一步:只给一项最值得做的对照实验,并给出停止/回退条件。

避免的常见错误

  • 未核实就断言“瓶颈一定是 MTE2”。
  • 用故意 WA 的极简内核的耗时宣称正式优化收益。
  • 混合多个改动后把收益归功于其中一个。
  • 忽略输出精度、非整块长度、shape 范围、dtype 和并行竞争。
  • 忽略性能波动,凭一次结果判断亚微秒级差异。
  • 编造 CANN API、硬件指令或具体测量数值;若版本不明,先询问或查当前文档。

示例

参考 逐轮诊断示例。

<!-- OB-S:375uZ1iIivdifahOVFAxFg -->