NPU性能画像不能只盯利用率

很多团队做性能排查时，第一眼就看利用率曲线，数字低就怀疑算子没铺满，数字高就以为系统接近极限。NPU如果只剩这一根指标，很多慢路径都会被错判，因为高利用率未必代表高效率，低利用率也未必意味着算力闲着。

最需要先区分的，是饥饿和空转。饥饿指的是后端阵列明明可用，却在等输入、等权重或等命令；空转则是任务本身拆得太碎，硬件不断在不同阶段切换却没有形成有效计算。两者在总利用率图上都可能表现为“没有跑满”，但优化方向完全不同。前者应回头查数据喂给和仲裁，后者则要看图切分、命令打包和同步边界。

单一利用率还会掩盖流水空泡。某些计数器把任一子模块忙碌都算成“设备活跃”，于是前端在收命令、DMA 在搬数据、后端在等待时，曲线仍然很好看。现场团队若据此判断“硬件已经很忙”，就会错过真正的空泡来源。对复杂图来说，更有价值的是把前端、访存、执行阵列和写回分别计数，再看它们是否在时间上连成连续流水。

性能计数器的采样窗口也会制造假象。取样太长，会把少数慢帧平均掉；取样太短，又可能只看到局部波动却错过整图趋势。尤其在多模型并发或周期性外设打断的场景里，慢问题往往不是持续存在，而是每隔几秒在同一位置出现一次。若计数器不能和帧序号、层级时间线或外设事件对齐，再多指标也只是漂亮噪声。

跨层关联因此很关键。某层执行时间变长，未必是这层算法突然复杂，可能是前一层写回拖慢了它的读入，也可能是下一层的共享缓冲未释放导致当前层被迫等待。只看单层 profiling，团队容易把症状当原因。把层级时间线和硬件计数器叠在一起，才有机会看出“慢的是谁”和“拖慢它的是谁”不是同一个对象。

还有一类常见误判来自计数器定义差异。不同芯片对“忙时”“等待”“气泡”的统计口径并不相同，同一概念在两个平台上未必能直接比较。若工具链升级后计数口径变了，而团队还沿用旧阈值，就可能把正常变化看成退化，或把真实退化误认为统计差异。性能画像首先要知道每个数字到底在数什么。

更稳妥的诊断流程，是先建立一条可解释的最小时间线：命令何时提交、数据何时到位、阵列何时开算、写回何时结束，再把计数器映射到这四段上。这样当利用率变化时，团队能立刻判断它属于饥饿、拥塞还是调度切碎，而不是在抽象百分比里来回猜。

采样本身也要控开销，因为高频取样若侵入命令路径，会把原本不存在的慢帧测出来。诊断工具若不先自证轻量，画像结果就可能一边观察一边改写被观察对象。

若还能把计数器与少量金标准样本绑定，团队就能判断某次利用率变化究竟影响了真实性能，还是只是统计口径换了一层外衣。

性能优化要的，不是更多孤立指标，而是把指标还原成执行流。只要饥饿与空转能被明确分开，NPU的利用率数字才会从表面热闹变成可操作的工程线索。