2. TinyML基础回顾

TinyML(微型机器学习)是指在极低功耗、极小内存和有限算力的嵌入式设备上运行机器学习模型的技术体系。与云端AI或传统嵌入式规则逻辑不同,TinyML必须在资源极度受限的硬件上完成数据采集、特征提取、推理决策甚至在线更新。理解端侧AI的约束条件,是设计可复用工程骨架的前提——因为骨架的每一层(数据管道、模型部署、运行时调度、功耗管理)都是围绕这些约束展开的。本章从硬件约束、应用场景和与传统ML的差异三个维度,建立TinyML工程化的底层认知框架。

TinyML 工程约束与设计空间 硬件约束 • 内存:SRAM 数十KB~数MB • Flash:256KB~16MB • 算力:MCU 数十~数百MHz • 功耗:mW级~µW级 • 无散热、无大容量存储 • 外设接口受限(SPI/I2C/UART) 工程骨架设计空间 • 模型量化:INT8/INT16 • 算子融合与剪枝 • 内存复用与静态分配 • 低功耗调度(事件驱动) • 增量更新与OTA • 传感器数据管道优化 典型应用场景 • 关键词唤醒(KWS) • 异常振动检测 • 人体活动识别(HAR) • 视觉唤醒/物体计数 • 预测性维护 • 环境感知(温湿度/气体) 与传统ML/云端AI的关键差异 维度 传统ML/云端 TinyML 部署环境 x86/GPU/大内存 MCU/RTOS/裸机 数据流 批量/离线/分布式 流式/在线/单样本 模型精度 FP32/FP64高精度 INT8/混合精度 功耗预算 数百瓦(服务器) mW级(电池供电) 更新方式 容器/模型热更新 OTA差分/离线烧录

2.1 端侧AI的三大硬约束:内存、功耗与算力

TinyML工程骨架的设计起点,不是模型精度,而是硬件资源预算。以典型的ARM Cortex-M4/M7或RISC-V MCU为例,其SRAM通常在16KB到512KB之间,Flash在256KB到2MB之间,主频在80MHz到480MHz之间。这意味着一个完整的TinyML系统必须将模型权重、中间激活值、运行时缓冲区、传感器数据队列全部塞进这几十到几百KB的内存中。相比之下,一个ResNet-50模型仅权重就有约100MB,显然无法直接部署。因此,工程骨架必须内置量化、剪枝、内存复用和算子替换机制。

功耗约束更为苛刻。对于纽扣电池供电的传感器节点,平均功耗必须控制在100µW到1mW之间,峰值功耗不超过几十mW。这要求系统采用"事件驱动+深度睡眠"的调度模式:传感器以低频率采样,MCU在无事件时进入睡眠状态(电流可低至1µA以下),仅在需要推理时快速唤醒并完成计算后再次休眠。工程骨架中的任务调度器、外设驱动和电源管理模块必须围绕这一模式设计,而不是像传统RTOS那样以时间片轮转为主。

算力方面,MCU没有向量指令集(部分Cortex-M55/M85支持Helium),没有硬件浮点单元(部分M4F有单精度FPU),整数乘法也需要多个周期。因此,模型推理必须采用定点运算,将浮点权重量化为INT8或INT16。以关键词唤醒模型为例,一个包含约50万参数的DS-CNN模型,在Cortex-M4上以INT8推理,单次推理时间约50-100ms,占用RAM约30KB,Flash约200KB。工程骨架需要提供统一的量化推理接口,并支持算子级性能剖析,以便开发者快速定位瓶颈。

核心原理:TinyML工程骨架的本质,是在"内存-功耗-算力"三维约束下寻找可行解。骨架必须提供资源预算检查工具(如模型内存占用估算、推理时间基准测试),在编译期或部署前就发现资源超限问题,而不是等到运行时崩溃。

2.2 典型应用场景与数据特征

TinyML的应用场景集中在需要实时响应、数据隐私敏感或网络覆盖不到的边缘设备上。根据数据模态,可分为以下几类:

场景类别典型任务传感器/输入模型规模推理频率
语音/音频关键词唤醒、声学事件检测MEMS麦克风50K-500K参数连续/10-50ms窗口
运动/IMU人体活动识别、跌倒检测加速度计/陀螺仪10K-100K参数1-50Hz
视觉物体检测、人员计数低分辨率摄像头(QVGA)100K-1M参数1-10fps
工业振动电机异常检测、预测性维护压电/加速度计5K-50K参数1-100Hz
环境感知气体分类、温湿度异常电化学/温湿度传感器1K-10K参数0.1-1Hz

