当前位置：首页 > news >正文

CANN / cannbot-skills：分册5性能评估与精度对比

news 2026/7/4 6:54:07

分册 5：性能评估与精度对比

【免费下载链接】cannbot-skillsCANNBot 是面向 CANN 开发的用于提升开发效率的系列智能体，本仓库为其提供可复用的 Skills 模块。项目地址: https://gitcode.com/cann/cannbot-skills

对应主流程§7～§8（分册正文 §8.1.1 = 训练短测，§8.2 = 正式训练排查）。

7) 性能评估（可选，把延迟/吞吐变成可复现的对比）

目标：在同一输入分布、同一 batch/并发设置、同一测量口径下，给出可与基线对比的延迟与吞吐数据；并在性能不达标时能快速定位瓶颈属于预处理/后处理/IO/推理内核哪一段。

7.0 测量顺序（推荐，与`Mig_Readme`、`Compare`对齐）

短测、冒烟、约定性能路径：先在目标昇腾 NPU 环境跑通并落盘指标（与Mig_Readme.md§3.1 所选数据集、batch、测量口径一致），优先填满Compare.md中「昇腾 NPU」相关列与Mig_report验证摘要。
再提供基线侧入口（仅当无完整日志或需补采时）：若项目内无可直接引用的完整训练日志，或日志缺推理性能等项，则在Mig_Readme.md§2.6补齐GPU上的训练（若适用）与推理「调用接口」——可复制的命令、脚本路径、虚拟环境、--device/CUDA_VISIBLE_DEVICES、batch、模型权重与 IO 约定。GPU baseline 由用户自行执行采集（默认 baseline 为 GPU），agent 只负责接口与口径说明；用户回传结果后再回填Compare.md。
与下面「基线选取」的关系：下面 §7 规定权威 baseline 来源（项目完整训练日志优先；否则默认 GPU）；执行顺序不强制「必须先有 baseline 数字」；允许NPU 数据先于 baseline 就绪，但归档与结论须待Compare.md口径对齐后定稿。

性能基线选取：

优先：项目内完整训练日志。检索仓库内训练/评测日志；若含与验收对齐的指标、数据集、环境与 batch/超参说明，直接摘录为 baseline，注明路径，无需重跑。
否则：默认 GPU baseline。性能对比以GPU为默认对照；由用户按Mig_Readme.md§2.6在 GPU 上补采；无可用 GPU 时填N/A并说明，暂停误导性对比。
CPU 对照（可选）：非默认；仅在项目明确要求或日志本身为 CPU 时补充。
与 NPU（昇腾）结果对比时，须说明 baseline 来自项目日志还是GPU 实测，避免读者误读。

触发条件（满足其一即可进入本节）：

用户明确要求性能测试或性能对比
环境检测结论为“可直接执行测试”且用户同意执行
项目验收标准中明确包含延迟/吞吐 KPI

若不满足触发条件：agent 应输出“未执行原因 + 待满足条件 + 可直接复用的测试命令模板”。

让 agent 在这一节必须输出 5 部分内容：测量范围、实验设置、指标口径、基准复现、性能报告模板。若默认GPU baseline因无可用 GPU且项目内无完整训练日志而无法建立对照，须在Compare.md填N/A并说明原因，暂停误导性对比。

7.1 测量范围（明确你在算哪段时间）

让 agent 选择并写清楚性能测量口径，至少包含下列一种或多种（推荐“分段”）：

端到端延迟：从“输入准备完成”到“输出准备完成”
推理纯耗时：只统计模型执行/设备侧推理时间（不含 Python/CPU 后处理）
预处理/后处理耗时（如果你的工程里有这两段）

要求：性能报告中要明确“本结果包含/不包含哪些环节”，避免口径不一致导致误判。

7.2 实验设置（减少波动的关键）

让 agent 给出并坚持以下实验设置，并将其写入输出（便于复现）：

