3、模型基础：掌握神经网络模型的基本结构、训练与导出流程，理解模型格式（SavedModel、H5、ONNX等）的区别
在进入TFLite Micro的模型转换与部署之前，必须先厘清“模型”在不同阶段的存在形态。很多开发者直接从网上下载一个 .tflite 文件就开始部署，一旦遇到算子不支持或量化精度骤降，往往束手无策。根本原因在于：不了解模型从训练到部署的完整生命周期，也不清楚中间格式（SavedModel、H5、ONNX）各自扮演的角色。本章将系统梳理神经网络模型的基本结构、训练与导出流程，并深入对比主流模型格式的差异，为后续章节的版本转换与算子映射打下坚实基础。
3.1 神经网络模型的基本结构：从张量到算子
神经网络模型的本质是一个有向计算图，由张量（Tensor）和算子（Operator）构成。张量是多维数组，是数据流动的载体；算子是计算节点，定义了张量之间的变换关系。以经典的卷积神经网络（CNN）为例，其基本结构包括：输入层（Input）、卷积层（Conv2D）、激活函数（ReLU）、池化层（MaxPooling）、全连接层（Dense）和输出层（Softmax）。每一层都对应一个或多个算子，而层与层之间的连接则通过张量的形状（Shape）和数据类型（Dtype）来约束。
在TFLite Micro的语境下，理解模型结构的关键在于算子粒度。训练框架（如TensorFlow）中的高层API（如Keras的Conv2D层）在导出时会被拆解为更底层的算子序列（如Conv2D + BiasAdd + Relu）。这种拆解直接影响后续的算子映射——如果某个底层算子在TFLite Micro的算子集中不存在，转换就会失败。因此，开发者需要具备“从层视角切换到算子视角”的能力。
3.2 训练与导出流程：从检查点到可部署文件
一个典型的模型训练与导出流程包含以下阶段：
- 数据准备与预处理：收集数据、划分训练/验证/测试集、归一化、数据增强等。
- 模型定义：选择网络架构（如MobileNetV2、ResNet等），设定输入形状和输出类别数。
- 训练循环：前向传播计算损失，反向传播更新权重，周期性在验证集上评估性能。
- 检查点保存：训练过程中定期保存权重（如 .ckpt 或 .weights.h5），用于恢复训练或故障恢复。
- 最终导出：训练完成后，将模型结构和权重打包为特定格式（SavedModel、H5、ONNX等）。
导出流程中有一个关键决策点：选择哪种中间格式作为转换的输入。对于TFLite Micro，官方推荐使用SavedModel作为转换器的输入，因为它完整保留了模型的签名（Signature）和元数据，且与TFLite Converter的兼容性最好。H5格式虽然方便，但在某些版本组合下可能丢失部分自定义层信息。ONNX则适合跨框架迁移，但需要额外处理算子映射的兼容性问题。
| 导出格式 | 文件内容 | 适用场景 | TFLite转换兼容性 |
|---|---|---|---|
| SavedModel | 计算图 + 权重 + 签名 + 资产 | TF Serving、TFLite转换首选 | ★★★★★（原生支持） |
| H5 | 结构 + 权重（单文件） | Keras快速保存/加载 | ★★★★（需注意版本兼容） |
| ONNX | 计算图 + 权重（跨框架） | PyTorch→TF迁移、模型互操作 | ★★★（需onnx-tf转换） |
| Checkpoint | 仅权重（无结构） | 训练恢复、迁移学习 | ★（需配合模型定义代码） |
3.3 模型格式深度对比：SavedModel、H5、ONNX的差异与选型
理解格式差异的核心在于信息完整度和运行时依赖。SavedModel是一个目录结构，包含saved_model.pb（计算图定义）、variables/（权重变量）、assets/（辅助文件）和signature（输入输出接口定义）。它的优势在于自包含性强，且支持TF Serving的版本管理。H5是Keras的序列化格式，将模型结构（JSON或YAML）和权重（HDF5二进制）打包在一个文件中，便于分发，但自定义层（Custom Layer）需要额外注册才能正确加载。
ONNX（Open Neural Network Exchange）是一种开放格式，旨在实现不同框架之间的模型互操作。它将模型表示为计算图，算子集（Opset）有版本号，不同框架对ONNX算子的支持程度不同。例如，PyTorch导出的ONNX模型可能包含TFLite不支持的算子（如某些动态形状操作），需要手动替换或修改。
3.4 实战场景：从PyTorch模型到TFLite的完整导出链路
假设我们有一个在PyTorch中训练好的图像分类模型（ResNet18），需要部署到ESP32-S3上运行TFLite Micro。以下是完整的导出链路：
# 步骤1：PyTorch导出ONNX
import torch
import torchvision.models as models
model = models.resnet18(pretrained=True)
model.eval()
dummy_input = torch.randn(1, 3, 224, 224)
torch.onnx.export(model, dummy_input, "resnet18.onnx",
input_names=["input"], output_names=["output"],
dynamic_axes={"input": {0: "batch"}, "output": {0: "batch"}})
# 步骤2：ONNX转TensorFlow（使用onnx-tf）
import onnx
from onnx_tf.backend import prepare
onnx_model = onnx.load("resnet18.onnx")
tf_rep = prepare(onnx_model)
tf_rep.export_graph("resnet18_savedmodel")
# 步骤3：TFLite转换（使用TF 2.x）
import tensorflow as tf
converter = tf.lite.TFLiteConverter.from_saved_model("resnet18_savedmodel")
converter.optimizations = [tf.lite.Optimize.DEFAULT]
converter.representative_dataset = representative_dataset_gen # 量化校准数据
tflite_model = converter.convert()
with open("resnet18.tflite", "wb") as f:
f.write(tflite_model)
在这个案例中，我们遇到了两个关键问题：动态轴（dynamic_axes）和量化校准。动态轴允许输入batch维度可变，但TFLite Micro要求固定输入形状，因此需要在ONNX导出时固定batch=1。量化校准需要提供代表性数据集（通常为100-500张验证集图片），用于计算激活值的动态范围，否则量化后的模型精度可能大幅下降。
3.5 常见误区与复盘：格式选择与版本兼容性
在实际项目中，开发者常陷入以下误区：
- 误区一：认为H5可以直接转换为TFLite。实际上，H5转换需要经过Keras模型加载，如果模型包含自定义层或Lambda层，转换器可能无法解析。
- 误区二：忽略TensorFlow版本差异。TF 1.x的TFLite转换器与TF 2.x的API完全不同，且TF 2.x的转换器对SavedModel的版本有严格要求（如TF 2.8不支持TF 2.10导出的SavedModel）。
- 误区三：混淆“权重文件”和“模型文件”。.h5文件既可以是完整模型，也可以是仅权重（通过save_weights保存），后者不包含结构信息，无法直接转换。
复盘建议：在项目启动时，先明确目标部署平台（MCU型号、RAM/Flash限制），再反向选择模型架构和导出格式。建议建立一张“模型版本-转换工具-目标平台”的兼容性矩阵，记录每次转换的参数和结果，便于回溯问题。