AirLLM：单卡24G显存跑70B大模型的逐层加载方案

1. 单卡跑大模型这件事，到底卡在哪

第一次看到 airllm 这个项目名的时候，我正蹲在一台只有单张 24G 显存的机器前发愁。手里有个 70B 级别的模型想跑推理，结果加载权重那一步就直接爆显存，连模型的门都没进去。相信不少做本地推理的朋友都遇到过这个场景：模型文件下载下来七八十 G，显卡显存却只有二三十 G，甚至更少，于是要么放弃，要么去租多卡机器，成本一下就上去了。

airllm 这个项目要解决的就是这个非常具体的痛点——让大模型在单张消费级显卡上跑起来，哪怕显存远小于模型体积。它的核心思路不是去压缩模型精度，也不是搞什么量化黑魔法，而是把推理过程拆开，让权重按需从内存或磁盘加载，用完就释放，从而把显存占用压到一个很低的水平。说白了，它做的事情是"用时间换空间"，把原本必须一次性塞进显存的权重，变成一层一层地流式加载。

这篇文章适合谁看？如果你手头只有一张普通显卡，想跑一些参数量比较大的开源模型做实验、做推理验证，又不想折腾多卡环境，那 airllm 值得你花时间研究。如果你只是想跑个 7B 小模型，那其实用不上它，常规加载方式就够了。另外，对推理性能有极致要求的生产场景，这个方案也不是首选，它的定位更偏向"能跑起来"而不是"跑得飞快"。下面我会从设计思路、核心原理、实操步骤到踩坑经验，完整地拆一遍。

2. 核心设计思路拆解：为什么是分层加载

2.1 大模型推理的显存到底被谁吃掉了

要理解 airllm 的价值，得先搞清楚推理时显存都被什么占用了。一个 Transformer 大模型在推理阶段，显存开销主要分三块：模型权重本身、激活值（中间计算结果）、以及KV Cache。其中权重是最大头，一个 70B 的模型如果用 FP16 存储，光权重就要 140G 左右，这还没算上任何中间计算的开销。

传统做法是把整个模型一次性加载到显存里，然后前向传播。问题就在于，权重是静态的，它在整个推理过程中一直占着显存，但每一层真正参与计算的时刻其实很短暂。也就是说，绝大部分时间里，大部分层的权重只是"躺"在显存里占地方，并没有被用到。airllm 抓住的就是这个时间差——既然每层权重只在它那一层计算时才需要，那为什么不让它算完就撤，下一层再加载进来？

这个思路和操作系统的虚拟内存有点像。你的电脑物理内存可能只有 16G，但照样能打开几十 G 的程序，靠的就是把不常用的数据换到磁盘上，需要时再换回来。airllm 对模型权重做的就是类似的事情，把"当前不需要的层"放到内存甚至磁盘，只把"正在算的那一层"搬进显存。

2.2 分层加载与量化的取舍逻辑

airllm 的核心机制是逐层加载（layer-by-layer loading）。它把模型按 Transformer 的层切开，推理时一层一层地加载权重、计算、释放，再加载下一层。这样一来，显存里同时存在的权重最多只有一两层，占用自然就下来了。

但这里有个绕不开的取舍：加载本身是有成本的。如果每一层都要从磁盘读，那磁盘 IO 就会成为瓶颈，推理速度会慢得让人抓狂。所以 airllm 在实现上做了几件事来缓解这个问题。第一，它支持把权重放在内存里而不是磁盘，内存的读取速度比磁盘快几个数量级，只要你的内存够大，就能显著提速。第二，它引入了量化选项，可以把权重压到 4bit 甚至更低，这样不仅显存占用更小，加载的数据量也大幅减少。

我实测下来，量化这一步对速度的影响非常直接。同一个模型，FP16 加载和 4bit 加载，后者不仅显存占用降到四分之一左右，加载耗时也明显缩短。当然，量化会带来一定的精度损失，这个后面会细说。选择哪种方案，取决于你更在意"跑得动"还是"跑得准"，以及你手头的内存和磁盘速度。

2.3 和常规量化方案的本质区别