环境固定：同一台机器，同一驱动/同一 CANN/同一代码版本与配置
batch size：列出要测的 batch 列表（至少包含 1 和目标 batch）
并发/线程：说明是单请求顺序还是并发（若不确定，先从单请求测起）
warmup：给出 warmup 次数建议（例如 10 次起步）并说明原因（预热缓存/编译初始化）
采样次数：给出 iterations 建议（例如 100 次起步）与统计指标（p50/p95/平均）
执行顺序（与§7.0一致）：先在NPU按同一口径完成短测/性能并记录；若无完整训练日志，再在Mig_Readme.md§2.6提供GPU 调用接口供用户执行 baseline。agent 不代跑 GPU 测试；采集顺序上 baseline 可晚于 NPU，但对比表定稿前须具备日志摘录或 GPU 实测（或 N/A + 原因）。

7.3 指标口径（建议统一成“延迟 + 吞吐”双指标）

让 agent 使用以下指标集合并在报告里逐项填充（没有也要给出计算方法/公式）：

Latency：p50/p95（单位 ms），以及平均值（可选）
Throughput：吞吐（如 images/s 或 samples/s），并注明按 batch 计算还是按请求计算
可选扩展：显存/内存占用、失败重试次数（如果工程支持）

7.4 基准复现（保证“测出来的就是同一个东西”）

让 agent 给出“可复现输入与数据一致性”要求：

写明各阶段所用数据集（短测、冒烟、全量精度/性能等），并与Mig_Readme.md§3.1 对齐；下载方式见同文件 §3.2
使用与精度评估相同的输入数据集划分与预处理配置
固定随机种子（若适用）
输入数据的尺寸/通道顺序/归一化参数与训练/基线保持一致
记录输出的校验方法（例如抽样对比 top1/mAP 或输出统计特征），确保性能测试没有“跑偏数据”

7.5 性能报告模板（agent 必须按字段输出）

要求 agent 在最终输出中给出类似下面的结构（可用 Markdown 表格呈现）：

迁移后（NPU，通常先就绪）vs 基线（优先：项目完整训练日志；否则默认 GPU实测；经§2.6提供接口由用户补采）：延迟 p50/p95、吞吐、batch size、测量口径（端到端/纯推理/分段）
对比结论：是否达到目标（通过/不通过）
瓶颈定位建议：优先按“预处理/后处理/IO/推理内核”给出一到两个最可能原因

同时要求：保存运行日志与 profiling 结果（若可用），用于回归定位。

8) 精度对比与回归报告（可选，迁移是否成功）

要求 agent 给出一份对比报告框架（即使没有最终数值，也要给出结构与需要的字段）：

与基线差异：精度指标、主要错误类型（如果能观察到）
性能差异：延迟与吞吐、瓶颈推测（前后处理/IO/批大小）
结论：通过/不通过/需调整的具体项

触发条件：

用户要求给出可量化回归结论
已具备可复现测试数据与基线口径
环境检测允许直接跑测试，或用户提供了离线测试结果供回填

数值一致性（在跑全量指标前强烈建议）：

Golden 样本：同一批固定输入（含预处理后的 tensor），在基线与 NPU 路径上各跑一次（可与§7.0一致：先固定 NPU 侧输出与口径，再由用户按Mig_Readme.md§2.6在GPU上补跑基线同输入，或引用项目训练日志）
对比：输出 tensor 的 shape、dtype、NaN/Inf、均值/方差/最大绝对误差；分类任务可对比 top-1 是否一致（小批量）；逐元素 rtol/atol须按目标精度设定（默认 FP16 见Compare.md§3.1，勿套用 FP32 级atol 1e-5）
若数值差异大：优先查预处理、输入 layout、后处理是否接错输出头，再查量化与算子替换

8.1 代码级迁移适配训练/推理测试（与「精度/性能对比」的关系）

精度、延迟、吞吐对比（见本分册 §7～§8 与 Compare.md）主要是在数据集或基准集上算业务指标，回答「效果与速度够不够」。

代码级迁移适配的训练/推理测试侧重「实现与图是否健康、能否稳定跑通」，通常在更小粒度上做，与上者互补，不是替代关系：

