嵌入式转端侧AI：从CNN原理到模型部署的实践指南

写这篇文章是因为我在从嵌入式开发转向端侧 AI 的过程中，积攒了不少“绕路”的经验。说实话，最初接到要在开发板上跑模型的需求时，满脑子都是疑问：为什么非要学 CNN？它跟嵌入式里熟悉的那些外设驱动、状态机有什么本质区别？直到自己真正把卷积网络理解透、量化完、部署到板子上跑起来，才意识到过去那些 RTOS、Linux 驱动、中断处理的经验并没有白费，它们恰恰是理解端侧 AI 的最佳底色。这篇总结想写给那些同样卡在“嵌入式如何进阶到 AI”路口的朋友，梳理一条从 CNN 入手的可行路径。

1. 转型的动机：嵌入式工程师为什么绕不开 CNN

1.1 端侧 AI 不是空中楼阁，底层还是嵌入式那套功夫

端侧 AI 的核心诉求，是在不依赖云端的情况下，把神经网络推理放到本地设备上执行。听起来跟嵌入式天然契合，因为嵌入式设备本来就在做本地计算。但真正把 AI 模型部署到单片机上时，你会发现它跟传统嵌入式开发的思维方式有很大差别。传统嵌入式关心的是寄存器配置、中断响应、总线时序；而端侧 AI 关心的是张量内存排布、算子优化、量化误差控制。这两套东西看起来风马牛不相及，实际上底层又紧密结合——你依然要面对 Flash 空间、RAM 容量、CPU 主频、外设带宽这些硬性约束。

我之前做过几年的嵌入式 Linux 项目，从驱动移植到 BSP 维护都跑过。起初觉得 AI 无非就是再加个 NPU 外设，用 API 调用就算了。等真正接触项目才发现，不深入理解 CNN 的结构和计算特性，根本没法做好模型选型和部署优化。比如选一个推理框架时要考虑的算子支持情况，背后的逻辑全是 CNN 里那些卷积层、Pooling 层、全连接层的组成。不懂这些，连文档都读不明白。

转岗或做技术转型的关键在于选对切入方向。我决定从 CNN 开始，主要是因为它是目前端侧视觉任务的基础模型结构，无论是分类、检测、分割，Base 结构里都大量使用卷积。学懂了 CNN 就能看懂大多数端侧模型的精髓，后续理解了 Transformer 等结构后也能触类旁通，不会像无头苍蝇一样乱撞。这个选择不是从零开始的冲动，而是基于十几年前搞过图像边缘检测、Sobel 算子的老本行经验才定下来的。

具体来说，CNN 的卷积操作本质就是一个“滑窗加权求和”，跟嵌入式里非常熟悉的 FIR 滤波、图像处理中常用的模板卷积是一家人。理解了这一层之后，整个端侧视觉模型的运作逻辑就能串起来。如果你也做过单片机处理传感器数据、做过 Linux 下视频采集这类工作，看到 CNN 一定会觉得“这不就是高级一点的滤波嘛”。这种熟悉感恰恰是转型最大的底气，不是重新学一门全新的学科，而是把你已有的硬件经验映射到新框架中。

1.2 端侧 AI 的实际落地场景，决定了你必须掌握什么

在端侧做 AI，总能碰到各种意想不到的应用需求。比如我接过一个 STM32 这样资源极受限设备上的手势识别需求，模型大小得压到 100KB 以内，RAM 占用不超过几十 KB，推理速度还要满足实时性。这类场景靠调用云端 API 永远解决不了，必须端侧搞定。类似的需求还有：

• 工业设备的预测性维护：通过电流、振动信号判断设备状态，往往需要一个小型 CNN 在 PLC 或边缘盒子上跑。
• 智能家居的人体检测、手势识别：隐私要求高，数据不出本地，模型必须跑到摄像头旁边的 MCU 或算力很一般的 SoC 上。
• 车载场景的分心驾驶检测：实时性要求极高，不能依赖网络的稳定性。

