2、TinyML基础回顾：模型部署流程、常见模型格式与版本管理概念

TinyML（微型机器学习）的核心挑战在于：将训练好的深度学习模型压缩、转换并部署到内存以KB计、算力以MHz计、功耗以mW计的微控制器（MCU）上。与云端或移动端AI不同，TinyML的部署链路中每一步都受到硬件资源的硬约束。理解模型部署的标准流程、模型格式的差异以及版本管理的必要性，是后续进行新旧模型自动化评估的前提。本章将系统梳理这三块基础内容，为后续章节的指标对比与自动化评估建立统一的认知框架。

上图展示了TinyML模型从训练到部署的完整链路，以及版本管理在其中的贯穿作用。可以看到，模型格式转换并非简单的文件后缀变更，而是涉及算子映射、量化参数调整、内存布局优化等一系列工程决策。版本管理也不仅仅是记录“v1、v2”，而是需要将模型文件、量化配置、部署脚本、固件代码作为一个整体进行关联追踪。下面我们逐一展开。

2.1 TinyML模型部署的标准流程

核心原理：TinyML部署流程本质上是一个“资源适配”过程——将深度学习框架中张量运算的抽象描述，映射为MCU上可执行的指令序列和内存操作。与云端部署不同，TinyML部署必须同时考虑以下硬约束：Flash存储（通常256KB~2MB）、RAM（通常16KB~512KB）、CPU主频（通常几十MHz到几百MHz）、以及功耗预算（通常mW级）。因此，部署流程的每一步都围绕“如何在精度损失可控的前提下，将模型压缩到硬件可承载的范围”。

标准部署流程（以TFLite Micro为例）可分为以下六个阶段：

1. 模型训练与验证：在PC端使用TensorFlow/PyTorch训练浮点模型，达到目标精度（如准确率≥95%）。此阶段产出的是标准浮点模型文件（如.h5、.pb）。
2. 量化准备：选择量化方案。训练后量化（PTQ）直接对浮点权重进行映射，无需重新训练；量化感知训练（QAT）在训练过程中模拟量化误差，精度更高但需要重新训练。量化位宽通常为8位，部分场景使用16位。
3. 格式转换：使用TFLite Converter将模型转换为.tflite格式。转换过程中会进行算子融合（如将Conv+BN+ReLU融合为一个算子）、常量折叠等图优化操作。
4. 模型分析与优化：使用TFLite Model Analyzer检查模型大小、算子列表、内存占用估算。若超出目标硬件限制，需要进一步剪枝、蒸馏或降低输入分辨率。
5. 生成C数组或静态库：将.tflite文件转换为C字节数组（xx.c/h），或使用TFLite Micro的C++ API直接链接。此步骤将模型数据嵌入固件镜像。
6. MCU端集成与验证：在嵌入式工程中编写推理调用代码，配置输入输出张量，进行板上验证。验证内容包括：输出数值一致性、推理延迟、峰值内存、功耗等。

# 使用Python检查模型参数量与估算内存
import tensorflow as tf
converter = tf.lite.TFLiteConverter.from_saved_model('model.pb')
converter.optimizations = [tf.lite.Optimize.DEFAULT]
tflite_model = converter.convert()
# 估算RAM：输入张量 + 中间特征图 + 输出张量
# 经验公式：RAM ≈ 最大中间特征图大小 × 2 + 权重大小 × 0.1

2.2 常见模型格式：TFLite、ONNX与C数组的对比与选型

核心原理：模型格式决定了模型的存储方式、加载方式、执行效率以及跨平台兼容性。在TinyML领域，不存在“万能格式”，每种格式都有其特定的适用场景。理解格式差异是进行版本对比的基础——不同格式的模型文件，其元数据、量化信息、算子集版本都可能不同，直接对比时需要统一基准。

