📚 课程目录第2章 TinyML基础

2. TinyML基础

TinyML 的核心思想并非“简化版的机器学习”，而是在功耗、内存、算力都极度受限的微控制器（MCU）上，让机器学习模型能够实时运行并完成推理。理解这一前提，需要先厘清微控制器与通用处理器（CPU）的本质差异，再认识主流硬件平台的选型逻辑，最后掌握从模型训练到端侧部署的完整软件链路。本章将围绕“硬件约束决定算法设计，工具链决定落地效率”这一主线，为后续异常告警案例打下扎实基础。

2.1 微控制器与嵌入式系统核心概念

微控制器（MCU）是将处理器核心、存储器（Flash 和 SRAM）、可配置输入输出外设（GPIO、定时器、ADC、UART、SPI、I2C 等）集成在单一芯片上的微型计算机。与运行 Linux 或 Windows 的应用处理器不同，MCU 通常没有 MMU（内存管理单元），直接操作物理地址，且资源以 KB 为单位计量。以 STM32F407 为例，其内置 1MB Flash 和 192KB SRAM，主频 168MHz，功耗在运行状态下仅为 200mW 左右，待机模式可低至 2μA。这种“资源极度受限但实时性极强”的特性，决定了 TinyML 模型必须经过量化、剪枝和算子优化才能落地。

嵌入式系统的核心设计原则是“专用性”与“确定性”。专用性意味着系统只为特定任务设计，例如振动异常检测只需要加速度计数据和分类模型，不需要通用操作系统；确定性则要求每次推理的时间、内存占用、功耗都可预测。这与云端 AI 的弹性伸缩理念截然不同。在异常告警场景中，MCU 通常以固定频率（如 100Hz）采集传感器数据，在中断服务程序中完成特征提取，再调用推理引擎输出告警结果，整个过程必须在一个控制周期内完成。

对比维度	MCU（微控制器）	MPU（应用处理器）
典型代表	STM32F4、ESP32、Arduino Nano	树莓派、RK3588、i.MX8
内存容量	几十KB ~ 几MB	512MB ~ 8GB
主频范围	16MHz ~ 600MHz	1GHz ~ 3GHz
操作系统	裸机 / RTOS（FreeRTOS、Zephyr）	Linux / Android
启动时间	毫秒级	秒级
典型功耗	mW 级	W 级
TinyML 适配性	核心目标平台	边缘计算，非严格 TinyML

  核心判断方法： 判断一个项目是否属于 TinyML 范畴，可依据三个硬性指标——① 设备供电是否采用电池或能量采集（平均功耗 < 100mW）；② 内存是否小于 1MB；③ 是否要求实时响应（延迟 < 100ms）。若三项均满足，则必须采用 TinyML 技术路线。

2.2 主流硬件平台选型与对比

当前 TinyML 开发最活跃的三大硬件平台分别是 Arduino 系列、ESP32 系列和 STM32 系列。它们各有侧重：Arduino 主打极低门槛和生态成熟度，适合快速原型验证；ESP32 内置 Wi-Fi/蓝牙，适合需要无线数据传输的端侧告警场景；STM32 则覆盖从低功耗到高性能的完整产品线，适合工业级量产。选型时需综合评估算力、内存、外设接口、功耗预算和开发成本。

以异常告警场景为例，若检测对象是工业旋转机械（振动频率 1kHz 以内），STM32F4 系列凭借 168MHz 主频和 FPU（浮点运算单元）可流畅运行 2 层 CNN 模型；若检测对象是冷链运输环境（温湿度变化缓慢），ESP32-S3 的 512KB SRAM 足以容纳轻量级 LSTM 模型，且 Wi-Fi 可直接上报告警；若仅做实验室教学验证，Arduino Nano 33 BLE 的 256KB RAM 配合 TensorFlow Lite Micro 官方示例，能最快跑通端到端流程。

平台型号	核心/主频	SRAM	Flash	典型功耗	适用场景
Arduino Nano 33 BLE	Cortex-M4F 64MHz	256KB	1MB	~30mW	教学、可穿戴
ESP32-S3	LX7 240MHz	512KB	8MB	~100mW	无线传感、智能家居
STM32L4	Cortex-M4F 80MHz	128KB	512KB	~10mW	电池供电、工业监测
STM32F4	Cortex-M4F 168MHz	192KB	1MB	~200mW	高性能端侧推理
STM32H7	Cortex-M7 480MHz	1MB	2MB	~500mW	复杂模型、边缘网关

选型风险提示： 不要只看主频和内存。ESP32 虽然主频高，但其 Xtensa 架构对 CMSIS-NN 优化库不兼容，需使用 ESP-DL 或自行优化算子；STM32H7 性能强劲但功耗较高，若产品要求电池续航超过 6 个月，应优先考虑 STM32L4 或 Apollo4 等超低功耗平台。务必在项目初期用实际模型跑通 benchmark，而非仅凭数据表做决策。

2.3 软件工具链：从训练到部署的完整链路

