企业官网建设流程全解析

1. 为什么选RV1103来做图像分类部署——硬件底子与项目背景

先说清楚我为什么盯上这颗芯片。IPC（网络摄像头）这类产品现在越来越卷，客户既要画面清楚，又要设备端直接跑AI识别，比如人形检测、宠物识别、区域入侵判断。传统方案是主控集成简单的运动检测，灵敏度低误报多；上大算力芯片成本又压不住。RV1103恰好卡在这个中间价位段，带一颗标称0.5TOPS的NPU，双核Cortex-A7做控制流绰绰有余，而且配套的RKNN工具链已经相当成熟，综合下来是尝试边缘分类任务不错的起点。

RV1103的定位很清晰：轻量、低功耗、主打IPC场景。它不像那些服务于汽车或服务器的旗舰SoC，有几十甚至上百TOPS算力，可以随便从网上拖个ResNet152来跑。这颗芯片的NPU算力对重型模型来说完全是空转，真正适合的是MobileNetV1/V2/V3、ShuffleNetV2这类轻量级网络。我这次的实验目标也很明确：在一个约60MB内存可用、NPU算力0.5TOPS的板卡环境下，把主流图像分类模型逐一适配跑通，测量真实性能数据，搞清楚哪些模型能用、哪些是上了板才后悔。

整个实验我按分类任务的标准流程来推进：模型选型 → 导出ONNX → 转为RKNN格式 → 板端验证推理耗时与精度。这不是那种只写了“成功跑通”的演示型验证，而是要回答几个实际问题：转换工具链哪个版本最稳？INT8量化到底掉多少精度？后处理放在CPU上会不会拖累整体帧率？芯片的带宽瓶颈会不会让理论算力打折扣？

如果你是做嵌入式AI、智能硬件、边缘视觉方向的朋友，这篇文章很可能帮你省掉一两周的踩坑时间。特别适合两类读者：一类是刚接触瑞芯微平台、打算把分类模型落地的工程师；另一类是已经在用其他低算力平台（比如各类MCU+NPU方案）做迁移评估的开发者。下文涉及大量实测数据、踩坑记录和参数细节，可以当一份参考笔记来用。

2. 模型选型逻辑：哪些分类模型值得在RV1103上跑，哪些是白费功夫

2.1 轻量级网络的适配面：不是所有“轻量”都适合NPU

图像分类模型在服务器上怎么选都可能被原谅，但在RV1103这种资源受限的平台上，每层算子都可能在转换时成为卡点。我第一轮选了四类模型做候选：MobileNetV1、MobileNetV2、MobileNetV3-Small、ShuffleNetV2-1.0x。它们的共同特点是参数集中在几百万级别，FLOPs控制在1G以内，理论上是NPU容易吃下的量级。但“理论能吃下”和“实际吃得好”是两回事。

MobileNetV1的结构全部由深度可分离卷积构成，这恰好是NPU最喜欢的标准化算子。转换时几乎不需要特殊处理，量化也相对稳定。MobileNetV2引入了倒残差和线性瓶颈，比V1精度略高，同时保持了参数量不膨胀。问题是它的shortcut连接会增加NPU内部的数据搬运开销，板端真实耗时并不如想象中那样只取决于算力标称值。MobileNetV3-Small在结构上加了SE（Squeeze-and-Excitation）注意力模块，这个模块里包含全局平均池化和全连接层，对NPU而言是一种不太友好的结构，因为它在特征图上做动态权重重标定，往往会被拆成多个子算子执行，多了不少访存操作。

ShuffleNetV2的channel shuffle操作在深度学习框架里是一通permute和reshape，转换到RKNN时容易变成额外的拷贝层。它的设计目标是降低内存访问成本，但这个优势在GPU上明显，在RV1103的NPU上反而可能因为算子拆分而打折扣。

2.2 为什么我把EfficientNet-Lite和PP-LCNet也拉进来对比

