2、TinyML基础：TinyML定义、边缘计算与云计算的对比、典型应用场景（如可穿戴设备、智能家居）

TinyML（微型机器学习）是机器学习与嵌入式物联网系统交叉融合的前沿领域，其核心目标是在功耗受限、计算资源有限、存储空间极小的微控制器（MCU）上部署和运行机器学习模型。与云端AI依赖高性能GPU/TPU集群不同，TinyML强调在数据产生的物理位置附近完成推理，实现毫瓦级甚至微瓦级的智能感知。理解TinyML的定义边界、边缘与云端的职责划分，以及典型场景的工程约束，是后续进行ONNX模型部署与功耗调优的认知基础。本章将系统梳理这些核心概念，并建立一套用于判断“何时该用TinyML”的决策框架。

上图展示了TinyML设备与云端在典型AIoT系统中的分工与协作关系。边缘端负责实时感知、特征提取和低延迟推理，云端则承担模型训练、大规模数据分析和OTA升级。两者通过低频通信链路交互，避免原始数据洪流对网络和云端的冲击。这种“端云协同”架构是当前TinyML产品落地的标准范式。

2.1 TinyML定义与核心边界

核心原理：TinyML并非简单的“在单片机上跑神经网络”，而是一套完整的工程方法论，涵盖模型设计、压缩、编译优化、运行时部署和功耗管理。其技术本质是在资源极度受限（通常Flash < 1MB，RAM < 256KB，CPU主频 < 200MHz）的MCU上，实现高效的推理计算。与嵌入式AI（如树莓派上的TensorFlow Lite）不同，TinyML的目标平台通常是裸机或RTOS环境，没有Linux内核的虚拟内存管理，所有内存分配和调度都需要精细控制。

判断方法：一个项目是否属于TinyML范畴，可以从以下三个维度进行判定：

• 功耗预算：设备依赖电池或能量采集供电，平均工作电流在mA级甚至μA级，峰值功耗不超过数百mW。
• 算力约束：处理器为ARM Cortex-M系列、RISC-V MCU或低功耗DSP，不支持SIMD指令集（部分支持DSP扩展），无硬件浮点单元（FPU）或仅有单精度FPU。
• 内存限制：模型权重和中间激活张量必须能放入片上SRAM，无法依赖外部DRAM。

2.2 边缘计算与云计算的深度对比

核心原理：边缘计算与云计算并非替代关系，而是互补关系。边缘计算将计算推向数据源，解决了云计算在实时性、带宽、隐私和可靠性方面的固有短板。在TinyML场景中，边缘设备通常只执行推理，而训练仍在云端完成。这种分工基于一个朴素的事实：训练需要海量数据和强大算力，而推理只需要“记住”训练得到的模式。

对比分析：下表从多个工程维度对比了TinyML边缘设备与云端数据中心在AI推理任务中的差异：

操作流程：在实际项目中，确定“端云分工”可遵循以下决策流程：

1. 列出所有功能需求，标注每个功能的实时性要求（硬实时/软实时/非实时）。
2. 评估数据敏感性，判断哪些数据不能离开设备（如生物特征、工业配方）。
3. 计算通信成本，估算每秒需要上传的数据量，对比可用带宽（如LoRa 2kbps vs Wi-Fi 2Mbps）。
4. 确定推理位置：若延迟要求 < 20ms 或数据敏感，则必须边缘推理；若模型需要频繁更新且延迟容忍 > 200ms，可考虑云端推理。
5. 设计混合方案：边缘做初步筛选（如唤醒词检测），云端做深度分析（如语义理解）。

2.3 典型应用场景拆解：可穿戴设备与智能家居

核心原理：可穿戴设备和智能家居是TinyML最具商业价值的落地领域。这两类场景的共同特点是：设备数量庞大、电池更换困难、隐私敏感、需要7×24小时持续感知。TinyML的价值在于让设备具备“本地智能”，只在必要时唤醒通信模块，从而大幅延长续航。