类型	典型内容	回答的问题
推理侧（代码级迁移适配）	固定输入的smoke：shape/dtype、无 NaN/Inf、输出范围合理；Golden与基线逐元素或统计量对比；多输出头是否接对	推理链路、预处理、设备/数据流是否与预期一致
训练侧 smoke（若迁移后仍训练）	单 batch 或极少 step：前向+反向+优化器是否跑通；loss 有限；梯度是否异常（全零/爆炸）；checkpoint 保存再加载是否一致	训练脚本与 NPU 适配层能否跑通
训练短测（可行性向，若迁移后仍训练）	在短子集 / 约定少 step上观测loss：相对短测起点整体稳定、明显下降，且相对降幅约 30%～50%（项目可在`Mig_Readme`§3.1 备注中收窄或改写区间）	可行性：链路与损失是否正常收敛到「够用」门槛；达标即停（见§8.1.1）
自动化（可选）	`pytest`/CI 中的小型用例：CPU 参考 vs NPU 同输入输出一致性（允许量化误差阈值）	回归时快速发现破坏性变更

让 agent 根据项目是否「仅推理」或「仍训练」给出建议，并在Mig_report.md的验证摘要中勾选是否已做：推理 smoke、Golden、训练 smoke（若适用）、训练短测（若适用）；全量精度/性能仍以 Compare.md 为准。

8.1.1 训练「短测」：通过准则与「达标即停、勿重复」（训练短测收口）

与§8.2 正式训练区分：本节是最小代价确认「能训、loss 能明显往下走」；不是part-02 可行性预判，不是调参长跑，也不是§8.2 中「继续加大 iteration」的场景。

指标：默认以loss（或团队在Mig_Readme§3.1 书面指定的唯一主损失）在短测窗口内的相对起点变化为准。
通过（短测判定）：loss稳定降低，且相对短测起始值累计降幅落在约 30%～50%（允许略出区间，但须在Mig_report写清实际百分比与曲线截图/日志路径）。达到即视为训练短测通过。
停止与禁止重复：一旦满足第 2 条，本阶段短测即结束；不要为「再确认一次」在同配置、同短测定义下重复多轮；也不要在已通过短测后再叠加同类短测拉长总步数。后续若需更长训练，进入正式训练或按Mig_Readme.md§5.3与§8.2，而非重复短测。
仅推理项目：不适用本节；短测一词在数据表可仍指「最小前向验证」，见Mig_Readme§3.1 说明列。

8.2 训练阶段：迭代加大与「代码/模型问题」判定（若迁移后仍训练）

适用于正式训练或加长验证跑（不含已通过且已收口的§8.1.1 训练短测）。训练短测达标后即停，勿按本条再对短测「加 iteration 重复验证」。代码级迁移适配 smoke仍以跑通、有限 loss、梯度无爆炸为主，不必套用下述 500 步阈值直接判废。

阶段性观察：在约定 checkpoint 或一轮训练结束时，若loss 下降不明显，或与任务相关的其它指标（如验证集精度、mAP、perplexity 等）相对基线/预期无明显变好，在算力与时间允许下，适当增大 iteration（或 epoch /max_steps等等价训练步数），并记录曲线、学习率与数据管线版本。
停止「只加步数」的阈值：若在已合理加大学习率/数据与上述迭代策略的前提下，累计优化步数（iteration 或等价总 step）大于 500仍无明显改善（loss 与关键指标相对起点或基线仍停滞）：优先怀疑模型结构、实现或数据管线，而非单纯「还没训够」。
后续动作：暂停继续堆叠 iteration；对代码与模型实现做系统检查与修复（例如：标签与loss是否一致、head 与冻结层、NPU 上自定义算子/替换路径是否改变梯度、学习率调度、数据增强与归一化是否与基线一致），修复后从小步数回归验证再逐步加大；过程写入Mig_report.md§7。
文档：在Mig_Readme.md§5.3填写本项目实际采用的阈值、指标名与命令参数，便于交接。