只看MobileNet和ShuffleNet太常规，我特意再加了两类不同风格的代表：EfficientNet-Lite和PP-LCNet。EfficientNet-Lite是Google为边缘设备裁剪的EfficientNet版本，保留了不少SE模块，理论上精度效率比很突出。但它内部使用了Swish激活函数，部分NPU对Swish支持不佳，有时会被替换成近似的分段函数，导致精度与参考值有偏差。PP-LCNet是百度提出的轻量网络，在CPU上的性能很好，PPLCNetx1.0在ImageNet上能跑到70%以上的Top-1精度，参数量也不大。它在结构上大量使用了深度可分离卷积和优化的激活函数，整体算子友好度看起来不差。

但实测下来，RV1103对这类面向通用推理优化的模型并没有特别的“优待”。模型整体性能和板端NPU执行效率是两套评价体系。如果你只看ImageNet精度和FLOPs，很可能会误判它一定能跑得飞快。实际情况是：FLOPs低是一回事，算子能否完整映射到NPU指令是另一回事；数据搬运次数和中间特征图体积，在某些情况下对耗时的影响远大于乘加运算量本身。

我最终圈定的实验清单包含：MobileNetV1、MobileNetV2、MobileNetV3-Small、ShuffleNetV2-1.0x、EfficientNet-Lite0、PP-LCNetx1.0，外加一个ResNet18作为“暴力对照”——让所有人直观看到，用一颗0.5TOPS算力的芯片跑ResNet系列是什么体验。

2.3 选型评估的硬指标：精度、体积、耗时、内存占用

模型选型不能只凭喜好，我给自己列了四个硬指标：分类精度（在验证集上的Top-1准确率）、模型体积（转换为RKNN后的文件大小）、单帧推理耗时（板端实测）、运行内存峰值。这四个指标最终决定一个模型能否在IPC这类场景落地。分类精度通过本地验证集评估，不需要整个ImageNet跑完；模型体积直接影响Flash占用；单帧耗时直接关系到是否满足实时检测需求；内存峰值则决定是否会和ISP或编码模块抢资源。

所有模型我都在PyTorch环境导出ONNX，再通过RKNN-Toolkit2转成RKNN。这里必须强调一点：转换后的RKNN模型已经不是原模型的逐层复制，NPU工具链会做算子融合、层重排、量化等操作，所以文件体积和原始ONNX体积没有线性关系。

3. 从ONNX到RKNN：模型转换全流程与算子兼容性实测

3.1 环境准备和版本搭配：这一步折腾了一整晚

RKNN工具链的版本匹配问题，是新手最容易翻车的地方，没有之一。PyTorch版本、ONNX版本、RKNN-Toolkit2版本、甚至Python版本之间都存在兼容性约束。我自己在开始阶段就踩了一次：用最新版RKNN-Toolkit2 2.x搭配PyTorch 2.0导出的ONNX，转换时报了一堆“Unsupported operator”的错。

后来我整理了推荐组合，算是实测稳定的搭配：

安装RKNN-Toolkit2这个工具时，建议用独立的conda环境，避免系统Python环境被各种依赖污染。它的依赖库比较多，包括numpy、onnx、tensorflow等，版本不匹配很容易导入失败。我习惯把工具链装在一台x86的Ubuntu机器上，模型转换在PC端完成，生成RKNN文件后再拷贝到板子上加载推理。RV1103板端只需要用到librknnmrt.so运行时库，不需要装完整工具链。

3.2 导出ONNX时的细节：输入尺寸、动态轴、批处理维度

导出ONNX这一步看似简单，里面有很多决定后续转换能否成功的细节点。第一，输入尺寸必须固定成单分辨率，不要保留动态的H和W。RV1103的NPU在静态shape下效率最高，动态分辨率在转换时会变得非常麻烦。第二，batch维最好直接固定为1，无需保留动态batch支持，因为分类任务在边缘设备上绝大多数是单帧识别，动态batch只会让量化校准和推理调度更复杂。

