1. 为什么我要从 CNN 重新出发

1.1 一个嵌入式老兵的困惑

做了七八年嵌入式，从裸机寄存器到 RTOS，从 STM32 到各种国产 MCU，我自认为对“资源受限”这四个字有肌肉记忆。但这两年端侧 AI 的风刮得太猛，客户张口就是“能不能在板子上跑个人脸识别”“这个语音唤醒能不能离线做”，我发现自己那套“抠内存、算时钟周期”的本事，到了神经网络面前突然不够用了。

最开始我也跟风，上来就想搞 Transformer、搞大模型量化，结果模型是能跑，但推理时间飘忽、内存峰值炸裂、精度还掉得莫名其妙。折腾了两个月，我做了个决定：退回去，从 CNN 重新开始。这不是倒退，而是把地基重新打一遍。

1.2 端侧 AI 到底在解决什么问题

说人话，端侧 AI 就是把原本要传到云端服务器上算的推理任务，直接放在设备本地完成。它解决的核心痛点有三个：延迟、隐私、离线可用性。你对着智能门锁说句话，不可能等数据绕一圈公网再回来开锁；工厂质检的摄像头也不可能把每一帧都传出去。

而 CNN（卷积神经网络）至今仍是端侧视觉任务的主力。原因很朴素：它的计算模式规整、参数共享、对量化友好，天然适合在算力有限的芯片上做定点加速。Transformer 虽然火，但在端侧，尤其是中低端 MCU 和入门级 NPU 上，CNN 依然是性价比最高的选择。

1.3 这篇文章适合谁看

如果你是从嵌入式、单片机、驱动开发转过来的，想搞明白端侧 AI 到底怎么落地；或者你是做算法的，想把模型塞进资源紧张的设备里，却不知道从哪下手——那这篇就是写给你的。我会把 CNN 的基础原理、端侧部署的完整链路、量化实操、踩过的坑，全部摊开讲。不堆公式，讲人话，给能直接抄的配置。

2. CNN 基础回顾：别急着上框架，先把账算明白

2.1 卷积到底在干什么

很多人一上来就背“卷积是特征提取”，但没想过为什么它能提特征。我用一个生活化的类比：你拿一个 3x3 的小窗口在一张大图上滑动，每滑到一个位置，就把窗口里的 9 个像素和 9 个权重做加权求和。这个过程本质上是在找局部模式——边缘、角点、纹理。

关键点在于权重共享。同一个 3x3 的卷积核，在整张图上滑一遍，用的都是同一组参数。这就是 CNN 参数量远小于全连接网络的根本原因。一张 224x224 的图，全连接第一层如果输出 1000 维，参数量是 224×224×3×1000，约 1.5 亿；而一个 3x3 卷积、输出 64 通道，参数量只有 3×3×3×64，约 1700 个。差了近十万倍。

2.2 输出尺寸怎么算，别到部署时才发现对不上

这是嵌入式转过来的人最容易翻车的地方。卷积输出尺寸公式：

输出 = floor((输入 - 卷积核 + 2×padding) / stride) + 1

我见过太多人模型训练时输入 224，部署时摄像头给的是 240，结果特征图尺寸对不上，后处理全乱。在动手写第一行代码前，先把每一层的输入输出尺寸在纸上列一遍，这是嵌入式思维给端侧 AI 带来的最大优势——我们对“资源账”敏感。

2.3 池化、激活、批归一化，各自扮演什么角色

池化是降采样，把特征图缩小，减少计算量，同时提供一定的平移不变性。最大池化最常用，因为它保留了最显著的特征响应。

激活函数负责引入非线性。ReLU 是端侧首选，因为它是纯比较操作，没有指数运算，量化后几乎零成本。Sigmoid 和 Tanh 在端侧要尽量避免，除非是最后的输出层。