这些应用共同的特点是对功耗、成本、延迟都有严格约束，恰好是嵌入式工程师的主场。难点在于，以前嵌入式工程师没有太多接触神经网络模型内部结构的机会，所以很多人在看到模型文件时无从下手。但换个角度想，嵌入式工程师熟悉硬件资源、熟悉底层内存分布、擅长性能优化，这些能力恰恰是端侧 AI 工程师最稀缺的底子。补上 CNN 这块拼图之后，整个端侧 AI 的技能栈就闭环了。

2. 拾起 CNN：核心概念里隐藏的嵌入式思维

2.1 卷积、池化、全连接——全部可以映射成嵌入式老朋友

CNN 的基本组件无外乎卷积层、池化层、全连接层和激活函数。如果以嵌入式工程师的视角来看：

• 卷积层，可以理解成一种带学习系数的滑动滤波窗口。图像输入像一帧一帧的像素数据，卷积核像是你在代码里写死的一个滤波系数矩阵。区别在于这些系数不是人定的，而是从训练数据里学出来的。
• 池化层，本质上就是降采样。跟嵌入式里对 ADC 采到的数据进行抽取、求平均异曲同工。最大池化就是在窗口里取最大值，我觉得最直观的解释是“把图像缩小但保留最明显的特征”。
• 全连接层，则像是一个加权表决器。前面卷积层提取特征，全连接层把这些特征综合成最终分类结果。跟状态机里最终依据关键标志位输出某种动作的逻辑非常像。
• 激活函数，跟嵌入式里的限幅、钳位函数一脉相承。ReLU 就是大于零不变、小于零清零，跟做传感器数据截断的处理手法完全一致。

这个映射过程很重要。一旦建立起来，CNN 就不再是晦涩的数学公式，而是一套你早就用过无数次的数据处理流水线。学习时只需要关注一件事：这些层的参数是从哪来的、是怎么变的。这就是训练阶段做的事。嵌入式工程师不一定需要精通反向传播的数学推导，但需要理解训练出来的是一堆权重参数，部署时段的计算是固定的前向推理，这跟你在嵌入式里查表、用固定系数做校准是同一套思路。

2.2 感受野和权值共享，决定了端侧实现的可行性

CNN 能在资源受限端侧设备上落地的原因，一部分藏在权值共享上。一个 3x3 的卷积核，只有 9 个权重加上 1 个偏置，无论输入图像多大，卷积核的参数数量都是固定的。这一点跟传统全连接网络有天壤之别，全连接层的参数量随输入尺寸呈平方级增长，而卷积则能做到“参数数量不随输入尺寸变化”。

我算过一笔账：如果输入一张 224x224 的 RGB 图片，要直接用全连接网络把它拍平成特征向量，第一层就要有 224x224x3 约 150752 个输入节点。假设隐藏层只有 512 个神经元，这一层全连接的参数量就是 150752x512 约 7700 万个参数。以单精度浮点来算，光这一层的模型文件就要约 300MB，这对端侧设备来说完全不可接收。而一个 3x3 卷积层的参数连几千个都不到，这就是端侧视觉模型能落地的根本原因。

感受野的概念也好理解。每一个卷积输出像素，实际上看到的输入范围是有限的。比如第一层 3x3 卷积，输出像素的感受野就是输入图像的 3x3 区域。多层堆叠之后，高层网络能一次看到更大的范围。这个特性在端侧部署时意味着什么？意味着你不需要一次性把整张图片全放进内存，尤其在处理视频流时，可以一块一块地处理，滑动窗口式的算力调度和内存管理方式，嵌入式工程师再熟悉不过了。

提示：不要把感受野理解成物理尺寸，它只是抽象的输入映射范围。实际部署时，卷积操作通常还是基于完整的三维数据块来做的，不会真的一行一行去处理，因为在 CPU 上这种访问模式缓存命中率太低。更常见的是通过内存搬移优化，把卷积计算所需的输入块提前搬到连续的缓冲区里。

