企业官网建设流程全解析

1. 边缘端图像分类部署的背景与选型逻辑

1.1 为什么要在RV1126B上折腾图像分类

做嵌入式视觉的同行大概都有个共识：训练模型只是万里长征第一步，真正让人掉头发的是把模型塞进那块算力、内存、功耗都卡得死死的板子里。瑞芯微RV1126B这颗芯片这两年在安防、智能门禁、工业质检、消费级机器人里出镜率很高，它自带NPU，标称算力在同类里算能打的，但"能跑"和"跑得好"完全是两码事。

我这次做的事情很直接：把当前主流的几类图像分类模型——从轻量级的MobileNet系列、ShuffleNet系列，到稍重一些的ResNet、EfficientNet，再到近两年比较火的ViT轻量变体——统一放到RV1126B上做一轮部署实验，横向对比它们的精度、推理延迟、内存占用、NPU利用率以及量化后的掉点情况。目标不是刷榜，而是给实际选型提供一份能直接抄作业的参考。

这篇文章适合三类人看：一是正在做边缘端视觉产品选型、纠结用哪个backbone的工程师；二是刚接触瑞芯微NPU工具链、想知道量化部署全流程长什么样的新手；三是已经能跑通demo、但想进一步压榨性能的老手。我会把每一步的操作意图、参数取舍、踩过的坑都摊开讲，尽量让你看完就能在自己的板子上复现。

1.2 RV1126B这颗芯片的脾气

先把硬件底子说清楚，不然讨论部署就是空中楼阁。RV1126B的NPU是瑞芯微自研架构，支持INT8和INT16推理，官方工具链对INT8的支持最成熟。它的内存带宽和片上缓存是主要瓶颈——这一点很关键，因为很多模型在PC上看着FLOPs不高，但一到板子上就因为访存模式不友好而拉胯。

我实测下来，这颗NPU对卷积类算子非常友好，尤其是3x3、1x1卷积和深度可分离卷积，基本能做到接近理论峰值的利用率。但对一些特殊结构就比较挑剔：比如大kernel的卷积、频繁的reshape和transpose、以及注意力机制里的矩阵乘，这些在量化转换阶段容易出问题，要么不支持，要么被迫回退到CPU跑，延迟直接爆炸。

所以选型的第一原则是：优先选卷积为主、结构规整、算子常规的模型。这也是为什么MobileNet和ResNet系列在边缘端一直生命力旺盛——不是它们多先进，而是它们"好伺候"。

1.3 实验的整体设计思路

我把实验分成四个阶段，逻辑是层层递进的：

第一阶段是模型准备与基线测试，在PC上跑通各模型的原始精度，作为后续对比的基准。第二阶段是量化转换，用官方工具链把浮点模型转成INT8，记录转换成功率和量化掉点。第三阶段是板端部署与性能实测，测延迟、内存、NPU占用。第四阶段是横向对比与选型建议，把数据整理成表，给出不同场景下的推荐。

这里有个容易被忽略的点：量化掉点必须在转换阶段就摸清楚，不能等上了板子才发现精度崩了。我的做法是准备一个校准集（calibration dataset），从训练集里随机抽几百张有代表性的图，覆盖各个类别和光照条件，用它来做量化校准。校准集的质量直接决定量化后的精度，这一点后面会细讲。

2. 模型准备与量化转换的核心细节

2.1 模型清单与选择理由

这次我选的模型覆盖了三大类结构，基本能代表当前边缘端的主流选择：

选这些不是为了凑数，而是每一类都对应一个具体的部署疑问。比如ShuffleNetV2的通道混洗操作，在量化时经常遇到算子不支持的问题；EfficientNet的SE模块涉及全局池化和逐通道乘法，也是量化敏感区；ViT变体则是想看看注意力机制到底能不能在RV1126B上跑得动。

2.2 量化转换的完整流程

量化是整个部署里最容易翻车的环节，我把流程拆成五步，每一步都有讲究。

第一步：模型导出为ONNX。这一步看似简单，但坑不少。PyTorch导出ONNX时要注意opset版本，我建议用opset 11或12，太新的版本工具链可能不认。导出后一定要用onnx-simplifier做一次简化，把冗余的算子合并掉，否则转换阶段会报一堆莫名其妙的错。命令大概是这样：

