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 的核心约束是四个维度的同时挤压：算力上限、内存带宽、功耗预算、实时性要求。这四个东西互相拉扯，你优化了其中一个，另外三个可能就崩了。

举个例子，某款常见的端侧 SoC，NPU 算力标称 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 看每一层的耗时，找出最慢的几层。常见瓶颈和优化手段如下：

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 的题，往往能找到更务实的方案。

最后分享一个小技巧：建一个自己的端侧模型性能数据库。每次部署一个模型，记录硬件平台、模型结构、量化方案、延迟、功耗、准确率。积累多了，下次选型时就有参考，不用每次都从头试错。我从去年开始记，现在已经攒了三十多条记录，选型效率提升非常明显。