边缘计算与实时推理——在Jetson上跑火焰检测的那些血泪教训
你可以在服务器上用A100训出一个精度99.9%的火焰识别模型，但你没法在监控杆子上装一台A100。真实的部署环境是：一个5瓦功耗的嵌入式盒子、8GB内存、2TOPS算力、环境温度可能到60°C、夏天太阳直晒下还得降频。在这个硬件上把模型跑起来、跑得快、跑得稳，才是检验一个火焰识别团队真功夫的地方。
我先泼一盆冷水——市面上80%的火焰识别创业公司，根本没有边缘部署能力。他们的demo演示是在一台配了RTX 4090的台式机上跑的，客户看了觉得"效果不错"，签了合同。一到现场部署，发现提供的算力盒子跑不动，要求客户升级硬件，客户一算账发现多花好几倍的钱，项目就黄了。
那边缘部署到底难在哪儿？我一条条说。
第一条：模型剪枝和量化是必修课，不是选修课。
你训练的时候用的是FP32精度的ResNet-101，几百MB的参数量，在Jetson Xavier NX上推理一帧可能要2秒钟。你必须做结构化剪枝砍掉不重要的通道，然后做INT8量化把模型压缩到原来的四分之一大小。
结构化的通道剪枝在火焰识别模型上尤其有效，因为火焰特征的稀疏性很强——很多通道学到的特征响应在整个数据集上都非常弱，砍掉它们对精度几乎没有影响。我做过实验，把一个YOLOv5s的backbone通道数从320剪到160，mAP掉了不到0.5个百分点，推理速度却翻了1.8倍。
但剪枝这事儿吧，工具链极其混乱。NVIDIA的TensorRT支持不错的剪枝和量化工具，但你需要先用ONNX导出模型，再用TensorRT做优化，中间稍有版本不兼容就报错，报错信息还极其晦涩。我曾经花了三天时间解决一个"算子不支持INT8"的问题，最后发现是某个自定义的激活函数在TensorRT里默认只支持FP16，需要手动在配置里开放INT8权限，这种坑真是踩一次记一辈子。
第二条：推理管线的"帧率抖动"是常态，你得学会容忍。
边缘设备上跑火焰识别，你绝对做不到每秒25帧稳定输出，实际运行的时候帧率会在10到30之间剧烈波动，取决于当前的CPU负载、内存使用、温度降频、系统后台任务调度。你如果要求每一帧都不丢、每一帧都出结果，那系统的实时性就废了。
工程上的做法是异步双缓冲流水线：一个线程负责从摄像头拉流和预处理，不停地把帧塞进一个环形缓冲区；另一个线程负责跑推理，从缓冲区里拿帧处理。推理线程跑得慢没关系，缓冲区丢帧就丢帧，只要推理线程拿到的帧是"当前最新的那一帧"就行。这样整个系统的"有效帧率"就是推理速度，而不会因为拉流和推理的速度不匹配导致卡顿。
第三条：I/O和显示的开销比推理本身还大。
这事儿很多做服务器的算法工程师根本意识不到。他们在服务器上测试的时候，输入是硬盘里读出来的图片文件，输出只是print一个检测结果。到了边缘设备上，输入是USB摄像头或者网络流（RTSP），输出要叠加画框和标签显示到HDMI接口或者编码成视频流推出去。这几个I/O操作的耗时加起来，经常比模型推理本身还多。
我优化过一套系统，推理只花了50毫秒，但RTSP拉流解码用掉了30毫秒，叠加画框用掉了20毫秒，显示输出又用了40毫秒，整个cycle下来140毫秒，帧率不到7帧。后来怎么优化的？换硬解码（用NVIDIA的硬件视频解码器），换低延迟的RTSP库，把画框的渲染从CPU挪到GPU，最后把整体cycle压到了80毫秒以内。这些优化跟深度学习算法一毛钱关系都没有，全是传统嵌入式开发的内容，但你没这些经验，边缘部署就做不成。
第四条：设备环境极其恶劣，你得考虑"容错设计"。
边缘设备通常装在户外或者工业现场，温度、湿度、灰尘、震动都远超实验室环境。设备一旦死机或者重启，你得保证系统能自动恢复。所以我们部署的系统都有看门狗（watchdog）定时器——如果程序30秒没有心跳，系统自动重启。
还有一个常见故障是摄像头断流。工业现场的网线可能被老鼠咬断、被叉车压断，或者交换机断电。断流恢复之后，程序要能自动重连摄像头，而不是卡死在"等待新帧"的死循环里。我们踩过这个坑——第一版程序没有做超时重连，某天晚上摄像头电源掉了，程序一直阻塞在receive函数里，第二天早上人来了一看，系统死透了，最后只能强制重启。
第五条：OTA远程升级，这事儿比你想的复杂。
一套火焰识别系统部署在几十个甚至几百个点上，你不可能每个点都派人去现场插U盘升级。必须做OTA（Over-The-Air）远程升级方案。
但OTA在边缘设备上有两个风险。第一个是"升级包传输中断"——网络不稳定的时候升级包下了一半断了，旧的模型已经删了新的又没下完，系统就成砖了。所以必须做双分区设计——一个主分区跑当前模型，一个备分区用来下载新模型，下载完成并校验通过后，下次重启时自动切换主备分区。第二个是"新模型精度变差"——模型升级后在特定场景下反而不如旧版本，这种时候你得有"一键回滚"的机制，能快速切回上一个稳定版本。
这些工程问题在论文里是看不到的，但在真实项目里它们占掉的时间和精力远远超过算法研发本身。我有时候觉得，做火焰识别的算法工程师和做部署的嵌入式工程师，活在两个平行宇宙里。前者关心mAP涨了多少，后者关心今晚设备会不会死机。
所以如果你是一个刚入行的CV算法工程师，我真心建议你花时间去了解一下部署侧的痛苦。自己去买一块Jetson Nano或者RK3588的开发板，把你训好的火焰检测模型移植上去跑一跑，从拉流到推理到显示输出全流程自己实现一遍。这个过程你会发现自己对模型架构的选择、对算子的兼容性、对内存管理、对多线程编程的理解，都会上升好几个台阶。那些只在Jupyter Notebook里跑过模型的人，永远做不出真正的工业级火焰识别产品。
最后一条，也是最重要的一条——别在边缘设备上追求"SOTA精度"，没意义的。边缘场景的火焰识别，用户最大的诉求是"稳定"和"快速"，而不是"今晚识别精度比昨晚高了0.3%"。把模型做到80分的精度、99.9%的稳定性，远比做到95分的精度、天天死机有价值得多。稳定压倒一切，这是边缘部署的第一法则。