2.3 端侧部署时 CNN 的计算量与内存访问是绕不开的坎

CNN 在端侧落地有一对矛盾：计算量和内存访问。计算量通常用乘加运算次数 MACs 来表示，乘加次数跟卷积核大小、输入特征图尺寸、输出通道数都有关系。一个典型的 3x3 卷积，输出一个像素的一个通道，需要 9 次乘法加 8 次加法。如果输出特征图有 128 个通道，每个通道 112x112 个像素，那么这一层的计算量就可能达到数亿次。对于没有硬件加速器的裸 CPU 或者 MCU，这是一个相当大的负担。

我整理过一个实际案例的数据，帮你理解部署时的资源消耗到底怎么估算：

当然这只是粗略估算，实际时间取决于框架优化程度、是否启用 SIMD 指令、内存访问连续性等。但大致能看出一个规律：想让推理够快，要么把模型结构设计的非常紧凑，要么靠硬件加速单元分担计算压力。在嵌入式环境里，很多时候两者要同时考虑。

内存访问的问题更加隐蔽，但一旦踩坑就很容易引发性能雪崩。嵌入式内存带宽低、缓存小，如果张量的内存布局不合理，卷积操作会频繁发生 Cache Miss，导致计算单元空转，推理时间瞬间翻好几倍。这个问题我后面会专门展开说明。

3. 工具链与框架选型：从“能用”到“好用”的选择逻辑

3.1 嵌入式端侧 CNN 部署的主流框架对比

端侧 AI 部署不像服务器端那样只有一个成熟统一的方案，而是要根据目标硬件来选。从我的实际体验来看，主要框架集中在几个：

• 推理框架层面：TensorFlow Lite Micro 适合 MCU 级，ONNX Runtime 适合边缘算力较强的设备，NCNN 是国产开源、对 ARM CPU 优化效果很好，Tengine 在国产芯片上有不错支持。
• 模型转换流程：PyTorch 训练好的模型导出为 ONNX，再转换成各框架支持的格式，是当前主流程。Keras 训练出来后转 TFLite 也比较顺手。
• NPU 相关：各家芯片厂商几乎都提供自己的工具链，比如瑞萨、ST、爱芯元智等。它们一般都会提供从模型到平台指令的转换工具，但你必须消化它们对算子、动态形状的限制。

对你来说，选型要遵循一个原则：先定硬件再定框架，而不是反过来。如果你手头是一块 STM32F4，那大概率跑不了太大模型，更适合直接集成 CMSIS-NN 这类优化库，自己手写推理逻辑，或者用 TensorFlow Lite Micro。如果你用的是树莓派这类 ARM Linux 设备，NCNN 可能更好用，它对 ARM 平台做了大量汇编级优化。如果是带有 NPU 的 AI 芯片，就要优先使用芯片原厂工具链，但前提是模型里的算子原厂工具链都支持。

我一开始犯过严重的选择错误，拿着一个训练好的模型试图直接在某个不支持某些算子的框架里跑，结果各种报错，被迫改模型结构。后来学乖了：先把模型结构里用到的算子理一遍，再对照目标推理框架的算子支持列表，提前规避问题。这里分享一个最常用的算子关注点：端侧框架对 Sigmod、Tanh 这类激活函数不一定支持，往往建议换成 ReLU 或 ReLU6；Transpose 操作也可能在部分框架中不被支持，尽量不要在模型中随意加维度交换操作。

3.2 为什么我最终还是选了“老本行”思路来搭环境

在做端侧 CNN 部署时，我最终选定的方案是用 Python 训练模型，导出 ONNX，再用 NCNN 跑在 ARM Linux 平台上。整套链路熟练之后，再拓展到其他硬件也不算难。

