📚 课程目录第2章嵌入式AI基础

嵌入式AI基础：边缘计算、MCU上的AI限制、典型应用场景

当我们讨论嵌入式AI时，本质上是在讨论如何将机器学习推理能力从云端数据中心迁移到靠近数据源头的物理世界。这一迁移并非简单的模型搬运，而是涉及计算架构、功耗预算、内存带宽和实时性约束的系统性重构。本章将首先厘清边缘计算与嵌入式AI的关系，随后深入剖析MCU（微控制器）在运行AI模型时面临的硬性边界，最后通过语音、视觉和异常检测三个典型场景，展示如何在资源受限的现实中寻找工程最优解。

边缘计算与嵌入式AI的定位差异

边缘计算是一个更广泛的架构概念，它涵盖了从靠近传感器的MCU到边缘网关、边缘服务器的整个计算谱系。而嵌入式AI特指在MCU或MPU（微处理器）等嵌入式设备上直接运行机器学习推理的过程。理解这一差异至关重要：并非所有边缘计算节点都适合部署AI模型，也并非所有AI模型都能压缩到MCU中运行。在工程实践中，我们通常将边缘计算划分为三个层级：端侧（MCU/传感器）、边侧（网关/工控机）和云侧（数据中心）。端侧追求极致的低功耗和实时响应，边侧提供更强的算力以运行复杂模型，云侧则负责模型训练和全局优化。

对于STM32这类典型MCU而言，其定位是端侧智能。这意味着我们需要在毫瓦级功耗预算内完成数据采集、信号预处理、特征提取和模型推理的全链路。与运行在GPU或边缘服务器上的AI不同，MCU上的AI没有批量处理的概念，每一次推理都是单样本、低延迟的流式处理。这种差异直接决定了模型架构的选择——我们通常不会选择ResNet-50或BERT这类大模型，而是采用深度可分离卷积、量化感知训练和知识蒸馏等技术，将模型压缩到几百KB以内。

MCU上部署AI的四大硬性限制

在开始任何嵌入式AI项目之前，必须对MCU的资源边界有清醒的认知。以下四个约束条件构成了嵌入式AI设计的“物理法则”，违反任何一条都可能导致项目返工。

约束维度	典型数值范围（STM32F4/H7系列）	对AI部署的影响	应对策略
算力（CPU主频）	168MHz ~ 480MHz	乘加运算吞吐量有限，无法运行大卷积核	使用深度可分离卷积、1x1卷积、模型剪枝
SRAM（运行内存）	192KB ~ 1MB	激活值存储受限，批量推理不可行	量化到int8/int16、内存复用、流式推理
Flash（存储）	1MB ~ 2MB	模型权重和代码总量受限	权重聚类、共享量化表、模型二值化
功耗预算	10mW ~ 100mW（活跃模式）	连续推理时间受限，需间歇工作	事件驱动唤醒、低功耗模式切换、硬件加速器

除了上述表格中的硬指标，还有一个常被忽视的软性约束——开发调试复杂度。MCU上的AI调试手段远不如云端丰富，无法使用GPU上的profiling工具，也无法方便地可视化中间层特征图。这意味着我们在设计模型时就要考虑可观测性，例如在关键层后插入调试输出点，或者使用仿真器进行指令级分析。

常见误区：很多初学者试图将TensorFlow或PyTorch中训练好的浮点模型直接转换为C数组烧录到MCU中。这种做法几乎必然失败——一个MobileNetV2浮点模型权重约14MB，远超STM32的Flash容量。正确的做法是：训练时即考虑量化感知训练（QAT），或训练后使用TensorFlow Lite Converter进行后训练量化（PTQ），将权重压缩到int8格式，体积缩小4倍，同时通过校准数据集将精度损失控制在2%以内。

典型应用场景一：语音唤醒与关键词识别

语音是MCU上AI落地最成熟的场景之一。以“小爱同学”或“Hey Siri”这类唤醒词为例，其核心需求是持续监听——设备必须7x24小时处于麦克风采集状态，但只有在检测到唤醒词时才启动主控系统。这要求语音预处理和推理的功耗必须极低，通常需要将平均功耗控制在毫瓦级别。

在STM32上实现语音唤醒的标准流程如下：

