嵌入式工程师重学CNN：从卷积到端侧AI部署的底层之路
1. 从裸机代码到模型参数：我为什么觉得必须重学 CNN
1.1 做了十年嵌入式，第一次被"模型"这个词卡住
先说个背景。我之前一直做嵌入式，从 8 位单片机上的裸机程序，到后来的 RTOS 驱动、Linux 底层移植，都是围绕寄存器、中断、DMA、内存池这些东西转。前几年端侧 AI 概念热起来的时候，说实话我一开始是有点不以为然的——嵌入式嘛，资源有限，跑跑控制逻辑才是本分，AI 这种东西应该是云端的事情。
直到有个项目需要把图像识别模型搬到一块 Cortex-M7 内核的设备上，我才第一次真正意识到自己的知识结构有个断层。板子资源是死的，Flash 和 RAM 就那么多，但模型怎么做缩放、怎么裁剪、量化之后精度掉多少、推理时间够不够实时——这些问题我完全答不上来。我能看懂 C 代码里的每一个指针，却看不懂模型文件里每一层的含义。
当时顺手查了很多资料，发现一个普遍现象：嵌入式圈子聊 AI 更多是聊工具链怎么用，比如 STM32Cube.AI 点几下生成代码，或者 TensorFlow Lite Micro 怎么编译进去。但一旦模型精度不对、内存爆了、推理跑不满帧率，很少有人能真正解释清楚问题出在模型的哪一层。原因很简单——工具能帮你部署，但帮不了你理解。
所以我决定退回去，从 CNN 开始重学。不是从 PyTorch 的接口开始学，而是从"卷积到底在算什么、权重到底长什么样、每一层输出多大张量"这个粒度开始学。这篇文章就是记录我这一段重回基础的过程，包括我踩过的坑、验证过的方法，以及给同样背景的嵌入式工程师的一些参考路线。
1.2 端侧 AI 落地的真正难点不在框架，而在对模型的底层理解
很多从嵌入式转过来的朋友，一开始学 AI 容易陷入一个路径依赖：把神经网络当作一个黑盒库函数，输入一个数组，输出一个数组，中间过程不用管。这个思路在纯软件平台上也许能撑一阵，但到了端侧部署场景，一定会撞墙。
为什么？因为端侧部署本质上是一个资源约束下的翻译问题。你需要把一个以浮点运算为中心、假设无限内存、逐层串行执行的数学模型，翻译成一个在有限 Flash、有限 RAM、可能没有 FPU、甚至没有操作系统的裸机环境下运行的实时任务。做这个翻译，你必须清楚每一层的输入输出尺寸、数据类型、内存占用、计算量分布，以及各层对最终精度的影响权重。
举个最简单的例子。一个 MobileNet 里的深度可分离卷积，理论上参数量和计算量都比标准卷积小很多，但它中间的 feature map 张量形状变化很频繁。如果你不理解每一层 tensor 的排布方式，就没办法做内存复用规划，也没办法判断中间结果谁可以覆盖谁。嵌入式工程师本来最擅长的就是内存规划，但面对模型时这套经验用不上了，因为模型的中间状态是动态变化的，且不像 RTOS 的任务栈那样可控。
CNN 是所有视觉类端侧模型的基础。目标检测、语义分割、人脸识别，骨架大概率都是 CNN。Transformer 架构虽然现在很火，但在低算力 MCU 级别的设备上，落地场景还是以 CNN 变体为主。所以从 CNN 重新开始，不是退步，是在补上端侧 AI 落地最依赖的那块地基。
2. 嵌入式思维和神经网络思维是两套操作系统
2.1 控制流思维 vs 数据流思维：代码阅读方式完全不同
我做嵌入式的时候，读代码的方式是沿着控制流走的：main 函数初始化外设，然后进 while 循环，中断来了跳中断服务函数，处理完回来继续。脑子里永远有一条清晰的执行路径，每一步都能在调试器里打上断点，检查寄存器和变量。
神经网络代码完全不是这个读法。以 PyTorch 为例，forward()函数里的每一行，本质上不是在"执行操作"，而是在描述数据的变换过程。conv = self.conv1(x)这行代码，不是触发一次函数调用然后等着返回，而是注册了一个计算节点。真正的计算要等到整体构图完成后，由框架的数据流引擎在设备上调度执行。你在中间打断点，看到的不是"当前执行到第几条指令"，而是"这个张量此刻在计算图里的什么位置、形状是什么、值分布大概什么样"。
这在调试策略上是个根本性的转变。嵌入式调试靠的是断点和单步，通过确定性的指令序列定位问题；神经网络调试靠的是张量形状检查和数值分布统计。比如某一层输出全变成 NaN，那你不能靠单步去"走"到那一层，你要靠的是在每一层输出之后打印 shape 和统计值，或者用 hook 函数把中间结果捞出来看。我一开始很不适应这种调试方式，总觉得不打断点就没办法定位问题，后来才慢慢明白：数据流程序里，问题往往不是"执行错在哪一行"，而是"数据在哪一层变换时出了偏差"。
2.2 确定性系统 vs 概率系统：心态层面的第一个坎
嵌入式的世界是确定性的。一个按键按下，IO 电平变化，中断触发，标志位置位，逻辑判断执行——每一步都是可预期、可重复的。哪怕有抖动，你也会用消抖逻辑让它变得确定。
神经网络恰恰相反，它从根上就是概率性的。模型不是通过规则推导得出结论，而是通过大量样本统计出权重参数，推理时计算每个类别的置信概率。这带来两个层面的心态冲击。
第一，模型的输出天然带"不确定性"。同一个输入，理论上输出是确定的（权重固定、输入固定、推理路径固定），但你对这个输出能有多大的信任度，取决于训练数据的代表性和模型的泛化能力。这不完全是技术问题，更像是一个工程判断问题——你需要在什么置信度以上才认为识别结果有效，低于阈值怎么处理，是丢弃还是走兜底逻辑。这种"概率容错设计"，嵌入式工程师以前很少需要面对。
第二，调试思路从"找到确切的 bug"变成"分析统计性偏差"。如果做图像分类，某类物体识别准确率低了 5 个点，你很难像查 bug 一样定位到具体的某一行代码。更合理的做法是收集错误样本，统计错误分布，看是数据问题（训练集里这类图片太少）、预处理问题（归一化参数不对）、还是模型容量问题（层数不够）。这种思维方式，和查"为什么串口多收了一个字节"是完全不同的两套方法论。
2.3 内存布局：从手动管理到张量生命周期规划
内存管理是嵌入式工程师的老本行。我之前维护过一个音视频处理模块，所有缓冲都是预先分配好的静态数组，靠精心设计的生命周期管理在极小内存下跑完整个流程。这个能力在端侧 AI 里同样关键——甚至更关键，因为模型的中间张量往往比输入数据大得多。
举个例子，一个 224x224x3 的 RGB 输入图，才约 150KB（按 FP32 算）。但经过第一层卷积后，如果输出是 112x112x32 的特征图，体积就变成了 1.5MB 左右。中间层特征图的体量往往远大于输入图像本身，且每一层都在变化。在裸机或 RTOS 环境下，你不可能给每一层都分配独立缓冲，必须做内存复用——不同层的输出可以共用同一块内存，只要保证生命周期不重叠。
这里有个很实用的规划思路：把模型的每一层抽象成"任务"，每个任务有一个输入缓冲区和一个输出缓冲区。分析完整条推理链后，找出所有互不重叠的中间张量，让它们共享同一块最大缓冲区。这和嵌入式里做 DMA 缓冲区复用是同一个逻辑，只是"任务"的粒度从外设变成了神经网络层。问题是，这个规划的前提是你得手工或借助工具导出每一层的输入输出尺寸——而大部分嵌入式工程师刚开始学 CNN 时，根本不会去看这个层面，这才是真正需要补的课。
3. CNN 核心组件在端侧硬件上的"翻译层"
3.1 卷积层：本质是一堆乘累加，但别再把它当黑盒
视觉类模型里，卷积层占比最高。理解卷积，不能只记住"提取特征"这种模糊概念，要从运算角度把它拆开：卷积核在输入特征图上滑动，每个位置做一次乘累加求和。一次乘累加就是读入一个输入像素值和一个权重值，相乘后累加，累加完再写回输出。
一台 Cortex-M4 级别的 MCU，主频 168MHz，带 FPU，理论峰值算力大概在 0.1 GOPS 左右。一个 224x224 输入、32 通道输出的普通 3x3 卷积，光乘累加次数就是 2242243293，约 433 亿次。显然不能直接这么算，所以端侧 CNN 部署必须做减法：或减小输入分辨率（比如 96x96），或用深度可分离卷积（MobileNet 系列的核心设计），或者改成单通道灰度输入。这些决策全都要你亲手算过一遍，才知道边界在哪里。
实际部署里还有更底层的问题：乘累加运算的精度、循环展开方式、DMA 搬运与计算的重叠。如果芯片带有硬件卷积加速器，比如某些 MCU 内置的 NPU 或 DSP 指令扩展，你还要理解数据在内存里的排布，怎么喂给加速器效率最高。这一步，恰恰是嵌入式工程师能把"模型部署"做深的核心：别人只是在调用现成 API，而你能看透 API 背后硬件在算什么。
3.2 池化与激活：计算量不大，但信息损失和内存策略值得关注
池化层做的是降采样。最大池化取窗口内的最大值，平均池化取均值。它没有可学习参数，计算量很小，但有一个容易被忽略的点：池化会改变张量空间尺寸，而后续层的输出尺寸随之变化，直接影响内存复用方案。代码里两三行就能实现一个池化层，但在嵌入式代码里，你得为不同尺寸的 feature map 规划不同的缓冲区，这就要回头去查模型里每一个池化层的确切参数（核大小、步长、padding 与否），一个都不能偷懒。
激活函数方面，ReLU 是端侧部署最友好的选项。它只是把负数置零，运算量几乎为零，而且不会引入复杂的浮点计算。Sigmoid 和 tanh 这类函数在嵌入式 MCU 上要小心——它们涉及 exp 运算，在标准 C 库里会用浮点库实现，耗时可能是 ReLU 的几十倍。有些部署工具链会把 Sigmoid 做成查表，但表的大小和精度范围也要权衡。所以说，模型架构设计阶段就要想着部署实现，这个经验我是在实际做性能优化时才深刻体会的。
3.3 量化：从 FP32 到 INT8 是信息压缩，还是有损压缩的艺术
量化是端侧部署里最绕不开的坎。模型训练时权重和激活都用 32 位浮点存储和计算，但在 MCU 上跑浮点，速度和内存消耗都难以接受。最常规的做法是量化为 INT8，也就是每个数值用 8 位有符号整数表示，浮点权重通过一个 scale 和 zero point 映射到整数区间。
量化不是简单的四舍五入。首先，你需要一个校准数据集，统计模型运行时激活值的分布范围，确定合适的 scale 和 zero point。这个数据集要贴近真实使用场景，如果校准数据分布和实际数据不一致，量化后的精度会明显下降。其次，每一层的量化参数都不同，部署在硬件上时，每一层的输入输出可能都需要反量化或重新量化，这部分转换代码往往是重点难点。
这东西落到嵌入式上，还有一个特别实际的痛点：内存翻倍占用。如果模型某层的输入是 INT8 但芯片的加速器要求 FP32 输入，你就得在内存里存两份数据，临时转换，这会带来额外的时间和空间开销。之前在一个项目里，就是因为某个库函数默认把输入转成 FP32，导致内存峰值比理论值高出一大截，排查了半天才发现是数据类型转换引起的。所以做端侧部署，必须时刻盯住每一个环节的数据类型，不是 FP32/INT8 二选一那么简单的。
4. 我的端侧 CNN 重学路线与实操验证
4.1 先跑通一条最简链路：MNIST → 量化 → 部署
我的做法是从最简单的任务开始，不是一上来就啃 YOLO 或者 Segment Anything。我选了一个最经典的 MNIST 手写数字识别，模型用 LeNet-5 的简化版。目标只有一个：把这个模型完整地从 PyTorch 训练 → 导出 → 量化 → 部署到开发板上跑通，中间每一步都亲手做一遍，不做任何框架封装的"一键部署"。
训练阶段我直接用了现成的 PyTorch 代码，但加了一个习惯：每一轮训练后，把模型的每一层输出 shape 打出来，记在本子上。这强迫我去关注模型内部的结构变化，而不是只盯着准确率曲线。LeNet-5 的结构很简单，卷积池化交替，到全连接层时把 feature map 展平成向量。通过手工计算每一层的输出尺寸，我很快就建立了一个直观感受："张量在模型里是怎么从 WxHxC 一步步变成类别概率的"。
量化阶段我用了两种方式对照：一种是 PyTorch 里自带的动态量化接口，另一种是后面部署工具链的量化方式。两者对比下来，差异很大——动态量化简单但一般只压权重不压激活，对推理加速帮助有限；部署链路的量化是把激活也量化的，压缩效果更显著，但精度损失也更需要关注。用 MNIST 这种简单任务做测试的好处是，你可以专心搞懂机制，不用花大量时间调模型结构。
部署阶段，我先在 PC 上用 Python 仿真推理，把所有中间层输出保存下来，作为参考基准。然后在开发板上加载同一份输入，把每一层的结果打印出来做比对。这一招非常有效——哪一层开始跟 PC 端结果对不上，问题就锁定在哪一层。这种"逐层对齐"的验证方法，我从这个项目之后一直沿用到现在，所有模型部署我都建议这么做。
4.2 工具链选型：Cube.AI 与 TFLite Micro 的取舍
端侧 CNN 部署，工具链是很关键的选择。我手头主力平台是 STM32 系列，所以先试的是 STM32Cube.AI。它的好处是集成度高，直接在 CubeMX 里导入模型文件（ONNX 或 Keras 格式），自动生成 C 代码和推理库，还内置了 RAM/Flash 占用评估。对嵌入式工程师来说，入门成本很低，因为它生成的代码风格和 KEIL/IAR 工程完全兼容。
TensorFlow Lite Micro 则是另一条路线。它更偏"通用"：一套推理引擎框架，可以跑多种模型，但需要自己处理板级适配、内存分配、算子注册。它可以让你看到推理引擎的完整实现代码，从算子到内存分配器都是开源可查的。如果你想深入了解端侧推理引擎的内部机制，TFLite Micro 源码是很不错的教材。
我的建议是两条路都走一遍，但顺序有讲究：先用 Cube.AI 跑通一条完整链路，建立信心，了解部署的基本流程；再用 TFLite Micro 或裸写的推理代码做一遍，理解背后的原理。原因很简单——工具链生成的代码能帮你上线，但当你遇到工具链解决不了的问题，比如要为一个自定义算子写实现，或者要优化某个特殊层的内存复用，你对底层机制的理解就决定你能不能独立解决。按照个人经验，真正让你值钱的不是会点按钮部署模型，而是能在工具链失效时自己动手把问题解决掉。
4.3 用示波器思维看推理：每一层的时间开销实测
嵌入式工程师做性能优化，依赖的就是测量。我把这个习惯带到了 CNN 部署上：每个卷积层、每个池化层、每个全连接层的执行时间，都要实测出来。
具体做法很简单：在模型生成的推理 C 代码里，在每一层调用之前翻转一个 GPIO，层执行完再翻转回来，用示波器或逻辑分析仪测量高电平持续时间。这样就能精准地知道每一层花了多少时间，而不需要依赖任何 profiling 工具的估算。结果非常直观：大部分时间都集中在卷积层，池化和激活几乎可以忽略，全连接层如果输出维度不大也很快。
然后我开始做优化实验，每一次只改一个参数，比如把卷积循环从三重嵌套改成四重嵌套加展开，或者把输入宽度改成 4 字节对齐，然后再次用 GPIO 测量时间对比。这种优化方式和我以前调中断响应时间、调 DMA 传输效率的套路一模一样。用这套方法，我逐步理解了为什么有些代码编译器会优化得好——因为内存访问连续性更好，Cache 命中率更高，而这也直接影响到端侧推理的吞吐量。
这些实测数据也让我养成了一个习惯：任何模型部署方案，先手工估算计算量和内存，再实测验证。估算能帮你预判，实测能告诉你真实情况，两者结合才能在设计阶段避开大坑，而不是等硬件跑起来才发现方案不可行。
5. 重学之路上的常见误解与避坑记录
5.1 拿嵌入式经验硬套神经网络，最容易犯的三个错
第一个错：用中断思维看待推理过程。有人觉得推理是个可以随时打断、恢复的操作，但实际上端侧推理是一个多层的连续计算流，中间状态巨大，无法像任务切换那样保存和恢复。你只能在推理前关中断，推理结束后再开，或者接受推理过程中的实时响应延迟。这个约束在系统设计时必须提前想清楚。
第二个错：只关注算力而忽略数据搬运。嵌入式工程师容易陷入主频和算力的对比，但端侧推理里数据搬运的代价往往比计算更大。片上 SRAM 可能只有几百 KB，而中间张量却有几 MB，这时候外部 Flash 或 SDRAM 的读写带宽会成为瓶颈。同样的模型，调整层的执行顺序，让数据在寄存器、SRAM、外部存储之间的搬运次数尽可能少，性能差异能拉开好几倍。
第三个错：不重视数据集和预处理。很多嵌入式工程师第一次跑模型，直接把摄像头采集的原始图像丢进去，然后发现识别率惨不忍睹。模型的训练数据是什么尺寸、什么颜色空间、做了什么归一化，部署端必须完全复现同样的预处理流程。比如训练时用的是 RGB 图像，你部署时喂进去的是 BGR 或 YUV，结果就会出问题。预处理不匹配导致精度丢失的概率，比量化本身还要大，这是我反复验证过的结论。
5.2 精度掉点排查优先级：先怀疑预处理，再怀疑量化，最后才怀疑模型
端侧部署后精度比训练时下降，是人人都要遇到的事情。我最初遇到时第一反应是量化精度损失，花了大量时间调量化参数，结果几乎没用。后来逐层比对才发现，问题出在输入预处理——训练时的归一化是减均值除方差，部署代码里写成了简单除以 255，分布对不上，所有激活值都偏移了。
完整的排查优先级应该是这样的：第一，检查输入预处理是否与训练时完全一致，包括尺寸缩放算法（resize 的插值方法都有影响）、颜色空间、归一化参数；第二，检查推理链路里是否有隐性的数据类型转换，比如某层接口把 INT8 转成了 FP32 导致精度变化；第三，检查量化配置本身，校准数据集是否合理、是否覆盖了真实场景的数据分布；第四，才轮到怀疑模型结构或训练是否充分。
还有一个容易忽视的点：端侧推理的随机性问题。受并发或中断干扰的影响，第一遍推理可能包含 warm-up 开销，处理时间会比后续慢很多。跑 benchmark 时要预热几次，取稳定值才客观。这些看起来是小事，但实测中坑过不少人。
5.3 给同样走在嵌入式转端侧 AI 路上的工程师几点实用建议
第一，不要贪多。别一上来就学目标检测、语义分割、Transformer，把图片分类里最简单的 CNN 结构彻底弄懂，一层一层手算过、部署过、优化过，比囫囵吞枣看十篇综述有价值得多。
第二，做实验，不要只看书。网上关于 CNN 的教程满天飞，但很多都停留在理论层面。真正的理解要建立在自己跑的每一层输出的 shape 变化、每组参数对精度和速度的影响上。动手验证是唯一能内化知识的方式。
第三，用你的嵌入式优势。这部分是你的护城河：对硬件的理解、内存管理的方法论、性能优化的测量习惯、系统级的资源调动能力。不要把时间花在和算法工程师比拼数学推导，而是聚焦在"如何把模型高效地塞进资源受限设备"这条路上。端侧 AI 越深入，越会发现它需要的是一名能把模型当"硬件"一样理解的人——这种人在纯算法圈子里反而稀缺。
第四，建立可复现的实验模板。我建议维护一套自己的部署复现工程：固定模型、固定数据集、固定板子，各种优化手段按顺序在上面做对比实验，记录时间、内存、精度三组数据。这就像一个测试平台，你的所有优化手段都可以在上面做对照实验，避免因为模型变化导致结论不可信。长期积累下来，你会拥有一套属于自己、经得起推敲的部署方法论，比翻来覆去看别人的总结可靠得多。
重学 CNN 这件事，做了大半年，回头看最大的收获不是会了多少新工具、新框架，而是在模型的每一层里建立了一种"直觉"——知道哪些参数影响精度，哪些地方拖慢速度，哪些结构在资源受限时可以先砍。这种直觉，恰恰是端侧 AI 落地中最稀缺的能力。如果你也在从嵌入式往端侧 AI 方向转型，希望你少走一些我走过的弯路，直接从"理解模型内部"开始出发。