很多人会问，既然都是省显存，那 airllm 和 GPTQ、AWQ 这些量化方案有什么区别？这是个好问题。量化方案的核心是降低每个参数的存储位宽，比如把 FP16 压成 INT4，模型体积直接缩小到四分之一。但量化之后，整个模型还是要一次性加载进显存，只是体积小了。如果你显存实在太小，量化到 4bit 还是装不下，那就没辙了。

airllm 走的是另一条路，它不改变参数的位宽（当然也可以叠加量化），而是改变权重的驻留策略。哪怕模型是 FP16 的，它也能通过逐层加载让显存占用降下来。所以这两者是正交的，可以叠加使用：先用 4bit 量化把模型压小，再用 airllm 的分层加载进一步降低峰值显存。这种组合拳在实际操作中很常见，尤其是显存特别紧张的时候。

理解了这个区别，你就能明白 airllm 的适用边界：它适合"显存装不下完整模型"的场景，而不是"模型能装下但想跑更快"的场景。如果你的显存本来就够，那用常规加载方式性能会更好，没必要引入分层加载的额外开销。

3. 核心细节解析与实操要点

3.1 环境准备与依赖安装

动手之前，先把环境理清楚。airllm 是个 Python 库，安装本身不复杂，但它对底层依赖有一定要求。基础环境需要 Python 3.8 以上，PyTorch 是必须的，而且要和你显卡的 CUDA 版本匹配。我建议用虚拟环境隔离，避免和系统里其他项目的依赖打架。

# 创建并激活虚拟环境 python -m venv airllm_env source airllm_env/bin/activate # Windows 用 airllm_env\Scripts\activate # 安装 PyTorch，注意根据你的 CUDA 版本选择对应命令 pip install torch --index-url https://download.pytorch.org/whl/cu118 # 安装 airllm pip install airllm

这里有个细节要注意：PyTorch 的版本和 CUDA 版本必须匹配，否则会出现"显卡识别不到"或者"算子不支持"的问题。我踩过一次坑，装了个 CPU 版的 PyTorch，结果跑起来慢得像蜗牛，排查半天才发现是装错了包。装完之后用torch.cuda.is_available()验证一下，返回 True 才算正常。

另外，如果你打算用 4bit 量化，还需要装bitsandbytes和accelerate这两个库。量化相关的功能依赖它们，缺了会直接报错。磁盘空间也要提前规划好，模型权重加上缓存，动辄上百 G，别到时候下到一半发现空间不够。

3.2 模型加载的关键参数

airllm 的 API 设计得比较简洁，核心就是加载模型和调用生成两步。但简洁不代表没有门道，几个关键参数直接决定了你能不能跑起来、跑得多快。

from airllm import AutoModel # 加载模型，指定压缩方式 model = AutoModel.from_pretrained( "模型路径或名称", compression="4bit", # 可选 None / "4bit" / "8bit" layer_shards_saving_path="./shards", # 分层缓存目录 profiling_mode=False, # 是否开启性能分析 )

compression参数是最关键的。设成None就是原始精度加载，显存占用最大但精度最高；设成"4bit"或"8bit"会启用量化，显存占用大幅下降。我的建议是，显存实在紧张就上 4bit，能接受一点精度损失；如果显存勉强够，用 8bit 平衡一下。

layer_shards_saving_path这个参数容易被忽略，但它很重要。airllm 在首次加载时会把模型按层切分并缓存到指定目录，下次再加载就直接读缓存，省去重复切分的时间。这个目录最好放在读写速度快的磁盘上，如果是机械硬盘，首次加载会非常慢。我一般会把它指向 SSD 上的一个专门目录。

3.3 推理调用的注意事项

加载完之后就是推理了。airllm 的生成接口和 HuggingFace 的用法类似，但有几个地方需要特别留意。

input_text = ["请用一句话解释什么是机器学习"] input_ids = model.tokenizer(input_text, return_tensors="pt").input_ids generation_output = model.generate( input_ids, max_new_tokens=128, use_cache=True, return_dict_in_generate=True, ) output = model.tokenizer.decode(generation_output.sequences[0]) print(output)

