TensorFlow Lite Micro 开发短记：资源预算如何取舍

TensorFlow Lite Micro 开发短记：资源预算如何取舍

在微控制器上做推理，延迟、Flash 和 RAM 往往不能同时最优。压缩模型之前，先说明目标：是把单次响应控制在时间预算内，还是在同一芯片上留出更多内存给通信和控制任务。

用同一条件比较方案

比较模型时固定输入窗口、时钟频率、编译器优化选项和算子实现。分别记录模型大小、tensor arena、一次 Invoke() 的时间，以及系统在采样和通信同时运行时的最坏延迟。只报空载平均时间，会掩盖调度冲突。

量化也要看实际误差。INT8 常能减少存储和带宽，但特征预处理、量化参数和输入范围有变化时，准确率可能先出问题。把代表性输入和错误样本纳入回归测试，别只用一段演示数据。

给资源留余量

不要把 arena、任务栈和 Flash 刚好塞满。发布版本还需要日志、升级和故障处理空间。先拿到稳定基线，再评估降低采样率、裁剪算子或更换模型结构；这样做出的取舍才可解释，也能复现。

比较结果要能还原

将每次构建的模型哈希、编译器版本、arena 大小和输入样本集 ID 写进测试结果。再让采样任务和通信任务按真实周期并发运行，记录连续多轮 Invoke() 的最长值，而非只取一次。若缩小 arena 后出现偶发失败，要把失败码与输入序号一起保存，先判断是内存布局还是模型本身导致。

资源预算还应留给故障处理路径：例如通信重连、传感器异常和固件升级时的临时缓冲。模型在单独 demo 中可运行，并不能证明它能与完整系统共存；最终选择应由目标芯片上的整体测试决定。

将原始测量日志随发布包归档，后续优化才能有可信的基线。