2、TinyML基础：TinyML定义、典型应用场景（如可穿戴设备、智能传感器）、与传统ML的差异

TinyML是机器学习与嵌入式系统交叉融合的前沿领域，其核心目标是在毫瓦级甚至微瓦级功耗预算下，于资源极度受限的微控制器（MCU）上部署和运行推理模型。理解TinyML的定义边界、典型应用场景及其与传统云端机器学习（ML）的本质差异，是进行功耗分配与系统设计的前提。本章将系统梳理这些基础概念，为后续章节中“mA budget约束下的功耗分配”奠定认知框架。

2.1 TinyML的定义与核心边界

核心原理：TinyML并非简单的“小模型机器学习”，而是一套完整的系统工程方法论。根据TinyML基金会（TinyML Foundation）的权威定义，TinyML是“在极低功耗、资源受限的嵌入式设备上，实现机器学习推理能力的技术与方法的集合”。其典型硬件平台为Arm Cortex-M系列MCU、RISC-V内核MCU或超低功耗DSP，这些器件的Flash容量通常在256KB至2MB之间，RAM容量在16KB至512KB之间，工作电流在活跃状态下为1mA至50mA，睡眠状态下可低至微安级。

从工程实践角度，TinyML的边界条件可归纳为以下四个维度：

• 功耗维度：系统总功耗预算通常在1mW至100mW之间，电池供电场景下要求设备持续运行数月甚至数年。例如，一颗CR2032纽扣电池（标称容量约220mAh）若系统平均电流为1mA，理论续航约220小时（约9天）；若平均电流降至100µA，续航可延长至约3个月。mA budget约束直接决定了模型复杂度、推理频率和通信策略。
• 存储维度：模型参数、中间激活值和运行时数据必须全部容纳在MCU的片上存储中。以1MB Flash为例，若采用int8量化，可存储约100万个参数（约相当于MobileNetV1的1/4规模）；若采用float32，则仅能存储约25万个参数。这迫使开发者必须采用量化、剪枝、知识蒸馏等模型压缩技术。
• 计算维度：MCU的CPU主频通常在16MHz至200MHz之间，且多数不具备硬件浮点单元（FPU）或仅支持单精度FPU。因此，整数运算和定点运算成为主流选择。例如，Cortex-M4F支持单精度FPU，但执行一次浮点乘加（FMA）指令需要约3个时钟周期，而整数乘加仅需1个周期。
• 实时性维度：推理延迟要求通常在10ms至100ms级别。以关键词唤醒（KWS）为例，从麦克风采集音频帧到输出唤醒结果，端到端延迟需控制在50ms以内，否则用户会感知到明显卡顿。

2.2 典型应用场景深度解析

场景分类与工程特征：TinyML的应用场景可划分为四大类，每类场景对功耗分配策略有截然不同的要求。下表对比了各类场景的关键参数特征：

场景类别	典型设备	平均电流预算	推理频率	传感器类型	通信方式
可穿戴健康	智能手环、医疗贴片	50µA - 500µA	1Hz - 100Hz	PPG、IMU、ECG	BLE（蓝牙低功耗）
工业预测维护	振动传感器节点	1mA - 10mA	1kHz - 10kHz采样，1Hz推理	加速度计、温度、电流	LoRa / NB-IoT
智能家居	语音唤醒模块、存在检测	10mA - 50mA（活跃）	连续监听，事件触发推理	MEMS麦克风、PIR、ToF	Wi-Fi / Zigbee
环境监测	农业土壤传感器	10µA - 100µA（平均）	每小时1次 - 每天1次	土壤湿度、pH、气象	LoRa / 卫星

案例拆解：可穿戴心率异常检测系统

以一款医疗级可穿戴心电贴片为例，该设备需连续监测用户心电图（ECG），并在检测到房颤（AFib）等异常心律时通过BLE发送警报。系统约束如下：

