📚 课程目录第3章 TinyML基础

3、TinyML基础：TinyML定义、典型工作流、在ESP32上运行TinyML的挑战（内存、算力、功耗）

TinyML是机器学习与嵌入式系统交叉领域中最具落地价值的技术方向之一。它并非简单地将模型“压缩”后塞进单片机，而是围绕资源受限设备重新设计模型架构、推理引擎与部署流程。在ESP32这类集成Wi-Fi/蓝牙的MCU上运行TinyML，意味着我们必须在几十KB到几MB级别的SRAM/PSRAM中完成特征提取、模型推理与结果后处理，同时兼顾实时性与电池寿命。理解TinyML的本质工作流，并清醒认识ESP32的内存、算力与功耗边界，是后续优化PSRAM分配策略的前提。

3.1 TinyML定义与核心原理

TinyML（Tiny Machine Learning）是指在极低功耗、极低算力、极小内存的嵌入式设备上部署和执行机器学习推理任务的技术体系。其核心思想不是“训练”，而是“推理”——模型在云端或PC上完成训练后，经过量化、剪枝、算子融合等优化，转换为适合MCU执行的格式。与常规嵌入式AI不同，TinyML强调三个硬性指标：内存占用小于2MB（典型ESP32 SRAM为320KB）、功耗低于100mW（电池供电场景）、延迟低于100ms（实时控制场景）。

从系统架构看，TinyML推理链路包含四个关键环节：数据采集（传感器驱动与DMA传输）、信号预处理（滤波、归一化、特征提取）、模型推理（算子执行与张量计算）、结果决策（阈值判断或后处理）。每个环节都会消耗内存和CPU周期，而ESP32的PSRAM（外部SPI RAM）正是为了缓解SRAM不足而设计的扩展存储。

核心理解：TinyML的本质是“在资源约束下做计算-存储-功耗的三角权衡”。PSRAM提供了更大的存储空间，但访问速度远低于内部SRAM（PSRAM约20MB/s带宽，SRAM可达数百MB/s），因此分配策略必须基于数据访问频率和生命周期来决策。

3.2 典型工作流：从训练到部署的完整链路

一个标准的TinyML项目遵循“训练-转换-部署-调优”四阶段流程。理解每个阶段的输入输出，有助于定位PSRAM分配问题。

阶段	关键操作	输出产物	对ESP32的影响
① 模型训练	使用TensorFlow/PyTorch训练浮点模型	.h5 / .pb 文件	模型结构决定算子类型和参数量
② 模型转换	TFLite Converter + 量化（INT8/FP16）	.tflite 文件	量化后权重减少4倍，但需校准数据集
③ 嵌入式部署	使用TFLite-Micro或ESP-DL加载模型	C++数组 / Flash分区	模型权重可放Flash，激活张量需RAM
④ 运行时调优	监控内存峰值、推理延迟、功耗	性能报告	决定哪些张量放PSRAM，哪些放SRAM

在ESP32上，部署阶段最关键的决策是内存布局。模型权重通常存储在Flash（4MB~16MB），推理时按需加载到RAM。而激活张量（中间计算结果）必须在RAM中连续存在，其大小由输入尺寸、网络深度和算子类型决定。例如，一个输入为160x120x3的图像分类模型，第一层卷积后可能产生160x120x16的激活张量，占用约1.2MB——这已经超出ESP32的320KB SRAM，必须借助PSRAM。

// 典型TFLite-Micro初始化流程（ESP32）
static tflite::MicroErrorReporter micro_error_reporter;
tflite::ErrorReporter* error_reporter = &micro_error_reporter;

const tflite::Model* model = tflite::GetModel(g_model);
static tflite::MicroMutableOpResolver<10> resolver;
resolver.AddConv2D();
resolver.AddFullyConnected();

// 关键：TensorArena 分配策略
constexpr int kTensorArenaSize = 200 * 1024; // 200KB
uint8_t* tensor_arena = (uint8_t*)ps_malloc(kTensorArenaSize); // 从PSRAM分配

tflite::MicroInterpreter interpreter(model, resolver, tensor_arena, kTensorArenaSize);
interpreter.AllocateTensors();

