📚 课程目录第4章模型训练与部署流程

4. 模型训练与部署流程

在MCU TinyML推理系统工程中，模型训练与部署并不是两个割裂的阶段，而是一条从物理世界信号出发、最终回到MCU固件中的完整工程链路。很多初学者把注意力集中在“训练一个准确率高的模型”上，却忽略了量化、算子兼容、内存约束和端侧一致性验证，导致模型在PC上表现良好，烧录到MCU后却无法运行或精度骤降。本节将这条链路拆解为六个关键环节，并给出可落地的工程方法。

一、核心原理：为什么MCU部署是一条“约束驱动”的链路

与服务器端推理不同，MCU端的资源边界是硬约束：Flash通常只有几百KB到几MB，SRAM可能只有几十KB到几百KB，主频多为几十MHz到几百MHz，且没有操作系统或只有RTOS。因此，整条链路必须“以终为始”——先明确目标MCU的Flash、SRAM、算力和算子库支持范围，再反向决定数据采集方式、模型结构、输入尺寸和量化策略。这条链路的核心矛盾是：模型表达能力与端侧资源预算之间的平衡。

工程链路的主线可以概括为：数据采集 → 数据预处理与特征工程 → 模型设计与训练 → 量化与转换 → 端侧集成与部署 → 一致性验证与迭代。每一步都会对后续步骤产生约束，任何一步的疏忽都可能在最后部署时暴露。

二、方法流程：六个环节的关键操作

1. 数据采集与标注。数据质量决定模型上限。对于MCU场景，采集时要尽量贴近真实部署环境：麦克风阵列的噪声底、IMU的安装方向、采样率与量程都要与最终产品一致。建议每个类别至少采集数百到数千个样本，并保留一部分“困难样本”（如低信噪比、运动干扰）。标注要统一标准，避免同一模式被标成不同类别。

2. 预处理与特征工程。MCU端通常无法承担复杂的在线特征计算，因此特征应在训练阶段确定，并在端侧用轻量代码复现。例如音频关键词唤醒常用MFCC，但端侧MFCC计算量较大，可改用Log-Mel滤波器组或直接输入原始波形给轻量CNN。关键原则是：训练与推理的预处理必须逐位一致，包括归一化参数、分帧长度、窗函数和填充方式。

3. 模型设计与训练。优先选择MobileNet、DS-CNN、TinyMLP等轻量结构。输入尺寸不宜过大，例如音频常用40×10或49×10的MFCC帧，IMU常用128×3或64×6的时序窗口。训练时使用Adam优化器、学习率衰减和早停，并监控验证集准确率。若后续要做量化感知训练（QAT），应在训练图中插入伪量化节点。

4. 量化与转换。这是MCU部署中最容易出问题的环节。训练完成后先做训练后量化（PTQ），用代表性数据集校准，得到int8模型。若精度下降超过可接受范围（如超过2%），再改用QAT。转换时使用TensorFlow Lite Converter，并确保目标算子被TFLite Micro支持。转换命令示例如下：

import tensorflow as tf

converter = tf.lite.TFLiteConverter.from_saved_model("saved_model")
converter.optimizations = [tf.lite.Optimize.DEFAULT]
converter.representative_dataset = representative_data_gen
converter.target_spec.supported_ops = [tf.lite.OpsSet.TFLITE_BUILTINS_INT8]
converter.inference_input_type = tf.int8
converter.inference_output_type = tf.int8

tflite_quant_model = converter.convert()
open("model_int8.tflite", "wb").write(tflite_quant_model)

5. 端侧集成与部署。将.tflite文件通过xxd或脚本转换为C数组，嵌入固件工程。在MCU端初始化Tensor Arena，注册算子，加载模型并调用Invoke。若使用CMSIS-NN，可显著加速卷积和全连接层。典型集成代码如下：

const unsigned char model_data[] = { ... };
const int model_data_len = sizeof(model_data);

static tflite::MicroMutableOpResolver<8> resolver;
resolver.AddConv2D();
resolver.AddDepthwiseConv2D();
resolver.AddFullyConnected();
resolver.AddSoftmax();

static tflite::MicroInterpreter interpreter(
    tflite::GetModel(model_data), resolver, tensor_arena, kTensorArenaSize);

interpreter.AllocateTensors();
interpreter.Invoke();

6. 一致性验证与迭代。在PC端用相同输入分别跑float32和int8模型，记录输出差异；再在MCU端跑同一输入，对比MCU输出与PC int8输出。若差异过大，检查量化参数、预处理一致性和算子实现。最终还要实测推理延迟、峰值SRAM和功耗，确认满足产品指标。

三、案例场景：关键词唤醒“Yes/No”的完整链路

以关键词唤醒为例，目标MCU为STM32F407（192KB SRAM，1MB Flash）。数据采集使用板载麦克风，16kHz采样，录制“Yes”“No”“Unknown”三类各800条。预处理提取40维MFCC，取10帧，输入形状为(40,10,1)。模型采用DS-CNN，参数量约12K。训练后PTQ量化，int8模型大小约28KB。端侧Tensor Arena设为60KB，推理延迟约18ms，准确率从float32的96.2%降至int8的95.1%，满足要求。若换成更小的STM32F103（20KB SRAM），则需进一步压缩输入尺寸或改用TinyMLP。

四、误区与复盘

常见误区	后果	正确做法
训练与端侧预处理不一致	精度骤降，难以定位	用同一份预处理代码或逐位对齐参数
忽略算子兼容性	模型无法加载或Invoke失败	转换前检查TFLite Micro算子列表
Tensor Arena过小	AllocateTensors返回错误	逐步增大并打印实际峰值内存
只测PC精度，不测MCU精度	上线后效果不达标	建立PC float32 / PC int8 / MCU int8三方对比
数据采集环境与部署环境差异大	模型泛化差	在真实噪声、真实安装条件下采集

建议在项目初期就建立“端侧一致性测试台”：固定一组测试样本，分别记录PC float32、PC int8和MCU int8的输出，作为每次迭代的回归基准。这样可以在量化、算子替换或模型结构调整时快速发现精度回退。

不要等到模型训练完成才开始考虑MCU资源。应在数据采集阶段就确定目标MCU型号、Flash/SRAM预算和算子库版本，并把它们作为模型设计的硬约束。否则很容易出现“模型很好但放不进去”的返工。

总结来看，MCU TinyML的模型训练与部署是一条以资源约束为起点、以端侧一致性为终点的工程链路。数据采集决定上限，预处理决定一致性，模型设计决定可行性，量化决定落地性，端侧集成决定性能，验证决定可靠性。只有把六个环节当作一个整体来设计，才能让TinyML模型真正在MCU上稳定运行。