2. TinyML基础

TinyML（Tiny Machine Learning）是机器学习与嵌入式物联网系统的交叉领域，其核心目标是在功耗受限、计算资源有限、存储空间狭小的微控制器（MCU）或边缘处理器上，部署和运行机器学习推理模型。理解TinyML的基础知识，是搭建硬件在环（HIL）测试台架的前提——只有清楚模型如何从训练走向部署、在硬件上如何执行，才能设计出有效的测试与数据回放方案。本章将系统梳理嵌入式机器学习的工作流程、典型应用场景、模型压缩技术以及部署过程中面临的核心挑战。

上图展示了TinyML从数据准备到部署测试的完整工程链路。与传统的云端AI不同，TinyML的每一个环节都受到硬件资源的严格约束，这也决定了其工作流程的特殊性。下面我们将逐一深入剖析各个阶段的核心原理与操作要点。

2.1 嵌入式机器学习的工作流程

TinyML的工作流程可以概括为“数据采集→模型训练→模型压缩→代码转换→硬件部署→测试验证”六个主要阶段。与云端AI相比，其最大的差异在于模型压缩和硬件适配环节的权重极高，且测试验证必须回归到真实硬件环境。

核心原理：从云端到边缘的范式转换

传统机器学习流程中，模型训练完成后直接部署在服务器或云端，通过API调用提供服务。而TinyML的推理过程发生在设备端，这意味着：

• 数据本地化：原始传感器数据不需要上传云端，降低了带宽需求和隐私风险。
• 实时响应：推理在本地完成，避免了网络延迟，适合工业控制、可穿戴设备等对实时性要求高的场景。
• 离线可用：即使断网，设备依然可以正常工作。

然而，这种范式转换带来了一个根本性矛盾：MCU的资源（Flash、RAM、CPU主频）与深度学习模型的计算需求之间存在数量级的差距。例如，一个经典的ResNet-50模型参数量约2500万，需要约100MB存储空间，而主流MCU的Flash通常只有512KB到2MB，RAM更是仅有128KB到512KB。因此，TinyML的工作流程必须围绕“如何在极小资源下实现可用精度”这一核心命题展开。

操作流程：六步走通TinyML项目

1. 数据采集与预处理：使用目标设备上的真实传感器采集数据，或使用历史日志数据。关键点在于数据分布要与实际部署环境一致。预处理包括去噪、归一化、滑动窗口分割等。
2. 模型训练（浮点精度）：在PC或服务器上使用TensorFlow、PyTorch等框架训练模型。此阶段使用float32精度，目标是获得一个精度达标的“大模型”。
3. 模型压缩：通过剪枝（移除不重要的权重连接）、量化（将float32权重转为int8或float16）、知识蒸馏（用小模型学习大模型的输出）等技术，将模型体积缩小数倍至数十倍。
4. 模型转换：将训练好的模型转换为TFLite格式，再进一步转换为TFLite Micro支持的C++数组格式。此过程会进行算子映射和优化。
5. 嵌入式部署：将生成的C++模型文件与推理引擎（如TensorFlow Lite for Microcontrollers）集成到MCU工程中，编译烧录。
6. 硬件测试与调优：在真实硬件上运行模型，测量推理时间、内存占用、功耗等指标，并根据结果调整模型结构或硬件选型。

2.2 典型应用场景与硬件约束分析

TinyML的应用场景非常广泛，但并非所有场景都适合。判断一个场景是否适合TinyML，需要从数据维度、实时性要求、功耗预算、成本敏感度四个维度进行评估。

典型场景分类

判断方法：场景适配性评估

在实际项目立项时，建议按照以下步骤进行可行性判断：

1. 计算量估算：统计模型所需的乘加运算次数（MACs）。对于主频100MHz的MCU，通常期望MACs不超过10M，否则推理延迟会超过100ms。
2. 内存预算：模型权重（Flash占用）+ 激活值（RAM占用）必须小于硬件规格的80%，留出余量给系统任务。
3. 功耗预算：如果设备使用纽扣电池供电，平均功耗需控制在1mW以下，这意味着MCU大部分时间需要处于睡眠状态，推理任务需在极短时间内完成。
4. 精度容忍度：量化后的模型精度损失通常在1%-3%以内是可接受的。如果应用场景对精度极其敏感（如医疗诊断），则需要谨慎评估。

2.3 模型压缩技术详解