注意：上述代码中ps_malloc()从PSRAM分配内存，但TFLite-Micro默认假设TensorArena在SRAM中。若PSRAM访问延迟过高，推理速度可能下降30%~50%。实际项目中应优先将小尺寸高频访问张量放在SRAM，大尺寸低频访问张量放在PSRAM。

3.3 在ESP32上运行TinyML的三大挑战

3.3.1 内存挑战：SRAM容量与PSRAM带宽的博弈

ESP32经典款（ESP32-D0WD）内置520KB SRAM，其中约320KB可供用户使用。对于TinyML推理，这个容量通常只够运行参数量小于100KB的模型（如关键字识别、简单异常检测）。当模型复杂度提升（如人体活动识别、视觉唤醒词），激活张量轻松突破1MB，此时必须使用PSRAM。但PSRAM存在两个致命弱点：访问延迟高（约10~20ns vs SRAM的4ns）和带宽受限（SPI接口理论带宽40MB/s，实际有效带宽约20MB/s）。

内存分配的核心判断方法是：统计每个张量的生命周期和访问频率。例如，卷积层的输入张量在每次推理中只被读取一次，但输出张量会被下一层多次读取。对于只读一次的数据（如输入图像），可以放在PSRAM；对于需要反复读写的中间特征图，应尽量放在SRAM。此外，DMA双缓冲技术可以将数据从PSRAM预取到SRAM，隐藏部分延迟。

经验法则：当模型推理延迟要求低于50ms时，激活张量必须全部放在SRAM；当延迟要求放宽到100ms以上时，可将前几层的大张量放到PSRAM。使用esp_get_free_heap_size()和heap_caps_get_free_size(MALLOC_CAP_SPIRAM)实时监控内存水位。

3.3.2 算力挑战：无FPU的定点运算优化

ESP32使用Tensilica Xtensa LX6处理器，主频240MHz，但没有硬件浮点单元（FPU）。这意味着浮点运算需要软件模拟，速度极慢。因此，TinyML模型在ESP32上必须进行INT8量化。量化后的卷积运算可以使用ESP32的SIMD指令（如esp_dsp库）加速，但需要手动管理量化参数（scale和zero_point）。

算力优化的另一个关键点是算子融合。例如，将Conv2D+ReLU+MaxPool融合为一个算子，减少内存访问次数。TFLite-Micro的MicroMutableOpResolver允许自定义算子注册，但ESP32上更推荐使用乐鑫官方的ESP-DL库，它针对ESP32的SIMD指令集深度优化了卷积和全连接层。

// ESP-DL 量化卷积示例（INT8）
dl::conv2d::Conv2D<int8_t> conv_layer;
conv_layer.set_input((int8_t*)input_data, {1, 160, 120, 3});
conv_layer.set_filter((int8_t*)weight_data, {16, 3, 3, 3});
conv_layer.set_bias((int32_t*)bias_data, {16});
conv_layer.set_activation(ReLU);
conv_layer.set_padding({1, 1, 1, 1});
conv_layer.set_stride({2, 2});
conv_layer.run();

算力挑战的量化指标：一个典型的1D卷积层（输入128点，16个滤波器，核大小3）在ESP32上执行INT8推理约需0.5ms；而同样的浮点运算需要8ms。因此，量化是ESP32上TinyML的必选项，而非可选项。

3.3.3 功耗挑战：推理频率与深度睡眠的平衡

ESP32在Active模式（Wi-Fi开启）下功耗高达240mA，即使关闭Wi-Fi，CPU全速运行也需50mA。对于电池供电的TinyML设备，必须采用事件驱动架构：平时处于Deep Sleep（功耗约10μA），当传感器检测到事件（如运动中断、声音超过阈值）时唤醒，执行一次推理，然后立即回到睡眠。

功耗优化的核心策略是降低推理频率。例如，一个振动监测设备不需要每毫秒都推理，而是每100ms采样一次，当信号能量超过阈值时才触发推理。此外，使用ESP32的ULP协处理器（Ultra-Low-Power Processor）可以在主CPU休眠时进行简单的传感器数据预处理，进一步降低功耗。