这套链路的好处在于 NCNN 的设计理念跟嵌入式底层很贴合：无第三方依赖、代码精巧、内存管理透明。它还有一个 net.opt 配置文件，可以直接手动指定数据处理模式、量化模式，这在嵌入式工程师看来尤为亲切。因为你能直接看到框架层面做了哪些操作，出问题时可以顺着代码排查，而不是深陷在一个黑盒引擎中。

更重要的一点是，NCNN 的量化工具使用起来非常明了，它能直接读取普通浮点模型的参数，聚合成 int8 精度的静态表，再配合校准数据集，把推理过程中的激活值量化误差控制在一个合理范围。对于一个跑过大量 C 代码的嵌入式工程师来说，理解量化原理很快，核心思路跟 ADC 定标非常相似：把连续的浮点数值映射到离散的整数点上，关键是找好缩放系数和零点。

4. 实操拆解：从训练模型到端侧部署的完整链路

4.1 第一步：数据准备与轻量模型训练要点

端侧模型的训练跟普通深度学习模型的训练在抱着的心态上要有明显不同：不是为了刷高分类准确率，而是要在尽量小的模型上达到可用的精度。所以从数据集准备开始，就要为“轻量化”做规划。

假设目标是做一个简单的图像分类项目，比如区分螺丝和螺母，用于工业零件分拣辅助。数据不需要很多，每一种准备两三百张图片就足够起步了，但要确保覆盖不同光照、角度、远近。嵌入式工程师通常不太习惯管理数据集，但这一步不能省，我会用脚本把图片统一 resize 到 128x128，并做基础的归一化。训练时的输入尺寸会直接决定未来端侧推理时的计算量，128x128 是均衡算力和精度的常规起点。

模型结构的话，直接抄经典结构也不合适。我会用 3 到 4 层卷积加一层全连接，通道数压到 16 或 32，参数总量控制在 5 万以内。这样做的好处是后续部署到 STM32 级设备时也有一线希望。训练时正常用交叉熵损失、Adam 优化器，跑大概 20 到 30 个 epoch。如果你的训练数据量很小，正则化一定要跟上，否则很容易过拟合，导致端侧跑出来准确率跟训练时严重不符。

训练完成之后需要做一件事：导出模型并做推理验证。这个验证要在电脑上完成，但必须模拟端侧的输入尺寸和数据格式。很多嵌入式工程师第一次部署失败，就是因为实际推理时喂进网络的数据格式跟训练时不一致，比如通道顺序是 RGB 还是 BGR、是否做了标准化、mean 和 std 的值是否跟训练脚本一致。这些看起来琐碎的细节，恰恰是部署链路中出问题最频繁的地方。

4.2 第二步：模型转换与参数抽取

训练完成后，先把模型转到 ONNX。在 PyTorch 里用 torch.onnx.export 导出并不复杂，但常常被两个小问题卡住：

• 输入张量的形状必须用固定值，不能是动态 batch，否则后续转换工具无法推断中间层大小。
• 模型里如果有一些自定义操作，ONNX 不一定能识别，需要提前用标准算子重写。

导出 ONNX 之后，我用 NCNN 的官方工具 onnx2ncnn 转换成 ncnn 的格式。转换完成之后一定要打开生成的 param 文件看看，逐层检查算子类型、输入输出张量的维度，确认和原始模型一致。我曾经遇到过一个教训：模型里用了某个宽函数转换成多个基本算子，NCNN 转换后默认是能跑通的，但有些算子组在量化时会报错，后来是在 param 文件里手动把相关的算子改成支持的组合才解决。

转换完成后，如果目标平台内存寸土寸金，就要进入模型压缩环节。常用手段按优先级排序是：

1. 剪枝：把接近零的权重直接去掉，减少计算量，但实现复杂度较高。
2. 量化：从 float32 降到 int8，模型体积直接缩到四分之一，推理速度在支持 int8 算子的硬件上也能显著提升。
3. 知识蒸馏：拿大模型当老师，引导小模型训练，训练成本较高。