python -m onnxsim model.onnx model_sim.onnx

第二步：准备校准集。校准集不是随便抽几张图就行。我的经验是：每个类别至少抽10到20张，总数控制在300到500张之间。太少校准不充分，太多转换时间会拉长。图片要做和训练时一致的预处理（resize、归一化），但注意——归一化的均值和方差要按量化工具的要求来，有些工具链要求输入是0到255的原始像素，有些要求归一化到0到1，搞错了精度直接崩。

第三步：配置量化参数。这一步是核心。工具链一般会提供一个配置文件，里面要指定输入节点名、输出节点名、量化类型（INT8）、校准方式（KL散度或min-max）。我实测下来，KL散度校准对分类模型更友好，掉点更小。另外要特别注意逐通道量化（per-channel）还是逐张量量化（per-tensor），逐通道精度更高但转换更慢，RV1126B是支持逐通道的，建议开启。

第四步：执行转换。转换过程中要盯着日志看，重点看有没有算子回退到CPU的警告。如果有，说明这个算子在NPU上不支持，要么改模型结构，要么接受性能损失。我遇到最多的是reshape和transpose，这两个在ViT变体里特别多。

第五步：验证量化模型。转换完不要急着上板子，先在PC上用工具链自带的模拟器跑一遍，对比量化前后的精度。如果掉点超过2个百分点，就要回头检查校准集和量化配置。

提示：量化转换不是一次就能成功的，我平均每个模型要调2到3轮才能达到满意的精度。别指望一把过，留足调试时间。

2.3 量化掉点的实测数据

把六个模型都转完之后，我整理了一份量化前后的精度对比。测试集用的是标准的1000类分类任务，top-1精度：

这份数据很能说明问题。ResNet18掉点最小，因为它的结构最规整，全是标准卷积和残差连接，量化友好度最高。MobileNetV2和ShuffleNetV2掉点都在1%出头，属于可接受范围。EfficientNet-B0掉点接近3%，主要是SE模块里的全局池化和sigmoid激活对量化敏感。ViT变体掉点超过5%，注意力机制里的softmax和矩阵乘在INT8下精度损失严重，这个后面会专门分析。

3. 板端部署与性能实测全记录

3.1 部署环境的搭建

板端部署的第一步是把工具链的运行时库和模型文件推到板子上。RV1126B一般跑的是精简的Linux系统，通过串口或网络登录进去操作。我习惯用scp传文件，然后写一个简单的C++推理程序调用NPU的API。

推理程序的核心逻辑就三步：初始化NPU上下文、加载模型、循环推理。但这里面有几个细节要注意。输入数据的排布格式必须和模型要求的一致，RV1126B的NPU一般要求NHWC格式，而PyTorch训练出来的是NCHW，转换工具通常会帮你处理好，但如果你自己写预处理，一定要确认清楚，搞反了结果全是乱的。

内存分配也是个坑。NPU推理需要一块连续的物理内存，工具链一般提供了内存分配接口。我建议一次性分配足够大的buffer，避免频繁申请释放导致碎片化。实测下来，ResNet18这种模型大概需要几十MB的输入输出buffer，具体看模型大小。

3.2 推理延迟实测方法与数据

测延迟不能只测一次，要跑几百次取平均，同时记录最大最小值，因为NPU调度有波动。我用的是clock_gettime打时间戳，测的是纯推理时间，不含预处理和后处理。

这组数据信息量很大。MobileNetV3-Small最快，6.5ms，因为它的参数量和计算量都最小，而且结构对NPU友好。ResNet18虽然参数量是MobileNetV2的三倍多，但延迟只有2.7倍左右，说明NPU对规整的卷积结构利用率很高。EfficientNet-B0延迟偏高，除了结构复杂，还因为部分算子回退到了CPU。ViT变体最慢，35.6ms，而且NPU占用率只有65%，说明大量算子在CPU上跑，NPU在"摸鱼"。

3.3 内存占用与功耗表现

内存占用分两部分：模型文件大小和运行时内存。模型文件大小直接反映在存储上，运行时内存则影响系统能同时跑多少任务。

功耗这块我是用外接功率计测的整板功耗，包含CPU、NPU、内存的总和。MobileNet系列功耗最低，适合电池供电的场景。ResNet18功耗最高，但考虑到它的精度和延迟，在对精度要求高、供电充足的场景里仍然值得考虑。

