边缘AI摄像头这件事真正让人头疼的从来不是模型能不能训出来而是训出来的模型能不能在板子上跑得动、跑得准、跑得稳。我这几轮拿RK3566做主控做图像分类落地选的网络是MobileNetV3整条链路从训练产物到板端出结果全靠RKNN工具链串起来。这篇就把我踩过的流程完整摊开模型怎么导出、量化数据集怎么准备、RKNN-Toolkit2 的参数为什么要那么填、板端运行时怎么接摄像头、精度掉了从哪儿查、长时间跑怎么不崩。适合手上已经有 RK3566 开发板、想把一个分类模型真正跑成产品的朋友也适合刚接触 NPU 部署、被各种 toolchain 版本和量化参数绕晕的同学。文中所有参数和数值都来自实际调试记录你可以直接照着改。1. 方案整体设计与硬件选型思路1.1 为什么是 RK3566 加 MobileNetV3 这个组合先把这个组合的合理性说清楚不然下面所有参数调整都是无根之木。RK3566 的定位是低功耗边缘主控四核 Cortex-A55主频最高 1.8GHz集成的自研 NPU 标称算力 0.8 TOPS支持 INT8 和 INT16 推理同时带 Mali-G52 2EE 图形单元和完整的视频编解码通路1080p 编码、4K 解码都不在话下。这个规格放在摄像头 本地推理 结果上传的场景里非常合适摄像头采集、图像缩放、格式转换、模型推理、结果封装一颗芯片全包不需要额外的加速卡整板功耗和成本都压得住。但 0.8 TOPS 是个什么概念它大约相当于每秒能完成 0.8 万亿次整数运算。拿 MobileNetV3-Small1.0 width224×224 输入来说单次前向大约 60M 乘加运算也就是 0.06 GFLOPs 量级。理论上算力绰绰有余实际跑起来能不能到 30fps瓶颈往往不在 NPU 本身而在预处理、内存拷贝和调度上。这就是为什么很多人第一次跑 demo 觉得怎么才 8fps换个写法就能上 30fps。选 MobileNetV3 而不是 ResNet、ViT 这类大模型理由很直接MobileNetV3 是为移动端设计的深度可分离卷积占了大头参数量小Small 版本约 2.5M量化友好INT8 掉点通常在 1 个百分点以内它的 h-swish 激活函数虽然对量化有一点敏感性但瑞芯微的工具链对这个结构处理得比较成熟不需要你做太多算子级别的适配。相比之下带复杂注意力的模型转 RKNN 经常遇到算子不支持、需要回退到 CPU 执行的问题一退回 CPU 性能直接腰斩。如果你的任务不是 ImageNet 那种千类分类而是工业质检的良品/不良品判断、或者特定场景的几类目标识别那 MobileNetV3 做骨干网再改最后的全连接层就够了前面的特征提取层几乎不用动。这种换个头就能用的灵活性是小模型落地时非常实际的优势。1.2 整条部署链路拆成四段来看我把整条链路拆成四段每段有明确的输入输出和验收标准这样出问题的时候能快速定位是哪一段的锅而不是从前到后瞎猜。第一段是训练侧约束确认。模型在 PyTorch 里训完之后要先确认几件事输入是不是固定尺寸、有没有动态 shape、归一化是放在模型内部还是外部、输出是 logits 还是 softmax 后的概率。这几件事直接决定了后面转换脚本怎么填参数。第二段是中间格式导出。PyTorch 导出 ONNX再做一次图优化常量折叠、算子融合把不必要的节点去掉。ONNX 是 RKNN 最稳的输入格式虽然工具链也支持 TensorFlow、Caffe、TFLite但 ONNX 的算子覆盖面最全调试信息也最清楚。第三段是RKNN 转换与量化。这是全文的重头戏涉及目标平台指定、均值方差配置、量化数据集准备、精度分析、混合量化回退。这一段做不好模型要么跑不起来要么跑起来精度稀烂。第四段是板端运行时集成。模型文件拷到板子上用 RKNN Runtime 加载接上摄像头采集链路做预处理、推理、后处理最后形成一个稳定的循环。这一段考验的是工程能力内存怎么复用、线程怎么编排、温度怎么监控。每一段的验收标准我也列一下方便你自查第一段看 ONNX 能不能被 onnxruntime 正确推理且结果和 PyTorch 对齐第二段看 onnx-simplifier 之后有没有残留奇怪算子第三段看仿真推理的余弦相似度是否大于 0.99第四段看板端连续跑 2 小时不崩、帧率稳定。四段全绿这个模型才算真正落地。1.3 算力和内存预算的粗算方法动手之前先算一笔账能省掉很多返工。算力这块MobileNetV3-Small 单帧约 60M MAddsINT8 下 NPU 实际有效算力打个折按标称的 30% 到 50% 估算也就是 0.24 到 0.4 TOPS。60M 乘加换算成操作数大约 120M ops除以 0.24 TOPS 得到 0.5ms这是理论下限。实际我测下来单帧 NPU 推理在 18 到 25ms 之间说明大量时间花在了数据搬运和调度开销上这也是为什么后面对预处理和内存布局的优化收益那么明显。内存这块更关键。RK3566 开发板常见配置是 2GB LPDDR4看起来宽裕但 Linux 系统本身、OpenCV、摄像头缓冲、应用进程加起来会吃掉一大半。RKNN 模型加载后占用分两部分权重INT8 量化后约 2.5MB和运行时工作区跟模型结构有关MobileNetV3-Small 大约 20 到 40MB。如果模型输入分辨率翻倍到 448×448工作区会涨到 3 到 4 倍这时候就要留意会不会触发内存不足。我的做法是在代码里预留至少 200MB 的余量然后用free -m和/proc/meminfo在推理循环里周期性打印观察有没有缓慢上涨的趋势。有上涨就是有泄漏通常是 OpenCV 的 Mat 没释放或者 numpy 数组在循环里反复分配导致的这个后面会细说。2. 模型转换前的准备工作2.1 训练侧必须提前确认的四个硬性约束模型转换失败十次里有六次是训练侧埋的雷。我把必须提前确认的点整理成四条你可以在训练脚本收尾时就核对一遍比转换报错后再回头改省事得多。第一条输入尺寸固定。RKNN 虽然支持动态 shape但边缘场景几乎没人用动态输入因为动态 shape 会让 NPU 无法预分配内存性能损失很大。所以导出 ONNX 的时候一定要用torch.onnx.export的dynamic_axes参数把动态维度关掉或者干脆不传这个参数。输入张量形状写成[1, 3, 224, 224]这种完全确定的。第二条归一化位置明确。这是最容易出岔子的地方。如果你的模型内部第一层就是Normalize或者减均值除方差的操作那 RKNN 的mean_values和std_values就必须留空或者设成 0 和 1否则会做两次归一化精度直接崩。反过来如果模型吃的是原始 0 到 255 的像素那归一化就得靠 RKNN 配置或者板端代码来做。我建议统一把归一化放在 RKNN 配置里因为这样板端代码最简单直接送 uint8 数据进去NPU 前处理会自动完成减均值和乘系数还能省掉一次 CPU 侧的浮点运算。第三条通道顺序对齐。PyTorch 训练时图像是 RGBOpenCV 读进来是 BGR这个转换如果在板端做很容易忘记或者做错位置。我的习惯是在训练和量化数据集准备阶段全部统一成 RGB板端用 V4L2 采集后通过 RGA 直接输出 RGB 格式整条链路不出现 BGR从源头杜绝这个问题。第四条输出层结构清楚。分类模型最后如果是Linear输出 logits板端就要自己做 softmax 或者直接取 argmax如果模型里已经带了 softmax输出就是概率。两种都行但要清楚是哪种因为后处理代码不一样。我倾向让模型输出 logitssoftmax 放在板端用整数近似算省一点 NPU 的活。这四条确认完再往下走就顺了。很多人跳过这一步直接转结果在精度分析环节看到余弦相似度只有 0.6回头排查半天最后发现就是归一化做了两遍。2.2 工具链环境搭建与版本匹配的坑RKNN 这套工具链最大的坑不是用法复杂而是版本必须严格匹配。PC 端的 RKNN-Toolkit2 版本、板端的 RKNN Runtime 库版本、NPU 驱动版本三者不匹配就会在各种奇怪的地方报错比如模型加载时报invalid RKNN model version或者推理时直接段错误。我的建议是 PC 端用 Python 虚拟环境装 RKNN-Toolkit2版本从 1.5.x 起步2.0 之后接口有一些调整。装之前先确认 Python 版本工具链对 3.8 到 3.10 支持最好3.11 以上经常出现依赖包编译失败。安装命令大致是这样python3 -m venv rknn_env source rknn_env/bin/activate pip install rknn_toolkit2 -i https://pypi.tuna.tsinghua.edu.cn/simple装完之后跑一句python -c from rknn.api import RKNN; print(RKNN())能打印出对象就说明装好了。如果报libcrypto或者libgomp找不到装对应的系统库就行这类问题搜报错原文基本都能找到答案。板端这边的 Runtime 库通常随官方 SDK 一起提供放在/usr/lib下面文件名类似librknnrt.so。第一件事是确认版本号板端执行strings /usr/lib/librknnrt.so | grep -i versionPC 端执行python -c from rknn.api import RKNN; print(RKNN().version)两个版本号的主次版本要能对上。对不上就把 PC 端工具链降到和板端一致或者把板端库升级不要抱侥幸心理混用我见过太多因为版本错配浪费时间的情况。调试阶段还有一个实用技巧RKNN-Toolkit2 支持连板调试也就是 PC 上转换完直接推到板子上跑不用手动拷贝。用法是在初始化 RKNN 对象后调用rknn.init_runtime(targetrk3566, device_idxxx)其中 device_id 是板子通过 USB 连上 PC 后 adb 识别到的序号。这个功能在调精度的时候特别方便改一版参数立刻能在真实硬件上验证。2.3 ONNX 导出与算子兼容性检查导出 ONNX 这一步我习惯写一个独立的脚本固定随机种子同时保存一份输入样例和对应的 PyTorch 输出方便后面逐层对比。核心代码就几行import torch import torch.onnx model.eval() dummy torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy, mobilenetv3_small.onnx, input_names[input], output_names[logits], opset_version12, do_constant_foldingTrue, )opset_version我固定在 12这个版本算子集稳定RKNN 支持度好太新的 opset 会引入一些工具链还没跟上的算子。do_constant_foldingTrue会把能提前算的常量节点折叠掉减小图规模。导出之后别急着转 RKNN先用onnxsim做一遍简化pip install onnx-simplifier python -m onnxsim mobilenetv3_small.onnx mobilenetv3_small_sim.onnx简化能干掉 Identity、Dropout 残留、多余 Reshape 这类节点图会干净很多。然后做一次算子清单检查用onnx的 Python API 把图里所有算子类型打印出来对照 RKNN 官方支持的算子列表逐条看。MobileNetV3 用到的算子基本就是 Conv、DepthwiseConv、Relu、HardSigmoid、Mul、Add、GlobalAveragePool、Reshape、Gemm这些工具链都支持一般不会出问题。真正需要注意的是那些看起来简单但会被拆解的算子比如HardSwish有些版本的 ONNX 导出后会保留成单个节点有些会拆成HardSigmoid Mul后者对量化更友好。检查完算子再跑一次 onnxruntime 推理和 PyTorch 输出对比 top-1 结果是否一致。一致说明导出链路没问题可以进入转换环节。这一步花不了五分钟但能挡掉后面一大堆莫名其妙的精度问题。3. MobileNetV3 转 RKNN 的完整实操3.1 量化数据集的准备与预处理对齐量化数据集的质量直接决定 INT8 模型的精度这是整个流程里最容易被敷衍、后果又最严重的一环。原理很简单RKNN 拿这些图片在模型里跑一遍统计每一层激活值的分布范围据此确定量化缩放系数。如果这些图片的分布和真实推理场景差太远量化参数就会偏精度自然掉。数量上我的经验是200 到 500 张足够关键不在多而在代表性。如果你做的是工业场景的缺陷分类那就不能全拿正常样本各种缺陷类型、各种光照条件、各种角度都要有。我通常按训练集的类别比例分层抽样每个类别至少 30 张覆盖不同时间段采集的图片。更关键的是预处理必须和板端完全一致。具体来说包括三件事图片要预先 resize 到模型输入尺寸224×224通道要是 RGB像素值保持 0 到 255 的 uint8。为什么强调这三件事因为 RKNN 在 build 阶段会把数据集图片直接喂进模型如果你给的图片尺寸不对某些版本会自动 resize用的插值方法和板端不一样统计出来的分布就有偏差如果给的是 BGR那颜色通道反了量化参数全错。写一个脚本批量处理输出一个dataset.txt每行一个图片的绝对路径import os, cv2 src_dir ./calib_images dst_dir ./calib_224 os.makedirs(dst_dir, exist_okTrue) lines [] for name in sorted(os.listdir(src_dir)): img cv2.imread(os.path.join(src_dir, name)) # BGR img cv2.cvtColor(img, cv2.COLOR_BGR2RGB) # 转 RGB img cv2.resize(img, (224, 224), interpolationcv2.INTER_LINEAR) out os.path.join(dst_dir, name) cv2.imwrite(out, cv2.cvtColor(img, cv2.COLOR_RGB2BGR)) # 存盘时转回 BGR lines.append(os.path.abspath(out)) with open(dataset.txt, w) as f: f.write(\n.join(lines))注意这里存盘时又转回 BGR是因为 OpenCV 的imwrite按 BGR 存。读取的时候 RKNN 内部用 OpenCV 读图读进来还是 BGR所以这里要保证磁盘上的文件被读成 BGR 后再由 RKNN 转成 RGB。这一段逻辑容易绕晕我的做法是干脆在 dataset.txt 里写图片路径然后在转换脚本里自己验证一张图的通道顺序打印几个像素值和训练时的预处理结果比对确认无误再批量跑。3.2 转换脚本逐段拆解与参数填法转换脚本本身不长但每个参数都有讲究。我把它拆成配置、加载、构建、导出四步逐步说明。from rknn.api import RKNN rknn RKNN(verboseTrue) rknn.config( mean_values[[123.675, 116.28, 103.53]], std_values[[58.395, 58.395, 58.395]], target_platformrk3566, quantized_dtypew8a8, quantized_algorithmnormal, optimization_level3, compress_weightTrue, ) ret rknn.load_onnx(model./mobilenetv3_small_sim.onnx) assert ret 0, load_onnx failed ret rknn.build(do_quantizationTrue, dataset./dataset.txt) assert ret 0, build failed ret rknn.export_rknn(./mobilenetv3_small_rk3566.rknn) assert ret 0, export failedmean_values和std_values这两个参数是 ImageNet 的标准值分别对应 RGB 三通道的均值和标准差。工具链内部的算法是(pixel - mean) / std得到归一化后的浮点输入。如果你训练时用的是别的均值和方差一定要换成你自己的这个值填错是最常见的精度杀手。另外要注意这两个参数接受的格式是三维列表RGB 顺序别写成 BGR 了。target_platformrk3566必须显式指定。这个参数不填的话默认可能按高端型号优化生成的模型在 RK3566 上跑不起来或者性能很差因为不同型号的 NPU 指令集和内存布局不一样。quantized_dtypew8a8表示权重和激活都用 8 位整数量化这是最通用也是性能最好的选择。如果想试精度更高的方案可以改成w8a16权重 8 位、激活 16 位精度会好一些但推理耗时会涨 30% 到 50%内存占用也翻倍。我的建议是先用 w8a8 跑精度不达标再考虑混合量化不到万不得已不用全局 16 位。quantized_algorithmnormal是默认的量化算法还有mmse、kl_divergence等选项。normal就是按最小最大值线性映射速度快大多数情况够用mmse会做一些误差最小化的搜索精度可能好一点点但 build 时间会明显变长。我一般先用 normal精度不够再换。optimization_level3是最高级别图优化会做算子融合、内存复用、常量折叠等操作。级别越高编译时间越长但运行时性能越好。级别调到 3 之后Conv Relu 会被融合成一个 NPU 指令省掉一次中间结果写回内存这个收益在 MobileNetV3 这种层数多的网络上很可观。compress_weightTrue会对权重做压缩模型文件能小一些加载时再解压。如果板端存储紧张可以开着对推理速度基本没影响。3.3 精度对齐从仿真到真机的验证方法模型转出来之后第一件事不是拷到板子上跑而是在 PC 端做仿真推理精度分析。RKNN 提供了accuracy_analysis接口能把浮点模型和量化模型在每一层的输出都 dump 下来逐层对比余弦相似度。rknn.accuracy_analysis( inputs[./calib_224/sample.jpg], output_dir./snapshot, targetrk3566, )跑完之后snapshot目录下会有一堆文件最关键的是error_analysis.txt里面按层列出了量化前后的误差。正常情况大部分层的余弦相似度都在 0.99 以上只有极个别层会掉到 0.95 左右。如果发现某一层掉到 0.8 以下那这一层就是精度瓶颈需要重点处理。MobileNetV3 里最容易掉精度的是带 h-swish 的那几层因为 h-swish 在 0 附近是硬饱和量化误差会被放大。遇到这种情况有两个应对手段一是用混合量化把这几层单独提出来用 16 位精度二是调整量化算法试试mmse。混合量化的流程在不同版本里函数名略有差异大体思路是先用一步分析生成配置文件手工编辑里面每层的量化类型再执行第二步 build。配置文件里每一层都有一行类似mobilenetv3/blocks/xxx/Relu: int8的内容把需要提高精度的层改成int16或者float就行。改完重新 build精度通常能回来大半但耗时会增加所以要权衡如果只改两三层的激活性能损失可能在 5% 以内完全可以接受。真机验证这一步不能省。仿真用的是 CPU 模拟 NPU 行为虽然结果接近但不完全等价。把 rknn 文件拷到板子上跑一批标注好的测试图统计 top-1 准确率和 PC 端浮点模型对比。我的经验是 INT8 模型相比浮点模型掉点控制在 1 个百分点以内就算合格超过 2 个点就要回头查量化数据集和预处理了。4. 板端推理与摄像头链路集成4.1 RKNN Runtime 初始化与内存布局要点板端的 Python 接口是rknnliteC 接口是librknnrt.so提供的rknn_init、rknn_inputs_set、rknn_run、rknn_outputs_get这一套。Python 版开发快适合快速验证产品化一般用 C 版能控制内存和线程。Python 版初始化就几步from rknnlite.api import RKNNLite import numpy as np rknn_lite RKNNLite() ret rknn_lite.load_rknn(./mobilenetv3_small_rk3566.rknn) ret rknn_lite.init_runtime(core_maskRKNNLite.NPU_CORE_0) img np.zeros((224, 224, 3), dtypenp.uint8) outputs rknn_lite.inference(inputs[img], data_formatnhwc)这里有几个细节必须讲清楚。第一个是输入布局。ONNX 模型是 NCHW 布局但 RKNN 在转换时会把输入改成 NHWC这是 NPU 硬件更友好的布局。所以板端送进去的 numpy 数组形状是(224, 224, 3)不是(3, 224, 224)。如果送错了形状推理不会报错但结果是乱的这个坑非常隐蔽。判断方法很简单inference的时候把data_formatnhwc写上去形状对不上会直接抛异常。第二个是输入数据类型。因为归一化配置在 RKNN 里了板端送进去的应该是 uint8 原始像素不需要自己转 float。工具链会在 NPU 内部完成 int8 转换和归一化。如果你自己已经做了归一化成 float32那mean_values就必须设成 0、std_values设成 1否则就是双重归一化。第三个是 core_mask。RK3566 这颗 NPU 是单核的NPU_CORE_0和NPU_CORE_AUTO效果一样不用指望多核并行。这点和高端型号不一样别照搬别人的代码写NPU_CORE_0_1_2会直接报错。inference返回的是一个列表分类模型通常只有一个输出所以取outputs[0]。输出已经转成 float32 的 numpy 数组形状是(1, num_classes)直接np.argmax就是预测类别。如果你在模型导出时带了 softmax那输出就是概率否则是 logits需要自己算 softmax 才能得到置信度。我的习惯是模型不带 softmax板端算一个近似的置信度用于阈值过滤。4.2 摄像头采集、RGA 缩放与预处理的流水线设计真正跑起来之后你会发现瓶颈往往不在 NPU。我用 V4L2 从摄像头拿到的原始帧是 NV12 格式1920×1080要送到模型里得经过 NV12 转 RGB、缩放到 224×224、可能还要裁剪居中这几步如果用 OpenCV 的cv::cvtColor加cv::resize来做在 A55 上要花 7 到 8ms比 NPU 推理的一半还多。解决办法是用 RK3566 内置的RGARaster Graphic Acceleration模块。RGA 是独立的 2D 图形加速单元支持格式转换、缩放、裁剪、旋转而且完全独立于 CPU 和 NPU可以和推理并行。用 RGA 把 NV12 直接转成 RGB 并缩放到 224×224实测耗时降到 1.8 到 2ms而且 CPU 占用几乎为零。C 语言里调用 RGA 用的是librga的 im2d 接口核心是构造源图像和目标图像的描述结构然后调用imresize或者imcvtcolor。大致流程是先importbuffer_fd把 DMA buffer 的文件描述符导入设置src的宽高、格式、虚拟地址设置dst的目标宽高格式然后提交任务、等待完成。如果你是 Python 开发可以直接用 OpenCV 的cv2.resize虽然慢一点但开发效率高产品化阶段再换 C 加 RGA。流水线的结构我是这样设计的一个采集线程负责从 V4L2 拿帧拿到的帧直接入队队列深度设 2 到 3太深会增加延迟太浅会丢帧一个推理线程从队列取帧做 RGA 转换、送 NPU 推理、做后处理然后把结果入结果队列一个输出线程负责把结果画到画面上或者通过串口、网络发出去。三个线程之间用条件变量同步队列满了就丢最老的一帧保证实时性。这个结构的好处是采集和推理解耦推理偶尔慢一点不会阻塞摄像头画面不会卡顿。要注意的是队列里的帧必须是深拷贝或者引用计数管理不能拿 V4L2 缓冲区的指针直接入队因为那个缓冲区马上要被下一次采集覆盖。我一开始就犯了这个错结果画面偶尔会撕裂排查了很久才定位到。4.3 多线程调度与帧率稳定性的实测数据把流水线跑通之后我做了一轮优化前后的对比实测环境是 RK3566 四核 A55 主频锁定 1.8GHz散热片加小风扇室温 25 度输入 1080p NV12模型 MobileNetV3-Small 224×224 INT8。处理环节优化前耗时优化后耗时优化手段V4L2 取帧3.2ms3.0ms增大 mmap 缓冲队列NV12 转 RGB 加缩放7.8ms1.9ms改用 RGA 硬件加速数据搬运与格式整理2.4ms0.8ms复用输出 buffer减少拷贝NPU 推理24.5ms18.6ms开 optimization_level3降频问题解决后处理取 top-k0.4ms0.3ms预分配数组单帧合计38.3ms24.6ms整体提升约 36%24.6ms 对应大约 40fps 的处理能力考虑到摄像头本身是 30fps实际上每帧都有富余队列基本不会堆积。这里的关键是 NPU 推理和 RGA 转换、采集在不同硬件单元上可以流水起来理论吞吐比串行耗时之和要快实测稳定在 30fps 无掉帧。温度这块要单独说。RK3566 四核 A55 加 NPU 满载运行如果没有散热措施芯片温度会在 10 分钟内爬到 85 度以上触发降频NPU 主频从 800MHz 降到 600MHz 甚至更低推理耗时从 18ms 涨到 30ms 以上帧率直接掉下来。我的做法是加一块铝散热片再加一个 5V 小风扇温度稳定在 55 到 62 度之间长时间跑不掉频。如果你做的是封闭外壳的产品一定要提前做热仿真或者至少留出风道别等量产了才发现降频。监控温度很简单读/sys/class/thermal/thermal_zone0/temp就行单位是毫摄氏度除以 1000 就是摄氏度。我在主循环里每 100 帧打一次日志超过 75 度就告警方便早期发现散热设计问题。5. 常见问题排查与避坑清单5.1 精度掉点的系统排查路径精度掉点是部署阶段最折磨人的问题因为它不报错只是结果不准。我总结了一套从外到内的排查顺序按这个顺序走基本能定位到根因。第一步先确认浮点模型本身在板端数据上是对的。拿同一批测试图用 ONNX 在 PC 上跑一遍看准确率是否符合预期。如果浮点模型就不准那是训练的问题跟量化无关别浪费时间在工具链上。第二步对齐预处理。这是最高频的原因。具体检查四点板端送进模型的通道是 RGB 还是 BGR、resize 的插值方法是双线性还是最近邻、有没有做中心裁剪、归一化的均值和方差是不是和训练一致。我遇到过一个案例训练时用的是Resize(256) CenterCrop(224)板端直接resize(224)看似差不多实际准确率掉了 4 个百分点因为构图比例变了。第三步看量化数据集。把 dataset.txt 里的图片随机抽 10 张出来和实际场景的图片并排看如果明显不是一个分布比如量化图是白天的实际场景是夜间的那就要重新采样。第四步做逐层误差分析。用accuracy_analysis看哪一层开始崩针对性地做混合量化。这一步的判断依据是余弦相似度0.99 以上忽略0.95 到 0.99 观察0.95 以下必须处理。第五步对比真机和仿真。如果仿真精度正常但真机掉点那大概率是输入数据在传递过程中出了问题比如 layout 搞错、数据类型不对、或者多线程下 buffer 被覆盖。这套顺序的价值在于从成本低、概率高的地方开始查而不是一上来就怀疑量化算法。实际上我处理的案例里八成以上都是预处理不对齐导致的。5.2 转换与运行阶段的报错速查表把常见的报错和对应处理整理成表遇到问题先查表能省不少搜索时间。报错现象可能原因处理办法invalid RKNN model versionPC 工具链与板端 Runtime 版本不匹配统一版本板端strings librknnrt.so查版本E init_runtime: core_mask invalid用了 RK3566 不支持的 core mask改成NPU_CORE_0或AUTOload_onnx failedONNX 里有不支持的算子或动态 shape用 onnxsim 简化检查 dynamic_axesbuild 阶段报unsupported op工具链不支持该算子替换等效算子或让该段回退 CPU 执行推理结果全是同一类输入 layout 错误或数据未归一化检查输入形状是否为 NHWC检查 mean/std 配置精度掉超过 5 个点量化数据集分布偏差或预处理不一致重做数据集逐层误差分析推理时进程被 kill内存不足或泄漏查/proc/meminfo检查循环内数组分配帧率周期性抖动温度触发降频读 thermal_zone加强散热画面偶发撕裂缓冲区被覆盖帧入队前做深拷贝或用引用计数rknn_outputs_get返回错误输出 buffer 未按模型输出数量分配先rknn_query查输出属性再分配这张表里头三条是我踩过最多次的尤其第一条版本不匹配表现千奇百怪有时候是加载失败有时候是加载成功但推理结果乱。养成习惯每次换板子或者换工具链第一件事就是核对版本号。5.3 长时间运行的稳定性与几个实操心得最后说几个只有长时间跑才能暴露的问题以及我摸索出来的处理方式。内存泄漏。Python 环境下最容易出问题的是 numpy 数组在循环里反复创建虽然 Python 有 GC但大数组的分配释放会给内存管理带来压力。我的做法是在初始化阶段就把所有需要的 buffer 预分配好循环里只做原地写入不新建对象。OpenCV 的 Mat 也是同理用dst参数复用输出别每次都让函数返回新 Mat。检测方法很简单跑 1 小时每 5 分钟记录一次 RSS如果曲线是斜向上的那一定有泄漏。NPU 上下文的复用。init_runtime只调用一次不要每帧都调。有人为了保险在循环里反复 load 和 init结果性能只有正常的三分之一还容易造成资源没释放。队列的背压处理。推理跟不上采集的时候队列会满。这时候正确的做法是丢最老的帧而不是阻塞采集线程也不是无限扩容队列。阻塞采集会导致摄像头驱动丢帧甚至超时无限扩容会导致延迟越来越大画面越来越滞后。丢帧策略下画面是实时的只是偶尔跳一帧体验反而更好。开机自启动的看门狗。产品形态下要考虑进程异常退出的情况我通常写一个简单的守护脚本检测主进程是否存活挂了就重启同时记录日志。日志里至少要有启动时间、模型版本、每小时的帧率统计和温度峰值出问题的时候这些信息能救命。模型文件的完整性校验。rknn 文件拷到板子上之后加一步 md5 校验防止拷贝中断导致文件损坏。这个错误很低级但很常见尤其在批量烧录的时候。我个人在实际操作中的体会是边缘部署这件事能跑起来和能稳定跑之间隔着一整个工程量级。前面转换调通的阶段大概占三成精力后面稳定性、性能、异常处理占七成。所以别在模型转换成功那天就以为完事了把长时间运行测试、温度测试、异常恢复测试都排进计划里产品才敢往外发。另外一个小建议把整条链路的每个环节都打上时间戳日志出问题的时候能一眼看出是哪一段慢、哪一段错比凭感觉猜高效太多。
