1. 从嵌入式转向端侧AI，我为什么把起点压在CNN上

先交代一下背景吧。我之前一直在做嵌入式开发，单片机、RTOS、Linux驱动、裸机程序都折腾过，典型的嵌入式老路子。突然转端侧AI，很多同行问我第一反应是“要不要先上大模型”，或者“直接学TensorFlow部署行不行”。我的选择是回过头去，把CNN老老实实重新啃一遍。

这个决定不是拍脑袋。端侧AI的落地场景，视觉任务占了一大半——人脸检测、物体识别、缺陷检测、手势识别，这些基本都是CNN的活儿。哪怕现在大模型很火，真正能塞进摄像头、机器人、MCU里的推理任务，90%以上还是CNN架构或者CNN的变体。所以说到底，端侧AI的“地基”就是CNN，绕不开。

我给自己定了一条非常朴素的学习主线：看懂CNN的数学原理、手写一个能跑的CNN训练脚本、理解量化与剪枝、最后部署到真实的端侧硬件上。这篇文章就是我的阶段性复盘，把这条路上值得说清楚的东西都整理出来，包括原理、代码、部署流程、踩过的坑。如果你也是嵌入式背景想往端侧AI走，或者已经在做AI但想补硬件部署的课，这篇应该能帮你少走不少弯路。

必须说明，这里涉及的硬件型号、框架版本都是我实际用过的环境组合，不同厂商的SDK差异巨大，但核心思路和方法论是通用的，换一套板子照样能套用。

2. 为什么端侧AI的先修课是CNN，而不是别的

2.1 从视觉任务的基本盘说起

端侧AI的“端”，指的是手机、摄像头、机器人、车载设备、智能家电这些资源受限的终端设备。这些设备上的智能功能，看图说话是最多的：门锁上的人脸识别、工业产线上的缺陷检测、无人机上的目标跟踪、果园里的成熟度判断……这些任务天然是视觉任务，而视觉任务当前最成熟、最可控的模型就是CNN。

有人可能会说Transformer不是也很强吗，ViT（Vision Transformer）不是效果更好吗？确实，在算力充足的云端，ViT系列表现很好。但到了端侧，模型大小、推理延迟、内存带宽都是硬约束。ViT的自注意力机制计算量巨大，对内存访问的要求很高，在摄像头SoC、嵌入式GPU这类平台上优化难度比CNN高得多。反观CNN，卷积操作局部性强、参数共享、结构规整，特别适合定点量化、算子融合、硬件加速。几乎所有的端侧NPU——不管是手机SoC里的，还是独立AI芯片里的——第一优先支持的算子都是卷积，原因就是CNN在端侧生态里积累最深。

所以我给想转行的人一个很直接的结论：大模型可以以后慢慢学，但CNN必须现在先吃透。它是端侧AI的入场券，没有这张券，后面谈量化、谈算子优化、谈硬件适配都是空中楼阁。

2.2 嵌入式开发者学CNN的天然优势

说到这儿得聊一个很多嵌入式同行没意识到的事情：在座各位学CNN，其实比纯算法背景的人有优势。为什么？因为CNN的落地难点根本不在数学推导，而在工程化——如何让模型在内存有限的芯片上跑起来，如何减少推理延迟，如何处理浮点数转定点数的精度损失。这些恰恰是嵌入式开发者的日常。

举个例子，嵌入式开发天天跟内存打交道，堆栈大小、DMA缓冲区、帧缓冲区的分配，一个字节都要抠。CNN的模型参数、中间特征图也要占内存，怎么复用内存块、怎么减少峰值内存占用，这些逻辑和搞嵌入式内存优化如出一辙。再比如定点化，嵌入式开发对Q格式定点数再熟悉不过了，CNN量化就是把这套老手艺用到权重和激活值上。这些经验是算法工程师短期内补不上的，但你已经有了。