在PyTorch里我用这样的代码导出分类模型：

import torch import torchvision.models as models model = models.mobilenet_v2(pretrained=True) model.eval() dummy_input = torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, "mobilenet_v2.onnx", input_names=["input"], output_names=["output"], opset_version=12, do_constant_folding=True )

opset_version选择12到13之间通常比较稳。opset太旧，某些新算子没有对应映射；opset太新，RKNN工具链可能还没跟上。另外，务必设置opsetset_version=12或13，这比保持默认值更可控。导出后用onnxruntime在PC端做一次推理验证，确认ONNX本身没问题，再进入RKNN转换，这是一个值得养成的好习惯——帮我把“模型本身报错”和“RKNN转换报错”彻底隔离开。

3.3 RKNN转换配置：量化策略、数据集与目标平台设置

RKNN转换的核心接口是RKNN-Toolkit2里的config和build方法。下面是我实验中用到的完整配置流程：

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_platform="rv1103", quantized_dtype="int8", quantized_algorithm="normal", quantized_method="layer", optimization_level=3 ) rknn.load_onnx(model="mobilenet_v2.onnx") rknn.build(do_quantization=True, dataset="./calibration_dataset.txt") rknn.export_rknn("mobilenet_v2.rknn")

三个参数要特别说明。

mean_values和std_values：这里的均值和标准差不是模型训练时的那个三通道取值，而是要和模型预处理对齐。大多数PyTorch图像分类模型的输入归一化是(x / 255 - mean) / std，其中mean和std的数值是ImageNet统计值。RKNN里的mean_values和std_values是配合NPU硬件前处理单元使用的，含义是(pixel - mean) / std，所以要把常用的[0.485, 0.456, 0.406]转换成0-255尺度。许多人在这一步出错，导致板端推理结果和中转结果不一致。转换公式为像素归一化到0-255后减均值：mean_values填103.53, 116.28, 123.675所对应的反推值不太容易搞，直接给标准换算结果更合理：mean=103.53, 116.28, 123.675（因为0.406*255=103.53）。std对应的是0.485*255=123.675这样一组数值……这个换算容易绕晕，建议验证的方式是：跑一个输入做PC端模拟推理，和ONNX输出对比，误差在千分之一以内就说明预处理配置正确。

target_platform="rv1103"：这个参数告诉工具链按RV1103的NPU指令集生成代码，板子固件是RV1103就填RV1103，不要填成其他平台，否则可能生成不可加载的模型。

quantized_algorithm="normal"：量化算法我测试了normal和mmse两种。mmse在部分模型上精度更好，转换耗时也高不少；normal是默认值，速度更快。对RV1103这种轻量任务，normal通常够用，追求精度时再尝试mmse。

3.4 算子兼容性的实测结果汇总

转换过程里我记录了每个模型的“首次转换是否成功”，结果很有参考价值。

ShuffleNetV2的channel shuffle失败是个典型案例。它的实现里有一系列reshape→transpose→reshape操作，某些组合在RKNN工具链里没有直接对应实现。我尝试过在导出前用脚本重写模型结构，把channel shuffle简化为单个自定义算子，但这样又引入额外工作量。考虑到ShuffleNetV2在RV1103上的预期收益未必比MobileNetV2高多少，我在实验中把它标记为“不推荐在RV1103上使用”。这个结论不是因为它精度差，而是转换成本高、板端性能优势不明显，性价比不划算。

4. INT8量化不是白嫖：精度损失实测与校准策略

4.1 为什么要量化：算力与带宽的性价比之选

RV1103的NPU对FP16和INT8都有支持，但实际最能发挥算力的是INT8。INT8量化把权重和激活值从32位浮点压到8位整数，内存占用直接降到四分之一，算力利用率也显著提升。在0.5TOPS这种小算力平台上，不量化基本等于放弃一半以上的理论性能。代价是精度会有一定程度的下跌，尤其在层数多、激活值范围波动大的模型上。

