📚 课程目录第4章资源预算核心指标

4、资源预算核心指标：理解模型大小、运行时内存、峰值堆栈、CPU占用率、功耗等关键资源指标的定义与测量方法

在STM32这类资源受限的MCU上部署TinyML模型，与在PC或云端服务器上运行深度学习模型有着本质区别。PC端开发者往往关注推理延迟和吞吐量，而MCU开发者必须将目光聚焦于“资源预算”——即模型在硬件上运行时所消耗的每一项物理资源。资源预算不仅是模型能否跑起来的前提，更是系统长期稳定运行、电池寿命达标、实时响应满足要求的决定性因素。本章将系统拆解模型大小、运行时内存、峰值堆栈、CPU占用率、功耗这五大核心指标的定义、测量方法及其在量产评估中的工程意义。

上图展示了资源预算评估的总体框架。在实际工程中，这五个指标并非孤立存在，它们相互耦合、彼此制约。例如，增大模型输入分辨率会同时提升RAM占用和CPU计算量，进而影响功耗；而使用量化技术虽然能减小模型大小和RAM占用，却可能增加CPU的定点运算负担。因此，资源预算的核心任务是在这些相互冲突的约束中寻找最优平衡点。

4.1 模型大小：Flash存储的“房价”

核心原理：模型大小指模型在MCU Flash中占用的存储空间，包括权重参数、激活函数、算子代码、元数据等。对于STM32系列，Flash容量从几十KB到数MB不等，而一个典型的MobileNetV1模型（float32）大小约为16MB，显然无法直接部署。因此，模型压缩技术（量化、剪枝、知识蒸馏）是TinyML落地的第一道门槛。

测量方法：模型大小并非简单地查看.h5或.tflite文件大小，而是需要关注编译链接后实际烧录到Flash中的二进制体积。具体步骤如下：

使用STM32Cube.AI或TFLite-Micro转换工具生成C数组或二进制模型文件。
在编译工程中查看.map文件或使用arm-none-eabi-size命令查看.text和.rodata段大小。
对比不同优化选项（如-Os vs -O2）对代码段的影响。

// 查看编译产物大小示例
arm-none-eabi-size build/STM32F746.elf
   text    data     bss     dec     hex filename
  45212    1232    8912   55356    d83c STM32F746.elf

案例拆解：某工业振动监测项目选用STM32L4系列（1MB Flash），原始CNN模型为2.3MB（float32）。通过int8量化后模型降至580KB，再结合权重剪枝（去除30%接近零的权重）进一步压缩至410KB。最终模型占用Flash的40%，为固件升级和日志存储预留了充足空间。

经验提醒：模型大小评估必须考虑“模型+运行时库”的总和。TFLite-Micro解释器本身约需20-50KB Flash，CMSIS-NN优化算子库也会增加10-30KB。在资源紧张时，可考虑使用STM32Cube.AI的代码生成模式，它只生成模型所需的算子，而非全量库。

4.2 运行时内存：RAM的“精打细算”

核心原理：运行时内存指模型推理期间占用的RAM总量，包括输入/输出张量缓冲区、中间激活值、权重缓存（若从Flash加载则不计入RAM）、以及临时变量。STM32F4系列通常只有128-192KB RAM，而一个224x224x3的输入图像就需150KB（float32），因此必须采用内存复用、原地计算、张量生命周期管理等技术。

测量方法：运行时内存的测量分为静态和动态两种：

静态分析：通过TFLite-Micro的arena_size计算，或STM32Cube.AI的“RAM estimation”报告。
动态测量：在代码中记录malloc/free调用，或使用MPU（内存保护单元）设置边界，在越界时触发HardFault中断。

内存类型	占用内容	典型大小（int8模型）	优化手段
输入缓冲区	原始传感器数据	1-10KB	DMA直接搬运
中间激活	各层输出特征图	10-100KB	内存复用、In-Place计算
权重缓存	从Flash读取的权重	0KB（直接寻址）	MMU/FMC映射
输出缓冲区	分类结果/回归值	0.1-1KB	固定地址分配

