📚 课程目录第2章 TinyML基础

TinyML基础：微控制器资源约束、典型应用场景与模型部署挑战

TinyML 的核心思想是在功耗极低、资源受限的微控制器（MCU）上直接运行机器学习推理，从而避免将数据上传到云端所带来的延迟、带宽和隐私问题。与服务器端的深度学习不同，TinyML 必须在 KB 级内存、MHz 级主频和mW 级功耗的约束下完成实时推理。理解这些硬件底层的物理限制，是后续选择非结构化权重剪枝比例的前提——因为剪枝的本质，就是在“存储容量”和“计算吞吐”的双重瓶颈下，用精度换取生存空间。

上图展示了 TinyML 部署的核心链路：左侧是 MCU 的物理资源天花板，右侧是典型应用场景，中间则是模型压缩与部署优化的挑战区域。非结构化权重剪枝正是作用于“训练稠密模型”与“MCU 部署”之间的关键桥梁。下面我们逐一展开分析。

2.1 微控制器资源约束：每一字节都要精打细算

微控制器与桌面 GPU 或手机 SoC 的本质区别在于：它没有“富余”资源。一颗典型的 Arm Cortex-M4 或 RISC-V MCU，其 SRAM 通常只有几十到几百 KB，Flash 存储也以 MB 为单位。这意味着模型权重、中间激活值、运行时缓冲区都必须共享同一块极小的内存池。

核心原理：存储与计算的双重瓶颈

在 TinyML 中，Flash 容量决定了模型能否被烧录，SRAM 容量决定了推理时能否不溢出，而主频与 MAC（乘加运算）能力决定了实时性。以关键词唤醒（KWS）任务为例，一个包含 5 万参数的 DNN 模型，若以 float32 存储，需要 200KB Flash，这已经接近入门级 MCU 的存储上限。若采用 int8 量化，则降至 50KB，但精度可能下降 1-2%。非结构化剪枝则通过将大量权重置零，配合稀疏存储格式，进一步压缩有效参数数量。

资源类型	典型范围	对模型的影响	剪枝的关联
Flash (代码+权重)	256KB - 2MB	决定模型大小上限	剪枝后稀疏矩阵可压缩存储
SRAM (运行时数据)	16KB - 512KB	决定激活值/中间缓冲区	剪枝减少激活值计算量，间接降低 SRAM 峰值
CPU 主频	48MHz - 240MHz	决定单次推理延迟	剪枝减少 MAC 次数，直接降低延迟
功耗预算	1mW - 50mW	决定电池寿命	剪枝后计算量下降，动态功耗降低

判断方法：如何评估目标 MCU 是否适合运行某模型

计算模型总参数量：统计卷积层、全连接层的权重数量之和。
估算 Flash 占用：参数量 × 量化字节数（float32=4B, int8=1B, 稀疏格式另加索引开销）。
估算 SRAM 峰值：取最大激活层尺寸 + 权重缓冲 + 临时变量。
估算 MAC 总数：每层输出尺寸 × 卷积核尺寸 × 输入通道数，求和后除以主频得到理论延迟下限。

风险提示：很多初学者只关注 Flash 是否放得下，却忽略了 SRAM 峰值。例如一个 1MB 的模型，若推理时激活值需要 300KB SRAM，而 MCU 只有 256KB，则直接导致内存溢出（HardFault）。剪枝虽然主要减少 Flash 占用，但通过减少通道数或稀疏化，也能间接降低激活值尺寸。

2.2 典型应用场景：从语音到振动的边缘智能

TinyML 的应用并非“把大模型缩小”，而是针对特定场景设计的小模型。这些场景的共同特点是：数据局部性强、实时性要求高、网络连接不可靠或功耗敏感。

场景一：关键词唤醒（KWS）与语音命令识别

智能音箱、TWS 耳机中的“Hey Siri”或“小爱同学”就是典型的 TinyML 应用。设备需要 24 小时监听麦克风，但只有在检测到唤醒词时才启动主系统。模型通常为 1D 卷积或 CRNN，参数量在 10 万以内，推理延迟需小于 50ms。剪枝在这里的价值在于：将模型从 200KB 压缩至 80KB，使得可以部署在 512KB Flash 的 BLE Audio MCU 上，同时保持 95% 以上的唤醒率。

场景二：工业预测性维护与异常振动检测

在工厂电机或泵上安装加速度传感器，通过分析振动频谱判断轴承磨损。这类任务通常使用轻量级随机森林或小型 1D-CNN。由于工业环境往往没有 Wi-Fi，且更换电池困难，模型必须能在 1mW 功耗下运行。非结构化剪枝可以将模型从 50KB 压缩至 20KB，使得可以使用更小封装的 MCU，降低 BOM 成本。

场景三：视觉识别（VGA 以下分辨率）

在智能门锁、工业质检中，使用 QVGA（320×240）或更小分辨率的图像输入。MobileNetV1 的 0.25 倍宽度版本是常见选择，但仍有约 40 万参数。通过 50% 的非结构化剪枝，可以在精度损失小于 1% 的情况下，将 Flash 占用从 160KB 降至 80KB（int8 量化后），从而适配 128KB Flash 的入门级 MCU。

  场景选择要点：并非所有任务都适合 TinyML。如果模型需要处理高分辨率图像或复杂语义理解，MCU 的算力无法满足。剪枝比例的选择必须基于具体场景的精度容忍度——例如唤醒词允许 2% 的误触发率，但工业安全检测可能要求 99.9% 的召回率。

2.3 模型部署挑战：从 PyTorch 到 MCU 的鸿沟

即使模型在 PC 上训练精度很高，部署到 MCU 仍面临一系列工程挑战。这些挑战直接影响剪枝策略的选择——例如，某些剪枝方法虽然减少了参数量，但产生的稀疏模式无法被 MCU 上的推理库高效加速。