案例拆解：我们以一款工业手环的跌倒检测功能为例，完整展示TinyML项目的工程决策过程。

• 背景与约束：某工厂为高危岗位工人配备智能手环，要求实时检测跌倒并自动报警。手环采用 Nordic nRF52840（Cortex-M4F, 64MHz, 256KB RAM），电池容量200mAh，目标续航30天。网络环境为工厂内部LoRa网关，上行带宽仅2kbps。
• 初始现象与目标：初版方案将加速度计原始数据（50Hz×3轴×2字节=300B/s）持续通过LoRa上传至云端进行跌倒检测。实测发现：LoRa模块平均电流45mA，手环续航仅4.5小时，且网关并发容量不足。目标改为：本地完成跌倒检测，仅报警时发送1条短消息（20字节）。
• 关键输入数据与参数：采集了2000次跌倒模拟数据和5000次日常活动数据（走路、弯腰、上下楼）。使用3轴加速度计，采样率50Hz，窗口大小2秒（100个采样点）。特征提取：计算合加速度向量幅值SVM = √(x²+y²+z²)，提取窗口内的峰值、均值、方差和过零率。
• 分析判断过程：对比了三种方案：A) 云端推理（原始方案）；B) 边缘提取特征+云端分类；C) 全边缘推理。计算发现：方案B需每2秒上传一次特征向量（约50字节），LoRa平均电流仍达12mA，续航约16小时；方案C采用一个3层全连接网络（输入8个特征，隐藏层16节点，输出3类），模型大小仅1.2KB，推理耗时0.8ms，平均电流仅0.5mA（MCU睡眠+定时唤醒采样）。最终选择方案C。
• 实际操作步骤：① 使用Python脚本离线训练模型，准确率98.2%；② 将模型转换为ONNX格式，再通过ONNX Runtime的MCU后端（如ONNX Runtime Micro）生成C数组；③ 在nRF52840上部署，使用RTC定时唤醒采样，每2秒执行一次推理；④ 优化功耗：采样时开启加速度计（电流180μA，持续20ms），推理时CPU全速运行（4mA，持续1ms），其余时间进入System OFF模式（0.7μA）。
• 结果对比：方案C实测平均电流0.8mA（含LED闪烁和RTC），理论续航200mAh/0.8mA ≈ 250小时（约10天），但实际通过优化采样策略（仅在运动强度超阈值时触发完整推理），平均电流降至0.3mA，续航达27天，接近目标。误报率从云端方案的3次/天降至0.5次/天（因为本地推理避免了网络延迟导致的上下文丢失）。
• 风险与代价：边缘推理的代价是模型无法利用云端海量数据进行实时更新。本案例中，若工厂引入新的作业动作（如攀爬），需要重新采集数据并手动OTA更新模型。此外，LoRa模块虽然平时关闭，但报警时仍需消耗80mA电流持续1秒发送，需确保电池在低电量时仍能支持该峰值。
• 复盘经验：① 特征工程比模型结构更重要——简单的统计特征配合小网络，效果优于直接输入原始波形的大网络；② 功耗优化必须从系统层面考虑，而非仅优化推理本身；③ 端云协同的正确模式是：边缘负责“检测”，云端负责“理解”（如跌倒后的姿态分析）。

智能家居场景补充：在智能家居中，TinyML的典型应用包括：本地语音命令识别（如“关灯”）、空调红外码学习、老人活动模式监测、漏水检测（通过振动传感器分析管道声音）。这些场景的共同约束是：设备通常使用纽扣电池或能量采集（太阳能、温差），且必须保证在Wi-Fi断网时仍能执行核心功能。例如，一款智能门锁采用TinyML进行人脸识别（仅提取特征向量，不上传原始图像），在本地完成比对，功耗控制在待机5μA、识别时50mA（持续200ms），4节AA电池可续航1年。

2.4 常见误区与总结复盘

核心原理：TinyML项目失败往往不是因为模型精度不够，而是因为工程约束考虑不周。以下是本领域最常见的五个误区，以及对应的规避策略。