实战场景：在STM32F103（20KB RAM）上部署关键词唤醒模型时，初始内存需求为28KB，超出硬件限制。通过将输入从40ms音频（16kHz采样）降为20ms、将第一层卷积的stride从2改为4、以及复用中间缓冲区，最终将RAM压至18KB，成功运行。

风险提示：RAM溢出是TinyML最常见的“隐性故障”。它不会立即导致崩溃，而是悄悄覆盖相邻变量，造成间歇性错误。量产前必须进行72小时以上的压力测试，并在测试中监控RAM水位线。

4.3 峰值堆栈：系统稳定性的“隐形杀手”

核心原理：峰值堆栈指程序执行过程中栈指针达到的最大深度。TinyML推理涉及多层函数调用（如Invoke()→Prepare()→Eval()→算子内核），每层调用都会压栈。若栈空间不足，将导致栈溢出，破坏相邻内存区域的变量，引发HardFault或静默数据损坏。

测量方法：常用的堆栈测量方法有三种：

栈填充法：在启动时用特定模式（如0xAAAAAAAA）填充整个栈区，运行后扫描被覆盖的边界。
任务级监控：使用FreeRTOS的uxTaskGetStackHighWaterMark()API。
硬件跟踪：利用STM32的DWT（Data Watchpoint and Trace）单元监控SP寄存器。

// 栈填充法示例（在main函数启动时执行）
#define STACK_FILL_PATTERN 0xA5A5A5A5
void stack_fill_init(void) {
    uint32_t *p = (uint32_t*)&_estack - 1;
    while (p > (uint32_t*)&_sstack) {
        *p-- = STACK_FILL_PATTERN;
    }
}
// 在任务运行后检查
uint32_t stack_usage_check(void) {
    uint32_t *p = (uint32_t*)&_estack - 1;
    uint32_t count = 0;
    while (p > (uint32_t*)&_sstack && *p == STACK_FILL_PATTERN) {
        count++; p--;
    }
    return count * 4; // 返回未使用的栈字节数
}

案例拆解：某智能门锁项目在量产前测试中发现，当人脸识别模型与蓝牙协议栈同时工作时，系统偶发重启。通过栈填充法检测，发现推理任务栈深度达到2.3KB，而配置的栈大小仅为2KB。分析发现，罪魁祸首是CMSIS-NN的arm_convolve_s8函数在特定输入尺寸下会递归调用自身，导致栈深度激增。解决方案是将栈大小调整为3.5KB，并优化了算子选择。

  关键结论：峰值堆栈的测量必须在“最坏情况”下进行——即所有中断嵌套、所有任务同时运行、模型处理最大输入尺寸时。仅测试正常路径会严重低估栈需求。

4.4 CPU占用率：实时性的“生命线”

核心原理：CPU占用率指模型推理占用的处理器时间比例。对于需要同时处理传感器采集、通信协议、用户界面的系统，推理必须控制在时间预算内。例如，一个10ms控制周期的系统，若推理耗时8ms，则留给其他任务的时间仅2ms，极易导致实时性崩溃。

测量方法：CPU占用率的测量需区分“平均占用率”和“峰值占用率”：

平均占用率：使用DWT->CYCCNT寄存器统计推理周期内的时钟周期数，除以总运行时间。
峰值占用率：通过GPIO翻转或逻辑分析仪测量推理开始/结束的脉冲宽度。

// 使用DWT测量推理耗时（单位：周期）
volatile uint32_t start_cycle, end_cycle;
DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;
start_cycle = DWT->CYCCNT;
model_invoke(&model, input, output);
end_cycle = DWT->CYCCNT;
float inference_ms = (float)(end_cycle - start_cycle) / SystemCoreClock * 1000.0f;

实战场景：在STM32H743（480MHz）上部署姿态识别模型，要求推理频率为100Hz（即10ms周期）。初始float32模型推理耗时12.5ms，超出预算。通过int8量化将耗时降至4.2ms，再启用CMSIS-NN的SIMD优化进一步降至2.8ms。最终CPU占用率仅为28%，为其他任务留出充足余量。

