2、TinyML基础：微控制器与边缘设备分类、资源约束（内存、算力、功耗）、典型应用场景
TinyML（微型机器学习）是边缘计算与嵌入式系统交叉领域中最具工程落地价值的方向之一。它并非简单地将深度学习模型“压缩”后塞进单片机，而是要求在微控制器（MCU）级别的硬件上，以极低的功耗、有限的内存和算力，完成实时或近实时的推理任务。理解TinyML的硬件基础，是后续进行TensorRT（或类似工具）硬件加速调参的前提——因为调参的本质，是在给定的资源约束下寻找性能与精度的最优平衡点。本章将系统梳理微控制器与边缘设备的分类、资源约束的量化指标，以及典型应用场景，为后续章节的模型优化与部署打下坚实的工程认知基础。
2.1 微控制器与边缘设备的分类体系
在TinyML工程实践中，硬件选型直接决定了模型压缩策略、推理框架选择以及调参方向。根据计算能力、内存容量和操作系统支持，边缘设备通常分为四个层级。理解这一分类，是进行TensorRT调参（尤其是针对不同硬件后端）的第一步。
| 类别 | 代表硬件 | 操作系统 | 内存容量 | 算力范围 | 典型推理框架 |
|---|---|---|---|---|---|
| Class 1: MCU | STM32F4, ESP32, RP2040 | 裸机/RTOS | 16KB~512KB SRAM | 10~100 MMACs/s | TensorFlow Lite Micro, CMSIS-NN |
| Class 2: MPU | Raspberry Pi, i.MX8M | Linux | 512MB~4GB DDR | 1~10 GOPS | TensorRT, ONNX Runtime |
| Class 3: NPU/加速器 | Edge TPU, Movidius, Kendryte K210 | RTOS/Linux | 8MB~64MB | 1~4 TOPS | 专用SDK + 量化工具 |
| Class 4: SoC异构 | Jetson Nano, RK3588 | Linux | 2GB~8GB | 10~100 GOPS | TensorRT, RKNN |
从调参视角看，Class 1 MCU 是TinyML最典型的战场。其SRAM通常只有几十到几百KB，Flash存储也极为有限，因此模型必须经过INT8量化甚至二值化处理。而Class 4 SoC异构平台虽然算力更强，但功耗和成本也随之上升，更适合需要复杂模型（如目标检测）的场景。在后续章节中，我们将重点围绕Class 1和Class 4展开TensorRT的调参策略，因为这两类设备在工业界部署量最大，且调参收益最明显。
2.2 资源约束的量化分析与工程影响
TinyML调参的核心矛盾在于：模型精度与资源消耗之间的权衡。我们需要从内存、算力、功耗三个维度建立量化认知，才能理解为什么TensorRT的某些优化策略（如层融合、内存复用）在边缘设备上至关重要。
2.2.1 内存约束：SRAM与Flash的分配策略
MCU的内存分为SRAM（运行时数据）和Flash（代码与权重存储）。一次推理的内存占用 = 权重大小 + 激活值大小 + 临时缓冲区。以STM32F4（192KB SRAM）为例，运行一个MobileNetV1（INT8量化后约4.2MB）是不可能的，因为权重已超出Flash容量。实际部署时，通常选择参数量小于1MB的模型，并采用内存复用技术——即多个层共享同一块激活缓冲区，以降低峰值内存。
// 内存估算示例（伪代码）
model_size = weight_bytes + activation_bytes
// 假设输入 32x32x3, 第一层卷积输出 32x32x16
activation_bytes = 32 * 32 * 16 * 1 (INT8) = 16KB
// 若模型有10层，峰值激活可能达到 50~100KB
// 因此，SRAM 192KB 的设备只能运行轻量级模型2.2.2 算力约束：MACs与硬件加速
算力通常以MACs（乘加运算）或GOPS（每秒十亿次操作）衡量。MCU的CPU主频一般在80~240MHz，且没有浮点单元（FPU）或仅有单精度FPU。因此，浮点模型在MCU上运行极慢，必须转换为定点运算。TensorRT在边缘设备上的核心优化之一，就是将浮点权重转换为INT8或INT16，利用硬件SIMD指令（如ARM的DSP扩展）加速。
2.2.3 功耗约束：能量效率的工程权衡
TinyML设备通常由电池供电，功耗预算在mW级别。功耗 = 动态功耗（与频率和电压相关）+ 静态功耗（漏电流）。在调参时，我们关注的是每次推理的能量消耗（Joules/Inference）。降低功耗的方法包括：降低CPU频率（但会增加推理时间）、使用硬件加速器（NPU在相同功耗下算力更高）、以及减少模型计算量（直接降低动态功耗）。
2.3 典型应用场景与部署案例拆解
为了将上述理论落地，我们以一个工业电机振动监测的TinyML项目为例，完整展示从硬件选型到资源约束分析的工程闭环。
案例背景与约束
某工厂需要在电机轴承上部署无线振动传感器，要求：电池供电（CR2032纽扣电池，容量约220mAh），设备寿命≥1年，每10分钟采集一次振动数据并推理（正常/异常）。硬件选型为Nordic nRF52840（Cortex-M4F，64MHz，256KB RAM，1MB Flash）。
初始现象与目标
初始方案采用3轴加速度计（采样率1kHz，采样1秒），直接传输原始数据到云端分析。但实测功耗高达15mA（无线传输为主），电池寿命仅约15天，远不达标。目标是将平均功耗降至0.1mA以下。
关键输入数据与指标
- 模型：1D-CNN，参数量 28KB（INT8量化后），单次推理需 45ms（CPU@64MHz）
- 激活值峰值：12KB
- 推理功耗：5mA @ 3V（CPU全速运行）
- 无线传输（BLE）功耗：15mA（每次传输0.1秒）
分析判断过程
原始方案功耗过高的根源在于无线传输。每次传输1秒数据（约12KB）需消耗15mA×0.1s = 1.5mAs。而本地推理仅需5mA×0.045s = 0.225mAs。因此，将推理迁移到本地，仅传输结果（1字节），可大幅降低功耗。
实际操作步骤
- 在PC上训练1D-CNN模型，准确率96.2%。
- 使用TensorFlow Lite Micro进行INT8量化，模型从112KB压缩至28KB。
- 部署到nRF52840，利用CMSIS-NN的DSP指令加速卷积运算。
- 优化推理流程：采用双缓冲机制，在采集下一段数据的同时推理当前数据。
- 调整CPU频率：推理时提升至64MHz，完成后降频至16MHz。
结果对比与复盘
| 方案 | 单次循环功耗 | 电池寿命 | 延迟 |
|---|---|---|---|
| 原始（云端推理） | 15mA×0.1s + 0.05mA×600s ≈ 31.5mAs | 约15天 | 2秒（含传输） |
| 优化后（本地推理） | 5mA×0.045s + 0.01mA×600s ≈ 6.225mAs | 约98天 | 45ms |
优化后功耗降低80%，但电池寿命仍不足1年。进一步分析发现，待机功耗（0.01mA）占比过高。通过启用nRF52840的System OFF模式（待机电流0.3uA），并将采样周期从10分钟延长至30分钟（根据轴承故障的时域特征，30分钟间隔仍可捕获早期故障），最终平均功耗降至0.08mA，电池寿命达到约1.2年。
2.4 常见误区与调参思维总结
在TinyML项目实践中，工程师常陷入以下误区，导致调参方向错误或部署失败。
- 误区一：盲目追求模型精度。在边缘设备上，精度提升1%可能带来30%的算力开销。正确做法是设定精度下限（如95%），然后最小化资源消耗。
- 误区二：忽略内存峰值。只关注模型大小，而忽略激活值内存。某些模型（如U-Net）的激活值远大于权重，导致SRAM溢出。
- 误区三：将PC端调参经验直接迁移。PC上的TensorRT优化（如FP16）在MCU上不可用，必须使用INT8或更低精度。
- 误区四：忽视数据搬运成本。在MCU上，从Flash读取权重的时间可能超过计算时间。使用常量折叠和权重预取可缓解此问题。