2、TinyML基础：定义、特点、典型应用场景与传统深度学习的区别
TinyML（微型机器学习）是机器学习与嵌入式物联网系统交叉融合的新兴领域，其核心目标是在功耗受限、计算资源有限、存储空间极小的微控制器（MCU）或极低功耗处理器上，直接部署和运行机器学习模型。与云端AI依赖高性能GPU集群不同，TinyML强调在设备端本地完成数据采集、推理和决策，实现真正的边缘智能。本章将系统阐述TinyML的定义边界、核心特点、典型应用场景，并通过对比表格和案例拆解，帮助学员建立对TinyML技术全貌的清晰认知，为后续基于RKNN工具链的模型转换与部署打下坚实的理论基础。
上图从宏观视角勾勒了TinyML的技术定位：它处于传统云端深度学习与嵌入式系统之间的交叉地带，既继承了深度学习的特征提取能力，又必须满足嵌入式环境的严苛约束。接下来，我们将从定义、特点、应用场景和对比维度四个层面展开详细论述。
2.1 TinyML的定义与核心边界
TinyML并没有一个全球统一的严格定义，但业界普遍认可的描述是：TinyML是机器学习模型与嵌入式物联网设备深度结合的技术领域，它使得在功耗仅为毫瓦甚至微瓦级别的微控制器上，能够运行经过优化的机器学习推理任务。 这里的“Tiny”不仅指模型规模小，更指代硬件平台的资源极限——通常包括：
- 处理器：ARM Cortex-M系列、RISC-V内核等，主频通常在几十MHz到几百MHz之间，无操作系统或运行轻量级RTOS。
- 内存：Flash存储通常在256KB到2MB之间，SRAM通常在64KB到512KB之间，需要精打细算地分配模型权重和中间张量。
- 功耗：整板功耗预算通常在1mW到100mW之间，电池供电场景下需要运行数月甚至数年。
- 网络：多数场景无Wi-Fi或蜂窝网络连接，或仅在特定时刻短暂联网，推理过程完全离线。
需要特别强调的是，TinyML与“边缘计算”既有联系又有区别。边缘计算通常指在网络边缘侧的网关或服务器上部署AI，这些设备往往具备Linux操作系统、数GB内存和较强的CPU/GPU；而TinyML则更进一步，将推理下沉到最末端的传感器节点本身，实现“传感器即AI”。例如，一个智能门磁传感器内部直接运行人体检测模型，而不是将数据上传到家庭网关。
核心判断标准：判断一个项目是否属于TinyML范畴，可以看三个硬性指标——① 推理设备是否为MCU或等效低功耗处理器（非Linux系统）；② 模型权重是否小于2MB（通常小于500KB）；③ 平均功耗是否低于100mW。满足以上三条，即可视为典型的TinyML应用。
2.2 TinyML的五大核心特点
TinyML之所以能成为一个独立的技术方向，是因为它在工程实现上与传统AI部署有着截然不同的设计哲学。以下是其最显著的五个特点：
| 特点维度 | 具体表现 | 工程影响 |
|---|---|---|
| 超低功耗 | 推理功耗可低至1mW以下，待机功耗μW级 | 电池供电设备可连续工作数月，无需频繁更换电池 |
| 资源极度受限 | Flash < 1MB，SRAM < 256KB，无MMU | 模型必须经过量化、剪枝、蒸馏等压缩手段 |
| 本地实时推理 | 端到端延迟通常在10ms~100ms级别 | 满足工业控制、可穿戴设备等实时响应需求 |
| 数据隐私安全 | 原始数据不出设备，仅上传脱敏结果 | 符合GDPR等隐私法规，降低数据泄露风险 |
| 部署环境多样 | 需适配不同厂商MCU、不同编译器工具链 | 要求模型具备硬件无关性，依赖工具链优化 |
在上述特点中，“资源极度受限”是TinyML区别于其他AI形态的最根本约束。以图像分类任务为例，一个在GPU上运行的ResNet-50模型权重约25MB，而Cortex-M4级别的MCU通常只有512KB Flash，这意味着模型体积需要压缩50倍以上。这正是本课程后续章节引入RKNN工具链的核心原因——RKNN不仅支持量化压缩，还能针对瑞芯微系列芯片的NPU进行算子级优化，将模型体积和推理速度同时提升到可用的水平。
2.3 典型应用场景深度拆解
TinyML的应用场景正在快速扩展，但当前最成熟、商业落地最多的领域集中在以下三个方向。我们逐一分析其技术需求和工程挑战。
2.3.1 智能家居：本地语音与视觉感知
智能家居是TinyML最早实现规模化落地的领域。以智能音箱的“唤醒词检测”为例，设备需要持续监听环境声音，但不可能将音频流实时上传到云端——这既消耗带宽，又存在隐私风险。通过TinyML技术，在设备端部署一个参数量仅数十KB的音频分类模型，即可在本地识别“小爱同学”或“Hey Siri”等唤醒词。当唤醒词被触发后，才启动云端交互。
另一个典型场景是存在性检测。传统红外传感器只能检测移动物体，无法区分“人静止坐在沙发上”和“宠物走动”。通过在低功耗摄像头模组上部署TinyML人体检测模型，智能空调可以根据人的位置和状态自动调节风向，实现节能与舒适度的平衡。这类模型通常采用MobileNet或EfficientNet-Lite架构，经INT8量化后体积可压缩至200KB以内。
2.3.2 可穿戴设备：健康监测与运动识别
可穿戴设备（智能手表、手环、医疗贴片）对功耗和体积的要求极为苛刻。以心率监测为例，传统方案是使用光电传感器采集PPG信号，再通过信号处理算法提取心率。而基于TinyML的方案可以直接在MCU上运行一个一维卷积神经网络（1D-CNN），对PPG信号进行端到端的心律不齐分类，准确率比传统阈值法提升15%~20%。
运动识别（步态分析、跌倒检测）是另一个重要方向。在老年人护理场景中，跌倒检测需要在100ms内发出警报，且不能误报（如弯腰捡东西不能触发）。TinyML模型通过融合加速度计和陀螺仪数据，在MCU上实时运行LSTM或TCN模型，可以实现低于1%的误报率。这类模型通常经过剪枝后参数量在50K~200K之间，推理一次仅消耗0.5mJ能量。
2.3.3 工业预测性维护：振动分析与异常检测
在工业现场，电机、泵、传送带等旋转机械的故障预测是TinyML的高价值场景。传统方案是在PLC或工控机上运行FFT频谱分析，但设备成本高、部署不灵活。TinyML方案将振动传感器（加速度计）与MCU集成，直接在设备本地运行异常检测模型。模型通过分析振动信号的时域和频域特征，判断设备是否处于健康状态，并在故障早期发出预警。
一个典型的案例是某工厂在压缩机上部署了基于TinyML的振动分析节点。该节点使用STM32L4系列MCU（主频80MHz，SRAM 128KB），模型为经过量化的1D-CNN，输入为256点振动波形，输出为“正常/异常”二分类。部署后，系统成功在轴承磨损初期（振动幅度仅增加8%时）检测到异常，比传统阈值报警提前了11天，避免了非计划停机造成的约30万元损失。
场景选择建议：并非所有AI应用都适合TinyML。如果应用需要大规模语义理解（如大语言模型）、需要持续更新模型权重、或需要跨设备关联分析，则仍应依赖云端或边缘服务器。TinyML最适合的是单一任务、实时响应、数据隐私敏感、功耗受限的场景。
2.4 TinyML与传统深度学习的系统对比
为了更清晰地理解TinyML的定位，我们从多个维度将TinyML与传统深度学习（云端训练+云端推理）进行对比。需要说明的是，这里的“传统深度学习”指的是以GPU/TPU为硬件基础、以Python/PyTorch/TensorFlow为开发框架的典型AI系统。
| 对比维度 | 传统深度学习 | TinyML |
|---|---|---|
| 硬件平台 | NVIDIA GPU、Google TPU、高性能CPU集群 | Cortex-M系列MCU、RISC-V、低功耗NPU（如RK3566） |
| 操作系统 | Linux、Windows Server，支持虚拟化 | 裸机或RTOS（FreeRTOS、Zephyr、RT-Thread） |
| 内存容量 | 16GB~1TB+ | 64KB~2MB |
| 功耗预算 | 300W~2000W（单卡） | 1mW~100mW（整板） |
| 模型精度 | FP32/FP16，追求最高精度 | INT8/INT16量化，精度损失控制在1%~3% |
| 开发语言 | Python为主，C++/CUDA为辅 | C/C++为主，部分支持MicroPython |
| 部署方式 | Docker容器、云服务API | 固件烧录、OTA升级 |
| 网络依赖 | 必须联网，数据上传云端 | 完全离线，数据本地处理 |
| 更新频率 | 模型可随时在线更新 | 需通过固件升级，更新周期长 |
| 典型延迟 | 100ms~数秒（含网络传输） | 10ms~100ms（纯本地推理） |
从上表可以看出，TinyML并非传统深度学习的简单“缩小版”，而是在硬件约束、开发流程、部署方式上都有本质区别的技术体系。一个在云端训练好的PyTorch模型，不能直接烧录到MCU上运行，必须经过模型压缩（量化/剪枝）→ 格式转换（如ONNX→RKNN）→ 算子适配 → 固件集成等一系列流程。这正是本课程的核心内容——如何将训练好的图像分类模型，通过RKNN工具链高效部署到瑞芯微平台。
2.5 常见误区与工程复盘
在TinyML项目的实际开发中，初学者和团队常陷入以下几个误区，我们结合真实项目经验进行总结复盘。
误区一：认为“模型小=效果好”
很多团队为了满足内存限制，盲目将模型压缩到极小尺寸，导致准确率大幅下降。正确的做法是：先评估任务复杂度，选择合适的基线模型（如MobileNetV2、EfficientNet-Lite），再通过量化感知训练（QAT）来减少精度损失，而不是一味压缩通道数。
误区二：忽略“内存峰值”而非“模型大小”
模型权重文件大小只是Flash占用，而推理过程中的中间特征图（activation）会占用SRAM。例如，一个输入为224×224×3的图像分类模型，第一层卷积输出的特征图可能就达到112×112×32=400KB，远超MCU的SRAM容量。因此，在模型选型时必须同时评估权重内存和激活内存的峰值。
误区三：忽视“数据采集与标注”的工程成本
TinyML模型虽然小，但训练数据的质量要求并不低。在工业振动检测案例中，我们花费了项目总工时的60%用于采集不同工况下的振动数据并进行标注。如果数据分布不覆盖实际运行场景，模型在部署后会出现严重的误报/漏报。
案例复盘：某智能门锁项目需要在低功耗MCU上实现“人脸识别”功能。初始方案直接使用OpenCV的Haar级联检测器，但误检率高且无法区分照片与真人。团队改用TinyML方案后，在RK3566平台部署了MobileFaceNet模型（INT8量化后约1.2MB），识别准确率达到98.7%。但项目初期忽略了“活体检测”需求，导致用打印照片即可解锁。后续在模型中增加了近红外图像输入通道，通过双模态判断活体，才最终通过安全认证。这个案例说明，TinyML项目不仅要考虑模型性能，还要结合硬件传感器特性进行系统级设计。