airllm大模型推理：用内存映射与逐层调度突破显存瓶颈-平芜编程栈

1. airllm 到底是个什么东西：显存不够时的另一种解题思路

先说我当时的处境。手里只有一张显存不那么宽裕的卡，跑 7B 模型勉强能塞下，想碰一碰更大规模的模型时，显存直接爆掉。换卡不现实，租服务器又是一笔开销。正当我在各种量化方案里打转的时候，看到了 airllm 这个项目——它走的完全不是缩小模型这条路，而是把模型权重放在磁盘和内存里，层层调度着喂给显卡。

这个思路给我的第一反应是：这也能行？但实际跑下来，它确实解决了一个非常关键的问题——不是跑的有多快，而是能不能跑起来。

airllm 从名字就能看出来，它关注的是让大语言模型推理这件事，不再被显存死死卡住。它把 Hugging Face 生态里的模型以内存映射的方式加载，而不是整块塞进显存。你在代码里的体验很接近通用的模型加载方式，但真正发生的内存调度逻辑完全不同。对于像我这样既想用大模型做实验、又不想在基础设施上大出血的人，它是一个很值得放进工具箱的选项。

1.1 大模型的内存大头，几乎都压在权重上

要理解 airllm 在解决什么问题，先得明白大模型跑起来时，显存都被谁吃了。

一个模型在推理时，显存里的东西主要有三块：模型权重、中间激活值、KV Cache。对于一个 7B 模型，半精度权重大约是 14GB，激活值和 KV Cache 取决于输入长度和 batch size，但相对权重来说往往是小头。到了 70B 这个级别，半精度权重直接到 140GB 左右，在消费级显卡上基本不可能整块放进去。

所以传统做法只有几条路：要么缩小权重（int8、int4 量化），要么把模型切开放在多张卡上，要么干脆用 CPU 硬扛。每条路都有代价。量化要处理精度损失和兼容性，多卡部署增加成本和复杂度，纯 CPU 推理则是直观的慢。airllm 选的是另一个方向——既然显存放不下整个权重，那我一次就只放一层到显存，算完这层就换下一层，磁盘和内存就是权重的"仓库"。

1.2 airllm 的核心取舍：用时间换空间

这听起来美好，代价也很明显：速度。

正常的 GPU 推理，权重常驻显存，前向传播是流水线一样往下走。airllm 的做法相当于每过一个 Transformer 层，都要从"仓库"把这一层的权重搬进显存，算完再搬走，换下一层。多了一层磁盘/内存到显存的搬运，推理速度自然上不去。

用生活里的例子打个比方：全量显存推理就像是把整本书摊开在桌面上，翻哪里都只要动一下手；airllm 则是把书放在书架里，每次只拿一页到桌面读，读完放回去再拿下一页。你要读完整本书，多花的时间全在来回取放上。

但反过来看，这个取舍非常聪明——它牺牲的是速度，换回来的是"能跑"。特别是在我这种只想验证一个模型效果、跑几个 prompt 的场景里，慢一点完全可以接受，真正不能接受的是连试都试不了。

1.3 哪些人适合先试它，哪些人别在这上面浪费时间

我建议这几类人可以直接试 airllm：

手里只有单张低显存显卡，但又想跑比显存大得多的模型；
想在本地快速验证一个开源大模型的效果，不想先折腾量化流程；
对显存的存量感兴趣，想搞明白权重调度和内存映射是怎么回事。

反过来，下面这些需求就别指望 airllm 了：

高并发服务：同一时间几十个请求进来，airllm 单进程推理的速度会把你拖垮；
低延迟交互：每生成一个 token 要几秒，聊天体验基本没法看；
训练或微调：airllm 不是为梯度计算设计的，反向传播的内存需求它扛不住。

把这个边界想清楚，你就能判断它对你有没有用。反正对我来说，它像一个应急方案——显存不够时，让我能先把模型跑起来再说。

2. 把磁盘当成显存的延伸：内存映射与逐层调度原理