其中量化是性价比最高的一步。NCNN 提供一个量化工具，它会统计每一层激活值的 min 和 max，将浮点映射到 int8 范围。校准数据集不用太大，一百张到几百张代表性的图片即可。量化完之后一定要拿真实数据对比浮点模型和量化模型的输出差异，如果某个类别的置信度变化太离谱，说明所选校准数据不够有代表性，需要补充。

注意：量化不是免费的午餐。int8 模型在处理一些绝对值较小的细小纹理时，精度损失可能相当明显，尤其在全连接层接近输出端更敏感。建议量化后跑完整验证集，而不是只看几张样例图就下结论。

4.3 第三步：端侧推理代码的工程化改造

NCNN 的 C++ 接口部署集成其实不复杂，核心逻辑就几步：加载模型参数与权重，创建 Extractor，输入数据填进 in，调用 extract 取结果。但工程上要做的远不止这些。

嵌入式端侧上，数据从摄像头到网络输入层通常不是直接复制就完事的。摄像头输出可能是 YUV 格式，需要转换成 RGB，再缩放、归一化。这一步在嵌入式工程师眼里，本质就是老朋友：格式转换和图像缩放。可以用 OpenCV，也可以用自己写 NEON 优化代码。为了控制内存和追求效率，我一般自己写一个简单的转换函数，bgr 转 RGB、除以 255、再用 net 的输入格式填进去，避免引入 OpenCV 那套相对笨重的依赖。

推理完成后，要对输出进行后处理。分类模型的输出是一个概率分布，需要取 top-k 索引。检测模型需要做非极大值抑制 NMS，这些逻辑跟嵌入式里做的事件处理队列有相似之处。建议把前处理、推理、后处理三个步骤严格拆成独立函数，方便后续在任何一个环节做优化或者对接不同传感器。实测下来，很多端侧应用最终消耗的时间大头反而在前处理和后处理上，尤其是 NMS 在高分辨率输入时耗时非常夸张，设计模型时就有意识减少候选框数量能从中获益。

4.4 第四步：性能调优的具体参数与实测数据

部署完成后，经常被问“你的模型在板子上到底能跑多少帧”。其实帧率跟硬件关系巨大，同一份模在 A53 核心和 A76 核心上可能是三四倍的差距。所以调优时要针对你的具体平台做定向优化。

我在某个 ARM Cortex-A53 双核设备上部署过一个轻量分类模型，基线推理时间约 35ms，经过以下优化逐步提升到 18ms：

• 开启 NCNN 的 fp16 存储，让模型权重和中间激活用半精度。
• 设置合理的线程数，双核设备我用 2 个线程，试过 4 个反而变慢，因为上下文切换开销抵消了并行收益。
• 手动检查内存对齐，把输入张量按 128 字节对齐分配，减少缓存行拆分。
• 把后处理里的 NMS 代码用循环展开和查表替代分支判断。

真实工程里，优化是一个反复试错的过程。我习惯先把整个推理流程拆成几个阶段，分别打点计时：前处理时间、数据装载时间、单层卷积时间、全连接时间、后处理时间。用数据定位瓶颈，然后针对性地优化，远比你盲目开启各种编译优化选项有效。最后一个很有用的经验是：有了 NPU 不等于万事大吉，有时数据搬运到 NPU 的开销比在 CPU 上跑还大，如果模型很小、输入尺寸很低，还不如直接 CPU 推理。

5. 实战复盘：一次真实端侧视觉项目的经验教训

5.1 项目背景与整体方案

我完整参与过的一个项目是把一个工业质检模型部署到边缘盒子。盒子是 ARM 平台，跑 Linux，算力并不强，CPU 是四核 Cortex-A55，内存 2GB。需求是对流水线上的零部件做缺陷分类，判断表面有没有划痕、脏污、缺损。原始模型在服务器上训练时用的是 ResNet-18，精度相当不错，但部署到边缘盒子后，单张推理时间高达 1.5 秒以上，完全无法满足流水线节拍。

