第2章模型移植全流程

第2章：模型移植全流程——从训练到推理的完整链路

大家好，我是你们的老朋友。今天咱们聊聊模型移植的完整流程。

说白了，就是把一个在服务器上跑得飞快的模型，塞进一个资源受限的嵌入式设备里。这个过程，我把它拆成四个环节：训练→转换→量化→部署。每个环节都有坑，我一个个说。

2.1 模型训练：起点决定终点

模型训练这一步，很多人觉得跟移植没关系。其实大错特错。

我个人习惯在训练阶段就考虑部署。为什么呢？因为训练时的很多选择，直接影响后面能不能顺利移植。

关键点：训练时就要为部署留后路

算子选择：尽量用标准算子，别用自定义OP。我在项目中遇到过，一个自定义的"特殊池化"层，转换工具死活不支持，最后只能手写C代码替代，折腾了两周。
输入尺寸：固定输入尺寸比动态尺寸好移植。你想想看，动态尺寸意味着内存分配要灵活，嵌入式设备哪有那么多资源给你折腾。
精度要求：训练时用FP32，但心里要清楚，最终部署大概率是INT8。所以训练时可以考虑量化感知训练（QAT），后面量化时损失会小很多。

嗯，这里要注意：训练时别用太花哨的trick。比如那种训练时才用的Dropout、BatchNorm的training模式，转换时很容易出问题。

2.2 模型转换：格式的"翻译官"

模型训练好了，是PyTorch的.pth或者TensorFlow的.pb。但嵌入式设备不认识这些格式。它们只认ONNX、TFLite、NCNN、MNN这些。

所以，转换就是做一次"翻译"。

我的经验：ONNX是中间格式的首选

我曾经在项目里试过直接从PyTorch转NCNN，结果各种报错。后来老老实实先转ONNX，再转NCNN，一路顺畅。ONNX就像一个通用语言，各家工具都支持。

转换时常见的坑有哪些？

算子不兼容：PyTorch里的某个算子，ONNX里没有对应实现。这时候要么换算子，要么手写自定义算子。
动态shape问题：模型输入是动态的，但转换工具要求静态shape。我建议训练时就固定输入尺寸，省得后面麻烦。
控制流问题：if-else、循环这些，转换时容易出幺蛾子。能避免就避免。

# 一个简单的PyTorch转ONNX示例
import torch
import torch.onnx

# 假设model已经训练好
dummy_input = torch.randn(1, 3, 224, 224)
torch.onnx.export(
    model, 
    dummy_input, 
    "model.onnx",
    input_names=['input'],
    output_names=['output'],
    dynamic_axes={'input': {0: 'batch_size'}, 'output': {0: 'batch_size'}}
)
print("转换完成，保存为model.onnx")

你看，代码很简单。但实际项目中，我经常遇到导出时某个算子不支持，然后得回去改模型结构。所以，转换这一步，我建议提前做个小规模的"试转换"，别等整个模型训练完了才发现问题。

2.3 量化压缩：给模型"瘦身"

模型转换完了，但体积还是太大。一个ResNet-50的FP32模型大概100MB，嵌入式设备哪装得下？

所以，量化压缩就派上用场了。

量化的本质：用更少的bit表示参数

FP32转INT8，模型体积直接缩小4倍。推理速度也能提升2-4倍。代价是精度会掉一点，通常1-2%以内。

量化方式主要有两种：

量化方式	原理	精度损失	适用场景
训练后量化（PTQ）	训练完成后，用校准集统计量化参数	较小（1-3%）	大部分场景
量化感知训练（QAT）	训练时模拟量化效果，让模型适应低精度	很小（<1%）	对精度要求高的场景

我个人习惯：先试PTQ，如果精度掉得太多，再上QAT。毕竟QAT需要重新训练，时间成本高。

避坑指南：量化不是万能的

我曾经在一个语音识别模型上做量化，结果精度掉了5%以上。后来发现是模型里有些层对精度特别敏感，比如某些激活函数。解决办法是：对这些敏感层保持FP32，其他层用INT8。这叫"混合精度量化"。

量化时还要注意：校准集的选择很重要。校准集要能代表真实数据分布。我见过有人随便拿100张图做校准，结果量化后模型在真实场景下表现很差。

2.4 部署推理：最后一公里

模型量化完了，终于可以部署到设备上了。

这一步，说白了就是把模型加载到嵌入式设备的内存里，然后用推理引擎跑起来。

常见的推理引擎有：

NCNN：腾讯出品，轻量级，ARM平台优化好
MNN：阿里巴巴出品，支持多平台
TFLite：Google出品，生态好
TensorRT：NVIDIA出品，GPU平台首选

部署时，我建议注意以下几点：

内存管理：嵌入式设备内存有限，要提前规划好模型参数、中间结果、输入输出的内存分配。我习惯用内存池，避免频繁malloc/free。
推理速度：用推理引擎的profiling工具，找出瓶颈层。有时候一个卷积层就占了80%的时间，可以考虑用Winograd算法加速。
多线程优化：现代嵌入式CPU都有多核，合理利用可以大幅提升速度。但要注意线程同步的开销。

// NCNN推理示例（C++）
#include "net.h"

ncnn::Net net;
net.load_param("model.param");
net.load_model("model.bin");

ncnn::Mat in = ncnn::Mat::from_pixels(image_data, ncnn::Mat::PIXEL_BGR, 224, 224);
ncnn::Extractor ex = net.create_extractor();
ex.input("input", in);

ncnn::Mat out;
ex.extract("output", out);

// 处理输出结果
float* data = (float*)out.data;
// ... 后处理逻辑

你看，代码量不大。但实际部署时，我遇到过各种奇怪问题：内存对齐不对导致崩溃、线程池配置不合理导致死锁、模型文件路径写错导致加载失败……嗯，这些都是经验教训。

2.5 全流程的关键挑战总结

说了这么多，我总结一下每个环节的关键挑战：

环节	关键挑战	我的建议
模型训练	算子选择、输入尺寸、精度预留	训练时就考虑部署，用标准算子
模型转换	算子兼容性、动态shape、控制流	先转ONNX，再转目标格式
量化压缩	精度损失、校准集选择、敏感层处理	先PTQ后QAT，混合精度量化
部署推理	内存管理、推理速度、多线程优化	用profiling找瓶颈，合理分配资源

最后说一句：模型移植不是一锤子买卖。我做过一个项目，前后迭代了5版才稳定。每次发现问题，都要回到前面的环节去调整。所以，保持耐心，做好记录，每一步都留好回退方案。

好了，这一章就到这里。下一章咱们聊聊具体的量化工具怎么用，到时候我会带大家手撸一个量化demo。

📚 课程目录