当然，劣势也很明显。嵌入式工程师普遍缺乏线性代数、概率统计的系统训练，对反向传播、梯度下降这些东西一开始会觉得抽象。我的经验是别看那种几百页的教材，先看代码，把一次前向传播、一次反向传播在纸上手推一遍，再对照框架源码看一遍，基本就通了。这个痛苦期大概两到三周就能熬过去，咬咬牙就过去了。

3. CNN核心知识点拆解，用嵌入式工程师听得懂的话讲

3.1 卷积层到底在干什么

CNN的名字就来自卷积操作。从信号处理的角度看，卷积就是两个函数的加权叠加；从图像处理的角度看，卷积就是一个“滑动窗口加权求和”的过程。想象一个手电筒在图像上扫描，每个位置照出一小块局部区域，这一小块区域和一个权重模板做点乘，得到一个输出值——这个权重模板就是卷积核，也叫滤波器。

对于一个嵌入式工程师来说，这个操作一点都不陌生。做过图像处理的应该用过Sobel算子做边缘检测，3x3的卷积核在图像上滑动，计算每个像素的梯度。CNN的卷积做的事本质上是一样的，只不过卷积核里的权重不是人手工指定的，而是训练过程中自动学出来的。低层卷积核可能学出了边缘、纹理，高层卷积核组合出眼睛、轮子这些复杂结构。

卷积层的几个关键参数，我用嵌入式开发能懂的术语解释一下：

• stride（步长）：类比DMA传输中的突发长度，决定了窗口每次滑多少格。步长越大，输出特征图越小，计算量越低，但空间信息丢失也越多。
• padding（填充）：类比缓冲区边界处理。不填充的话，图像边缘像素参与计算的次数比中间像素少，边缘信息容易被忽略。填充可以保持特征图尺寸不变。
• kernel size（卷积核尺寸）：类比滤波器的窗口大小。3x3是端侧最常用的尺寸，因为计算量小、感受野可以通过堆叠层数扩大，很多NPU都对3x3做了专门的硬件加速。
• 输入输出通道数：类比多路ADC通道。输入通道是上一层的输出通道数，输出通道是这一层用了多少个卷积核，每个卷积核负责提取一种特征。

一个卷积层的计算量大体是：输出特征图的长宽 × 输出通道数 × 卷积核尺寸 × 输入通道数。比如输入是 224x224x64，用64个3x3卷积核，步长1，输出也是224x224x64，那么这一层的乘加次数大约是224×224×64×9×64≈18.5亿次。这个数字在PC上几毫秒就完事了，但在很多端侧芯片上就得认真掂量掂量。

3.2 池化层、全连接层和感受野

池化层的作用是降采样，常用的是最大池化和平均池化。拿2x2最大池化来说，就是在一个2x2的小方块里取最大值，图像尺寸缩小一半，通道数不变。这就像嵌入式图像处理里的抽帧或降采样，目的是减少后续计算量，同时保留主要的特征响应。

全连接层则比较好理解，就是传统的神经网络层，每个输出节点和每个输入节点都有连接，本质上是一个矩阵乘法。在CNN里，全连接层通常放在最后，把卷积池化提取出的特征“汇总”成最终的分类结果。但注意，全连接层的参数量非常巨大——一个 7x7x512 的特征图展平后就有25088个值，如果接一个4096节点的全连接层，光这一层就有1亿个参数左右。在端侧部署时，很多方案都会把全连接层替换成1x1卷积，或者直接使用全局平均池化（GAP）来减少参数量。

感受野这个概念，嵌入式工程师可以用“摄像头视野”来类比。越靠近输出层的特征图上的一个像素，对应输入图像上的区域越大，这个区域就是感受野。堆叠多个3x3卷积层可以扩大感受野，两个3x3卷积堆叠等效于一个5x5卷积的感受野，但参数量更少（2×9 vs 25），而且中间多了非线性变换，表达能力强得多，这也是为什么现代CNN普遍用小卷积核堆叠而不是大卷积核。

