把分类模型往RV1106这颗0.5T算力的NPU上搬是一件看起来简单、落地时细节非常多的事。RV1106是瑞芯微面向摄像头、门锁这类轻量AIoT场景的芯片内置NPU理论算力0.5TOPSINT8内存带宽和CPU性能也都按低功耗方案设计。我拿它做了一轮主流图像分类模型的部署实验覆盖MobileNet系列、ShuffleNetV2、EfficientNet-Lite和ResNet系列完整走通了ONNX转换、RKNN量化、板端推理和精度验证的流程。这篇博文就是把实验过程里那些文档上不太会写的内容整理出来包括工具链版本坑、算子兼容性、量化精度变化、真实耗时口径以及选型建议。适合正在做轻量级视觉产品选型、或者刚接触RKNN工具链的工程师参考。1. 实验目标与平台认知1.1 0.5TOPS算力到底意味着什么RV1106的NPU标称0.5TOPS这个数字听起来不大放到实际场景里会有更直观的理解。以MobileNetV1为例输入224x224分辨率时完整推理的乘加运算量大约是570M MACs也就是1.14GFLOPs。如果NPU能100%利用0.5TOPS意味着每秒能处理5000亿次INT8运算理论上50ms左右可以跑完MobileNetV1。但实际中还要算上数据搬运、算子调度、NPU利用率损耗远达不到这个理想值。所以第一个核心结论是在RV1106上图像分类模型的运算量最好控制在500M MACs以内才能获得20~30ms级别的单帧耗时。这个级别下能选的模型其实很清晰MobileNetV1/V2/V3、ShuffleNetV2、EfficientNet-Lite这些轻量网络是主力ResNet18属于“能跑但不算快”的边缘选项ResNet50基本只适合做基准测试。我这次实验把ResNet50也纳入进来目的不是推荐它而是想看看不同复杂度模型在这颗芯片上量化后的精度保持规律。另外要注意的是0.5TOPS是针对INT8的算力FP16、FP32在NPU上效率会明显下降。所以在RV1106上做分类任务INT8量化不是可选项而是必选项。这也意味着模型转换时对量化参数的敏感度会直接影响最终精度后面我会专门展开。1.2 模型选型不是越新越好这次实验选择了七个代表性模型MobileNetV1、MobileNetV2、MobileNetV3-Small、ShuffleNetV2、EfficientNet-Lite0、ResNet18、ResNet50。选择标准有三个。第一是结构代表性。MobileNetV1是深度可分离卷积的经典形态MobileNetV2加入了倒残差结构MobileNetV3引入了SE注意力机制和h-swish激活ShuffleNetV2强调通道重排和内存访问优化EfficientNet-Lite是NAS搜索出来的复合缩放网络ResNet则是标准残差结构。这七款模型基本覆盖了轻量分类网络的主流设计范式在NPU上踩到的算子兼容性问题也各不相同。第二是推理延迟预期的层次感。实测前我预估的范围是10ms到100ms量级这个跨度足够画出“模型复杂度-耗时-精度”的三维对比曲线也便于判断不同产品需求的性价比。第三是算子分歧度。MobileNetV1是最容易转换的几乎全程走全标准Conv和DepthwiseConvMobileNetV3的SE模块和h-swish激活在RKNN转换时可能引入额外算子ShuffleNetV2的channel shuffle在NPU上效率不稳定EfficientNet-Lite的Swish激活也要关注。这些差异正是实验最值得看的部分。这里给一个参考建议如果目标模型属于“新出的结构”比如带大核注意力、动态卷积这类算子最好先确认RKNN工具链对应版本支持的算子列表不然转换阶段就会卡住而不是到了板端才发现问题。2. 环境与工具链准备2.1 RKNN-Toolkit2的版本坑RV1106对应的工具链是RKNN-Toolkit2不是老版的RKNN-Toolkit1。两者的API、模型格式完全不通下载时不能搞混。我一开始图省事装了最新版的pip包结果在build阶段报了一堆和rv1106 target平台相关的错误后来才发现版本迭代中部分平台支持有变化不同芯片型号要对应特定版本范围。这类坑的排查方法是在转换代码里先打印版本号然后对照SDK里release note中的支持列表。比较新的SDK包通常自带一套匹配好的rknn-toolkit2依赖建议直接用SDK内置环境或requirements.txt安装而不是用pip全装最新版。我这里最终固定在一个兼容版本上目标平台声明为rv1106后续所有实验都基于这个版本完成。版本匹配还涉及板端的librknnrt运行时库注意两点其一转换工具和板端运行时尽量同版本跨大版本容易出现rknn_init阶段异常其二如果板端刷的是厂商出厂镜像用包管理器里的librknnrt.so版本通常更稳若自己替换库要用strings查看版本信息确认。2.2 板端运行环境与调试通道在进入正式部署前先把板端环境跑通。RV1106开发板通常通过USB adb连接主机板端启动rknn_server服务PC端工具才能把rknn模型推送到NPU上执行。这个连接链路一旦有问题后面的实验全做不了。常见连接问题有两个。第一个是adb找不到设备一般是USB驱动或线材问题第二个是rknn_server没有启动需要手动在板端执行启动脚本或检查系统镜像是否包含对应组件。我建议在正式实验前先跑一个最小的内置demo模型比如SDK自带的分类示例确认从PC到板端的链路完全通畅再开始批量转换模型。板端推理还受CPU和NPU频率影响。RV1106的NPU频率通常由内核动态调频决定但实验对比需要稳定工况我通过devfreq接口把NPU频率锁定在固定档位避免不同模型测试时频率漂移导致误差。另外网络推理时CPU侧也在做人脸检测、图像采集等任务的话会抢占CPU资源所以测试时要尽量减少后台负载。RV1106这类低功耗芯片内存带宽本身就窄图像输入、模型参数、中间特征图同时在DDR上搬运很容易成为实际瓶颈。3. 完整部署流程实录3.1 从PyTorch到ONNX再到RKNN以MobileNetV1为例我先在PC上用PyTorch导出ONNX模型。导出时有一个容易踩到的细节opset版本不要设得太高。RV1106工具链对高opset的支持并不是实时的我测试中opset 17以上偶尔会遇到一些算子节点无法识别换成opset 11基本都能顺利转换。如果你的PyTorch版本默认导出的opset偏高在torch.onnx.export里显式指定一下。导出后建议先用onnxsim做一轮常量折叠和算子简并能减小ONNX模型的规模也能减少一些冗余的Transpose节点。下面是一个标准的RKNN转换流程from rknn.api import RKNN rknn RKNN() rknn.config( mean_values[[123.675, 116.28, 103.53]], std_values[[58.395, 57.12, 57.375]], target_platformrv1106 ) ret rknn.load_onnx(modelmobilenetv1.onnx) ret rknn.build(do_quantizationTrue, datasetdataset.txt) ret rknn.export_rknn(mobilenetv1_int8.rknn) rknn.release()这里mean_values和std_values的值取决于你训练模型时的预处理方式。MobileNetV1在ImageNet上的常用预处理是RGB三通道分别做归一化对应上面那组数值。如果你的训练代码用的是[0, 1]归一化那转换时要对应调整。数据集的图片建议放200张左右内容尽量贴近真实落地场景。量化校准集和推理场景分布差别大的话精度会明显变差。校准集图片尺寸必须先resize到模型输入尺寸再写进dataset.txt。不要用原始尺寸图片否则解码后大小不匹配某些版本会直接量化失败。dataset.txt每一行是一个绝对路径每张图片都会被解码、预处理、收集激活值所以数量不用贪多200张足够多了反而每次build都慢。3.2 板端推理与测速口径模型转换完之后在PC上可以用RKNN模拟器先跑精度验证但最终性能必须板端实测。RV1106上推理的基本代码为rknn_context ctx; rknn_init(ctx, model_data, model_size, 0, NULL); rknn_input inputs[1]; inputs[0].index 0; inputs[0].type RKNN_TENSOR_UINT8; inputs[0].size 224 * 224 * 3; inputs[0].fmt RKNN_TENSOR_NHWC; inputs[0].buf image_buffer; rknn_inputs_set(ctx, 1, inputs, NULL); rknn_run(ctx, NULL); rknn_output outputs[1]; rknn_outputs_get(ctx, 1, outputs, NULL);这里要注意输入格式。从OpenCV读到的BGR图像如果直接用uint8输入要让RKNN把数据格式转成CHW排列否则推理结果会奇怪。一般SDK默认输入格式为NHWC图像数据按HWC连续排列配合uint8类型时NPU内部会做量化scale映射。如果你在PC端preprocess时已经做了float归一化这里就不能再设uint8要改成float32类型否则会发生双重归一化。测速不能只看一次rknn_run的时间。我的做法是每一个模型都先跑20次warm-up再连续测200次取p50和p99两个分位数。单次推理时间在RV1106上抖动比较明显尤其是第一次调用时有算子初始化开销此外NPU与CPU之间的任务提交和同步等待也会掺杂进去。had测前几帧不能算因为存在cache和频率爬坡影响。更准确的做法是用rknn自带profiling接口它会返回NPU算子级别的耗时明细。这样可以区分哪些时间消耗在NPU计算上哪些消耗在数据搬运上。后处理的softmax和top-5排序如果用CPU跑在MobileNet这类模型上也会占用2~3ms如果测的是“端到端帧率”这个部分必须计入。3.3 量化精度验证方法精度验证我分为两步。第一步是PC上的RKNN模拟器精度测试输入用ImageNet val子集抽出的2000张图得到INT8量化模型的top-1准确率第二步是板端实测同一批图片对比模拟器和板端推理结果是否一致。板端和模拟器偶尔会有微小差异主要来自NPU数值舍入细节如果差异超过1个百分点需要检查librknnrt版本是否一致。从实际数据来看MobileNetV1在量化后top-1大约下降2个百分点ResNet18只下降不到2个百分点MobileNetV3-Small下降3~4个百分点ShuffleNetV2下降3个百分点附近。这个规律符合业界对轻量网络量化敏感性的普遍认知结构越轻、激活值分布越不均匀对量化误差的放大效应越明显。MobileNetV3的SE模块在量化后会引入更多敏感激活如果校准集覆盖不足精度掉得比V1更快。量化前建议在PC上额外分析激活值分布看是否有明显长尾或异常离群点。如果有优先考虑用更大的校准集或对原模型做QAT感知训练。对RV1106这种不得不量化的平台QAT往往比int8 PTQ更稳代价是需要重新微调模型。4. 七款模型横向对比4.1 实测数据总表下面是RV1106板端实测的结果汇总。测试条件输入分辨率224x224uint8输入NPU频率锁定最高档单帧耗时取200次推理的p50值精度变化是量化模型相对float原始模型的top-1差值。模型量化后大小单帧耗时(ms)精度变化(top-1)主要问题MobileNetV14.9MB22-2.1%无明显问题MobileNetV26.6MB20-2.5%无明显问题MobileNetV3-Small3.8MB14-3.8%SE算子部分走CPUShuffleNetV24.6MB18-3.1%channel shuffle转换后算子切割多EfficientNet-Lite05.1MB17-2.0%无明显问题ResNet1822.3MB46-1.7%参数多、内存带宽占用高ResNet5049.8MB105-1.5%实时性不足不推荐MobileNetV3-Small理论计算量最小但实际耗时没有和理论优势对齐因为SE模块里全局池化和全连接映射在RV1106上没有完全跑在NPU的深度优化路径上。打印算子分配结果后会看到部分片段被标成CPU算子这类算子虽然占比不大但CPU与NPU之间来回切换会导致整个pipeline停顿。ShuffleNetV2的channel shuffle在转换时会被分解成多个slice和concat操作增加额外数据搬运这也是理论快、实测被拉平的核心原因。ResNet18耗时46ms对一个224x224的分类任务来说勉强可以接受但它的22MB模型体积会在每次加载时多占用不少内存带宽。RV1106这种低成本芯片的DDR位宽有限模型参数频繁从DDR读取时会压缩图像数据搬运的带宽整体体验反而没有更小的模型流畅。4.2 “老模型”反而更稳的深层原因实验里最直观的规律是经典结构模型在NPU上更省心。原因并不复杂。其一是算子类型更规整MobileNetV1核心算子就是普通卷积加深度可分离卷积在NPU上有成熟映射ResNet权重排布规整量化时激活值分布也比较集中。其二是这些模型没有复杂激活函数和全局池化后的小型全连接层避免了单算子开销被放大。其三是它们被导入RKNN生态的年份早属于官方和社区反复验证过的结构。MobileNetV3和EfficientNet-Lite虽然更先进但它们的h-swish、SiLU、SE等算子在一些NPU工具链的优化列表里优先级不高即便没有EEROR也可能被映射成低效的算子序列。这提醒我们做嵌入式部署时不能只看论文里的FLOPs和Accuracy要拿到目标芯片工具链里run一遍再决策。4.3 部署选型建议结合这次实验如果只能给一个结论在RV1106上做图像分类落地优先考虑MobileNetV2或EfficientNet-Lite0。MobileNetV2的算子兼容性、量化精度、实测速度都在一个非常平衡的位置EfficientNet-Lite0理论精度更好一点点但它的优势在真实NPU上未必那么明显还需要额外确认Swish激活的算子实现。如果对帧率要求高、接受一点精度损失MobileNetV3-Small可以做但前提是接受SE算子在CPU上执行的风险。如果对精度非常敏感且硬件成本允许ResNet18是更稳的选择45ms级别的耗时在一些非实时抓拍场景是够用的。建议大家在选型时同时关注三个维度模型FLOPs、NPU算子映射情况、量化后精度保持能力。三者权重按产品场景来定实时交互场景看重前两项离线分析场景看重第三项。5. 常见问题与排障实录5.1 转换阶段的合规检查与算子兜底转换阶段最常见的错误是“某算子不支持”。我遇到过的包括ONNX里残差Add的broadcast形状不匹配、某些导出版本把BatchNorm折叠前残留了额外节点、以及部分注意力模块的动态shape导出。这类问题有一个通用排查思路在load_onnx之后、build之前打印ONNX节点列表人工扫一遍是否有不常见算子。如果有先尝试onnxsim简化再不行就在PyTorch端手动重写该模块将其替换为等价的基础算子组合。替换不是改变模型结构而是把复杂算子拆成NPU能跑的算子序列。e.g. 某模型中用了一个自定义上采样模块导出后工具链不识别我就在PyTorch里把它替换成标准双线性插值重新导出后转换通过。遇到不认识的新算子直接找RKNN工具链的算子支持列表通常能省很多时间官网和SDK文档里都有。还有一点量化阶段偶发“crop size mismatch”或图片解码失败常见原因是dataset.txt里有损坏图片或路径中包含中文。校准集图片最好集中放在英文路径目录避免特殊符号。5.2 板端推理阶段的性能与精度问题板端推理有几个高频问题值得单独说。第一是推理时间不稳定。如果同一个模型单帧耗时经常出现20%波动先检查NPU频率是否被锁定。RV1106的NPU调频节点路径在不同SDK版本里有差异用cat /sys/class/devfreq/*/cur_freq确认当前频率档位必要时通过devfreq接口强制设置。第二是rknn_init失败。这个通常是因为板端librknnrt.so与PC端rknn-toolkit2版本跨度过大。建议两边保持同一个SDK版本或者把板端librknnrt.so替换成与工具链配套版本。替换前备份原文件因为某些厂商镜像里内核模块和runtime版本是绑定的。第三是精度和PC模拟结果差异大。先检查输入数据的排列格式一些底层图像库返回的buffer是BGRA或者带stride对齐这会让单通道数据错位。再检查图像resize算法RKNN内置resize和OpenCV默认resize的插值系数不完全一致对分类模型影响不大但对细粒度分类影响明显。第四是后处理阶段CPU占用过高。softmax如果用exp计算在RV1106这类不带FP32加速单元的小核CPU上会有可观延迟。实际分类任务对top-1或top-5概率归一化不一定需要严格softmax可以比较logits之间的大小直接取最大值省去exp计算。如果一定要softmax数值用定点近似或查表法。5.3 量化精度掉点的排查顺序精度问题在嵌入式视觉项目里比较棘手。按我的经验排查顺序是先确认预处理参数再检查校准集分布最后看激活值分布和量化策略。第一步检查mean和std。很多人把[0,1]归一化模型默认用ImageNet的mean/std来转换精度直接就崩了。第二步检查校准集分类模型校准图尽可能包含各个类别且背景接近真实场景如果校准集都是纯色背景的网上图片而目标场景是室内实拍激活范围就可能偏移。第三步检查是否开启per-channel量化。部分版本对Conv权重默认用per-channel对激活值用per-tensor如果模型层数深且激活分布不均可以尝试调整量化策略。RV1106工具链一般支持设置量化方式和批次大小太低层数的模型在校准时容易出现过拟合到校准集的情况。5.4 实验流程上的一些习惯最后分享几个流程习惯。第一所有模型转换前都归档一份原始ONNX的hash值和转换参数方便复现现场。第二每次debate测试先在PC模拟器上跑通再上板省去大量板端交叉调试时间。第三测速脚本统一用固定输入内容不要用真实摄像头数据流来测模型性能因为采集帧率也会叠加进去。第四保存每轮实验的NPU日志和算子分布报告后续分析性能卡点时能快速回看。个人体会是RV1106这颗芯片虽然算力标签不高但把它当作“可以用工具链约束来倒推模型选型”的典型平台跑完这一轮实验反而对分类模型的算子本质更清晰了。如果你手头也在做类似轻量级NPU的部署建议先不要贪最新模型把手边最成熟的模型完整跑通一遍转换链路再逐步替换结构整体节奏会更稳。后续我还打算对比一下改输入分辨率到128x128之后几个模型的耗时和精度变化以及在动态shape输入场景下的表现到时再继续更新数据。