量化不是简单的“把浮点数取整”。工具链会统计每一层激活值的分布，确定一个合适的量化范围，把浮点数值映射到[-128, 127]的整数区间。范围选大了，小的数值被压缩，精度损失大；范围选小了，超出部分被截断，同样损失信息。校准数据集的作用，就是让工具链“看清”真实输入下各层激活值的分布情况，据此算出比较合理的scale和zero_point。

4.2 校准数据集的构建：数量、多样性、与训练集的偏差

我在构建校准数据集时用了200张来自业务场景的图片，覆盖室内、室外、白天、夜晚、不同光照条件。数量不多，但能让统计出的激活值分布比用纯ImageNet图片更贴近真实使用环境。原理上，校准集的作用是模拟“模型部署后会看到的数据”。如果部署场景是门禁摄像头，结果校准集却是风景，量化出来的scale就可能偏差很大，导致识别率掉得离谱。

每张校准图片在送入工具链前，会被预处理成和训练时一致的大小、通道顺序、归一化方式。校准集文件列表的格式是每行一个图片路径，toolkit会自动做前处理，但这里的细节是通道顺序和均值的匹配性。我的训练流程用的是RGB顺序、mean/std按ImageNet统计值归一化，因此在config里填写的mean和std要和这个保持一致，不能图省事填全零。

4.3 精度下降的实测数据：TOP-1准确率对比

我拿了一个包含5000张图片的验证子集做量化前后对比。这个验证集覆盖大约20个类别，是从真实业务中挑选分类难度中等的场景，避免太简单或太难导致看不出差异。

MobileNetV3-Small和EfficientNet-Lite0的下降最明显，和它们结构里大量使用缩放类操作、动态激活有关。MobileNetV3里Swish激活函数的值域会随输入变化明显，量化时较难用一个全局scale覆盖所有分布；EfficientNet-Lite的SE模块同样存在类似问题。如果你的业务场景对精度要求很敏感，建议优先选择MobileNetV1/V2这类传统但结构稳定的模型做基线，再结合实际数据做微调或蒸馏，而不是执着于用了最新结构就当救命稻草。

4.4 量化失败的典型症状：全黑输出和置信度异常

转换过程中我遇过一次量化后模型输出全是0的情况。排查后发现根源在预处理参数不匹配：训练时用的是x/255 → (x-mean)/std，工具链里却写了x-mean → x/std，数值范围完全错位，激活值统计出来的scale几乎全是0。修复方式是统一预处理到同一个公式，重新做校准，问题立刻消失。

另一种症状是输出类别分数极其接近，比如所有类别概率都落在0.04到0.06之间，区分度很差。这通常是量化时激活值范围太小，整个动态范围被压缩到少数几个整数档位。解决办法是换量化算法为mmse，或者增大校准集覆盖度，让激活值分布统计更全面。

5. 推理性能实测：FPS、内存占用与芯片资源画像

5.1 板端推理时间测量方法：多次取均值，防抖动

测量单帧耗时，我用的方法是用芯片的内部计时器，对同一输入连续推理50次，去掉前5次预热，再对剩余45次取平均。后续每次都单独算耗时，结果差异可能来自DDR带宽争用、NPU调度抖动、系统中断等，所以不能只跑一次就下结论。测速脚本用C++实现，避免Python解释器带来的额外开销。

RV1103板端推理接口的调用逻辑是：加载RKNN模型 → 设置输入 → 运行推理 → 读取输出。我在板端写了独立的测试程序，输入数据直接用随机噪声填充，这样评测的是模型计算和调度耗时，不包含图像采集和预处理的时间。实际业务中，这些外围时间也需要计入，但这里先给纯推理数据。

5.2 各模型板端性能实测数据

下面是RV1103上各模型的真实推理耗时，输入分辨率统一为224×224，INT8量化。