3.3 从零手写一个简单的CNN训练脚本

说再多原理不如跑一个demo。我用PyTorch写了一个经典的CNN，用来做CIFAR-10分类。CIFAR-10是10类、32x32的小图片数据集，非常适合在本地快速验证模型。

import torch import torch.nn as nn import torch.optim as optim import torchvision import torchvision.transforms as transforms transform = transforms.Compose([ transforms.RandomHorizontalFlip(), transforms.RandomCrop(32, padding=4), transforms.ToTensor(), transforms.Normalize((0.4914, 0.4822, 0.4465), (0.2023, 0.1994, 0.2010)), ]) trainset = torchvision.datasets.CIFAR10(root='./data', train=True, download=True, transform=transform) trainloader = torch.utils.data.DataLoader(trainset, batch_size=128, shuffle=True, num_workers=2) class SimpleCNN(nn.Module): def __init__(self): super().__init__() self.features = nn.Sequential( nn.Conv2d(3, 32, kernel_size=3, padding=1), nn.ReLU(inplace=True), nn.MaxPool2d(2), nn.Conv2d(32, 64, kernel_size=3, padding=1), nn.ReLU(inplace=True), nn.MaxPool2d(2), nn.Conv2d(64, 128, kernel_size=3, padding=1), nn.ReLU(inplace=True), nn.MaxPool2d(2), ) self.classifier = nn.Sequential( nn.Flatten(), nn.Linear(128 * 4 * 4, 256), nn.ReLU(inplace=True), nn.Linear(256, 10), ) def forward(self, x): x = self.features(x) x = self.classifier(x) return x model = SimpleCNN() criterion = nn.CrossEntropyLoss() optimizer = optim.Adam(model.parameters(), lr=1e-3) for epoch in range(30): running_loss = 0.0 for i, (inputs, labels) in enumerate(trainloader): optimizer.zero_grad() outputs = model(inputs) loss = criterion(outputs, labels) loss.backward() optimizer.step() running_loss += loss.item() print(f'Epoch {epoch+1}, Loss: {running_loss / len(trainloader):.4f}') torch.save(model.state_dict(), './simple_cnn.pth')

这个代码在普通的笔记本GPU上，30个epoch大概十几分钟就能训完，测试精度能到75%左右。重点不是追求刷榜，而是通过调试这个代码，把卷积层的维度变化、反向传播的梯度流、loss收敛趋势这些基本概念彻底搞明白。我特别建议新手在这里做一件事：打印出每一层输入输出的shape，亲眼看看数据是怎么一层层变小的，这比看十遍理论都有用。

从训练到端侧部署，中间还有一道关键的桥梁——模型导出和格式转换。我把这个单独拿出来讲，因为它卡住了很多人。

4. 端侧AI部署的关键环节：模型导出、格式转换与量化

4.1 端侧AI的硬件选型

先聊选型，因为部署方式完全取决于目标硬件。端侧AI硬件大概分三个档次：

低端MCU级别，运行内存几十到几百KB，主频几十到几百MHz，一般没有专门的AI加速器，只能跑极度压缩后的极小模型，或者只做简单的特征提取，比如关键词唤醒、手势识别这类。这档主要用CMSIS-NN这类纯软件优化库跑网络。

中端摄像头SoC或应用处理器级别，这是端侧AI的主战场。这类芯片一般带NPU或者GPU，内存从几十MB到几GB，能跑YOLO系列、MobileNet这类主流视觉模型，智能摄像头、无人机、机器人基本都是用这一档。部署工具一般是厂商自带的SDK，比如各种神经网络编译器或者推理引擎。

高端手机SoC级别，算力更强，内存也更大，能跑比较大的模型甚至部分大模型，但功耗和成本都不是一般嵌入式项目能承受的。

我给个表格，直观点对照：

