1. 单卡跑大模型的现实困境与airllm的破局思路

显存不够这件事，几乎是每个想在自己机器上跑大模型的人都会撞上的第一堵墙。一张24GB显存的消费级卡，想加载一个700亿参数的模型，按FP16精度算，光权重就要吃掉140GB左右的空间，这还没算推理过程中的KV Cache和中间激活值。传统做法要么是多卡并行，要么是量化压缩，要么直接上CPU+内存硬扛——但多卡不是人人都有，量化会损失精度，CPU推理速度又慢得让人抓狂。

airllm这个项目做的事情，说白了就是让大模型在低显存设备上也能跑起来，而且不需要量化。它的核心思路不是把模型压缩变小，而是把模型按层拆分，推理时只加载当前需要的那一层到显存里，用完就释放，下一层再加载。这样一来，显存占用从“整个模型”变成了“单层模型+少量开销”，一张4GB显存的卡理论上就能跑70B的模型。

这个方案解决的核心问题是：显存瓶颈。它适合那些手里只有消费级显卡、但又想跑大参数模型的开发者、研究者和技术爱好者。你不需要买A100，不需要租多卡集群，一台普通带独显的机器就能跑起来。当然，代价也很明显——推理速度会慢，因为每层都要从磁盘或内存重新加载。但对于很多离线场景、实验场景、学习场景来说，这个代价是可以接受的。

我最初接触airllm是在一个需要本地跑大模型做文本分析的项目里，手头只有一张8GB的卡，试过量化方案但效果不理想，后来看到这个思路觉得很有意思，就深入研究了一下它的实现原理和实际表现。下面把我拆解这个项目的完整思路和实操经验分享出来。

2. 核心原理拆解：分层加载到底是怎么工作的

2.1 模型分层加载的基本逻辑

要理解airllm，得先搞清楚Transformer类模型的结构。一个典型的大语言模型由几十到上百个Transformer层堆叠而成，每一层包含自注意力机制和前馈网络。推理时，数据从第一层进去，逐层传递，最后一层输出结果。

传统推理框架的做法是：把整个模型的所有层都加载到显存里，然后数据在显存内部逐层流转。这样做速度快，因为不需要反复搬运数据，但显存占用极高。

airllm的做法完全不同：它把模型文件按层拆分存储，推理时只把当前层加载到显存，计算完这一层后，把这一层的显存释放掉，再加载下一层。数据在层与层之间传递时，中间结果存在内存或显存的一个小缓冲区里。

注意：这里的“释放”并不是真的把显存还给系统，而是标记为可复用。实际实现中会复用同一块显存区域，避免频繁的分配和释放操作。

这个思路的关键在于：单层的参数量远小于整个模型。以一个70B参数的模型为例，假设有80层，每层大约875M参数，FP16精度下每层约1.75GB。加上推理时的中间激活值和KV Cache，单层推理的显存需求大概在2-3GB左右。这意味着4GB显存的卡就能跑起来。

2.2 为什么不做量化也能跑

很多人会问：既然显存不够，为什么不直接量化到4bit或8bit？量化确实能大幅降低显存占用，但它有两个问题：一是精度损失，虽然现在量化技术越来越好，但在某些对精度敏感的任务上，量化后的模型表现会明显下降；二是量化本身需要额外的校准过程，不是所有模型都有现成的量化版本。

airllm选择不做量化，走的是“时间换空间”的路线。它保留了模型的原始精度，推理结果和全量加载完全一致。代价是速度——每层都要从磁盘读取，磁盘I/O成了瓶颈。如果模型存在机械硬盘上，速度会非常慢；存在SSD上会好很多；如果能全部放进内存，速度还能再上一个台阶。

2.3 分层加载的性能瓶颈在哪里

实际跑下来，性能瓶颈主要在两个地方：

第一是磁盘I/O。每层推理都要读取对应的模型文件，如果模型总大小是140GB，分80层，每层约1.75GB，每跑一次推理就要读140GB的数据。机械硬盘的连续读取速度大概在100-200MB/s，算下来光读模型就要十几分钟。SSD能到500MB/s到3GB/s，时间能压缩到几分钟以内。

第二是层间数据传输。每层计算完后，中间结果要从显存传到内存，下一层加载后再从内存传回显存。这个传输量虽然不大，但频繁的PCIe传输也会累积成可观的延迟。

所以airllm的实际表现高度依赖存储介质。我实测下来，同样的模型，放在NVMe SSD上和放在机械硬盘上，推理速度能差5到10倍。

3. 实操环境搭建与模型部署全流程

3.1 硬件与软件环境准备

先说一下我的测试环境，供参考：

软件依赖方面，airllm本身是一个Python包，安装很简单：

pip install airllm

