2、TinyML基础：嵌入式机器学习的特点、资源约束、典型应用场景与主流框架
TinyML（微型机器学习）是机器学习与嵌入式物联网系统交叉融合的前沿领域，其核心目标是在功耗受限、计算资源有限、存储空间狭小的微控制器（MCU）或极低功耗处理器上，直接部署和运行机器学习模型。与云端AI依赖大规模GPU集群不同，TinyML强调在设备本地完成数据采集、推理甚至增量学习，从而实现毫瓦级功耗下的智能感知。理解TinyML的基础特性，是后续搭建量化感知训练（QAT）环境的前提——因为QAT的一切设计，本质上都是在为这些资源约束服务的。
上图展示了TinyML工程链路的全貌。可以看到，量化感知训练（QAT）并非孤立的技术，它处于模型训练与硬件部署之间的关键位置。在嵌入式环境中，模型不仅要“跑得动”，还要“跑得准”且“跑得省”。下面我们从四个维度深入剖析TinyML的核心知识体系。
2.1 嵌入式机器学习的核心特点与资源约束
核心原理：嵌入式机器学习区别于云端AI的本质特征在于“物理边界”。MCU的CPU主频通常只有几十MHz到几百MHz，RAM以KB为单位计量，Flash存储也仅有MB级别。这意味着模型必须足够小、足够快、足够省电。以STM32F4系列为例，其Cortex-M4内核主频168MHz，内置192KB SRAM和1MB Flash，却需要同时运行实时操作系统、传感器驱动和推理引擎。这种严苛的资源预算，决定了TinyML模型必须采用量化（如INT8）、剪枝、知识蒸馏等压缩技术。
| 资源维度 | 典型MCU范围 | 云端GPU对比 | 对模型的影响 |
|---|---|---|---|
| 算力 | 10~500 MOPS | 数TFLOPS | 限制网络深度与卷积核数量 |
| 内存(RAM) | 16KB ~ 1MB | 数十GB | 限制激活值存储，需流式推理 |
| 存储(Flash) | 64KB ~ 4MB | 数TB | 限制模型参数总量 |
| 功耗 | 1mW ~ 100mW | 数百瓦 | 需低功耗模式与事件驱动 |
判断方法：在项目启动前，应通过“资源预算表”评估可行性。首先计算模型参数量（例如MobileNetV1的1.0版本约430万参数，INT8量化后约4.3MB），再估算激活值峰值（取决于输入分辨率和网络结构）。若Flash或RAM超限，则需要考虑更激进的量化（如4bit）或更换更小的网络架构。
2.2 典型应用场景与信号特征分析
核心原理：TinyML的应用场景集中在“感知-判断-动作”的闭环中。由于MCU直接连接传感器，数据天然具有时序性和物理上下文。例如，加速度计的振动信号、麦克风的音频流、摄像头的图像帧，这些信号在时域或频域上具有可学习的模式。理解信号特征有助于选择合适的模型输入形式（如FFT频谱图、原始波形、灰度图）。
案例拆解：工业电机预测性维护
- 背景与约束：某工厂需要在电机轴承上部署振动异常检测，要求功耗低于10mW，响应时间小于200ms，且不能改变现有机械结构。选用STM32L4系列MCU（Cortex-M4, 80MHz, 64KB RAM）。
- 初始现象：电机正常运行时振动频谱主要集中在1kHz以下，当轴承磨损时，出现2kHz~5kHz的高频冲击成分。但环境噪声干扰大，直接阈值判断误报率高。
- 关键输入数据：使用ADXL345加速度计，采样率4kHz，每帧采集256个样本（64ms窗口）。对原始信号做512点FFT，取前128个频段作为模型输入特征。
- 分析判断过程：对比了两种方案：方案A使用3层全连接网络（输入128，隐藏层64/32，输出2分类），浮点模型大小约12KB；方案B使用1D-CNN（卷积核尺寸5，通道数16/32），浮点模型约25KB。在PC端验证，方案B的F1分数为0.97，方案A为0.93。
- 实际操作步骤：考虑到RAM限制（激活值峰值），方案A的峰值激活值约128*4=512字节，方案B约32*128*4=16KB。最终选择方案A，并采用INT8量化（QAT训练），量化后模型大小降至3KB，激活值降至128字节。
- 结果对比：部署后实测功耗6.8mW，推理延迟45ms，F1分数为0.91（量化损失2%）。误报率从原来的每8小时1次降至每72小时1次。
- 风险与代价：为了满足功耗要求，牺牲了部分精度（F1从0.93降至0.91）。若未来需要更高精度，可考虑更换为带FPU的MCU或增加DSP指令集。
- 复盘经验：特征工程（FFT）比单纯增加网络深度更有效；QAT的伪量化节点有效缓解了INT8量化带来的精度损失；模型选择必须同时考虑参数量与激活值峰值。
2.3 主流框架对比：TensorFlow Lite Micro 与 PyTorch Mobile
核心原理：框架的选择决定了从训练到部署的工具链效率。TensorFlow Lite Micro（TFLM）是专为MCU设计的推理引擎，其核心优势在于极小的二进制体积（约20KB）和低运行时开销。PyTorch Mobile则更侧重于移动端（手机/平板），但通过ExecuTorch实验性扩展，也开始支持MCU。此外，Edge Impulse等商业平台提供了从数据采集到部署的完整SaaS方案。
| 特性 | TensorFlow Lite Micro | PyTorch Mobile / ExecuTorch | Edge Impulse |
|---|---|---|---|
| 目标硬件 | MCU (Cortex-M, RISC-V) | 移动端为主，MCU实验性 | MCU + 云服务 |
| 量化支持 | INT8/INT16 成熟 | INT8 支持，工具链较新 | 内置QAT与PTQ |
| 运行时体积 | ~20KB Flash | ~1MB+ (裁剪后) | 依赖具体后端 |
| 算子覆盖 | 常用算子（Conv, DepthwiseConv, FullyConnected） | 算子丰富，但裁剪复杂 | 自动选择可用算子 |
| 社区与生态 | 成熟，Arm CMSIS-NN优化 | PyTorch生态，研究友好 | 低代码，适合快速原型 |
判断方法：选择框架时，首先确认目标MCU是否在官方支持列表中。其次，检查模型中的算子（如自定义激活函数）是否被目标框架支持。如果模型包含LSTM或Attention机制，TFLM的算子支持可能受限，此时可考虑将模型转换为TFLite格式后，使用select算子（需额外增加Flash占用）。
converter工具链，支持训练后量化（PTQ）和量化感知训练（QAT）。若团队已有PyTorch模型，可先通过torch.export导出为ONNX，再转换为TFLite格式，但需注意算子映射的兼容性。
2.4 常见误区与总结复盘
误区一：忽视内存峰值。许多开发者只关注模型文件大小，却忽略了推理时的中间激活值。例如，一个输入为64x64x32的特征图，在INT8下需要64*64*32=128KB的RAM，这往往超出了MCU的可用内存。解决方法是使用“内存规划工具”（如TFLM的RecordingAllocator）分析峰值内存，并考虑分块推理或减少通道数。
误区二：量化精度损失归咎于框架。实际上，量化损失主要来源于权重和激活值的动态范围不匹配。QAT通过在训练中模拟量化误差，让模型自适应调整权重分布，从而显著减少损失。但QAT并非万能，若模型本身过拟合或数据分布极端，量化后仍可能失效。
误区三：盲目追求高精度。在TinyML场景中，精度与资源消耗呈正相关。一个F1分数0.95的模型可能比0.92的模型大4倍，功耗高3倍。应根据业务容忍度设定精度下限，而非一味追求最优。