mmap直挂权重只需1.2秒——大模型冷启动加速原理与实操

前两天我调一个推理服务，模型是DINOv3这个级别的视觉大模型，权重文件动辄几个GB。同事跑过来抱怨说每次冷启动加载权重都要等好几十秒，监控图上那个Pod一直处于未就绪状态，看得人血压飙升。我顺手用mmap把权重直挂进去，冷启动时间直接掉到1.2秒左右，从“让人想放弃”变成“可以接受”。这篇是连续记录的第3天第1篇，今天不聊配置调优，就专门磕一个问题：为什么mmap直挂权重只需要1.2秒。

这个话题适合所有被模型加载卡过脖子的人，不管你是做推理服务、离线批处理还是模型压缩，只要和权重文件打过交道，都值得花几分钟把mmap的原理和实操流程弄明白。先把结论放在前面：mmap快不是因为它“读得快”，而是因为它“根本没读”。这篇会把这六个字拆开讲清楚，顺带给出可以直接抄走的代码和踩坑记录。

1. 先搞清楚：mmap是什么，它和read差在哪

1.1 一次read背后发生了什么

很多人一听到“加载权重”就默认要用read系函数把字节搬进内存，觉得这是天经地义的事。其实这一步的背后开销远比你想象的大。当你的进程调用read(fd, buf, len)时，内核会把磁盘上的数据先读到内核的页缓存（page cache）里，然后把页缓存里的内容再拷贝到用户态传入的buf地址中。到这一步，你的用户态内存里才有了一份“拷贝”。

我把这个过程比作什么呢？就像你去图书馆借书，不是直接翻书，而是得先让管理员把书搬到复印机上，复印一份给你，你再看复印件。如果你只是看、不批注，那这份复印件其实是多余的。

这里面的核心开销有两个：一个是DMA把磁盘块搬进页缓存的IO时间，另一个是内核态到用户态的一次memcpy拷贝。对于几个GB的权重文件，memcpy拷贝几个GB的数据，在PCIe带宽和内存带宽充裕的情况下尚且要一秒钟左右，再加上IO排队和系统调用上下文切换，几十秒真不夸张。而且最致命的是，read会把整个文件都“物质化”到内存里，不管你后面用不用得着。

1.2 mmap直接映射地址空间，省掉一次拷贝

mmap全称memory map，它做的事情用一句话说就是：把文件的某个区间和你进程的一段虚拟内存地址一一映射起来。映射完以后，你访问内存地址addr[i]，等价于访问文件偏移offset+i处的字节。这个过程中没有一次性拷贝，没有立即读盘。

关键点在于“访问时才加载”。mmap系统调用本身只建立映射关系（页表项），它不负责把数据搬进来。当你的代码第一次去touch那块地址空间时，CPU发现虚拟页没有对应的物理页，触发缺页中断（page fault），内核才从磁盘拉取那一页进物理内存，然后把页表修好，再返回用户态继续执行。这个懒加载机制和“按需换页”本质上是同一套东西。

所以mmap快的本质是时间维度上的“偷懒”：它把一次性搬数据的庞大开销，打散成按页粒度的小开销，并且推迟到你真正用到某个权重张量时才发生。

1.3 mmap不是冷门魔法，PyTorch和TensorRT都在用

有朋友会觉得mmap是C++老古董干的事，跟深度学习框架没关系。不是的。PyTorch从1.13左右开始就在torch.load里内置了mmap参数；TensorRT做模型序列化和反序列化时也大量依赖内存映射；Hugging Face的safetensors库加载大模型时默认就是通过mmap方式打开文件，整套体系已经跑了很多年。

一个更贴近日常的例子：操作系统加载可执行文件用的就是mmap。你在Linux下跑一个几百MB的python或二进制程序，第一次执行可能只有几百毫秒，靠的完全不是“把整个文件读进内存”，而是mmap + 按需换页。你平时启动一个大型IDE那么快，背后就是mmap在撑场子。

了解了这一层，再回头看标题里的“1.2秒”，你就知道它不是玄学，只是把read落下的功课换成了操作系统早就准备好的机制。

2. 直挂权重为什么只要1.2秒：拆解这1.2秒去哪了

2.1 1.2秒里根本没有把GB级数据读进内存

先说一个最常见的误解。有人听到“mmap加载权重只要1.2秒”，脑子里自动浮现出“它用1.2秒把3GB的权重读完了”，然后开始质疑各种IO带宽能不能达到这个速度。不是这样的，方向完全反了。

