2、TinyML与边缘AI基础：TinyML定义、典型应用、与传统深度学习的区别
在进入Person Detection示例工程改造之前，我们必须先厘清TinyML在整个人工智能技术版图中的位置。TinyML并非简单的“小模型”或“轻量级深度学习”，而是一套面向极端受限资源环境的完整工程方法论。本章将从定义、应用场景、与传统深度学习的本质差异三个维度展开，为后续在MCU上部署人员检测模型奠定认知基础。
上图展示了传统深度学习、TinyML与边缘AI三者之间的定位关系。传统深度学习依赖云端GPU集群，功耗高达数百瓦；边缘AI通常运行在网关或边缘服务器上，功耗在数瓦到数十瓦之间；而TinyML则将推理能力压缩到微控制器（MCU）级别，功耗仅为毫瓦甚至微瓦级。这三者并非互斥关系，而是构成了一条从云端到终端的算力光谱，TinyML位于光谱的最末端，也是最受限的一端。
2.1 TinyML的核心定义与边界
核心原理：TinyML是机器学习与嵌入式物联网系统的交叉领域，其核心目标是在功耗受限、内存受限、计算能力受限的微控制器上部署和运行机器学习模型。根据TinyML基金会（TinyML Foundation）的官方定义，TinyML涉及“在极低功耗设备上执行推理的硬件、算法和软件技术”。这里的“极低功耗”通常指毫瓦级甚至微瓦级，设备往往依靠纽扣电池或能量采集供电，需要持续运行数月甚至数年。
从技术栈角度看，TinyML包含三个关键层次：
- 模型层：采用模型压缩技术（量化、剪枝、知识蒸馏）将深度学习模型压缩到几十KB到几百KB。例如，MobileNetV1经过INT8量化后，模型大小可以从4.2MB压缩到约1.1MB，而针对MCU的极端压缩版本可以进一步缩小到300KB以内。
- 运行时层：使用专门为MCU设计的推理框架，如TensorFlow Lite for Microcontrollers（TFLM）、CMSIS-NN、Glow等。这些框架针对ARM Cortex-M系列处理器的SIMD指令和硬件加速器进行了深度优化。
- 硬件层：典型的TinyML硬件平台包括ARM Cortex-M0/M4/M7系列MCU、ESP32、RP2040，以及带有硬件加速器的平台如MAX78000、Sony Spresense等。这些平台通常只有几十KB到几MB的SRAM和Flash。
关键判断标准：一个系统是否属于TinyML，可以从三个维度判断：① 推理功耗是否低于100mW；② 模型大小是否小于2MB；③ 是否在MCU或同等算力的处理器上运行。如果三个条件都满足，则可以认定为TinyML系统。例如，在STM32F746上运行一个100KB的人脸检测模型，推理功耗约15mW，完全符合TinyML标准。
需要特别强调的是，TinyML并不等同于“小模型”。虽然TinyML模型通常较小，但核心区别在于部署环境的极端约束。一个在树莓派上运行的MobileNetV2模型（约14MB）虽然模型不大，但由于树莓派功耗在2-5W，且运行Linux操作系统，因此不属于TinyML范畴。TinyML的本质是在资源受限的裸机或RTOS环境下，通过精细的工程优化实现AI推理。
2.2 TinyML的典型应用场景
TinyML的应用场景集中在需要持续感知、实时响应、隐私保护的物联网设备中。以下四个场景最具代表性：
| 应用领域 | 典型用例 | 关键约束 | 代表硬件 |
|---|---|---|---|
| 智能家居 | 语音唤醒词检测（“Hey Siri”）、人体存在检测 | 待机功耗<1mW，响应延迟<100ms | ESP32-S3、Cortex-M4 |
| 工业预测性维护 | 电机振动异常分类、轴承故障诊断 | 长时间连续运行，误报率<1% | STM32H7、MAX78000 |
| 可穿戴健康 | 心电异常检测、跌倒检测、睡眠阶段分类 | 电池续航>7天，模型<200KB | Apollo4、nRF5340 |
| 农业与环境 | 害虫识别、土壤湿度预测、空气质量分类 | 太阳能供电，极端温度范围 | RP2040、Cortex-M0+ |
以人体存在检测为例，这是Person Detection示例工程的核心场景。在智能楼宇中，传统方案使用PIR（被动红外）传感器，但PIR无法区分“人”和“宠物”或“热源干扰”。TinyML方案通过MCU上的图像分类模型，可以在不将图像上传到云端的情况下，实时判断是否有人存在。这不仅保护了隐私，还避免了网络延迟和带宽成本。
另一个值得关注的场景是关键词唤醒。在TWS耳机中，TinyML模型持续监听麦克风输入，当检测到特定唤醒词时才启动主处理器。这种“Always-on”工作模式要求模型推理功耗低于1mW，同时保持95%以上的唤醒准确率。目前，Arm的Ethos-U55微神经网络加速器已经能够将此类模型的功耗降低到0.5mW以下。
2.3 TinyML与传统深度学习的核心区别
理解TinyML与传统深度学习的差异，是进行工程改造的前提。两者的区别不仅体现在模型大小上，更体现在整个开发流程、部署方式和运行约束上。
2.3.1 开发流程差异
传统深度学习开发流程通常是：数据收集 → 模型设计 → 训练调优 → 部署到服务器/云端。开发者主要关注模型精度（如Top-1准确率、mAP），对推理延迟和资源占用相对宽松。而TinyML开发流程必须从硬件约束出发：
- 硬件规格分析：首先明确MCU的Flash容量、SRAM大小、CPU频率、是否有硬件加速器。例如，STM32F746拥有1MB Flash和320KB SRAM，这意味着模型大小不能超过800KB（预留系统代码空间），激活缓冲区不能超过200KB。
- 模型选型与压缩：根据硬件约束选择模型架构。对于人员检测任务，通常选择MobileNetV1或EfficientNet-Lite，并配合INT8量化。量化后模型精度损失通常控制在1-3%以内。
- 端侧验证：在真实硬件上进行推理测试，测量实际延迟、功耗和内存峰值。这一步在传统深度学习中往往被忽略，但在TinyML中至关重要。
2.3.2 技术指标对比
| 对比维度 | 传统深度学习 | TinyML |
|---|---|---|
| 算力需求 | TFLOPS级别（GPU/TPU） | GOPS级别（MCU） |
| 内存占用 | GB级别（模型+激活） | KB级别（模型+激活） |
| 数值精度 | FP32/FP16/BF16 | INT8/INT4/FP16（部分） |
| 推理功耗 | 200-500W（GPU） | 1-50mW（MCU） |
| 操作系统 | Linux/Windows + CUDA | 裸机/FreeRTOS/Zephyr |
| 模型更新 | 云端热更新 | OTA固件升级（需谨慎） |
| 调试手段 | TensorBoard、GPU Profiler | JTAG/SWD、串口日志、功耗分析仪 |
2.3.3 工程思维转变
从传统深度学习转向TinyML，最大的挑战不是技术本身，而是工程思维的转变。传统深度学习追求“更高精度”，而TinyML追求“在约束下的最优解”。例如，一个人员检测模型在GPU上可以达到98%的mAP，但经过INT8量化并压缩到200KB后，mAP可能下降到92%。在TinyML项目中，92%的mAP如果满足应用需求，就是可接受的方案。
常见误区：很多开发者试图将云端模型直接部署到MCU上，结果发现Flash和SRAM严重不足。例如，一个ResNet-50模型（约25MB）即使经过INT8量化也有6.3MB，远超STM32F746的1MB Flash。正确的做法是从硬件约束出发，反向选择合适的模型架构，而不是先选模型再考虑硬件。
2.4 案例拆解：从云端到MCU的人员检测模型迁移
为了更直观地理解TinyML与传统深度学习的差异，我们拆解一个实际案例：将云端人员检测模型迁移到MCU上。
背景与约束：某智能门禁项目最初使用NVIDIA Jetson Nano（功耗5W）运行YOLOv4-tiny模型，实现人员检测。项目需要将功能迁移到电池供电的无线门铃上，要求整机待机功耗低于2mW，检测功耗低于50mW，且模型必须在1秒内完成单帧推理。
初始现象与目标：YOLOv4-tiny模型大小为22MB，FP32精度，在Jetson Nano上推理延迟约30ms。直接迁移到MCU（以STM32H743为例，2MB Flash、1MB SRAM）显然不可行。目标是将模型压缩到300KB以内，推理延迟低于500ms。
关键输入数据与参数：
- 原始模型：YOLOv4-tiny，22MB，FP32，COCO数据集训练
- 目标硬件：STM32H743，Cortex-M7 @480MHz，2MB Flash，1MB SRAM
- 量化工具：TensorFlow Lite Converter（INT8量化）
- 推理框架：TensorFlow Lite for Microcontrollers
分析判断过程：首先，YOLOv4-tiny的22MB模型大小远超2MB Flash限制，必须更换模型架构。经过评估，选择MobileNetV1-SSD（目标检测）作为替代，其FP32模型大小为6.8MB。经过INT8量化后，模型压缩到680KB，仍然超过300KB的目标。进一步采用通道剪枝（移除贡献度低的卷积核），将模型压缩到280KB，精度从原始mAP 0.72下降到0.65。
实际操作步骤：
- 使用TensorFlow Model Optimization Toolkit进行权重剪枝，剪枝率50%，模型大小降至3.4MB。
- 进行INT8量化感知训练（Quantization-Aware Training），模拟量化误差，微调模型权重。
- 转换为TFLite格式，使用TFLM部署到STM32H743。
- 使用CMSIS-NN优化卷积运算，利用Cortex-M7的SIMD指令。
- 实测推理延迟：单帧（96x96输入）推理耗时380ms，峰值内存占用420KB。
结果对比：
| 指标 | Jetson Nano方案 | STM32H743方案 | 变化 |
|---|---|---|---|
| 模型大小 | 22MB | 280KB | ↓ 98.7% |
| 推理延迟 | 30ms | 380ms | ↑ 12.7倍 |
| 检测功耗 | 5W | 45mW | ↓ 99.1% |
| mAP（COCO） | 0.72 | 0.65 | ↓ 9.7% |
风险与代价：精度下降9.7%在门禁场景中可接受（误检率从2%上升到3.5%），但推理延迟从30ms增加到380ms，意味着门铃检测到人后需要等待近0.4秒才能触发报警。对于门禁场景，这个延迟在可接受范围内，但如果用于安全监控，则需要优化输入分辨率或使用硬件加速器。
复盘经验：这个案例揭示了TinyML工程的核心方法论：先定约束，再选模型，最后调优。如果一开始就坚持使用YOLO系列模型，项目将无法推进。通过模型替换、剪枝、量化三步组合，最终在功耗降低99%的同时，保持了可接受的精度和延迟。
2.5 常见误区与总结复盘
在TinyML学习和实践中，以下误区最为常见：
误区一：认为TinyML只是“模型压缩”。模型压缩是TinyML的重要环节，但远非全部。TinyML还涉及推理框架的适配、内存管理、功耗优化、外设驱动等嵌入式系统工程问题。一个压缩到100KB的模型，如果推理框架无法在MCU上运行，依然无法部署。
误区二：忽视数据采集的嵌入式约束。传统深度学习的数据集通常是静态的、预先标注好的。而TinyML设备的数据来自真实传感器，存在噪声、光照变化、视角差异等问题。例如，人员检测模型在训练时使用标准RGB图像，但MCU上的摄像头可能输出Bayer格式或低分辨率灰度图，这需要额外的预处理。
误区三：盲目追求高精度。在TinyML中，精度与资源占用是一对矛盾。一个提高2%精度的模型改动，可能导致Flash占用增加50%或推理延迟翻倍。正确的做法是设定一个“够用”的精度阈值，然后在此约束下优化资源占用。
总结复盘：本章的核心知识点可以归纳为以下三点：
- TinyML的本质是“约束下的AI”——功耗、内存、算力三重约束决定了其技术路线与传统深度学习截然不同。
- 应用场景驱动技术选型——人员检测、语音唤醒、振动分析等场景各有侧重，需要根据具体需求选择模型架构和优化策略。
- 工程思维比算法能力更重要——在TinyML项目中，硬件规格分析、量化误差评估、内存峰值计算等工程能力往往决定了项目的成败。