工作模式	电流消耗	适用场景	PSRAM状态
Active (Wi-Fi ON)	240mA	模型OTA升级、数据上报	可访问
Active (Wi-Fi OFF)	50mA	实时推理（<100ms延迟）	可访问
Modem Sleep	20mA	周期性采样+推理	可访问
Deep Sleep	10μA	事件唤醒	掉电（数据丢失）

风险提示：PSRAM在Deep Sleep模式下会掉电，所有存储在PSRAM中的中间数据都会丢失。因此，关键模型参数和校准数据必须放在Flash或SRAM中，PSRAM仅用于临时计算缓冲。若需在唤醒后快速恢复，可将模型权重映射到Flash的MMU（Memory Management Unit）区域，实现按需加载。

3.4 实战场景：基于ESP32的振动异常检测系统

我们设计一个工业设备振动监测系统，要求：使用ESP32-WROOM-32E，采集加速度计（ADXL345）数据，检测异常振动模式，通过Wi-Fi上报。系统约束：电池供电（18650锂电池），需连续工作7天，推理延迟<200ms。

初始方案与问题：工程师最初将整个TFLite模型（包含3层卷积+2层全连接，参数量约200KB）加载到SRAM中，TensorArena分配了150KB。结果发现：内存不足导致系统反复重启，且推理延迟高达350ms（因为浮点运算）。

分析过程：通过heap_caps_get_free_size()监控发现，SRAM剩余不足50KB，而激活张量峰值达到180KB。进一步分析模型结构，发现第一层卷积的输入是128x3的窗口数据，输出为128x16的特征图，占用约32KB；第二层卷积输出128x32，占用64KB；第三层输出64x64，占用128KB。这些激活张量生命周期短（仅在本层计算时存在），但峰值叠加导致内存溢出。

优化步骤：

量化模型：使用TensorFlow Lite Converter将模型从FP32转为INT8，权重从200KB降至50KB，激活张量峰值从180KB降至45KB。
分层内存分配：将第一层卷积的输入数据（来自DMA缓冲）放在PSRAM，因为只读取一次；将第二、三层的激活张量放在SRAM，因为需要多次读写。
算子融合：将Conv2D+ReLU+MaxPool融合为单一算子，减少中间张量的内存分配次数。
功耗管理：设置加速度计中断阈值，当振动幅度超过0.5g时唤醒ESP32，执行推理后立即进入Deep Sleep。

结果对比：优化后，SRAM占用从450KB降至120KB，PSRAM占用80KB（仅用于输入缓冲），推理延迟从350ms降至85ms，平均功耗从80mA降至15mA（事件驱动模式），电池续航从1.5天延长至9天。

复盘经验：PSRAM分配不是“越多越好”，而是“按需分配”。本案例中，将输入缓冲放在PSRAM是合理的，因为DMA写入和CPU读取是顺序访问，PSRAM的带宽瓶颈影响不大。但若将卷积层的输出张量放在PSRAM，则每次卷积计算都需要跨总线访问，延迟会急剧上升。因此，判断标准是：数据是否被频繁随机访问？如果是，则必须放SRAM；如果是顺序流式访问，可以放PSRAM。

3.5 常见误区与总结

误区一：所有内存都从PSRAM分配。这会导致推理速度大幅下降，因为PSRAM的随机访问延迟是SRAM的5倍以上。正确做法是使用heap_caps_malloc(size, MALLOC_CAP_SPIRAM)和heap_caps_malloc(size, MALLOC_CAP_8BIT)分别管理PSRAM和SRAM。

误区二：忽略Flash的MMU映射。ESP32的Flash可以通过MMU映射到数据总线，实现“按需加载”模型权重。这比将整个模型复制到PSRAM更高效，因为Flash的读取速度（约40MB/s）与PSRAM相当，且不占用RAM空间。

误区三：只关注峰值内存，忽略内存碎片。TFLite-Micro的TensorArena采用线性分配器，不会产生碎片，但若使用标准malloc分配PSRAM，频繁的分配释放会导致碎片。建议使用ps_malloc配合静态分配池。