TinyML基础：嵌入式机器学习的概念、典型应用场景、资源约束与挑战
TinyML（Tiny Machine Learning）是机器学习与嵌入式物联网系统交叉融合的前沿领域，其核心目标是在毫瓦级甚至微瓦级功耗预算下，于MCU（微控制器）、DSP（数字信号处理器）或NPU（神经网络处理单元）等资源极度受限的硬件上，部署和运行经过优化的机器学习模型。与云端AI依赖高速网络和强大算力不同，TinyML强调本地推理、低延迟、数据隐私和极低功耗。理解TinyML的基础概念、应用边界和工程约束，是后续在Arm Ethos-U系列NPU上进行模型部署与调优的必修课。本章将系统梳理嵌入式机器学习的核心原理、典型场景、资源约束体系以及工程落地中的关键挑战。
核心原理：从云端AI到边缘AI的范式转移
传统嵌入式系统与AI的结合经历了从“端-云”协同到“端侧智能”的演进。TinyML的底层逻辑并非简单地将神经网络模型“缩小”，而是基于信息论与计算理论的重新设计。其核心原理包含三个层面：
- 模型层面的稀疏化与低比特化：神经网络中存在大量冗余连接和参数。通过训练后量化（Post-Training Quantization, PTQ）将FP32权重映射为INT8甚至INT4，可将模型体积压缩4~8倍，同时利用Arm Ethos-U等NPU的硬件加速特性，实现近线性的推理速度提升。例如，一个MobileNetV1模型在FP32下约需4.3MB存储，量化至INT8后仅需1.1MB，完全可放入主流MCU的Flash中。
- 运行时层面的算子融合与内存复用：嵌入式推理引擎（如TensorFlow Lite for Microcontrollers）通过算子融合（如Conv+ReLU+Pooling合并）减少中间张量的内存搬运。同时，采用“内存规划器”静态分配张量缓冲区，避免动态内存分配带来的碎片化和不确定性，确保实时性。
- 硬件层面的异构计算：Arm Ethos-U系列NPU作为MCU的协处理器，专门针对矩阵乘法和卷积运算设计了脉动阵列（Systolic Array）。CPU负责控制流和预处理，NPU负责大规模并行计算，两者通过AXI总线高速交互，实现能效比（TOPS/W）的飞跃。
典型应用场景与部署判断方法
并非所有AI应用都适合TinyML。判断一个场景是否适合嵌入式机器学习，需要遵循“3S原则”：Small（数据量小或特征明确）、Simple（任务单一）、Sensitive（对延迟或隐私敏感）。以下是当前工业界和消费电子领域最成熟的四类场景：
| 场景类别 | 具体案例 | 输入数据特征 | 典型硬件资源需求 | 部署可行性 |
|---|---|---|---|---|
| 语音/音频理解 | 智能音箱唤醒词、工业设备异响检测 | 16kHz/16bit单声道，1~2秒帧 | Flash: 300KB, SRAM: 50KB | 高（成熟度最高） |
| 振动/状态监测 | 电机轴承故障预测、旋转机械失衡 | 加速度计三轴数据，1kHz采样 | Flash: 100KB, SRAM: 20KB | 极高（规则明确） |
| 视觉感知 | 人脸检测门禁、工业OCR字符识别 | QVGA(320x240)灰度或RGB图像 | Flash: 1MB, SRAM: 500KB | 中高（需NPU加速） |
| 生物电信号 | 可穿戴ECG心律失常检测、EEG睡眠分期 | 单导联/多导联，250~500Hz | Flash: 200KB, SRAM: 40KB | 高（需严格低功耗） |
操作判断流程：在项目立项时，建议按以下步骤进行技术选型：
- 数据量评估：若需处理每秒超过10MB的原始数据（如高清视频流），且无法在端侧降采样，则不适合TinyML。
- 实时性要求：若控制闭环要求<10ms响应，且无法容忍网络抖动，则必须端侧推理。
- 功耗预算：若设备使用纽扣电池且需连续工作1年以上，平均功耗必须控制在100µW以内，这要求模型推理功耗低于10mW。
- 模型复杂度测试：在PC上训练一个基线模型，若参数量超过5M且无法通过剪枝降至1M以下，则需考虑更换更高效的模型架构（如MobileNetV3、EfficientNet-Lite）。
资源约束体系：内存、算力与功耗的三角博弈
嵌入式机器学习面临的核心约束可以用“不可能三角”来概括：精度、资源消耗、开发效率三者难以兼得。具体到硬件层面，主要约束体现在以下三个维度：
- 存储墙（Memory Wall）：典型MCU的Flash为512KB~2MB，SRAM为256KB~1MB。一个300KB的模型在推理时，需要同时容纳权重、激活值、中间计算结果。若激活值超过SRAM容量，将导致频繁的Flash读取，功耗增加10倍以上。因此，激活值的内存占用往往比权重更关键。
- 算力墙（Compute Wall）：Arm Cortex-M55内核主频通常为160MHz~400MHz，提供约0.5~2 GOPS的算力。而Ethos-U55 NPU可提供32~128 GOPS的算力。但NPU的利用率取决于数据搬运效率。若卷积核尺寸与NPU的MAC阵列不匹配，实际吞吐量可能仅为峰值的30%。
- 功耗墙（Power Wall）：在Active状态下，MCU+NPU的功耗通常在50mW~200mW。对于电池供电设备，需要采用“事件驱动”架构：传感器持续工作（µW级），但NPU仅在检测到关键事件时才被唤醒。例如，Always-on语音唤醒场景中，VAD（语音活动检测）模块功耗仅需50µW，而完整的KWS模型推理功耗为5mW，平均功耗可控制在100µW以内。
案例拆解：工业电机振动异常检测的端侧部署
为了将上述概念具象化，我们拆解一个真实的工业预测性维护案例。某工厂需要在一条生产线的10台电机上加装无线振动传感器，用于检测轴承早期故障。原始方案是将3轴加速度计数据通过Wi-Fi上传至云端进行FFT分析，但存在两个痛点：车间Wi-Fi信号不稳定导致数据丢失；敏感的设备运行参数不允许出园区。
初始目标与约束：采用Arm Cortex-M55+Ethos-U55方案，要求设备使用2节AA电池供电，连续工作6个月。传感器采样频率为4kHz，每次采集1秒数据（3轴共12000个样本）。
关键输入数据与参数：
- 模型输入：经过FFT后的频谱特征，取0~2kHz频段的128个频点幅值。
- 模型结构：2层1D-CNN（卷积核大小3，通道数16/32）+ 全连接层（输出3类：正常/内圈故障/外圈故障）。
- 量化策略：PTQ量化至INT8，权重从原始FP32的180KB压缩至45KB。
分析判断过程：初始在PC上训练模型精度为98.2%，但部署到开发板上后，实测推理时间为85ms，功耗高达45mW。通过Vela编译器分析发现，NPU利用率仅为22%，瓶颈在于第一层卷积的输入数据需要从SRAM频繁搬运至NPU，且FFT预处理在CPU上耗时30ms。
实际操作步骤：
- 算子替换：将标准Conv1D替换为Depthwise Separable Conv，参数量减少40%，精度仅下降0.3%。
- 数据流水线优化：利用CMSIS-DSP库的硬件加速FFT函数，将预处理时间从30ms降至8ms。
- 内存复用：将FFT输出缓冲区与模型输入张量共用同一块SRAM区域，节省12KB内存。
- 功耗调度：采用“双缓冲”机制，在NPU推理第N帧数据时，CPU同时采集第N+1帧数据，将整体有效功耗降至12mW。
结果对比与复盘：优化后推理时间降至23ms，平均功耗降至9mW（满足电池寿命要求），精度保持97.6%。复盘经验：在TinyML中，数据预处理（特征工程）的优化空间往往大于模型结构本身。此外，NPU并非万能，对于小卷积核（如3x3）且通道数少的层，CPU+SIMD指令可能比NPU更高效，需要灵活切换。
常见误区与总结复盘
在TinyML项目开发中，以下误区会导致项目延期或失败：
- 误区一：忽视数据采集的物理约束。传感器噪声、温漂、安装位置差异会导致训练集与真实数据分布偏移。解决方法是采用数据增强（添加高斯噪声、随机缩放）和域自适应技术。
- 误区二：将量化视为“事后补救”。量化感知训练（QAT）应在训练阶段就模拟INT8的数值范围，而非在训练完成后直接PTQ。对于激活值动态范围大的网络（如MobileNetV1），PTQ可能导致精度暴跌5%以上。
- 误区三：忽略工具链的版本兼容性。TensorFlow Lite for MCU、Vela编译器、CMSIS-NN库之间存在版本依赖。例如，Vela 3.0不支持某些自定义算子，需要提前确认算子白名单。
- 误区四：缺乏系统级的功耗测量。仅用万用表测平均电流是不够的，需要使用高精度功耗分析仪（如Joulescope）捕捉推理瞬间的电流尖峰，以优化电源管理策略。
总结：TinyML的本质是在“资源受限”与“智能能力”之间寻找最优平衡点。本章节建立的概念框架——从模型压缩、硬件加速到功耗调度——是后续学习Ethos-U部署的基石。掌握这些基础，你将能更深刻地理解为何在Arm平台上，软件（模型结构）与硬件（NPU架构）的协同设计是决定最终性能的关键。