批归一化（BN）在训练时加速收敛，在推理时会被折叠进卷积层——也就是说，推理阶段 BN 是不存在的，它变成了一组缩放和平移参数融合进卷积权重。这个折叠过程是端侧部署的关键优化点，后面量化部分会详细讲。

2.4 一个最小可用的 CNN 结构长什么样

对于端侧入门，我建议从这样的结构开始：

• 输入层：96x96 或 112x112 灰度/RGB
• 3 到 5 个卷积块，每个块 = Conv + BN + ReLU + MaxPool
• 通道数从 16 起步，逐层翻倍到 128 或 256
• 全局平均池化替代全连接，大幅减少参数
• 最后接一个小的全连接或直接 1x1 卷积输出类别数

这个结构在 STM32H7 这类带 FPU 的 MCU 上，跑 10 类以内的分类任务，单帧推理可以做到几十毫秒级别。别小看这个数字，很多工业场景完全够用。

3. 端侧部署的完整链路拆解

3.1 从训练到部署，中间隔了多少道坎

很多人以为模型训练完导出个文件就完事了，实际上从 PyTorch 的 .pth 到设备上能跑的二进制，中间至少经过：模型导出 → 图优化 → 量化 → 代码生成 → 集成编译。每一道坎都可能让精度掉几个点，或者让推理时间翻倍。

我踩过最深的坑是：训练时用的是 RGB 三通道，部署时摄像头输出的是 YUV，转换代码写错了通道顺序，模型输出全是乱的。这种问题在 PC 上永远测不出来，只有上板子才会暴露。

3.2 模型导出：ONNX 是绕不开的中间站

ONNX 是目前最通用的模型交换格式。从 PyTorch 导出：

