边缘AI与TinyML基础：边缘计算、TinyML概念、典型应用场景与硬件限制
在进入Edge Impulse与TFLite Micro的具体操作之前，必须先厘清它们所依附的底层技术版图。边缘AI与TinyML并非简单的“在单片机上跑神经网络”，而是一套涉及算力分配、功耗约束、数据生命周期与部署链路的系统工程。本章将围绕四个核心模块展开：边缘计算的本质与分层架构、TinyML的定义与数学本质、典型应用场景的工程特征，以及硬件资源的硬性天花板。理解这些内容，将直接决定你在后续章节中如何选择模型架构、量化策略与部署目标。
上图展示了从云端到终端的分层架构与约束传导关系。值得注意的是，TinyML并非边缘AI的全部，而是边缘AI中最靠近物理世界的那一层。在工程实践中，我们通常将边缘AI划分为“近端边缘”（网关级）与“极边缘”（MCU级），而TinyML特指后者。这种分层决定了数据流的方向：终端设备负责低延迟的实时响应，网关负责聚合与复杂决策，云端负责模型迭代与全局优化。理解这一传导链，是后续使用Edge Impulse进行模型压缩与部署的前提。
核心原理：边缘计算的分层逻辑与TinyML的数学本质
边缘计算的核心思想是将计算推向数据源附近，以减少网络往返延迟、降低带宽消耗并增强数据隐私。在工业物联网、智能家居与可穿戴设备中，这一需求尤为迫切。TinyML作为边缘计算的极端形态，其定义包含三个关键维度：模型规模（通常在100KB以下）、运行时功耗（毫瓦级甚至微瓦级）、部署环境（无操作系统或RTOS的裸机环境）。从数学本质上看，TinyML模型执行的是受限的矩阵乘法与激活函数运算，其计算量通常以MAC（乘加运算）为单位衡量。例如，一个典型的1D卷积层，若输入通道为16、输出通道为32、卷积核大小为3，则单次推理的MACs约为16×32×3×采样点数。这种运算的瓶颈不在FLOPs，而在内存带宽——因为MCU的Flash与RAM访问速度远低于CPU内核。
从算法角度看，TinyML依赖的模型必须经过量化（通常为INT8或INT16）与剪枝。量化将浮点权重映射到定点整数域，以损失少量精度换取4倍以上的存储压缩和2-3倍的推理加速。以TFLite Micro为例，其核心解释器仅支持有限算子集，且所有张量必须预先分配静态内存。这意味着开发者无法依赖动态shape或运行时内存分配，必须在编译期确定所有缓冲区的尺寸。这一约束直接影响了模型架构设计——例如，全局池化层比全连接层更受青睐，因为后者需要巨大的权重矩阵。
判断方法：如何评估一个场景是否适合TinyML
并非所有边缘AI场景都适合TinyML。在项目立项阶段，工程师需要从以下四个维度进行可行性判断：
| 评估维度 | 适合TinyML的条件 | 不适合TinyML的信号 |
|---|---|---|
| 延迟要求 | 端到端响应需小于20ms，且无法承受网络抖动 | 允许100ms以上延迟，且网络稳定 |
| 数据带宽 | 传感器数据量大（如IMU 1kHz采样），上传成本高 | 事件型低频数据（如温度每分钟1次） |
| 功耗预算 | 电池供电，平均电流需小于1mA | 可插电或使用大容量电池 |
| 模型复杂度 | 输入特征维度低（<100），分类数少（<50） | 需要图像分类（ImageNet级别）或复杂时序预测 |
一个实用的判断流程是：首先计算原始数据量——若每秒产生超过10KB的传感器数据，且无法本地缓存，则TinyML的片上推理几乎是唯一选择；其次评估模型参数量——若模型压缩至INT8后仍超过2MB，则需考虑更换硬件平台或简化模型结构；最后检查硬件外设——确认MCU具备硬件乘法器（如ARM Cortex-M4F或M7），否则软件浮点模拟将导致推理时间呈数量级增长。
案例拆解：工业电机振动监测的TinyML部署
我们以一个真实的工业预测性维护场景为例。某工厂需要在电机轴承上部署无线振动传感器，用于检测异常磨损。初始方案是使用ESP32采集3轴加速度计数据（采样率4kHz，16位分辨率），通过Wi-Fi上传至云端进行FFT分析。实测发现：每秒钟产生24KB原始数据（3轴×4000Hz×2字节），Wi-Fi上传功耗高达180mA，且网络延迟导致报警响应时间超过3秒。更严重的是，工厂车间内有多台电机同时工作，Wi-Fi信道拥塞导致数据丢包率高达7%。
重新设计后，团队改用Nordic nRF52840（Cortex-M4F，64MHz，1MB Flash，256KB RAM），在片上完成以下处理链路：
- 时域特征提取：计算每50ms窗口的RMS、峰值因数、峭度，将24KB原始数据压缩为12个特征值（约96字节）。
- 频域特征：执行256点FFT，提取1x、2x、3x转频幅值，增加6个特征。
- 模型推理：使用一个两层全连接网络（输入18维，隐藏层16节点，输出3类），模型大小仅4.2KB（INT8量化后）。
- 决策与通信：仅在检测到异常时通过BLE发送报警帧（20字节），正常状态下每10分钟发送一次心跳。
部署后的实测数据：推理耗时2.3ms，平均功耗从180mA降至9.4mA（其中BLE广播占主导），电池寿命从3天延长至11个月。报警延迟从3秒降至8ms。关键风险在于：FFT计算需要2048字节的临时缓冲区，这占用了RAM的8%，因此必须使用static分配而非堆分配。此外，模型在-20℃至85℃的温度漂移测试中，峭度特征的方差变化导致误报率上升了1.2%，最终通过增加温度补偿系数解决。
复盘经验：该案例的核心收益并非“省电”，而是将决策权下沉到数据源头。云端只负责模型更新与长期趋势分析，而实时保护动作完全由终端完成。这避免了网络中断时的安全风险，也大幅降低了数据合规成本。
常见误区与总结复盘
在TinyML项目实践中，工程师常陷入以下误区：
误区二：忽略数据预处理成本。许多开发者只优化模型推理，却忽视了传感器读取、滤波、特征缩放的时间。在4kHz采样下，一个简单的IIR滤波器可能消耗比推理更多的CPU周期。
误区三：将PC上的浮点模型直接转换。TFLite Micro要求模型必须经过“代表性数据集”校准的量化，否则精度损失可能超过10%。Edge Impulse的自动量化工具虽然方便，但开发者仍需检查每一层的激活值范围。