📚 课程目录第2章 TinyML基础

2、TinyML基础：定义、典型应用场景与硬件平台

TinyML（微型机器学习）是机器学习与嵌入式物联网系统交叉融合的前沿领域，其核心目标是在功耗受限、计算资源有限、存储空间狭小的微控制器（MCU）或极低功耗处理器上，直接部署和运行机器学习推理模型。与云端AI依赖高速网络和强大GPU集群不同，TinyML强调本地化、实时性、低功耗与隐私保护。理解TinyML的基础定义、典型应用场景以及硬件平台的资源约束，是后续规划RTOS（实时操作系统）任务调度、确定推理任务优先级的前提。本章将系统梳理这些基础概念，并建立“算法-硬件-实时性”的全局视图。

上图展示了TinyML生态系统的三个核心支柱：应用场景（解决什么问题）、硬件平台（在哪里运行）以及资源约束（边界条件）。这三者共同决定了RTOS中推理任务的设计方式——例如，一个在Cortex-M4上运行的语音唤醒模型，其推理任务必须被拆分为“特征提取”和“分类”两个子任务，并分别赋予不同的实时优先级。下面我们将逐一深入剖析。

2.1 TinyML的定义与核心特征

TinyML并非简单的“小模型”，而是一套完整的工程方法论。其官方定义由TinyML基金会提出：“在极低功耗、资源受限的嵌入式设备上，使能机器学习推理技术的一系列工具、算法和硬件架构”。它的核心特征可以归纳为以下四点：

极致的资源效率：模型大小通常小于100KB，运行时内存占用小于256KB，Flash存储小于1MB。这要求模型量化（如INT8）和剪枝成为标配。
本地化推理：数据无需上传云端，在设备端直接完成预处理、推理和后处理，从根本上消除网络延迟和带宽成本。
事件驱动与稀疏激活：系统并非持续满负荷运行，而是由传感器事件（如声音、运动、振动）触发推理，空闲时进入深度睡眠模式。
软硬件协同设计：算法必须针对特定MCU的指令集（如ARM Cortex-M的DSP指令）和内存层次进行优化，而非通用计算。

  关键理解：在RTOS集成语境下，TinyML推理任务通常是一个周期性的、计算密集型的、有硬截止时间的任务。例如，一个以20ms周期运行的振动异常检测模型，其推理必须在下一个采样周期到来前完成，否则数据将被覆盖。这决定了它在RTOS中应被设置为高优先级周期任务，而非低优先级后台任务。

2.2 典型应用场景深度拆解

TinyML的应用场景广泛，但并非所有场景都适合。判断一个场景是否适合TinyML，需满足三个条件：数据可在本地处理、模型复杂度可控、实时性要求明确。以下是三个最具代表性的场景。

2.2.1 关键词唤醒（KWS）

这是TinyML最成熟的落地场景。设备（如智能音箱、耳机）需要持续监听环境声音，但仅在检测到特定唤醒词（如“Hey Siri”）时才启动主系统。其技术链路为：麦克风采集16kHz/16bit音频 → 分帧（30ms帧长，20ms帧移） → 提取MFCC特征（40维） → 送入深度可分离卷积网络（DS-CNN） → 输出概率序列 → 状态机判定唤醒。

在RTOS中，该任务通常被划分为两个子任务：音频采集任务（高优先级，由DMA中断驱动）和推理任务（中优先级，周期为20ms）。推理任务必须保证在20ms内完成，否则会丢失音频帧。实际工程中，一个参数量为30K的INT8量化模型在Cortex-M4（180MHz）上推理耗时约15ms，刚好满足实时性要求。

2.2.2 工业异常检测（预测性维护）

在旋转机械（电机、泵、风机）上部署加速度传感器，通过分析振动频谱判断轴承磨损或不对中故障。与KWS不同，异常检测通常采用半监督学习——仅用正常数据训练自编码器，推理时计算重构误差。若误差超过阈值，则判定为异常。