这个结果让我重新理解了“0.5TOPS”的意义。MobileNetV2跑224×224输入要38ms，只有26fps左右，远没有想象中那样轻松。一个重要原因在于，RV1103的NPU算力标称值在峰值算子类型下才有，实际混合算子执行时，访存带宽和NPU利用率都会拖后腿。尤其MobileNet类模型，深度卷积部分算子极小，计算密度低，NPU无法达到峰值利用率，大量时间消耗在DDR数据搬运上。

MobileNetV3-Small的最小耗时在意料之中：结构紧凑、中间特征图体积小，访存压力相对最低。但它精度也在四者中最弱，所以实际选型要在“速度能满足要求”和“精度够用”之间找平衡点。ResNet18耗时破百毫秒，单帧10fps，对于连续性检测不够用，但如果只是周期性拍照识别（比如每隔3秒抓拍一次），其实也能接受。

5.3 内存占用的边界测试：会不会把摄像头ISP挤出局

RV1103内置ISP和编码模块会占用不少内存带宽与物理内存，作为IPC方案时，NPU推理不能把内存吃干抹净。我用/proc/meminfo记录了运行推理前后的内存变化，观察每个模型的峰值占用增量。

结论很直接：如果这台设备除了分类还要同时跑ISP、H.264编码、网络传输，那么ResNet18和EfficientNet-Lite0这类内存占用高的模型就不合适。MobileNetV3-Small的内存占用最友好，对整体系统几乎无感。RV1103大多数方案的可用内存有限，跑分类模型前一定先做一轮内存增量评估，不要等到固件集成后发现系统频繁OOM。

5.4 CPU后处理开销：softmax和Top-K统计的隐藏成本

NPU只负责算完最后的全连接层或GAP层后的特征向量，softmax、Top-K统计、阈值判断都是CPU活。RV1103的CPU是Cortex-A7，主频不算高，这些看似轻量的操作在实际频繁调用时也有一笔账。我单独测过纯CPU端softmax加Top-5统计的耗时：1000个类别的输出向量，TP约35万次乘加和exp运算，单次大约0.4ms。看起来很小，但如果你以30fps跑，每秒12ms CPU占用，在一些延迟敏感场景下会影响编码或音视频线程。

建议写法是直接用C++实现softmax，不要调用Python的numpy或torch，因为板端Python环境稀缺且慢。手写循环十几行代码搞定，还能顺便做定点加速优化。

6. 部署过程中的关键坑与排查链路

6.1 踩坑记录：模型加载失败的完整排查过程

有一次，我把RKNN文件拷到板端，加载时直接报错“Initialize RKNN runtime failed”。检查文件确实存在，权限也没问题，这个报错一下看不出所以然。我的排查链路如下：

1. 检查板端rknpu驱动版本是否和工具链匹配。RV1103的NPU用户态驱动和内核驱动都有版本要求，工具链1.6.0生成的模型可能需要特定驱动版本加载。
2. 逐条比对target_platform与加载端固件版本。发现编译RKNN时选了rv1103，但板子固件实际上是rv1103的某个早期测试版本，NPU固件接口不一致，导致runtime初始化失败。
3. 重新刷了对应版本的固件，驱动更新后，同一个RKNN文件顺利加载。

这个问题说明：转换时的target_platform必须和最终板端固件的NPU驱动严格对应，工具链升级后固件也需要同步更新。不要以为RKNN模型是“通用的”，它和NPU指令集绑定得很紧。

6.2 踩坑记录：预处理通道顺序导致精度暴跌

另一个问题更隐蔽。我用OpenCV读取图片时默认是BGR顺序，而分类模型训练时用RGB。如果直接把BGR数据送入NPU，结果会错得一塌糊涂，但不会报错。TOP-1准确率直接从预期的70%掉到20%左右，乍一看还以为是量化出的问题。