mmap模式下，真正花在“读文件”这件事上的时间，不发生在加载阶段，而发生在后续推理阶段每次访问权重时。加载阶段只做两件事：把文件开起来，然后把文件映射进虚拟地址空间。这两件事的开销跟文件大小几乎无关，只跟映射本身的代价有关——建立页表映射、做一些权限校验和后续的VMA维护，通常是毫秒级。

那1.2秒花在哪里？花在Python / PyTorch层面的元数据重建上。文件里的safetensors或torch序列化权重，除了裸张量字节外还带一段JSON或数组格式的元数据头，记录每个张量的名字、形状、数据类型、起始偏移量、元素个数。直挂权重前，框架要先解析这段元数据，把几百上千个张量名字和维度关系恢复出来，再为每个张量构造Tensor对象、约定dtype和shape。这些对象创建和校验，对Python这类解释型语言来说反而是最耗时的一环。

2.2 映射建立只有毫秒级：open、fstat、mmap三连

为了验证这个说法，可以看一次典型的直挂流程拆解。第一步是open()打开文件句柄，这会触发一次路径查找和文件锁处理；第二步是fstat()拿文件大小和权限；第三步是mmap()传入fd、偏移和长度，指定MAP_SHARED或MAP_PRIVATE以及PROT_READ。

这三步在x86-64 Linux下对几个GB的文件来说基本属于“感觉不到耗时”的级别，加起来通常是几百微秒到几毫秒。为什么这么便宜？因为mmap系统调用本身只是在进程的虚拟地址空间里画一块地盘，登记一下“这块地址对应哪个文件的哪个区间”，完全没有触达磁盘数据。

有人会问：那不对吧，我见过mmap一个大文件有时候也会卡顿几百毫秒啊。这种情况多半发生在文件特别大、虚拟地址空间需要较大的VMA树维护，或者系统开启了严格的大页预留。但常规配置文件，真没那么多成本。

2.3 真正吃掉时间的：解析、构造和首次touch

真正吃掉剩余1.2秒的，是以下这些步骤：

• 打开PyTorch / safetensors文件时，读取文件头部元数据段，解析张量清单
• 为每个张量创建Storage对象、Dtype对象并校验shape合法性
• 如果张量本身带了内存对齐要求（类似64B对齐或128B对齐），需要按偏移量对齐访问
• 如果权重不只是一层，比如YOLOv11这种百层以上的结构，构造函数调用链会叠加
• 进程启动、Python解释器初始化、CUDA runtime / 设备上下文初始化，也可能占掉几百毫秒

换句话说，1.2秒里面很大一块不是“文件映射”本身，而是“把静态字节变成Python对象图”的过程。这也解释了为什么你在C++里用mmap直接拿裸指针读同一份权重，耗时能压缩到100~200毫秒——省掉的是Python对象的构造和解析开销。

2.4 冷启动和热启动的差距，可能比你想的大

同样一份权重，冷启动和热启动的差异能到3到5倍以上。冷启动指文件不在操作系统页缓存里，页缓存里没有对应数据块，第一次touch张量数据时，必须去磁盘/SSD/NVMe盘上做真实IO；热启动指之前打开过这个文件，数据已经躺在page cache里，访问时不需要磁盘IO。

所以你在监控里看到“1.2秒”，要问清楚是第几次。同一份文件，第一次冷加载可能到3秒，第二次热加载可能只有0.3秒。这不是mmap不稳定，而是page cache的命中率在起作用。我在实测中喜欢把一次服务重启后的首次加载单独记为“冷”，同进程内重新load记为“热”，两个数字分开观察。做压测和容量规划时这两个数不能混着看。

3. 实操：PyTorch、safetensors和C++里怎么直挂权重

3.1 PyTorch推理加载：一行mmap=True

现在PyTorch官方的torch.load支持mmap参数。最简单的用法是：

import torch state_dict = torch.load("model.pt", map_location="cpu", mmap=True) model.load_state_dict(state_dict)

这里的mmap=True会让torch在反序列化张量时优先使用mmap方式打开文件，而不是一次性把整个文件读进内存。对推理服务特别友好，因为推理不需要修改权重，映射为只读完全合法。如果你加载的是safetensors格式，用法也类似：

from safetensors.torch import load_file, load # 整个文件直挂 tensors = load_file("model.safetensors", device="cpu") # 或按需读取单个张量，safetensors内部就是mmap实现 tensor = load_file("model.safetensors", device="cpu")["model.layers.0.self_attn.q_proj.weight"]