该场景的实时性要求具有弹性：并非每个采样点都需要立即推理，而是以1-10秒为周期进行批量推理。因此，在RTOS中可将其设置为低优先级任务，利用CPU空闲时间执行，避免与通信任务争抢资源。但需注意，一旦检测到异常，必须立即触发高优先级的中断处理任务进行数据保存和报警。

2.2.3 视觉识别（图像分类）

在智能门锁、工业质检中，使用低分辨率摄像头（如96x96 RGB）进行人脸或缺陷检测。视觉模型通常比音频模型大一个数量级，对内存带宽要求高。例如，MobileNetV1（alpha=0.25）量化后仍有约400KB参数，需要外部Flash存储，推理时逐层加载到RAM。

视觉推理任务的RTOS设计难点在于内存管理。由于MCU的RAM通常只有256KB，而模型中间特征图可能占用大量内存，因此需要采用内存池复用和就地推理技术。在RTOS中，该任务通常独占一个高优先级线程，并禁止被其他任务抢占，以避免内存碎片化。

场景	输入数据	模型类型	典型延迟要求	RTOS任务属性
关键词唤醒	16kHz音频流	DS-CNN / CRNN	<50ms	周期任务，20ms周期，高优先级
异常检测	1kHz振动波形	自编码器 / 1D-CNN	<1s（弹性）	低优先级，可被抢占，批量处理
视觉识别	96x96 RGB图像	MobileNet / EfficientNet	<200ms	高优先级，独占CPU，内存保护

选型建议：在课程实验或产品原型阶段，优先选择KWS作为入门场景，因为它对硬件要求最低（仅需麦克风阵列），且模型训练工具链成熟（TensorFlow Lite for MCU）。异常检测次之，视觉识别难度最高，建议在掌握RTOS调度后再深入。

2.3 硬件平台与资源约束分析

硬件平台决定了TinyML模型的上限。当前主流平台分为三个层级，每个层级的RTOS集成策略截然不同。

2.3.1 低端MCU（Cortex-M0/M0+）

代表芯片：STM32L0、Nordic nRF52系列。主频16-64MHz，RAM 8-32KB，Flash 64-256KB。这类平台无法运行任何CNN模型，仅能运行决策树、线性回归或极小的逻辑回归模型。在RTOS中，推理任务通常被实现为函数调用而非独立任务，因为任务切换开销（约2-5μs）已经占用了大量CPU时间。

2.3.2 中高端MCU（Cortex-M4/M7/M33）

代表芯片：STM32F4/H7、i.MX RT系列。主频180-600MHz，RAM 256KB-1MB，Flash 1-2MB。这是TinyML的主战场。支持INT8量化模型，可运行参数量在100K-1M之间的模型。硬件上通常配备FPU（浮点单元）和DSP指令，可加速矩阵运算。在RTOS中，推理任务应设置为中等优先级，并利用CMSIS-DSP库进行底层优化。

2.3.3 带NPU的SoC（Cortex-A + NPU）

代表芯片：STM32N6、瑞萨RA8、以及树莓派RP2040+外部NPU。NPU（神经网络处理单元）可提供高达1-4 TOPS的算力，但功耗也相应提升至数百mW。此时，RTOS的职责转变为管理NPU的DMA传输和任务队列。推理任务本身由NPU硬件完成，CPU仅负责数据搬运和结果后处理。

风险提示：初学者常犯的错误是忽视内存带宽瓶颈。即使MCU主频很高，如果模型权重存储在外部Flash（通过SPI/QSPI接口），读取速度可能仅为10-20MB/s，导致推理速度被IO限制。在RTOS设计时，必须考虑将热数据（如当前层的权重）预取到内部SRAM或TCM（紧耦合内存）中。