音频采集：使用PDM（脉冲密度调制）数字麦克风，通过STM32的DFSDM（数字滤波器）外设进行抽取滤波，得到16kHz/16bit的PCM数据。
特征提取：计算40维Mel频率倒谱系数（MFCC）或滤波器组（Filter Bank）特征，每帧25ms，帧移10ms。这一步需要消耗约5-8MIPS的算力。
模型推理：使用深度可分离卷积网络（DS-CNN）或CRNN，输入为40x40的特征图，输出为唤醒词/非唤醒词的二分类概率。
后处理：采用滑动窗口平均或状态机进行平滑，避免单帧误触发。

一个经过优化的DS-CNN模型参数量约为30K-50K，在int8量化后Flash占用约30-50KB，SRAM占用约20-30KB（用于激活值缓冲）。在168MHz的Cortex-M4F上，单次推理时间约为30-50ms，满足实时性要求。值得注意的是，特征提取的耗时往往比模型推理更长，因此优化FFT实现（使用CMSIS-DSP库）和MFCC计算是整体性能提升的关键。

  案例拆解：工业设备语音告警

  某工厂部署了基于STM32U5的振动传感器节点，需要识别设备异常时的特定告警音（如轴承摩擦声）。初始方案直接使用云端训练的ResNet-18模型，转换为int8后仍有2.3MB，无法部署。分析后发现，告警音主要集中在2kHz-6kHz频段，因此将采样率从16kHz降至8kHz，MFCC特征维度从40降至24，模型替换为4层DS-CNN（参数量18K）。最终模型Flash占用仅18KB，SRAM占用12KB，推理时间12ms，功耗从3.2mW降至1.1mW。关键改进在于：利用领域知识缩小输入特征维度，而非盲目压缩模型。

典型应用场景二：视觉检测与图像分类

视觉任务对MCU的挑战远大于语音，因为图像数据量呈数量级增长。一张96x96的RGB图像，即使缩小到32x32灰度图，也有1024个像素点，是语音特征维度的数十倍。因此，MCU上的视觉AI必须从传感器端就开始优化。

在STM32上部署视觉模型时，推荐采用以下工程路径：

传感器选择：优先选用带DVP或MIPI CSI接口的低分辨率摄像头（如OV7670、OV2640），输出QVGA（320x240）或更小的图像。
预处理下沉：在进入模型前完成裁剪、缩放、灰度化、归一化。使用DMA2D（图形加速器）进行图像拷贝和格式转换，避免CPU逐像素搬运。
模型选择：MobileNetV1（alpha=0.25）或EfficientNet-Lite0是MCU上视觉任务的常用起点。对于更严格的资源限制，可考虑二值化神经网络（BNN），但需注意精度损失。
帧率控制：MCU上视觉推理通常只能达到1-10 FPS，因此需要根据应用场景调整采样策略——例如在异常检测中，可以每5秒采集一帧，而非连续视频流。

以STM32H747（双核Cortex-M7+M4）为例，在M7核上运行MobileNetV1（alpha=0.25，输入96x96x3），int8量化后Flash占用约400KB，SRAM占用约250KB，单次推理约80ms。如果使用M4核进行图像采集和预处理，M7核专注推理，可以实现流水线并行，将有效帧率提升至8-10 FPS。

经验提醒：视觉任务中，图像预处理的一致性是精度复现的隐形杀手。训练时使用的归一化参数（均值、标准差）、缩放算法（双线性插值 vs 最近邻）必须与MCU端完全一致。建议在训练脚本中保存预处理参数，并在MCU端使用定点数模拟浮点运算，避免因浮点精度差异导致推理结果漂移。

典型应用场景三：异常检测（振动/电流/温度）

异常检测是工业物联网中最具商业价值的嵌入式AI场景。与语音和视觉不同，异常检测通常处理的是时间序列数据，且正常样本远多于异常样本，这决定了模型架构和训练策略的特殊性。

在MCU上实现异常检测有两种主流技术路线：

技术路线	模型类型	内存占用	推理时间（@168MHz）	适用场景
基于重构误差	Autoencoder（自编码器）	Flash 20-50KB, SRAM 10-20KB	5-15ms	振动信号、电流波形
基于距离/密度	隔离森林 / 局部异常因子	Flash 5-15KB, SRAM 5-10KB	1-5ms	温度、压力等慢变信号

