1. 课程导入
TFLite Micro（TensorFlow Lite for Microcontrollers）是专为内存资源受限的MCU（微控制器）设计的推理引擎。在典型的嵌入式设备中，Flash容量通常在256KB到2MB之间，RAM则仅有几十到几百KB。当我们将一个训练好的神经网络模型部署到这样的设备上时，模型权重、偏置、量化参数等数据往往占据整个固件体积的70%以上。如果这些常量数据被错误地放置在RAM中，轻则导致启动时内存溢出，重则使设备根本无法运行模型。因此，常量区优化——即如何将权重等只读数据合理地安排在Flash中，并让CPU在推理时高效访问——是TFLite Micro部署中最关键的基础环节之一。
上图展示了TFLite Micro常量区优化的整体链路：模型编译产物（权重、偏置、元数据）通过链接脚本被分配到Flash的只读段（.rodata），MCU在推理时通过XIP（Execute in Place）或缓存机制直接访问这些常量数据，从而避免将大量权重复制到有限的RAM中。这一过程涉及编译器、链接器、MCU存储架构和TFLite Micro运行时多个层面的协同设计。
1.1 常量区优化的核心原理
TFLite Micro的模型数据本质上是一个扁平化的字节数组（通常以C数组形式嵌入固件），其中包含权重、偏置、量化参数、算子描述符等。这些数据在模型加载后不会被修改，因此属于典型的只读数据。常量区优化的核心原理可以概括为：让只读数据停留在Flash中，并通过地址映射或缓存机制被CPU直接访问，而不是在启动时复制到RAM。
从嵌入式系统的存储结构来看，MCU通常具备以下存储区域：
- Flash（非易失性）：存放代码和只读常量，掉电不丢失。支持XIP的MCU（如Cortex-M33、RISC-V）可以直接在Flash地址上执行代码和读取数据。
- SRAM（易失性）：存放栈、堆、全局变量和临时张量。访问速度快，但容量小、功耗高。
- EEPROM/外部Flash：用于存储配置参数或大模型，访问速度较慢，通常需要DMA或内存映射。
TFLite Micro的默认实现中，模型数据通过tflite::GetModel(buffer)解析，该buffer可以指向Flash地址。如果链接脚本将模型数组放置在.rodata段，那么模型权重就自然位于Flash中。推理时，算子内核（如卷积、全连接）直接通过指针访问这些Flash地址，无需额外的RAM拷贝。
关键点：常量区优化的本质是存储位置决策——决定哪些数据放在Flash、哪些放在RAM，以及如何通过链接脚本和运行时配置实现这种布局。优化目标不是单纯地“省空间”，而是在RAM容量、Flash访问速度和代码可维护性之间取得平衡。
1.2 判断方法：如何识别常量区优化的需求
在实际项目中，并非所有模型都需要深度优化常量区。以下判断方法可以帮助你快速评估是否需要投入精力进行常量区优化：
| 判断维度 | 需要优化的信号 | 不需要优化的场景 |
|---|---|---|
| RAM占用率 | 模型权重 > RAM容量的50%，或启动时出现堆栈溢出 | RAM充足，权重仅占10%以下 |
| Flash剩余空间 | Flash剩余 < 20%，需要压缩或重定位 | Flash空间充裕，可容纳完整模型 |
| 启动时间 | 启动时复制权重耗时 > 100ms，影响用户体验 | 启动时间无严格要求 |
| OTA升级需求 | 需要远程更新模型，要求模型段可独立替换 | 固件一次性烧录，不更新模型 |
| 功耗约束 | 频繁从Flash读取导致功耗超标（Flash读取电流高于RAM） | 电池容量充足，功耗不敏感 |
一个简单的量化判断流程：
- 编译固件后，查看
.map文件中.rodata段的大小，记为R；查看RAM中.data+.bss的大小，记为M。 - 如果
R / (R + M) > 0.6，说明模型数据占主导，必须确保这些数据在Flash中。 - 如果
M接近MCU的RAM上限（如超过80%），则必须检查是否有权重被错误地复制到RAM。 - 使用
readelf -S或objdump -h查看段属性，确认.rodata的Flags包含ALLOC且READONLY。
1.3 案例拆解：一个典型的MCU模型部署优化过程
我们以一个实际项目为例：某智能传感器节点使用STM32L476（1MB Flash，128KB RAM）部署一个语音关键词识别模型（KWS）。模型包含约300KB的int8权重和20KB的偏置/缩放因子。
初始现象：直接使用TFLite Micro默认配置编译后，固件可以烧录，但设备启动时立即进入HardFault。通过调试器查看，发现_sdata和_edata的复制循环试图将300KB的权重从Flash复制到RAM，而RAM只有128KB，导致栈指针覆盖了关键数据。
分析过程：
- 查看链接脚本（.ld文件），发现模型数组被放在了
.data段（可读写），而非.rodata段。 - 检查模型生成代码，发现
model_data[]数组被声明为const，但链接脚本的段分配规则未将const变量归入.rodata。 - 进一步使用
nm命令查看符号表，确认model_data的地址位于RAM区域（0x20000000之后）。
操作步骤：
- 修改链接脚本，在
.rodata段中显式添加KEEP(*(.rodata*))，并确保model_data被编译到只读段。 - 在C代码中，将
model_data声明为const unsigned char model_data[] __attribute__((section(".rodata")))，强制指定段属性。 - 重新编译后，检查
.map文件，确认model_data地址位于Flash区域（0x08000000之后）。 - 在TFLite Micro初始化代码中，使用
tflite::GetModel(model_data)直接传入Flash地址，并设置arena（Tensor Arena）为RAM中的一块静态缓冲区。
结果对比：
| 指标 | 优化前 | 优化后 |
|---|---|---|
| RAM占用 | 320KB（溢出） | 48KB（Tensor Arena + 中间结果） |
| 启动时间 | 无法启动 | 12ms（无权重拷贝） |
| Flash占用 | 320KB（.data段） | 320KB（.rodata段） |
| 稳定性 | HardFault | 稳定运行 |
风险与代价：将权重放在Flash中后，每次推理时CPU需要从Flash读取数据。对于STM32L476，Flash访问需要等待状态（2个等待周期），导致推理速度下降约15%。为缓解这一问题，我们启用了ART加速器（Adaptive Real-Time Accelerator），将Flash读取延迟降低到接近RAM的水平。
复盘经验：常量区优化不是简单的“把const变量放Flash”，而是需要从链接脚本、编译器属性、运行时配置三个层面协同调整。尤其要注意，某些MCU的Flash不支持字节寻址（如需要32位对齐），此时需要在模型生成时进行对齐填充。
1.4 常见误区与总结复盘
在TFLite Micro常量区优化实践中，开发者常陷入以下误区：
误区一：认为const关键字就足够。在嵌入式C中，const只是编译期约束，不保证变量被放在只读段。必须结合链接脚本和段属性才能确保物理位置。
误区二：忽略Flash访问速度差异。虽然Flash容量大，但访问速度通常比RAM慢2-5倍。对于计算密集型的算子（如卷积），如果权重频繁从Flash读取，可能成为性能瓶颈。此时需要考虑缓存策略或部分缓存到RAM。
误区三：将所有数据都放入Flash。某些数据（如量化缩放因子）虽然名义上是常量，但在推理过程中可能被修改（例如动态量化）。这类数据应放在RAM中，否则会导致HardFault。
误区四：忽视对齐问题。ARM Cortex-M要求32位访问必须4字节对齐。如果模型数据在Flash中的地址未对齐，会导致总线错误。TFLite Micro的模型生成工具通常已处理对齐，但自定义模型时需注意。
总结复盘：常量区优化的核心决策路径可以归纳为：
- 识别数据属性：区分真正只读（权重、偏置）和伪只读（运行时可能修改的量化参数）。
- 段分配：通过链接脚本将只读数据放入
.rodata，可读写数据放入.data或.bss。 - 运行时验证：使用调试器检查内存映射，确认模型地址位于Flash区域。
- 性能调优：根据Flash访问延迟决定是否启用缓存、DMA或部分RAM缓存。
- OTA考虑：如果模型需要远程更新，应将模型段独立分区，并支持运行时重映射。