torch.onnx.export( model, dummy_input, "model.onnx", opset_version=11, input_names=["input"], output_names=["output"], dynamic_axes=None # 端侧固定输入尺寸，不要动态轴 )

注意：端侧部署一定要固定输入尺寸，dynamic_axes 留空。动态尺寸会让后续量化工具无法确定内存分配，直接报错。

导出后务必用 onnxruntime 跑一遍，和 PyTorch 的输出做数值对比，误差在 1e-4 以内才算正常。这一步不做，后面出了问题你根本不知道是导出错了还是量化错了。

3.3 图优化：把没用的东西删干净

ONNX 图里通常有一堆推理时不需要的节点：Dropout、Identity、多余的 Reshape。用 onnx-simplifier 过一遍：

python -m onnxsim model.onnx model_sim.onnx

它会自动做常量折叠、算子融合、死代码消除。我实测下来，一个典型的 MobileNet 变体，简化后节点数能减少 20% 到 30%，推理时间相应下降。

更关键的是BN 折叠。训练时的 Conv+BN 在推理时可以合并成一个 Conv，权重和偏置重新计算：

W_folded = W * gamma / sqrt(var + eps) b_folded = beta - gamma * mean / sqrt(var + eps)

这个操作在 onnx-simplifier 或后续的量化工具里通常会自动完成，但你要知道它发生了，否则看到权重数值变了会慌。

3.4 量化：端侧 AI 的命门

量化是把 FP32 的权重和激活值映射到 INT8 的过程。为什么必须做？因为大多数端侧芯片的 INT8 算力是 FP32 的 4 倍甚至更多，而且内存占用直接降到四分之一。

量化分两种：训练后量化（PTQ）和量化感知训练（QAT）。PTQ 简单，拿一批校准数据跑一遍就能量化，适合快速验证。QAT 精度更好，但要在训练时插入伪量化节点，流程复杂。

我的建议：先用 PTQ 跑通全流程，精度不够再上 QAT。很多任务 PTQ 掉点不到 1%，完全可接受。

量化的核心是确定 scale 和 zero_point：

real_value = scale * (quantized_value - zero_point)

对于对称量化，zero_point = 0，scale = max(abs(real_value)) / 127。非对称量化则要分别统计 min 和 max。端侧芯片通常对对称量化支持更好，因为计算时可以省掉 zero_point 的修正。

3.5 代码生成与集成

量化完的模型最终要变成 C 代码或者芯片专用的二进制。不同平台工具链不一样，但流程大同小异：加载量化模型 → 生成推理代码 → 提供输入输出接口 → 集成到你的工程里。

这里有个经验：生成的代码不要直接改。工具链升级后重新生成会覆盖你的修改。正确做法是在外面包一层适配层，把摄像头数据格式转换、预处理、后处理都放在适配层里，生成的推理代码保持原样。

4. 实操：在资源受限设备上跑通第一个 CNN

4.1 硬件选型与资源预算

假设我们选一颗带 INT8 加速的入门级 MCU，主频 200MHz 左右，SRAM 512KB，Flash 1MB。这个配置在今天的端侧 AI 场景里很典型。

先做资源预算：

这个预算下，模型参数量控制在 30 万以内比较稳妥。一个 5 层卷积、通道 16-32-64-128-128 的网络，参数量大约在 20 万左右，量化后 200KB，符合要求。

4.2 数据预处理：端侧最容易出错的地方

PC 上训练时，预处理通常是：归一化到 [0,1]，减均值除方差。端侧要做的第一件事是把这个预处理也量化。

假设均值是 [0.485, 0.456, 0.406]，方差是 [0.229, 0.224, 0.225]，输入是 0-255 的 uint8。我们可以把整个预处理融合成一个定点运算：

output_int8 = (input_uint8 - mean_uint8) * scale_factor

其中 mean_uint8 和 scale_factor 在编译时算好，运行时只做整数减法和乘法。这样既快又不会引入浮点误差。

注意：摄像头输出的 YUV 转 RGB 的公式系数也要一起量化，否则通道顺序和数值范围都会出问题。我建议在 PC 上用同一套量化后的预处理代码跑一遍测试集，确认精度无损再上板。

4.3 推理引擎的初始化与内存布局

推理引擎初始化时，最关键的是内存池的分配。端侧没有动态内存分配的自由，所有张量内存必须静态规划。

常见做法是：分析每一层激活值的大小，找出峰值，然后让不同层的激活值复用同一块内存。因为 CNN 是逐层计算的，第 1 层的输出用完，第 3 层才需要新内存，中间可以复用。

一个简化的内存复用策略：

层1输出: 96×96×16 = 147KB 层2输出: 48×48×32 = 73KB 层3输出: 24×24×64 = 36KB 层4输出: 12×12×128 = 18KB 层5输出: 6×6×128 = 4.6KB

峰值在层1，147KB。如果内存池按峰值分配，总共只需要 147KB 加上输入输出缓冲，远小于各层之和。这就是为什么端侧模型要尽量早降采样——第一层输出太大，内存根本扛不住。

4.4 推理循环的写法与性能测量

推理循环本身很简单：

void inference_loop(void) { preprocess(input_buf, model_input); model_invoke(); postprocess(model_output, result); }

但性能测量有讲究。不要用系统 tick 去测，精度不够。用芯片的周期计数器（DWT->CYCCNT 或类似寄存器），在推理前后各读一次，差值除以主频就是精确时间。

我实测一个 20 万参数的模型，在 200MHz MCU 上，INT8 推理约 15ms，加上预处理和后处理总共 25ms 左右。40FPS 的摄像头数据，每帧间隔 25ms，刚好打满。如果要留余量，就得降输入分辨率或者减通道数。

4.5 精度验证：别只看 PC 上的数字

PC 上量化后精度 95%，上板子可能只有 90%。原因通常是：预处理不一致、量化参数在板子上重新计算了、或者内存溢出导致数据被覆盖。

我的验证流程是：

1. PC 上跑 FP32 模型，记录每张测试图的输出
2. PC 上跑量化模型，对比输出，确认掉点在可接受范围
3. 板子上跑同一批图（通过串口喂进去），对比输出
4. 如果第 3 步掉点严重，检查预处理和内存

提示：板子上的测试图不要用摄像头实时采，用固定图片通过串口或 SD 卡输入，排除摄像头引入的变量。

5. 常见问题与排查技巧实录

5.1 模型跑起来但输出全是同一个类别

这是最经典的问题。排查顺序：

• 输入数据是否正常？打印前 10 个像素值，看看是不是全 0 或全 255
• 预处理是否和训练一致？归一化参数、通道顺序
• 量化参数是否合理？如果 scale 太小，所有输入都被量化到 0
• 权重是否正确加载？检查 Flash 里的权重和 PC 上的二进制是否一致

我遇到过一次，原因是量化校准数据用了全黑的图，导致 scale 计算出来极小，正常图片全被截断。换了一批正常校准图就好了。

5.2 推理时间忽长忽短

通常是内存访问冲突或者中断干扰。检查：

• 推理期间是否关了中断？不关的话，中断服务程序会打断推理，导致时间波动
• 内存池是否对齐？INT8 数据最好 4 字节对齐，否则访问效率下降
• 是否有 cache 未命中？如果芯片有 cache，推理前把模型权重预加载到 cache

5.3 量化后精度掉太多

先看是哪一层掉点。逐层对比 FP32 和 INT8 的输出，找到误差最大的层。常见原因：

• 该层权重动态范围太大，对称量化损失严重，考虑非对称量化
• 激活值分布不均匀，ReLU 后大量 0 值，考虑用 KL 散度校准
• 第一层和最后一层对精度敏感，可以保留 FP32

5.4 常见问题速查表

5.5 几个我踩过的坑

坑一：BN 折叠后权重变了，以为模型坏了。其实是对的，折叠后的权重就是应该和原来不一样，只要输出一致就行。

坑二：量化工具默认用非对称量化，但芯片只支持对称。结果推理时 zero_point 被忽略，输出全偏。一定要确认工具和芯片的量化模式匹配。

坑三：输入尺寸在训练时是 112，部署时为了省事改成 96，没重新训练。精度直接崩了。输入尺寸变了，感受野和特征尺度都变了，必须重新训练或至少微调。

坑四：忘了关调试串口打印。推理循环里每帧打印一次日志，串口阻塞导致帧率掉一半。量产代码里所有打印都要条件编译掉。

6. 从 CNN 出发，下一步往哪走

6.1 把 CNN 吃透后，迁移到其他结构会快很多

CNN 里的卷积、池化、量化、内存复用这些概念，在后续学深度可分离卷积、MobileNet 系列、甚至轻量级 Transformer 时都会反复出现。你会发现，深度可分离卷积就是把普通卷积拆成 depthwise 和 pointwise 两步，计算量降到约九分之一；而 Transformer 里的注意力机制，本质上也是一种加权求和，只是权重是动态计算的。

我自己的体会是：CNN 是端侧 AI 的“九九乘法表”，背熟了，后面心算大数才不慌。

6.2 端侧 AI 的边界正在快速扩展

以前端侧只能做分类，现在检测、分割、关键点、甚至小型的生成任务都在往端侧搬。但不管任务怎么变，资源受限这个前提不会变。算力、内存、功耗这三座大山，永远需要你用嵌入式的思维去平衡。

6.3 给转行者的几句实在话

别被“AI”两个字吓住。端侧 AI 的核心竞争力，恰恰是嵌入式工程师最擅长的：对资源的极致把控、对时序的精确理解、对硬件行为的直觉。算法可以学，但这些工程直觉是几年板子调出来的。

我从 CNN 重新开始，不是因为我不会别的，而是因为我知道，只有把最基础的东西嚼碎了，后面盖楼才不会塌。如果你也在从嵌入式往端侧 AI 转，我的建议就一句：先跑通一个最小的 CNN，从数据采集到推理输出，全链路走一遍。走完这一遍，你就入门了。