我当时的排查思路：先不量化，用FP16模型跑一遍同样的图片，发现精度同样差，说明问题跟量化无关。再检查输入图像的三通道像素值和期望值对比，发现R通道和B通道完全互换。修正方式是调整RKNN的config参数，或者把图片在送入前转换为RGB。这个坑新手几乎必踩，检测方法是选一张有明显色彩特征的图片，比如蓝天和红苹果，跑一次分类看结果是否合理。

6.3 踩坑记录：动态shape和固定shape的暗坑

ONNX导出时如果没固定输入分辨率，转换工具链也能处理，但生成的RKNN模型会包含动态shape逻辑，板端推理时会触发额外的内存重分配和重新调度，耗时比固定shape高出不少。我对比过同一个模型动态与固定输入尺寸的耗时差异，动态版本平均多耗时约20%~30%，而且内存抖动明显。

务必在导出ONNX时使用固定shape的dummy input，并在RKNN的转换配置中不设置任何动态shape参数。分类任务不需要动态输入，固定好后能让NPU的调度器把算子流水线编排得更紧凑。

6.4 踩坑记录：图像缩放与中心裁剪的对齐问题

分类模型训练时的预处理通常包含缩放和中心裁剪，比如先resize到256×256，再中心裁剪到224×224。这个流程在部署到板端时很容易被简化成“直接resize到224×224”。两者虽然在图片内容上看接近，但网络的输入分布已经发生变化，精细特征的相对位置和比例也不一致，精度会小幅下降。

我在部署时按训练流程写了一个等价的预处理链路：解码 → 等比缩放至短边256 → 中心裁剪224×224。这样虽然多消耗一点CPU时间，但保证了模型看到的输入分布尽可能接近训练分布。实测中，这个对齐操作比不做时正确率高了大约1.5个百分点。

6.5 性能调优尝试：从NPU调度到图像预处理全部移入硬件模块

为了榨干RV1103的潜力，我做了几项调优。第一，输入图像格式从RGB改为NV12，让ISP直接输出NPU可用的YUV格式，省掉CPU侧的颜色空间转换。RV1103的ISP支持输出NV12，NPU推理接口可以接收这种格式并自行处理，省了CPU时间。第二，将图像缩放在ISP里做，让硬件缩放器代替CPU的resize。ISP的缩放虽然支持有限倍率，但配合中心裁剪，恰好能覆盖224×224这个常见输入尺寸。第三，把分类的后处理从Python下沉到C++，在采集线程结束后的空闲时间里计算，避开了与编码线程的资源竞争。

这些调优综合下来，端到端延迟从“采集+推理+后处理”的约68ms降到了约52ms，占比提升明显。但要注意，其中很大一部分收益来自ISP硬件缩放和NV12格式，并不只是NPU本身变快了。

7. 这套部署方案在真实项目中怎么用

7.1 典型场景拆解：智能门铃的人形/宠物分类、园区摄像头的事件分级

RV1103常见于电池供电的门铃、猫眼、低功耗相机。这些设备算力预算非常有限，但需要做基础的事件判断。比如门铃触发PIR后，摄像头抓拍一帧，NPU跑一次分类模型，判断画面中是人、宠物还是车辆，然后决定是否推送告警。这个场景只需要单帧识别，不需要连续30fps的检测，因此MobileNetV3-Small的29ms单帧耗时完全够用，而且功耗更低、内存占用更小。

园区摄像头场景监控范围大、场景复杂，分类模型需要对多类目标做分级告警。此时可以将MobileNetV2作为骨架，因为它的精度略优于V3-Small，实测内存增量也只有8.6MB，对IPC的整体稳定性影响很小。若涉及的人形/非人形二分类，可以考虑用模型二分类替代多分类，进一步简化任务，提升准确率。

7.2 三种模型组合策略：一个芯片跑多个分类任务的资源分配