挑战一：算子支持不完整

主流的 TFLite Micro、CMSIS-NN 等推理库只支持有限的算子集合。例如，BatchNormalization 在推理时通常被折叠到卷积层中，但某些自定义的稀疏卷积算子可能不被支持。如果剪枝后产生的是不规则稀疏矩阵，而推理库不支持稀疏卷积，那么剪枝带来的理论加速将完全无法兑现。

挑战二：量化与稀疏的相互作用

非结构化剪枝通常与 int8 量化结合使用。但量化会将权重映射到有限的离散值，这可能导致剪枝后的微小权重在量化后变为非零值，从而破坏稀疏性。因此，剪枝比例的选择必须考虑量化误差的放大效应。

// 伪代码示例：剪枝后量化导致稀疏性丢失
float32_weight = 0.001;  // 剪枝阈值以下，应置零
int8_weight = quantize(0.001); // 可能量化为 1，不再是零
// 解决：先量化再剪枝，或使用剪枝感知量化

挑战三：内存对齐与碎片化

MCU 的 SRAM 通常要求 4 字节对齐。非结构化剪枝产生的稀疏矩阵若使用 CSR（压缩稀疏行）格式存储，索引数组会占用额外内存。对于小模型，索引开销可能超过权重节省的空间，导致“剪枝后反而更占内存”的尴尬局面。

存储格式	权重占用	索引开销	适用场景
稠密 (Dense)	N × 字节	无	剪枝比例 < 30%
CSR (稀疏行)	非零值 × 字节	每行 2 字节 + 每非零值 2 字节	剪枝比例 > 70%
位掩码 (Bitmap)	非零值 × 字节	每权重 1 bit	中等稀疏度，需硬件支持

2.4 案例拆解：在 STM32F103 上部署剪枝后的 KWS 模型

下面通过一个完整的案例，展示资源约束如何驱动剪枝比例的选择。

背景与目标：某智能家居产品需要在一颗 STM32F103C8T6（Cortex-M3, 72MHz, 64KB SRAM, 128KB Flash）上实现“小爱同学”唤醒词检测。初始模型为 2 层卷积 + 2 层全连接，总参数量 85,000，float32 存储需 340KB，远超 Flash 容量。

初始现象：直接 int8 量化后，模型降至 85KB，但 Flash 剩余空间仅 43KB，无法容纳代码和运行时库。同时，推理延迟为 180ms，超过 100ms 的实时性要求。

分析过程：

Flash 瓶颈：85KB 权重 + 30KB 代码 = 115KB，仍超出 128KB。需要将权重压缩至 70KB 以下。
SRAM 瓶颈：最大激活层为第一层卷积输出，尺寸为 64×32×8 = 16KB，加上权重缓冲 20KB，峰值约 40KB，尚可接受。
延迟瓶颈：总 MAC 数为 12M，72MHz 主频下理论延迟 167ms，实际 180ms 合理。需要减少 MAC 数。

剪枝策略：采用幅度剪枝，对全连接层施加 60% 剪枝比例，对卷积层施加 30% 比例。原因：全连接层参数量占比 70%，且对精度影响较小；卷积层对特征提取更敏感。

实际操作：

# 伪代码：非结构化剪枝流程
for layer in model.layers:
    if layer.type == 'Dense':
        threshold = percentile(layer.weights, 60)  # 60% 分位数
    elif layer.type == 'Conv2D':
        threshold = percentile(layer.weights, 30)
    mask = abs(layer.weights) > threshold
    layer.weights *= mask  # 置零
# 微调 5 个 epoch，学习率 1e-4

结果对比：

指标	原始 int8	剪枝后 (30%/60%)	变化
Flash 权重占用	85KB	52KB (CSR格式)	-39%
推理延迟	180ms	110ms	-39%
唤醒率 (正样本)	96.2%	94.8%	-1.4%
误唤醒率 (每小时)	0.8次	1.2次	+0.4次

风险与代价：CSR 格式在 MCU 上需要额外的索引解析逻辑，导致代码量增加 4KB。同时，稀疏卷积在 CMSIS-NN 中不支持，只能使用稠密卷积计算，因此卷积层的 30% 剪枝并未带来延迟收益，反而因索引开销增加了 3% 的延迟。最终通过将卷积层剪枝比例降至 15%，全连接层提升至 70%，才达到最佳平衡。

复盘经验：剪枝比例的选择不能只看参数减少百分比，必须结合目标硬件的算子支持情况。在 MCU 上，全连接层的剪枝收益远大于卷积层，因为全连接层通常可以映射为矩阵乘法，稀疏加速更容易实现。而卷积层若没有稀疏卷积库，剪枝只会增加索引开销。

2.5 常见误区与总结复盘

在 TinyML 部署中，关于资源约束和剪枝的关系，存在几个常见误区：

误区一：认为剪枝比例越高越好。实际上，当剪枝比例超过 80% 时，CSR 索引开销会显著增加，且精度可能急剧下降。对于 MCU 上的小模型，70% 往往是收益拐点。
误区二：忽略 SRAM 峰值。有些工程师只关注 Flash 是否够用，却忽略了推理时的中间激活值。剪枝虽然减少了权重，但若激活值不变，SRAM 压力依然存在。
误区三：认为 int8 量化可以完全替代剪枝。量化只能减少每个权重的字节数，但无法减少 MAC 计算量。剪枝则能同时减少存储和计算，两者互补而非替代。
误区四：在 PC 上验证稀疏加速效果。PC 的 CPU 或 GPU 对稀疏矩阵有专门优化，而 MCU 上的 CMSIS-NN 可能不支持。必须在目标硬件上实测延迟。