max_new_tokens控制生成的最大长度，这个值设得越大，推理时间越长，因为每生成一个 token 都要走一遍完整的逐层加载流程。use_cache建议保持 True，它能缓存注意力计算的中间结果，避免重复计算，对速度有正面帮助。

注意：airllm 的逐层加载机制决定了它的推理速度天然比常规加载慢。如果你要生成很长的文本，耐心是必须的。我实测过一个 70B 模型生成 100 个 token，在单卡上要等好几分钟，这个心理预期要提前建立。

4. 完整实操流程与关键环节实现

4.1 从零到跑通的完整步骤

我把整个流程拆成可复现的步骤，你照着走一遍基本就能跑起来。第一步是确认硬件条件，显卡显存、内存大小、磁盘剩余空间都要心里有数。显存决定你能加载多大的层，内存决定缓存策略，磁盘决定首次加载的速度。

第二步是准备模型。你可以从公开渠道下载开源模型权重，注意选对格式，airllm 支持的是标准的 PyTorch 权重格式。下载完之后确认文件完整性，别下到一半断了导致权重损坏，这种问题排查起来很费劲。

第三步是配置加载参数。根据你的显存大小决定是否量化，根据磁盘情况决定缓存目录。这一步没有标准答案，需要根据实际情况调。我的经验是，先按最保守的配置（4bit 量化 + SSD 缓存）跑通，确认流程没问题，再逐步调整参数找最优解。

第四步是执行推理并观察资源占用。跑的时候开个终端监控显存和内存，看看峰值占用是多少，有没有出现内存溢出。如果显存还是爆，说明单层权重太大，需要进一步量化或者换更小的模型。

4.2 参数选择的计算过程

量化位数怎么选，其实可以算一笔账。假设模型有 N 个参数，FP16 下每个参数占 2 字节，4bit 下占 0.5 字节。一个 70B 模型，FP16 需要 140G 存储，4bit 只需要 35G 左右。但 airllm 是逐层加载的，显存里同时只有一两层，所以显存占用和总参数量关系不大，主要取决于单层的参数量。

以常见的 70B 模型为例，假设它有 80 层，那单层大约 0.875B 参数。FP16 下单层权重约 1.75G，4bit 下约 0.44G。再加上激活值和 KV Cache 的开销，单层峰值显存大概在 2-3G（FP16）或 1G 以内（4bit）。这就是为什么 airllm 能在 24G 甚至更小的显存上跑 70B 模型——因为峰值显存只和单层有关，和总层数无关。

内存方面，如果你把所有权重都缓存在内存里，那内存占用就是整个模型的大小。70B 模型 4bit 量化后约 35G，你的内存最好有 64G 以上才比较从容。如果内存不够，airllm 会退回到从磁盘读取，速度会慢很多。

4.3 实操现场记录与性能观察

我拿一台 24G 显存、64G 内存、NVMe SSD 的机器做了一次完整测试。模型选的是一个 70B 级别的开源模型，4bit 量化。首次加载时，airllm 花了几分钟做分层切分和缓存，这个过程 CPU 和磁盘 IO 都比较高，属于正常现象。

切分完成后开始推理，显存峰值稳定在 6G 左右，远低于 24G 的上限，说明还有余量。内存占用在 40G 上下波动，主要是权重缓存。生成速度方面，平均每个 token 大概几秒钟，生成一段 100 字的回复要等几分钟。这个速度谈不上快，但考虑到硬件条件，能跑起来本身就是胜利。

第二次加载就快多了，因为缓存已经建好，直接读缓存即可。所以如果你要反复用同一个模型，第一次的等待是值得的。我还试过把缓存目录放在机械硬盘上，首次加载时间直接翻了好几倍，所以强烈建议用 SSD。

5. 常见问题与排查技巧实录

5.1 显存溢出与内存不足的排查

最常见的问题就是跑着跑着报显存溢出。这时候先别急着换硬件，按顺序排查。第一，确认量化是否生效，有时候参数写错了，实际还是按 FP16 加载，显存自然爆。第二，检查是不是有其他进程占着显存，用nvidia-smi看一眼就清楚。第三，如果单层权重确实太大，那就只能进一步量化或者换更小的模型。