但它底层依赖transformers、torch、accelerate等库，这些会自动安装。需要注意的是，torch版本要和CUDA版本匹配，否则会出现各种奇怪的错误。我建议先用conda创建一个独立环境，避免和系统里的其他包冲突。

conda create -n airllm python=3.10 conda activate airllm pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 pip install airllm

提示：如果你的CUDA版本不是12.1，去PyTorch官网查对应的安装命令。版本不匹配是新手最容易踩的坑，报错信息往往看不懂，但根源就是版本问题。

3.2 模型下载与格式转换

airllm支持HuggingFace格式的模型。你可以直接从HuggingFace下载，也可以用本地已经下载好的模型。下载大模型时建议用huggingface-cli或者git lfs，直接git clone可能会因为文件太大而失败。

huggingface-cli download meta-llama/Llama-2-70b-hf --local-dir ./llama-70b --local-dir-use-symlinks False

下载完成后，airllm需要把模型转换成它自己的分层格式。这个转换过程会自动进行，第一次加载模型时会花比较长的时间。转换的逻辑是把原始模型文件按层拆分，每层存成独立的文件，同时生成一个索引文件记录层的顺序和位置。

转换后的模型目录结构大概是这样：

llama-70b-airllm/ ├── layer_0.safetensors ├── layer_1.safetensors ├── ... ├── layer_79.safetensors ├── config.json └── index.json

注意：转换过程需要足够的磁盘空间，大概是原始模型大小的1.5倍左右。因为转换过程中原始文件和拆分后的文件会同时存在，转换完成后可以删掉原始文件释放空间。

3.3 加载模型与推理测试

加载模型和推理的代码非常简洁，airllm封装得很好：

from airllm import AutoModel model = AutoModel.from_pretrained("./llama-70b-airllm") input_text = ["请用一句话解释什么是机器学习。"] input_tokens = model.tokenizer(input_text, return_tensors="pt", return_attention_mask=False, truncation=True, max_length=128, padding=False) 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)

这段代码看起来和普通的transformers推理没什么区别，但底层做的事情完全不同。AutoModel.from_pretrained会读取索引文件，准备好分层加载的逻辑。generate调用时，每一层都会动态加载和释放。

第一次跑的时候会感觉特别慢，因为要等模型转换完成。转换完成后再次运行就快很多了。我实测70B模型在8GB卡上，生成64个token大概需要3到5分钟，具体取决于SSD速度和CPU性能。

3.4 关键参数调优与显存控制

airllm有几个关键参数可以调节，直接影响显存占用和速度：

max_seq_len：控制输入序列的最大长度。这个参数直接影响KV Cache的大小，设得越大显存占用越高。如果只是做短文本生成，设成128或256就够了。

layer_shards_saving_path：指定分层文件的存储路径。如果你有多个硬盘，可以把模型放在最快的那个盘上。

compression：airllm支持对分层文件做压缩，进一步减少磁盘占用。但压缩和解压会消耗CPU时间，需要权衡。

prefetching：是否预取下一层。开启后会在当前层计算的同时异步加载下一层，能显著提升速度，但会额外占用一些内存。

我一般会这样配置：

model = AutoModel.from_pretrained( "./llama-70b-airllm", max_seq_len=256, compression=None, prefetching=True )

提示：prefetching对速度提升很明显，但需要足够的内存做缓冲。如果内存不够，反而会因为频繁的swap导致速度下降。建议至少32GB内存再开这个选项。

4. 性能实测与优化经验分享

4.1 不同存储介质下的速度对比

我分别在三种存储介质上跑了同一个70B模型，生成32个token的耗时如下：

这个数据很直观地说明了存储介质的重要性。如果你打算认真用airllm跑大模型，NVMe SSD基本是必须的。机械硬盘虽然能跑，但速度慢到几乎不可用。

4.2 内存充足时的加速方案

如果你有足够大的内存（比如128GB），可以把整个模型先加载到内存里，然后让airllm从内存加载每一层，而不是从磁盘。这样速度会快很多，因为内存的读取速度是磁盘的几十倍。

实现方式是用tmpfs或者ramdisk把模型目录挂载到内存里：

sudo mkdir /mnt/ramdisk sudo mount -t tmpfs -o size=160G tmpfs /mnt/ramdisk cp -r ./llama-70b-airllm /mnt/ramdisk/

然后把模型路径指向/mnt/ramdisk/llama-70b-airllm。这样每层加载都是从内存读取，速度能提升到接近全量加载的水平。当然，前提是你的内存足够大，能装下整个模型。

4.3 实际使用中的注意事项

第一，模型转换是一次性的，但很耗时。70B模型的转换过程大概需要30到60分钟，取决于磁盘速度。建议在晚上或者不需要用机器的时候做转换。

