嵌入式AI视觉落地的那些事儿——直面AI视觉落地难的挑战

从算法原型到嵌入式产品中间隔着一道不浅的沟。不少团队在PC上跑通了模型信心满满地往ARM板上一放才发现帧率掉到零点几界面卡死内存泄漏……这些问题不是靠调几个参数能解决的需要系统性地理解整个开发链条。一、QT界面开发算法与界面必须解耦嵌入式AI应用通常需要图形界面QT是常见选择。但开发中容易陷入一个误区把算法函数直接写在界面类的响应函数里。点一下“开始检测”界面就卡住直到检测完成才能动。QT的信号与槽机制天然适合处理这类问题。把耗时任务放在QThread里执行通过信号把结果传回主界面界面就能保持响应。更进一步可以用读写者模式管理多路视频一个线程负责采集放入环形缓冲区几个检测线程从缓冲区取数据显示线程统一渲染。这样各路视频互不干扰资源利用率也高。算法层和界面层应当彻底分离。定义一套算法接口YOLOv5、YOLOv8等不同模型都实现这个接口。界面只调用接口不关心具体实现。换模型只需要改配置界面代码几乎不用动。二、OpenCV算法落地不能照搬PC代码PC上OpenCV怎么方便怎么来到了嵌入式平台就得精打细算。图像预处理这条链在PC上可能几毫秒在嵌入式上就是几十毫秒。需要检查每一步的开销看看能否用硬件加速替代。NPU对输入格式有特定要求。比如RK3588的NPU需要RGB planar格式而OpenCV默认是interleaved。转换格式本身就会消耗时间最好能用硬件支持的API直接完成。同样图像解码、缩放等操作如果能用硬件解码器和RGARaster Graphics Acceleration加速能省下不少CPU资源。模型部署是另一道坎。PyTorch训练好的模型需要转换成目标平台支持的格式RKNNRK3588或TensorRTJetson。转换过程中精度会有损失需要反复校准。常见问题包括输入归一化参数不一致、输出解析错误等。转换后的模型最好在板子上用真实数据验证一遍确保检测框位置和置信度符合预期。三、嵌入式平台适配每块板子有自己的脾气RK3588和Jetson Orin是当前主流的嵌入式AI平台但开发体验差异不小。交叉编译环境搭建就是个开端库依赖容易出问题。用Docker创建编译环境是个好习惯一次配置到处使用。性能调优需要深入硬件细节。同样一个YOLOv8模型在Jetson上用TensorRT跑在RK3588上用RKNN跑代码路径不一样优化技巧也不一样。需要查阅硬件手册了解NPU、CPU、GPU如何协同工作。有时候检测瓶颈不在模型推理而在图像解码——用硬件解码器能快好几倍。内存管理要特别小心。嵌入式设备内存有限每帧都动态分配图像对象很快会导致内存碎片甚至泄漏。对象池是个有效方案预先分配固定数量的图像对象循环使用避免频繁new/delete。四、多路视频处理读写者模式安防监控、工业检测等场景经常需要同时处理多路视频。如果每路开一个线程CPU很快就会被压垮。读写者模式更适合一个采集线程轮询各路摄像头把原始帧放入环形缓冲区几个检测线程从缓冲区取帧处理完后放入结果队列显示线程统一渲染。缓冲区大小要合理设置太小容易丢帧太大会增加延迟。还要注意帧率匹配如果检测速度跟不上采集速度需要做丢帧策略。五、从原型到产品每一步都不能省嵌入式AI产品开发不是“写个算法然后拷过去”那么简单。界面要响应快算法要跑得稳硬件资源要榨干还要考虑设备长时间运行的散热和稳定性。现场运行半年后死机查下来往往是内存泄漏——某个cv::Mat没有释放。压力测试、长时间测试必不可少。模型精度在实验室没问题到了现场光照变了检测率下降需要采集真实场景数据重新训练或微调。工程师高培觉得嵌入式AI开发需要的不是单点技术而是全局视角QT界面、OpenCV算法、模型部署、多线程优化、硬件加速、系统稳定性缺一不可。