airllm 能跑起来，靠的不是魔法，而是两个底层机制：内存映射（mmap）和逐层权重调度。搞懂这两点，你就明白它为什么快不了，也明白为什么它能把显存压得那么低。

2.1 权重文件先搞清楚：模型大，大头在权重上

先看大模型权重在磁盘上是什么样。现在主流的模型权重打包格式里，一个模型通常对应一个或几个二进制文件，里面存的就是所有层的权重张量。这些文件往往有几个 GB，70B 级别的模型要上百 GB。

正常代码里加载模型，会比较粗暴地把整个文件内容读进内存，再通过框架的 API 把权重发到显存。这样做的问题在于，内存和显存都要有足够空间，缺一个都不行。airllm 的不同在于，它不着急一次性读完文件，只用 mmap 把文件映射到进程的虚拟地址空间里，操作系统在真正访问某个页时才会从磁盘读入。

2.2 mmap 的省内存逻辑

mmap 不是新东西，操作系统很早就提供了这个机制。它最核心的价值是：文件不需要通过 read/write 这些系统调用去"复制"到用户态内存，而是直接让你操作一块由文件支撑的虚拟内存。

这句话听起来抽象，我换个方式说。普通读文件，相当于你把书里的内容一笔一笔抄到自己的笔记本上；mmap 则像是你给书做了一个书签索引，你翻开哪页，那页才真正放到你眼前，书本身还是放在书架上。对内存来说，这意味着如果程序只是逻辑上"看过"某个位置，不一定真把那一页读进物理内存，因为映射是惰性的、按页加载的。

对应到 airllm 的场景：它把模型权重文件这么一映射，进程的虚拟地址空间里就有了完整权重"看起来都在"的样子，但物理内存里只放真正访问过的页面。于是你不需要先准备好 140GB 物理内存，再去读一个 140GB 的模型文件。

2.3 前向过程里的逐层搬运

有了 mmap，权重文件可以被灵活读取了，但要让显存只放下少量权重，真正的关键是"一层一层地算"。

一个标准的 Transformer 模型，结构是一堆重复的层堆叠起来的。从前向传播的角度看，输入先经过第一层，把结果传给第二层，第二层算完再传给第三层，依此类推。每一层都需要自己的权重，整层权重加载完才能开始算。

airllm 的做法就是钻了这个空子：既然层与层之间是串行的，那我完全可以让某一层的权重只在它执行前向的那一刻出现在显存里。具体来说，代码层面对每一层做的事情可以简化成下面几步：

判断当前层的权重是否已经在显存里；
如果没有，用 mmap 去权重文件里把这一层的张量找出来，发到显存中一块临时的显存区域；
让输入过这一层，做矩阵乘法和注意力计算，得到中间结果；
前向结束后把这一层临时占用的显存释放掉；
拿着中间结果去下一层。

这么循环下来，显存里永远只有"正在计算的那一层权重"加上激活值和 KV Cache。权重最大的那一部分被摊到了时间轴上，而不是空间轴上。这也是为什么模型越大，跑得越慢——每多一层，就多一次调度的开销。

2.4 三种方案的直观对比

我把全量 GPU 推理、airllm、纯 CPU 推理放在一张表里对照一下，哪个环节花销在哪里就很清楚。

维度	全量 GPU 推理	airllm	纯 CPU 推理
权重存放	常驻显存	磁盘/内存映射，逐层进显存	常驻内存
显存需求	极高	低	很低
内存需求	中	高（激活、缓存、映射页）	很高
单轮速度	最快	慢	最慢
延迟稳定性	稳定	逐层取放，抖动明显	取决于内存带宽
适合场景	生产服务、高并发	实验、低显存试跑	老机器救急

airllm 处在中间位置：显存压力大幅下降，内存有一定压力但比纯 CPU 那种什么都堆内存里要轻，速度则介于两者之间。它本质上是在"显存够不够"和"速度够不够"之间找了一个新的平衡点。

2.5 为什么慢是必然的：生成阶段每一层都要重新"拿一次权重"