• 硬件平台：Nordic nRF52840（Cortex-M4F @64MHz，1MB Flash，256KB RAM）
• 电池：CR2032纽扣电池（220mAh），目标续航14天
• 平均电流预算：220mAh / (14天 × 24小时) ≈ 0.65mA（含所有功耗）
• 传感器：ADS1292 ECG前端（采样率512Hz，功耗约300µA）
• 推理模型：1D-CNN，输入512点（1秒窗口），模型大小约32KB（int8量化）

功耗分配分析：

1. 传感器采集：ECG前端连续工作，功耗300µA，占总预算的46%。优化方案：采用“检测-唤醒”模式，平时以低功耗模式监测信号质量，仅在信号有效时启动全速采样。
2. MCU推理：每次推理耗时约15ms（64MHz主频），电流约8mA。若每秒推理1次，等效平均电流为8mA × 15ms / 1000ms = 0.12mA，占总预算的18%。优化方案：将推理频率降至每5秒1次，等效电流降至0.024mA。
3. BLE通信：仅在检测到异常时发送警报，每次发送耗时20ms，电流15mA。假设每天发送10次，等效平均电流为15mA × 20ms × 10 / 86400s ≈ 0.035µA，可忽略不计。
4. 睡眠功耗：MCU在System OFF模式下功耗约1.5µA，加上传感器关断后的漏电流，总计约5µA，占总预算的0.8%。

通过上述分配，系统总平均电流约为300µA + 24µA + 5µA ≈ 329µA，远低于650µA的预算上限，留有充足余量。实际部署中，还需考虑电池自放电、温度影响和器件老化等因素，建议预留20%-30%的功耗余量。

2.3 TinyML与传统ML的差异对比

核心差异维度：TinyML并非传统ML的简单“缩小版”，而是在多个维度上发生了质变。下表从工程实践角度对比了二者的关键差异：

对比维度	传统ML（云端/边缘服务器）	TinyML（MCU端）	工程影响
硬件平台	GPU / TPU / 多核CPU	单核MCU（Cortex-M/RISC-V）	无并行计算，需手工优化循环
数值精度	FP32 / FP16 / BF16	int8 / int16 / 定点数	需量化感知训练，精度损失控制
内存层次	GB级DRAM + 大容量缓存	KB级SRAM + Flash直接映射	需优化内存复用，避免动态分配
操作系统	Linux / Windows + 容器	裸机 / RTOS（FreeRTOS等）	无虚拟内存，需静态内存规划
功耗管理	数百瓦，散热优先	mW级，电池寿命优先	需精细的睡眠/唤醒状态机
模型更新	云端热更新，分钟级	OTA固件升级，需校验和回滚	模型版本管理复杂度高
调试手段	完整IDE + 可视化工具	JTAG/SWD + 串口打印	需设计可观测性埋点

开发流程差异：传统ML开发流程通常是“数据收集→训练→评估→部署”，模型训练与部署环境分离。而TinyML引入了“硬件在环（Hardware-in-the-Loop）”的迭代模式：

1. 模型设计阶段：需考虑目标MCU的算力上限（MACs/s）和内存上限。例如，Cortex-M4F @100MHz的理论峰值算力约为100M MACs/s，而MobileNetV2需要约300M MACs，直接部署不可行，必须进行结构搜索或轻量化设计。
2. 量化与压缩：训练后的FP32模型需经过量化（Post-Training Quantization, PTQ）或量化感知训练（Quantization-Aware Training, QAT）转换为int8格式。PTQ通常只需少量校准数据，但精度损失可能达2%-5%；QAT在训练中模拟量化误差，精度损失可控制在1%以内，但训练复杂度增加。
3. 算子映射：模型中的卷积、全连接等算子需映射到CMSIS-NN、TensorFlow Lite Micro等优化库。CMSIS-NN利用Cortex-M内核的DSP指令（如SMLAD）实现4倍以上的推理加速。
4. 功耗验证：在真实硬件上测量各阶段的电流曲线，使用高精度功耗分析仪（如Joulescope、Otii）记录推理、通信、睡眠等状态的电流波形，验证是否满足mA budget。

