CANN oam-tools 之 npu-perf-analysis Skill 评测用例集解析5 大场景如何验证 NPU 性能分析的准确性【免费下载链接】oam-tools本项目为开发者提供故障定位工具包含故障信息收集软硬件信息展示AI core error报错分析等能力提升故障问题定位效率文档可在昇腾社区搜索“故障处理简介”选择社区版。项目地址: https://gitcode.com/cann/oam-tools本文围绕 oam-tools 仓库中npu-perf-analysis性能分析 Skill 的标准评测用例集展开系统拆解 5 个评测场景的输入条件、预期输出结构与关键断言并结合 SKILL.md 及其配套的阈值表、指标公式与数据 Schema说明每个断言背后要验证的能力点。读完本文你将掌握如何用一套可量化的断言体系检验 AI Agent 的 NPU profiling 分析正确性如何识别预热步、等待锚点假热点、Host Dispatch 瓶颈等典型性能陷阱以及如何将评测方法论复用到你自己的性能分析工作中。一、背景npu-perf-analysis Skill 在评测什么npu-perf-analysis是 oam-tools 仓库skills/cann-npu-perfanalysis/中面向昇腾 Ascend NPU 的性能分析 Skill。它的核心任务是读取ASCEND_PROFILER_OUTPUT/目录下的 profiling 数据覆盖 8 个性能维度迭代效率、算子热点、硬件利用率/MFU、通信效率、设备空泡、等待锚点、层级结构、多卡均衡输出 Host/Device Bound 总判定、瓶颈诊断理由与 Markdown HTML 双格式报告。整个分析流程在 SKILL.md 中被组织为 Phase 0–4Phase 0 数据预检定位ASCEND_PROFILER_OUTPUT含嵌套目录递归扫描、清点文件建立能力矩阵、检测kernel_details.csv的 Schema 版本V1/V2、统计设备数与步数、检测芯片型号Phase 1 迭代效率计算computing_ratio/comm_not_overlap_ratio/free_ratio/overlap_ratio识别预热步判定瓶颈优先级Phase 2 深度分析算子热点维度 2、MFU维度 3、通信效率维度 4、设备空泡维度 5、等待锚点维度 6、层级结构维度 7、多卡均衡维度 8外加算子级 Compute/Memory Bound 判定Phase 3 瓶颈诊断按 P0–P3 优先级汇总输出事实 → 阈值对比 → 判定理由 → 置信度的证据链Phase 4 报告生成Agent 写report.md与analysis_data.json再由 generate_html.py 渲染单文件 HTML 报告。评测用例集正是为了回答一个关键问题这个 Skill 的分析结果到底准不准仅靠人工翻阅报告难以规模化验证因此需要用「输入数据集 预期输出结构 可检查的关键断言」三件套把分析质量变成可自动核对的事实。二、评测用例集总体设计eval-cases.md 共定义 5 个标准评测场景每个场景的数据集都有鲜明的性能特征覆盖 Skill 的核心能力面用例数据集模型类型核心验证点用例 1gemmaMoE 推理预热步识别Step 3 CommNO51.6%、MoE 特征算子、等待锚点 AivKernel 假热点用例 2qwen7bDenseQwen-7BP0 Host Dispatch 瓶颈free_ratio≈82%、严禁推荐通信优化用例 3ds3.2DeepSpeed ZeRO-3 训练单设备声明Device_id3、预热步Step 10 CommNO68.7%、双瓶颈诊断用例 4longcatMoE 长文本推理嵌套目录自动发现、P0 通信瓶颈74.1%、单 Rank 带宽声明用例 5gemmaMoE 推理等待锚点专项分析、假热点降级、真实热点识别每个用例统一采用三段式结构场景描述一句话说明数据集特征与评测意图输入数据路径 用户问题模拟真实用户提问方式预期输出结构 关键断言定义报告必须具备的章节/要素以及可数值核对的具体断言。值得注意的是评测不只关注「分析得对不对」还关注「不做什么」——5 个用例中有 3 个包含「不错误推荐」类断言用例 1 不得推荐优化 MatMul/减少通信量、用例 2 严禁出现通信优化建议、用例 5 不得把假热点当真实瓶颈这体现了性能分析中「对症下药」比「多多益善」更重要。三、用例 1MoE 模型预热步识别 等待锚点检测场景分析 Gemma MoE 推理模型的 profiling 数据数据路径为prof-data/gemma/ASCEND_PROFILER_OUTPUT/用户问题为「帮我分析这份 NPU profiling 数据看看有没有性能问题」。预期输出结构报告须包含「分析上下文」文件清单、Schema 版本 V2、步骤数 3、设备数 1、「迭代效率」Step 3/4/5 时间拆分表格、「算子热点」Top-10 表格、「等待锚点」被标记的 kernel、「瓶颈诊断」P0–P3 分级、「优化建议」并同时生成 Markdown 与 HTML 两种格式报告。关键断言解读断言 1.1预热步标注Step 3 的CommNO51.6%与 Step 4–5 的约 8–10% 差距超过 20 个百分点报告必须将 Step 3 标注为「疑似预热步不具代表性」且不参与正常步均值计算。这与 SKILL.md Phase 1 的预热步检测规则首步comm_not_overlap_ratio比后续步均值高出 20 个百分点即标注及阈值表第五节「预热步识别规则」完全一致——首个 Step 的 CommNO 偏高通常意味着初始 AllReduce 含初始化开销或 JIT 编译预热未完成。断言 1.2正常步瓶颈判定基于 Step 4–5 均值computing_ratio ≈ 70%、free_ratio ≈ 21%。21% 超过 10% 警告线但未超过严重阈值10%的 2 倍因此只应判为 P3 级别的轻微 Host Dispatch 风险不能升格为 P0。这直接对应用例 1 中iteration_efficiency.bottleneck的样例输出label: HOST_DISPATCH_MILD, priority: P3。断言 1.3MoE 特征检测算子热点章节必须出现MoeGatingTopKSoftmax、MoeComputeExpertTokens、GroupedMatmul、MoeInitRouting等 MoE 特征算子并说明其为 MoE 架构的正常计算开销而非瓶颈。这对应 SKILL.md Phase 2A 的moe_normal标注规则MoE 专属算子出现时不得建议「减少计算量」。断言 1.4等待锚点检测等待锚点章节须列出AivKernelwait_ratio ≈ 99.96%、Duration ≈ 6μs、Wait ≈ 16293μs并标注「假热点按 total_cost 排名靠前但实际计算时间极短真实原因在上游」。判定规则见 metrics-formulas.md 第三节wait_ratio Wait_Time_us / (Duration_us Wait_Time_us)is_wait_anchor (wait_ratio 0.95) AND (Duration_us 10.0)。断言 1.5不错误推荐优化建议中不得出现「优化 MatMul 算子实现」或「减少通信量」等不对症建议——因为真正的问题是设备在等待而非 MatMul 效率不足或通信量过大。四、用例 2Host Dispatch 严重瓶颈识别场景分析 Qwen-7B Dense 模型的 profiling 数据prof-data/qwen7b/ASCEND_PROFILER_OUTPUT/该数据集特征是 Free Time 极高约 82%且无通信操作用户问题为「为什么这个模型训练很慢效率低在哪里」。预期输出结构维度 4通信效率须明确标注「跳过无通信数据CommNO0Overlap0」维度 8多卡均衡须标注「跳过仅有单卡数据Device_id0」包含 P0 瓶颈诊断优化建议至少含一条针对 Host Dispatch 的具体措施。关键断言解读断言 2.1P0 Host DispatchStep 2–4 的free_ratio均在 81–83%超过严重阈值 10% 的 8 倍报告须输出优先级P0、标签HOST_DISPATCH_BOTTLENECK、证据free_ratio 82%Step 2/ 81%Step 3/ 81%Step 4。这对应阈值表的优先级规则任一指标超过严重阈值 2 倍以上即 P0同时HOST_DISPATCH_BOTTLENECK的定义为free_ratio 0.10。断言 2.2不推荐通信优化优化建议中绝对不能出现任何关于「通信」「AllReduce」「overlap」的建议——该数据集Communication全为 0。这对应 SKILL.md NEVER 列表禁止对Communication0的数据集输出任何通信优化建议。这也是评测「不错误推荐」权重为高的典型体现。断言 2.3首要建议指向 Host 侧P0 优化建议必须包含以下方向之一减少算子下发次数算子融合、图编译、检查 PyTorch eager 模式小算子碎片化、使用 torch.compile 或 mindspore 图模式。断言 2.4绝对热点与相对重要性区分MatMulV2以Ratio66.2%排名第一但报告必须区分「绝对热点」与「相对重要性」在free_ratio82%的情况下设备实际有效执行时间仅约 18%MatMul 的真实影响被放大首要问题是 Host Dispatch 而非 MatMul 本身效率。这呼应 contenteditable="false">【免费下载链接】oam-tools本项目为开发者提供故障定位工具包含故障信息收集软硬件信息展示AI core error报错分析等能力提升故障问题定位效率文档可在昇腾社区搜索“故障处理简介”选择社区版。项目地址: https://gitcode.com/cann/oam-tools创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考