我做测试用的是一块带NPU的中端SoC开发板，算力大概3TOPS左右，内存2GB。这个配置跑CIFAR-10训练出来的简单CNN绰绰有余，实际上我后来部署的是一个轻量的人脸检测模型，推理延迟能做到20毫秒以内。

4.2 模型导出与格式转换

训练好模型之后，第一步是把它从PyTorch格式导成通用的中间格式，目前最通用的是ONNX。一个最基本的坑：模型导出时，输入尺寸必须是固定的，因为端侧推理引擎在编译计算图时，需要确定每一层的输入输出尺寸。训练时常见的动态维度——比如batch size不确定、输入图片尺寸可变——在端侧不允许。所以导出前要确保模型输入是一个固定的形状。

导出的代码很简单：

import torch from simple_cnn import SimpleCNN model = SimpleCNN() model.load_state_dict(torch.load('./simple_cnn.pth', map_location='cpu')) model.eval() dummy_input = torch.randn(1, 3, 32, 32) torch.onnx.export( model, dummy_input, './simple_cnn.onnx', opset_version=11, input_names=['input'], output_names=['output'] )

注意model.eval()这一步，必须加，不然后端推理时模型里如果有BatchNorm、Dropout这类层，行为会和训练时不一致。BatchNorm在训练时用的是mini-batch的统计量，推理时要用全局统计量，eval模式就是切换这个。

拿到ONNX之后，还要过推理引擎这一关。我用的后端是那个开发板自带的推理框架，各家SDK不同，但入口一般是把ONNX转成平台自己的模型格式。如果你的板子不支持ONNX直转，有一个通用后备方案：先转成通用的中间表示，比如TFLite，再通过TFLite的转换工具进一步适配各种硬件。

4.3 量化：把浮点模型变成硬件认识的整数

模型导出只是格式问题，量化才是性能分水岭。CNN训练时用FP32浮点数，权重和激活值都是32位浮点。但大多数NPU只支持INT8甚至更低精度的整数运算，原因很简单：整数运算的硬件电路比浮点小得多、快得多、省电得多。把一个乘加单元从FP32改成INT8，面积大约可以缩小到原来的四分之一，功耗更是大幅下降。

量化的核心思想是：把浮点数范围内的取值映射到有限个整数级别上。比如用一个scale（缩放因子）和zero_point（零点）来完成映射。训练后量化（Post-Training Quantization）是最省事的方案，训练完的模型喂一些校准数据，统计出每层激活值的分布范围，然后计算出最优的scale和zero_point，就能把权重和激活值从FP32压到INT8。

实际操作时，校准集选多少张图片比较合适？我的经验是200到500张有代表性的就够了，太少统计不准，太多浪费时间。校准图片要覆盖模型现实场景中的典型输入——做人脸检测就用不同光照、不同角度的人脸图，别用Imagenet的自然风景图去校准，否则激活值分布一偏，量化后的精度损失会非常明显。

量化后的模型大小直接缩到四分之一。我的simple_cnn原模型大概2.2MB，INT8量化后变成了550KB左右。对于端侧部署来说，这个体积好处不止是省Flash，同时内存带宽压力也小了——推理时模型权重从内存搬运到计算单元的时间大幅缩短，整个推理延迟显著下降。

量化最怕的是精度崩掉。轻度精度下降（比如几个百分点的准确率损失）是正常的；但如果掉了十几个点，那就是量化做得不对，常见原因有三个：一是校准集没有代表性，二是某些层对量化非常敏感，三是模型里有奇怪的算子被粗糙地量化了。解决办法是在pytorch里打开per-channel量化（逐通道量化），也就是按卷积核的每个输出通道分别计算scale，而不是整个张量共享一个scale。逐通道量化在乘加计算时不增加额外开销，因为scale可以在编译时合并进权重，所以工程上是划算的选择。

4.4 端侧推理框架和常见算子约束

