Orin 上同一模型 FPS 不同：测量方法、功耗和前后处理拆解

文章目录1. 结论先行2. 为什么「同一模型」也会差很远3. 建议的四段计时3.1 一个演算例子4. 一张最小记录表5. 功耗档和温度同一套代码的两个世界6. 和同事对齐时的问法7. 适合怎么用这张表7.1 实施计时实现上的两点提醒8. 常见误区9. 术语速查9.1 和「换模型」决策怎么衔接10. 小结摘要Jetson Orin 上跑检测时最常见的争论不是模型本身而是两边报出来的 FPS 差一截。本文把测速拆成可记录的几段读帧、预处理、纯推理、后处理与画框并说明功耗档、分辨率、是否含编解码如何写进测试记录。适合已经能在 Orin 上跑通推理、准备对外报数或和同事对齐指标的人。读完应能搭一张最小测速表避免用不可比的数字做决策。说明具体nvpmodel档位名称随板型与 JetPack 变化以你板上nvpmodel -q为准。文中不给脱离条件的绝对 FPS。1. 结论先行FPS 是测法的产物不是模型的身份证。先拆时间线再谈优化读帧、预处理、推理、后处理/画框/写盘。记录里至少固定板型与 JetPack、功耗档、输入尺寸、batch、是否端到端。DevKit 峰值不能直接当量产指标散热和外壳会改掉频行为。和别人对数字前先对测法测法不一致时争论没有公共前提。能写进方案书的不是某次碰巧测到的峰值而是带条件的、可复测的区间。2. 为什么「同一模型」也会差很远两边都说自己跑的是同一个权重仍可能出现A 报 45 FPSB 报 18 FPS博客里的数字和你板上差两倍换个分辨率或开个远程桌面数字又漂了常见不是权重文件不同而是计时边界不同。有人只算 GPU 内核时间有人从读图算到 OpenCV 画框有人锁了高性能档有人默认省电档还在降频。还有几类更容易被忽略的差异差异点典型表现输入来源本地图片 vs USB 相机 vs RTSP是否画框/编码纯推理很快一存 mp4 立刻变慢预热把冷启动算进平均数字系统性偏低并发同板还跑着别的容器或桌面合成精度策略FP32 / FP16 / INT8 混着比图1. 端到端 FPS 往往被 D 段拖住却被误写成模型不行。3. 建议的四段计时用同一组输入固定视频或图片集分别记段包含什么容易忽略A 读帧/读图相机、解码、文件 IOSSD/SD 速度差、USB 相机抖动B 预处理resize、归一化、letterbox、色序CPU 上做还是 GPU 上做C 纯推理引擎/框架 forward是否含第一次建引擎的预热D 后处理NMS、画框、编码、写盘、展示保存视频时 D 段可占大半对外沟通时写两行纯推理 FPS主要看 C端到端 FPSABCD产品验收通常看端到端模型迭代对比更宜看纯推理并固定 A/B/D 的实现。否则你优化了引擎同事却在比「含画框存盘」的旧口径两边都会觉得对方在吹牛。3.1 一个演算例子假设某次拆段结果示意单位 ms/帧段耗时A8B6C12D24则纯推理约 (1000/12 \approx 83) FPS端到端约 (1000/50 20) FPS若只报 83现场一接相机一画框观感会断崖。优化顺序上D 段往往比再抠 C 段更划算少画调试框、异步写盘、降低编码码率都可能直接抬端到端。4. 一张最小记录表每次报数前填这些字段图2. 缺任一字段数字都很难复现。board: Orin Nano / NX / AGX 内存 JetPack / L4T: x.x nvpmodel: sudo nvpmodel -q input: 640x640 / 1280x720 ... batch: 1 warmup: 50 iter, measure: 200 iter metric: pure_infer | e2e include_draw: yes/no include_encode: yes/no temp note: tegrastats 是否接近降频 clock note: 是否手动 jetson_clocks预热很重要。第一次推理常含引擎加载、缓存分配把冷启动算进平均值会系统性偏低。建议固定warmup N 次不计入再测 M 次取平均并附带标准差或 min/max避免只报最好的一次。团队协作时把上面模板存成仓库里的bench_template.md比口头对齐可靠。5. 功耗档和温度同一套代码的两个世界sudonvpmodel-qtegrastats切换档位后再测不要假设上次测过就还一样。短时冲高温度不一定立刻掉速但贴着降频点跑数字会抖。量产壳和 DevKit 开放散热不是同一工况。方案书里若只写峰值现场一装壳就翻车。更稳妥的写法是给定功耗档与壳温上限下的区间而不是单点神话数字。几点实践开发压测可以开高档但要看壳温和风扇是否在转对比实验必须同档跨档对比要明确写出来若使用锁频类脚本记录里也要注明否则别人复现会偏6. 和同事对齐时的问法开会前先问清你的 FPS 含不含画框和写盘输入分辨率和 batch 是多少nvpmodel当时是哪一档有没有看温度测的是本地文件还是实时相机有没有 warmup样本多少这几句比继续换模型省时间。若对方答不全先补测再争论架构。7. 适合怎么用这张表更适合对内迭代固定纯推理口径比模型对外验收固定端到端口径与工况排障看哪一段突然变长不太适合用单次峰值写进不可撤销的合同条款把不同分辨率、不同档位的结果画在同一张进步曲线上却不标注条件7.1 实施不必一次上完整压测平台。按三天做就够用第 1 天定口径和产品/算法对齐两行对内看纯推理对外看端到端。把记录模板放进仓库缺字段不许贴到群里当结论。第 2 天拆四段同一输入跑通 A/B/C/D。若没有精细探针至少用墙钟时间包住四段函数先拿到数量级。重点看 D 是否异常大。第 3 天固定工况再比模型锁同一nvpmodel、同一分辨率、同一是否画框。只在这时换引擎精度或模型结构曲线才有意义。若项目已接近验收再补短时温升曲线、装壳后复测、断网/相机重连后的恢复时间。这些不一定进 FPS 公式但常决定现场能不能稳住。计时实现上的两点提醒同步点GPU 异步队列未同步就读时间会把内核时间测偏。需要在段边界做 device synchronize或框架等价 API。不要用打印当计时日志 IO 本身会污染 D 段。正式数字用安静模式跑。8. 常见误区误区更稳妥的做法拿博客 FPS 直接写标书按本机记录表重测并写清条件端到端变慢就换更大模型先看 D 段是否在存视频/画框只测几帧就报均值固定 warmup 足够样本远程桌面开着测 UI 链路远程显示本身占 CPU/带宽混用 FP16 与 FP32 结果精度策略写入记录9. 术语速查术语含义纯推理主要统计模型 forward 段端到端从输入到可用输出的全链路warmup不计时的预热迭代nvpmodelJetson 功耗模式降频温度或功耗触发的频率下降batch单次推理打包的样本数9.1 和「换模型」决策怎么衔接测法对齐之后优化才有顺序D 段过大 → 先减画框/编码/同步写盘A 段过大 → 查相机、解码、存储介质B 段过大 → 预处理搬到 GPU 或减少重复转换C 段仍不够 → 再谈 TensorRT 精度、输入尺寸、模型结构很多人一上来就换更大/更小模型等于在未校准的秤上称重量。秤校准了模型对比才便宜。若你同时维护多块板Nano 与 AGX 混用记录表要分板归档不要把 AGX 的端到端数字直接贴到 Nano 的验收单上。10. 小结Orin 上 FPS 对不上优先怀疑测法而不是先怀疑板子或权重。把时间拆开、把条件写全数字才有比较意义。能复现的测法本身就是边缘项目的交付物之一。