注意safetensors的load_file返回的是一个字典，底层持有了映射对象。别把返回结果当普通dict乱删，尤其是当你还想用同一个映射做多进程共享时。

3.2 训练时为什么强烈不建议开mmap

我见过有人图省事，torch.load把所有checkpoint全部加了mmap=True，包括训练脚本。开头看起来没问题，loss也能正常降。但跑着跑着就开始出现奇奇怪怪的显存OOM和性能抖动。

原因出在训练场景需要反向传播，权重张量必须是可写的、真实分配在内存里的，而且是需要参与autograd记录的叶子张量。mmap直挂出来的张量本质上是文件页的只读视图，如果你想对它做in-place更新（比如Parameter.data = ...），要么触发写时复制，要么直接被SIGBUS拍死，要么由于页缓冲特性和trainer的预期完全不一致，引发张量底层存储的暗坑。

另一个隐藏问题是DataLoader的多进程模式。如果训练主进程mmap共享权重，每个DataLoader worker都继承同一个映射，那么worker在访问/修改数据时会影响页缓存状态。训练时权重每个step都要更新、写入新值，这种情况下mmap带来的按需换页机制会频繁失效，性能不升反降。

一句话总结：推理直挂，训练老老实实拷贝。

3.3 C++原生挂载：open、fstat、mmap三板斧

如果你追求的是极致速度，需要把1.2秒进一步打成几十毫秒，那就得上C++。在Linux环境下，最核心的流程固定是三步：打开文件、获取大小、映射。

#include <fcntl.h> #include <unistd.h> #include <sys/mman.h> #include <sys/stat.h> #include <cstdio> int fd = open("model.weights", O_RDONLY); struct stat st; fstat(fd, &st); size_t file_size = st.st_size; const char* base = static_cast<const char*>( mmap(nullptr, file_size, PROT_READ, MAP_SHARED, fd, 0) ); if (base == MAP_FAILED) { perror("mmap failed"); close(fd); return -1; }

映射完以后，base就是整个文件在用户态的虚拟地址。接下来你的权重解析器可以从base开头读取元数据，根据偏移量直接拿到某个张量的起始指针：

const void* weight_ptr = base + metadata["tensor_offset"]; const float* weight_data = static_cast<const float*>(weight_ptr);

到这一步，你的模型权重不是“拷贝”进来的，而是直接把地址指到了文件映射区内。后面只要你不对这块内存做修改，这份权重就永远不会独占常驻内存，也省掉了一次完整的文件拷贝。配合稀疏推理或者按层调度，还能做到只touch需要的层，连“加载”过程都进一步压缩。

3.4 别忘了madvise：操作系统的预读你还可以再抢救一下

直挂之后还有一个容易被忽略的系统调用：madvise。它用来告诉内核“你这块映射，我接下来会怎么访问”，内核会据此调整预读策略和页回收优先级。

如果推理前明确知道要按顺序把权重全部读一遍，可以主动声明顺序访问：

madvise(base, file_size, MADV_SEQUENTIAL);

如果推理是随机访问各层权重，则用：

madvise(base, file_size, MADV_RANDOM);

这里多花一行代码的价值在于：MADV_SEQUENTIAL会预热页缓存，按顺序提前fetch后面的页；MADV_RANDOM则让内核果断放弃预读，避免白白把不需要的页拉进page cache。我遇到过一种场景，模型权重有几层在推理时永远用不到，但默认预读策略把整个文件都拉进了page cache，白白占掉几个GB的物理内存。加上madvise之后，内存占用肉眼可见地降了下来。

4. 直挂之后，系统怎么处理按需加载和共享

4.1 访问第一个权重元素时发生了什么

直挂mmap只完成映射，不完成加载。你何时触发真正的IO？答案是你第一次去读映射区地址的时候，比如代码执行到某个算子的weight指针访问。这一刻CPU把虚拟地址翻译给MMU，MMU在页表里查不到对应物理页，抛一个缺页异常，内核接管，从文件偏移处读一页（通常4KB）进物理内存，更新页表，返回用户态。你的代码毫无感知，但第一个权重元素的访问背后在这个瞬间已经发生过一次真实的磁盘IO。

如果文件本身刚好在page cache里（比如你刚下载完、或者前一次映射还热着），那么这次缺页不需要走磁盘，直接从系统缓存里取，时间可以快几个数量级。

这个机制有一个很实在的好处：如果你的推理只用了模型的前半部分，后半部分权重映射进来了但从未访问，就永远不占物理内存。大模型做投机采样、逐层调度或部分层量化评估时，这个特性可以把内存效率拉满。