RV1103上有时需要部署多个分类模型，比如一个检测动物、一个检测包裹、一个检测人脸。我的建议是优先选择一个体积最小的通用模型做主骨架，再针对不同任务做fine-tune，而不是同时加载多个独立模型。原因很简单，RV1103的内存运行增量很小，每个模型少说也要8MB左右，多模型同时驻留很容易触发内存瓶颈。

另外可以考虑“级联架构”：先用一个高召回、低精度的轻量模型做第一级粗筛，只有粗筛命中时才加载更精细的模型做二次确认。例如先用MobileNetV3-Small判断“有无人形”，当置信度落在0.3~0.8之间时，再临时加载MobileNetV2或PP-LCNet做一次细分类。这样平均每次事件只用一次小模型推理，既省电又减少内存常驻占用。RKNN模型支持动态加载和卸载，虽然加载过程有几十毫秒延迟，但对非连续识别场景完全可以接受。

7.3 精度补偿方案：蒸馏、微调与阈值校准

当量化后的精度达不到业务要求时，首选补救手段不是换模型，而是做量化感知训练或蒸馏。用未量化精度更优的大模型（比如在PC端训练的EfficientNet-B0）作为teacher，量化易损的轻量模型作为student，蒸馏后学生模型的Top-1精度通常能拉升1到2个百分点，这在分类任务中很可能直接从“不可用”跨到“可用”区间。数据上要用真实业务数据微调最后几层全连接层，比在通用数据集上训练更贴合场景。

阈值校准是个经常被忽略但极其有效的招术。默认分类阈值0.5并不一定匹配实际类别的先验概率。通过在验证集上调整每个类别的判断阈值，可以降低误报率，减少误触发带来的客户投诉。我在门铃场景里，把“人形”类别的阈值从0.5拉到0.7之后，误报率下降了接近40%，代价是召回率略微降低，但对告警推送类产品，低误报优先级更高。

7.4 长期稳定运行观察：温升、掉帧和NPU占用率

我连续跑了12小时压力测试，监测NPU占用率、内存峰值、CPU负载和外壳温度。MobileNetV2每100ms推理一次，整体NPU占用率约18%，CPU占用率约9%，内存增量稳定在8.6MB附近，长时间运行无异常。MobileNetV3-Small的占用率更低，约12%。这两个模型都比较适合7×24小时运行。

但EfficientNet-Lite0连续跑2小时后，内存增量从14.2MB逐渐涨到16.7MB，怀疑是板端运行时在某些层上触发了碎片化分配。虽然没有崩溃，但对长期稳定性有隐患，所以工业级产品我不太推荐使用这类模型。

7.5 后续扩展方向：从分类到检测、分割的演进成本

RV1103的算力虽然有限，但分类模型跑通后，向检测和分割扩展并不是不可行。检测模型如TinyYOLO、NanoDet、PicoDet都有轻量版本，经过INT8量化后也有机会在RV1103上达到可用的帧率。分割任务可以使用轻量分割网络如ESPNetv2或SegNet的裁剪版本，但这通常会把RV1103的NPU负载推到很高，需要更谨慎的资源规划。

我的建议是，先把分类任务在RV1103上做到极致稳定，跑通数据采集、标注、训练、量化、板端验证的完整闭环，再逐步扩展检测和分割。这个过程中积累的预处理、校准、性能测量方法，在检测和分割任务上几乎可以复用，边际成本会低很多。

最后说点我自己的体会。RV1103这个平台的定位不是“跑分漂亮”，而是“够用且便宜”。跑分类模型最忌讳的，就是照搬服务器端的选型思路拿一个看起来精度高的模型硬塞进去。MobileNetV3-Small这类模型在标称算力上有优势，但真实收益要结合你的业务场景来判断；MobileNetV2和MobileNetV1虽然在速度上略慢，但算子兼容性极佳、量化稳定性高，作为生产基线是更安心的选择。另外，硬件设计阶段一定要把ISP输出格式、内存带宽和NPU访问路径考虑进去，软件部署再秀也补不了硬件层面的资源浪费。希望这篇实测记录对你有实际帮助。