1. 当显存告急时，我们还能不能跑大模型
第一次在单卡24G显存上尝试加载一个70B参数级别的模型时，我盯着终端里那行红色的显存溢出报错看了很久。这不是什么罕见的场景——任何一个在消费级硬件上折腾过大模型推理的人，大概都经历过类似的时刻。模型权重动辄上百GB，而手头的显卡显存就那么点，量化能压一部分，但压到一定程度精度就崩了。于是问题变成：有没有一种办法，能让大模型在有限显存上跑起来，同时又不至于把精度牺牲得太离谱？
airllm这个项目就是冲着这个痛点来的。它的核心思路说起来并不复杂：既然显存装不下整个模型，那就不要一次性装进去。把模型按层切分，推理的时候只把当前需要的层加载到显存里，用完就释放，下一层再加载。这样显存占用就从"整个模型的大小"变成了"单层的大小加上一些运行时开销"。听起来像是用时间换空间的老套路，但真正把它做到可用、做到推理速度不至于让人崩溃，里面有不少工程上的细节值得聊。
这篇文章适合几类人看：手头只有消费级显卡但想跑大模型的开发者、对模型推理优化感兴趣的技术爱好者、以及正在评估不同推理方案选型的工程师。我会从airllm的核心机制讲起，拆解它为什么能省显存、省到什么程度、代价是什么，然后给出完整的实操步骤和参数配置，最后分享一些在实际使用中踩过的坑和总结出来的经验。全文基于我对这类分层推理方案的实践理解来写，涉及具体操作的地方会给出可直接复现的步骤。
2. airllm的分层推理机制到底是怎么省显存的
2.1 模型权重的分层加载与释放逻辑
要理解airllm为什么能省显存，得先搞清楚常规推理时显存被什么占满了。当你用常规方式加载一个模型时，显存里主要装着这些东西：模型权重（大头）、KV Cache（推理过程中累积的键值缓存）、激活值（中间计算结果）、以及框架本身的开销。其中模型权重通常占了绝大部分。一个70B参数的模型，即使用fp16精度，权重也要140GB左右，这还没算KV Cache。
airllm的做法是把模型权重按Transformer层拆开。一个70B的模型通常有80层左右，每层大约1.75GB（fp16）。推理时，它只把当前正在计算的那一层加载到显存，算完之后把这一层的输出传给下一层，同时释放掉上一层的权重。这样一来，显存里同时存在的权重就只有一层的大小，加上KV Cache和激活值，总占用可以控制在几GB的量级。
这个思路和操作系统的虚拟内存有点像：物理内存不够的时候，把不常用的页换出去，需要的时候再换进来。区别在于，airllm的"换页"粒度是整层，而且它知道推理是顺序进行的，所以可以精确地预判下一层需要什么。
但这里有个关键问题：层与层之间的数据传输怎么办？如果每一层都要从磁盘加载到显存，磁盘IO就会成为瓶颈。airllm在这方面做了几件事来缓解：一是使用内存映射文件（memory-mapped file）来加载权重，避免一次性把整个文件读进内存；二是利用操作系统的页缓存，让频繁访问的层数据尽量留在内存里；三是通过预取机制，在当前层计算的同时就开始加载下一层的数据。
2.2 与量化方案的对比：省显存的两种不同路径
说到省显存，大多数人第一反应是量化。把fp16降到int8、int4，显存占用直接减半甚至减到四分之一。airllm走的是另一条路：不改变权重的精度，而是改变权重的加载方式。这两条路并不互斥，实际上可以叠加使用。
我整理了一个对比表格，方便看清楚两种方案的区别：
| 维度 | 量化方案 | airllm分层加载 |
|---|---|---|
| 省显存原理 | 降低每个参数的位宽 | 减少同时驻留显存的层数 |
| 精度影响 | 有损，低位宽下明显 | 无损（保持原始精度） |
| 推理速度 | 通常更快（计算量减少） | 受IO带宽限制，可能更慢 |
| 显存下限 | 取决于量化后的模型大小 | 取决于单层大小，可低至几GB |
| 适用场景 | 显存中等紧张，追求速度 | 显存极度紧张，追求精度 |
从表格能看出来，airllm的优势在于精度无损和显存下限极低。如果你手头只有8GB甚至更少的显存，量化到int4可能还是装不下某些大模型，但airllm理论上只要单层能装下就能跑。代价是推理速度会受限于磁盘IO和内存带宽，尤其是当模型层数多、每层数据量大的时候。
实际使用中，我通常会把两者结合起来：用int8量化把单层大小进一步压下来，同时用airllm的分层加载来控制显存峰值。这样既保证了精度不至于崩得太厉害，又让显存占用维持在一个很低的水平。
2.3 推理速度的瓶颈在哪里
很多人第一次用airllm的时候，最直观的感受是"慢"。这个慢是有原因的，得从数据流的角度来分析。常规推理时，模型权重一直在显存里，GPU计算单元可以满负荷运转，瓶颈通常在计算本身。而airllm的推理过程中，GPU经常处于等待状态——等下一层的数据从磁盘或内存传过来。
具体来说，瓶颈可能出现在三个环节：磁盘读取速度、内存到显存的传输带宽、以及层与层之间的同步开销。如果模型放在机械硬盘上，磁盘读取会成为主要瓶颈；如果放在SSD上，内存带宽可能成为瓶颈；如果内存也不够大，频繁的页换入换出又会拖慢速度。
我在一台配置为SSD加64GB内存的机器上做过测试，跑一个70B的模型，airllm的推理速度大约是常规方式的十分之一到五分之一。这个数字听起来很吓人，但考虑到常规方式根本跑不起来（显存不够），airllm的价值在于"能跑"而不是"跑得快"。对于离线推理、批量处理、或者对延迟不敏感的场景，这个速度是可以接受的。
注意：如果你追求的是实时交互式的推理体验，airllm可能不是最佳选择。它更适合那些"能出结果就行"的场景，比如批量生成、离线分析、或者模型效果验证。
3. 从零跑通airllm的完整操作路径
3.1 环境准备与依赖安装
在开始之前，先确认一下硬件和软件环境。airllm对硬件的要求其实很宽松，这也是它的卖点之一。我建议的最低配置是：一张支持CUDA的显卡（显存4GB以上）、16GB以上的系统内存、以及一块SSD（强烈建议，机械硬盘会让速度慢到难以忍受）。软件方面，需要Python 3.8以上、PyTorch（版本要和CUDA匹配）、以及transformers库。
安装airllm本身很简单，一条命令的事：
pip install airllm但这里有个容易忽略的点：airllm依赖的PyTorch版本和CUDA版本要匹配好。我有一次在CUDA 11.8的环境里装了为CUDA 12.1编译的PyTorch，结果airllm跑起来各种报错，排查了半天才发现是版本不匹配。建议先用nvidia-smi确认CUDA版本，然后去PyTorch官网查对应的安装命令。
另外，transformers的版本也需要注意。airllm需要transformers的某些接口来加载模型配置和分词器，版本太老或太新都可能出问题。我实测下来，transformers 4.36到4.40之间的版本比较稳定。
3.2 模型加载与推理的代码实现
环境准备好之后，就可以写推理代码了。airllm的API设计得比较简洁，核心就是AutoModel这个类。下面是一个完整的示例：
from airllm import AutoModel # 指定模型路径或HuggingFace模型ID model_id = "meta-llama/Llama-2-70b-hf" # 加载模型，airllm会自动处理分层加载 model = AutoModel.from_pretrained(model_id) # 准备输入 input_text = ["请用一句话解释什么是机器学习。"] input_tokens = model.tokenizer( input_text, return_tensors="pt", return_attention_mask=False, truncation=True, max_length=128 ).input_ids # 执行推理 output = model.generate( input_tokens, max_new_tokens=100, use_cache=True, return_dict_in_generate=True ) # 解码输出 output_text = model.tokenizer.decode(output.sequences[0]) print(output_text)这段代码看起来和常规的transformers推理没什么区别，这正是airllm设计得好的地方——它把分层加载的复杂性封装在了AutoModel内部，对使用者来说几乎是透明的。
但有几个参数值得特别说明。max_length控制输入的最大长度，这个值会影响KV Cache的大小，进而影响显存占用。max_new_tokens控制生成的最大token数，同样会影响KV Cache。如果你显存特别紧张，可以把这两个值调小一些。use_cache=True是必须的，否则每生成一个token都要重新计算所有层的KV，速度会慢到无法接受。
3.3 关键参数的调优与显存控制
airllm提供了一些参数来控制分层加载的行为，这些参数直接影响显存占用和推理速度。我整理了一个参数说明表格：
| 参数名 | 作用 | 推荐值 | 注意事项 |
|---|---|---|---|
| layer_shards_saving_path | 指定分层权重的缓存路径 | SSD上的目录 | 不要放在机械硬盘上 |
| compression | 权重压缩方式 | None或"4bit" | 4bit可进一步省显存但损失精度 |
| profiling_mode | 是否输出性能分析 | False | 调试时可设为True |
| prefetching | 是否预取下一层 | True | 开启可提升速度 |
其中compression参数值得多说一句。airllm支持在分层加载的基础上再做4bit量化，这样单层的大小可以进一步压缩到原来的四分之一左右。对于显存极度紧张的情况，这个选项很有用。但要注意，4bit量化是有精度损失的，具体损失多少取决于模型和任务，建议先在小规模测试上验证效果。
prefetching参数控制是否在当前层计算时预取下一层的数据。开启后，GPU计算和IO传输可以重叠进行，速度会有明显提升。但预取会占用额外的内存和显存，如果资源实在紧张，可以关掉。
我在实际调优时的经验是：先把prefetching打开，如果显存不够再考虑开compression，最后才调整max_length和max_new_tokens。这个顺序的原因是，前两个参数对精度的影响相对可控，而后两个参数直接影响模型能处理多长的输入和输出。
4. 实际使用中那些文档没写的坑
4.1 磁盘IO才是真正的隐形瓶颈
官方文档在介绍airllm的时候，重点讲的是显存节省，对磁盘IO的强调不够。但我实际用下来，磁盘IO才是决定体验的关键因素。同样的模型，放在机械硬盘上和放在NVMe SSD上，推理速度可以差五到十倍。
原因很简单：airllm在推理过程中需要反复读取模型权重文件。虽然操作系统有页缓存，但模型文件动辄几十上百GB，内存根本缓存不下全部。每次推理都要从磁盘读取大量数据，磁盘的随机读取性能就直接决定了速度下限。
我做过一个粗略的测试：在一个70B模型上，用NVMe SSD时每秒能生成大约2到3个token，换成机械硬盘后降到每秒0.3到0.5个token。这个差距在长文本生成时会变得非常明显——生成500个token，SSD需要三四分钟，机械硬盘要将近半小时。
所以如果你打算认真用airllm，一块像样的SSD是必须的。容量方面，至少要能放下模型文件本身，再加上一些缓存空间。我建议预留模型大小1.5倍以上的空间。
4.2 内存不足时的连锁反应
airllm虽然省显存，但对系统内存还是有一定要求的。如果内存不足，操作系统会频繁进行页换入换出，导致整个系统变卡，推理速度断崖式下降。
我遇到过一次典型的情况：在一台32GB内存的机器上跑一个70B模型，模型文件大约140GB。推理开始后，内存很快被页缓存占满，然后系统开始换页，磁盘IO飙升，推理速度从每秒2个token掉到每秒0.1个token，几乎处于卡死状态。
解决办法有两个：一是增加内存，让页缓存能容纳更多的层数据；二是限制airllm的内存使用，通过layer_shards_saving_path把分层权重写到SSD上，减少对内存页缓存的依赖。我后来把内存加到64GB，情况明显改善，推理速度恢复到了正常水平。
提示：在Linux系统上，可以通过
free -h命令查看内存和页缓存的使用情况。如果发现页缓存频繁被回收，说明内存不够用了。
4.3 模型格式转换中的版本兼容问题
airllm支持多种模型格式，包括HuggingFace的原生格式、safetensors格式等。但在实际使用中，不同格式之间的转换可能会遇到版本兼容问题。
我遇到过一个比较隐蔽的坑：某个模型在HuggingFace上是safetensors格式，但airllm在加载时需要先转换成它自己的分层格式。转换过程中，如果transformers的版本和模型保存时的版本不一致，可能会导致某些层的权重加载失败，而且报错信息很不直观，只提示"shape mismatch"，不告诉你是哪一层出了问题。
排查这类问题的思路是：先用transformers直接加载模型，确认模型本身没问题；然后再用airllm加载，如果报错，对比两者的transformers版本。如果版本不一致，尝试降级或升级transformers到模型要求的版本。
另外，airllm在第一次加载模型时会进行格式转换，这个过程可能比较耗时（取决于模型大小和磁盘速度）。转换完成后的分层权重会缓存在layer_shards_saving_path指定的目录里，下次加载就直接用缓存，速度快很多。所以第一次跑的时候要有耐心，不要以为卡死了就强行中断。
5. 把airllm用好的几个进阶思路
5.1 与量化方案叠加使用的最佳实践
前面提到过，airllm可以和量化叠加使用。具体怎么叠加效果最好，我摸索出了一套流程。
第一步，先用常规方式加载模型，用int8量化跑一遍基准测试，记录精度指标（比如在某个验证集上的准确率）。第二步，用airllm加载原始精度的模型，跑同样的测试，确认精度没有下降（理论上应该完全一致）。第三步，在airllm的基础上开启4bit压缩，再跑测试，看精度下降了多少。如果下降在可接受范围内，就用这个配置；如果下降太多，就退回int8加airllm的组合。
这套流程的关键在于，每一步都要有量化的精度评估，不能凭感觉。我见过有人直接上4bit加airllm，结果模型输出质量明显下降，却以为是airllm的问题，其实是量化损失导致的。
5.2 批量推理时的显存与速度平衡
airllm在批量推理时的表现和单条推理不太一样。批量推理时，KV Cache会成倍增加，因为每个样本都要维护自己的KV。如果batch size设得太大，KV Cache可能会把显存占满，导致airllm无法加载下一层的权重。
我的经验是，batch size不要超过4，除非你的显存特别充裕。如果确实需要处理大量数据，可以用小batch size加循环的方式，虽然总时间可能差不多，但至少不会因为显存溢出而中断。
另外，批量推理时可以把max_length设得小一些，因为批量处理通常不需要太长的上下文。这样KV Cache会小很多，显存压力也小。
5.3 什么场景下值得用airllm
最后聊聊适用场景的问题。airllm不是万能的，它有明确的适用边界。
适合的场景：显存极度有限但需要跑大模型、对推理延迟不敏感、需要保持原始精度、离线批量处理。比如在个人开发机上验证大模型效果、在教学环境中演示大模型推理、或者在边缘设备上跑轻量级的大模型应用。
不适合的场景：需要实时交互、对吞吐量要求高、显存其实够用只是懒得优化。这些场景下，量化方案或者直接用更大的显卡会更合适。
我个人的判断标准是：如果显存不够装下量化后的模型，或者量化后精度损失无法接受，那就用airllm。如果显存够装量化模型且精度可接受，优先用量化。如果显存充裕，那就别折腾了，直接常规推理。
在实际项目中，我通常会把airllm作为一个"保底方案"——当其他方案都跑不通的时候，它至少能让我把模型跑起来，拿到结果。虽然慢，但能出结果比什么都重要。等到验证了模型效果确实有价值，再考虑升级硬件或者优化推理方案。这个思路在我做过的几个项目里都挺管用，分享出来供参考。