注意：功耗数据受环境温度影响较大，我是在室温25度下测的，高温环境下功耗会略有上升，做产品设计时要留余量。

3.4 预处理与后处理的性能影响

很多人只关注模型推理延迟，忽略了前后处理。实际上在边缘端，图像预处理（resize、归一化、格式转换）经常占用和推理相当甚至更多的时间。我实测下来，一张1080P的图resize到224x224，用CPU做双线性插值大概要3到5ms，如果再加上归一化和NCHW到NHWC的转换，总耗时能到8ms以上，比MobileNetV3的推理还慢。

优化思路有两个：一是用NPU或硬件加速器做预处理，RV1126B有专门的图像处理单元，可以分担这部分工作；二是把预处理和后处理也量化，减少数据搬运。我试过把resize放到硬件单元上做，整体延迟能降30%左右，效果很明显。

后处理主要是softmax和top-k，这部分计算量小，但要注意softmax在INT8下容易溢出，建议在CPU上用浮点做，或者用工具链提供的定点softmax实现。

4. 常见问题排查与选型经验

4.1 量化转换阶段的典型报错

报错一：不支持的算子。最常见的就是遇到Resize、Transpose、Gather这类算子。解决办法是先看工具链文档支持列表，不支持的要么改模型结构替换掉，要么接受它回退到CPU。比如ViT里的patch embedding用了大量reshape，我就把它改成了等价的卷积实现，转换就顺利了。

报错二：校准集格式不对。症状是转换能过，但精度惨不忍睹。原因通常是校准集的预处理和训练时不一致，或者输入节点名写错了。排查方法是把校准集的第一张图dump出来，和训练时的输入对比，逐像素检查。

报错三：内存溢出。转换大模型时可能遇到，尤其是ResNet18以上量级的。解决办法是减小校准集batch size，或者分阶段转换。

4.2 板端运行的常见异常

异常一：推理结果全错。九成是输入格式问题。检查NHWC还是NCHW，检查归一化参数，检查输入尺寸。我踩过一次坑，模型要求输入是0到255的uint8，我传了0到1的float，结果输出全是乱的。

异常二：延迟忽高忽低。一般是NPU调度被其他任务抢占，或者内存带宽被占满。建议推理时把其他进程停掉，或者用工具链提供的性能模式锁定频率。

异常三：跑一段时间后崩溃。多半是内存泄漏。检查每次推理后有没有释放临时buffer，NPU上下文有没有正确销毁。

4.3 不同场景下的选型建议

把上面的数据综合起来，我给几个典型场景的推荐：

场景一：超低功耗、实时性要求高。比如电池供电的智能门锁、无线摄像头。首选MobileNetV3-Small，6.5ms延迟、0.7W功耗，精度65.8%对于人脸检测、简单分类够用。如果精度不够，退而求其次选MobileNetV2。

场景二：精度优先、供电充足。比如工业质检、安防NVR。选ResNet18，69.2%的精度，22.4ms延迟在多数场景可接受，而且量化掉点最小，稳定性最好。

场景三：需要注意力机制但算力有限。可以试试ShuffleNetV2，它的分组卷积和通道混洗在NPU上表现比预期好，精度和MobileNetV2接近，延迟更低。

场景四：想上Transformer。我的建议是再等等。当前RV1126B对注意力机制的支持还不够成熟，ViT变体掉点5%以上、延迟35ms以上，性价比不高。除非你的场景非Transformer不可，否则卷积模型仍然是更务实的选择。

4.4 几个能省时间的实操技巧

第一个技巧：建立自己的模型转换脚本模板。把ONNX导出、简化、量化配置、转换、验证这几步写成一个shell脚本，换个模型只改几个参数就行。我一开始每个模型手动敲命令，后来脚本化之后效率提升好几倍。

第二个技巧：校准集要固定下来。每次转换用同一套校准集，这样不同模型之间的掉点数据才有可比性。我见过有人每次随机抽校准集，结果同一模型两次转换精度差1个多点，根本没法分析。

第三个技巧：善用工具链的模拟器。上板子之前先在PC模拟器上跑一遍，能提前发现大部分问题，省去反复烧录的时间。模拟器的精度和板端基本一致，延迟数据虽然不准，但精度验证足够用。