还有一个很多人没注意到的细节：为什么 token 生成阶段会更慢。

大模型生成是逐 token 的。输入 prompt 时是预填充阶段，一整段 prompt 一起过模型；之后每出一个新 token，就要把已经生成的整个序列再跑一遍前向。对 airllm 来说，这就意味着每生成一个 token，所有层都要再轮一遍，每一层都要重新从 mmap 里把权重搬到显存。

全量显存推理没有这个问题，因为权重一直就在那里。airllm 每轮都要来回折腾，所以生成速度会比预填充明显慢。我在实测里感受到的"一个字要等好几秒"，根源就在这里。理解了它，你以后看到数据不会奇怪，也更清楚该怎么调参。

3. 从零跑通 airllm：环境、代码与实测数据

原理理解了，剩下就是动手。这一部分我把完整的操作过程写下来，包括环境怎么准备、代码大概长什么样、以及怎么观察显存和速度变化。

3.1 环境准备：硬盘、内存、系统，一个都不能少

先说系统。airllm 的 mmap 方案在 Linux 下面最省心，我建议你用 Linux 发行版，或者用 WSL 也可以。Windows 下文件锁和权限问题比较折腾，后面踩坑章节我还会细说。

接着是硬件三件套，按重要性排：

硬盘：模型文件本身有多大，就要准备多大空间，最好再留出跟模型差不多大小的额外空间，因为首次使用可能会有转换缓存。SSD 是底线，机械硬盘会让调度等待放得更大；
内存：虽然 mmap 是惰性加载，但跑起来后实际访问的页面还是会进入内存。以我的经验，跑 7B 级别模型，建议至少 16GB 内存；跑更大的模型，内存最好往 64GB 以上走。内存不够会很早就开始 swap，速度直接崩；
显存：这是 airllm 帮你削减的部分。我实测过 6GB 显存跑一个 70B 级别的开源模型，能正常生成，但每一步都很漫长。显存当然还是越大越好，因为激活值和 KV Cache 还是需要放一放。

安装很简单，依赖也不复杂：

pip install airllm

如果网络条件不好，可以配置国内镜像源加速安装，这个按你自己的环境来。

3.2 最简单的推理脚本

装完之后，核心 API 非常接近你习惯的方式。不同版本接口略有差异，我用的版本大概是这样的结构：

