MPU 和 AI 图像处理这两个词放在一起很容易让人想到工业相机、缺陷检测、边缘盒子。我最近一个项目就是把原先跑在 MCU 上的简单图像算法整体迁移到一块带 NPU 的 MPU 上目标很直接在本地完成基于 AI 的实时图像处理不依赖服务器。这篇文章想把整个过程中的设计决策、部署流程、优化手段和踩坑记录整理出来给同样在评估 MPU 方案的人一个参考。1. 为什么 AI 图像处理要从 MCU 换到 MPU1.1 先算一笔账图像数据没你想的那么小很多硬件项目一开始都会用 MCU 做图像处理比如用摄像头做颜色识别、找二维码、测光强这些任务在 MCU 上确实能跑。可一旦换成 AI 图像处理比如目标检测、语义分割、关键点识别情况就完全不同了。最核心的变化不是算力需求而是数据吞吐量。以一块常见的 720p 传感器为例RGB888 格式下每帧数据量是 1280 乘 720 乘 3 个字节约 2.76MB。按 30 帧每秒计算每秒光是原始图像数据就要搬运 82.9MB。换成 1080p数字直接变成 6.22MB 每帧、186.6MB 每秒。这个数据量对于 DSP 内部的小 RAM 可能还能接受但对普通 MCU 来说片内 SRAM 一般只有几百 KB根本放不下几帧。就算外扩 SDRAM总线带宽也往往卡在几十 MB/s 这个量级还没等 AI 算起来图像数据搬运已经占满了整个系统。所以很多项目从 MCU 迁到 MPU第一个驱动因素就是内存带宽。MPU 这边通常搭配 DDR3/DDR4/DDR5 或者 LPDDR带宽动辄几 GB/s 到几十 GB/s一帧 1080p 图像读进来只是小意思。再加上绝大多数 MPU 都带存储控制器、DMA 和丰富的外设接口整个图像流水线才有继续设计的空间。1.2 MCU 的瓶颈和 MPU 的拐点MCU 不是不能处理图像而是它擅长处理的是“图像已经在内存里、处理逻辑简单”的场景。比如我用 STM32 做过一个找红色小球的项目思路是先做颜色阈值分割再找轮廓、算质心算法复杂度很低MCU 完全扛得住。但同样这个项目如果换成要识别“这是一个什么类型的小球”哪怕模型再小MCU 上跑一个几百 KB 的神经网络也是非常吃力的。具体瓶颈有几层。第一层是算力MCU 主频通常在 100MHz 到 600MHz没有向量指令集和 AI 加速器的话一个简单的 MobileNet 都可能跑到几百毫秒甚至几秒一帧。第二层是内存神经网络中间层的数据量往往比模型文件本身大得多几个特征图叠在一起就可能超过全部可用 RAM。第三层是软件生态MCU 上跑 Linux 比较费劲摄像头驱动、ISP 管线、内存管理、文件系统这些组件都要重复造轮子。而 MPU 不一样。MPU 通常指应用处理器级别的微处理器标配 MMU可以稳定运行 Linux内存容量从 256MB 到 8GB 都有。Linux 带来的好处是巨大的摄像头可以用 V4L2 标准接口图像处理可以用 OpenCV/GStreamer模型部署可以用 ONNX Runtime / TFLite / 各家 NPU 工具链显示输出可以用 DRM/Wayland。从 MCU 迁到 MPU本质上是从“所有东西自己一个循环里做”换到“有标准系统帮你管理硬件资源”的开发模式。1.3 为什么不是直接用 GPU 或 DSP 顶上有些老项目会考虑用 DSP 来做图像处理比如 TI 的 C6000 系列性能确实强但开发周期长而且很多 DSP 工具链封闭出了问题不好查。GPU 在 PC 和服务端是主流但在边缘设备上功耗和发热往往扛不住尤其是那些无风扇的工业盒子长时间跑 GPU 推理很容易降频。MPU 在这里的定位就很微妙了。很多新出的 MPU 除了 CPU 核心还集成了 ISP、GPU、NPU、视频编解码单元形成一个完整的 SoC。CPU 负责控制和调度ISP 负责把 RAW 数据变成高质量图像NPU 负责跑神经网络GPU 负责显示和简单渲染视频编解码单元负责录像和推流。整个系统真正做到了“专事专办”这也是 MPU 在 AI 图像处理方向受欢迎的根本原因。2. MPU 上 AI 图像处理的核心硬件逻辑2.1 ISP把 RAW 变成 AI 能吃的数据很多人第一次接触 MPU 图像处理都会忽略 ISP结果模型在电脑上测试准确率很高搬到板子上就翻车。真正常见的翻车点恰恰是 ISP 配置不对。摄像头传感器出来的原始数据通常是 Bayer RAW这个格式人眼看是偏色的AI 模型也没法直接用。ISP 要把 RAW 经过坏点校正、去马赛克、白平衡、自动曝光、降噪、色彩校正等一串处理后才能输出 YUV 或者 RGB 图像。各家 MPU 的 ISP 能力差异很大有的支持 3A自动曝光、自动白平衡、自动对焦有的需要外接协处理器有的 ISP 只支持特定格式的 RAW。在实际项目里我建议第一步就要把 ISP 输出抓出来看确认颜色、亮度、分辨率是否符合预期。尤其是做训练数据集时要么用板子上的 ISP 输出重新采集样本要么在训练前做数据增强模拟 ISP 的处理效果。否则训练集来自普通相机推理时输入是另一套颜色风格的图像精度下降非常明显。2.2 NPU 的算子支持范围决定模型能不能跑NPU 是 MPU 上负责跑神经网络的核心模块但它不是万能的。不同厂商的 NPU 支持不同的算子集合比如卷积、池化、全连接、激活函数这些常见算子基本都支持但某些特殊算子比如动态形状相关的算子、某些注意力机制里的乘加组合可能会在转换时报错。我踩过一个典型的坑PC 上跑 YOLOv5s 没问题转换到芯片 NPU 时却提示一个自定义上采样算子不支持。当时工具链没有给出自动回退选项整个转换失败。后来换了 YOLOv8 的官方导出版本并且把上采样改成工具链支持的固定比例模式才顺利转换。这件事给我的教训是选模型之前先查目标 NPU 的工具链官方文档看看当前版本支持哪一批模型结构不要等代码都写完了再去转模型。2.3 选型关注哪些指标现在市面上的 AI 图像处理 MPU 方案不少像 NXP i.MX 8M Plus、瑞芯微 RK3588、TI AM62A、瑞萨 RZ/V2L 这些都有各自的定位。平台AI 算力参考值典型优势工具链NXP i.MX 8M Plus约 2.3 TOPS工业级接口生态成熟eIQ ToolkitRockchip RK3588约 6 TOPS接口丰富社区资料多RKNN-Toolkit2TI AM62A约 2 TOPS低功耗边缘研究案例多Edge AI StudioRenesas RZ/V2L约 1 TOPS 级别内置 DRP适合轻量模型DRP-AI Translator参数只做一个大致参考具体数值一定要以厂商最新资料为准。选型时我除了看算力更看重三件事第一是工具链是否顺手包括模型转换、量化、调试、性能分析是不是一套完整闭环第二是 ISP 质量和摄像头接口的兼容性很多板子自带摄像头模块但工业项目往往要接第三方摄像头第三是内存布局和外部存储接口AI 模型和图像帧都吃内存尽量选内存带宽充裕的方案。3. 从模型到 MPU一套可以“抄作业”的部署流程3.1 先在 PC 上验证模型ONNX Runtime 跑一次推理拿到一块新板子之后不要直接扑到硬件调试点上先在 PC 上把模型和图像处理流程验证明白。PC 上的 OpenCV ONNX Runtime 组合非常方便几乎所有 MPU 工具链都支持 ONNX 作为中间格式。我习惯先写一个简单的 Python 脚本把摄像头或图片数据喂给模型确认输出符合预期。示例代码如下import cv2 import numpy as np import onnxruntime as ort def letterbox(img, size(640, 640), pad_value114): h, w img.shape[:2] r min(size[0] / h, size[1] / w) new_w, new_h int(w * r), int(h * r) resized cv2.resize(img, (new_w, new_h)) canvas np.full((size[0], size[1], 3), pad_value, dtypenp.uint8) top (size[0] - new_h) // 2 left (size[1] - new_w) // 2 canvas[top:top new_h, left:left new_w] resized return canvas, r, left, top net ort.InferenceSession(model.onnx) cap cv2.VideoCapture(0) while True: ok, frame cap.read() if not ok: break input_blob, ratio, padx, pady letterbox(frame) rgb cv2.cvtColor(input_blob, cv2.COLOR_BGR2RGB) rgb rgb.astype(np.float32) / 255.0 blob np.transpose(rgb, (2, 0, 1))[None, ...] outputs net.run(None, {net.get_inputs()[0].name: blob}) # 后处理部分每个模型差异很大建议先把输出 tensor 打印出来 print(outputs[0].shape)这个脚本的核心是 letterbox 预处理目的是把任意分辨率的图像缩放到模型输入尺寸同时保持宽高比避免直接拉伸导致目标变形。注意 padding 通常用 114这是很多检测模型训练时的默认填充值。PC 上只要这一步的结果能跑通后面换硬件时主要改动就是模型加载方式和输入 buffer。3.2 模型转换与 INT8 量化PC 上验证用的是 FP32 模型到了 MPU 上很多人第一反应是直接转一个 INT8 模型理由很简单NPU 在 INT8 下最快内存占用也最小。但这里有一个容易被忽略的点INT8 量化需要校准集而且校准集必须贴近实际使用场景。量化过程其实是在统计模型每一层激活值的数值范围然后把这个范围映射到 8bit 的整数空间。如果校准集只有几十张网上的图片而实际场景是低照度工业车间画面亮度、噪声甚至色彩分布都和校准集差得远那量化后的模型精度可能直接掉几个点。我推荐的做法是从现场摄像头采集至少几百帧代表性图像做成一个包含曝光变化、角度变化、遮挡情况的校准集再交给各家的量化工具处理。有的工具链还支持混合量化或部分层保留 FP16比如某些检测头的输出层对数值精度比较敏感。遇到量化后精度明显下降的情况不要急着加数据先把敏感层找出来单独设置精度。几乎所有成熟工具链的文档里都有精度分析章节建议好好看一遍。3.3 板端集成视频流里跑推理的最小循环模型转换成功之后就可以开始写板端应用了。这里我强烈建议把采集、推理、输出三个环节设计成独立的线程或者任务而不是在一个死循环里全部完成。一个最小但合理的结构是这样的采集线程从 V4L2 设备读取一帧图像放到一组固定数量的 buffer 里推理线程从 buffer 里取出一帧先做分辨率转换和格式转换然后提交给 NPU 推理推理完成后后处理线程解析检测结果用 OpenCV 画框再送到显示或者网络模块。这样设计的核心原因是摄像头采集是固定帧率的外部事件推理耗时会有波动如果把两者强同步帧率会跟着推理耗时跳来跳去。以 V4L2 为例下面是一段从板端摄像头抓一帧并转成 ready 数据的伪代码思路import cv2 import numpy as np cap cv2.VideoCapture(/dev/video0, cv2.CAP_V4L2) cap.set(cv2.CAP_PROP_FRAME_WIDTH, 1280) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 720) cap.set(cv2.CAP_PROP_FOURCC, cv2.VideoWriter_fourcc(M, J, P, G)) ret, frame cap.read() # 此时 frame 已经是 YUV 或 BGR取决于驱动配置 # 后续再把 frame 缩放到模型输入尺寸实际项目里我更推荐直接调用 NPU 工具链提供的 C/C 接口而不是 Python因为 Python 的帧拷贝和对象创建在长时间运行时会产生开销而且不好控制内存对齐。当然如果项目原型验证阶段用 Python 完全没问题等性能瓶颈明显了再往 C 迁移也来得及。4. 性能调优和真实踩坑记录4.1 先用 profiler 看瓶颈CPU、NPU、内存带宽三兄弟部署到板子上之后第一个问题往往是“为什么跑不到目标帧率”。这时候一定要用工具定位瓶颈而不是盲目优化。我见过太多人发现帧率低就直接把模型换小结果换完帧率几乎没变因为真正的瓶颈在图像缩放。我常用的方法分三步。第一步用系统的 CPU 占用观察整体负载如果 CPU 单核接近 100%多半是图像预处理或者后处理代码有问题。第二步看 NPU 的利用率各家工具链基本都有性能分析工具能显示每次推理的耗时、NPU 占用率、DDR 读写量。第三步如果 CPU 和 NPU 占用都不高但实际帧率还是低那就要检查摄像头驱动、buffer 队列、显示输出是否阻塞了主循环。这里说一个我自己的经历之前一块板子跑目标检测推理耗时只有 12ms四舍五入可以到 80 帧但实际只有 25 帧。查到最后发现显示叠加时用了 OpenCV 的 putText 在 1080p 全图上画框这个操作本身不慢但在每一帧都做中文字体渲染CPU 直接被拖垮。换成只对 ROI 区域做叠加帧率立刻上来了。4.2 图像预处理优化的三个方向AI 图像处理系统的预处理主要集中在格式转换、缩放、归一化这几步。表面上看起来很简单但在边缘设备上处理不好会成为隐藏的瓶颈。第一个方向是尽量用硬件完成格式转换和缩放。很多 MPU 的 ISP 可以直接输出不同分辨率的 YUV/RGB 流NPU 的输入 buffer 也支持直接写入。如果 ISP 支持缩放就不要等 CPU 把全分辨率图像读回来再缩。第二个方向是避免逐像素循环。Python 里用 numpy 向量化操作C/C 里尽量用 NEON 指令或者厂商提供的加速库。第三个方向是复用 buffer不要在每帧里 new 一个同样大小的数组。内存分配在 PC 上不算什么但在嵌入式环境里分配器往往不够高效频繁分配会造成碎片和延迟。4.3 我踩过的几个坑第一个坑是量化精度暴跌。最开始图省事用了模型默认的校准图片结果在真实场景里掉了很多点。后来我用摄像头连续采集了上千帧真实画面做校准精度恢复了不少。这件事给我的教训是校准集永远要来自实际部署现场的图像不能贪图方便。第二个坑是摄像头输出格式和模型输入不一致。PC 上跑模型OpenCV 读回来的图像默认是 BGR很多模型转换工具会约定输入格式是 RGB如果忘记转换模型输出会非常诡异。板子上用 V4L2 有时得到的格式是 NV12 或 YUYV不转就直接丢给 NPU常有颜色错乱的问题。第三个坑是内存对齐。有些 NPU 要求输入 buffer 的地址和宽度按 32 字节或 64 字节对齐。如果按照图像宽度直接申请内存恰好没有对齐驱动会在内部多拷贝一次。虽然不影响正确性但性能会有损耗。第四个坑是显示和推理共用内存带宽。在 1080p 分辨率下同时做摄像头采集、NPU 推理、视频叠加和 HDMI 输出DDR 带宽会被占满。表现就是帧率不稳偶尔卡顿。解决方案是降低显示分辨率或者把显示步骤放到单独的线程并且使用 DMA 通道。第五个坑是系统服务抢占 CPU。开发板上默认开着很多服务比如自动更新、日志清理、桌面环境这些都会影响实时性。生产环境建议用精简系统镜像关闭不用的服务并把推理线程绑核。4.4 常见问题速查表现象可能原因排查建议模型转换失败算子不支持 / 模型版本过新查看工具链支持列表换模型结构量化后精度下降校准集没覆盖实际场景重新收集真实场景校准图图像颜色偏绿或偏紫摄像头格式与输入约定不一致确认 YUV/RGB 顺序检查 ISP 配置帧率达不到预期CPU 预处理过重或内存带宽瓶颈用 profiler 定位 CPU/NPU/带宽占用推理结果抖动线程没有同步buffer 被覆盖使用双缓冲或环形缓冲启动时摄像头打不开V4L2 设备节点占用或驱动没加载检查 dmesg释放设备节点一点个人经验我实际做项目时有个体会在 MPU 上跑 AI 图像处理最影响交付效率的往往不是算力而是工具链的完整度。算力只是一个数字真正花时间的是模型转换、量化、ISP 调试、性能优化这些琐碎环节。所以如果你正在选型建议先把手头最常见的模型和图像处理流程跑在一块目标板子上完整验证一遍再决定方案不要只对着参数表挑。尤其要记住先把摄像头图像流稳定下来再去碰模型这条路比反过来走顺畅得多。
