1. 从嵌入式到端侧 AI为什么我选择回头啃 CNN做了七八年嵌入式开发从裸机寄存器到 RTOS再到后来跑 Linux 的 SoC我自认为对“资源受限”这四个字有肌肉记忆。但这两年端侧 AI 的风向变得太快身边不少做 MCU 的朋友突然开始聊模型量化、算子融合、NPU 调度好像一夜之间不会点深度学习就没法在嵌入式圈子里混了。我也跟风试过直接上 Transformer 的端侧部署方案结果被现实狠狠教育了一顿——内存炸了、延迟飘了、功耗压不住最后连模型都跑不起来。折腾了两个月之后我决定把那些花哨的架构先放一放重新从 CNN 开始把端侧 AI 的底层逻辑彻底捋清楚。这个决定不是退步而是回归常识。CNN 在端侧 AI 里的地位就像 C 语言在嵌入式里的地位——你可能觉得它老但它是理解一切上层建筑的基石。卷积核怎么在内存里排布、特征图怎么复用、量化误差从哪里来、算子怎么映射到硬件指令这些问题在 CNN 上都能找到最直观的答案。而且现在的端侧场景无论是智能门锁的人脸识别、工业相机的缺陷检测还是可穿戴设备的手势分类CNN 依然是性价比最高的选择。这篇文章就是把我从嵌入式转向端侧 AI 的完整思考过程、技术选型逻辑、实操踩坑记录全部摊开适合那些有嵌入式基础但深度学习刚入门的朋友也适合做端侧部署时被模型大小和推理速度折磨过的同行。2. 端侧 AI 的真实需求与 CNN 的不可替代性2.1 端侧场景到底在约束什么很多人从云端 AI 转过来做端侧第一反应是“把模型缩小就行了”但实际约束远不止模型大小。我总结下来端侧 AI 的核心约束是四个维度的同时挤压算力上限、内存带宽、功耗预算、实时性要求。这四个东西互相拉扯你优化了其中一个另外三个可能就崩了。举个例子某款常见的端侧 SoCNPU 算力标称 1 TOPS听起来够用但实际有效算力可能只有标称的 30% 到 50%因为内存带宽跟不上。你跑一个 ResNet-50理论计算量 4 GFLOPs按 1 TOPS 算应该 4 毫秒跑完但实际可能是 20 毫秒甚至更久瓶颈就在数据搬运上。这就是端侧 AI 和云端 AI 最大的区别云端拼的是峰值算力端侧拼的是数据复用率和内存访问效率。功耗就更不用说了。云端 GPU 功耗几百瓦无所谓端侧设备可能总共就 500 毫安时的电池NPU 跑满 1 瓦半小时就没电了。所以端侧 AI 的模型设计从一开始就要考虑“每焦耳能跑多少次推理”而不是单纯看准确率。2.2 CNN 为什么依然是端侧首选Transformer 在云端确实统治了 NLP 和部分视觉任务但端侧部署时它的自注意力机制计算复杂度是序列长度的平方级而且需要大量的矩阵乘和内存交换。我实测过一个轻量级 ViT参数量压到 5M 以下在端侧 NPU 上跑延迟比同精度的 MobileNetV3 高了 3 倍多功耗高了 2 倍。原因很简单CNN 的卷积操作有局部连接和权重共享两个天然优势这两个特性直接对应到硬件上就是数据复用率高、片上缓存友好。卷积的局部连接意味着每个输出像素只依赖输入的一个小邻域这个邻域数据可以放在寄存器或紧耦合内存里反复用。权重共享意味着同一个卷积核在整张图上滑动权重只需要加载一次。这两个特性让 CNN 在端侧硬件上天然具备高数据复用率而数据复用率正是端侧 AI 能效比的核心指标。另外CNN 的算子结构非常规整卷积、池化、激活、逐元素加这些算子在 NPU 或 DSP 上都有成熟的硬件加速方案。你去看任何一款端侧 AI 芯片的指令集卷积指令一定是最先被优化、工具链最成熟的。Transformer 的算子就复杂多了LayerNorm、Softmax、多头注意力每个都有不同的数据排布要求工具链支持参差不齐。2.3 从嵌入式视角看 CNN 的天然亲和性做嵌入式的人有个思维习惯一切从内存布局出发。我们写 C 代码的时候结构体怎么对齐、缓冲区怎么分配、DMA 怎么搬运这些直觉在理解 CNN 时特别有用。CNN 的特征图在内存里就是一块多维数组NCHW 还是 NHWC 排布直接决定了卷积计算的访存模式。嵌入式里常用的乒乓缓冲、循环展开、SIMD 指令在 CNN 算子优化里全都能用上。我甚至觉得一个有嵌入式背景的人去学 CNN 部署比一个纯算法背景的人去学上手速度要快得多因为前者对“数据怎么在内存和计算单元之间流动”有天然的敏感度。而且 CNN 的量化特别直观。嵌入式里我们经常做定点数运算Q15、Q7 这些格式玩得很熟。CNN 的 INT8 量化本质上就是把浮点权重和激活值映射到 8 位整数域再通过缩放因子还原。这个映射过程、溢出保护、舍入策略和嵌入式里的定点数处理逻辑几乎一模一样。你如果做过 ADC 采样后的定点滤波理解 CNN 量化就是分分钟的事。3. CNN 核心细节拆解从卷积到量化3.1 卷积操作的硬件友好性分析卷积为什么对硬件友好我们拿一个 3x3 卷积、输入通道 32、输出通道 64 的例子来算一笔账。输入特征图大小 56x56输出也是 56x56。直接卷积的计算量是 56x56x32x64x3x3约等于 5.8 亿次乘加。如果按浮点算每次乘加 2 个操作就是 11.6 亿次操作。这个量级在端侧 NPU 上如果数据复用做得好几百微秒能跑完。关键在“数据复用”四个字。3x3 卷积核在输入特征图上滑动时相邻的输出像素共享大量输入数据。一个 56x56 的输入特征图每个像素平均被 9 个输出像素用到边界少一些。如果每次计算都从 DRAM 重新读输入那内存带宽直接爆炸。所以实际硬件实现时会把输入特征图分块tiling一块数据加载到片上缓存后反复计算多个输出像素这就是空间复用。权重也一样。64 个输出通道的权重每个 3x3x32总共 18432 个权重。这些权重在整张图上滑动时反复使用所以权重可以常驻片上缓存这就是权重复用。空间复用加权重复用让 CNN 的算术强度计算量/访存量远高于全连接层和注意力层。我实测过一个对比同样参数量下纯卷积网络的算术强度大约是 Transformer 的 5 到 10 倍。这意味着在同样的内存带宽下CNN 能跑出更高的有效算力利用率。3.2 特征图内存布局与访存优化特征图的内存布局是端侧 CNN 部署里最容易被忽视、但影响最大的细节之一。NCHW 和 NHWC 两种排布在不同硬件上的性能差异可能达到 2 倍以上。NCHW 是通道优先适合 GPU 和某些 NPU因为通道维度连续方便做通道级的向量化。NHWC 是通道在后适合 CPU 和部分 DSP因为空间维度连续方便做行级的 SIMD 加载。端侧芯片五花八门有的 NPU 只支持 NHWC有的只支持 NCHW你拿到的模型格式如果和硬件不匹配就得插入额外的转置操作这个转置的代价可能比卷积本身还大。我的经验是在模型训练阶段就确定目标硬件的布局偏好直接按目标格式导出。比如目标芯片是 NHWC 原生那训练时就用 TensorFlow 的默认布局导出时不要转 NCHW。如果目标芯片是 NCHW就用 PyTorch 训练导出时保持 NCHW。中间少一次转置端侧就少一次全图遍历。还有一个细节是通道对齐。很多 NPU 的向量化宽度是 8 或 16如果你的通道数不是 8 或 16 的倍数硬件会做 padding浪费算力。所以设计模型时通道数尽量取 8 的倍数比如 24、32、48、64而不是 20、36、52 这种。这个习惯我从嵌入式里的 DMA 对齐沿袭过来在 CNN 里同样适用。3.3 量化端侧 CNN 的必修课量化是端侧 CNN 部署绕不开的坎。FP32 模型在端侧跑内存占用大、算力消耗高、功耗也高。INT8 量化能把模型大小压到 1/4推理速度提升 2 到 4 倍功耗降低一半以上。但量化不是简单地把浮点转整数里面有很多坑。先说对称量化和非对称量化。对称量化把浮点范围映射到 [-127, 127]零点固定为 0适合权重这种分布对称的数据。非对称量化映射到 [0, 255]零点可调适合激活值这种经过 ReLU 后非负的数据。实际部署时权重用对称量化激活用非对称量化是常见组合。再说逐层量化和逐通道量化。逐层量化是整个层共用一个缩放因子实现简单但精度损失大。逐通道量化是每个输出通道一个缩放因子精度高但硬件实现复杂。端侧 NPU 如果支持逐通道量化优先用逐通道尤其是深度可分离卷积这种通道间差异大的结构。量化最疼的地方是精度掉点。我踩过最惨的一次一个 MobileNetV2 量化后准确率掉了 8 个百分点排查了半天发现是某个深度卷积层的激活值范围异常大把整个量化范围拉宽了导致小值区域分辨率不够。解决办法是在量化校准阶段用足够多的代表性样本并且对异常层做截断处理把激活值的动态范围限制在 99.9% 分位数以内牺牲一点极值精度换取整体分辨率提升。还有一个经验量化感知训练比训练后量化效果好得多。如果条件允许在训练阶段就模拟量化误差让模型自己去适应。我做过对比同样一个模型量化感知训练后掉点 1% 以内训练后量化掉点 3% 到 5%。虽然量化感知训练麻烦一点但端侧部署的精度损失是实打实的用户体验值得多花这个时间。4. 端侧 CNN 实操全流程从模型到部署4.1 模型选型与裁剪策略端侧 CNN 选型不能只看 ImageNet 准确率要看准确率-延迟-功耗的三维帕累托前沿。我一般从三个维度筛选参数量、计算量、内存访问量。参数量决定模型存储大小计算量决定推理延迟下限内存访问量决定实际能效比。目前端侧比较成熟的骨干网络有 MobileNetV3、ShuffleNetV2、EfficientNet-Lite 这几个。MobileNetV3 的 h-swish 激活在端侧有硬件加速支持时很香但如果没有swish 的计算代价比 ReLU 高不少。ShuffleNetV2 的通道混洗操作在某些 NPU 上支持不好会退化成内存拷贝。EfficientNet-Lite 的复合缩放策略在端侧有点过度设计实际部署时往往需要手动裁剪。我的做法是先选一个基线模型然后在目标硬件上实测每一层的延迟找出瓶颈层针对性裁剪。比如某个阶段的通道数从 64 砍到 48准确率掉 0.5%但延迟降 20%这种买卖就划算。裁剪不是拍脑袋要基于实测数据做决策。还有一个技巧是替换大卷积核。5x5 卷积在端侧很少见因为计算量是 3x3 的 2.78 倍但感受野只大了 1.67 倍。如果模型里有 5x5 卷积优先考虑用两个 3x3 堆叠替代感受野一样计算量还少。这个等价替换在 VGG 时代就被验证过端侧更是金科玉律。4.2 训练阶段的端侧友好设计训练阶段就要为端侧部署做准备而不是训练完再想办法压缩。我总结了几条端侧友好设计原则第一激活函数优先选 ReLU 或 ReLU6。ReLU6 把输出限制在 [0, 6]量化时动态范围可控比 ReLU 的无上界友好得多。MobileNet 系列一直用 ReLU6 不是没有道理的。第二避免大范围的逐元素操作。比如 Add、Mul 这些操作如果两个输入的特征图范围差异大量化后精度损失严重。可以用加权融合替代直接相加让两个输入的范围接近。第三BN 层融合进卷积。BN 在推理阶段就是一个线性变换完全可以折叠进前面的卷积权重和偏置里。这样端侧就少了一个算子少了一次内存读写。几乎所有端侧推理框架都会做这个优化但你在训练时就要保证 BN 的统计量是稳定的否则融合后误差会放大。第四控制特征图数量。端侧内存有限中间特征图太多会爆内存。我一般把峰值特征图内存控制在 2MB 以内对应大约 512x512x8 的规模。如果某个阶段的特征图太大就提前下采样或者减少通道数。4.3 部署阶段的算子映射与调度模型训练完导出成 ONNX 或 TFLite接下来就是部署阶段。这一步的核心工作是算子映射和调度优化。算子映射就是把框架里的算子对应到硬件指令。比如 Conv2D 映射到 NPU 的卷积指令ReLU 映射到激活指令MaxPool 映射到池化指令。大部分标准算子都有现成映射但一些特殊算子比如自定义的激活函数、非标准的池化方式可能没有硬件支持需要软件回退。软件回退的代价很大一次回退可能让整个推理延迟翻倍。所以模型设计时尽量用标准算子这是端侧部署的铁律。调度优化是决定多个算子怎么串行或并行执行。端侧 NPU 通常有多个计算单元比如卷积单元、向量单元、标量单元。如果调度得当卷积和激活可以流水线执行一个算子在算的时候另一个算子在准备数据。我实测过一个调度优化把推理延迟从 15 毫秒压到 9 毫秒靠的就是算子融合和流水线调度。还有一个实操细节是内存复用。端侧内存有限中间特征图的内存要反复利用。推理框架一般会做内存池化但你可以通过调整算子执行顺序来降低峰值内存。比如把两个不相关的分支错开执行而不是并行执行峰值内存能降不少。5. 常见问题与排查技巧实录5.1 量化掉点严重怎么排查量化掉点是最常见的问题。我的排查顺序是先看逐层敏感度再查激活值分布最后调校准策略。逐层敏感度分析就是每次只量化一层其他层保持浮点看准确率掉多少。掉点最多的层就是敏感层需要特殊处理。常见敏感层是第一个卷积层和最后一个全连接层这两个层往往需要保持浮点或者用更高位宽。激活值分布用直方图看。如果某个层的激活值有长尾比如大部分在 [0, 1] 但偶尔蹦到 100那量化范围会被拉到 [0, 100]小值区域分辨率极低。解决办法是截断把 99.9% 分位数之外的值截掉牺牲极值精度换整体分辨率。校准策略方面KL 散度校准比最小最大校准效果好但计算量大。端侧部署如果时间紧可以用移动平均校准用一批样本的滑动平均来确定量化范围效果介于两者之间。5.2 推理延迟不达标的优化路径延迟不达标先定位瓶颈。用推理框架的 profiler 看每一层的耗时找出最慢的几层。常见瓶颈和优化手段如下瓶颈类型典型表现优化手段卷积层耗时高单层占比超过 30%减小通道数、换深度可分离卷积、用 Winograd 算法内存拷贝耗时高算子间有大量 memcpy算子融合、调整内存布局、减少转置激活函数耗时高swish/h-swish 占比高换 ReLU/ReLU6、查硬件加速支持调度开销大小算子多、启动频繁算子融合、批处理、减少分支Winograd 算法值得单独说。对于 3x3 卷积Winograd 能把乘法次数减少到直接卷积的 1/2.25。但 Winograd 的数值稳定性差量化后误差会放大。我的经验是浮点推理用 Winograd量化推理慎用除非硬件有专门的 Winograd 指令且精度验证通过。5.3 内存溢出与峰值内存控制端侧内存溢出往往是峰值内存超了。峰值内存出现在哪里一般是多个分支并行执行或者大特征图未及时释放的时候。控制峰值内存的手段第一串行化分支。如果模型有多个分支让它们顺序执行而不是并行峰值内存能降一个分支的量。第二及时释放。推理框架一般有内存池但你可以通过调整算子顺序让大特征图尽早被消费掉。第三分块计算。对于大特征图可以分块加载、分块计算、分块写回用时间换空间。我踩过一个坑某个模型在 PC 上跑得好好的端侧一跑就 OOM。排查发现是某个中间特征图在 PC 上是 4MB端侧内存只有 2MB。解决办法是把那个阶段的通道数从 128 砍到 64准确率掉 0.3%但内存直接减半问题解决。5.4 精度与速度的平衡经验精度和速度的平衡是端侧 AI 的永恒话题。我的经验是先定速度预算再压精度。比如产品要求 30 毫秒推理延迟那就先按这个延迟选模型和量化方案然后在满足延迟的模型里选精度最高的。而不是先选一个高精度模型再想办法压延迟那样往往压不下来。还有一个经验是分场景调优。同一个模型在不同场景下可以有不同的精度-速度配置。比如人脸识别注册阶段可以用高精度模型识别阶段用低精度快速模型。这种多模型级联的策略在端侧很实用。6. 从 CNN 出发的端侧 AI 进阶路线6.1 掌握 CNN 部署后的下一步CNN 部署跑通之后下一步可以往三个方向走检测、分割、轻量级注意力。检测方向从 SSD 到 YOLO 系列端侧部署的核心是后处理优化。NMS 在端侧很耗时可以用硬件加速或者近似算法替代。分割方向从 FCN 到 DeepLab端侧的核心是多尺度特征融合的内存控制。轻量级注意力方向比如 MobileViT、EfficientFormer把注意力的计算量压到可接受范围是当前的研究热点。我的建议是先把 CNN 的分类和检测做扎实再考虑注意力。因为注意力的部署工具链还不够成熟踩坑成本高。CNN 的工具链经过多年打磨稳定性和性能都有保障。6.2 工具链选型与生态观察端侧 AI 工具链目前主流的有 TensorFlow Lite、ONNX Runtime、PyTorch Mobile以及各家芯片厂商的自有工具链。我的选型原则是优先用芯片厂商的原生工具链因为只有厂商自己最清楚硬件的脾气。TFLite 和 ONNX Runtime 适合做原型验证和跨平台对比但最终部署往往要转到厂商工具链。厂商工具链的坑也不少。文档不全、算子支持列表不透明、量化工具难用这些都是常态。我的应对策略是先跑通官方 Demo再改自己的模型。官方 Demo 跑通了说明环境没问题然后一步步替换成自己的模型每换一步测一次出问题好定位。6.3 给嵌入式同行的学习建议如果你也是嵌入式背景想转端侧 AI我的建议是不要一上来就啃深度学习理论先从部署入手。找一个现成的端侧模型在目标硬件上跑通然后逐步替换、裁剪、量化在这个过程中理解每个操作的意义。理论可以后面补但动手经验是补不来的。另外保持对内存和功耗的敏感。这是嵌入式人的优势不要丢掉。端侧 AI 的很多问题归根结底是内存和功耗问题而不是算法问题。你用嵌入式的思维去解端侧 AI 的题往往能找到更务实的方案。最后分享一个小技巧建一个自己的端侧模型性能数据库。每次部署一个模型记录硬件平台、模型结构、量化方案、延迟、功耗、准确率。积累多了下次选型时就有参考不用每次都从头试错。我从去年开始记现在已经攒了三十多条记录选型效率提升非常明显。