这个项目的教训非常典型：在服务器上训练一切正常，拿到端侧就发现又大又慢，被迫换模型。我后来做的第一步是把 ResNet-18 这类 Base 模型替换成自己设计的轻量 CNN，结构上参考 MobileNet 的深度可分离卷积思想。深度可分离卷积是 CNN 在移动端落地的关键结构之一，把标准卷积分解为深度卷积和逐点卷积，计算量能下降好几倍。

以 3x3、输入输出均为 32 通道的特征图为例，计算量对比如下：

一种直观的理解：标准卷积相当于每个输出通道都要对全输入通道做一次空间滤波，计算量很大；深度可分离卷积则先每个输入通道独立滤波，再用 1x1 卷积混合通道，相当于把“空间滤波”和“通道混合”拆成两步，总计算量显著下降。

换模型结构之后，精度从 ResNet-18 的 92% 掉到了 88%，但推理时间从 1.5 秒降到 220ms。通过量化到 int8，进一步降到 95ms。最后综合采取一些数据增强把精度拉回到 90%，整个项目才算真正达标。

5.2 踩过的坑：内存布局、多线程与精度损失

这个项目里踩的坑很有代表性，整理出来给大家参考：

• 内存布局引发的缓存效率问题：最初没有留意 NCNN 的内部张量格式，喂入数据用的是 CHW 顺序，而模型训练时也是 CHW。但某些层内部实现默认按 NHWC 更高效，导致卷积时大量缓存未命中。后来我在网络开头加入 Permute 算子，将数据格式调整为框架更高效的内存布局，推理时间直接降了 30%。
• 多线程计数超过物理核心：代码里默认把线程数设成了 4，但设备实际只有 4 核，其中还有系统占用。推理时的不稳定波动非常严重，后来固定使用 2 个线程并绑核，时间反而更稳定。
• 量化后模型输出异常：有类别的置信度几乎恒定在 0.5 附近，排查了很久发现校准数据集严重偏向正常样本，缺陷样本太少，导致激活值的统计范围不准确。补充缺陷样本重新校准后问题解决。

这些问题现在看来都不复杂，但当时每个都折腾了不少时间。如果你也要做类似项目，强烈建议在方案设计阶段就把任务场景跑通，提前用真实采样数据验证转换工具链的兼容性问题，避免把问题积累到最后一步集中爆发。

5.3 从数据到部署的全流程检查清单

以下检查表是我现在做端侧 CNN 项目时的标配流程，拿来就能用：

这套清单像极了嵌入式开发里的 Check List，每个环节都写清楚约束条件和验证标准。做端侧 AI 和做嵌入式项目在工程方法论上高度一致，这套从“不可能”到“可能”的经验，正是两者之间最值得互相迁移的东西。

6. 避坑指南与更进一步的方向

6.1 端侧 CNN 项目中最容易翻车的五个隐蔽问题

表面上的坑好躲，隐藏的问题才真的要命。我回顾自己踩过的以及帮别人排查过的端侧项目，抽出了几个隐蔽性很强的点：

• 数据对齐与 Endian 问题。不同芯片平台的字节序不同，模型文件转换后如果直接拷贝到新平台跑，权重解析出来乱七八糟。尤其是一些 MCU 平台是小端序，模型文件写死成大端序会导致输出完全乱掉。常见解决方案是在模型转换工具里指定字节序，或对权重文件做一次镜像翻转。
• 内存碎片化。在长时间不重启的设备上，反复分配和释放大块的模型推理内存会让堆碎片化严重，最终导致推理到某一次时分配失败。我建议启动时一次性把所有需要的大缓冲区申请好，后续复用这几块固定内存。
• 温差校正。工业现场环境温度变化大，传感器的输出特性会漂移，如果输入数据没有做额外的温度补偿，模型的置信度会慢慢下降。这听起来像是传统嵌入式问题，但在端侧 AI 场景也一样存在，因为输入数据的质量直接决定模型输出的可靠性。
• 模型更新机制。设备部署后模型要升级怎么办？我建议从一开始就在程序里设计一个“启动时检查模型版本”的机制，把模型文件和版本号一起打包，加载前校验哈希值。不要以为模型文件是只读的就没问题，文件系统损坏、升级中断都可能让你的设备直接变砖。
• 快速验证脚本。我每次拿到一台新端侧设备，第一件事不是立刻集成完整业务逻辑，而是先跑一个最小验证程序：加载模型，输入一张现成的测试图，看输出是否跟预期一致。这一步可以把框架不兼容、模型文件损坏、内存分配失败这类基础问题快速筛掉。

