边缘计算与TinyML基础
在嵌入式设备上实现本地告警识别，首先需要理解两个核心概念：边缘计算与TinyML。边缘计算将数据处理能力从云端下沉到网络边缘，而TinyML则是在极低功耗、极小内存的微控制器上运行机器学习模型的技术。两者结合，使得在传感器节点上直接完成数据采集、特征提取、模型推理和告警触发成为可能。本章将系统梳理边缘计算的定义、TinyML的技术边界，并通过对比表格和实际案例，帮助您建立清晰的工程判断框架。
边缘计算的核心原理与工程定位
边缘计算并非简单的“把服务器搬到现场”，而是一种分布式计算架构的重新设计。其核心思想是将数据处理、存储和应用逻辑放在靠近数据源头的网络边缘节点上。在TinyML告警系统中，边缘节点通常就是集成传感器和微控制器（MCU）的嵌入式设备。边缘计算的本质是“数据在哪里产生，就在哪里处理”，这改变了传统“端-管-云”的集中式处理模式。
从工程角度看，边缘计算的价值体现在三个维度：时延维度，本地推理避免了数据往返云端的网络延迟，对于振动异常、声音异常等需要毫秒级响应的告警场景至关重要；带宽维度，工业现场每秒可能产生数千个加速度样本，全部上传云端既不经济也不现实，边缘节点只上传告警事件或压缩特征；可靠性维度，当网络中断或云端服务不可用时，边缘设备仍能独立完成监测和告警功能，这是安全生产场景的硬性要求。
边缘计算的实现层级通常分为：端侧（传感器+MCU）、边缘网关和边缘服务器。TinyML主要工作在端侧，而边缘网关负责协议转换和聚合。在课程项目中，我们聚焦于端侧MCU上的模型部署，因为这是功耗和成本最敏感、也最能体现TinyML优势的层级。
TinyML的定义与技术边界
TinyML是机器学习与嵌入式物联网系统的交叉领域，其定义为：在功耗受限（毫瓦级甚至微瓦级）、内存受限（KB级别）、计算能力受限（几十MHz主频）的MCU上，部署和运行机器学习模型的技术与方法论。它并非简单地将模型“压缩”，而是从模型架构设计、量化压缩、运行时优化到硬件指令集适配的全链路工程实践。
TinyML的技术栈包含三个关键层次：
- 模型层：采用轻量化网络结构，如MobileNet、TinyMLPerf基准模型，或针对特定任务设计的1D-CNN、决策树集成等。模型参数量通常在几十KB到几百KB之间。
- 编译器与运行时层：TensorFlow Lite for Microcontrollers、CMSIS-NN、Glow等工具链，将训练好的模型转换为C++数组，并利用ARM Cortex-M系列处理器的SIMD指令（如DSP扩展）加速推理。
- 硬件层：主流平台包括STM32F4/H7系列、ESP32、Nordic nRF52系列，以及专为TinyML设计的MAX78000等。这些MCU通常集成FPU（浮点单元）或DSP指令，但内存仍以SRAM为主，容量在256KB~1MB之间。
需要特别强调的是，TinyML不等于“在树莓派上跑模型”。树莓派运行Linux系统，拥有GB级内存和GPU，属于边缘服务器范畴。TinyML的目标平台是裸机或RTOS环境下的MCU，这决定了其模型量化（通常为8位整数）和内存管理的特殊性。
与传统云端AI的深度对比
为了帮助您在实际项目中做出架构决策，下表从多个维度对比了TinyML边缘推理与云端AI推理的差异。请注意，两者并非替代关系，而是互补关系——TinyML负责实时响应和初步筛选，云端负责复杂分析和全局优化。
| 对比维度 | TinyML边缘推理 | 云端AI推理 |
|---|---|---|
| 硬件平台 | MCU（Cortex-M/RISC-V），主频≤200MHz | GPU/TPU/CPU集群，主频≥2GHz |
| 内存容量 | SRAM 256KB~1MB，Flash 1~2MB | DRAM 16GB~512GB |
| 功耗预算 | 1mW~100mW（电池供电） | 300W~2000W（需散热） |
| 推理延迟 | 1ms~50ms（确定性） | 100ms~2s（含网络传输） |
| 网络依赖 | 完全离线可用 | 必须联网，断网即失效 |
| 数据隐私 | 原始数据不出设备 | 数据需上传，存在泄露风险 |
| 模型复杂度 | 参数量≤1MB，8位整数运算 | 参数量可达GB级，32位浮点运算 |
| 更新维护 | 需OTA固件升级，周期长 | 云端热更新，灵活快速 |
| 适用场景 | 实时告警、设备状态监测、关键词唤醒 | 复杂图像识别、自然语言处理、全局数据分析 |
从上表可以看出，TinyML的核心优势在于确定性延迟和离线自治。在边缘告警场景中，我们最关心的是“设备是否在100毫秒内发出告警”，而不是“模型准确率是否达到99.9%”。因此，TinyML项目通常采用“边缘初判+云端复核”的混合架构：边缘设备用轻量模型快速过滤正常数据，仅将疑似异常片段上传云端做二次确认。
典型应用场景与工程案例拆解
TinyML在工业、医疗、消费电子领域已有大量落地实践。以下通过一个电机振动监测的案例，完整展示从场景分析到方案落地的闭环过程。
案例背景与约束：某工厂需要对20台关键电机进行24小时振动监测，每台电机安装一个加速度传感器（ADXL345）和一颗STM32L4系列MCU（Cortex-M4F，80MHz，SRAM 128KB）。工厂要求：① 检测电机轴承早期故障（特征频率在2kHz~5kHz）；② 告警延迟不超过200ms；③ 设备采用电池供电，目标续航6个月；④ 工厂Wi-Fi信号不稳定，不能依赖实时上传。
初始方案与问题：最初方案是传感器每100ms采集一组512点FFT频谱，通过Wi-Fi上传云端进行异常检测。实测发现：每次上传约4KB数据，20台设备同时工作时，Wi-Fi拥塞导致平均延迟达到1.2秒，且电池仅能支撑3周。根本原因在于：FFT频谱数据量过大，且云端推理的往返时间不可控。
TinyML改造方案：
- 特征工程前置：在MCU上直接计算时域特征（峰值、均方根、峭度）和频域特征（特定频带能量），将每帧数据压缩为16个浮点特征（量化后为16字节）。
- 轻量模型部署：训练一个包含2层隐藏层（每层16个神经元）的全连接网络，参数量约600个，量化后模型大小仅2.4KB。使用TensorFlow Lite for Microcontrollers部署，单次推理耗时约3ms。
- 两级告警策略：第一级，模型输出异常概率超过0.7时，立即触发本地蜂鸣器告警；第二级，将异常帧的原始数据（512点）缓存到SD卡，并在Wi-Fi可用时批量上传云端做精确故障类型诊断。
- 功耗优化：MCU在正常状态下进入睡眠模式，每100ms唤醒一次采集数据并推理，平均工作电流从45mA降至8mA，电池续航提升至5个月。
结果对比：改造后，告警延迟稳定在50ms以内（本地推理3ms+判断逻辑），误报率从云端方案的12%降至5%（因为本地特征提取减少了传输噪声干扰）。云端复核机制保留了故障类型识别的能力，同时将上传数据量减少了97%。
风险与代价：本地模型对未见过的故障模式泛化能力有限，需要定期用新数据重新训练并OTA更新模型。此外，8位量化导致模型精度损失约1.5%，在安全关键场景需设置更保守的告警阈值。
这个案例揭示了TinyML告警系统设计的核心原则：在边缘做“粗筛”，在云端做“精诊”。边缘模型不需要完美，只需要足够好地捕捉异常信号，将高价值数据留给云端处理。
常见误区与设计复盘
在TinyML项目实践中，工程师常陷入以下误区，需要特别警惕：
- 误区一：追求模型精度而忽视内存占用。在MCU上，模型参数量超过SRAM容量会导致频繁的Flash读取，推理速度下降10倍以上。正确做法是优先保证模型能完整加载到SRAM中，再考虑精度优化。
- 误区二：忽略数据采集与标注成本。TinyML模型虽然小，但训练数据同样需要覆盖各种工况和故障模式。很多项目在模型部署后才发现现场数据分布与训练数据差异巨大，导致误报率飙升。
- 误区三：将PC端模型直接转换部署。PC端模型可能包含TinyML工具链不支持的算子（如某些自定义层），且浮点模型直接量化会导致精度骤降。正确流程是使用量化感知训练（QAT）从训练阶段就模拟8位精度。
- 误区四：忽视无线通信的功耗占比。在告警设备中，MCU推理功耗往往只占20%，而无线发射（尤其是Wi-Fi）占60%以上。设计时应尽量减少无线传输次数，或使用BLE/Sub-GHz等低功耗协议。
工程提醒：在开始TinyML项目前，请务必完成以下三项检查：① 确认MCU的SRAM和Flash容量是否满足模型+运行时库的需求（预留30%余量）；② 确认传感器采样率与模型输入尺寸匹配，避免在MCU上做昂贵的重采样；③ 确认告警响应时间预算，包括传感器采样时间、特征计算时间、模型推理时间和无线发送时间，总和必须小于业务要求的最大延迟。