整个部署流程的另一个大坑是算子支持范围。你的PC上的PyTorch能跑的算子有上千个，但端侧推理引擎支持的算子可能只有几十个到上百个，很多高级操作——某些不常用的激活函数、Deformable Convolution、复杂的张量变换——在端侧引擎里根本不存在。

我建议在模型设计阶段就养成“端侧友好”的意识：

• 激活函数能用ReLU就用ReLU，ReLU几乎是所有NPU都无条件支持的。
• 避免使用Softmax以外的复杂归一化操作，LayerNorm、InstanceNorm在部分端侧引擎上支持得并不好。
• 上采样操作优先用最近邻插值，而不是双线性插值，因为前者的计算图更简单。
• 尽量避免动态分支、循环结构，端侧推理引擎对静态图的支持远好于动态图。

从ONNX转到端侧模型时，工具会提示某个算子不支持的报错。遇到这种情况不要慌，先查算子在端侧工具链的算子清单里是否有替代实现，或者修改网络结构——比如把不支持的激活函数换成一个近似但等价的组合——再不行就在PC端先用脚本把图结构改掉，重新导出。我碰到过不少算子不支持的情况，最常见的还是在对BatchNorm做融合时出问题——正常情况下，推理引擎会把BatchNorm的缩放和平移融合进前一层卷积的偏置里，但如果卷积层和BatchNorm之间的连接被某个不支持的操作断开了，融合就失败，运行速度就会明显变差。

5. 从嵌入式到端侧AI的实操路线与避坑手册

5.1 我实操过的完整部署链路

我拿一个行人检测模型做例子，把从训练到板端推理的完整链路走一遍，每一步都标注了要注意的细节，方便你直接照做。

第一步，模型选型。端侧做行人检测最常用的是轻量化的YOLO系列变体，比如YOLOv5n或者YOLOv8n。模型大小大约5到10MB，算力需求集中在0.5到2TOPS区间，中端SoC刚好能跑。选模型的准则是：先定硬件的算力和内存上限，再去挑在这个上限内精度最好的模型，而不是反过来先选模型再找硬件。

第二步，准备训练环境。我用的还是PyTorch，因为这个生态最成熟，预训练模型和社区资源最丰富。如果走MobileNet或ResNet这类分类任务，还可以考虑用框架自带的预训练权重做迁移学习，行人检测这种目标检测任务一般就用对应检测框架自带的预训练权重。

第三步，训练。在终端设备的场景下，我的做法是先在自己采集的数据集上进行二次训练，让模型适应目标场景，比如特定的摄像头角度和光照。训练过程中的关键超参数——学习率、batch size、锚框尺寸——可以参考模型的默认配置，但一定要根据你自己的数据集分布调整锚框。不做这步，模型在你自己场景下的检出率会打折扣。

第四步，导出到ONNX。这一步的坑我已经在上面讲过了，主要就是固定输入尺寸、切换eval模式。检测模型还需要额外注意输出层：YOLO的输出不止是分类结果，还有检测框的坐标和置信度，导出时要搞清楚每个输出张量的含义和维度顺序，因为后面在端侧做后处理时要用到这些信息。

第五步，转换到端侧模型格式并量化。不同厂家的工具链不同，但流程都是先做算子映射，再做定点化。我在这一步会重点检查两件事：一是算子是否全部映射成功、有没有落到CPU回退的路径，一旦有算子走CPU回退，推理速度会掉得很明显；二是量化后精度测试结果，用一个标注好的验证集对比量化前后模型的mAP，下降不超过2-3%是可以接受的。

第六步，写板端推理代码。这一步嵌入式背景的优势就充分发挥了。主要工作是：初始化推理引擎、申请输入输出内存缓冲区、加载图片并做预处理（缩放、减均值、除方差、CHW布局转换）、调用推理接口、对输出做后处理（解析检测框、做NMS）、把结果显示出来或传给业务逻辑。内存缓冲区的申请和复用、Cache一致性处理、图像数据的对齐和填充，这些全是嵌入式的老本行。

