3. TinyML推理基础：模型部署流程、内存与算力约束、常见音频模型
TinyML推理与云端推理最大的差异在于资源边界极其清晰：Flash可能只有几百KB，RAM可能只有几十KB，CPU主频可能只有几十MHz，且没有散热风扇。音频推理任务（如关键词唤醒KWS、异常声音检测）通常需要处理连续的帧流，这对模型部署提出了比静态图像分类更严苛的时序与内存要求。本章聚焦模型从训练到端侧部署的完整流程，剖析内存与算力的硬约束，并拆解两类最常见的音频模型结构，为后续滑窗推理与告警控制打下工程基础。
3.1 模型部署流程：从训练权重到端侧可执行代码
TinyML模型部署不是简单的“把模型文件拷贝到设备上”，而是一条需要反复迭代的工程链路。以TensorFlow Lite for Microcontrollers（TFLM）为例，标准流程包含五个关键环节：训练与验证、模型转换与量化、C++工程集成、端侧验证、迭代调优。每个环节都有特定的工具链与验收标准。
3.1.1 训练与验证阶段
训练阶段在PC或云端完成，使用PyTorch、TensorFlow或Keras等框架。对于音频模型，训练数据通常为16kHz单声道WAV文件，经过预加重、分帧（帧长30ms，帧移20ms）、加窗后提取MFCC特征。训练时需特别注意：验证集必须包含真实环境噪声，因为实验室干净音频与现场混响、背景噪声差异极大。训练完成后，模型以浮点权重（FP32）保存，此时模型大小可能为数百KB到数MB，远超出MCU的Flash容量。
3.1.2 模型转换与量化
转换阶段的核心任务是将浮点模型压缩为适合MCU的格式。主要操作包括：
- 权重剪枝：移除接近零的权重连接，减少非零参数数量。
- 量化：将FP32权重映射为INT8或INT16。INT8量化可将模型体积缩小4倍，且推理速度提升2~4倍。量化方式分为训练后量化（PTQ）和量化感知训练（QAT），后者精度损失更小。
- 格式转换：将模型导出为FlatBuffer格式的.tflite文件，该格式无需解析即可直接映射到内存。
转换后需用验证集重新评估精度。经验法则：INT8量化后准确率下降不应超过2%，若超过则需改用QAT或混合量化（敏感层保留FP16）。
3.1.3 C++工程集成与端侧验证
TFLM提供了一套纯C++的推理引擎，不依赖操作系统，可直接运行在裸机或RTOS上。集成步骤包括：
- 将.tflite模型转换为C数组（使用
xxd -i model.tflite > model_data.cc）。 - 在工程中声明
tflite::MicroInterpreter，并分配Tensor Arena（内存池）。 - 实现音频采集回调，将ADC采样数据填入输入张量。
- 调用
interpreter->Invoke()执行推理，从输出张量读取结果。
端侧验证需关注三个指标：峰值RAM占用（通过打印arena_used_bytes）、单次推理耗时（使用DWT循环计数器或clock()）、连续运行稳定性（至少运行24小时无内存泄漏）。
3.2 内存与算力约束：TinyML的“紧箍咒”
理解内存与算力约束，是设计音频推理系统的前提。MCU的资源限制不仅影响模型选择，还直接决定滑窗推理的帧缓冲策略和告警控制逻辑的实现方式。
3.2.1 内存约束的四个维度
| 内存类型 | 典型容量 | 主要用途 | 音频推理中的占比 |
|---|---|---|---|
| Flash（代码+只读数据） | 256KB ~ 1MB | 模型权重、推理引擎代码、常量表 | 模型权重占60%~80% |
| RAM（静态区） | 32KB ~ 256KB | 全局变量、Tensor Arena、音频帧缓冲 | Tensor Arena占40%~60% |
| RAM（堆/栈） | 数KB | 函数调用、临时变量 | 栈溢出是常见崩溃原因 |
| DMA缓冲 | 1KB ~ 8KB | ADC采样数据搬运 | 双缓冲需2×缓冲大小 |
音频推理的特殊性在于：输入特征（如MFCC）需要连续帧拼接。例如，一个40×10的MFCC特征图，若每帧20ms，则需要200ms的音频数据。若MCU的RAM仅有32KB，则必须采用环形缓冲区覆盖旧数据，而非一次性加载全部音频。
3.2.2 算力约束与实时性预算
算力约束直接决定推理延迟。以Cortex-M4F（80MHz）为例，执行一次10万次乘加运算（MACs）的INT8卷积约需5~10ms。音频滑窗推理的实时性要求为：推理时间必须小于帧移时间。若帧移为20ms，则推理预算为20ms；若帧移为50ms，则预算为50ms。超出预算将导致音频数据堆积，产生“追赶效应”，最终丢失事件。
算力优化手段包括：
- 算子融合：将Conv+BN+ReLU融合为单次循环，减少内存读写。
- 深度可分离卷积：将标准卷积分解为深度卷积+逐点卷积，计算量降低8~9倍。
- 查表激活函数：用256字节的LUT替代exp/tanh计算。
3.3 常见音频模型：KWS与异常检测
音频TinyML应用主要集中在两类任务：关键词唤醒（KWS）和异常声音检测。两者在模型结构、输入特征和输出解释上差异显著。
3.3.1 KWS模型：DS-CNN与CRNN
KWS的目标是从连续音频流中识别预设关键词（如“Hey Siri”）。最经典的TinyML模型是DS-CNN（Depthwise Separable CNN），其结构为：
输入层: MFCC 40×10 (40维特征, 10帧)
卷积层1: 3×3 深度卷积, 64通道
卷积层2: 1×1 逐点卷积, 64通道
卷积层3: 3×3 深度卷积, 128通道
卷积层4: 1×1 逐点卷积, 128通道
全局平均池化
全连接层: 128 → 12 (关键词数+静音+未知)
Softmax输出DS-CNN的参数量约54K（INT8后约54KB），在Cortex-M4上推理延迟约30ms。另一种结构是CRNN，用GRU层替代部分卷积，擅长捕捉时序依赖，但GRU的循环计算在MCU上效率较低，通常只在RAM大于64KB的设备上使用。
3.3.2 异常检测模型：自编码器与1D-CNN
异常检测的目标是识别“非正常”声音（如管道泄漏、电机异响）。由于异常样本难以收集，通常采用无监督学习：只用正常声音训练模型，推理时计算重建误差，误差超过阈值则判定为异常。
最常用的结构是自编码器（Autoencoder）：
编码器: 输入频谱图 64×16 → Conv(32) → Conv(16) → 潜变量(8)
解码器: 潜变量(8) → Deconv(16) → Deconv(32) → 重建 64×16
损失函数: MSE(输入, 重建输出)推理时，计算输入与重建输出的MSE。正常声音的MSE较低（如<0.05），异常声音的MSE显著升高（如>0.2）。另一种轻量方案是1D-CNN分类器，将声音分为“正常”和“异常”两类，但需要标注数据，且对未见过的异常类型泛化能力差。
3.3.3 模型选择对比
| 对比维度 | DS-CNN (KWS) | CRNN (KWS) | Autoencoder (异常检测) |
|---|---|---|---|
| 输入特征 | MFCC 40×10 | MFCC 40×20 | Log-Mel 64×16 |
| 参数量 | 54K | 120K | 80K |
| INT8模型大小 | 54KB | 120KB | 80KB |
| 推理延迟 (80MHz) | ~30ms | ~80ms | ~45ms |
| 峰值RAM | ~15KB | ~28KB | ~20KB |
| 适用场景 | 唤醒词、命令词 | 连续语音命令 | 设备异响、环境异常 |
3.4 案例拆解：工业泵异常检测模型的部署优化
某工厂需要在振动传感器节点（Cortex-M4F, 80MHz, 128KB Flash, 32KB RAM）上部署异常检测模型，用于监测水泵轴承磨损。初始方案采用Autoencoder模型，输入为64×16的Log-Mel频谱图，模型大小120KB，推理延迟60ms，峰值RAM 25KB。实测发现：Flash超限（120KB > 128KB-代码占用30KB），且推理延迟超过帧移40ms的预算。
分析过程：首先检查Flash占用，发现模型权重占120KB，而代码+运行时环境占30KB，总占用150KB，超出128KB。其次，推理延迟60ms中，解码器部分占40ms，因为转置卷积在MCU上效率较低。最后，RAM 25KB中，输入频谱图缓冲占16KB（64×16×2字节），Tensor Arena占9KB。
优化措施：
- 模型压缩：将潜变量从8维降至4维，解码器通道数减半，模型大小降至65KB。
- 输入降维：将频谱图从64×16改为32×16（降低频率分辨率），输入缓冲降至8KB。
- 算子替换：将转置卷积替换为最近邻上采样+标准卷积，推理延迟降至35ms。
- 帧移调整：将帧移从40ms调整为50ms，留出15ms余量。
结果对比：优化后模型大小65KB，Flash总占用95KB；推理延迟35ms，满足50ms预算；峰值RAM 18KB。异常检测准确率从92.3%降至90.1%（下降2.2%），但仍在可接受范围。部署后连续运行72小时，未出现内存泄漏或看门狗复位。
复盘经验：（1）Flash和RAM要同时预算，不能只看模型大小；（2）转置卷积是MCU上的性能陷阱，应优先用上采样+卷积替代；（3）输入特征降维是性价比最高的优化手段，频率分辨率从64降至32，计算量减少50%，精度损失仅2%。