3、模型选型与优化：边缘场景下的模型选型原则
边缘AI芯片部署，说白了就是一场“戴着镣铐跳舞”。
你想想看，服务器端你可以堆算力、堆内存，模型再大也不怕。但在边缘端，芯片就那么点功耗，内存就那么几百兆，甚至几十兆。模型选型选不好，后面所有工作都是白费。
我个人习惯，拿到一个边缘部署项目，第一件事不是看算法，而是先看芯片的算力墙和内存墙。这两堵墙决定了你能跑什么模型。
3.1 边缘场景下的模型选型原则
选模型，我总结了三句话：算力匹配、内存够用、精度达标。
具体来说，有这几个原则：
- 参数量要小：边缘芯片的SRAM通常只有几MB，模型参数一多，就得频繁搬运数据，功耗和延迟都上去了。
- 计算量要低：MACs（乘加运算次数）是硬指标。MobileNet的深度可分离卷积，就是专门为低算力量身定做的。
- 支持量化友好：有些模型结构对INT8量化不敏感，比如ReLU6激活函数就比ReLU更稳定。我踩过坑，后面细说。
- 推理框架兼容：选模型前，先确认你的推理引擎（比如TensorRT、ONNX Runtime、TFLite）是否原生支持。
核心观点：边缘部署，模型选型不是“选最好的”，而是“选最合适的”。
3.2 主流轻量级模型对比
我这些年接触最多的三类轻量模型：MobileNet、YOLO-Lite、TinyML系列。它们各有各的脾气。
| 模型 | 典型参数量 | 适用场景 | 量化友好度 | 我的评价 |
|---|---|---|---|---|
| MobileNetV3 | ~2.5M | 分类、特征提取 | 高（ReLU6 + h-swish） | 稳，适合做基座 |
| YOLO-Lite | ~5M | 目标检测 | 中（需调参） | 速度快，但小目标容易丢 |
| TinyML（如Tiny YOLO） | ~0.5M | 极低功耗场景 | 高 | 精度有限，但能跑在MCU上 |
我记得有一次做智能门锁项目，芯片是Cortex-M7，只有512KB RAM。当时团队想用YOLO-Lite，我一看参数量5M，直接否了。最后选了Tiny YOLO，量化后模型才300KB，跑起来刚刚好。
小技巧：如果芯片支持硬件加速（比如NPU），优先选结构规整的模型。MobileNet的深度可分离卷积，在NPU上效率极高。
3.3 模型量化：INT8与FP16
量化，说白了就是把模型从“高精度浮点”压缩成“低精度整数”。
为什么要做？因为边缘芯片的算力有限，INT8的运算速度通常是FP32的2-4倍，内存占用也直接减半。
3.3.1 INT8量化
INT8量化是最常用的。我习惯用对称量化，公式很简单：
q = round(r / scale)
r = q * scale其中 scale 是缩放因子。实际部署时，我会先跑一个校准集，统计激活值的分布，然后确定最佳的 scale 和 zero_point。
我曾经在量化一个YOLO-Lite模型时，发现检测框全偏了。排查了半天，原来是某些层的激活值分布太宽，量化后信息丢失严重。后来我改用逐通道量化（per-channel quantization），问题就解决了。
避坑指南：INT8量化后，一定要做精度验证。如果精度下降超过1%，建议回退到FP16，或者做量化感知训练（QAT）。
3.3.2 FP16量化
FP16量化比INT8简单得多，几乎不需要校准。如果你的芯片支持FP16（比如NVIDIA Jetson系列），直接用就行。
但要注意：FP16的数值范围比FP32小，训练时如果梯度爆炸，FP16会直接溢出。我一般会在训练脚本里加一个 loss scaling 操作。
3.4 模型剪枝与蒸馏
这两个技术，我经常搭配使用。剪枝负责“瘦身”，蒸馏负责“补课”。
3.4.1 模型剪枝
剪枝分两种：结构化剪枝和非结构化剪枝。
- 结构化剪枝：直接剪掉整个通道或卷积核。好处是硬件友好，但精度下降明显。
- 非结构化剪枝：剪掉权重中的小值。精度保留好，但稀疏矩阵在边缘芯片上加速效果有限。
我个人更推荐结构化剪枝。比如对MobileNet，我会剪掉那些L1范数小的通道。剪枝后微调3-5个epoch，精度基本能恢复。
3.4.2 知识蒸馏
蒸馏的核心思想：用一个大模型（教师）教一个小模型（学生）。
我常用的蒸馏损失函数：
loss = alpha * CE(y_student, y_true) + (1 - alpha) * KL(y_student, y_teacher)其中 alpha 一般取0.7，KL 是KL散度。教师模型的软标签（soft label）能提供更多信息，学生模型学起来更快。
我记得有个项目，学生模型只有教师模型的1/10大小，但通过蒸馏，精度只掉了0.3%。效果非常惊艳。
3.5 ONNX模型转换与优化
ONNX是模型转换的“通用语言”。不管你是PyTorch、TensorFlow还是Keras，最终都转成ONNX，再部署到边缘芯片上。
3.5.1 转换步骤
以PyTorch转ONNX为例：
import torch
import torch.onnx
model = torch.load('model.pth')
dummy_input = torch.randn(1, 3, 224, 224)
torch.onnx.export(
model,
dummy_input,
'model.onnx',
opset_version=11,
input_names=['input'],
output_names=['output'],
dynamic_axes={'input': {0: 'batch_size'}}
)这里要注意 opset_version。我一般用11或13，太老的版本不支持一些新算子。
3.5.2 ONNX优化
ONNX模型导出后，我还会做两件事：
- 常量折叠：把固定计算提前算好，减少推理时的计算量。
- 算子融合：比如把Conv + BN + ReLU融合成一个算子，减少内存访问。
这些操作可以用 onnx-simplifier 和 onnxruntime 的优化工具完成。
经验之谈：ONNX转换后，一定要用 onnxruntime 跑一遍推理，验证输出是否一致。我见过太多人转完模型直接部署，结果推理结果全是错的。
3.6 本章知识体系图
下面这张图，是我梳理的模型选型与优化全流程。你可以把它当作一个检查清单。
嗯，这张图基本覆盖了从选型到部署的完整链路。你实际做项目时，可以按这个流程一步步走，基本不会漏掉关键环节。
最后提醒一句：模型优化不是一锤子买卖。很多时候需要反复迭代——量化后精度掉了，就回去调剪枝策略；剪枝后模型变小了，但速度没提升，就检查一下算子是否被硬件加速。别怕麻烦，边缘部署本身就是个精细活。
公众号:蓝海资料掘金营，微信deep3321