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

从算法原型到嵌入式产品，中间隔着一道不浅的沟。不少团队在PC上跑通了模型，信心满满地往ARM板上一放，才发现帧率掉到零点几，界面卡死，内存泄漏……这些问题不是靠调几个参数能解决的，需要系统性地理解整个开发链条。

一、QT界面开发：算法与界面必须解耦

嵌入式AI应用通常需要图形界面，QT是常见选择。但开发中容易陷入一个误区：把算法函数直接写在界面类的响应函数里。点一下“开始检测”，界面就卡住，直到检测完成才能动。

QT的信号与槽机制天然适合处理这类问题。把耗时任务放在QThread里执行，通过信号把结果传回主界面，界面就能保持响应。更进一步，可以用读写者模式管理多路视频：一个线程负责采集，放入环形缓冲区；几个检测线程从缓冲区取数据；显示线程统一渲染。这样各路视频互不干扰，资源利用率也高。

算法层和界面层应当彻底分离。定义一套算法接口，YOLOv5、YOLOv8等不同模型都实现这个接口。界面只调用接口，不关心具体实现。换模型只需要改配置，界面代码几乎不用动。

二、OpenCV算法落地：不能照搬PC代码

PC上OpenCV怎么方便怎么来，到了嵌入式平台就得精打细算。图像预处理这条链，在PC上可能几毫秒，在嵌入式上就是几十毫秒。需要检查每一步的开销，看看能否用硬件加速替代。

NPU对输入格式有特定要求。比如RK3588的NPU需要RGB planar格式，而OpenCV默认是interleaved。转换格式本身就会消耗时间，最好能用硬件支持的API直接完成。同样，图像解码、缩放等操作，如果能用硬件解码器和RGA（Raster Graphics Acceleration）加速，能省下不少CPU资源。

模型部署是另一道坎。PyTorch训练好的模型，需要转换成目标平台支持的格式：RKNN（RK3588）或TensorRT（Jetson）。转换过程中精度会有损失，需要反复校准。常见问题包括输入归一化参数不一致、输出解析错误等。转换后的模型最好在板子上用真实数据验证一遍，确保检测框位置和置信度符合预期。

三、嵌入式平台适配：每块板子有自己的脾气

RK3588和Jetson Orin是当前主流的嵌入式AI平台，但开发体验差异不小。交叉编译环境搭建就是个开端，库依赖容易出问题。用Docker创建编译环境是个好习惯，一次配置，到处使用。

性能调优需要深入硬件细节。同样一个YOLOv8模型，在Jetson上用TensorRT跑，在RK3588上用RKNN跑，代码路径不一样，优化技巧也不一样。需要查阅硬件手册，了解NPU、CPU、GPU如何协同工作。有时候检测瓶颈不在模型推理，而在图像解码——用硬件解码器能快好几倍。

内存管理要特别小心。嵌入式设备内存有限，每帧都动态分配图像对象，很快会导致内存碎片甚至泄漏。对象池是个有效方案：预先分配固定数量的图像对象，循环使用，避免频繁new/delete。

四、多路视频处理：读写者模式

安防监控、工业检测等场景经常需要同时处理多路视频。如果每路开一个线程，CPU很快就会被压垮。读写者模式更适合：一个采集线程轮询各路摄像头，把原始帧放入环形缓冲区；几个检测线程从缓冲区取帧，处理完后放入结果队列；显示线程统一渲染。

缓冲区大小要合理设置，太小容易丢帧，太大会增加延迟。还要注意帧率匹配，如果检测速度跟不上采集速度，需要做丢帧策略。

五、从原型到产品，每一步都不能省

嵌入式AI产品开发，不是“写个算法然后拷过去”那么简单。界面要响应快，算法要跑得稳，硬件资源要榨干，还要考虑设备长时间运行的散热和稳定性。

现场运行半年后死机，查下来往往是内存泄漏——某个cv::Mat没有释放。压力测试、长时间测试必不可少。模型精度在实验室没问题，到了现场光照变了，检测率下降，需要采集真实场景数据重新训练或微调。

工程师高培觉得嵌入式AI开发需要的不是单点技术，而是全局视角：QT界面、OpenCV算法、模型部署、多线程优化、硬件加速、系统稳定性，缺一不可。