优化阶段	推理耗时	CPU占用率（100Hz周期）	备注
float32基线	12.5ms	125%	无法满足实时性
int8量化	4.2ms	42%	精度损失<0.5%
CMSIS-NN优化	2.8ms	28%	启用SIMD指令

经验提醒：CPU占用率评估不仅要看推理本身，还要考虑数据预处理（如FFT、滤波）和后处理（如softmax、阈值判断）的开销。这些辅助操作可能占推理耗时的20-40%。

4.5 功耗：电池寿命的“经济账”

核心原理：功耗是电池供电设备的核心指标，由动态功耗（与频率、电压、翻转率相关）和静态功耗（漏电流）组成。TinyML推理的功耗模型为：E_total = E_compute + E_memory + E_idle。其中，E_compute与CPU频率和指令数成正比，E_memory与Flash/RAM访问次数相关，E_idle则取决于低功耗模式的进入/退出策略。

测量方法：功耗测量需要硬件支持，常用方法包括：

串联采样电阻法：在电源路径串联10mΩ-100mΩ电阻，使用示波器或高精度ADC测量压降。
专用功耗分析仪：如Joulescope、Otii Arc，可同步采集电流和电压，绘制功耗曲线。
MCU内部ADC：利用STM32的VREFINT通道和外部采样电阻实现粗略测量。

案例拆解：某可穿戴心电监测设备使用STM32L552（超低功耗系列），目标电池寿命为7天（200mAh锂聚合物电池）。系统每100ms采集一次ECG信号，每次推理消耗：

传感器采集+预处理：2.1mA × 15ms = 31.5μAh
模型推理（int8）：3.8mA × 8ms = 30.4μAh
BLE传输：6.5mA × 5ms = 32.5μAh
待机（STOP2模式）：1.2μA × 99.97s ≈ 33.3μAh

单周期总能耗约127.7μAh，每天约消耗30.6mAh，理论寿命约6.5天。通过将推理频率降至50Hz（每200ms一次），并将BLE数据包合并发送，单周期能耗降至89.2μAh，寿命延长至8.2天，满足需求。

风险提示：功耗测量必须在“真实负载”下进行，而非空载测试。模型推理时的电流波动可能高达数十mA，若电源设计余量不足，会导致电压跌落，引发复位或数据损坏。建议在电源输出端增加100μF以上的去耦电容。

4.6 综合评估与常见误区

综合评估框架：资源预算不是一次性工作，而是贯穿整个开发周期的持续活动。建议建立“资源预算表”，在模型选型、量化、优化、集成各阶段持续更新。

指标	预算值	实测值	余量	风险等级
Flash占用	512KB	410KB	20%	低
RAM占用	96KB	82KB	15%	中
峰值堆栈	3.5KB	2.9KB	17%	低
CPU占用率	40%	28%	30%	低
平均功耗	1.5mA	1.35mA	10%	中

常见误区：

误区一：只关注模型文件大小，忽略运行时库开销。实际上，TFLite-Micro解释器+算子库可能比模型本身占用更多Flash。
误区二：用PC端的内存分析工具估算MCU内存。MCU没有虚拟内存，所有分配必须静态确定。
误区三：在优化CPU占用率时，只优化推理内核，忽略数据拷贝和格式转换的开销。在STM32上，memcpy和数据类型转换可能消耗高达30%的推理时间。
误区四：功耗测试使用开发板而非最终产品PCB。开发板上的调试LED、USB转串口芯片、稳压器静态电流会严重污染测量结果。

总结复盘：资源预算的本质是“在约束下做决策”。每个指标都有其物理意义和测量边界，只有深入理解这些指标背后的硬件机制，才能做出合理的工程权衡。建议团队在项目启动时即建立资源预算基线，每周更新一次，并在每次模型变更后重新测量全部五项指标。量产前的最终验证应包含：极端温度下的内存压力测试、最高中断频率下的栈深度测试、以及电池电压最低时的功耗测试。只有通过这“三重考验”，TinyML模型才能真正从实验室走向量产。