4.2 多个进程共享同一份页缓存

mmap还有另一个宝藏特性：多个进程映射同一个文件时，操作系统会尽量让大家共享同一份物理页。换句话说，你起了8个推理worker，每个worker都mmap同一个几个GB权重文件，物理内存里可能只有一份权重页，大家共享读，而不是各自复制一份。

这一点在多Worker推理、灰度发布和多模型共存的环境中价值很大。平时你用read加载，每个进程都有一份私有的用户态副本，4个worker就吃4倍内存；用mmap，4个worker吃的大概是1倍权重空间加上少量页表开销。

需要注意的是，MAP_SHARED意味着一个进程对映射区的修改对其它进程可见。推理场景通常只读，没问题。但如果你不小心在某个worker里对映射区写了东西，相当于污染了所有worker共享的那份页缓存。所以做共享映射时，务必保证映射区始终只读，别给自己埋雷。

4.3 显存占用为什么看起来“很怪”

经常会有人在推理时打开nvidia-smi，发现显存占用忽高忽低，甚至模型刚加载完显存占用反而不高，等第一轮推理跑起来才突然飙高。这就是后续按需加载导致的：映射区在主机内存里的页是慢慢touch出来的，但CUDA张量一旦加载，框架会把权重拷贝到显存，正常显存占用其实还是会涨起来。

不过在Device-to-Device的场景里有个坑：如果你的推理框架支持“设备侧稀疏加载”，比如tensor并行只在特定层间切换，那么框架可能不会提前把全部权重搬到显存，而是在推理到那一层时才触发一次HtoD拷贝。于是nvidia-smi看起来就是宽幅波动的，监控系统如果按平均占用报警，容易误报。这种情况不是bug，是直挂机制的正常副作用，报警阈值要根据峰值设计，不能用均值。

5. 实际踩坑记录与问题速查表

5.1 磁盘闪断、文件被替换引发SIGBUS

mmap最怕的一种死法：文件在映射期间被外部操作截断或删除，然后你的进程再去访问映射区里未加载的那段地址。此时内核发现文件页已经“不存在”，无法把物理页分配给你，处理缺页失败，直接向进程发SIGBUS信号。如果你没有信号处理器，整个服务当场崩掉。

我吃过一次大亏：线上有个服务在推理过程中，隔壁离线任务把权重文件滚动更新，文件名没变，但底层inode换了，映射区朝旧文件的那部分访问立刻炸了。后面加了两重保障：一是发布流程里禁止原地覆盖权重文件，二是进程启动时对权重文件做一次打开后持有fd，整个生命周期不再按路径重新打开，从源头隔离外部更新。

5.2 训练过程中对mmap张量做in-place更新

有同事在训练脚本里用mmap加载预训练权重，然后又执行了类似param.data += 0.1的操作，程序报错很诡异，类似“RuntimeError: Inference tensors cannot be saved for backward”。排查后定位到，mmap出来的张量被视为inference-only张量，不参与自动求导图的保存。

即使你绕过报错，硬对这个映射区做修改，你改的还是共享页缓存里的同一块物理页，这对多进程共享或者后续重新load会产生难以排查的数据污染。训练场景，老老实实把权重copy到独立内存里，别拿mmap搞骚操作。

5.3 模型并行场景下madvise互相伤害

做多卡tensor并行时，每个rank通常都会映射同一份权重文件。如果某个rank在某个时间点调用了madvise MADV_DONTNEED，告诉内核“这块我暂时不用的页可以回收”，后果是内核把共享的物理页回收掉，同一物理页在其它rank的映射里也不可用了。其他rank下次访问时只能再次触发缺页从磁盘拉取，白白增加一段莫名卡顿。

所以在多进程共享映射搭配随机访问的应用里，没有把握就别乱加madvise。如果确实需要释放某些层的页缓存，先评估它是不是也被别的rank共享着，否则你释放一次，全员跟着付一次缺页的代价。

5.4 小文件和机械硬盘下优势不明显

mmap也不是万能的。文件只有几MB甚至几百KB时，mmap的页表建立、VMA维护和缺页处理开销，可能比一次痛快的read还大。我实测过跑YOLO小模型（权重文件不到20MB），read加载和mmap加载的差距基本在误差范围内，没必要折腾。

