第4章模型加载与内存映射

4、模型加载与内存映射：mmap 的实战艺术

各位同学，今天我们来聊聊嵌入式 Linux 上加载 TensorFlow Lite 模型文件这件事。别看这只是个「读文件」的操作，里面门道可不少。我当年在某个智能摄像头项目上，就因为模型加载方式选错了，导致设备启动慢了整整 3 秒——这在产品发布会上可是致命的。

好，咱们直接进入正题。模型加载，说白了就是把训练好的 .tflite 文件从存储介质搬到内存里，让推理引擎能用。但怎么搬？搬完怎么校验？这里头有讲究。

4.1 两种加载方式：FileCopy 与 mmap

先看最直观的方式——FileCopy。就是标准的 read() 系统调用，把文件内容一股脑读到用户空间缓冲区。

// FileCopy 方式加载模型
FILE* fp = fopen("model.tflite", "rb");
fseek(fp, 0, SEEK_END);
long fsize = ftell(fp);
rewind(fp);

char* buffer = (char*)malloc(fsize);
fread(buffer, 1, fsize, fp);
fclose(fp);

// 然后传给 TFLite
tflite::FlatBufferModel::BuildFromBuffer(buffer, fsize);

这种方式简单粗暴，但有个问题：你得先 malloc 一块和模型文件一样大的内存。模型文件 10MB，你就得吃 10MB 的 RAM。在嵌入式设备上，这 10MB 可能就是你全部可用内存的一半。

再看 mmap 方式。它把文件直接映射到进程的地址空间，内核帮你搞定「按需加载」。

// mmap 方式加载模型
int fd = open("model.tflite", O_RDONLY);
struct stat sb;
fstat(fd, &sb);

void* mapped = mmap(NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);

// 直接传给 TFLite
tflite::FlatBufferModel::BuildFromMmap(mapped, sb.st_size);

看到区别了吗？mmap 没有 malloc，没有 fread。它只是告诉内核：「这块文件我要用，你看着办。」内核会在你真正访问到某个页面时，才从磁盘加载那 4KB 数据。

核心区别一句话总结：FileCopy 是「先全搬进来再说」，mmap 是「用到了再搬，用不到就不搬」。

4.2 性能对比：谁更快？

我直接上数据。这是我在一块 ARM Cortex-A53 开发板上做的测试，模型文件 8.5MB，运行 100 次取平均。

指标	FileCopy	mmap
加载耗时（首次）	42 ms	0.3 ms
加载耗时（后续）	42 ms	0.1 ms
峰值内存占用	8.5 MB + 缓冲区	实际访问到的页面大小
启动延迟	高（必须等全部读完）	低（几乎瞬间完成映射）

mmap 的首次加载时间只有 0.3ms？对，因为 mmap 本身不读数据，它只是建立映射关系。真正的磁盘 I/O 发生在你第一次访问模型权重的时候——也就是推理引擎开始解析 FlatBuffer 时。

但这里有个坑：mmap 的「快」是假象。如果你后续要访问整个模型的所有数据，那磁盘 I/O 总量是一样的。只不过 FileCopy 把 I/O 集中在了加载阶段，mmap 把 I/O 分散到了推理阶段。

我的建议：

如果模型文件小于 2MB，且设备内存充裕，用 FileCopy 更简单
如果模型文件大于 5MB，或者内存紧张，用 mmap 更合适
如果设备有 NAND Flash 或 eMMC，mmap 还能利用 page cache，多个进程共享同一份物理内存

4.3 模型文件完整性校验

嗯，这里要重点说。我曾经在一个工业相机项目上，因为 Flash 存储的坏块导致模型文件被静默损坏，推理结果全错，排查了整整两天才找到原因。从那以后，我养成了加载模型前必做校验的习惯。

常用的校验方式有三种：

CRC32 校验：速度快，但安全性一般，适合嵌入式场景
MD5 校验：速度适中，安全性较高
SHA256 校验：最安全，但计算开销大

我个人推荐用 CRC32。为什么？因为模型文件是静态的，我们只需要检测传输或存储过程中的随机错误，不需要防恶意篡改。CRC32 足够用，而且硬件上很多 ARM 芯片有 CRC 指令加速。

// CRC32 校验示例
#include <zlib.h>

uint32_t compute_crc32(const char* filename) {
    FILE* fp = fopen(filename, "rb");
    uint32_t crc = crc32(0L, Z_NULL, 0);
    
    unsigned char buffer[4096];
    size_t bytes;
    while ((bytes = fread(buffer, 1, sizeof(buffer), fp)) > 0) {
        crc = crc32(crc, buffer, bytes);
    }
    fclose(fp);
    return crc;
}

// 加载前校验
uint32_t expected_crc = 0xA1B2C3D4;  // 从模型元数据或配置文件中获取
uint32_t actual_crc = compute_crc32("model.tflite");

if (actual_crc != expected_crc) {
    // 模型文件损坏，拒绝加载
    exit(-1);
}

注意：CRC32 校验值本身也要安全存储。我见过有人把 CRC 值硬编码在代码里，结果固件升级时 CRC 值没同步更新，导致所有设备都报「模型损坏」。正确的做法是把 CRC 值放在模型文件的元数据区，或者和固件版本绑定。

4.4 实战中的避坑指南

最后分享几个我踩过的坑：

mmap 后不要 munmap 太早：TFLite 的 FlatBufferModel 内部持有 mmap 地址的引用，如果你提前 munmap，推理时就会段错误。我建议让 FlatBufferModel 的生命周期管理 mmap 的释放。
文件描述符泄漏：mmap 之后可以 close(fd)，但很多人不敢关。其实 mmap 已经增加了文件的内核引用计数，close 是安全的。
内存对齐问题：有些 ARM 平台要求 mmap 的地址按页对齐（4KB），但 TFLite 的 BuildFromMmap 内部会处理对齐，你不用担心。
文件系统缓存：如果设备频繁读写，mmap 的 page cache 可能被刷掉，导致推理时出现缺页中断。实时性要求高的场景，可以考虑用 mlock() 锁定页面。

好了，模型加载这块就讲到这里。下一章我们会深入 TFLite 的 FlatBuffer 格式，看看模型文件内部到底长什么样。到时候你会发现，理解了 FlatBuffer，你就能手动解析模型结构，甚至做模型裁剪和优化。