Autoencoder的部署流程如下：首先在云端使用正常样本训练一个欠完备自编码器（隐藏层维度远小于输入维度），使其能够重构正常样本。部署到MCU后，计算重构误差（MSE），当误差超过阈值时判定为异常。这种方法的优势在于无需标注异常样本，且模型结构简单，非常适合MCU。

在实际工程中，我们还需要考虑时间窗口的设计。对于振动信号，通常采集1-2秒的时域波形，计算FFT得到频谱特征（如128维），然后输入Autoencoder。窗口过长会增加延迟，过短则无法捕捉低频特征。建议通过实验对比不同窗口长度下的F1分数来确定最优值。

风险提示：Autoencoder对“未知的正常模式”可能产生高重构误差。例如，设备在启动阶段和稳定运行阶段的振动特征差异很大，如果训练数据只包含稳定运行数据，则启动阶段会被误判为异常。解决方案是：在训练集中覆盖尽可能多的正常工况，或使用多个Autoencoder分别建模不同工况，并在MCU端增加工况识别前置模块。

模型部署的工程化流程与常见误区

无论选择哪种场景，MCU上的AI部署都应遵循统一的工程化流程，以避免“模型训练完成但无法落地”的窘境。

约束定义：明确目标MCU的Flash/SRAM/主频/功耗预算，以及推理延迟上限。
模型选型：根据任务复杂度选择模型家族，优先考虑MobileNet、DS-CNN、TinyMLPerf基准中的模型。
量化感知训练：在训练阶段就模拟int8量化误差，使用伪量化节点。
转换与校准：使用TensorFlow Lite Converter转换为.tflite格式，并用量化校准数据集计算每层激活值的动态范围。
生成C数组：将.tflite文件转换为C字节数组，或使用STM32Cube.AI工具链直接生成优化后的C代码。
板级验证：在真实硬件上测试推理结果与PC端仿真结果的差异，通常要求top-1精度差异小于1%。
功耗调优：使用STM32的WFI（等待中断）和STOP模式，在推理间隙进入低功耗状态。

  案例复盘：电机轴承异常检测项目

  背景：某风电企业需要在每台风机上部署振动监测节点，节点使用STM32L4系列MCU，要求平均功耗低于5mW，检测准确率不低于95%。

  初始方案：使用2D-CNN直接处理原始振动波形（1024点），模型参数量120K，Flash占用480KB，超出预算。

  分析过程：通过频谱分析发现，轴承故障特征集中在1kHz-3kHz频段，且故障频率与转频存在固定比例关系。因此将原始波形降采样至4kHz，并计算包络谱（Envelope Spectrum），将输入维度从1024降至256。

  优化操作：① 将2D-CNN替换为1D-CNN（参数量降至35K）；② 使用int8量化，Flash占用降至140KB；③ 将模型推理拆分为两段——第一段检测转频（每10秒执行一次），第二段仅在转频稳定时执行故障诊断（每30秒执行一次）。

  结果：最终Flash占用128KB，SRAM占用32KB，单次推理时间8ms，平均功耗3.8mW，准确率96.2%。

  复盘经验：领域知识（包络谱分析）比模型结构创新更能有效压缩模型规模；间歇性推理策略是满足功耗预算的关键。

总结与设计决策清单

嵌入式AI并非简单地将模型“塞进”MCU，而是一个从数据采集到模型推理的全链路系统工程。在开始STM32+TensorFlow Lite项目之前，请务必回答以下问题：

我的MCU是否有硬件浮点单元（FPU）？如果没有，必须使用定点量化模型。
模型权重和中间激活值是否能在SRAM中放下？如果放不下，考虑分块推理或模型剪枝。
推理延迟是否满足控制回路的实时性要求？如果延迟超过100ms，可能需要升级到MPU或增加硬件加速器。
功耗预算是否允许连续推理？如果不行，设计事件驱动的唤醒机制。
训练数据的分布是否覆盖了MCU实际部署环境中的所有工况？

最后，建议在项目初期就搭建一个最小可行产品（MVP）——使用开发板、现成传感器和预训练模型跑通端到端流程，再逐步优化模型和硬件设计。嵌入式AI的调试周期远长于云端AI，早期验证可以避免后期返工的高昂成本。