我手里那块8GB显存的显卡，过去一年最大的作用就是看别人跑大模型。7B量化勉强能跑，生成速度感人；13B想都不敢想；70B这个词基本等于"别人的玩具"。直到我遇到AirLLM这个项目，思路才算打开了——它不要求你把整个模型塞进显存，而是把Transformer一层一层拆开，算一层、放一层、丢一层，单显卡也能挑战超大模型。这篇文章围绕AirLLM的分层推理方案，讲讲它的原理、完整的上手流程、实测数据，以及我在使用过程中踩过的那些坑，适合手里显卡不太行、但又想在本地跑大模型的人参考。
1. 显存不够这件事，为什么这么要命
1.1 大模型对显存的消耗结构
很多人以为大模型占显存主要是"参数多"，这个理解方向对，但不完整。以常见的7B模型为例，FP16精度下每个参数占2字节，光权重就是14GB；13B模型是26GB；70B模型更是高达140GB。这还只是权重，没有算上推理过程中的KV Cache、中间激活值、临时缓冲。所以8GB显卡连7B模型的FP16权重都装不下，更不用说部署。
这里有一个容易忽略的点：一次推理并不是只加载一遍权重那么简单。Transformer是逐层计算的，每一层的输出会成为下一层的输入。中间激活值的峰值往往出现在长序列输入时，序列越长，激活值越大。这也是为什么很多人用小显存跑量化模型，依然会在输入长文本时直接OOM。
1.2 现有主流方案的局限
面对显存墙，主流思路大体有几种，各自都有代价：
- 量化：把权重从FP16压成INT8或INT4，显存占用直接除以2或4。但量化只能解决权重体积，解决不了"整个模型权重必须同时驻留显存"这个前提。4bit的7B模型大约4GB，8GB卡能跑，但4bit的70B模型仍需约35GB，普通卡依然无解。
- 多卡并行：用张量并行把模型切到多张卡上，对个人玩家来说多卡成本太高。
- 云端API：花钱买服务，数据要出本地，很多场景根本不适合。
这些方案本质上都在"让模型完整驻留显存"这个前提下想办法。AirLLM的切入点不太一样：它承认显存放不下，干脆把模型切成一段一段，用"时间"换"空间"。
2. AirLLM的分层推理原理拆解
2.1 关键洞察：Transformer层的天然隔离性
Transformer模型的结构是线性的，由多个重复的Decoder层堆叠而成。对输入序列做前向计算时，流程非常固定：先过Embedding，再过第0层，输出传给第1层，再传给第2层……直到最后输出层。
这个结构带来一个重要特性：在计算某一层时，其他层的参数并没有参与运算。理论上，只需要当前层的参数在显存里就行。既然只需要当前层，那就不必把全部层常驻显存，完全可以算完一层就把它放回内存，再把下一层搬上显存。这正是AirLLM依赖的核心特性。
说得更具体一点：AirLLM把模型按层切分，每次只将当前层参数移动到GPU进行前向计算，计算完成后立刻把层参数移回CPU内存，只保留必要的小数据在GPU上，比如KV Cache和近期激活值。这样显存占用被压缩到"一层参数加中间缓存"的量级，而不是"整个模型"的量级。
2.2 算完即走的执行流程
用一个完整的生成过程来说明会更清楚：
- 输入文本被分词、转为token id，经过Embedding得到初始特征。
- 对第0层：从CPU内存或磁盘加载第0层参数到GPU显存，在GPU上完成第0层前向计算，输出特征保留，第0层参数释放或移回内存。
- 对第1层重复相同操作，依次类推，直到所有层计算完毕。
- 最后通过输出层得到下一个token的概率分布。
- 生成下一个token时，使用已有KV Cache从第0层重新开始计算，重复上述过程。
这里的关键是：每次推理，每一层的参数都会在内存和显存之间走一遍。70B模型有几十层，哪怕每层只有几百MB，逐层搬运带来的累计数据量也很惊人。但正因为如此，单卡跑大模型才真正变为了可能。
2.3 为什么它慢，但依然有价值
如果只看单token生成速度，AirLLM肯定比整模型驻留显存的方式慢很多。它本质上是用PCIe总线带宽和CPU内存带宽，去换取GPU显存容量。
一个比较直观的类比：整模型驻留显存相当于在自己客厅里摆好了所有家具，随时能用，速度快但占地大；AirLLM相当于只有一个房间，需要的时候才从仓库把家具搬进来，摆好、用完、再搬走。搬家耗时很长，但仓库够大，你能体验到的"使用空间"就大了很多倍。
所以AirLLM适合的场景非常明确：目标是跑通，是让模型能加载、能推理、能出结果，而不是追求高并发和低延迟。对个人开发者调试、离线批量推理、教学演示、验证模型效果来说，慢一点完全可接受。
3. 把AirLLM跑起来的完整流程
3.1 环境准备
AirLLM依赖PyTorch和HuggingFace生态，需要先保证基础环境可用。我用的环境是Linux系统、Python 3.9、CUDA 12.1、PyTorch 2.1。安装很直接：
pip install airllm需要留意的是，AirLLM会去HuggingFace加载模型，所以建议提前设置好HuggingFace的下载缓存目录，并且保证网络能正常访问模型仓库。如果下载容易断，可以设置环境变量HF_HUB_ENABLE_HF_TRANSFER=1来启用更快的传输方式。
提示：如果服务器上没有外网权限，最省事的做法是在有网的机器上把模型下载好，然后把
~/.cache/huggingface整个目录拷贝过去。AirLLM在加载时发现本地已有缓存，就不会再去远程拉取。
3.2 最小示例：用AirLLM跑一次推理
这里以某个开源中文对话模型为例，演示AirLLM的使用方式。
from airllm import AutoModel import torch # 指定模型名，AirLLM会自动下载权重 model = AutoModel.from_pretrained("some/open-chat-model-7b") # 把模型设置为AirLLM的自动调度模式 model.to("auto") model.eval() prompt = "请用三句话介绍秋天的景色" inputs = tokenizer(prompt, return_tensors="pt").to("cuda") with torch.no_grad(): output = model.generate( inputs.input_ids, max_new_tokens=50, do_sample=True, top_p=0.9, temperature=0.8, pad_token_id=tokenizer.eos_token_id, ) print(tokenizer.decode(output[0], skip_special_tokens=True))AirLLM对transformers的API做了兼容，很多现有代码只需要改动加载方式就能跑通。它支持多个入口：AirLLMLlama2专门针对Llama结构优化，AutoModel适配更多模型。
这里有个容易误解的点：model.to("auto")并不是把模型全部参数搬到GPU，而是让AirLLM接管参数调度。真正意义上的"搬"发生在每一层计算时。初始化阶段看到的显存占用可能很小，这是正常的。
3.3 关键配置参数的意义
AirLLM有几个常用参数，理解它们能帮你省很多麻烦：
mem_threshold：触发参数卸载的阈值。默认情况下框架会尽量多保留一些层在显存中以提升速度，但如果显存很紧张，可以调低这个值，让它更早把层放回内存。batch_size：推理批大小。增大batch_size能摊薄逐层搬运的开销，因为同一层参数可以被多个样本复用。但batch_size过大会增加KV Cache和激活值显存占用。max_length：序列最大长度，直接影响KV Cache大小。长文本场景会明显增加显存压力，因为KV Cache需要占用显存。
这几个参数本质上是在"GPU容量"和"搬运开销"之间做权衡。我自己的经验是，显存不足时优先调低mem_threshold和max_length，而不是急着换batch_size。
4. 实测效果：哪些模型能跑、速度到底多慢
4.1 不同参数规模在8GB显卡上的表现
我手头没有特别好的卡，用8GB显存的显卡做了一轮实测，测试模型均为4bit量化版本，输入prompt长度约200 token，生成50 token。数据大致如下（不同卡、不同驱动会有差异，仅供参考）：
| 模型规模 | 显存占用峰值 | 首token耗时 | 平均生成速度 |
|---|---|---|---|
| 7B量化 | 约4.5GB | 约15s | 约1.8 token/s |
| 13B量化 | 约6.2GB | 约30s | 约0.9 token/s |
| 70B量化 | 接近8GB | 约120s | 约0.2 token/s |
7B尚可日常调试用，13B属于"能忍"的范畴，70B则只适合跑离线任务。毕竟启动一次推理就要等几分钟首token，交互式使用基本没戏。
需要说明的是，首token耗时包含prefill阶段，这个阶段需要把所有层都过一遍，所有来回搬运都要发生一次，所以时间特别长。之后的每个token也要过全量层，但方向上是逐层搬运、计算，开销依然很高。
4.2 速度瓶颈到底卡在哪
我在实测中通过nvidia-smi和系统监控工具观察运行时状态，发现瓶颈几乎不在GPU算力上。GPU利用率经常只有20%上下，大量时间卡在数据搬运上。具体来说：
- PCIe 3.0 x16的带宽约16GB/s，假设70B模型每层参数约500MB，搬上搬下就是1GB流量，每秒能搬十几层已经不错了。几十层串行下来，单次前向的搬运时间轻松超过1秒。
- CPU内存带宽同样会成为瓶颈。如果模型被换出到普通机械硬盘或SATA SSD，速度更感人，NVMe SSD会好很多。
- 生成阶段无法避免地逐token重新计算全部层，每一层都要搬运一次，没有可并行的空间。
所以这里有个很实用的优化方向：如果AirLLM把层放在CPU内存里，就尽量让CPU内存带宽大一些；如果落到磁盘上，就把交换目录放到NVMe上。数据从哪来，直接决定你能跑多快。
4.3 和其他低显存方案的对比
很多人会拿AirLLM和llama.cpp、vLLM等方案对比。它们解决的问题有交集，但侧重点不同：
| 方案 | 核心思路 | 显存要求 | 速度 | 适用场景 |
|---|---|---|---|---|
| llama.cpp (GGUF) | 量化加尽量加载，内存溢出兜底 | 权重压缩后尽量驻留，可溢出到内存 | 中等 | 模型较小、要求能跑就行 |
| vLLM | 高效推理框架 | 需要足够显存容纳完整模型 | 快 | 服务化部署、高并发 |
| AirLLM | 逐层搬运 | 单层显存即可，低显存甚至CPU-only | 慢 | 个人本地实验、超小显存 |
llama.cpp也能把超出显存的部分放到内存，但它的假设是"能加载尽量加载、溢出部分走swap"；AirLLM则是"默认就逐层卸载、显存只容纳单层"。所以同样8GB显存跑70B时，AirLLM反而可能更稳，因为它的调度模型是显存友好型的。
注意：两者并不冲突。实际使用中我也见过有人把AirLLM和量化权重叠加使用，即先用量化把单层体积压得更小，再用逐层调度运行。这种组合能跑更大的模型，或者给KV Cache留出更多显存。
5. 排错与调优：我在使用中踩过的坑
5.1 "还有显存却报OOM"：mem_threshold的坑
我第一次跑13B模型时，显存明明只用了5GB，却报CUDA OOM。后来查了源码和讨论区，才发现AirLLM对"单层可驻留层数"有一个默认策略，它会尝试把尽可能多的层缓存到显存以提速，默认阈值下可能同时保留多个层，占用的显存比预期大得多。
解决方案是显式调小mem_threshold参数，例如：
model = AutoModel.from_pretrained("some/open-chat-model-13b", mem_threshold=0.2)把阈值调到0.2意味着显存利用率达到20%就开始主动卸载层。这样能避免框架贪心缓存导致的OOM。代价是每层都搬运，速度会更慢，但在显存紧张时这是必要的。
5.2 模型加载中断：本地缓存损坏
AirLLM在下载大模型时如果网络不稳定，很容易出现半截文件。HuggingFace的缓存体系一般能识别损坏文件，但偶尔也会因为并发下载导致重复文件占满磁盘。我的处理方式是：
# 查看本地缓存，删除明显未完成的分块文件 du -sh ~/.cache/huggingface/*更好的做法是启用HF_HUB_ENABLE_HF_TRANSFER=1并配合hf_transfer库，下载速度提升不少，断点续传也稳定一些。
5.3 输入序列过长导致KV Cache爆掉
长文档、多轮对话这类场景，KV Cache是线性增长的。比如40层的模型，每层缓存大小是seq_len乘hidden_dim再乘头数，seq_len从512加到2048，KV Cache体积会翻好几倍。而AirLLM的KV Cache在默认配置下会占用显存，所以输入过长时会迅速吃掉显存。
办法是尽量控制在较短上下文里生成，或者用截断方式压缩输入。我一般设置max_new_tokens不超过256，上下文超过800 token就做摘要而非直接生成。
5.4 让速度提升一截的几个实用手段
这三个优化是我实测后觉得性价比最高的：
- 优先用4bit量化权重。量化后每层参数变小，搬运数据量直接减半，对逐层方案来说提升非常明显。用AirLLM跑量化模型通常比FP16模型快一半以上。
- 调大batch_size但别超过2。在显存允许的前提下，batch=2能让两层之间的参数搬运被两个样本分摊，吞吐提升约30%，但batch=4很容易把KV Cache顶爆。
- 把设备临时目录放到NVMe上。如果模型被换出到磁盘而非CPU内存，就务必让交换分区位于NVMe SSD，机械硬盘的随机读写会让单层加载慢到一个难以忍受的程度。
6. 聊点更深的：AirLLM之后还能怎么玩
6.1 用AirLLM做低显存评测
我个人觉得AirLLM在"评测和对比模型"这个场景里被低估了。很多测评脚本只需要跑完特定测试集并输出分数，并不要求低延迟。当你手里只有一张低显存卡，又需要在本地验证某个开源模型的效果时，AirLLM是性价比很高的选择。跑一批样本可能要几十分钟，但跑完就是跑完，结果和常规方案差异不大。
6.2 和LoRA适配组合
AirLLM本身定位是推理库，但配合PEFT库，可以在CPU/GPU混合调度下做低资源适配。思路是：模型权重量化后使用LoRA，只训练适配器，模型权重不需要全部驻留显存。这样即使是消费级显卡，也能对超大参数量的开源模型做参数高效微调实验。当然速度不理想，但用于验证和原型测试是可行的。
6.3 它的局限，也得说清楚
AirLLM不是银弹。如果你要做生产级服务、高并发对话、实时流式输出，它并不合适。它的延迟会随模型增大而急剧恶化，70B级别基本告别交互式体验。另外它对长上下文的支持也比较吃力，因为KV Cache常驻显存的策略限制了序列长度。所以别拿AirLLM硬扛大并发场景，那不是它该做的。
6.4 我个人的选择建议
用了AirLLM一段时间后，我的倾向是把它定义为"最后一公里的工具"。如果你手里有超过12GB的显存，跑13B以下模型时，常规加载、量化方案通常体验更好；但当你只有8GB甚至6GB，却非要在本地跑某个70B模型验证结果时，AirLLM就是那个让你不用云服务器也能完成的方案。说白了，它增加了你手上硬件的能力上限，而不是让一切都变快。
在我实际使用中，最舒服的工作流是：把AirLLM当作"慢但稳"的底层调度器，模型用量化权重，输入尽量精简，batch=1跑离线任务。调参时优先调mem_threshold，显存不够了再考虑砍序列长度，最后才动batch_size。这套顺序帮我省下了不少排查时间。如果你也正拿着一块低显存卡纠结"到底能不能跑大模型"，不妨先把它装上试一版，跑通之后你会有一种"硬件天花板被掀开了一层"的错觉——虽然慢，但真的能跑。
