把模型真正跑在板子上之前我习惯先想清楚一个问题在 GPU 上刷出来的 Top-1 精度和用户设备上每秒能跑多少帧到底哪个更重要很多做边缘 AI 的同行应该都有同感——论文里的 FLOPs、参数量都只是参考ONNX 转完后能不能在 NPU 上顺利运行INT8 量化后精度掉多少才是项目能否落地的关键。RK3588 在我这几年的边缘视觉项目里出镜率非常高。它最吸引人的点是异构算力齐全8 核 CPU、GPU、NPU 一应俱全NPU 理论上有 6 TOPS 的 INT8 算力还支持 INT4、INT16 混合量化对图像分类、目标检测、人脸识别这类任务完全够用。这次我专门做了一轮实验把从轻量级到中等复杂度的主流图像分类模型都过了一遍包括 MobileNetV3 系列、ResNet 系、EfficientNet-Lite以及 ConvNeXt、Swin Transformer、ViT 这类带注意力机制的模型记录下从 PyTorch/TensorFlow 导出 ONNX再到转换成 NPU 专用格式最后在板端跑推理的全过程。这篇文章不是简单的跑分而是把部署链路里最容易踩坑的环节拆开讲包括工具链版本怎么对齐、校准集怎么准备、预处理参数为什么不能凭感觉填、Transformer 类模型量化后为什么容易崩。如果你正准备在 RK3588 或者同类带 NPU 的平台上做图像分类这份实验分析可以直接当一份避坑参考。1. 为什么选 RK3588 做图像分类部署实验1.1 平台算力与异构架构先把这个平台的家底说清楚。RK3588 采用 8nm 制程CPU 部分是 4 个大核加 4 个小核的经典大小核架构GPU 是 Mali 系列但这次实验的主角不是它们而是那颗集成在 SoC 里的 NPU。它内部有多个 NPU 核心协同工作峰值算力标称 6 TOPSINT8如果跑 INT16 算力会折半但大多数图像分类模型用 INT8 就够了。我之所以拿图像分类模型来做这套实验原因很简单图像分类是计算机视觉里最基础、也最能反映部署链路健康状况的任务。它的网络结构覆盖了普通卷积、深度可分离卷积、残差连接、全局池化、全连接、LayerNorm、Softmax、GELU 等大量常用算子这些算子几乎会在检测、分割、ReID 等更复杂任务里再次出现。换句话说分类模型部署通了其他任务至少能少踩一半坑。另一个实际原因是软硬件配合相对成熟。RK3588 上跑 Linux 系统非常顺Python 环境、C/C 交叉编译链、NPU 运行时库都齐全不像有些 MCU 平台需要自己折腾裤衩级驱动。而且这颗 NPU 通过 DMA 和 CPU 共享内存输入输出可以直接走零拷贝通路对后续做多路视频流并行很有价值。这个特性在后面的性能测试里也会有体现。1.2 实验模型的选择逻辑很多人喜欢只看一两个模型就得出结论但我这次刻意把模型分成了三个梯度。第一梯度是轻量级 CNN以 MobileNetV3-Small、MobileNetV3-Large 为代表这类模型做边缘端分类最常用参数量小、计算量低属于“闭着眼睛跑”的那类。第二梯度是经典中量级模型包括 ResNet18、ResNet50、EfficientNet-Lite0它们在分类精度和计算量之间有比较好的平衡也是很多迁移学习任务的主干网。第三梯度是结构更新、对 NPU 更不友好的 Transformer 类模型比如 ConvNeXt-Tiny、Swin-T、ViT-Tiny它们依赖注意力机制或复杂激活函数转换和量化时经常会碰到算子支持问题。选这些模型的另一个考虑是它们都有人气很高的预训练权重方便统一用同一套公开分类数据集来评测不用自己从头训练能够把变量控制在“部署环境”这一层而不是模型权重质量上。模型参数量约理论计算量部署关注点MobileNetV3-Small2.5M56M MACs算子简单、量化友好MobileNetV3-Large5.4M219M MACs轻量级里精度较高ResNet1811.7M1.8G MACs残差结构、经典ResNet5025.6M4.1G MACs精度高带宽压力略大EfficientNet-Lite04.7M0.4G MACs深度可分离量化后偏敏感ConvNeXt-Tiny28.6M4.5G MACs含 LayerNorm、GELUSwin-T28.3M4.5G MACs窗口注意力算子映射复杂ViT-Tiny5.7M1.3G MACs全局注意力量化风险高从结果来看这个梯度设计基本达到了目的轻量模型跑得快但精度天花板有限中量模型是性价比甜区Transformer 模型则在转换阶段就给我上了一课。后续内容我会把每个环节的细节都摆出来。2. 部署工具链与量化方案拆解2.1 从 PyTorch/TensorFlow 到 ONNX 的转换所有模型部署的第一步都是先把训练框架的权重导出成一种“中间表示”因为 NPU 工具链不可能直接认识 PyTorch 的 .pth 文件或者 TensorFlow 的 SavedModel。ONNX 就是目前最通用的中间格式之一。理论上你用 PyTorch 训练再导出 ONNX然后交给 NPU 工具链去编译链路是通的。但这步的坑比想象中多。最基础的是要保证模型的预处理逻辑在导出时就被“焊”进图里或者至少保证后续转换配置和训练时完全一致。很多人在 GPU 上推理时用 PyTorch 的 transforms包括 Resize、CenterCrop、Normalize部署到板端却发现精度崩了排查到最后往往是预处理参数错位比如 RGB/BGR 顺序不对、mean/std 用错、缩放后没有先减均值再乘方差等等。导出 ONNX 还有几个关键参数要注意。opset版本不能太低太低会导致某些新算子无法表示dynamic_axes如果不设置模型默认是固定输入尺寸。图像分类模型一般固定成 224×224 就好但如果你后续想跑批量推理建议把 batch 维度设为动态这样同一个 .onnx 文件既能 batch1也能 batch4。不过动态维度在转 NPU 模型时可能带来额外的算子复杂度需要根据工具链支持情况权衡。如果 ONNX 里带有一些过于“花哨”的算子比如自定义注意力实现里的einsum、broadcast组合直接用算子优化器简化一下会更稳。简化后的模型往往能减少一些冗余的 Reshape、Transpose这些多余节点在 NPU 上经常是性能杀手。2.2 RK3588 NPU 工具链与 RKNN 格式RK3588 的 NPU 并不能直接跑 ONNX需要先把它转成平台私有的模型格式这一步必须用官方提供的工具链完成。我这次的流程是在 x86 的 PC 上用工具链读取 ONNX配置量化参数编译生成 .rknn 格式文件然后把 .rknn 拷贝到板子上用板端运行时库加载推理。必须强调的是版本对齐问题。工具链版本和板端运行时库版本一定要严格匹配否则最常见的现象是 PC 端转换一切正常板端一加载就报版本不匹配或者报一个莫名其妙的内存错误。我吃过一次亏当时工具链升级到了新版本但板端系统里的运行时库还是旧版排查了很久才发现是这个问题。建议开一个新项目时先把工具链和运行时库的版本号固定写进文档最好连 Linux 内核版本和 Python 版本一起记录部署问题里有一大半跟环境漂移有关。转换过程中的算法规格也需要注意。比如 NPU 对某些算子的支持是有限制的Resize 的插值方式、池化的核大小与步长组合、Softmax 的轴方向、激活函数的范围都可能影响算子映射。工具链会在转换时打印算子映射日志看到 “not support” 或者 “fallback” 这类字眼就要留意了。有些算子会落到 CPU 上执行在整体耗时上会明显拖后腿后面我在 Transformer 模型上就遇到了这种情况。2.3 INT8 量化PTQ 与 QAT 的取舍RK3588 的 6 TOPS 算力是 INT8 算力把 FP32 模型转成 INT8 不仅能跑得更快还能显著减少内存带宽压力。量化方案主要分两种训练后量化和量化感知训练。训练后量化用起来最省事。你只需要准备一个校准集工具链会统计各层激活值的分布然后计算量化参数。校准集数量不能太少我曾经试过只放 20 张图结果某一层激活值范围统计得特别偏最终模型在真实数据上精度损失超过 3%。建议校准集至少覆盖 100 到 200 张图片最好能从目标业务场景里抽而不是随便找一堆不相关的图。如果目标场景是车牌识别你却拿风景图做校准量化后的模型很有可能会在车牌数据上精度崩掉。量化感知训练的效果通常比训练后量化好但需要你在训练流程里就让模型模拟量化误差等于训练和部署要做联合调整。对于图像分类模型除了极小的模型和含注意力的模型绝大多数情况下训练后量化已经完全够用我这次除了 ViT-Tiny 这类特别敏感的模型外都优先走训练后量化。如果碰到个别层量化后误差特别大可以考虑对该层做混合精度也就是某些关键层保持 FP16 或 INT16其他层用 INT8工具链支持按层设置量化参数这也是后面精度调优的重要手段。3. 完整实操模型转换到板端推理3.1 环境准备与版本对齐先把环境讲清楚。我是在一台 x86 机器上做转换操作系统是 Ubuntu 20.04Python 用 3.8工具链选用与板端运行时匹配合适的版本。建议有条件的话用独立的虚拟环境因为工具链依赖的 NumPy 版本、OpenCV 版本和你要跑的深度学习框架容易起冲突单独环境后续重装不心疼。板端是 RK3588 开发板内存 8GB系统是 Linux默认已经烧录了包含 NPU 驱动和运行时库的固件。我习惯先把 NPU 频率调到比较固定的档位避免降频干扰测试结果。Linux 下可以通过设备树或者 sysfs 节点查看频率状态跑性能测试前先写一个固定频率的命令把 CPU 也调整成性能模式。这些操作细节看起来很琐碎但对复现实验结果影响很大同一块板子电源策略不同推理耗时能差 20%。3.2 三步完成模型转换转换脚本不算复杂核心逻辑如下from rknn.api import RKNN rknn RKNN(verboseTrue) rknn.config( mean_values[[123.675, 116.28, 103.53]], std_values[[58.395, 57.12, 57.375]], target_platformrk3588, quantized_dtypew8a8 ) ret rknn.load_onnx(modelmobilenetv3.onnx) if ret ! 0: raise RuntimeError(load onnx failed) ret rknn.build(do_quantizationTrue, datasetdataset.txt) if ret ! 0: raise RuntimeError(build failed) ret rknn.export_rknn(mobilenetv3.rknn) rknn.release()mean_values和std_values必须和训练时保持一致。我选的这组值是常见 ImageNet 预处理的默认值如果你的模型是在自定义数据集上训练的这里要换成你自己的统计值。还有一个隐藏点工具链会对输入做归一化一般来说顺序是“先减均值再除方差”这个顺序不能搞反。dataset.txt每行放一张校准图片的绝对路径。我建议校准图片从测试集里抽不抽取训练集因为训练集参与过模型参数拟合用它做量化校准会让统计结果过于乐观部署后真实场景精度会打折扣。抽取数量不需要太多300 张左右对稳定统计已经足够了。转换完成后还需要在 PC 端做一个精度评估。工具链提供了模拟器功能可以直接加载未量化的模型和量化后的模型跑一遍图片输出预测结果和真实标签的差异用来粗筛精度损失。不过模拟器只是参考最终数据还是要以板端实测为准因为板端运行时库版本、NPU 行为都会对结果有影响。3.3 板端 C 推理示例与性能计时板端推理我优先用 C/C 接口而不是 Python因为 Python 解释器开销和 GIL 锁会干扰性能测试。C 接口调用流程也比较直接#include stdio.h #include stdlib.h #include time.h #include rknn_api.h int main() { rknn_context ctx; int ret rknn_init(ctx, mobilenetv3.rknn, 0, 0); if (ret 0) { printf(rknn_init error %d\n, ret); return -1; } // 读取输入图片并做预处理得到归一化后的 uint8/int8 数据 cv::Mat img read_image(test.jpg); rknn_input inputs[1]; inputs[0].index 0; inputs[0].type RKNN_TENSOR_UINT8; inputs[0].size img.total() * img.channels(); inputs[0].buf img.data; inputs[0].pass_through 0; rknn_output outputs[1]; outputs[0].want_float 1; outputs[0].index 0; clock_gettime(CLOCK_MONOTONIC, t1); ret rknn_run(ctx, inputs, NULL); ret rknn_outputs_get(ctx, 1, outputs, NULL); clock_gettime(CLOCK_MONOTONIC, t2); // outputs[0].buf 里就是分类 logits 或 softmax 结果 rknn_outputs_release(ctx, 1, outputs); rknn_destroy(ctx); return 0; }性能测试需要注意预热。第一次调用 rknn_run 时模型在 NPU 上有加载初始化、内存分配等过程耗时往往会比后续运行高很多所以不能拿第一次的耗时当性能数据。正确做法是先跑至少 50 轮“空跑”让运行环境稳定下来然后再正式跑几百轮取平均值。我通常会统计三个指标平均单帧耗时、P99 耗时、连续运行时的最大耗时。P99 能反映卡顿情况对视频流应用特别重要。4. 实验结果解读与数据对比4.1 推理耗时与吞吐量对比这是整轮实验最直观的数据。统一使用 224×224 输入batch1NPU 频率固定到最高档数据全部来自板端 C 接口实测。需要说明的是不同工具链版本、不同固件版本数据会有差异但整体排序有参考价值。模型INT8 NPU 平均耗时理论最大 FPS量化前 CPU 耗时参考MobileNetV3-Small2.6 ms38415 ms 左右MobileNetV3-Large4.8 ms20828 ms 左右ResNet186.9 ms14535 ms 左右ResNet5014.2 ms7090 ms 左右EfficientNet-Lite07.5 ms13341 ms 左右ConvNeXt-Tiny25.3 ms39110 ms 左右Swin-T42.8 ms23150 ms 左右ViT-Tiny31.6 ms3170 ms 左右从数据里能明显看到CNN 系模型在 NPU 上的加速比非常高MobileNetV3-Small 比 CPU 快 5 倍以上ResNet50 也是 6 倍左右。这说明这类模型的主要算子比如卷积、ReLU、全局池化、全连接都能很好映射到 NPU 的硬件计算单元上。Transformer 系模型就没有那么幸运了。Swin-T 的耗时接近 ResNet50 的三倍ViT-Tiny 作为一个小模型也跑出了和中型 CNN 相当的时间。原因是注意力机制涉及大量矩阵转置、Softmax、LayerNorm 等操作这些不是 NPU 的强项有一部分算子会被拆成 CPU 计算或通过复杂映射执行造成额外的内存搬运和多次读写最终把加速比拉低。4.2 精度损失与量化影响精度测试我统一使用公开 1K 类分类数据集的验证集子集选取固定数量的图片保证每个模型用同一份评测数据避免抽样误差。同时对所有模型分别统计 FP32 基准精度和 INT8 转换后精度。模型FP32 Top-1参考INT8 Top-1精度损失MobileNetV3-Small67.5%67.0%-0.5%MobileNetV3-Large75.2%74.8%-0.4%ResNet1869.8%69.5%-0.3%ResNet5076.1%75.8%-0.3%EfficientNet-Lite075.1%74.2%-0.9%ConvNeXt-Tiny82.0%80.5%-1.5%Swin-T81.3%78.9%-2.4%ViT-Tiny72.3%68.7%-3.6%经典 CNN 对 INT8 量化很宽容损失基本控制在 0.5% 以内。EfficientNet-Lite0 损失接近 1%因为它的深度可分离卷积对激活值范围更敏感需要稍微调整量化策略。Transformer 系模型的损失明显更大尤其是 ViT-Tiny量化后掉了 3.6%几乎到了不能直接商用的程度。后来我针对 ViT-Tiny 做了混合精度实验只把 Embedding 层和最后一层分类头保持 FP16其余层还是 INT8精度损失从 3.6% 降到 1.2%耗时只增加了约 15%。这说明量化敏感层往往在模型入口和出口而不是中间所有层。这个结论对做模型优化很有用优先保护所有和空间结构相关的层比如 Patch Embedding、Position Embedding以及最后的分类头。4.3 内存、功耗与稳定性观察除了速度和精度部署还绕不开内存和功耗。模型推理时的常驻内存由权重、中间激活值、输入输出缓冲三者组成。INT8 量化后权重部分大幅缩小但中间激活值的大小对某些模型反而更明显。实测下来ResNet50 的模型文件只有 26MB 左右但在 batch1 时推理峰值内存占用大概 120MB 左右而 ViT-Tiny 模型文件更小峰值内存却接近 ResNet50 的 80%因为注意力矩阵的中间结果占了不少临时内存。功耗方面我只是用板载电流计做了趋势观察没有做精密测量。轻量模型整板功耗稳定在一个较低区间ResNet50 连续跑 1000 帧后整板功耗明显上升Swin-T 连续跑时发热更加集中。有一个实际现象值得注意长时间高负载运行后如果散热条件不够好NPU 频率会下降推理耗时可能从 14ms 慢慢涨到 18ms 甚至更高。所以测试耗时一定要记录温度或频率状态否则数据根本没有可比性。5. 常见问题与排查经验5.1 算子兼容性导致的转换失败我做的这些模型里最让人头疼的是 Transformer 类模型在转换时报算子不支持。常见的问题主要集中在 GELU 激活函数的不同实现、LayerNorm 的标准化维度、Softmax 的 axis 设置以及注意力机制里的多头 Reshape 和 Transpose 组合。碰到这样的情况我的第一步是用算子优化器先自动简化 ONNX很多由 PyTorch 导出的冗余节点会被合并掉。第二步是看抑制日志里到底卡在哪个算子然后针对性地改动模型源码。比如 GELU 可以用近似公式拆成 Sigmoid 和乘法组合LayerNorm 在一些工具链版本里可以直接支持但如果你的版本不支持就需要把 LayerNorm 改写为计算均值、方差、归一化、缩放加平移的算子组合耐心一点都能绕过去。还有一个更省力的方案换一个更新版本的工具链。工具链每次大版本更新都会增加一批算子的硬件映射支持尤其是 Transformer 相关的算子这两年在逐步完善。所以如果你报错先确认当前工具链不是太老。最近我做 ViT 系列时升级工具链版本后原本需要拆算子的模型可以直接转换省了大量手动重写工作。5.2 量化后精度异常的定位思路量化后精度大幅下降是最难排查的部分。因为 NPU 是黑盒你看不到中间激活的真实数值只能靠经验。我常用的定位方法分几步。第一先把量化关闭生成一个 FP32 或 INT16 模型在板端跑一遍确认转换本身没有破坏精度。如果关闭量化后精度依然很差问题在模型转换和预处理跟量化无关。第二如果关闭量化精度正常、打开 INT8 后精度崩了我会把校准集扩充到几百张并把校准图片换成业务场景数据。第三如果校准集调整没用就用混合精度逐层排查把可能敏感的层单独挑出来保持高精度二分法定位。还有一次我碰到精度掉很多最后发现是图像预处理时用了 BGR 顺序而模型训练用的是 RGB。这种事很蠢但也很常见。在板端推理时OpenCV 读取图片默认是 BGR如果你直接把 Mat 喂给 NPU而 NPU 输入端期望的是 RGB精度必然有问题。最好在代码里明确转换通道顺序并且写一个单元测试打印预处理前后的像素值不要靠目测。5.3 性能瓶颈与缓存对齐技巧从实验数据可以看出模型在 NPU 上的耗时并不跟参数量严格正比。ResNet18 和 EfficientNet-Lite0 的参数量差别不小但耗时差别不大原因在于 EfficientNet 的深度可分离卷积需要频繁访问内存而 NPU 的算子调度有时跟不上。遇到这种情况不要盲目换更大的模型先看看是不是内存带宽卡脖子了。提升性能有几个小技巧。输入数据的通道顺序尽量保持连续内存避免做跨步访问如果板端支持 C 接口的零拷贝输入就用零拷贝把图片数据直接放到 DMA buffer 里省掉一次拷贝连续跑多个 batch 时如果模型支持动态 batch可以通过加大 batch 减少平均耗时但要注意 batch 太大会导致中间激活值激增内存占用可能翻倍。另外如果模型里某几个算子被强制 CPU 回退有时候整体耗时反而比全部走 NPU 更快因为避免了两边同步的开销。可以在转换配置或者运行时里尝试把某些低效算子调度到 CPU不要迷信“所有层都必须跑 NPU”。我做 ViT-Tiny 的时候把几个大的矩阵乘法留在 NPU把 Softmax 和 LayerNorm 放 CPU整体延迟反而比纯 NPU 方案低。最后一件事板子的散热和电源一定要稳定。我跑长时间性能测试时发现如果单纯拿散热台架上的数据去评估真实设备往往会被打脸。真实盒子塞在机箱里温度上来之后 NPU 频率会明显下降。所以在选型阶段就要给算力留 20% 到 30% 的余量而不是卡着理论峰值来设计系统。这次实验做下来我个人最深的体会是分类模型部署的难度曲线不是按参数量排的而是按“算子结构”排的。传统 CNN 就像一盘家常菜随便怎么炒都难吃不到哪去Transformer 类模型就像一道讲究火候的菜每一步都不能出错。如果你以后要在类似 NPU 平台上做更复杂的检测或分割模型建议先拿分类模型把工具链、量化、硬件特性摸透再往下走会省非常多时间。最后再分享一个小习惯每次转换后都保留一份完整的日志包括模型文件名、工具链版本、运行时版本、校准集大小、预处理参数。部署问题玄学的时候这一份日志就是你最实用的排障地图。 
长河君 · 2026/10/14 20:05:22 · 阅读 1.2k RK3588 NPU图像分类部署实践：从ONNX转换到INT8量化避坑指南
把模型真正跑在板子上之前我习惯先想清楚一个问题在 GPU 上刷出来的 Top-1 精度和用户设备上每秒能跑多少帧到底哪个更重要很多做边缘 AI 的同行应该都有同感——论文里的 FLOPs、参数量都只是参考ONNX 转完后能不能在 NPU 上顺利运行INT8 量化后精度掉多少才是项目能否落地的关键。RK3588 在我这几年的边缘视觉项目里出镜率非常高。它最吸引人的点是异构算力齐全8 核 CPU、GPU、NPU 一应俱全NPU 理论上有 6 TOPS 的 INT8 算力还支持 INT4、INT16 混合量化对图像分类、目标检测、人脸识别这类任务完全够用。这次我专门做了一轮实验把从轻量级到中等复杂度的主流图像分类模型都过了一遍包括 MobileNetV3 系列、ResNet 系、EfficientNet-Lite以及 ConvNeXt、Swin Transformer、ViT 这类带注意力机制的模型记录下从 PyTorch/TensorFlow 导出 ONNX再到转换成 NPU 专用格式最后在板端跑推理的全过程。这篇文章不是简单的跑分而是把部署链路里最容易踩坑的环节拆开讲包括工具链版本怎么对齐、校准集怎么准备、预处理参数为什么不能凭感觉填、Transformer 类模型量化后为什么容易崩。如果你正准备在 RK3588 或者同类带 NPU 的平台上做图像分类这份实验分析可以直接当一份避坑参考。1. 为什么选 RK3588 做图像分类部署实验1.1 平台算力与异构架构先把这个平台的家底说清楚。RK3588 采用 8nm 制程CPU 部分是 4 个大核加 4 个小核的经典大小核架构GPU 是 Mali 系列但这次实验的主角不是它们而是那颗集成在 SoC 里的 NPU。它内部有多个 NPU 核心协同工作峰值算力标称 6 TOPSINT8如果跑 INT16 算力会折半但大多数图像分类模型用 INT8 就够了。我之所以拿图像分类模型来做这套实验原因很简单图像分类是计算机视觉里最基础、也最能反映部署链路健康状况的任务。它的网络结构覆盖了普通卷积、深度可分离卷积、残差连接、全局池化、全连接、LayerNorm、Softmax、GELU 等大量常用算子这些算子几乎会在检测、分割、ReID 等更复杂任务里再次出现。换句话说分类模型部署通了其他任务至少能少踩一半坑。另一个实际原因是软硬件配合相对成熟。RK3588 上跑 Linux 系统非常顺Python 环境、C/C 交叉编译链、NPU 运行时库都齐全不像有些 MCU 平台需要自己折腾裤衩级驱动。而且这颗 NPU 通过 DMA 和 CPU 共享内存输入输出可以直接走零拷贝通路对后续做多路视频流并行很有价值。这个特性在后面的性能测试里也会有体现。1.2 实验模型的选择逻辑很多人喜欢只看一两个模型就得出结论但我这次刻意把模型分成了三个梯度。第一梯度是轻量级 CNN以 MobileNetV3-Small、MobileNetV3-Large 为代表这类模型做边缘端分类最常用参数量小、计算量低属于“闭着眼睛跑”的那类。第二梯度是经典中量级模型包括 ResNet18、ResNet50、EfficientNet-Lite0它们在分类精度和计算量之间有比较好的平衡也是很多迁移学习任务的主干网。第三梯度是结构更新、对 NPU 更不友好的 Transformer 类模型比如 ConvNeXt-Tiny、Swin-T、ViT-Tiny它们依赖注意力机制或复杂激活函数转换和量化时经常会碰到算子支持问题。选这些模型的另一个考虑是它们都有人气很高的预训练权重方便统一用同一套公开分类数据集来评测不用自己从头训练能够把变量控制在“部署环境”这一层而不是模型权重质量上。模型参数量约理论计算量部署关注点MobileNetV3-Small2.5M56M MACs算子简单、量化友好MobileNetV3-Large5.4M219M MACs轻量级里精度较高ResNet1811.7M1.8G MACs残差结构、经典ResNet5025.6M4.1G MACs精度高带宽压力略大EfficientNet-Lite04.7M0.4G MACs深度可分离量化后偏敏感ConvNeXt-Tiny28.6M4.5G MACs含 LayerNorm、GELUSwin-T28.3M4.5G MACs窗口注意力算子映射复杂ViT-Tiny5.7M1.3G MACs全局注意力量化风险高从结果来看这个梯度设计基本达到了目的轻量模型跑得快但精度天花板有限中量模型是性价比甜区Transformer 模型则在转换阶段就给我上了一课。后续内容我会把每个环节的细节都摆出来。2. 部署工具链与量化方案拆解2.1 从 PyTorch/TensorFlow 到 ONNX 的转换所有模型部署的第一步都是先把训练框架的权重导出成一种“中间表示”因为 NPU 工具链不可能直接认识 PyTorch 的 .pth 文件或者 TensorFlow 的 SavedModel。ONNX 就是目前最通用的中间格式之一。理论上你用 PyTorch 训练再导出 ONNX然后交给 NPU 工具链去编译链路是通的。但这步的坑比想象中多。最基础的是要保证模型的预处理逻辑在导出时就被“焊”进图里或者至少保证后续转换配置和训练时完全一致。很多人在 GPU 上推理时用 PyTorch 的 transforms包括 Resize、CenterCrop、Normalize部署到板端却发现精度崩了排查到最后往往是预处理参数错位比如 RGB/BGR 顺序不对、mean/std 用错、缩放后没有先减均值再乘方差等等。导出 ONNX 还有几个关键参数要注意。opset版本不能太低太低会导致某些新算子无法表示dynamic_axes如果不设置模型默认是固定输入尺寸。图像分类模型一般固定成 224×224 就好但如果你后续想跑批量推理建议把 batch 维度设为动态这样同一个 .onnx 文件既能 batch1也能 batch4。不过动态维度在转 NPU 模型时可能带来额外的算子复杂度需要根据工具链支持情况权衡。如果 ONNX 里带有一些过于“花哨”的算子比如自定义注意力实现里的einsum、broadcast组合直接用算子优化器简化一下会更稳。简化后的模型往往能减少一些冗余的 Reshape、Transpose这些多余节点在 NPU 上经常是性能杀手。2.2 RK3588 NPU 工具链与 RKNN 格式RK3588 的 NPU 并不能直接跑 ONNX需要先把它转成平台私有的模型格式这一步必须用官方提供的工具链完成。我这次的流程是在 x86 的 PC 上用工具链读取 ONNX配置量化参数编译生成 .rknn 格式文件然后把 .rknn 拷贝到板子上用板端运行时库加载推理。必须强调的是版本对齐问题。工具链版本和板端运行时库版本一定要严格匹配否则最常见的现象是 PC 端转换一切正常板端一加载就报版本不匹配或者报一个莫名其妙的内存错误。我吃过一次亏当时工具链升级到了新版本但板端系统里的运行时库还是旧版排查了很久才发现是这个问题。建议开一个新项目时先把工具链和运行时库的版本号固定写进文档最好连 Linux 内核版本和 Python 版本一起记录部署问题里有一大半跟环境漂移有关。转换过程中的算法规格也需要注意。比如 NPU 对某些算子的支持是有限制的Resize 的插值方式、池化的核大小与步长组合、Softmax 的轴方向、激活函数的范围都可能影响算子映射。工具链会在转换时打印算子映射日志看到 “not support” 或者 “fallback” 这类字眼就要留意了。有些算子会落到 CPU 上执行在整体耗时上会明显拖后腿后面我在 Transformer 模型上就遇到了这种情况。2.3 INT8 量化PTQ 与 QAT 的取舍RK3588 的 6 TOPS 算力是 INT8 算力把 FP32 模型转成 INT8 不仅能跑得更快还能显著减少内存带宽压力。量化方案主要分两种训练后量化和量化感知训练。训练后量化用起来最省事。你只需要准备一个校准集工具链会统计各层激活值的分布然后计算量化参数。校准集数量不能太少我曾经试过只放 20 张图结果某一层激活值范围统计得特别偏最终模型在真实数据上精度损失超过 3%。建议校准集至少覆盖 100 到 200 张图片最好能从目标业务场景里抽而不是随便找一堆不相关的图。如果目标场景是车牌识别你却拿风景图做校准量化后的模型很有可能会在车牌数据上精度崩掉。量化感知训练的效果通常比训练后量化好但需要你在训练流程里就让模型模拟量化误差等于训练和部署要做联合调整。对于图像分类模型除了极小的模型和含注意力的模型绝大多数情况下训练后量化已经完全够用我这次除了 ViT-Tiny 这类特别敏感的模型外都优先走训练后量化。如果碰到个别层量化后误差特别大可以考虑对该层做混合精度也就是某些关键层保持 FP16 或 INT16其他层用 INT8工具链支持按层设置量化参数这也是后面精度调优的重要手段。3. 完整实操模型转换到板端推理3.1 环境准备与版本对齐先把环境讲清楚。我是在一台 x86 机器上做转换操作系统是 Ubuntu 20.04Python 用 3.8工具链选用与板端运行时匹配合适的版本。建议有条件的话用独立的虚拟环境因为工具链依赖的 NumPy 版本、OpenCV 版本和你要跑的深度学习框架容易起冲突单独环境后续重装不心疼。板端是 RK3588 开发板内存 8GB系统是 Linux默认已经烧录了包含 NPU 驱动和运行时库的固件。我习惯先把 NPU 频率调到比较固定的档位避免降频干扰测试结果。Linux 下可以通过设备树或者 sysfs 节点查看频率状态跑性能测试前先写一个固定频率的命令把 CPU 也调整成性能模式。这些操作细节看起来很琐碎但对复现实验结果影响很大同一块板子电源策略不同推理耗时能差 20%。3.2 三步完成模型转换转换脚本不算复杂核心逻辑如下from rknn.api import RKNN rknn RKNN(verboseTrue) rknn.config( mean_values[[123.675, 116.28, 103.53]], std_values[[58.395, 57.12, 57.375]], target_platformrk3588, quantized_dtypew8a8 ) ret rknn.load_onnx(modelmobilenetv3.onnx) if ret ! 0: raise RuntimeError(load onnx failed) ret rknn.build(do_quantizationTrue, datasetdataset.txt) if ret ! 0: raise RuntimeError(build failed) ret rknn.export_rknn(mobilenetv3.rknn) rknn.release()mean_values和std_values必须和训练时保持一致。我选的这组值是常见 ImageNet 预处理的默认值如果你的模型是在自定义数据集上训练的这里要换成你自己的统计值。还有一个隐藏点工具链会对输入做归一化一般来说顺序是“先减均值再除方差”这个顺序不能搞反。dataset.txt每行放一张校准图片的绝对路径。我建议校准图片从测试集里抽不抽取训练集因为训练集参与过模型参数拟合用它做量化校准会让统计结果过于乐观部署后真实场景精度会打折扣。抽取数量不需要太多300 张左右对稳定统计已经足够了。转换完成后还需要在 PC 端做一个精度评估。工具链提供了模拟器功能可以直接加载未量化的模型和量化后的模型跑一遍图片输出预测结果和真实标签的差异用来粗筛精度损失。不过模拟器只是参考最终数据还是要以板端实测为准因为板端运行时库版本、NPU 行为都会对结果有影响。3.3 板端 C 推理示例与性能计时板端推理我优先用 C/C 接口而不是 Python因为 Python 解释器开销和 GIL 锁会干扰性能测试。C 接口调用流程也比较直接#include stdio.h #include stdlib.h #include time.h #include rknn_api.h int main() { rknn_context ctx; int ret rknn_init(ctx, mobilenetv3.rknn, 0, 0); if (ret 0) { printf(rknn_init error %d\n, ret); return -1; } // 读取输入图片并做预处理得到归一化后的 uint8/int8 数据 cv::Mat img read_image(test.jpg); rknn_input inputs[1]; inputs[0].index 0; inputs[0].type RKNN_TENSOR_UINT8; inputs[0].size img.total() * img.channels(); inputs[0].buf img.data; inputs[0].pass_through 0; rknn_output outputs[1]; outputs[0].want_float 1; outputs[0].index 0; clock_gettime(CLOCK_MONOTONIC, t1); ret rknn_run(ctx, inputs, NULL); ret rknn_outputs_get(ctx, 1, outputs, NULL); clock_gettime(CLOCK_MONOTONIC, t2); // outputs[0].buf 里就是分类 logits 或 softmax 结果 rknn_outputs_release(ctx, 1, outputs); rknn_destroy(ctx); return 0; }性能测试需要注意预热。第一次调用 rknn_run 时模型在 NPU 上有加载初始化、内存分配等过程耗时往往会比后续运行高很多所以不能拿第一次的耗时当性能数据。正确做法是先跑至少 50 轮“空跑”让运行环境稳定下来然后再正式跑几百轮取平均值。我通常会统计三个指标平均单帧耗时、P99 耗时、连续运行时的最大耗时。P99 能反映卡顿情况对视频流应用特别重要。4. 实验结果解读与数据对比4.1 推理耗时与吞吐量对比这是整轮实验最直观的数据。统一使用 224×224 输入batch1NPU 频率固定到最高档数据全部来自板端 C 接口实测。需要说明的是不同工具链版本、不同固件版本数据会有差异但整体排序有参考价值。模型INT8 NPU 平均耗时理论最大 FPS量化前 CPU 耗时参考MobileNetV3-Small2.6 ms38415 ms 左右MobileNetV3-Large4.8 ms20828 ms 左右ResNet186.9 ms14535 ms 左右ResNet5014.2 ms7090 ms 左右EfficientNet-Lite07.5 ms13341 ms 左右ConvNeXt-Tiny25.3 ms39110 ms 左右Swin-T42.8 ms23150 ms 左右ViT-Tiny31.6 ms3170 ms 左右从数据里能明显看到CNN 系模型在 NPU 上的加速比非常高MobileNetV3-Small 比 CPU 快 5 倍以上ResNet50 也是 6 倍左右。这说明这类模型的主要算子比如卷积、ReLU、全局池化、全连接都能很好映射到 NPU 的硬件计算单元上。Transformer 系模型就没有那么幸运了。Swin-T 的耗时接近 ResNet50 的三倍ViT-Tiny 作为一个小模型也跑出了和中型 CNN 相当的时间。原因是注意力机制涉及大量矩阵转置、Softmax、LayerNorm 等操作这些不是 NPU 的强项有一部分算子会被拆成 CPU 计算或通过复杂映射执行造成额外的内存搬运和多次读写最终把加速比拉低。4.2 精度损失与量化影响精度测试我统一使用公开 1K 类分类数据集的验证集子集选取固定数量的图片保证每个模型用同一份评测数据避免抽样误差。同时对所有模型分别统计 FP32 基准精度和 INT8 转换后精度。模型FP32 Top-1参考INT8 Top-1精度损失MobileNetV3-Small67.5%67.0%-0.5%MobileNetV3-Large75.2%74.8%-0.4%ResNet1869.8%69.5%-0.3%ResNet5076.1%75.8%-0.3%EfficientNet-Lite075.1%74.2%-0.9%ConvNeXt-Tiny82.0%80.5%-1.5%Swin-T81.3%78.9%-2.4%ViT-Tiny72.3%68.7%-3.6%经典 CNN 对 INT8 量化很宽容损失基本控制在 0.5% 以内。EfficientNet-Lite0 损失接近 1%因为它的深度可分离卷积对激活值范围更敏感需要稍微调整量化策略。Transformer 系模型的损失明显更大尤其是 ViT-Tiny量化后掉了 3.6%几乎到了不能直接商用的程度。后来我针对 ViT-Tiny 做了混合精度实验只把 Embedding 层和最后一层分类头保持 FP16其余层还是 INT8精度损失从 3.6% 降到 1.2%耗时只增加了约 15%。这说明量化敏感层往往在模型入口和出口而不是中间所有层。这个结论对做模型优化很有用优先保护所有和空间结构相关的层比如 Patch Embedding、Position Embedding以及最后的分类头。4.3 内存、功耗与稳定性观察除了速度和精度部署还绕不开内存和功耗。模型推理时的常驻内存由权重、中间激活值、输入输出缓冲三者组成。INT8 量化后权重部分大幅缩小但中间激活值的大小对某些模型反而更明显。实测下来ResNet50 的模型文件只有 26MB 左右但在 batch1 时推理峰值内存占用大概 120MB 左右而 ViT-Tiny 模型文件更小峰值内存却接近 ResNet50 的 80%因为注意力矩阵的中间结果占了不少临时内存。功耗方面我只是用板载电流计做了趋势观察没有做精密测量。轻量模型整板功耗稳定在一个较低区间ResNet50 连续跑 1000 帧后整板功耗明显上升Swin-T 连续跑时发热更加集中。有一个实际现象值得注意长时间高负载运行后如果散热条件不够好NPU 频率会下降推理耗时可能从 14ms 慢慢涨到 18ms 甚至更高。所以测试耗时一定要记录温度或频率状态否则数据根本没有可比性。5. 常见问题与排查经验5.1 算子兼容性导致的转换失败我做的这些模型里最让人头疼的是 Transformer 类模型在转换时报算子不支持。常见的问题主要集中在 GELU 激活函数的不同实现、LayerNorm 的标准化维度、Softmax 的 axis 设置以及注意力机制里的多头 Reshape 和 Transpose 组合。碰到这样的情况我的第一步是用算子优化器先自动简化 ONNX很多由 PyTorch 导出的冗余节点会被合并掉。第二步是看抑制日志里到底卡在哪个算子然后针对性地改动模型源码。比如 GELU 可以用近似公式拆成 Sigmoid 和乘法组合LayerNorm 在一些工具链版本里可以直接支持但如果你的版本不支持就需要把 LayerNorm 改写为计算均值、方差、归一化、缩放加平移的算子组合耐心一点都能绕过去。还有一个更省力的方案换一个更新版本的工具链。工具链每次大版本更新都会增加一批算子的硬件映射支持尤其是 Transformer 相关的算子这两年在逐步完善。所以如果你报错先确认当前工具链不是太老。最近我做 ViT 系列时升级工具链版本后原本需要拆算子的模型可以直接转换省了大量手动重写工作。5.2 量化后精度异常的定位思路量化后精度大幅下降是最难排查的部分。因为 NPU 是黑盒你看不到中间激活的真实数值只能靠经验。我常用的定位方法分几步。第一先把量化关闭生成一个 FP32 或 INT16 模型在板端跑一遍确认转换本身没有破坏精度。如果关闭量化后精度依然很差问题在模型转换和预处理跟量化无关。第二如果关闭量化精度正常、打开 INT8 后精度崩了我会把校准集扩充到几百张并把校准图片换成业务场景数据。第三如果校准集调整没用就用混合精度逐层排查把可能敏感的层单独挑出来保持高精度二分法定位。还有一次我碰到精度掉很多最后发现是图像预处理时用了 BGR 顺序而模型训练用的是 RGB。这种事很蠢但也很常见。在板端推理时OpenCV 读取图片默认是 BGR如果你直接把 Mat 喂给 NPU而 NPU 输入端期望的是 RGB精度必然有问题。最好在代码里明确转换通道顺序并且写一个单元测试打印预处理前后的像素值不要靠目测。5.3 性能瓶颈与缓存对齐技巧从实验数据可以看出模型在 NPU 上的耗时并不跟参数量严格正比。ResNet18 和 EfficientNet-Lite0 的参数量差别不小但耗时差别不大原因在于 EfficientNet 的深度可分离卷积需要频繁访问内存而 NPU 的算子调度有时跟不上。遇到这种情况不要盲目换更大的模型先看看是不是内存带宽卡脖子了。提升性能有几个小技巧。输入数据的通道顺序尽量保持连续内存避免做跨步访问如果板端支持 C 接口的零拷贝输入就用零拷贝把图片数据直接放到 DMA buffer 里省掉一次拷贝连续跑多个 batch 时如果模型支持动态 batch可以通过加大 batch 减少平均耗时但要注意 batch 太大会导致中间激活值激增内存占用可能翻倍。另外如果模型里某几个算子被强制 CPU 回退有时候整体耗时反而比全部走 NPU 更快因为避免了两边同步的开销。可以在转换配置或者运行时里尝试把某些低效算子调度到 CPU不要迷信“所有层都必须跑 NPU”。我做 ViT-Tiny 的时候把几个大的矩阵乘法留在 NPU把 Softmax 和 LayerNorm 放 CPU整体延迟反而比纯 NPU 方案低。最后一件事板子的散热和电源一定要稳定。我跑长时间性能测试时发现如果单纯拿散热台架上的数据去评估真实设备往往会被打脸。真实盒子塞在机箱里温度上来之后 NPU 频率会明显下降。所以在选型阶段就要给算力留 20% 到 30% 的余量而不是卡着理论峰值来设计系统。这次实验做下来我个人最深的体会是分类模型部署的难度曲线不是按参数量排的而是按“算子结构”排的。传统 CNN 就像一盘家常菜随便怎么炒都难吃不到哪去Transformer 类模型就像一道讲究火候的菜每一步都不能出错。如果你以后要在类似 NPU 平台上做更复杂的检测或分割模型建议先拿分类模型把工具链、量化、硬件特性摸透再往下走会省非常多时间。最后再分享一个小习惯每次转换后都保留一份完整的日志包括模型文件名、工具链版本、运行时版本、校准集大小、预处理参数。部署问题玄学的时候这一份日志就是你最实用的排障地图。