GGML 中的内存映射与冷热加载机制

在大模型本地化部署和边缘端推理中，模型的启动加载耗时（Cold-Start Latency）与多进程内存开销，往往直接决定了系统的可用性体验。

如果一个 14B 参数的模型权重文件大小为 8GB，采用传统的 fread 或 read 文件 I/O 方式：

• 启动时必须由操作系统从磁盘完整读取 8GB 数据到用户态堆内存中，在机械盘或慢速固态上往往需要等待 10~30 秒；
• 如果同一台机器上启动了 3 个并发推理 Worker 进程，物理内存就会被重复占用 $8\text{GB} \times 3 = 24\text{GB}$，瞬间导致系统发生 OOM。

llama.cpp 底层的 GGML 库之所以能够做到“秒级即时启动”并支持跨进程零冗余共享，其核心在于其深度集成了操作系统的 内存映射（Memory-Mapped Files, mmap） 机制。

+--------------------------------------------------------------------------+
|                     GGUF 文件 mmap 虚拟内存映射全景                        |
+--------------------------------------------------------------------------+
| 磁盘上的 GGUF 权重文件 (8 GB)                                             |
| [ Header & Metadata ] -> [ Tensor 0 Weight ] -> [ Tensor 1 Weight ] ...  |
+--------------------------------------------------------------------------+
                                    |
                    +---------------+---------------+ (mmap 只读映射)
                    |                               |
                    v                               v
[ 进程 A 虚拟地址空间 (Virtual Memory) ]   [ 进程 B 虚拟地址空间 (Virtual Memory) ]
| ptr_0 ---> 映射到对应文件偏移量        |   | ptr_0 ---> 映射到相同物理 Page Cache  |
+------------------------------------+   +------------------------------------+
                    \                               /
                     +--------------+--------------+
                                    v (操作系统内核统一管理)
                      [ 物理 RAM: 内核 Page Cache 共享 ]

1. mmap 系统调用的物理本质：虚拟地址直连 Page Cache

mmap 并不是一种“高速读取文件的方法”，它本质上是操作系统的虚拟内存管理原语。

当 GGML 调用 mmap(NULL, file_size, PROT_READ, MAP_SHARED, fd, 0) 时：

1. 瞬间完成映射（< 1 毫秒）：操作系统内核只是在当前进程的虚拟内存空间（VMA）中划出一块大小相等的虚拟地址区间，并建立该区间与磁盘文件的索引映射，此时根本没有发生任何物理磁盘读取！
2. 所有 Tensor 指针直接解算：GGML 遍历 GGUF 文件头中的权重元数据，计算出每个 Tensor 在文件中的物理偏移 offset，并将 tensor->data = base_ptr + offset。张量的裸指针在瞬间全部就绪；
3. 按需缺页异常加载（Demand Paging）：当模型前向计算真正访问到第 5 层的权重指针时，CPU 硬件的 MMU（内存管理单元）触发缺页中断（Page Fault），内核以 4KB 页面为单位将对应的权重数据从磁盘调入物理内存的 Page Cache 中。

2. 多进程无拷贝共享（Zero-Copy Sharing）

在多实例或多容器部署场景下，mmap 带来了降维打击级别的内存节省。

由于 GGML 以 MAP_SHARED 模式打开只读权重文件：

• 操作系统内核的 Page Cache 是全局唯一的；
• 无论启动 2 个、5 个还是 10 个独立进程，它们访问的都是同一批物理内存页面；
• 8GB 的模型在物理 RAM 中永远只占用一份 8GB 空间，消除了多进程部署时的内存冗余。

3. 冷热加载调优：madvise 与预取策略

虽然按需缺页加载实现了秒开，但在首次推理时，频繁的缺页中断会导致前向计算出现卡顿。

为了平衡首字响应与内存压力，GGML 提供了基于 madvise 的内核提示机制：

// 向内核提供内存访问模式建议
#include <sys/mman.h>

void ggml_mmap_tune(void * addr, size_t length, bool prefetch) {
    if (prefetch) {
        // 提示内核：即将顺序顺序访问全量权重，触发内核激进预读（Read-Ahead）
        madvise(addr, length, MADV_WILLNEED);
    } else {
        // 提示内核：将以随机或小批量模式访问，避免过多无用预读浪费 I/O
        madvise(addr, length, MADV_RANDOM);
    }
}

• 高并发推理集群：启动时调用 MADV_WILLNEED 或利用多线程预读，将全量权重一次性全部打入 Page Cache，确保运行期没有任何 I/O 抖动；
• 边缘小内存设备：保持按需缺页加载，内核会在内存紧张时自动将未使用的只读权重页面回收到磁盘，保证系统不崩溃。

利用操作系统内核数十年来千锤百炼的虚拟内存子系统，GGML 用最少量的代码实现了最极致的资源效率。