内存不足的表现是程序被系统杀掉，或者报 MemoryError。这时候要么加内存，要么把缓存策略改成从磁盘读。从磁盘读虽然慢，但至少能跑起来。我遇到过一次内存溢出，排查发现是缓存目录设置不当，导致权重被重复加载，修正路径后就正常了。

5.2 加载缓慢的优化思路

加载慢通常有三个原因：磁盘慢、量化没开、缓存没命中。磁盘慢是硬伤，换 SSD 是最直接的解法。量化没开的话，加载的数据量大，自然慢。缓存没命中则是因为缓存目录被清理了或者路径变了，重新切分一次就好。

还有一个容易被忽略的点是首次加载的切分开销。airllm 第一次加载模型时要做分层切分，这个操作很耗时。如果你只是临时跑一次，这个开销可能比推理本身还大。所以我的建议是，确定要长期用某个模型，就耐心等它切分完，之后就能享受缓存带来的加速。

5.3 常见问题速查表

5.4 独家避坑经验

说几个文档里不会写但实际很坑的点。第一，模型路径不要有中文和空格，airllm 底层的一些文件操作对特殊字符处理不好，路径带中文可能直接报错。第二，缓存目录要预留足够空间，切分后的分片文件加起来可能比原模型还大，空间不够会中途失败。第三，不要在推理过程中手动清理缓存，会导致加载中断。

还有一个经验是，先用小模型验证流程，再上大模型。我一开始直接拿 70B 模型试，结果各种问题混在一起，排查起来很痛苦。后来换了个 7B 模型先把流程跑通，确认环境没问题，再换大模型，问题就清晰多了。这个"先小后大"的策略，能帮你快速定位是环境问题还是模型问题。

6. 适用场景与边界判断

6.1 什么情况下值得用 airllm

airllm 最适合的场景是硬件受限但想跑大模型做验证。比如你只有一张消费级显卡，想试试某个大模型的效果，又不想花钱租多卡机器，那它就是很实用的工具。另外，做模型对比实验、跑一些离线推理任务，它也能派上用场，因为这些场景对速度不敏感，能出结果就行。

还有一种场景是学习和研究。想理解大模型推理的显存分布、逐层加载的原理，airllm 的代码是个很好的学习材料。它把很多底层机制暴露出来，比直接看框架源码要直观得多。

6.2 什么情况下不建议用

如果你的显存本来就够，那就别用 airllm，常规加载方式性能更好。如果是对延迟敏感的生产服务，逐层加载的速度瓶颈会让你无法接受。如果模型本身就不大（比如 7B 以下），常规方式轻松搞定，引入 airllm 反而是画蛇添足。

还有一个边界是批量推理。airllm 的逐层加载机制在批量场景下效率不高，因为每层都要反复加载。如果你要处理大量请求，还是得靠多卡或者更专业的推理框架。

6.3 和其他方案的组合思路

airllm 不是孤立的，它可以和很多方案组合。前面提到的量化是最常见的搭配，4bit 量化加分层加载，能把硬件门槛降到很低。另外，它也可以和 CPU 卸载方案结合，把部分计算放到 CPU 上，进一步缓解显存压力，当然速度会更慢。

从更宏观的角度看，airllm 代表了一种"用工程手段弥补硬件差距"的思路。在硬件资源有限的情况下，通过巧妙的调度和加载策略，让原本跑不动的任务跑起来。这种思路在很多领域都有借鉴意义，不局限于大模型推理。

我个人在实际操作中的体会是，airllm 最大的价值不是性能，而是降低了尝试的门槛。它让手头只有普通显卡的人也能摸到大模型，这种"能跑起来"的意义，有时候比"跑得快"更重要。当然，用之前一定要对速度有合理预期，别指望它能在单卡上跑出多卡的速度。最后分享一个小技巧：如果你的内存够大，把缓存目录设到内存盘上，加载速度会有肉眼可见的提升，这个我在多次测试中验证过，效果很稳。