选型建议：在课程后续的自动化评估场景中，我们主要使用TFLite格式作为对比基准，原因有三：其一，TFLite Micro是当前MCU端支持最广泛的推理引擎；其二，TFLite文件内嵌了完整的量化参数（scale/zero_point），便于自动化提取；其三，TFLite的算子版本管理机制相对清晰，便于检测模型兼容性。ONNX更适合在PC端做模型转换的中间格式，而C数组则是最终部署形态。

2.3 版本管理概念：从“文件覆盖”到“模型血缘追踪”

核心原理：传统软件版本管理关注代码变更，而TinyML模型版本管理需要同时追踪三类对象：模型文件本身（权重、结构）、生成模型的代码与数据（训练脚本、数据集版本）、部署配置（量化方案、编译器版本、目标硬件）。这三者共同决定了一个“模型版本”的实际行为。缺少任何一环，都无法复现或对比模型性能。

版本管理的关键维度：

• 模型内容版本：记录网络结构、权重数值、量化参数。建议使用Git LFS或DVC（Data Version Control）管理大文件。
• 训练环境版本：记录TensorFlow/PyTorch版本、CUDA版本、随机种子。同一份代码在不同环境训练出的模型可能有细微差异。
• 转换工具链版本：TFLite Converter的版本直接影响算子融合策略和量化结果。例如，TF 2.6与TF 2.10对同一模型的转换结果可能不同。
• 部署目标版本：MCU的固件库版本、TFLite Micro的版本、编译器优化选项（-O2 vs -Os）都会影响推理结果。

版本命名与标记策略：建议采用语义化版本+元数据标签的方式。例如：v2.3.1-quant-int8-imx93，其中v2.3.1是模型迭代版本，quant-int8表示量化方案，imx93表示目标硬件平台。这种命名方式在自动化评估中可以直接解析出关键属性。

2.4 案例拆解：一个语音唤醒词模型的版本混乱问题

场景背景：某智能家居团队开发了一个关键词唤醒模型（识别“你好小智”），部署在Cortex-M4F内核的MCU上（192KB RAM，1MB Flash）。团队在三个月内迭代了5个版本，但近期发现线上设备出现误唤醒率上升的问题。

初始现象：最新版本v5在实验室测试准确率为97%，但线上误唤醒率从0.5次/小时上升到2次/小时。团队无法快速定位原因，因为本地只保留了v5的.tflite文件，v1~v4的模型文件已丢失。

分析过程：

1. 首先检查v5模型的量化参数，发现输入特征的scale为0.0078125，而v3（线上稳定版本）的scale为0.00390625。这意味着输入信号的量化精度降低了一半。
2. 进一步检查训练日志，发现v5使用了新的数据增强策略（添加了环境噪声），但校准数据集（用于PTQ）仍使用旧数据，导致量化参数与模型实际分布不匹配。
3. 由于没有保存v3的模型文件，无法直接对比两个版本的权重差异，只能通过线上日志反推。

解决方案与复盘：

• 紧急回滚：从固件版本管理系统中找到v3对应的C数组文件，回滚固件，误唤醒率恢复正常。
• 建立模型版本仓库：使用DVC管理所有.tflite和训练数据，每次发布自动生成model_card.json。
• 制定量化校准规范：要求每次模型更新时，必须使用与训练集分布一致的校准数据集，并在版本记录中标注校准集哈希值。
• 自动化评估触发：在CI/CD流水线中增加“新旧模型对比”步骤，自动对比量化参数、权重分布、以及使用同一测试集的精度差异。

2.5 总结与常见误区复盘

本章核心要点回顾：

实践建议：从今天开始，为你的每个TinyML模型建立一份“模型身份证”（model_card），至少包含以下字段：模型ID、训练框架版本、量化类型（PTQ/QAT）、量化位宽、校准数据集版本、目标MCU型号、TFLite Micro版本、期望RAM/Flash占用、以及已知的精度指标。这份文档将成为后续自动化评估脚本的数据源。