2.4 功耗分配的核心原则与设计方法论

功耗分配原则：在mA budget约束下，功耗分配应遵循“先测量，后分配；先静态，后动态；先硬件，后软件”的原则。具体步骤如下：

1. 建立功耗基线：使用功耗分析仪测量系统各状态（活跃、睡眠、深度睡眠、关断）的电流值，并记录各状态的持续时间。例如，某系统活跃状态电流为12mA，持续20ms；睡眠状态电流为50µA，持续980ms，则平均电流为12mA×0.02 + 0.05mA×0.98 ≈ 0.29mA。
2. 识别功耗热点：通过电流波形分析，找出占比最高的功耗模块。通常，无线通信（Wi-Fi/BLE）和传感器采集是两大热点。例如，BLE广播一次约消耗20mA×5ms = 0.1mAs，若每秒广播一次，等效电流为0.1mA。
3. 制定分配策略：根据各模块的功耗占比和业务优先级，设定功耗预算上限。例如，规定传感器采集不超过总预算的40%，推理不超过30%，通信不超过20%，睡眠漏电不超过10%。
4. 动态功耗管理：采用动态电压频率调整（DVFS）、时钟门控、电源门控等技术。例如，在推理完成后立即切换到低功耗模式，而非保持活跃等待。
5. 验证与迭代：在真实场景中长时间运行（至少24小时），记录电池电压下降曲线，验证实际续航是否达到设计目标。若续航不足，需重新分析功耗热点并优化。

案例复盘：智能振动传感器节点

某工业设备预测维护项目，要求部署无线振动传感器节点，监测电机轴承故障。节点采用STM32L4系列MCU（Cortex-M4F @80MHz），配备ADXL345加速度计（测量范围±16g，采样率3.2kHz），通过LoRa通信。设计目标：使用2节AA电池（总容量约2000mAh），续航6个月。

初始设计：MCU持续采样加速度计，每100ms执行一次FFT和故障分类推理。实测平均电流为8.5mA，理论续航仅2000mAh / 8.5mA ≈ 235小时（约10天），远不达标。

分析过程：通过功耗分析仪发现，MCU活跃时间占比过高（约80%），且LoRa通信每次发送消耗较大。进一步拆解：

• 加速度计采样：3.2kHz × 16bit × 2轴 = 102.4kbps，持续采样电流约400µA
• MCU推理：每次FFT+CNN推理耗时约35ms，电流12mA，每100ms执行一次，等效电流为12mA × 0.35 = 4.2mA
• LoRa发送：每次发送200ms，电流40mA，每10分钟发送一次，等效电流为40mA × 0.2 / 600 ≈ 0.013mA
• 睡眠电流：约5µA

优化措施：

1. 降低采样率：根据轴承故障特征频率（通常在1kHz以下），将采样率降至1.6kHz，加速度计功耗降至200µA。
2. 事件驱动推理：仅在振动能量超过阈值时才执行FFT和推理，正常状态下MCU进入睡眠。通过硬件比较器监测加速度计输出，当RMS值超过设定阈值时产生中断唤醒MCU。实测正常工况下，每小时仅需推理2-3次。
3. 优化推理频率：将推理间隔从100ms延长至1秒，且仅在事件触发时执行。
4. LoRa发送策略：仅在检测到异常时立即发送，正常状态每30分钟发送一次心跳包（缩短为50ms）。

优化后结果：系统平均电流降至约0.35mA，理论续航提升至2000mAh / 0.35mA ≈ 5714小时（约238天），满足6个月续航要求。实际部署中，考虑到电池自放电（约2%/月）和温度影响，实测续航约5.5个月，符合预期。