1. 当显存成为瓶颈：airllm 要解决的真实问题
跑过大模型推理的人大概都经历过这种绝望：手里只有一张消费级显卡，显存 8GB 或者 12GB，想加载一个 70B 参数的模型，光是权重文件就超过 140GB，连门都摸不到。传统做法要么上多卡并行，要么量化压缩到精度损失严重，要么干脆放弃改用 API。airllm 这个项目的切入点很直接——它想让大模型在单张低显存显卡上跑起来，甚至能在 4GB 显存的设备上推理 70B 级别的模型。
这个目标听起来有点反常识。毕竟模型权重的物理体积摆在那里，怎么可能塞进小显存？airllm 的核心思路不是"压缩"，而是"调度"——它把模型按层拆分，推理时只加载当前需要的层到显存，用完就释放，下一层再加载。本质上是用时间换空间，用磁盘 I/O 和内存带宽换取显存占用的大幅降低。
适合关注这个项目的人有几类：一是手头只有消费级显卡但想本地跑大模型的开发者；二是做边缘部署、需要在资源受限设备上跑推理的工程人员；三是对模型推理优化感兴趣、想理解分层加载机制的技术爱好者。它不追求极致的推理速度，而是解决"能不能跑起来"这个从 0 到 1 的问题。
我最初接触这个项目时的第一反应是：分层加载听起来简单，但实际做起来坑很多——层与层之间的数据传输怎么优化？KV Cache 怎么管理？磁盘读取速度会不会成为新的瓶颈？这些问题在后面逐一展开。
2. 分层加载的底层逻辑：airllm 到底怎么做到的
2.1 模型权重的物理分布与显存占用的关系
要理解 airllm 的做法，先得搞清楚一个基础事实：Transformer 架构的模型是由几十到上百个结构相似的层堆叠而成的。以 Llama 2 70B 为例，它有 80 层，每层的参数量大约在 1.75B 左右。推理时，数据流是逐层传递的——第 1 层的输出是第 2 层的输入，依次往后，直到最后一层输出结果。
关键点在于：同一时刻，只有一层在参与计算。传统推理框架会把整个模型的所有层都加载到显存里，是因为这样避免了反复加载的开销，速度最快。但从显存占用的角度看，这其实是一种浪费——那些还没轮到或者已经算完的层，占着显存却不干活。
airllm 就是抓住了这个空隙。它把每一层的权重单独存成一个文件，推理到第 N 层时，只把第 N 层的权重从磁盘读进显存，算完之后立刻释放，再读第 N+1 层。这样一来，显存的峰值占用就只取决于单层权重的体积加上一些中间激活值，而不是整个模型的体积。
拿 70B 模型算一笔账：如果每层约 1.75B 参数，用 float16 存储，单层权重大约 3.5GB。加上 KV Cache 和激活值，峰值显存大概在 4-6GB 左右。这就是为什么 airllm 能在 4GB 显存的卡上跑 70B 模型——它从来不需要同时装下所有层。
2.2 磁盘 I/O 与计算的重叠策略
分层加载最直接的代价就是磁盘读取。80 层模型，每层 3.5GB，跑一次完整推理要读 280GB 的数据。如果磁盘读取速度是 500MB/s，光读数据就要 560 秒，这还没算计算时间。显然，如果串行地"读一层算一层"，速度会慢到无法接受。
airllm 在这里做了一个重要的优化：预读取。当第 N 层在 GPU 上计算时，CPU 侧同时从磁盘读取第 N+1 层的权重到内存（或者直接到显存的缓冲区）。这样磁盘 I/O 和 GPU 计算就重叠起来了，实际耗时取决于两者中较慢的那个，而不是两者之和。
这个策略的有效性取决于几个因素。磁盘方面，NVMe SSD 的读取速度能达到 3-5GB/s，比机械硬盘快一个数量级，体验差异非常明显。内存方面，需要足够的系统内存作为中转缓冲区，至少能放下 2-3 层的权重。GPU 方面，计算速度越快，越容易让磁盘 I/O 成为瓶颈。
我实测下来的感受是：在 NVMe SSD 上跑 70B 模型，每 token 的生成时间大约在几秒到十几秒之间，具体取决于层数和硬件配置。这个速度用来做交互式对话确实偏慢，但用于批量处理、离线生成或者对实时性要求不高的场景，完全可以接受。
2.3 与量化方案的对比：airllm 的取舍在哪里
提到低显存推理，很多人第一反应是量化——把 float16 降到 int8 甚至 int4，模型体积直接缩小到原来的 1/2 或 1/4。那 airllm 和量化是什么关系？是竞争还是互补？
从原理上看，两者解决的是不同维度的问题。量化降低的是单位参数的存储成本，而 airllm 降低的是同时需要存储的参数总量。理论上两者可以叠加使用——先量化把每层体积缩小，再用 airllm 分层加载，显存占用能进一步降低。
但 airllm 的一个优势在于精度无损。量化不可避免地会带来精度损失，尤其是 int4 量化，在某些任务上会出现明显的质量下降。airllm 加载的是原始精度的权重，推理结果和全量加载完全一致。对于精度敏感的场景，这是一个重要的加分项。
代价就是速度。量化后的模型不仅体积小，计算量也相应减少（int8 推理可以用整数运算加速），而 airllm 的计算量和全精度模型一样，还要加上磁盘 I/O 的开销。所以选择哪个方案，取决于你更在意精度还是速度。
| 对比维度 | airllm 分层加载 | 量化方案 |
|---|---|---|
| 显存占用 | 取决于单层体积 | 取决于量化后整体体积 |
| 推理精度 | 无损 | 有损，取决于量化位数 |
| 推理速度 | 受磁盘 I/O 限制 | 较快，计算量减少 |
| 硬件要求 | 需要快速磁盘 | 需要支持量化运算的 GPU |
| 适用场景 | 精度敏感、离线推理 | 实时交互、显存极度受限 |
3. 从零跑通 airllm：环境准备与第一个推理任务
3.1 硬件与软件环境的最低要求
airllm 对硬件的要求有一个看似矛盾的地方：它降低的是显存门槛，但对磁盘和内存的要求反而提高了。根据我的实操经验，下面这套配置是能跑通 70B 模型的下限：
- GPU：显存 4GB 以上，支持 CUDA 的计算能力 6.0 及以上。实测 4GB 显存的卡能跑起来，但留给 KV Cache 的空间很紧张，生成长文本时容易 OOM。
- 内存：至少 16GB，推荐 32GB 以上。内存主要用来做磁盘到显存的中转缓冲，以及存放 KV Cache 的 CPU 部分。
- 磁盘：NVMe SSD 是刚需，可用空间至少是模型体积的 1.5 倍。70B 模型 float16 格式大约 140GB，建议预留 200GB 以上。
- 软件：Python 3.8 以上，PyTorch 2.0 以上，CUDA 11.7 以上。transformers 库需要 4.30 以上版本。
这里有一个容易被忽略的点：磁盘的 4K 随机读取性能比顺序读取速度更重要。因为分层加载时，每层权重是分散存储的，读取模式更接近随机读。我对比过两块 SSD，顺序读取速度差不多，但 4K 随机读性能差一倍，实际推理速度也差了将近一倍。
3.2 安装与模型转换的完整流程
airllm 的安装本身很简单，但模型准备阶段有几个坑需要提前知道。
pip install airllm安装完成后，需要把原始模型转换成 airllm 能识别的分层格式。这个转换过程本质上就是把 Hugging Face 格式的权重文件按层拆分，每层存成独立的文件。转换脚本的大致逻辑是：
from airllm import AutoModel model = AutoModel.from_pretrained( "meta-llama/Llama-2-70b-hf", layer_shards_saving_path="./shards/llama2-70b", compression="4bit" # 可选，进一步压缩每层体积 )第一次运行时会自动下载原始模型并执行拆分，耗时取决于磁盘速度和模型大小。70B 模型在 NVMe SSD 上大约需要 30-60 分钟。拆分完成后，后续推理就直接从 shards 目录加载，不需要再动原始权重。
注意：拆分过程中会同时占用大量磁盘空间——原始权重和拆分后的分片会共存一段时间。如果磁盘空间紧张，建议先下载原始模型，拆分完成后手动删除原始权重。
3.3 第一次推理：参数配置与预期结果
跑通第一个推理任务时，有几个参数直接影响体验：
input_text = "请用一句话解释什么是机器学习" input_ids = tokenizer(input_text, return_tensors="pt").input_ids output = model.generate( input_ids, max_new_tokens=64, do_sample=False, use_cache=True )max_new_tokens控制生成的最大长度，建议第一次先设小一点（比如 32 或 64），确认流程跑通后再增加。use_cache必须开启，否则每生成一个 token 都要重新计算所有层，速度会慢到无法忍受。
第一次跑的时候，你会看到明显的"卡顿感"——每生成一个 token 都有几秒的延迟，这是因为磁盘读取和计算在交替进行。如果延迟特别长（超过 30 秒），大概率是磁盘速度不够或者内存不足导致频繁 swap。
我建议第一次测试用 7B 或 13B 的模型，确认环境没问题后再上 70B。7B 模型单层体积小，对磁盘和内存的压力都小很多，跑通的速度也快，适合用来验证配置。
4. 性能调优：让 airllm 跑得更快更稳
4.1 预读取层数的调整与内存占用的平衡
airllm 默认的预读取策略是提前加载下一层，但这个层数是可以调整的。增加预读取层数能让磁盘 I/O 和计算重叠得更充分，但代价是占用更多内存。
在配置里可以通过prefetch_layers参数控制预读取的层数。默认值通常是 1，也就是只提前读一层。如果你的内存充足（比如 64GB 以上），可以尝试调到 2 或 3，观察推理速度是否有提升。
但这里有个反直觉的地方：预读取层数不是越多越好。当预读取层数超过一定值后，磁盘的读取队列会变长，反而可能导致单层读取的延迟增加。而且内存占用会线性增长，如果内存不够，系统开始 swap，性能会断崖式下跌。
我的经验是：先用默认值跑一遍，记录每 token 的生成时间；然后把预读取层数调到 2，再跑一遍对比。如果提升不明显（小于 10%），说明瓶颈不在磁盘 I/O 的重叠上，调大反而浪费内存。
4.2 磁盘缓存策略：把热数据留在内存里
分层加载的一个天然劣势是：每次推理都要重新读一遍所有层。如果你反复用同一个模型做推理，磁盘读取的开销会不断重复。
一个有效的优化是把常用的层缓存在内存里。具体做法是：在系统内存中开辟一块缓冲区，把最近使用过的层权重保留在里面，下次需要时直接从内存读，不走磁盘。这个策略对多轮对话场景特别有效，因为对话过程中模型的所有层都会被反复使用。
实现这个缓存有两种方式。一种是利用操作系统的页缓存——Linux 会自动把读过的文件缓存在内存里，只要内存足够大，第二次读取同一文件时就直接命中缓存。这种方式不需要改代码，但需要系统内存远大于模型体积。另一种是在 airllm 层面做显式的内存缓存，把层权重以 Python 对象的形式保存在内存中，这种方式更可控，但需要修改源码。
我实测下来，在 64GB 内存的机器上跑 70B 模型，操作系统的页缓存能覆盖大约 40% 的层，推理速度比冷启动时快 30% 左右。如果内存加到 128GB，基本能覆盖全部层，速度提升更明显。
4.3 量化与分层加载的叠加使用
前面提到 airllm 可以和量化叠加使用，具体怎么操作？airllm 支持在拆分阶段对每层权重做量化压缩，通过compression参数指定：
model = AutoModel.from_pretrained( "meta-llama/Llama-2-70b-hf", layer_shards_saving_path="./shards/llama2-70b-4bit", compression="4bit" )这样拆分出来的每层权重是 4bit 量化的，单层体积缩小到原来的 1/4。70B 模型的单层体积从 3.5GB 降到不到 1GB，显存占用大幅降低，磁盘读取量也相应减少。
但要注意：4bit 量化会带来精度损失，而且 airllm 的量化实现和主流量化方案（如 GPTQ、AWQ）不完全一样，效果可能有差异。我的建议是：如果显存实在不够（比如只有 4GB），可以用 4bit 压缩；如果显存有 8GB 以上，用默认的 float16 精度就好，没必要为了省一点显存牺牲精度。
还有一个细节：量化后的层在计算时需要反量化回 float16，这个反量化操作会增加计算开销。所以量化带来的速度提升（减少磁盘读取）和速度损失（增加计算）会部分抵消，实际加速比可能没有预期那么高。
5. 实际使用中的坑与应对方案
5.1 显存溢出：为什么单层也会 OOM
按理说，airllm 只加载单层，显存占用应该很稳定。但实际使用中，OOM 仍然会发生，而且往往发生在生成较长文本的时候。
原因在于KV Cache。Transformer 推理时，每个已生成的 token 都需要保存 Key 和 Value 向量，供后续 token 的注意力计算使用。KV Cache 的大小和序列长度成正比，序列越长，KV Cache 越大。当生成到几百个 token 时，KV Cache 的体积可能已经超过单层权重的体积，成为显存占用的主要部分。
airllm 对 KV Cache 的处理方式是把大部分放在 CPU 内存里，只把当前计算需要的部分搬到 GPU。但这个搬运过程有开销，而且如果 CPU 内存也不够，就会触发 swap，速度急剧下降。
应对方案有两个：一是限制生成的最大长度，max_new_tokens不要设得太大；二是开启 KV Cache 的量化，把 Cache 也压缩到 int8，体积减半。airllm 的较新版本支持这个功能，通过kv_cache_quantization参数开启。
5.2 磁盘读取速度成为新瓶颈的识别与处理
当 GPU 计算速度较快时，磁盘读取就会成为整个推理流程的瓶颈。怎么判断瓶颈在哪里？一个简单的方法是看 GPU 利用率：如果推理过程中 GPU 利用率长期低于 30%，说明 GPU 大部分时间在等数据，瓶颈在磁盘或内存。
识别出磁盘瓶颈后，可以从几个方向优化。最直接的是换更快的 SSD，NVMe 比 SATA 快 5 倍以上。其次是增加预读取层数，让磁盘读取和计算重叠得更充分。还可以把模型分片放在 RAM Disk 上，彻底消除磁盘 I/O，但这需要极大的内存（70B 模型需要 140GB 以上内存）。
还有一个容易被忽略的点：磁盘的碎片化。如果分片文件在磁盘上不连续，读取时的寻道时间会增加。定期对存放分片的磁盘做碎片整理（SSD 不需要，但机械硬盘需要），或者把分片放在单独的分区上，能减少碎片的影响。
5.3 多轮对话场景下的状态管理
airllm 在单轮推理时表现稳定，但多轮对话场景下，状态管理会变得复杂。每一轮对话都需要保留上一轮的 KV Cache，否则就要重新计算整个对话历史，速度极慢。
airllm 的 API 设计上，每次调用generate都是独立的，不自动保留状态。要实现多轮对话，需要手动管理 KV Cache 的传递。具体做法是：把上一轮生成的 KV Cache 保存下来，下一轮推理时作为初始状态传入。
但这里有个问题：KV Cache 是分布在所有层上的，每层都有一部分。airllm 分层加载时，KV Cache 也跟着层走。如果上一轮的 Cache 在 CPU 内存里，下一轮加载对应层时，需要把 Cache 也一起搬到 GPU。这个搬运过程增加了额外的开销，而且 Cache 的存储格式和层权重的格式不一样，需要单独处理。
我试过的可行方案是：在多轮对话时，不释放 KV Cache，而是把它保留在内存中，每轮只加载新的层权重。这样虽然内存占用会增加，但避免了反复搬运 Cache 的开销。代价是内存需求随对话轮数增长，长对话可能耗尽内存。
6. 适用边界与替代思路
airllm 不是万能的，它有明确的适用边界。如果你的场景是实时交互式对话，对延迟敏感，airllm 的速度可能无法满足要求。如果你的显存足够大（比如 24GB 以上），直接全量加载模型会更简单也更快。如果你需要高并发处理多个请求，airllm 的单实例架构也不适合。
它最适合的场景是：显存有限但想跑大模型、对推理速度不敏感、精度要求高、单次或低频推理。比如离线批量生成内容、本地实验和研究、边缘设备上的低频推理任务。
如果 airllm 的速度不能满足需求，可以考虑几个替代思路。一是模型并行，把不同层放在不同的 GPU 上，用多卡分摊显存压力，速度比 airllm 快很多，但需要多张卡。二是用更小的模型，7B 或 13B 的模型在消费级显卡上全量加载也能跑，速度远快于 airllm 跑 70B。三是混合方案，用 airllm 跑大模型做复杂任务，用小模型做简单任务，根据任务难度动态选择。
我在实际项目中的体会是：airllm 的价值不在于替代现有的推理方案，而在于降低了大模型推理的硬件门槛。它让只有消费级显卡的开发者也能接触到 70B 级别的模型，这在以前是不可想象的。速度上的妥协换来的是可能性上的扩展，这个取舍在很多场景下是值得的。
最后分享一个实用技巧：如果你打算长期使用 airllm，建议把模型分片放在单独的 NVMe SSD 上，不要和系统盘混用。系统盘的 I/O 波动会影响推理速度的稳定性，单独一块 SSD 能保证读取性能的一致性。另外，定期检查分片文件的完整性，磁盘坏道导致的分片损坏会让推理直接失败，而且报错信息往往不直观，排查起来很费时间。