第四个技巧：记录每次实验的完整配置。模型版本、量化参数、校准集、工具链版本，全部记下来。我吃过亏，隔了两周想复现一个结果，发现忘了当时用的哪个校准集，只能重来。

4.5 关于精度与速度的取舍思考

做边缘部署久了会发现，精度和速度从来不是简单的线性关系。MobileNetV3-Small比MobileNetV2快25%，但精度低5个点；ResNet18比MobileNetV2慢2.7倍，精度只高1.7个点。这个账怎么算，完全取决于你的应用场景。

我的经验是：先确定延迟上限，再在这个约束下选精度最高的模型。比如你的产品要求单帧处理不超过15ms，那ResNet18直接出局，在MobileNetV2、MobileNetV3、ShuffleNetV2里选。如果延迟要求放宽到25ms，ResNet18就值得考虑，因为它量化掉点小、稳定性好，长期运行的可靠性更高。

还有一个容易被忽略的点：模型精度不等于系统精度。分类模型只是整个pipeline的一环，前面的检测、后面的逻辑判断都会影响最终效果。有时候模型精度差1个点，但通过优化前后处理，系统整体准确率反而更高。所以别死盯着模型精度，要看端到端效果。

5. 实验数据的深度解读与延伸

5.1 为什么ResNet18的量化掉点最小

这个现象值得单独说说。ResNet18掉点只有0.6%，远低于其他模型，根本原因是它的结构对量化最友好。标准卷积的权重分布比较集中，量化时的信息损失小；残差连接是恒等映射，不引入额外误差；没有SE、没有注意力、没有分组卷积，全是规整的算子。

反观EfficientNet-B0，SE模块里的全局平均池化会把空间信息压缩成一个通道向量，再经过sigmoid激活。sigmoid在0和1附近梯度很小，量化时这些区域的精度损失被放大，导致掉点明显。ViT更严重，softmax的输出是概率分布，INT8的256个量化级根本不够表达这种精细的分布，掉点自然大。

这个规律可以推广：结构越规整、激活函数越线性、数据分布越集中，量化越友好。选模型的时候，如果量化部署是硬需求，就要优先考虑这些因素，而不是只看浮点精度。

5.2 NPU占用率背后的信息

NPU占用率这个指标很多人不看，但它能告诉你模型到底有没有"跑满"硬件。MobileNetV2占用率85%，说明大部分算子在NPU上跑，效率高。ViT变体只有65%，说明三分之一的时间NPU在等CPU，这种模型即使浮点精度再高，部署价值也大打折扣。

我一般把NPU占用率低于75%视为"部署不友好"的信号。遇到这种情况，要么改模型结构把算子替换成NPU支持的，要么换模型。硬上一个占用率低的模型，等于花了大价钱买NPU却只用了六成算力，不划算。

5.3 批量推理与单帧推理的差异

上面的数据都是单帧推理。实际产品里有时候会做批量推理，比如一次处理4张或8张图。我测过批量推理，延迟不是线性增长的。MobileNetV2单帧8.2ms，batch=4时总延迟约26ms，平均每帧6.5ms，反而更快，因为NPU的并行度被利用起来了。

但批量推理对内存要求更高，而且会增加端到端延迟（要等一批凑齐）。所以实时性要求高的场景还是单帧推理，吞吐优先的场景可以用批量。这个取舍要根据具体产品来定。

5.4 后续可以扩展的方向

这套实验框架还能往几个方向延伸。一是目标检测模型，YOLO系列在RV1126B上的部署是很多人的刚需，量化策略和分类模型有差异，值得单独测。二是模型剪枝与量化结合，先剪枝再量化，看能不能在保持精度的同时进一步压缩。三是不同量化策略的对比，比如KL散度vs min-max，逐通道vs逐张量，这些对精度的影响都值得量化分析。

我自己接下来打算把YOLOv5s和YOLOv8n也纳入测试，看看检测模型在这颗芯片上的表现。如果后面有结果，再整理一篇分享出来。

踩过几次坑之后我最大的体会是：边缘端部署没有银弹，每个模型、每个芯片、每个场景都有自己的脾气。别人测出来的数据只能参考，真正靠谱的还是自己动手跑一遍。上面这些数据和经验，希望能帮你少走点弯路。