import torch from airllm import AirLLMLlama2 from transformers import AutoTokenizer model_id = "./some-open-model" tokenizer = AutoTokenizer.from_pretrained(model_id) model = AirLLMLlama2.from_pretrained( model_id, compression="fp16", # 权重精度：fp16 / int8 / int4 dtype="fp16", device_map="cuda" ) model = model.to("cuda") prompt = "请用一句话解释什么是内存映射" inputs = tokenizer(prompt, return_tensors="pt").to("cuda") with torch.no_grad(): output = model.generate( inputs.input_ids, max_new_tokens=64, do_sample=True, temperature=0.7 ) print(tokenizer.decode(output[0], skip_special_tokens=True))

注意几个点。第一，from_pretrained里我传的是本地路径，因为建议你先把权重库整体下到本地，再用路径映射。第二，compression参数控制权重精度，第一次跑完想测显存极限，可以先不动。第三，如果你的版本里没有AirLLMLlama2这个类，去看看AutoModel，新版往往把入口统一到那里了，用法差不太多。

3.3 观察显存和耗时：别只盯着"能不能跑"

我每次跑这类东西，都喜欢先把观测工具挂上，不然你会搞不清楚瓶颈到底在哪。

开一个终端跑watch -n 1 nvidia-smi，实时看显存占用；另一个思路是在代码里直接打印：

import torch def print_mem(tag): allocated = torch.cuda.memory_allocated() / 1024**3 reserved = torch.cuda.memory_reserved() / 1024**3 print(f"{tag}: allocated={allocated:.2f}GB, reserved={reserved:.2f}GB") print_mem("before forward") # ... forward / generate ... print_mem("after forward")

我实际跑下来的一组参考数据（低显存卡 + 大模型），大致是这样：

阶段	显存占用	单次耗时
模型加载后	约 3.8GB	首次加载 5～10 分钟
预填充阶段	峰值约 4.2GB	prompt 越长越久
单 token 生成	峰值约 4.2GB	约 3～6 秒

这个数据只是参考。同样一个模型在不同卡上、不同max_length下，差距会很大。我测完最大的感受是：显存确实压住了，但时间成本非常真实。你要有心理准备。

3.4 max_length 和生成参数的实际影响

很多人觉得显存不够，于是把max_new_tokens调得很小，这是对的，但还不够。

KV Cache 的大小跟序列长度直接相关，而 KV Cache 在 airllm 下也不会全部塞进显存，一部分还是占内存。我的建议是，先做一个小实验：固定 prompt，分别设max_new_tokens为 16、64、256，观察显存和内存的变化曲线。你会看到序列越长，资源占用上升得越明显，而且生成时间也越长。

实际使用里，我倾向于把max_new_tokens压到够用就行，比如 64 到 128。do_sample可以开，但温度别调太高，否则长文本下容易出现重复输出。这些不是 airllm 特有的问题，但在这个很慢的环境里，每一步成本都比平时高，所以值得提前把它控制好。

4. 踩坑记录：从段错误到内存爆掉的完整排查链路

airllm 用起来不算复杂，但坑也不少。我在折腾过程中踩了好几个，每个都花了不少时间，这里把完整排查链路写出来，希望对你有帮助。

4.1 权重文件被移动，进程直接 SIGBUS

我第一次遇到的是崩溃得特别莫名其妙的场景：模型跑得好好的，之后我把模型目录挪了一下位置，再启动代码，进程直接秒退，什么错误栈都没留下。

这个现象非常典型——SIGBUS（总线错误）。原因是 mmap 映射的是文件，当你把文件移走或者删掉，映射所依赖的文件区域已经不在原来的位置，进程访问到那一页时，操作系统没法把它换入内存，直接给进程一个严重信号。

排查链路：

先确认是不是段错误：在 bash 里跑程序，看退出码是不是 139（128 + 11，即 SIGSEGV）或者 135（SIGBUS）；
用dmesg | tail -20看内核日志里有没有 bus error 相关记录；
检查模型文件是否还在原来路径：ls -l ./some-open-model；
检查磁盘空间是否满了：df -h。

解决方式很朴素：给模型目录一个固定位置，不要轻易移动；保证磁盘有足够空间；如果使用的是解析出来的软链路径，确认每次启动都解析到同一个真实路径。

4.2 显存没满，内存反而先爆了

另一个让我挠头的问题是，显存显示还有富余，但整个系统越来越卡，最后某一个进程报 OOM。当时我第一反应是代码写错了，搞得张量没释放。

后来观察下来，问题出在三个地方叠加：

mmap 页面的换入：权重文件虽然不占物理内存，但前向传播访问过哪些页，这些页就会真正进入内存。层数一多，访问过的页面越来越多，物理内存的 RSS 会持续上涨；
中间变量和 KV Cache：长序列下的中间张量、注意力缓存，该占的内存一点也不会少；
转换缓存：首次跑某些模型时，airllm 可能会对权重做分块处理，中间的缓存文件或内存对象很占资源。

排查的时候别只盯nvidia-smi，要看free -h和top。我那次就是显存还剩下 2GB，内存已经压到 90% 了。

解决思路：

把max_new_tokens和max_length降下来，KV Cache 是最大的变量；
限制进程并发数，别在后台开着别的重型任务；
有条件就扩大物理内存，或者至少准备足够的 swap 兜底，但依赖 swap 会让速度更惨。

4.3 第一次加载像卡死，第二次却飞快

有一个现象特别容易让人误判成"程序死锁"：第一次初始化某个大模型，终端里啥信息都没有，CPU 占用却能看到在动，但等了好几分钟也没反应。

这不是 bug，而是首次使用需要完成一些前置工作，比如把权重文件整理成便于 mmap 访问的格式、生成转换缓存等。等第一次跑完，第二次启动会明显快很多。

我当时的处理方式很简单：跑一次最小脚本，让它从头到尾把初始化流程走完，确认缓存目录出现新文件，再正常去跑真实任务。中间不要 Ctrl+C，否则缓存写了一半，反而可能留下脏数据。

判断是不是真卡死的办法：用top看进程 CPU 状态，如果一直在变化，说明正在干活；如果完全睡眠且 I/O 也没有，才是真的卡住。

4.4 Windows 环境与多实例并发的问题

如果你非要在 Windows 下用，我建议优先开 WSL。Windows 自带的环境里，文件映射的权限、路径解析和 Linux 有差异，出现问题时的报错也经常不直观。我印象最深的坑是路径带中文或空格，mmap 某些实现直接拒绝映射，报错完全不提示原因。

另外，airllm 是为单进程单模型设计的工具。我在机器上试过同时开两个进程加载同一个大模型，结果两个进程都在抢内存和磁盘 I/O，显存倒是没爆，但整个系统被拖成一个慢动作。如果你确实需要同时服务多个请求，不要指望 airllm 扛，换个更合适的推理框架才是正事。

5. 选型判断与后续扩展：什么时候继续用，什么时候换方案

airllm 能帮你把模型"跑起来"，但真正要用好它，还需要你清楚它的边界，以及怎么和其他工具配合。

5.1 compression 参数应该怎么选

compression是 airllm 里一个值得研究的参数。我实测过几种配置，简单总结如下：

配置	显存占用	精度	适用情况
fp16	较高	最高	显存能挤一挤，追求准确输出
int8	中等	中高	显存有限但仍想保留效果
int4	较低	中低	显存极致紧张，能接受输出质量下降

从我的经验看，如果模型本身不大，优先用 fp16。当你确定显存真的不够了，再往 int8 甚至 int4 降。有一点要注意：压缩等级不同，模型的输出风格和细节都可能变化，最好实际拿几条 prompt 对比一下，别只看显存数字。

5.2 和量化推理、C++ 推理后端对比

airllm 不是唯一的低显存方案。市面上还有更偏量化的路线，以及把推理逻辑用 C++ 重写、配合分页注意力机制的方法。它们之间的区别在哪？

量化路线：把权重压成更低精度，整个塞进显存。优点是速度仍然快，缺点是你要面对量化过程中的精度损失和兼容性问题；
C++ 推理后端：通常要转换模型格式，换推理 API，但吞吐和延迟远好于 airllm。适合确定要上生产服务的情况；
airllm：最接近"原生模型体验"，API 跟平时写模型脚本差不多，上手快，但性能和并发是硬伤。

我个人把它定位成"试玩层"和"应急层"。在新模型发布后，我往往先用 airllm 跑几个例子，看看模型能力是不是符合预期。确认值得继续用，再做量化和部署层面的细化工作。这样不会一开始就陷入格式转换和参数调优的泥潭。

5.3 我现在的使用习惯

折腾完这一圈，我的做法已经稳定下来：所有低显存场景，airllm 先进场把模型跑通，确认效果后，再根据需求决定下一步。

比如我在评估一个新开源模型时，流程是这样的：

下载权重到本地固定目录；
用 airllm 写一个试跑脚本，跑 5 到 10 条不同领域的 prompt；
观察显存曲线、内存峰值和生成速度，判断这台机器到底能跑到什么程度；
如果模型效果值得继续用，再考虑量化、分页注意力后端，或者分布式方案。

这四步做完，基本不会出现"模型试跑时一切正常、一上量就崩"的尴尬。

对我来说，airllm 最宝贵的不是它跑得多快，而是它把"尝试一个超大模型"的门槛降到了一个很低的位置。你不需要先砸钱买大显存，不用一开始就陷入复杂的工程流程，就能先验证想法本身。等你真的需要高性能推理的那天，再回头优化也不迟。

airllm大模型推理：用内存映射与逐层调度突破显存瓶颈