TinyML 的软件工具链可划分为四个阶段：模型训练（PC 端）、模型转换与量化、端侧推理引擎、硬件抽象层。训练阶段通常使用 TensorFlow 或 PyTorch 在 GPU 服务器上完成，但端侧部署必须转换为 TensorFlow Lite 格式（.tflite），并经过量化将 FP32 权重压缩为 INT8 或 INT16。以 100KB 的 FP32 模型为例，转换为 INT8 后体积降至 25KB，推理速度提升 3-5 倍，精度损失通常控制在 2% 以内。

推理引擎方面，TensorFlow Lite for Microcontrollers（TFLM）是当前事实标准，它提供了解释器、算子内核和内存分配器，但需要开发者手动管理内存池。CMSIS-NN 是 ARM 官方为 Cortex-M 系列提供的优化算子库，通过 SIMD 指令和查表法加速卷积和全连接层。STM32 用户还可使用 ST 官方的 X-CUBE-AI 工具，它支持将 Keras、ONNX 模型直接转换为 STM32 工程代码，并自动生成校验报告。

# 模型转换与量化示例（PC端执行）
import tensorflow as tf

# 加载训练好的 Keras 模型
model = tf.keras.models.load_model('vibration_model.h5')

# 转换为 TFLite 格式并应用 INT8 量化
converter = tf.lite.TFLiteConverter.from_keras_model(model)
converter.optimizations = [tf.lite.Optimize.DEFAULT]
converter.representative_dataset = representative_dataset  # 校准数据集
tflite_model = converter.convert()

# 保存量化后的模型
with open('vibration_model_int8.tflite', 'wb') as f:
    f.write(tflite_model)

在开发环境层面，Arduino IDE 适合初学者，但工程管理能力较弱；PlatformIO 提供跨平台编译、库管理和单元测试，更适合复杂项目。对于 STM32，STM32CubeMX 用于初始化外设和生成 HAL 库代码，配合 Keil MDK 或 STM32CubeIDE 完成编译调试。调试时需重点关注内存溢出和推理耗时，可使用串口打印关键日志，或利用 J-Link 的 RTT 功能实时观测变量。

经验提醒： 在转换模型时，务必使用 representative_dataset 提供校准数据（通常取训练集的 100-500 个样本），否则量化后的模型精度可能骤降。另外，TFLM 默认不支持所有算子，如 LSTM 需要额外导入算子包，建议在模型设计阶段就查阅 TFLM 支持的算子列表，避免后期返工。

2.4 实战场景：基于 ESP32-S3 的电机异常告警原型

为验证上述硬件与工具链的配合，我们设计一个电机轴承异常检测原型。硬件采用 ESP32-S3 开发板（8MB PSRAM），外接 MPU6050 六轴加速度计（I2C 接口，采样率 1kHz），通过 Wi-Fi 将告警信息发送至手机。目标是在 512KB SRAM 内运行一个 1D CNN 模型，对正常/异常振动进行分类，推理延迟不超过 50ms。

初始阶段，我们使用 STM32F4 上的 CMSIS-NN 基准测试数据作为参考，但发现 ESP32-S3 无法直接复用。于是改用 Edge Impulse 平台进行数据采集和模型训练：采集正常状态 10 分钟、异常状态 10 分钟（人为在轴承外圈加工 0.5mm 凹槽），每段数据切分为 2 秒窗口，提取时域特征（RMS、峰值因子、峭度）和频域特征（FFT 前 20 个频段能量）。模型采用 3 层卷积 + 全局平均池化 + 全连接层，参数量 12K，FP32 大小 48KB。

转换过程中遇到两个关键问题：一是 Edge Impulse 默认输出 FP32 模型，直接部署后推理耗时 120ms，超出预算；二是 ESP32-S3 的 Wi-Fi 协议栈占用约 180KB RAM，导致内存紧张。解决方案是：① 使用 INT8 量化，模型体积降至 12KB，推理耗时降至 35ms；② 将 Wi-Fi 初始化延迟到首次告警触发时，平时保持关闭状态，节省约 150KB RAM。最终部署后，系统待机功耗 80mW，告警时功耗 180mW，检测准确率 96.2%，误报率 1.8%。

优化阶段	模型大小	推理耗时	RAM 占用	准确率
FP32 原始模型	48KB	120ms	310KB	97.1%
INT8 量化后	12KB	35ms	180KB	96.2%
量化 + 延迟 Wi-Fi 初始化	12KB	35ms	120KB	96.2%

  案例复盘： 该原型的核心教训是“硬件约束必须前置”。若在模型设计阶段就考虑 ESP32-S3 的 SRAM 限制，可直接采用深度可分离卷积减少参数量，而非事后量化补救。此外，Edge Impulse 虽然简化了数据标注和训练流程，但其自动生成的代码在内存管理上不够精细，对于量产项目建议手动编写推理调度逻辑。

2.5 常见误区与总结

误区一：认为 MCU 上只能运行决策树或线性模型。实际上，经过 INT8 量化后的 2-3 层 CNN 在 STM32F4 上可达到 10ms 级推理，完全满足工业实时性要求。误区二：忽视外设中断与推理引擎的优先级冲突。在异常告警中，传感器数据采集中断优先级应高于推理任务，否则可能导致数据丢失。误区三：盲目追求模型精度而忽略内存碎片问题。TFLM 默认使用静态内存池，若模型包含动态 shape 操作（如 Reshape），可能导致内存分配失败，应在转换时固定输入维度。