模型部署与推理耗时优化

优化推理耗时最容易犯的错误是先动手再测量。拿到一个跑得慢的模型，直觉是换一个更小的，结果是精度掉了、时间也没省下来，因为瓶颈根本不在模型上。正确顺序是先分解：从相机触发到结果输出这条链路，采集占多少、预处理占多少、推理占多少、后处理占多少、结果发布占多少。把每一段测出来，才知道该动哪里。

耗时的分布常常反直觉

实测经验里，许多工位的时间并不主要花在推理上。图像从相机搬到主机内存要时间，尤其在多相机同时工作的时候；预处理里的缩放、色彩空间转换、归一化，在通用 CPU 上逐像素做一遍，耗时可能与一次小模型的推理相当；后处理里的阈值分割、轮廓提取、连通域分析，在图像分辨率高时同样可观。如果只优化模型，这些段落一分钱都省不下来。

另一个常见现象是等待。程序的耗时不一定花在计算上，也可能花在等：等相机把这一帧传完、等上次推理的结果、等磁盘把记录写完。这类时间在单帧测试里看不出来，因为它被前一段的计算掩盖了；只有在连续跑几百帧、统计每帧从触发到输出的端到端时间时才会暴露。所以测量的口径应该是「端到端延迟的分布」，而不是「推理函数的平均耗时」。

分辨率是第一杠杆，也是第一个陷阱

把输入分辨率从 1024 降到 512，像素数少四分之三，推理耗时大致按这个比例下降，这是所有手段里收益最直接的一条。但它同时会改变检测能力：原本占若干像素的小缺陷，下采样之后可能只剩一个像素，甚至混进背景里消失。所以降分辨率必须与检出率一起验证，用固定的样本集跑一遍，看有没有原本能检出的缺陷掉了出去。

一个更精细的做法是分区处理：大部分区域用低分辨率快速排除，只在可疑区域用高分辨率复核。这相当于把算力花在真正需要的地方，代价是逻辑变复杂、需要一套可靠的粗筛机制。当节拍很紧、而缺陷又可能出现在任意位置时，这个思路通常比单纯降分辨率更划算。

显存、内存与首帧开销

按帧统计耗时的时候，有几项开销很容易被漏掉。第一是首次推理的长尾：模型加载、显存分配、算子预热都发生在最初几帧上，如果统计时把它平均进去，会得到一个偏乐观的数字，正确的做法是跑够几百帧之后再看稳定区间的分布。第二是内存带宽而不是算力：高分辨率图像在几段处理之间来回拷贝，瓶颈常常落在拷贝上，而把预处理放进加速器内部完成可以省掉这一整段。第三是日志与存图：工位每秒产生几十兆图像，写盘如果同步执行，会直接卡住流水线，异步写和批量落盘是必须的。这三项加起来常常占掉可观的一段时间，而它们都不在模型里面——这也解释了为什么换一个更小的模型有时几乎看不到改善。一个实用的判断方法是把整条链路按段打时间戳跑上几百帧，看每段的分布而不是平均值：平均值会被少数快帧拉低，掩盖掉长尾，而真正决定会不会丢帧的恰恰是那个长尾。