本章不只讲“怎么优化”，更强调优化前后的测量协议。没有测量，就无法区分模型慢、拷贝慢、预处理慢还是同步慢。
先给出本讲路线图；后续每一段都对应这里的一行，最后回到路线收束。
先把端到端链路拆开，再决定计时边界。一个“优化”如果只减少 execute，却让端到端 p95 变差，就不能直接验收。
10次记录的作用是验证脚本和展示方法，不足以宣布生产 SLA。尤其设备仍有 Health Alarm 等背景因素时必须标注。
计时工具和 Profiling 不是互相替代关系。先知道哪个阶段可疑，再用 Timeline 解释为什么可疑。
先让学生把“性能问题”映射到脚本。一个脚本同时改预处理、拷贝和并发，就无法解释收益来源。
这不是推荐写法，而是可诊断基线。先让低效路径可测量，再用同一协议验证复用是否改善端到端指标。
原始日志只有 count=10，没有实际 warmup 数、完整命令和逐样本板况。脚本默认 warmup 5/runs 100 不能反推为本次参数，因此这里必须把 warmup 写成“未记录”。四个均值只覆盖 10 个计时样本，不是总执行次数或稳定吞吐。
重点训练“数字要带范围”。离开模型、输入、代码路径和板卡版本，性能数字没有可复用意义。
Buffer 复用是确定内存生命周期，不是单纯追求一个加速比。必须验证资源没有提前释放，且输出仍然正确。
保留 2.034x 和 1.994x，但不要把 CPU 工作区复用写成 NPU 加速。样本数是20，也不能冒充 ResNet18 的10次执行记录。
不要预设“用了 DVPP 就一定更快”。本次课件不加入新的 DVPP 数字，只讲比较方法和固定开销来源。
AIPP 的比较对象是两条不同输入合同。先校验预处理后的数值与输出一致性，再看耗时，不能只换 OM 文件。
1.818x 和 1.815x 只能归到模拟模式。日志缺实际 frames、queue depth 和 stage sleep，脚本默认 frames=200 又不能解释 wall，因此必须明确协议未完整保留，不能写成 NPU 端到端吞吐或完整可复现基准。
要求学生从症状出发，而不是从 API 出发。每个动作都要说明预期改善哪个指标，以及失败时如何回退。
验收报告必须让下一位同学能复现。没有运行次数、阶段边界和版本，任何加速比都不能复用。
最后检查学生有没有把不同实验混成一张性能表。正确的结论必须带样本数、阶段边界和证据组。