1. 当显存成为瓶颈：airllm 要解决的真实问题
跑大模型最让人头疼的事，往往不是模型效果不好，而是根本跑不起来。你手里有一张消费级显卡，显存就那么多，想加载一个 70B 参数量的模型，光是权重按 FP16 算就要 140GB 左右，这还没算激活值和 KV Cache。绝大多数人的第一反应是"换卡"，但现实是大多数人换不起。airllm 这个项目切入的正是这个痛点：它想做的事情很朴素——让显存不够的机器也能把大模型跑起来。
它的核心思路不是去压缩模型精度到面目全非，也不是搞一套复杂的分布式推理框架，而是把"分层加载"这件事做到极致。简单说，模型推理时并不是所有层都需要同时待在显存里，airllm 的做法是让每一层在需要计算时才被加载进显存，算完就释放，下一层再进来。这样一来，显存占用从"整个模型的大小"变成了"单层的大小加上一些运行时开销"。
这个思路听起来简单，但真正落地要处理的问题非常多：层与层之间的数据怎么传递、磁盘 IO 会不会成为新瓶颈、量化怎么配合、不同模型架构怎么适配。airllm 把这些工程细节都封装好了，对外暴露的接口却相当简洁。它适合的人群很明确：手头只有一张中低端显卡、但想跑大参数模型的开发者；做模型推理验证、不想为了跑一次 demo 就租昂贵算力的人；以及想理解大模型推理内存管理机制的工程师。
我最初接触这个项目时的预期其实不高，觉得"分层加载"这种方案大概率是能跑但慢得没法用。实际用下来发现，它在某些场景下的表现比我预想的要实用得多，尤其是配合量化之后，单卡跑 70B 从"完全不可能"变成了"慢但能用"。这篇文章就把我在实际使用中摸清楚的东西完整讲一遍，包括它的原理、怎么配、哪些坑要避、以及什么情况下它并不适合。
2. 分层加载的底层逻辑：为什么显存能省下来
2.1 推理过程的时间局部性
要理解 airllm 为什么可行，得先回到 Transformer 推理的本质。一个 decoder-only 的大模型，推理时是逐层串行计算的：第 0 层的输出喂给第 1 层，第 1 层的输出喂给第 2 层，一直到最后一层出 logits。这个过程中，任意时刻真正参与计算的只有当前那一层。其他层虽然占着显存，但在这一刻是"闲置"的。
传统做法之所以把整个模型都塞进显存，是因为从显存里读数据比从内存或磁盘读快太多了，全部放显存能最大化计算效率。但这是一个"用空间换时间"的取舍。airllm 反过来做，用"时间换空间"：既然同一时刻只需要一层，那就只保留一层在显存里，其余层放在磁盘上，需要时再搬进来。
这里有个关键点容易被忽略：搬进来的开销到底有多大。一层 70B 模型的权重，按 FP16 算大概是 70B 除以层数再乘以 2 字节。以常见的 80 层结构估算，单层大约 1.75GB 左右。如果每次前向传播都要从磁盘读 1.75GB，80 层就是 140GB 的读取量，这个 IO 压力是实打实的。所以 airllm 能不能用，很大程度上取决于你的磁盘速度。
2.2 单层显存占用的估算方法
很多人关心"我这张卡到底能不能跑某个模型"，这里给一个粗略的估算思路。假设模型参数量为 P（单位是十亿），层数为 L，精度为 FP16（每参数 2 字节），那么单层权重大约是：
单层权重 ≈ (P × 2) / L (GB)以 70B、80 层为例，单层约 1.75GB。再加上推理时的激活值、KV Cache 和框架本身的运行时开销，实际显存占用通常是单层权重的 1.5 到 2 倍。所以一张 8GB 显存的卡，跑 70B 的分层推理是可行的，但会比较紧张；12GB 以上会舒服很多。
如果是 4-bit 量化，每参数字节数降到约 0.5，单层权重直接降到原来的四分之一，70B 单层只要 0.44GB 左右，这时候连 6GB 的卡都能比较从容地跑起来。这也是为什么 airllm 和量化几乎是绑定使用的——量化不只是省显存，它同时把磁盘 IO 量也降下来了，一举两得。
2.3 磁盘 IO 才是真正的隐形瓶颈
我在第一次实测时犯了个错误：把模型放在了一块老旧的机械硬盘上。结果就是模型能加载，但推理速度慢到令人绝望，生成一个 token 要等好几秒。后来换成 NVMe SSD，速度立刻上了一个台阶。这个对比让我意识到，airllm 的性能瓶颈几乎完全不在 GPU 上，而在存储上。
这里给一个直观的对比，帮助你在选存储时有个判断：
| 存储类型 | 顺序读取速度（大致） | 70B 分层推理体验 |
|---|---|---|
| 机械硬盘 | 100-200 MB/s | 基本不可用，token 间隔以秒计 |
| SATA SSD | 500 MB/s 左右 | 勉强能用，但明显卡顿 |
| NVMe SSD | 2000-7000 MB/s | 可用，配合量化体验较好 |
| 内存盘 | 10000 MB/s 以上 | 最快，但需要足够大的内存 |
提示：如果你的机器内存足够大（比如 128GB 以上），可以考虑把模型先加载到内存里，再让 airllm 从内存读取。这样能绕开磁盘 IO 的瓶颈，速度提升非常明显。代价是内存占用会很高。
理解了这三层逻辑——时间局部性、单层显存估算、磁盘 IO 瓶颈——你就掌握了 airllm 的全部核心原理。剩下的都是工程细节和参数调优。
3. 从零跑通第一个分层推理：环境与实操
3.1 环境准备中最容易忽略的两件事
安装 airllm 本身很简单，一条 pip 命令的事。但真正决定你能不能顺利跑起来的，是两个经常被忽略的前置条件。
第一是 CUDA 和 PyTorch 的版本匹配。airllm 依赖 PyTorch 做底层计算，如果你的 PyTorch 是 CPU 版本，或者 CUDA 版本和驱动对不上，会出现各种奇怪的报错。我的建议是先确认torch.cuda.is_available()返回 True，再装 airllm。这一步花两分钟，能省掉后面半小时的排查。
第二是磁盘空间。分层加载意味着模型权重需要以某种形式完整地存在磁盘上，而且量化过程可能还会产生额外的缓存文件。一个 70B 的模型，原始权重加上量化后的版本，占用几十到上百 GB 是常态。装之前先df -h看一眼剩余空间，别跑到一半发现磁盘满了。
# 确认 PyTorch 和 CUDA 正常 python -c "import torch; print(torch.__version__, torch.cuda.is_available())" # 安装 airllm pip install airllm3.2 最小可运行示例与参数解读
airllm 的 API 设计得相当克制，核心就是一个AutoModel类。下面是一个最小可运行的例子：
from airllm import AutoModel MAX_LENGTH = 128 # 加载模型，指定压缩方式 model = AutoModel.from_pretrained( "model-path-or-name", compression="4bit", # 量化方式，可选 4bit / 8bit layer_shards_saving_path=None, # 分层缓存路径 ) input_text = ["请用一句话解释什么是分层加载。"] input_tokens = model.tokenizer( input_text, return_tensors="pt", return_attention_mask=False, truncation=True, max_length=MAX_LENGTH, padding=False, ) generation_output = model.generate( input_tokens["input_ids"].cuda(), max_new_tokens=64, use_cache=True, return_dict_in_generate=True, ) print(model.tokenizer.decode(generation_output.sequences[0]))这段代码里有几个参数值得单独说。compression="4bit"是最关键的，它决定了显存和 IO 的双重开销，不设这个参数的话，70B 模型基本跑不动。layer_shards_saving_path用来指定分层权重的缓存位置，如果你有更快的盘，把它指过去能明显提速。max_new_tokens控制生成长度，这个值越大，总耗时越长，因为每生成一个 token 都要把所有层重新过一遍。
3.3 第一次运行时的预期与实测感受
第一次跑的时候，一定要有心理准备：加载阶段会很慢。因为 airllm 需要把模型权重做量化并分片存储，这个过程可能持续十几分钟甚至更久，取决于模型大小和磁盘速度。这一步是一次性的，之后再用同一个模型就不用重复了。
真正开始生成后，你会发现第一个 token 的延迟特别高，后面会稍微快一点。这是因为第一轮要把所有层都过一遍建立缓存，后续 token 能复用一部分 KV Cache。但即便如此，分层推理的速度和"模型全在显存里"相比还是有数量级的差距。我实测下来，70B 4bit 在 NVMe 上的生成速度大概是每秒几个 token 的水平，用来做功能验证、跑通流程完全够用，但拿来做实时对话就不现实了。
这里有个实操心得：调试阶段先用一个小模型（比如 7B 或 13B）把整个流程跑通，确认环境、路径、参数都没问题，再换成大模型。直接上 70B 的话，一旦哪里出错，光是重新加载就要等很久，排查效率极低。
4. 量化、缓存与路径：决定速度的三个开关
4.1 4bit 与 8bit 的取舍不是精度问题那么简单
很多人选量化精度时只盯着"精度损失"，但在 airllm 这个场景下，量化方式首先影响的是速度和可行性。8bit 相比 4bit，单层权重大一倍，意味着每次前向传播要读的数据量翻倍，磁盘 IO 压力也翻倍。在磁盘速度有限的情况下，8bit 很可能直接把推理速度拖到不可接受。
我的建议是：除非你对输出质量有非常高的要求，否则优先用 4bit。4bit 量化在大模型上的质量损失，对于大多数验证性、实验性用途来说是可以接受的。而且 airllm 的分层加载本身已经引入了延迟，再叠加 8bit 的 IO 开销，体验会很差。
| 量化方式 | 单层权重（70B/80层） | 显存需求 | IO 压力 | 适用场景 |
|---|---|---|---|---|
| FP16 | 约 1.75GB | 高 | 高 | 显存充足时 |
| 8bit | 约 0.88GB | 中 | 中 | 质量优先 |
| 4bit | 约 0.44GB | 低 | 低 | 大多数场景推荐 |
4.2 分层缓存路径选对了能省一半时间
layer_shards_saving_path这个参数看起来不起眼，但它直接决定了 airllm 从哪里读取分层权重。默认情况下它会用某个缓存目录，如果你不主动指定，很可能落在系统盘上。系统盘往往是速度一般的 SSD，甚至可能是共享的云盘。
正确的做法是把它指向你机器上最快的存储。如果你有 NVMe SSD，就指到 NVMe 上；如果内存够大，甚至可以做一个内存盘（tmpfs）指过去。我做过对比，同样的模型和参数，从普通 SATA SSD 换到 NVMe，生成速度大概能提升一倍以上。这个改动几乎零成本，但收益非常直接。
model = AutoModel.from_pretrained( "model-path", compression="4bit", layer_shards_saving_path="/path/to/fast/nvme/cache", )注意：缓存路径一旦确定，后续换路径需要重新做量化分片，所以第一次就选好。另外要确保这个路径有足够的空间，量化后的分片文件加起来可能比原始模型还大。
4.3 一个被低估的优化：预热与复用
airllm 每次调用generate都会重新走一遍分层加载流程。如果你需要连续做多次推理，每次都从头加载是很浪费的。一个实用的做法是把模型对象保持常驻，不要每次请求都重新from_pretrained。模型对象本身占用的显存不多（因为权重是分层加载的），但省掉了重复初始化的开销。
另外，如果你的使用场景是批量处理一批输入，尽量把它们组织成一次generate调用，而不是循环调用。因为分层加载的开销是"每轮前向传播"级别的，批处理能让这个开销被多个样本分摊，整体效率更高。这一点和常规的显存内推理逻辑不太一样，值得特别注意。
5. 踩坑实录：那些让我卡了半天的报错
5.1 显存明明够却报 OOM
这是我最开始遇到的一个反直觉问题：明明按单层权重估算，8GB 显存绰绰有余，但运行时报显存不足。排查了半天才发现，问题出在max_length和max_new_tokens设得太大。这两个参数决定了 KV Cache 的大小，而 KV Cache 是随序列长度线性增长的。序列越长，缓存越大，显存占用就越高。
解决办法很直接：把max_length和max_new_tokens调小。调试阶段用 128 或 256 就够了，确认流程通了再根据需要往上加。如果确实需要长序列，那就得在显存和序列长度之间做权衡，或者考虑用更激进的量化。
5.2 模型加载到一半卡住不动
有一次加载一个较大的模型，进度条走到某个位置就再也不动了，也没有报错。这种情况通常是磁盘 IO 被打满了，或者缓存路径所在的分区空间不足。我的排查顺序是：先看磁盘剩余空间，再看磁盘 IO 占用，最后检查缓存路径的权限。
还有一个可能是模型文件本身下载不完整。如果是通过模型名称自动下载的，网络中断会导致文件损坏。这时候清掉缓存重新下载通常能解决。建议在下载大模型时用稳定的网络环境，并且下载完校验一下文件完整性。
5.3 生成结果乱码或重复
如果模型能跑但输出是乱码或者无限重复，大概率是 tokenizer 配置或者输入格式的问题。airllm 需要配合正确的 tokenizer 使用，如果模型路径下的 tokenizer 文件和权重不匹配，就会出现这种情况。另外，return_attention_mask=False这个设置在某些模型上是必须的，如果设成 True 反而可能出问题。
排查这类问题的思路是：先用一个很小的、确定能正常工作的模型验证整个 pipeline，确认 tokenizer、输入格式、生成参数都没问题，再换目标模型。这样能把"模型本身的问题"和"代码配置的问题"区分开。
5.4 换模型后参数不兼容
不同模型架构对分层加载的支持程度不一样。有些模型层结构规整，airllm 处理起来很顺；有些模型有特殊的层类型或者共享权重，就可能出现加载失败或者结果异常。遇到这种情况，先确认这个模型是否在 airllm 的适配范围内，不要想当然地认为"是个 Transformer 就能跑"。
6. 它适合谁，又不适合谁
6.1 明确适用的几类场景
airllm 最适合的场景，我总结下来有这么几类。一是功能验证和原型开发：你想快速验证一个大模型在某个任务上的表现，但手头没有大显存机器，airllm 能让你用现有设备跑起来。二是教学和原理学习：通过分层加载，你能直观地看到大模型推理时内存是怎么流动的，对理解推理机制很有帮助。三是低频次的离线任务：比如每天跑一次的数据处理，速度慢一点无所谓，能跑就行。
这几类场景的共同点是：对延迟不敏感，对"能不能跑起来"更敏感。airllm 的价值就在于把"不能跑"变成了"能跑，只是慢"。
6.2 这些情况下别硬上
反过来，如果你的场景是实时对话、高并发服务、或者对响应速度有硬性要求，那 airllm 基本不适合。分层加载带来的延迟是结构性的，不是调参能解决的。这种场景下，要么用更小的模型，要么用真正的多卡方案，要么用专业的推理服务框架。
还有一种情况是磁盘速度实在跟不上。如果你只有机械硬盘，或者磁盘 IO 已经被其他任务占满，那 airllm 的体验会差到没有实用价值。这种情况下，与其折腾 airllm，不如考虑用 API 调用或者租用算力。
6.3 和其他省显存方案的对比
市面上省显存的方案不止一种，简单对比一下能帮你做选择。模型量化（如 GPTQ、AWQ）是把权重压小，但仍然需要全部加载进显存，省的是"模型大小"这一维度。CPU offload（如 accelerate 的 device_map）是把部分层放到内存，比 airllm 快，但需要足够大的内存。airllm 则是把层放到磁盘，对内存要求最低，但速度最慢。
| 方案 | 显存需求 | 内存需求 | 速度 | 适合场景 |
|---|---|---|---|---|
| 纯量化 | 中 | 低 | 快 | 显存勉强够 |
| CPU offload | 低 | 高 | 中 | 内存充足 |
| airllm 分层 | 极低 | 低 | 慢 | 显存内存都紧张 |
选择哪个，取决于你的硬件短板在哪里。显存不够但内存够，用 offload；显存内存都不够，才轮到 airllm。
7. 几个能立刻用上的调优技巧
7.1 用内存盘把 IO 瓶颈彻底绕开
如果你的机器内存足够大（比如 64GB 以上），可以划一块内存盘出来，把layer_shards_saving_path指过去。内存的读写速度比最快的 NVMe 还要快一个数量级，这能显著改善生成速度。代价是内存盘会占用实际内存，模型分片有多大就要占多少内存，所以要算好账。
# 在 Linux 上创建一个 40GB 的内存盘 sudo mkdir /mnt/ramdisk sudo mount -t tmpfs -o size=40G tmpfs /mnt/ramdisk创建好之后把缓存路径指到/mnt/ramdisk即可。注意内存盘在重启后会清空，每次重启都要重新做量化分片，所以更适合长时间连续使用的场景。
7.2 控制序列长度比什么都重要
前面提过 KV Cache 随序列长度增长，这里再强调一次：在 airllm 场景下，序列长度是影响显存和速度的最敏感参数。能短则短，不要为了"保险"把max_length设得很大。实际测试时，从 128 开始，逐步往上加，找到你机器能稳定承受的上限。
7.3 批处理要谨慎
批处理能分摊分层加载的开销，但也会成倍增加 KV Cache 的显存占用。在显存本来就紧张的情况下，批处理很容易触发 OOM。我的建议是：如果显存充裕，可以适当批处理；如果显存紧张，老老实实单条处理，别为了那点效率提升把显存撑爆。
7.4 监控磁盘 IO 找到真正的瓶颈
调优时不要凭感觉，用工具看数据。Linux 下可以用iostat看磁盘读写速率，用nvidia-smi看显存和 GPU 利用率。如果发现 GPU 利用率很低而磁盘 IO 很高，说明瓶颈在存储，优化方向就是换更快的盘或者上内存盘。如果显存占用接近上限，那就要考虑降量化精度或者缩短序列。
# 实时查看磁盘 IO iostat -x 1 # 查看 GPU 状态 nvidia-smi -l 1这几个技巧都是我在实际使用中反复验证过的，尤其是内存盘和序列长度控制这两条，对体验的改善最明显。airllm 这个项目本身还在持续迭代，不同版本的行为可能有差异，遇到问题时先确认版本，再去对照文档和 issue，能少走很多弯路。