这些场景的共同数据特征是:时序性强(音频、IMU、振动均为时间序列)、单样本推理(每次只处理一个窗口,不依赖批量数据)、特征局部化(关键信息集中在短时窗口内)。工程骨架的数据管道应针对这些特征设计:采用环形缓冲区管理传感器数据流,支持滑动窗口切片,并提供统一的特征提取接口(如MFCC、FFT、统计特征)。

2.3 与传统ML的差异:从训练到部署的全链路对比

传统机器学习(包括云端深度学习)与TinyML的差异不仅体现在硬件上,更体现在整个工程方法论上。下表从六个关键维度进行对比:

对比维度传统ML/云端AITinyML工程影响
模型训练GPU集群,FP32,大数据集PC/云端训练,量化感知训练骨架需提供量化模拟工具
模型部署容器/服务,动态加载静态链接,编译期确定骨架需支持模型转C数组
推理运行时依赖操作系统,多线程裸机/RTOS,单线程事件驱动骨架需提供轻量调度器
数据流批量读取,ETL管道流式采样,DMA传输骨架需封装传感器驱动
模型更新热加载新模型文件OTA差分升级,需校验骨架需集成引导加载程序
调试手段日志、可视化、交互式JTAG/SWD、串口打印、有限日志骨架需提供轻量日志模块

一个容易被忽视的差异是失败模式。云端模型推理失败可以重试或降级,而TinyML设备一旦内存溢出或栈溢出,往往直接死机或复位,且难以远程恢复。因此,工程骨架必须内置看门狗、内存保护(MPU)、异常捕获和状态上报机制。此外,传统ML的数据集可以离线扩充,而TinyML设备部署后数据分布可能漂移(如传感器老化、环境变化),骨架需要支持简单的在线校准或周期性重训练触发。

2.4 案例拆解:电池供电的工业振动监测节点

为具体说明上述约束如何影响工程骨架设计,我们拆解一个真实的工业场景:在工厂电机上部署振动监测节点,用于预测性维护。节点由CR2032纽扣电池供电,要求连续工作6个月以上,每10分钟采集一次振动数据并判断电机状态(正常/异常)。

初始约束与目标:MCU选用STM32L432(Cortex-M4F,80MHz,64KB SRAM,256KB Flash),加速度计为ADXL345(I2C接口,±16g,13位分辨率)。目标:平均功耗低于50µA(约150µW),异常检测准确率≥95%,误报率≤1次/天。

关键参数与设计决策:

  • 内存预算:模型权重量化后需≤20KB,激活缓冲区≤8KB,传感器DMA缓冲区4KB,剩余留给系统栈和任务控制块。
  • 功耗分解:传感器采样+推理约50ms,平均电流15mA(峰值),深度睡眠电流1.2µA。每10分钟一个周期,占空比=50ms/600s≈0.0083%,平均电流≈15mA×0.000083+1.2µA≈2.45µA,满足50µA预算。
  • 模型选择:采用1D-CNN(3层卷积+2层全连接),输入为256点FFT幅值谱,输出为二分类。量化后模型大小18.5KB,单次推理时间约35ms。

实施过程与问题:初版骨架使用FreeRTOS,但发现任务切换开销和定时器功耗偏高(额外增加3µA)。改为裸机事件驱动后,功耗降至2.1µA。另一个问题是ADXL345的I2C读取在DMA模式下偶尔出现数据错位,导致推理结果异常。排查发现是DMA缓冲区未对齐到32字节,修改为对齐分配后问题消失。

结果与复盘:最终系统平均功耗2.3µA,理论电池寿命约2.3年(CR2032容量约220mAh),实际测试6个月电压下降约15%。准确率96.2%,误报率0.3次/天。复盘经验:① 工程骨架的电源管理模块必须支持"采样-推理-睡眠"三段式状态机;② DMA缓冲区的内存对齐是嵌入式ML的常见坑;③ 模型量化后需在目标硬件上重新验证精度,不能只依赖PC端模拟。

常见误区:很多开发者将TinyML等同于"在MCU上跑TensorFlow Lite",但实际工程中,模型推理只占系统功耗和内存的一小部分。传感器驱动、数据搬运、任务调度和电源管理往往消耗更多资源。可复用骨架必须覆盖全链路,而非仅关注推理引擎。

2.5 总结:工程骨架的设计原则

综合上述分析,TinyML工程骨架应遵循以下设计原则:

  1. 资源显式化:所有内存分配在编译期完成,禁止动态malloc;提供内存池和静态分配器。
  2. 功耗可计算:每个模块(传感器、推理、通信)的功耗可独立测量,骨架提供功耗统计接口。
  3. 量化优先:默认使用INT8推理,提供量化精度评估工具,必要时支持混合精度。
  4. 事件驱动:避免轮询和阻塞等待,所有外设操作基于中断或DMA完成回调。
  5. 可测试性:在PC上模拟硬件接口(通过HAL抽象层),实现"一次编写,两端调试"。