6.2 接下来值得钻研的方向：从 CNN 到更多端侧模型结构

当 CNN 基础打牢之后，端侧 AI 还有几条进阶方向值得探索。

轻量化结构设计是第一条。MobileNet 里的深度可分离卷积、ShuffleNet 的通道重排、GhostNet 的冗余特征生成，都是在 CNN 框架内做手脚的思路。理解了计算量、参数量与精度之间的关系后，你可以学着像搭积木一样设计适合特定硬件的模型结构。这也是最接近嵌入式工程师思维模式的方向之一，本质上就是在做资源约束下的优化设计。

注意力机制是第二条。现在很多端侧模型会嵌入简化版注意力模块，比如 SE 模块、CBAM 模块，在不显著增加计算量的前提下提升精度。这里的核心思想是让网络在不同通道、不同空间位置上“分配不同注意力”，逻辑上特别像嵌入式系统里中断优先级的概念。重要的事情优先处理，次要的事情降级处理，模型效率和识别精度同时受益。

Transformer 结构是第三条。它虽然以自注意力为核心，但在图像任务里经常借助 CNN 来构建 Patch Embedding，两种结构是紧密耦合的。理解了 CNN 再看 ViT 会顺畅很多，而目前端侧 Transformer 也在快速发展，将来会有更多设备跑起轻量 Transformer。到那时候，你现在打牢的 CNN 基础依然是理解整个系统的重要桥梁，不会被淘汰，反而会成为更大拼图的基础单元。

6.3 用嵌入式工程的思路来学 CNN：我的训练法

最后分享一个我向别人推荐过很多次的经验：用嵌入式工程的思路来学 CNN，效果会事半功倍。

具体做法是这样的：不要急着去啃各种理论推导，而是先搭起一条最小可用的部署链路。比如在电脑上跑通 MNIST 训练和推理，随后想办法把它在板上跑通，哪怕只是打印一个数字结果不涉及任何业务场景。链路通了之后，再用“改参数观察现象”的方式逐个拆解 CNN 的组件。把卷积核数量从 8 改到 16，看推理时间涨了多少、精度涨了多少；把卷积层从 2 层加到 4 层，看内存占用怎么变化。通过亲手修改模型，你才能建立起每个超参数对端侧资源的敏感性认知，这个过程和嵌入式工程师通过改定时器参数观察波形变化的经验路径很一致。

另外要刻意训练自己读模型结构图的习惯。端侧部署时，光看代码识别不出来模型结构，但打开 param 文件、画一张网络结构图，每一层输入输出的尺寸标出来，就能迅速定位哪些层是吃内存大户、哪些层是计算热点。把 CNN 结构图当成嵌入式系统的框图来读，是端侧 AI 工程师的核心技能之一。等到你能在一张模型结构图前一眼看出“这里会不会有量化波动风险、那里的计算量是不是冗余”时，这个转型就算是真正走通了。

写到这里，回想起当初自己面对一堆卷积公式时的迷茫，其实不过是因为没有找到跟已有知识体系的连接点。嵌入式工程师的能力积累不会浪费，CNN 里的每一个概念，几乎都能在硬件底层找到对应的影子。把学模型这件事，当成是在写一个新外设的驱动，慢慢就能得心应手。