第七步，性能调优。精度和速度都达标后，还要看功耗和内存。用功耗仪测不同帧率下的功耗，用性能分析工具看NPU的利用率。如果NPU利用率低，通常意味着预处理或后处理在CPU上耗时太长，成了瓶颈；或者数据搬运的内存带宽是瓶颈。针对前者，优化图像缩放和归一化的并行度；针对后者，把输入图像和输出结果的数据格式对齐NPU要求，减少不必要的内存拷贝。

5.2 嵌入式开发者转型过程中的四个思维陷阱

转型过程中，我观察到最常见的思维陷阱有四个，这里一个个说清楚。

第一个陷阱是不习惯“数据驱动”的开发方式。嵌入式开发通常是确定性的：你写了什么代码，硬件就执行什么行为，一切都可预测。但AI不是这样，模型的行为由数据决定，同一个模型在不同数据集上可能表现完全不一样。我在调试检测漏报时，第一反应是查代码逻辑，后来才发现是训练数据里某个场景的样本太少，根本不是代码的问题。转型的关键之一是接受“性能问题可能来自数据”这种不确定性。

第二个陷阱是低估数据预处理的重要性。对嵌入式开发者来说，把摄像头图像喂给模型，看起来就是取帧、缩放、喂进去就完了。但实际上，训练时的预处理和推理时的预处理必须完全一致——包括像素归一化的方式、缩放的插值算法、颜色通道顺序。我以前犯过一个低级的错：训练时用OpenCV读图，默认是BGR通道顺序，相关代码也按BGR设计了，但后来换了推理框架后，框架默认读进来直接当RGB处理了，结果模型在真实场景里精度惨不忍睹。排查了大半天，罪魁祸首就是一个通道顺序。

第三个陷阱是忽略端侧后处理的成本。模型推理跑在NPU上非常快，但很多人只优化模型推理时间，忽略了前后处理时间。一个典型的例子：模型推理只用10毫秒，但从摄像头取帧、把图像缩放到模型输入尺寸、转成模型要求的数值格式、再把结果解析回可用的检测框，总共CPU耗时可能高达50毫秒。对摄像头30FPS来说，这个时间预算完全不够用。我自己踩过一个典型的坑：一开始天真地用通用图像库的API做缩放，没有做硬件加速，每帧要吃掉30多毫秒，后来改成硬件加速的缩放接口，处理时间直接降到3毫秒。优化前后处理这件事，往往是端侧AI性能优化的最大空间所在。

第四个陷阱是用“PC思维”衡量部署难度。在PC上用PyTorch跑NN推理，几行代码就完事，但在端侧，你要查芯片手册确认内存对齐要求、要做Cache刷新、要处理模型文件的字节对齐、要确认DRAM和NPU之间数据搬运的位宽。这不是代码风格问题，是工程问题。好在这部分本来就是嵌入式的强项，只是很多人一开始没意识到自己的经验在这里是值钱的。

5.3 端侧推理引擎选型速查

聊完链路和陷阱，再给一个推理引擎的选型参考表。这里不针对具体厂商，纯粹从工程使用角度分析。

选型原则不复杂：如果你的硬件有厂商SDK，优先用厂商SDK；如果厂商SDK不成熟或者有迁移需求，就用一个社区活跃的通用框架；如果目标是MCU这种极端环境，就得直接考虑纯手工优化的推理实现。

5.4 常见问题排查实录

把我在实际部署过程中遇到的典型问题整理成一个速查表，这些都是实战中真正会把人气死但在网上又很难搜到答案的问题。