模型压缩是TinyML落地的关键使能技术。没有压缩，深度学习模型几乎无法在MCU上运行。目前主流的压缩技术包括量化、剪枝、知识蒸馏三种，它们可以组合使用。

量化：从float32到int8

量化是将模型权重和激活值从32位浮点数转换为更低比特位（如8位整数）的过程。以int8量化为例，模型体积直接缩小4倍，推理速度提升2-4倍（取决于MCU是否支持SIMD指令）。

# TensorFlow 后训练量化示例
import tensorflow as tf

# 加载浮点模型
converter = tf.lite.TFLiteConverter.from_saved_model('float_model')
# 设置优化策略
converter.optimizations = [tf.lite.Optimize.DEFAULT]
# 提供代表性数据集用于校准
def representative_dataset():
    for _ in range(100):
        yield [np.random.randn(1, 128, 128, 3).astype(np.float32)]
converter.representative_dataset = representative_dataset
# 转换为int8量化模型
tflite_model = converter.convert()

量化过程中最关键的是校准（Calibration）步骤。校准数据集需要覆盖模型可能遇到的数据分布范围，否则量化后的精度损失会显著增大。常见的校准集大小为100-500个样本。

剪枝：移除冗余连接

剪枝分为结构化剪枝和非结构化剪枝。非结构化剪枝将权重矩阵中接近零的值置零，产生稀疏矩阵，但需要特殊硬件支持才能加速。结构化剪枝则直接移除整个卷积核或神经元，更适合MCU部署。

知识蒸馏：小模型学习大模型

知识蒸馏通过让一个小模型（学生网络）学习大模型（教师网络）的软输出（概率分布），从而在保持较高精度的同时大幅减少参数量。这种方法特别适合从云端大模型向边缘小模型迁移的场景。

2.4 部署挑战与工程应对策略

即使完成了模型压缩，将模型成功部署到MCU上并稳定运行，仍然面临诸多工程挑战。这些挑战往往不是孤立的，而是相互关联的。

挑战一：算子支持不全

TFLite Micro内置的算子库远小于完整版TFLite。例如，某些高级的注意力机制算子、动态形状算子可能不被支持。应对策略包括：

• 在模型设计阶段就使用TFLite Micro支持的算子（如Conv2D、DepthwiseConv2D、FullyConnected、Softmax等）。
• 对于不支持的算子，需要手动实现自定义算子并注册到推理引擎中，这会增加开发工作量。

挑战二：内存碎片与峰值占用

MCU的RAM通常只有几十到几百KB，而推理过程中的中间激活值会占用大量内存。TFLite Micro使用“内存规划器”来复用缓冲区，但开发者仍需关注峰值内存占用。在HIL测试中，应通过日志记录每次推理的内存使用情况，确保没有溢出风险。

挑战三：数值精度与确定性

量化模型的数值行为与浮点模型存在差异，且不同编译器优化选项可能导致结果不一致。在HIL测试中，需要建立“黄金标准”输出（通常由浮点模型在PC上生成），并允许一定的误差范围（如±1 LSB）。

案例拆解：工业电机振动异常检测项目

某工厂希望部署一个电机振动异常检测系统，要求使用现有的STM32F446RE开发板（Cortex-M4F，180MHz，512KB Flash，128KB RAM），电池供电，目标功耗低于50mW。

初始方案与问题：工程师最初使用一个包含5层卷积的CNN模型，float32精度，参数量约800KB，远超Flash容量。直接部署失败。

分析过程：首先进行模型压缩。采用int8量化后，模型体积降至200KB，满足Flash要求。但进一步测试发现，推理时RAM峰值达到96KB，接近128KB上限，且推理延迟为180ms，导致功耗超标。

优化操作：

1. 将第一层卷积的滤波器数量从32减至16，参数量进一步降至120KB。
2. 使用深度可分离卷积替换标准卷积，MACs从12M降至4M。
3. 在HIL台架上使用真实振动数据回放测试，发现量化后模型对小幅振动信号的灵敏度下降，通过增加校准数据集中高频振动样本的比例解决。

结果对比：优化后模型体积110KB，RAM峰值52KB，推理延迟45ms，平均功耗28mW，检测准确率从97.2%降至96.1%，满足工厂要求的95%阈值。

复盘经验：模型压缩不是孤立的步骤，需要与硬件资源、功耗预算、精度要求联合优化。HIL测试台架在此过程中发挥了关键作用——通过数据回放，工程师能够在数小时内完成数百次迭代测试，而无需每次都在真实设备上手动采集数据。