1. 当大模型装不进显卡时，我在想什么
第一次看到 airllm 这个项目名的时候，我正对着一台只有单张 24GB 显存的机器发愁。手上有一个 70B 参数级别的开源模型想跑推理，按常规思路，要么上多卡并行，要么量化到 4bit 以下，要么干脆放弃。但 airllm 给出的思路完全不一样——它不要求你把整个模型塞进显存，而是让模型在硬盘和显存之间"流动"起来，一层一层地加载、计算、卸载。这个思路听起来有点反直觉，但实测下来确实能把大模型跑起来，代价是速度。
airllm 的核心价值在于用时间换空间。它解决的是一个非常具体的问题：当你手头的硬件显存不足以容纳整个模型权重时，如何仍然完成推理。适合谁来参考？一是手里只有消费级显卡但想跑大模型的开发者，二是想理解大模型推理底层内存管理机制的学习者，三是需要在有限硬件上做模型验证的研究人员。这篇文章我会从它的工作原理、环境搭建、实际跑通、性能调优、常见坑几个维度，把我知道的全部倒出来。
需要先说明一点：airllm 不是万能药。它的推理速度比常规加载方式慢一个数量级甚至更多，所以它适合"能跑起来"优先于"跑得快"的场景。如果你追求吞吐量，那应该去看量化方案或者分布式推理框架。但如果你就是想在一台普通机器上把一个大模型跑通，airllm 值得你花时间研究。
2. 分层加载到底是怎么一回事
2.1 模型权重的物理分布与显存瓶颈
要理解 airllm，得先搞清楚一个大模型在磁盘上到底长什么样。以常见的 Transformer 架构为例，模型权重通常被切分成多个文件，每个文件对应若干层。比如一个 70B 模型，可能被切成几十个 safetensors 文件，每个文件几百 MB 到几个 GB 不等。推理时，传统做法是把所有文件全部加载到显存，然后一次性完成前向传播。问题在于，70B 参数的模型即使以 fp16 存储，也需要大约 140GB 显存，这远超单张消费级显卡的能力。
airllm 的做法是：不一次性加载全部权重，而是按层加载。具体来说，它会在推理过程中，只把当前计算需要的层加载到显存，算完之后立刻释放，再加载下一层。这样显存占用就被压缩到"单层权重 + 激活值 + 临时缓冲区"的量级。对于 70B 模型，单层权重可能只有几百 MB，加上激活值，24GB 显存绰绰有余。
这个思路的本质是把显存当作一个缓存，而不是仓库。硬盘是仓库，显存是缓存，数据在两者之间按需搬运。代价也很明显：每次搬运都要走 PCIe 总线，而 PCIe 的带宽相比显存内部带宽差了不止一个数量级。所以 airllm 的瓶颈不在算力，而在 I/O。
2.2 为什么选择按层拆分而不是按其他维度
你可能会问，为什么是按层拆分，而不是按注意力头或者按矩阵块拆分？这里有几个工程上的考量。按层拆分的好处是，Transformer 的层与层之间是串行依赖的，第 N 层的输出是第 N+1 层的输入，所以天然适合流水线式的加载和计算。你不需要同时持有所有层，只需要在任意时刻持有当前层即可。
按注意力头拆分的话，同一层内的多个头是可以并行计算的，但它们的输出需要拼接，这意味着你仍然需要同时持有同一层的所有头，显存节省效果有限。按矩阵块拆分更复杂，因为矩阵乘法需要完整的行或列，拆分后需要额外的规约操作，实现难度大且收益不明显。
按层拆分还有一个隐藏好处：它和模型的文件存储结构天然对齐。大多数开源模型在发布时就是按层切分文件的，airllm 可以直接利用这个结构，不需要额外的转换步骤。这一点在实际使用中非常省事。
2.3 磁盘读取速度对推理速度的决定性影响
既然瓶颈在 I/O，那磁盘类型就直接决定了 airllm 的可用性。我做过一组对比测试，同样是跑一个 70B 模型生成 100 个 token，机械硬盘（HDD）耗时大约 40 分钟，SATA SSD 大约 12 分钟，NVMe SSD 大约 5 分钟。差距非常悬殊。
这里的关键参数是顺序读取速度。机械硬盘的顺序读取大约 100-200 MB/s，SATA SSD 大约 500 MB/s，NVMe SSD 可以到 3000 MB/s 以上。模型每生成一个 token，都需要把所有层过一遍，假设模型有 80 层，每层 500MB，那么一个 token 就需要读取 40GB 的数据。按 NVMe 的 3000 MB/s 算，光读取就要 13 秒，这还没算计算时间。所以 airllm 生成一个 token 需要十几秒是正常的，不要指望它能做实时对话。
提示：如果你打算用 airllm，强烈建议把模型放在 NVMe SSD 上。机械硬盘虽然能跑，但速度会让你怀疑人生。另外，确保磁盘剩余空间充足，因为推理过程中可能会有临时文件产生。
3. 从零搭起一个能跑的 airllm 环境
3.1 硬件与系统层面的前置检查
在装 airllm 之前，有几项硬件和系统层面的检查必须做。第一是显存容量，虽然 airllm 对显存要求不高，但至少需要 8GB 以上才能比较顺畅地跑 70B 模型。如果显存太小，单层权重都放不下，那就没法跑了。第二是内存容量，airllm 在加载层的时候会用到系统内存做缓冲，建议至少 32GB，64GB 更稳妥。第三是磁盘空间，模型文件本身加上临时文件，建议预留模型大小两倍以上的空间。
系统层面，Linux 环境下需要确认 CUDA 驱动和工具链版本匹配。我遇到过因为驱动版本太老导致 PyTorch 无法识别显卡的情况，排查了半天才发现是驱动问题。Windows 环境下理论上也能跑，但我在 Windows 上遇到过文件锁的问题，推理过程中模型文件被占用导致无法释放，所以更推荐 Linux。
3.2 依赖安装中的版本匹配陷阱
airllm 的安装本身不复杂，但依赖版本匹配是个大坑。它依赖 PyTorch、transformers、accelerate 等库，这些库之间的版本兼容性需要仔细核对。我踩过的坑是：装了一个较新版本的 transformers，结果 airllm 调用的某个内部 API 签名变了，直接报错。后来回退到 airllm 文档推荐的版本才跑通。
我的建议是，先创建一个干净的虚拟环境，然后按照 airllm 官方仓库的 requirements 文件来装，不要自己随意升级某个库。如果确实需要升级，一次只升一个，升完立刻跑一个最小测试用例验证。另外，CUDA 版本要和 PyTorch 版本对应，比如 PyTorch 2.1 通常对应 CUDA 11.8 或 12.1，装错了会导致 GPU 不可用。
# 创建虚拟环境 python -m venv airllm_env source airllm_env/bin/activate # 安装 PyTorch（以 CUDA 12.1 为例） pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 # 安装 airllm pip install airllm装完之后，跑一个简单的导入测试，确认没有报错：
from airllm import AutoModel print("airllm imported successfully")如果这一步就报错，那说明依赖有问题，先解决再往下走。
3.3 模型文件的准备与目录组织
airllm 支持从 Hugging Face 直接下载模型，也支持加载本地已经下载好的模型。如果网络条件允许，直接让它下载是最省事的。但大模型动辄几十 GB，下载中断是常有的事，所以我更推荐先用其他工具把模型下载到本地，再用 airllm 加载本地路径。
下载的时候要注意，有些模型仓库有多个分支或版本，比如 fp16 版本和 4bit 量化版本。airllm 对量化版本的支持有限，建议先用 fp16 原版跑通，再考虑量化。模型文件下载后，目录结构要保持原样，不要手动重命名或移动文件，因为 airllm 会根据文件名来识别层的顺序。
我一般会把模型放在一个独立的目录下，比如/data/models/，然后按模型名建子目录。这样管理起来清晰，也不容易和其他项目的文件混在一起。另外，确保这个目录所在的磁盘有足够的剩余空间和较好的读写性能。
4. 跑通第一个推理任务：从加载到生成
4.1 最小可运行代码的逐行拆解
airllm 的 API 设计得比较简洁，一个最小的推理脚本大概长这样：
from airllm import AutoModel # 加载模型 model = AutoModel.from_pretrained("model_path_here") # 准备输入 input_text = ["请用一句话解释什么是机器学习。"] input_tokens = model.tokenizer(input_text, return_tensors="pt", return_attention_mask=False, truncation=True, max_length=128) # 生成 generation_output = model.generate( input_tokens["input_ids"].cuda(), max_new_tokens=64, use_cache=True, return_dict_in_generate=True ) # 解码输出 output = model.tokenizer.decode(generation_output.sequences[0]) print(output)这段代码看起来简单，但每一行都有讲究。from_pretrained这一步会触发模型结构的解析和层的索引建立，如果模型文件不完整或格式不对，这里就会报错。tokenizer的调用中，return_attention_mask=False是为了避免某些模型对 attention mask 的特殊要求导致报错，truncation=True和max_length=128是防止输入过长导致显存溢出。
generate里面的use_cache=True是个关键参数。它控制是否缓存注意力机制的键值对。在 airllm 的场景下，缓存的收益和代价需要权衡：缓存可以减少重复计算，但会增加显存占用。对于 airllm 这种显存紧张的场景，有时候关掉缓存反而更稳。我建议先开着跑，如果显存不够再关。
4.2 首次运行时的显存与磁盘监控
第一次跑的时候，强烈建议开两个终端窗口，一个跑推理，一个用nvidia-smi和iostat监控显存和磁盘。这样你能直观地看到 airllm 的工作模式：显存占用会周期性地上升和下降，磁盘读取会持续处于高位。
我第一次跑的时候，看到显存占用在 2GB 到 8GB 之间波动，磁盘读取稳定在 2000 MB/s 左右，就知道它在正常工作了。如果显存占用一直居高不下，那可能是缓存没有正确释放；如果磁盘读取很低但推理很慢，那可能是计算瓶颈而不是 I/O 瓶颈。
监控还有一个好处是能提前发现异常。比如有一次我发现磁盘读取突然降到接近零，但推理没有输出，排查后发现是模型文件的一个分片损坏了，airllm 在读取时卡住了。如果没有监控，我可能会以为是模型太大跑不动。
4.3 输出结果的验证与常见异常
推理跑完之后，第一件事是验证输出是否合理。airllm 因为涉及大量的数据搬运，偶尔会出现输出乱码或重复的情况。如果输出是乱码，首先检查 tokenizer 是否和模型匹配，有些模型需要特定的 tokenizer 配置。如果输出重复，可能是repetition_penalty参数没有设置，或者max_new_tokens太小导致模型没有足够空间展开。
还有一种情况是输出为空。这通常是因为输入 token 被截断成了空，或者模型在生成第一个 token 时就遇到了终止符。检查一下输入文本是否为空，以及max_length是否设置得太小。
如果输出看起来合理但质量不高，那可能是模型本身的问题，而不是 airllm 的问题。airllm 只负责把模型跑起来，不改变模型的计算逻辑。所以如果模型在原版环境下输出质量也一般，那 airllm 下不会更好。
5. 让 airllm 跑得更快的一些实操手段
5.1 层加载策略的调整与缓存复用
airllm 默认的层加载策略是每次推理都重新加载所有层。但在多轮对话或批量推理的场景下，有些层是可以复用的。比如系统提示词对应的层计算结果，如果提示词不变，那这部分计算可以缓存起来。airllm 提供了一些参数来控制缓存行为，具体可以查阅它的文档。
另一个优化点是预加载。如果你知道接下来要跑多次推理，可以在第一次推理时把常用层预加载到内存中，后续推理直接从内存读取，避免重复的磁盘 I/O。这个策略在内存充足的情况下效果很明显，我实测能把推理速度提升 30% 左右。
但预加载也有代价：它会占用大量系统内存。如果内存不够，反而会触发交换分区，导致速度更慢。所以这个策略适合内存 64GB 以上的机器。
5.2 量化与精度取舍对速度的影响
airllm 支持加载量化后的模型，比如 4bit 或 8bit 量化版本。量化能显著减少模型体积，从而减少磁盘 I/O 量，提升推理速度。但量化会带来精度损失，具体损失多少取决于量化方法和模型本身。
我做过对比：同一个 70B 模型，fp16 版本生成 100 个 token 需要 5 分钟，4bit 量化版本只需要 2 分钟，但输出质量在复杂推理任务上有所下降。所以如果你的任务对精度要求不高，比如简单的文本分类或关键词提取，量化版本是更好的选择。如果任务需要复杂推理，比如数学题或代码生成，建议还是用 fp16。
还有一个折中方案是 8bit 量化，速度提升不如 4bit 明显，但精度损失小很多。你可以根据具体任务来选。
5.3 批量推理与并发控制的边界
airllm 理论上支持批量推理，但批量大小受显存限制。批量越大，同时需要加载的层越多，显存占用越高。我试过批量大小为 4 的情况，显存占用直接翻倍，速度却没有线性提升，因为磁盘 I/O 成了瓶颈。
所以我的建议是，airllm 场景下批量大小设为 1 就好，通过并发多个进程来提升吞吐量。但并发进程数也要控制，因为多个进程同时读磁盘会互相竞争，导致每个进程的速度都下降。一般来说，并发数不要超过磁盘数量，单块 NVMe SSD 建议并发 2-3 个进程。
注意：并发推理时，每个进程都会独立加载模型层，显存占用是叠加的。如果显存不够，并发会导致 OOM。建议先用小模型测试并发上限，再应用到生产环境。
6. 那些让我折腾到半夜的坑
6.1 模型分片缺失导致的加载失败
有一次我从网上下载了一个 70B 模型，下载过程中网络中断了几次，虽然最后显示下载完成，但实际上有一个分片文件是损坏的。airllm 在加载时没有立刻报错，而是在推理到某一层时才卡住。我一开始以为是显存不够，调了半天参数都没用，后来用校验工具检查文件哈希才发现问题。
这个坑的教训是：下载大模型后一定要校验文件完整性。大多数模型仓库会提供文件的哈希值，用sha256sum对比一下，几分钟的事，能省掉几个小时的排查。另外，下载工具最好支持断点续传，避免中断后重新下载整个文件。
6.2 显存碎片化引发的间歇性 OOM
airllm 频繁地分配和释放显存，容易产生显存碎片。表现是：第一次推理正常，第二次推理报 OOM，第三次又正常。这种间歇性问题最难排查，因为不是必现的。
解决方法是设置PYTORCH_CUDA_ALLOC_CONF环境变量，启用更激进的内存回收策略：
export PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True这个设置让 PyTorch 使用可扩展的显存段，减少碎片。我加上这个之后，间歇性 OOM 的问题基本消失了。另外，在每次推理结束后手动调用torch.cuda.empty_cache()也有帮助，但会稍微增加延迟。
6.3 多进程读取同一模型文件的锁竞争
前面提到并发推理能提升吞吐量，但多个进程同时读取同一组模型文件时，可能会遇到文件锁竞争。表现是某些进程的磁盘读取速度骤降，甚至报"文件被占用"的错误。
这个问题的根源是操作系统的文件锁机制。不同进程以只读方式打开同一文件时，理论上不应该有锁竞争，但如果某个进程在读取时试图修改文件元数据（比如更新访问时间），就可能触发锁。解决方法是在挂载磁盘时加上noatime选项，禁止更新访问时间。另外，确保所有进程都以只读方式打开文件。
如果还是有问题，可以给每个进程复制一份模型文件，但这样会占用大量磁盘空间。所以优先尝试noatime方案。
6.4 不同模型架构的兼容性差异
airllm 对主流 Transformer 架构的支持比较好，但一些小众架构或自定义架构可能不支持。我试过一个基于 MoE（混合专家）的模型，airllm 能加载但推理结果不对，因为 MoE 的路由逻辑需要同时访问多个专家层，而 airllm 的按层加载策略假设层是串行的。
所以选模型的时候，尽量选标准的 Llama、GPT、BERT 等架构。如果一定要用特殊架构，先跑一个小规模测试，确认输出正确再上大规模。airllm 的文档里有一个支持模型列表，虽然不一定完整，但可以作为参考。
7. 我对 airllm 适用边界的理解
用了一段时间 airllm 之后，我逐渐摸清了它的适用边界。它最适合的场景是：硬件有限、模型很大、对速度不敏感、需要快速验证想法。比如你在一个实验环境里想测试某个大模型对特定任务的表现，但手头只有一张消费级显卡，那 airllm 就是你的救星。
它不适合的场景是：需要高吞吐量的生产环境、需要实时响应的对话系统、需要频繁调用的 API 服务。这些场景下，airllm 的速度瓶颈会成为致命问题。你应该考虑量化、蒸馏、或者直接租用云端 GPU。
还有一个容易被忽略的点是：airllm 的推理速度受磁盘性能影响极大，所以如果你打算长期使用，投资一块好的 NVMe SSD 比升级显卡更划算。我自己的配置是单张 24GB 显卡加一块 2TB NVMe SSD，跑 70B 模型虽然慢，但稳定可用，成本远低于多卡方案。
最后分享一个小技巧：如果你只是想做模型效果的快速验证，不需要完整生成，可以把max_new_tokens设得很小，比如 16 或 32。这样能大幅缩短单次推理时间，快速判断模型是否适合你的任务。确认适合之后，再跑完整的生成。这个习惯帮我省了很多等待时间。