第二，不要频繁切换模型。每次切换模型都要重新加载索引和初始化，虽然比转换快，但也有开销。如果要做多个模型的对比实验，建议一次性跑完一个再换下一个。

第三，注意散热。长时间推理会让GPU和SSD都处于高负载状态，散热不好的话会降频。我一开始用笔记本跑，跑了半小时后速度明显下降，后来加了散热底座才好一些。

第四，batch size不要设太大。airllm本身对batch的支持有限，设太大反而会因为显存不足而报错。建议batch size设为1，需要处理多条数据时用循环逐条处理。

5. 常见问题排查与避坑指南

5.1 加载模型时报错“Out of Memory”

这是最常见的问题。虽然airllm的设计目标就是低显存，但在某些环节仍然可能爆显存。常见原因和解决方法：

提示：如果显存实在太小（比如4GB），可以把max_seq_len设成64，max_new_tokens设成32，这样基本能跑起来，只是生成的内容会很短。

5.2 推理速度异常慢

如果速度比预期慢很多，按以下顺序排查：

先看磁盘I/O是不是瓶颈。用iostat或者iotop查看磁盘读取速度，如果磁盘利用率接近100%，说明瓶颈在磁盘。换SSD或者把模型放到内存里能解决。

再看CPU是不是瓶颈。airllm在层间传输数据时会用到CPU做内存拷贝，如果CPU性能太差或者被其他任务占满，也会拖慢速度。用htop看一下CPU利用率。

最后看GPU利用率。如果GPU利用率很低（比如低于30%），说明GPU大部分时间在等数据，瓶颈在数据加载环节。如果GPU利用率很高但速度还是慢，说明GPU本身算力不够。

5.3 生成结果质量有问题

airllm本身不改变模型的计算逻辑，所以生成质量应该和全量加载一致。如果发现结果异常，检查以下几点：

确认模型转换过程没有出错。转换时如果磁盘空间不足或者中途中断，可能导致某些层文件损坏。重新转换一次试试。

确认输入tokenization没有问题。airllm用的是模型自带的tokenizer，如果tokenizer配置有问题，输入编码会出错。可以先用小模型测试一下tokenizer是否正常。

确认没有混用不同版本的模型文件。有时候下载了多个版本的模型，路径指错了，加载了不匹配的层文件，会导致结果混乱。

5.4 实操避坑清单

• 模型转换前确保磁盘有足够空间，建议预留原始模型大小2倍以上的空间
• 转换过程中不要中断，中断后需要删除临时文件重新开始
• 推理时关闭其他不必要的后台程序，尤其是占用磁盘和内存的
• 如果用的是Windows系统，建议在WSL2里跑，原生Windows的支持不如Linux完善
• 定期检查SSD健康状态，大量读写对SSD寿命有影响
• 模型文件不要放在网络挂载的磁盘上，网络延迟会让速度慢到无法忍受

6. 适用场景分析与替代方案对比

6.1 airllm适合什么场景

airllm最适合的场景是离线实验和学习研究。比如你想在自己的机器上跑一个70B模型看看效果，但手头只有一张消费级显卡，airllm就能派上用场。它不需要量化，结果和全量加载一致，适合做精度敏感的实验。

另一个适合的场景是低频推理任务。比如你有一个每天只需要跑几次的文本分析任务，对延迟不敏感，但对结果精度要求高，airllm就很合适。反正一天就跑几次，慢一点无所谓。

不适合的场景也很明显：高并发、低延迟的在线服务。airllm的推理速度决定了它不可能支撑实时交互，如果你要做聊天机器人或者API服务，还是得用量化方案或者多卡方案。

6.2 和其他低显存方案的对比

从表里能看出来，airllm的定位很明确：用速度换显存，且不牺牲精度。它填补了一个空白——那些既没有多卡条件、又不想牺牲精度的用户，终于有了一个可用的方案。

6.3 后续可以扩展的方向

airllm目前还在持续迭代，我关注到几个有意思的方向：一是对更多模型架构的支持，现在主要支持Llama系，后续可能会扩展到更多模型；二是对量化+分层的混合方案的支持，如果能结合量化和分层加载，速度和显存都能兼顾；三是对多模态模型的支持，如果能跑视觉-语言模型，应用场景会更广。

我自己在实际使用中的体会是，airllm最大的价值不是它有多快，而是它降低了跑大模型的门槛。以前想跑70B模型，要么租云服务器，要么买多张卡，现在一张8GB的卡就能跑起来，虽然慢，但至少能跑。对于学习和实验来说，这个意义很大。

最后分享一个小技巧：如果你只是想测试模型效果，不需要生成很长的文本，可以把max_new_tokens设成16或32，这样单次推理时间能控制在几分钟以内，迭代实验的效率会高很多。等确定了prompt和参数，再跑长文本生成。