第一个问题是模型转换时提示算子不支持。排查思路是：先看报错中提到的算子名称，去算子支持文档查是否支持，不支持就回到模型源码，把这个算子替换成支持范围内的等价实现，重新导出。我的经验是，模型在定义阶段就避免NMS、自定义损失函数这类操作出现在前向图里，把它们放到后处理环节，推理图就是干干净净的卷积、池化、激活和全连接。

第二个问题是转换时提示张量维度动态、无法静态化。排查思路是检查模型里有没有用变量作为输入维度，比如自适应池化层，或者要求动态batch的接口。解决办法是固定输入尺寸，把自适应池化层替换成普通池化层，把动态shape全部改成显式shape。

第三个问题是量化后精度大幅下降。这个最让人头疼，排查优先级从高到低为：先怀疑校准集有没有代表性——换成和真实场景更接近的图片重做校准；再开启逐通道量化模式；最后查有没有特殊层对量化敏感，比如某些结构里的ELU激活函数或者大的动态范围的层，对这种层可以尝试跳过量化、保留浮点计算，虽然牺牲一点速度，但精度能保住。

第四个问题是板端推理耗时远超预期。排查顺序：先确认有没有算子走了CPU回退——通过工具链的profiling报告一眼就能看出来，有的话优先替换；然后查预处理和后处理是不是在大幅消耗CPU——通过定时器分段统计，定位到具体函数；再查内存拷贝次数——比如每帧有没有在CPU和NPU之间多次搬运数据，尽量减少不必要的拷贝。

第五个问题是频繁推理时出现内存分配失败。这个在嵌入式里太常见了，根源是推理引擎每次调用都会尝试申请新的内存缓冲区，没有复用已有的缓冲区。解决办法是构建一个全局的内存池，在模型初始化阶段一次性分配好所有需要的缓冲区，推理过程中不再动态分配，只在结束时释放。这个思路和嵌入式开发里的内存池如出一辙，完全是常规操作。

5.5 给零基础入门者的三个月路线图

如果你也是嵌入式背景，刚决定走端侧AI的路，我给一个比较切实的三个月路线。

第一个月主攻CNN原理和基础代码。花两周把卷积、池化、全连接、反向传播这些概念的代码实现一遍，不要求效率高，只要求真正理解前向和反向的每一步在干什么。再用一周训练一个小型CNN跑通MNIST或者CIFAR-10，最后留一周把模型导出成ONNX，在PC上用ONNX Runtime做一次纯CPU推理。

第二个月主攻量化与推理框架。训练一个MobileNetV2或自己设计的轻量分类网络，用训练后量化的方式压到INT8，对比量化前后的精度和模型体积差异。同时上手一个通用端侧推理框架，在PC上模拟端侧的部署流程，把转换、编译、推理、性能测试的完整流程跑通。

第三个月上真实硬件。找一块带NPU的开发板，从头部署一个目标检测模型，完成摄像头取流、预处理、推理、后处理、结果显示完整闭环。这个阶段不要追求复杂模型，只要让流程完整跑起来就可以。然后再用一周的时间分段优化延迟，把整个pipeline的性能拉高，重点调试前后处理和内存拷贝。

这个路线图的核心逻辑是：先懂原理、再懂工具、最后懂硬件。每一步的产出都要是“能跑起来的代码”，而不是“看过读过”的知识点。我见过很多人卡在原理层面，整天看书推导，就是不肯动手写代码，这样三个月下来基本还在原地。

6. 一点个人的体会

坦白说，从嵌入式转到端侧AI，最难的不是学到新的知识，而是接受一种新的调试方式——之前调bug可以靠断点一步步跟踪，现在很多时候只能靠数据和概率来定位问题，一开始确实相当不适应。我个人的建议是不要试图一口气把所有东西都搞懂，先把一条链路完整跑通，信心建立起来，再回头加深原理，会更顺一些。另外，一定要多跑板子上的真实推理，别偷偷待在舒适的PC环境里不动。端侧AI真正的功力，全都是在具体的芯片平台上一次一次踩坑踩出来的。