// 示例：在Cortex-M4上使用CMSIS-DSP进行矩阵乘法加速
// 假设输入特征为 1x128，权重为 128x64
arm_mat_instance_f32 mat_a, mat_b, mat_out;
arm_mat_init_f32(&mat_a, 1, 128, (float32_t*)input);
arm_mat_init_f32(&mat_b, 128, 64, (float32_t*)weights);
arm_mat_init_f32(&mat_out, 1, 64, (float32_t*)output);
arm_mat_mult_f32(&mat_a, &mat_b, &mat_out); // 硬件加速，耗时约0.5ms @180MHz

2.4 案例拆解：从零部署一个振动异常检测模型

为了将上述概念串联，我们以一个实际的工业风机轴承监测项目为例，展示TinyML从硬件选型到RTOS集成的完整链路。

背景与约束：某工厂需要在10台风机上加装无线传感器节点，监测轴承早期故障。要求：节点电池供电（2节AA电池），工作寿命≥1年，检测准确率≥95%，误报率≤1次/月。现场无WiFi，需通过BLE 5.0将报警信息发送至网关。

硬件选型：选择STM32L4系列（Cortex-M4 @80MHz，512KB Flash，128KB RAM），外接ADXL345加速度传感器（±16g，1kHz采样率），使用BLE模块（nRF52832）进行通信。该MCU在睡眠模式下功耗为1μA，工作模式（80MHz）功耗约20mA。

模型设计：采集正常状态振动数据100小时，提取时域特征（RMS、峰值因子、峭度）和频域特征（1x/2x/3x转频幅值），共12维特征。训练一个两层全连接自编码器（12-8-12），隐藏层使用ReLU激活。模型参数量为12*8+8+8*12+12=212个参数，量化后仅占用848字节Flash。

RTOS集成过程：

任务划分：创建3个任务——传感器采集任务（优先级3，周期1ms）、特征提取任务（优先级2，周期1s）、推理任务（优先级1，周期1s）。BLE通信任务（优先级0，事件驱动）。
内存优化：特征提取任务和推理任务共享一个全局缓冲区，通过互斥锁保护。推理任务使用静态分配的内存池，避免动态分配导致碎片。
功耗管理：传感器采集任务完成后，CPU进入WFI（等待中断）状态。推理任务仅在特征提取完成后被唤醒，执行时间约2ms，然后立即睡眠。
实时性验证：使用逻辑分析仪测量，从传感器中断到推理完成的总延迟为3.2ms，远小于1s的周期要求。CPU占用率仅为0.32%，满足电池供电需求。

结果与复盘：实际运行6个月后，成功检测出2次轴承早期磨损（振动幅值增加15%），误报0次。但发现一个问题：当环境温度变化超过20℃时，自编码器的重构误差阈值需要动态调整。最终通过增加温度补偿系数解决。

  经验总结：该案例表明，TinyML项目的成功不仅取决于模型精度，更取决于RTOS任务设计是否匹配硬件资源。将推理任务放在低优先级，利用空闲时间执行，既保证了实时性，又实现了极低功耗。这是“资源约束驱动设计”的典型范例。

2.5 常见误区与设计复盘

在TinyML与RTOS集成中，以下误区需要特别警惕：

误区一：模型越大越准。在资源受限设备上，模型大小与推理延迟呈非线性关系。一个200KB的模型可能导致推理时间超过100ms，无法满足实时性。应优先使用模型剪枝和知识蒸馏。
误区二：所有任务都设为高优先级。这会导致低优先级任务饿死，且增加上下文切换开销。正确做法是使用速率单调调度（RMS），周期越短优先级越高。
误区三：忽略数据预处理时间。在KWS中，MFCC特征提取可能占整个推理时间的40%。在RTOS中，应将特征提取和分类器推理拆分为两个任务，利用流水线并行。
误区四：使用浮点模型。Cortex-M4虽然有FPU，但浮点运算比INT8定点运算慢3-5倍，且功耗更高。应默认使用INT8量化，仅在必要时对关键层保留浮点。