在机械硬盘上，随机IOPS很差，按需加载会导致大量小粒度随机IO，比顺序read的吞吐差很多。SSD和NVMe盘则对随机读非常友好，几乎不用太担心。所以如果你还在用HDD跑推理，先换盘可能比研究mmap参数更见效。

6. 想自己验证1.2秒：给一套压测方法

6.1 三组对比实验就能把账算清楚

别光听我说，自己动手测最靠谱。复现的核心设计是三组实验读同一个几GB权重文件：

# 1. read直读整文件，统计耗时 time python -c " import torch state_dict = torch.load('model.pt', map_location='cpu') print('read加载完成') " # 2. mmap仅映射，不touch任何数据 time python -c " import torch state_dict = torch.load('model.pt', map_location='cpu', mmap=True) print('mmap映射完成') " # 3. mmap映射完，再全量touch一遍，模拟推理前全部读一遍 time python -c " import torch state_dict = torch.load('model.pt', map_location='cpu', mmap=True) for name, tensor in state_dict.items(): tensor.sum() print('mmap全量touch完成') "

第一组的耗时基本等于“文件全量读进内存 + 序列化解析”，第二组的耗时大致是你今天关心的“1.2秒”——只有映射和对象重建，第三组则是“映射 + 真实IO全量加载”，时间会比第二组高出很多。

这三组数据跑完，你就能区分开哪些时间花在基础设施上，哪些是文件数据的真实搬运成本。以后别人再问“为什么mmap直挂权重只要1.2秒”，你可以直接把三组时间甩过去，比讲一百句原理都管用。

6.2 关键看三个指标：major fault、minor fault、IO吞吐

时间只是表象，想定位瓶颈还得看系统指标。Linux下可以用perf stat或直接读/proc/self/stat里minflt和majflt两项，分别表示“minor fault”（物理页已在页缓存中，无需磁盘IO）和“major fault”（需要从磁盘读页）。

• mmap映射阶段结束时，如果你的major fault是0，说明映射没有触发真实磁盘IO，完全符合预期
• 首次推理时如果有大量major fault，说明权重页是逐个从磁盘拉上来的，这时候磁盘吞吐决定了真实耗时
• 如果热启动阶段major fault接近0，说明page cache全部命中，时间可以压到极低

我经常用pidstat -r和iostat两个命令左右对照。前者看进程的整体minor/major fault趋势，后者看磁盘设备层的实际读吞吐。两个指标配合，能迅速定位时间是卡在缺页排队还是卡在序列化解析。

6.3 什么时候这个数字会被打破

1.2秒不是常量，它随时可能被打破。文件从几个GB涨到几十GB时，即使映射本身不随大小线性增长，元数据解析也可能变慢；扩展名和Header设计不好，解析器扫描时间会明显上升。

另外，如果模型文件是加密的或在网络文件系统上，映射建立后每次缺页都可能带着解密或网络RTT的开销，按需加载的隐性成本会陡增。这种情况下不如一次性read进内存，把加密/网络的数据块拉回本地连续解密，更可控。

要稳住这个数字，核心在于两个点：一是权重文件格式本身要设计成“元数据头 + 对齐张量块”的布局，尽量减少文件头解析损耗；二是尽可能把文件留在操作系统page cache中，不要在进程生命周期里频繁清理缓存或反复触发DONTNEED。

7. 说点我自己的操作体会

照着上面的方法，我把手头的推理服务从几十秒冷启动压到稳定1.2秒之后，印象最深的一点是：大部分时间根本不是花在“读文件”上，而是花在“解析和构造对象”上。所以如果你也在优化模型加载，别一上来就怀疑磁盘不行、网络不行，先用我上面给的三组实验把耗时的构成拆开，再做针对性的优化。

另外一个很实用的经验：进程起来后，趁空闲把权重文件提前mmap并touch一遍，宁可在初始化时多耗一点流量，也不要让第一个推理请求来承担缺页风暴。我现在的做法是在服务启动后、对外宣告就绪前，先对映射区做一次MADV_SEQUENTIAL配合全量touch，把这个预热成本固定显式化，而不是让用户请求的第一个batch去撞枪口。这样4个9的SLA守护下，监控曲线也好看很多。

mmap直挂权重这件事，底层原理不复杂，但实操中的坑确实不少。如果你也刚上手，建议从推理服务的小流量灰度开始改，观察冷启动耗时、物理内存占用和page cache命中率三个指标，稳了之后再放量。后面我还会记录怎么把这份权重文件的格式本身也优化一下，从直挂进一步做到“部分层懒加载、按请求加载单层权重”，到时候再继续写。