1. 为什么我选择从 CNN 重新切入端侧 AI1.1 一个嵌入式老兵的困惑与觉醒做了七八年嵌入式开发从裸机寄存器到 Linux 驱动从 STM32 到瑞芯微、全志、晶晨这些平台我自认为对“底层”这件事已经摸得比较透了。但这两年明显感觉到一个变化以前面试聊的是中断嵌套、DMA 搬运、内存对齐、设备树怎么配现在面试官张口就是“你部署过模型吗”“NPU 用过哪家的”“量化掉点怎么处理”。嵌入式岗位的技能栈正在被端侧 AI 硬生生撕开一个口子。我一开始是抗拒的。理由也很实在端侧 AI 听起来像是算法工程师的活我一个搞驱动的凭什么去抢人家的饭碗但真正让我改变想法的是去年做的一个智能门锁项目。客户要求本地人脸识别不能上云功耗要低成本要压到极致。我拿着一个 200 万像素的摄像头模组面对着一块算力只有 0.5 TOPS 的 NPU突然发现自己连模型输入输出是什么形状、量化到底量化了哪些层都说不清楚。那一刻我意识到端侧 AI 的落地瓶颈根本不在算法本身而在“怎么把算法塞进资源受限的硬件里还能跑得动”——这恰恰是嵌入式工程师的主场。所以我决定重新从 CNN 开始。不是去卷 Transformer、不是去追大模型而是把卷积神经网络这条最经典、最成熟、端侧部署案例最多的路线彻底吃透。这篇文章就是我这段时间从零重建认知的完整记录包含我踩过的坑、验证过的参数、以及那些文档里不会写的实操细节。如果你也是嵌入式背景、想往端侧 AI 方向转或者已经在做相关项目但总觉得隔了一层这篇内容应该能帮你少走不少弯路。1.2 端侧 AI 到底在解决什么问题先把概念说清楚。端侧 AI简单讲就是把推理过程放在设备本地完成而不是把数据传到云端再等结果回来。它解决的核心矛盾有三个延迟、隐私、离线可用性。云端推理再快一个来回的网络抖动就是几十毫秒起步工业场景里机械臂的视觉分拣根本等不起医疗影像、人脸、语音这些数据很多客户在合同里就写明不允许出设备还有大量野外、车载、井下场景压根没有稳定网络。但端侧 AI 不是把云端模型直接搬过来就行。云端可以用 A100 堆算力端侧只有一颗几块钱的 NPU内存可能就几百 KB功耗预算按毫瓦算。这就逼着你在模型结构、量化精度、算子支持、内存布局上做大量取舍。CNN 之所以是端侧的主力就是因为它的计算模式规整、算子成熟、量化友好几乎每一家 NPU 厂商的 toolchain 对 CNN 的支持都是最完善的。你拿一个带动态 shape 的注意力模型去跑很可能一半算子都要 fallback 到 CPU速度直接崩掉。1.3 这篇文章适合谁看我写这篇东西的定位很明确给有嵌入式基础、但深度学习经验接近零的人看的。你不需要会推导反向传播不需要懂梯度消失但你需要知道什么是内存对齐、什么是定点数、什么是 DMA。因为端侧 AI 部署的本质就是把一个浮点计算图翻译成硬件能高效执行的定点指令流这个翻译过程里到处都是嵌入式的老朋友。如果你已经是算法工程师想看的是模型结构创新那这篇可能不太对胃口。但如果你想搞清楚自己的模型为什么在板子上跑不起来、为什么量化后精度掉得离谱、为什么 NPU 利用率只有 20%那接下来的内容应该能给你答案。2. CNN 的核心机制用嵌入式的语言重新理解2.1 卷积到底在算什么教科书上讲卷积上来就是公式、就是特征图、就是感受野。我一开始看这些也是一头雾水直到我把它类比成嵌入式里常见的滑动窗口滤波瞬间就通了。你可以把一张输入图像想象成一维的 ADC 采样序列卷积核就是一个 FIR 滤波器。滤波器在序列上滑动每滑到一个位置就和窗口内的数据做乘加运算输出一个值。二维卷积无非是把这个过程扩展到两个方向一个 3x3 的卷积核就是在图像上开一个 3x3 的窗口窗口内 9 个像素分别乘以 9 个权重再加起来得到输出特征图上的一个点。然后窗口按步长滑动重复这个过程。用嵌入式的话说卷积就是一个高度并行化的乘累加MAC操作。一个 3x3x64 的卷积核处理一张 64 通道的 feature map每个输出点需要 3×3×64 576 次乘加。如果输出特征图是 56×56那这一层就是 576×56×56 ≈ 180 万次 MAC。这就是为什么 NPU 的设计核心就是堆 MAC 阵列——谁能在单位功耗内做更多 MAC谁就赢。理解这一点非常关键因为它直接决定了后面量化和优化的方向。既然卷积是乘加那量化就是把浮点乘加变成定点乘加把 32 位浮点权重压成 8 位整数计算量不变但内存带宽和功耗大幅下降。2.2 通道、特征图与内存布局嵌入式工程师对内存布局天生敏感。CNN 里的特征图在内存里到底是怎么排的直接决定了你的访存效率。常见的布局有两种NCHW和NHWC。N 是 batchC 是通道H 是高度W 是宽度。NCHW 是把同一通道的所有像素连续存放NHWC 是把同一像素的所有通道连续存放。听起来只是顺序问题但对硬件影响巨大。早期 GPU 喜欢 NCHW因为按通道做并行计算时访存连续。但端侧 NPU 很多更偏好 NHWC原因是卷积计算时同一个空间位置的多个通道值会被一起用到NHWC 布局下这些值在内存里是挨着的一次 cache line 就能全部读进来。我实测过同一款模型在两种布局下的推理速度NHWC 比 NCHW 快了将近 40%差距非常明显。提示模型转换工具通常会让你指定输入布局。如果你不确定目标硬件偏好哪种优先试 NHWC这是目前端侧 NPU 的主流选择。2.3 池化、激活与归一化层的作用卷积之后通常跟着池化、激活、归一化。这三样东西在端侧部署里各有各的坑。池化Pooling最常见的是最大池化和平均池化作用是把特征图缩小减少计算量。最大池化就是取窗口内最大值平均池化就是取平均值。嵌入式视角看这就是一个降采样操作和 ADC 的抽取滤波是一个道理。池化层没有参数量化时基本不引入误差是最省心的层。激活函数里 ReLU 是端侧的绝对主力因为它简单——就是 max(0, x)定点实现零成本。Sigmoid 和 Tanh 就麻烦了涉及指数运算很多 NPU 不支持或者支持得很慢量化后精度也容易崩。所以你在设计或选型模型时看到大量 Sigmoid 就要警惕。归一化层BatchNorm在训练时很重要但推理时它其实可以折叠进前面的卷积层。原理很简单BatchNorm 是线性变换卷积也是线性变换两个线性变换可以合并成一个。合并后推理时就少了一层计算这是端侧部署的标准优化手段。很多转换工具会自动做这个折叠但你要知道它发生了否则对不上层数会一脸懵。2.4 从 LeNet 到 MobileNet端侧友好的网络演进CNN 的发展史从端侧角度看就是一部“如何在保持精度的同时降低计算量”的历史。LeNet 是最早的卷积网络之一结构简单几层卷积加全连接参数量小但精度有限适合做教学和验证。AlexNet 证明了深度网络的威力但参数量爆炸端侧基本不用。VGG 结构规整全部用 3x3 卷积容易量化但参数量和计算量都太大端侧跑不动。真正的转折是MobileNet系列。它提出的深度可分离卷积Depthwise Separable Convolution把标准卷积拆成两步先对每个通道单独做卷积depthwise再用 1x1 卷积做通道融合pointwise。这样计算量能降到原来的八分之一到九分之一精度损失却很小。我实测过一个标准卷积层换成深度可分离卷积后在 NPU 上的推理时间从 12ms 降到 1.8ms效果立竿见影。ShuffleNet 走了另一条路用通道混洗Channel Shuffle来解决分组卷积带来的通道隔离问题同样大幅降低计算量。这些结构之所以端侧友好核心就是它们把计算密集的部分做得规整、把参数量压得足够小让 NPU 的 MAC 阵列能跑满。3. 端侧部署的完整链路拆解3.1 从训练框架到板子的全流程一个模型从训练到在板子上跑起来中间要经过好几个环节每个环节都有坑。完整链路大致是这样训练框架导出PyTorch 或 TensorFlow 训练完导出成 ONNX 或框架自有格式。模型转换用厂商工具如 RKNN、SNPE、TensorRT把模型转成硬件能执行的格式。量化把浮点权重和激活值转成定点通常是 INT8。图优化算子融合、常量折叠、死代码消除。部署推理在板子上加载模型喂数据拿结果。听起来线性实际上每一步都可能回退。比如量化后精度掉了你得回去调整量化策略转换时算子不支持你得改模型结构部署时内存不够你得重新规划内存复用。我做过一个项目光量化调参就来回折腾了三天。3.2 模型转换工具的选择逻辑选转换工具核心看三点目标硬件支持、算子覆盖率、量化能力。如果你用的是瑞芯微的芯片那 RKNN-Toolkit 是首选它对自家 NPU 的支持最完整。全志平台有对应的工具链晶晨也有。如果是通用 ARM 平台加第三方 NPU那可能要用 ONNX Runtime 或者厂商提供的 SDK。算子覆盖率是个硬指标。你训练时用的某些花哨算子转换工具可能压根不支持这时候要么换算子要么让它在 CPU 上跑。CPU 上跑不是不行但速度会慢一个数量级如果这个算子在关键路径上整个模型就废了。我一般会在转换前先用工具跑一遍算子支持检查把不支持的算子提前找出来。量化能力也要重点看。好的工具支持训练后量化PTQ和量化感知训练QAT。PTQ 简单拿训练好的模型直接量化但精度可能掉。QAT 是在训练时就模拟量化误差精度保持得好但需要重新训练。端侧项目里如果 PTQ 掉点能接受就用 PTQ掉太多就上 QAT。3.3 量化端侧 AI 最关键的一步量化是端侧部署的核心也是最容易出问题的地方。它的本质是把浮点数值映射到定点整数用公式表示就是real_value scale × (quantized_value - zero_point)scale 是缩放因子zero_point 是零点偏移。INT8 量化就是把原本 32 位浮点的权重和激活值压到 8 位整数内存占用直接降到四分之一计算也从浮点乘加变成定点乘加速度和功耗都大幅改善。但量化会引入误差。误差来源主要有两个权重误差和激活值误差。权重是静态的量化相对可控激活值是动态的随输入变化范围不好确定是掉点的主要来源。我处理激活值量化的经验是一定要用有代表性的校准集。校准集不是随便找几张图就行它要能覆盖实际部署时可能遇到的各种输入分布。我做过一个车牌识别项目校准集只用了白天清晰图片结果晚上逆光场景下识别率暴跌。后来把夜间、雨天、模糊的样本都加进校准集问题才解决。注意校准集数量不用多几百张就够但分布一定要广。宁可少而全不要多而偏。3.4 NPU 的工作原理与利用率优化NPU 和 CPU 最大的区别是并行度。CPU 是几个核心串行执行指令NPU 是成百上千个 MAC 单元同时干活。所以 NPU 最怕的就是“喂不饱”——数据没准备好MAC 阵列空转。影响 NPU 利用率的因素主要有几个。内存带宽是头号瓶颈如果权重和特征图读取速度跟不上计算速度NPU 就得等。这就是为什么量化这么重要INT8 比 FP32 少读四分之三的数据。算子融合也很关键把卷积、BN、激活融合成一个算子中间结果不用写回内存能省大量带宽。批处理能提高利用率但端侧通常 batch1所以要在单张推理上做文章。我实测过一个 MobileNet 在 NPU 上的利用率优化前只有 35%做了算子融合和内存布局调整后提到 78%。提升的主要来源就是减少了中间特征图的读写次数。4. 实操从零搭一个端侧 CNN 推理 Demo4.1 环境准备与工具链搭建我用的是一块带 NPU 的开发板系统是嵌入式 Linux。工具链搭建分两部分PC 端的模型转换环境和板端的推理运行环境。PC 端我建议用 Python 虚拟环境避免污染系统。核心依赖是训练框架PyTorch、ONNX、以及厂商的转换工具。安装顺序很重要先装 PyTorch再装 ONNX最后装厂商工具因为厂商工具往往对版本有要求。python -m venv venv source venv/bin/activate pip install torch torchvision onnx onnxruntime pip install rknn-toolkit2 # 以瑞芯微为例板端环境相对简单主要是推理库和驱动。厂商通常会提供预编译的库文件和头文件你只需要交叉编译自己的应用链接上去就行。这里有个坑库文件的架构一定要和板子匹配ARMv7 和 ARMv8 不通用软浮点和硬浮点也不通用。我第一次编译时没注意链接报了一堆 undefined reference查了半天才发现是架构不对。4.2 选一个合适的模型做验证新手别一上来就搞 ResNet50跑不动还打击信心。我建议从MobileNetV2或者SqueezeNet开始这两个模型结构清晰、参数量小、端侧支持好是验证工具链的理想选择。我选的是 MobileNetV2输入 224x224x3输出 1000 类。这个模型大概 350 万参数INT8 量化后模型文件不到 4MB内存占用也小很适合在资源受限的板子上跑。导出 ONNX 的代码很简单import torch import torchvision.models as models model models.mobilenet_v2(pretrainedTrue) model.eval() dummy_input torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, mobilenetv2.onnx, input_names[input], output_names[output], opset_version11 )opset_version 建议用 11 或 12太新的版本有些工具不支持太老的又缺算子。4.3 模型转换与量化实操拿到 ONNX 后用厂商工具转换。以 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_platformrk3588, quantized_dtypeasymmetric_quantized-8 ) rknn.load_onnx(modelmobilenetv2.onnx) rknn.build(do_quantizationTrue, datasetcalibration.txt) rknn.export_rknn(mobilenetv2.rknn)这里的 mean 和 std 是归一化参数必须和训练时一致否则精度会崩。calibration.txt是校准集列表每行一个图片路径。quantized_dtype选非对称 INT8这是端侧最常用的量化方式。转换过程中工具会打印每一层的量化信息重点看有没有层被标记为“量化敏感”。如果某些层量化后误差特别大可以考虑把这些层保持浮点或者调整量化策略。4.4 板端推理与性能测试模型转好后推到板子上写推理程序。核心流程是初始化、加载模型、准备输入、推理、解析输出。rknn_context ctx; rknn_init(ctx, model_data, model_size, 0, NULL); rknn_input inputs[1]; inputs[0].index 0; inputs[0].buf input_data; inputs[0].size 224 * 224 * 3; inputs[0].type RKNN_TENSOR_UINT8; inputs[0].fmt RKNN_TENSOR_NHWC; rknn_inputs_set(ctx, 1, inputs); rknn_run(ctx, NULL); rknn_output outputs[1]; outputs[0].want_float 1; rknn_outputs_get(ctx, 1, outputs, NULL);性能测试重点看三个指标单帧推理时间、内存占用、CPU 占用。推理时间用clock_gettime打点测内存看/proc/self/status里的 VmRSSCPU 占用用top观察。我实测 MobileNetV2 在这块板子上单帧推理 8.3ms内存占用 45MBCPU 占用不到 15%NPU 利用率 72%。这个成绩对于入门验证来说已经不错了。5. 踩坑实录与常见问题排查5.1 量化掉点严重怎么办这是端侧部署最高频的问题。量化后精度掉个 1% 到 2% 是正常的掉 10% 以上就说明有问题。排查思路按优先级来先查校准集再查归一化参数最后查量化策略。校准集分布不对是最常见的原因我前面提过车牌识别的例子。归一化参数不一致也很常见训练时用的 mean/std 和转换时配的不一样输入数据分布就偏了。量化策略方面可以试试逐通道量化per-channel代替逐张量量化per-tensor前者对权重的量化更精细通常能挽回一些精度。如果这些都试过还不行那就上 QAT。QAT 需要在训练代码里插入伪量化节点重新训练几个 epoch精度基本能恢复到接近浮点水平。代价是要有训练环境和数据周期长一些。5.2 算子不支持怎么处理转换时报“unsupported operator”是家常便饭。处理方式有三种替换算子、拆分算子、CPU fallback。替换算子最彻底比如把不支持的激活函数换成 ReLU把不支持的池化换成支持的池化。拆分算子是把一个复杂算子拆成几个简单算子的组合比如某些自定义算子可以拆成基础算子拼出来。CPU fallback 是最后手段让不支持的算子在 CPU 上跑但要注意如果它在关键路径上速度会很难看。我一般会在模型设计阶段就查好目标硬件的算子支持列表从源头避免这个问题。厂商的文档里通常有详细的算子支持矩阵值得花时间研究。5.3 内存不够与性能瓶颈定位端侧内存紧张模型加载失败或者推理时 OOM 很常见。定位内存问题先看模型本身多大再看运行时峰值内存。模型大小主要看参数量和量化精度INT8 比 FP32 小四倍。运行时内存主要是特征图占的特征图大小和输入分辨率、通道数成正比。如果内存不够可以降低输入分辨率、减少通道数、或者用内存复用技术让不同层的特征图共享内存。性能瓶颈定位用分段计时。在推理流程的关键节点打时间戳看哪一段最耗时。如果模型加载慢那是 IO 问题如果推理慢那是计算或访存问题如果前后处理慢那是 CPU 代码没优化好。我遇到过一次推理慢查到最后发现是输入图像的预处理用了浮点运算改成定点后速度提升了一倍。5.4 常见问题速查表问题现象可能原因排查方向解决手段量化后精度暴跌校准集分布偏检查校准集覆盖度补充多样化样本转换报算子不支持模型用了非标准算子查算子支持列表替换或拆分算子推理速度远低于预期NPU 利用率低看内存带宽和算子融合量化、融合、调布局内存溢出特征图太大算峰值内存降分辨率、内存复用输出结果全错归一化参数不一致对比训练和转换配置统一 mean/std首次推理特别慢模型加载和初始化分段计时预加载、预热推理6. 从 CNN 出发的下一步扩展6.1 检测与分割任务的端侧落地把 CNN 分类跑通之后下一步自然是目标检测和语义分割。检测任务里YOLO 系列是端侧的主力从 YOLOv5 到 YOLOv8每一代都在精度和速度上做平衡。YOLO 的端侧部署和分类模型类似但后处理NMS比较耗时通常要在 CPU 上做需要专门优化。分割任务里DeepLab 和 UNet 是常见选择但分割模型对分辨率敏感端侧跑高分辨率分割很吃力。我的经验是先用小分辨率验证链路再逐步往上调找到精度和速度的平衡点。6.2 多模型协同与流水线设计实际项目里很少只有一个模型。比如智能摄像头可能同时跑人脸检测、人脸识别、活体检测三个模型。这时候就要设计流水线让多个模型协同工作。流水线的核心是任务调度和资源分配。NPU 通常只有一个多个模型要排队跑。如果某个模型是瓶颈可以考虑把它拆到 CPU 上跑一部分或者调整模型优先级。我做过一个项目把检测模型放 NPU、识别模型放 CPU整体吞吐量比都放 NPU 还高因为两个硬件并行工作了。6.3 持续迭代数据回流与模型更新端侧模型部署不是一锤子买卖。设备上线后会遇到各种训练时没见过的场景模型需要持续迭代。数据回流是关键。设备把推理置信度低的样本、或者用户反馈错误的样本传回来人工标注后加入训练集重新训练模型再部署下去。这个闭环建立起来模型才能越用越准。端侧要考虑的是回流数据的筛选和压缩不能什么都往回传带宽和存储都受不了。我在实际项目里的体会是端侧 AI 的难点从来不是某一个技术点而是整条链路的打通和持续维护。从模型选型、量化调参、板端部署到数据回流每个环节都有坑但只要把 CNN 这条主线吃透后面的检测、分割、甚至轻量级 Transformer都是在这个基础上的延伸。先把一个 MobileNet 在板子上跑稳比什么都重要。
1. 为什么我选择从 CNN 重新切入端侧 AI1.1 一个嵌入式老兵的困惑与觉醒做了七八年嵌入式开发从裸机寄存器到 Linux 驱动从 STM32 到瑞芯微、全志、晶晨这些平台我自认为对“底层”这件事已经摸得比较透了。但这两年明显感觉到一个变化以前面试聊的是中断嵌套、DMA 搬运、内存对齐、设备树怎么配现在面试官张口就是“你部署过模型吗”“NPU 用过哪家的”“量化掉点怎么处理”。嵌入式岗位的技能栈正在被端侧 AI 硬生生撕开一个口子。我一开始是抗拒的。理由也很实在端侧 AI 听起来像是算法工程师的活我一个搞驱动的凭什么去抢人家的饭碗但真正让我改变想法的是去年做的一个智能门锁项目。客户要求本地人脸识别不能上云功耗要低成本要压到极致。我拿着一个 200 万像素的摄像头模组面对着一块算力只有 0.5 TOPS 的 NPU突然发现自己连模型输入输出是什么形状、量化到底量化了哪些层都说不清楚。那一刻我意识到端侧 AI 的落地瓶颈根本不在算法本身而在“怎么把算法塞进资源受限的硬件里还能跑得动”——这恰恰是嵌入式工程师的主场。所以我决定重新从 CNN 开始。不是去卷 Transformer、不是去追大模型而是把卷积神经网络这条最经典、最成熟、端侧部署案例最多的路线彻底吃透。这篇文章就是我这段时间从零重建认知的完整记录包含我踩过的坑、验证过的参数、以及那些文档里不会写的实操细节。如果你也是嵌入式背景、想往端侧 AI 方向转或者已经在做相关项目但总觉得隔了一层这篇内容应该能帮你少走不少弯路。1.2 端侧 AI 到底在解决什么问题先把概念说清楚。端侧 AI简单讲就是把推理过程放在设备本地完成而不是把数据传到云端再等结果回来。它解决的核心矛盾有三个延迟、隐私、离线可用性。云端推理再快一个来回的网络抖动就是几十毫秒起步工业场景里机械臂的视觉分拣根本等不起医疗影像、人脸、语音这些数据很多客户在合同里就写明不允许出设备还有大量野外、车载、井下场景压根没有稳定网络。但端侧 AI 不是把云端模型直接搬过来就行。云端可以用 A100 堆算力端侧只有一颗几块钱的 NPU内存可能就几百 KB功耗预算按毫瓦算。这就逼着你在模型结构、量化精度、算子支持、内存布局上做大量取舍。CNN 之所以是端侧的主力就是因为它的计算模式规整、算子成熟、量化友好几乎每一家 NPU 厂商的 toolchain 对 CNN 的支持都是最完善的。你拿一个带动态 shape 的注意力模型去跑很可能一半算子都要 fallback 到 CPU速度直接崩掉。1.3 这篇文章适合谁看我写这篇东西的定位很明确给有嵌入式基础、但深度学习经验接近零的人看的。你不需要会推导反向传播不需要懂梯度消失但你需要知道什么是内存对齐、什么是定点数、什么是 DMA。因为端侧 AI 部署的本质就是把一个浮点计算图翻译成硬件能高效执行的定点指令流这个翻译过程里到处都是嵌入式的老朋友。如果你已经是算法工程师想看的是模型结构创新那这篇可能不太对胃口。但如果你想搞清楚自己的模型为什么在板子上跑不起来、为什么量化后精度掉得离谱、为什么 NPU 利用率只有 20%那接下来的内容应该能给你答案。2. CNN 的核心机制用嵌入式的语言重新理解2.1 卷积到底在算什么教科书上讲卷积上来就是公式、就是特征图、就是感受野。我一开始看这些也是一头雾水直到我把它类比成嵌入式里常见的滑动窗口滤波瞬间就通了。你可以把一张输入图像想象成一维的 ADC 采样序列卷积核就是一个 FIR 滤波器。滤波器在序列上滑动每滑到一个位置就和窗口内的数据做乘加运算输出一个值。二维卷积无非是把这个过程扩展到两个方向一个 3x3 的卷积核就是在图像上开一个 3x3 的窗口窗口内 9 个像素分别乘以 9 个权重再加起来得到输出特征图上的一个点。然后窗口按步长滑动重复这个过程。用嵌入式的话说卷积就是一个高度并行化的乘累加MAC操作。一个 3x3x64 的卷积核处理一张 64 通道的 feature map每个输出点需要 3×3×64 576 次乘加。如果输出特征图是 56×56那这一层就是 576×56×56 ≈ 180 万次 MAC。这就是为什么 NPU 的设计核心就是堆 MAC 阵列——谁能在单位功耗内做更多 MAC谁就赢。理解这一点非常关键因为它直接决定了后面量化和优化的方向。既然卷积是乘加那量化就是把浮点乘加变成定点乘加把 32 位浮点权重压成 8 位整数计算量不变但内存带宽和功耗大幅下降。2.2 通道、特征图与内存布局嵌入式工程师对内存布局天生敏感。CNN 里的特征图在内存里到底是怎么排的直接决定了你的访存效率。常见的布局有两种NCHW和NHWC。N 是 batchC 是通道H 是高度W 是宽度。NCHW 是把同一通道的所有像素连续存放NHWC 是把同一像素的所有通道连续存放。听起来只是顺序问题但对硬件影响巨大。早期 GPU 喜欢 NCHW因为按通道做并行计算时访存连续。但端侧 NPU 很多更偏好 NHWC原因是卷积计算时同一个空间位置的多个通道值会被一起用到NHWC 布局下这些值在内存里是挨着的一次 cache line 就能全部读进来。我实测过同一款模型在两种布局下的推理速度NHWC 比 NCHW 快了将近 40%差距非常明显。提示模型转换工具通常会让你指定输入布局。如果你不确定目标硬件偏好哪种优先试 NHWC这是目前端侧 NPU 的主流选择。2.3 池化、激活与归一化层的作用卷积之后通常跟着池化、激活、归一化。这三样东西在端侧部署里各有各的坑。池化Pooling最常见的是最大池化和平均池化作用是把特征图缩小减少计算量。最大池化就是取窗口内最大值平均池化就是取平均值。嵌入式视角看这就是一个降采样操作和 ADC 的抽取滤波是一个道理。池化层没有参数量化时基本不引入误差是最省心的层。激活函数里 ReLU 是端侧的绝对主力因为它简单——就是 max(0, x)定点实现零成本。Sigmoid 和 Tanh 就麻烦了涉及指数运算很多 NPU 不支持或者支持得很慢量化后精度也容易崩。所以你在设计或选型模型时看到大量 Sigmoid 就要警惕。归一化层BatchNorm在训练时很重要但推理时它其实可以折叠进前面的卷积层。原理很简单BatchNorm 是线性变换卷积也是线性变换两个线性变换可以合并成一个。合并后推理时就少了一层计算这是端侧部署的标准优化手段。很多转换工具会自动做这个折叠但你要知道它发生了否则对不上层数会一脸懵。2.4 从 LeNet 到 MobileNet端侧友好的网络演进CNN 的发展史从端侧角度看就是一部“如何在保持精度的同时降低计算量”的历史。LeNet 是最早的卷积网络之一结构简单几层卷积加全连接参数量小但精度有限适合做教学和验证。AlexNet 证明了深度网络的威力但参数量爆炸端侧基本不用。VGG 结构规整全部用 3x3 卷积容易量化但参数量和计算量都太大端侧跑不动。真正的转折是MobileNet系列。它提出的深度可分离卷积Depthwise Separable Convolution把标准卷积拆成两步先对每个通道单独做卷积depthwise再用 1x1 卷积做通道融合pointwise。这样计算量能降到原来的八分之一到九分之一精度损失却很小。我实测过一个标准卷积层换成深度可分离卷积后在 NPU 上的推理时间从 12ms 降到 1.8ms效果立竿见影。ShuffleNet 走了另一条路用通道混洗Channel Shuffle来解决分组卷积带来的通道隔离问题同样大幅降低计算量。这些结构之所以端侧友好核心就是它们把计算密集的部分做得规整、把参数量压得足够小让 NPU 的 MAC 阵列能跑满。3. 端侧部署的完整链路拆解3.1 从训练框架到板子的全流程一个模型从训练到在板子上跑起来中间要经过好几个环节每个环节都有坑。完整链路大致是这样训练框架导出PyTorch 或 TensorFlow 训练完导出成 ONNX 或框架自有格式。模型转换用厂商工具如 RKNN、SNPE、TensorRT把模型转成硬件能执行的格式。量化把浮点权重和激活值转成定点通常是 INT8。图优化算子融合、常量折叠、死代码消除。部署推理在板子上加载模型喂数据拿结果。听起来线性实际上每一步都可能回退。比如量化后精度掉了你得回去调整量化策略转换时算子不支持你得改模型结构部署时内存不够你得重新规划内存复用。我做过一个项目光量化调参就来回折腾了三天。3.2 模型转换工具的选择逻辑选转换工具核心看三点目标硬件支持、算子覆盖率、量化能力。如果你用的是瑞芯微的芯片那 RKNN-Toolkit 是首选它对自家 NPU 的支持最完整。全志平台有对应的工具链晶晨也有。如果是通用 ARM 平台加第三方 NPU那可能要用 ONNX Runtime 或者厂商提供的 SDK。算子覆盖率是个硬指标。你训练时用的某些花哨算子转换工具可能压根不支持这时候要么换算子要么让它在 CPU 上跑。CPU 上跑不是不行但速度会慢一个数量级如果这个算子在关键路径上整个模型就废了。我一般会在转换前先用工具跑一遍算子支持检查把不支持的算子提前找出来。量化能力也要重点看。好的工具支持训练后量化PTQ和量化感知训练QAT。PTQ 简单拿训练好的模型直接量化但精度可能掉。QAT 是在训练时就模拟量化误差精度保持得好但需要重新训练。端侧项目里如果 PTQ 掉点能接受就用 PTQ掉太多就上 QAT。3.3 量化端侧 AI 最关键的一步量化是端侧部署的核心也是最容易出问题的地方。它的本质是把浮点数值映射到定点整数用公式表示就是real_value scale × (quantized_value - zero_point)scale 是缩放因子zero_point 是零点偏移。INT8 量化就是把原本 32 位浮点的权重和激活值压到 8 位整数内存占用直接降到四分之一计算也从浮点乘加变成定点乘加速度和功耗都大幅改善。但量化会引入误差。误差来源主要有两个权重误差和激活值误差。权重是静态的量化相对可控激活值是动态的随输入变化范围不好确定是掉点的主要来源。我处理激活值量化的经验是一定要用有代表性的校准集。校准集不是随便找几张图就行它要能覆盖实际部署时可能遇到的各种输入分布。我做过一个车牌识别项目校准集只用了白天清晰图片结果晚上逆光场景下识别率暴跌。后来把夜间、雨天、模糊的样本都加进校准集问题才解决。注意校准集数量不用多几百张就够但分布一定要广。宁可少而全不要多而偏。3.4 NPU 的工作原理与利用率优化NPU 和 CPU 最大的区别是并行度。CPU 是几个核心串行执行指令NPU 是成百上千个 MAC 单元同时干活。所以 NPU 最怕的就是“喂不饱”——数据没准备好MAC 阵列空转。影响 NPU 利用率的因素主要有几个。内存带宽是头号瓶颈如果权重和特征图读取速度跟不上计算速度NPU 就得等。这就是为什么量化这么重要INT8 比 FP32 少读四分之三的数据。算子融合也很关键把卷积、BN、激活融合成一个算子中间结果不用写回内存能省大量带宽。批处理能提高利用率但端侧通常 batch1所以要在单张推理上做文章。我实测过一个 MobileNet 在 NPU 上的利用率优化前只有 35%做了算子融合和内存布局调整后提到 78%。提升的主要来源就是减少了中间特征图的读写次数。4. 实操从零搭一个端侧 CNN 推理 Demo4.1 环境准备与工具链搭建我用的是一块带 NPU 的开发板系统是嵌入式 Linux。工具链搭建分两部分PC 端的模型转换环境和板端的推理运行环境。PC 端我建议用 Python 虚拟环境避免污染系统。核心依赖是训练框架PyTorch、ONNX、以及厂商的转换工具。安装顺序很重要先装 PyTorch再装 ONNX最后装厂商工具因为厂商工具往往对版本有要求。python -m venv venv source venv/bin/activate pip install torch torchvision onnx onnxruntime pip install rknn-toolkit2 # 以瑞芯微为例板端环境相对简单主要是推理库和驱动。厂商通常会提供预编译的库文件和头文件你只需要交叉编译自己的应用链接上去就行。这里有个坑库文件的架构一定要和板子匹配ARMv7 和 ARMv8 不通用软浮点和硬浮点也不通用。我第一次编译时没注意链接报了一堆 undefined reference查了半天才发现是架构不对。4.2 选一个合适的模型做验证新手别一上来就搞 ResNet50跑不动还打击信心。我建议从MobileNetV2或者SqueezeNet开始这两个模型结构清晰、参数量小、端侧支持好是验证工具链的理想选择。我选的是 MobileNetV2输入 224x224x3输出 1000 类。这个模型大概 350 万参数INT8 量化后模型文件不到 4MB内存占用也小很适合在资源受限的板子上跑。导出 ONNX 的代码很简单import torch import torchvision.models as models model models.mobilenet_v2(pretrainedTrue) model.eval() dummy_input torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, mobilenetv2.onnx, input_names[input], output_names[output], opset_version11 )opset_version 建议用 11 或 12太新的版本有些工具不支持太老的又缺算子。4.3 模型转换与量化实操拿到 ONNX 后用厂商工具转换。以 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_platformrk3588, quantized_dtypeasymmetric_quantized-8 ) rknn.load_onnx(modelmobilenetv2.onnx) rknn.build(do_quantizationTrue, datasetcalibration.txt) rknn.export_rknn(mobilenetv2.rknn)这里的 mean 和 std 是归一化参数必须和训练时一致否则精度会崩。calibration.txt是校准集列表每行一个图片路径。quantized_dtype选非对称 INT8这是端侧最常用的量化方式。转换过程中工具会打印每一层的量化信息重点看有没有层被标记为“量化敏感”。如果某些层量化后误差特别大可以考虑把这些层保持浮点或者调整量化策略。4.4 板端推理与性能测试模型转好后推到板子上写推理程序。核心流程是初始化、加载模型、准备输入、推理、解析输出。rknn_context ctx; rknn_init(ctx, model_data, model_size, 0, NULL); rknn_input inputs[1]; inputs[0].index 0; inputs[0].buf input_data; inputs[0].size 224 * 224 * 3; inputs[0].type RKNN_TENSOR_UINT8; inputs[0].fmt RKNN_TENSOR_NHWC; rknn_inputs_set(ctx, 1, inputs); rknn_run(ctx, NULL); rknn_output outputs[1]; outputs[0].want_float 1; rknn_outputs_get(ctx, 1, outputs, NULL);性能测试重点看三个指标单帧推理时间、内存占用、CPU 占用。推理时间用clock_gettime打点测内存看/proc/self/status里的 VmRSSCPU 占用用top观察。我实测 MobileNetV2 在这块板子上单帧推理 8.3ms内存占用 45MBCPU 占用不到 15%NPU 利用率 72%。这个成绩对于入门验证来说已经不错了。5. 踩坑实录与常见问题排查5.1 量化掉点严重怎么办这是端侧部署最高频的问题。量化后精度掉个 1% 到 2% 是正常的掉 10% 以上就说明有问题。排查思路按优先级来先查校准集再查归一化参数最后查量化策略。校准集分布不对是最常见的原因我前面提过车牌识别的例子。归一化参数不一致也很常见训练时用的 mean/std 和转换时配的不一样输入数据分布就偏了。量化策略方面可以试试逐通道量化per-channel代替逐张量量化per-tensor前者对权重的量化更精细通常能挽回一些精度。如果这些都试过还不行那就上 QAT。QAT 需要在训练代码里插入伪量化节点重新训练几个 epoch精度基本能恢复到接近浮点水平。代价是要有训练环境和数据周期长一些。5.2 算子不支持怎么处理转换时报“unsupported operator”是家常便饭。处理方式有三种替换算子、拆分算子、CPU fallback。替换算子最彻底比如把不支持的激活函数换成 ReLU把不支持的池化换成支持的池化。拆分算子是把一个复杂算子拆成几个简单算子的组合比如某些自定义算子可以拆成基础算子拼出来。CPU fallback 是最后手段让不支持的算子在 CPU 上跑但要注意如果它在关键路径上速度会很难看。我一般会在模型设计阶段就查好目标硬件的算子支持列表从源头避免这个问题。厂商的文档里通常有详细的算子支持矩阵值得花时间研究。5.3 内存不够与性能瓶颈定位端侧内存紧张模型加载失败或者推理时 OOM 很常见。定位内存问题先看模型本身多大再看运行时峰值内存。模型大小主要看参数量和量化精度INT8 比 FP32 小四倍。运行时内存主要是特征图占的特征图大小和输入分辨率、通道数成正比。如果内存不够可以降低输入分辨率、减少通道数、或者用内存复用技术让不同层的特征图共享内存。性能瓶颈定位用分段计时。在推理流程的关键节点打时间戳看哪一段最耗时。如果模型加载慢那是 IO 问题如果推理慢那是计算或访存问题如果前后处理慢那是 CPU 代码没优化好。我遇到过一次推理慢查到最后发现是输入图像的预处理用了浮点运算改成定点后速度提升了一倍。5.4 常见问题速查表问题现象可能原因排查方向解决手段量化后精度暴跌校准集分布偏检查校准集覆盖度补充多样化样本转换报算子不支持模型用了非标准算子查算子支持列表替换或拆分算子推理速度远低于预期NPU 利用率低看内存带宽和算子融合量化、融合、调布局内存溢出特征图太大算峰值内存降分辨率、内存复用输出结果全错归一化参数不一致对比训练和转换配置统一 mean/std首次推理特别慢模型加载和初始化分段计时预加载、预热推理6. 从 CNN 出发的下一步扩展6.1 检测与分割任务的端侧落地把 CNN 分类跑通之后下一步自然是目标检测和语义分割。检测任务里YOLO 系列是端侧的主力从 YOLOv5 到 YOLOv8每一代都在精度和速度上做平衡。YOLO 的端侧部署和分类模型类似但后处理NMS比较耗时通常要在 CPU 上做需要专门优化。分割任务里DeepLab 和 UNet 是常见选择但分割模型对分辨率敏感端侧跑高分辨率分割很吃力。我的经验是先用小分辨率验证链路再逐步往上调找到精度和速度的平衡点。6.2 多模型协同与流水线设计实际项目里很少只有一个模型。比如智能摄像头可能同时跑人脸检测、人脸识别、活体检测三个模型。这时候就要设计流水线让多个模型协同工作。流水线的核心是任务调度和资源分配。NPU 通常只有一个多个模型要排队跑。如果某个模型是瓶颈可以考虑把它拆到 CPU 上跑一部分或者调整模型优先级。我做过一个项目把检测模型放 NPU、识别模型放 CPU整体吞吐量比都放 NPU 还高因为两个硬件并行工作了。6.3 持续迭代数据回流与模型更新端侧模型部署不是一锤子买卖。设备上线后会遇到各种训练时没见过的场景模型需要持续迭代。数据回流是关键。设备把推理置信度低的样本、或者用户反馈错误的样本传回来人工标注后加入训练集重新训练模型再部署下去。这个闭环建立起来模型才能越用越准。端侧要考虑的是回流数据的筛选和压缩不能什么都往回传带宽和存储都受不了。我在实际项目里的体会是端侧 AI 的难点从来不是某一个技术点而是整条链路的打通和持续维护。从模型选型、量化调参、板端部署到数据回流每个环节都有坑但只要把 CNN 这条主线吃透后面的检测、分割、甚至轻量级 Transformer都是在这个基础上的延伸。先把一个 MobileNet 在板子上跑稳比什么都重要。
、中断、异常、接口、系统调用、体系结构)
