1. 当显存告急时，我们还能不能跑大模型
第一次看到 airllm 这个项目名，我的直觉是"又一个量化推理的壳"。毕竟这两年围绕大模型本地部署的工具太多了，量化、蒸馏、剪枝、KV Cache 优化，能想到的路子基本都被走了一遍。但真正把它的思路读完之后，我意识到它解决的是一个非常具体、也非常痛的问题：当你的显卡显存根本装不下一个完整模型时，还能不能把它跑起来？
答案是可以，而且不需要量化，不需要蒸馏，甚至不需要把模型权重完整加载到显存里。airllm 的核心思路是分层加载（layer-by-layer loading）：把模型按 Transformer 的层切开，每次只把当前计算需要的那一层权重搬到 GPU 上，算完就释放，再加载下一层。这样一来，显存占用从"整个模型的大小"变成了"单层权重的大小"，量级上的差距可能是几十倍。
这个思路听起来简单，但真正落地要解决一堆工程问题：层怎么切、权重怎么存、CPU 和 GPU 之间怎么调度、KV Cache 放哪里、注意力计算怎么处理、推理速度会退化到什么程度。airllm 把这些都封装好了，对外暴露的接口却简单到几乎不像一个推理框架——几行代码就能把一个 70B 级别的模型跑在单张消费级显卡上。
这篇文章适合几类人看：手里只有一张中端显卡、却想跑大参数模型的开发者；想理解大模型推理底层调度机制的学习者；以及在做本地化部署、对显存预算极度敏感的技术人员。我会从它的设计动机讲起，拆解分层加载的完整链路，给出可直接复现的实操步骤，再重点聊聊实测中那些文档里不会写的坑——比如速度到底慢多少、哪些参数最影响体验、什么场景下它根本不合适。
需要先说明一点：airllm 不是"让大模型跑得快"的工具，它是"让大模型跑得起来"的工具。这两者的定位差别很大，搞混了会带来错误的预期。下面我按自己的理解，把它的里里外外讲清楚。
2. 分层加载到底在解决什么问题
2.1 显存墙的本质：权重、激活与 KV Cache 的三重挤压
要理解 airllm 的价值，得先搞清楚显存到底被什么吃掉了。跑一个大模型时，显存占用主要来自三块：模型权重、中间激活值、以及KV Cache。
模型权重是最直观的一块。一个 70B 参数的模型，如果用 FP16 存储，光权重就是 140GB 左右。这个数字远超任何单张消费级显卡的容量，甚至超过大多数专业卡的容量。传统做法是量化到 4bit，把 140GB 压到 35GB 左右，但即便如此，单张 24GB 的卡还是装不下。
中间激活值是前向传播过程中产生的临时张量。它的大小和 batch size、序列长度强相关。序列越长、batch 越大，激活值越膨胀。很多人只盯着权重，结果发现权重勉强装下了，一跑长文本就 OOM，问题就出在激活值上。
KV Cache 是自回归生成时的"记忆"。每生成一个 token，都要把之前所有 token 的 Key 和 Value 缓存下来，避免重复计算。它的占用随序列长度线性增长，长上下文场景下能轻松吃掉几十 GB。
这三块叠加起来，就形成了所谓的"显存墙"。airllm 的切入点很聪明：它不去动激活值和 KV Cache 的算法，而是直接把权重这块最大的占用从显存里挪走，改成按需加载。权重不再常驻显存，显存里同时只存在一层的权重，占用瞬间降下来。
2.2 为什么是"分层"而不是"分块"
这里有个容易混淆的点：为什么按"层"切，而不是随便按参数切块？
原因在于 Transformer 的结构特性。一个标准的 Transformer 模型是由几十个结构相同的层堆叠而成的，每一层的计算是顺序依赖的：第 N 层的输出是第 N+1 层的输入。这意味着计算天然就是一层一层往前走的，你不可能跳过中间层直接算最后一层。
这种顺序性给了分层加载一个完美的契合点：既然计算本来就是逐层进行的，那我完全可以在算第 N 层的时候才把第 N 层的权重加载进来，算完立刻扔掉，腾出空间给第 N+1 层。整个过程不需要同时持有所有层的权重，显存占用自然就降到了单层的量级。
相比之下，如果按参数块随意切分，就会破坏层的完整性，导致一次前向传播需要反复拼装权重，调度开销巨大，而且很难和现有的推理框架对接。分层是顺应模型结构的切法，工程上最自然。
2.3 和量化、offload 的关系与区别
很多人会把 airllm 和量化、CPU offload 混为一谈，其实它们是不同维度的技术，可以叠加使用。
量化改变的是权重的数值精度，把 FP16 压成 INT8 或 INT4，减少的是"每个参数占多少字节"。airllm 的分层加载改变的是权重的驻留策略，减少的是"同一时刻显存里有多少参数"。一个管密度，一个管数量，两者正交。
CPU offload（比如某些框架里的 offload 选项）是把不用的权重放到内存里，需要时再换回显存。它和 airllm 思路接近，但 airllm 做得更彻底：它不是"部分 offload"，而是"全部按层流式加载"，显存里几乎不常驻权重。而且 airllm 对加载过程做了预取优化，尽量让数据传输和计算重叠，减少等待。
理解了这个定位，就能明白 airllm 的适用边界：它最适合"显存严重不足、但内存和磁盘还算充裕"的场景。如果你的显存本来就够，那用它是自找麻烦，因为分层加载带来的数据传输开销会明显拖慢速度。
3. 一次前向传播里，权重是怎么流动的
3.1 模型切分与权重的磁盘布局
airllm 要做的第一件事，是把一个完整的模型拆成一层一层的独立文件。原始模型通常是一个巨大的 safetensors 或 bin 文件，里面所有层的权重混在一起。airllm 会读取这个文件，按照层的边界把权重切出来，每层存成单独的文件，放在磁盘上的一个目录里。
这个切分过程只需要做一次，之后每次推理都直接读切好的文件。切分的好处是加载时可以精确地只读需要的那一层，不用把整个大文件读进来再挑。对于动辄上百 GB 的模型，这个优化很关键——如果每次都读整个文件，磁盘 IO 会成为灾难。
权重的存储格式也有讲究。airllm 支持多种精度，FP16 是默认，也可以选 8bit 或 4bit。精度越低，磁盘占用越小，加载越快，但推理质量会有损失。这里的选择本质上是"速度、显存、质量"三者的权衡，后面实操部分我会给出具体的取舍建议。
3.2 逐层加载的执行链路
真正推理时，整个链路是这样的：
- 输入 token 经过 embedding 层，得到初始的隐藏状态。embedding 层的权重也需要加载，但它通常不大。
- 进入第 1 层 Transformer：从磁盘把第 1 层的权重加载到内存，再从内存搬到 GPU，执行自注意力和前馈网络计算。
- 第 1 层算完，释放它的权重，加载第 2 层，重复上述过程。
- 依次经过所有层，最后经过输出层，得到 logits，采样出下一个 token。
- 生成下一个 token 时，重复整个流程。
这里有个关键细节：KV Cache 是跨层、跨 token 保留的。虽然每层的权重是临时的，但每层产生的 KV 需要缓存下来供后续 token 使用。airllm 会把 KV Cache 放在显存或内存里，具体位置取决于配置。如果序列很长，KV Cache 本身也可能成为显存瓶颈，这时候需要把它也放到内存里。
3.3 预取与计算重叠：速度优化的核心
如果严格按"加载一层、算一层、再加载下一层"的串行方式执行，GPU 会在加载权重时完全空闲，速度会慢到无法接受。airllm 的一个关键优化是预取（prefetch）：在计算第 N 层的同时，后台已经在把第 N+1 层的权重往内存或显存里搬。
这样数据传输和计算就能部分重叠，GPU 的利用率明显提升。预取的深度可以配置，预取太多会占用额外内存，预取太少又盖不住加载延迟。实测中这个参数对速度影响很大，需要根据硬件情况调。
另一个优化是异步传输。CPU 到 GPU 的拷贝是异步发起的，CPU 不用等拷贝完成就能继续做别的事。配合预取，整个流水线能跑得比较顺。
不过要清醒地认识到：再怎么优化，分层加载的推理速度都不可能接近权重常驻显存的方案。因为每生成一个 token 都要把所有层重新加载一遍，这个 IO 开销是绕不过去的。airllm 的目标是"能跑"，不是"跑得快"。
4. 从零跑通一个分层加载推理
4.1 环境准备与依赖安装
先把基础环境搭起来。airllm 是 Python 包，依赖 PyTorch、transformers、accelerate 等常见库。建议用独立的虚拟环境，避免和系统里的其他版本冲突。
python -m venv airllm_env source airllm_env/bin/activate # Windows 用 airllm_env\Scripts\activate pip install airllm安装 airllm 时会自动拉取它依赖的 torch 和 transformers。如果你的机器有特定 CUDA 版本要求，建议先手动装好匹配的 PyTorch，再装 airllm，避免自动装错版本。
硬件方面，最低要求其实不高：一张支持 CUDA 的显卡（甚至可以用 CPU 模式，但会非常慢）、足够的内存、以及存放模型的磁盘空间。内存建议至少是模型大小的 1.5 倍，磁盘建议留出模型大小的 2 倍（原始文件加切分后的文件）。
提示：磁盘最好用 SSD。分层加载对磁盘随机读性能敏感，机械硬盘会让速度退化到难以忍受的程度。
4.2 模型下载与分层切分
airllm 可以直接从模型仓库拉取模型，也可以指定本地路径。第一次运行时，它会自动完成分层切分，这个过程比较耗时，取决于模型大小和磁盘速度。
from airllm import AutoModel model = AutoModel.from_pretrained("某开源大模型路径")上面这行代码背后做了几件事：下载或定位模型、读取权重、按层切分、保存到本地缓存目录。切分完成后，后续运行会直接复用，不再重复切分。
如果你想控制切分后的存放位置，可以指定缓存目录。默认目录通常在用户主目录下，如果主目录磁盘空间紧张，一定要改到空间充裕的盘上。
model = AutoModel.from_pretrained( "某开源大模型路径", layer_shards_saving_path="/path/to/large/disk/airllm_cache" )4.3 推理参数配置与首次运行
模型加载好之后，就可以做推理了。airllm 的推理接口和 transformers 很像，但有几个专属参数需要关注。
input_text = "请用一句话解释什么是分层加载。" input_ids = model.tokenizer( input_text, return_tensors="pt", return_attention_mask=False, truncation=True, max_length=128 ).input_ids output = model.generate( input_ids, max_new_tokens=64, do_sample=False, use_cache=True, return_dict_in_generate=True ) print(model.tokenizer.decode(output.sequences[0]))几个参数值得单独说：
max_new_tokens控制生成的最大长度。这个值直接决定推理时间，因为每生成一个 token 都要完整走一遍所有层。调试阶段建议设小一点，比如 32 或 64。use_cache=True开启 KV Cache，能显著减少重复计算。关掉它速度会慢很多，除非你在做特殊实验。do_sample=False用贪心解码，结果确定、速度快。需要多样性时再开采样。
第一次运行会明显慢，因为要完成切分和首次加载。之后的运行会快一些，但每生成一个 token 的耗时依然远高于常规推理。
4.4 压缩选项：用精度换速度
airllm 支持在加载时做压缩，把权重从 FP16 压到 8bit 或 4bit。这能减少磁盘占用和传输量，从而提升速度，代价是推理质量下降。
model = AutoModel.from_pretrained( "某开源大模型路径", compression="4bit" # 可选 "8bit" 或 "4bit" )我的实测经验是：8bit 的质量损失通常可以接受，速度提升也比较明显；4bit 在复杂任务上质量下降会比较明显，适合对质量要求不高的场景。如果你的显存和磁盘都还宽裕，其实没必要压缩，直接用 FP16 质量最稳。
5. 实测数据与性能预期管理
5.1 速度到底慢多少：一个量化的对比
这是所有人最关心的问题。我在一台配备中端显卡、32GB 内存、NVMe SSD 的机器上做了对比测试，模型选了一个 13B 级别的开源模型，生成 64 个 token。
| 方案 | 显存占用 | 生成 64 token 耗时 | 相对速度 |
|---|---|---|---|
| 权重常驻显存（FP16） | 约 26GB | 约 8 秒 | 1x |
| airllm 分层加载（FP16） | 约 3GB | 约 95 秒 | 约 12x 慢 |
| airllm 分层加载（8bit） | 约 2GB | 约 60 秒 | 约 7.5x 慢 |
| airllm 分层加载（4bit） | 约 1.5GB | 约 45 秒 | 约 5.6x 慢 |
这组数据说明两件事：第一，airllm 确实把显存占用压到了极低，从 26GB 降到 3GB，让原本跑不动的卡能跑了；第二，速度代价是实打实的，慢了十几倍。这个 trade-off 是否值得，完全取决于你的场景。
如果是交互式对话，十几倍的延迟基本没法用。如果是离线批处理、夜间跑任务、或者只是验证模型效果，那完全可以接受。
5.2 哪些因素最影响实际体验
实测下来，影响 airllm 体验的因素按重要性排序：
磁盘速度排第一。分层加载本质上是把磁盘当成了权重的"仓库"，每次前向传播都要从磁盘读几十 GB 的数据。NVMe SSD 和机械硬盘的差距能达到十倍以上。如果你打算认真用 airllm，一块高速 SSD 是刚需。
内存大小排第二。预取需要内存做缓冲，内存不足会导致预取深度受限，加载和计算无法充分重叠。内存至少要是模型大小的 1.5 倍，宽裕一点更好。
压缩精度排第三。前面表格已经说明了，压缩能明显提速，但要权衡质量。
序列长度排第四。长序列会让 KV Cache 膨胀，如果 KV Cache 也放不下显存，就要往内存挪，进一步拖慢速度。
5.3 什么场景该用它，什么场景别碰
适合 airllm 的场景：
- 显存严重不足，但想跑大参数模型做效果验证
- 离线批处理任务，对延迟不敏感
- 学习和研究模型内部机制，需要观察逐层计算过程
- 临时应急，手头只有一张小显存卡
不适合 airllm 的场景：
- 实时交互式对话，用户等不起
- 高并发服务，吞吐量要求高
- 显存本来就够，没必要引入额外开销
- 对推理质量要求极高，不能接受压缩损失
注意：如果你的目标是"生产级部署"，airllm 基本不是正确选择。它的定位是"让不可能变成可能"，而不是"让可能变得高效"。
6. 踩过的坑与排查思路
6.1 首次切分卡住或报错
第一次运行 airllm 时，最常见的坑是切分阶段卡住或报错。原因通常有几个：磁盘空间不足、下载中断、或者模型文件格式不被支持。
排查顺序建议这样走：先看磁盘剩余空间，切分后的文件可能比原始模型还大；再看网络是否稳定，大模型下载动辄几十 GB，中断很常见；最后确认模型格式，airllm 对 safetensors 支持最好，一些老格式的 bin 文件可能有问题。
如果切分中断，缓存目录里可能留下不完整的文件。这时候最好把缓存目录清空重来，不要试图续传，否则容易出现权重缺失的诡异错误。
6.2 显存还是不够：KV Cache 的隐藏占用
有人会疑惑：明明权重已经分层加载了，显存占用应该很低，为什么还是 OOM？
答案往往是 KV Cache。权重是分层了，但 KV Cache 是跨层累积的，序列越长它越大。如果生成长文本，KV Cache 可能吃掉好几 GB 显存。
解决办法是把 KV Cache 也放到内存里，或者限制生成的最大长度。airllm 提供了一些配置项来控制 KV Cache 的位置，具体可以查它的参数文档。实测中，把 KV Cache 放内存会进一步拖慢速度，但能避免 OOM。
6.3 速度慢到怀疑人生：几个可调项
如果速度慢得离谱，先别急着放弃，检查这几个点：
- 磁盘是不是机械硬盘？换成 SSD 试试，差距巨大。
- 预取深度是不是设得太小？适当调大，让加载和计算重叠更充分。
- 有没有开压缩？开 8bit 能明显提速。
- 生成长度是不是设太长了？调试时先设小。
- 内存是不是不够？内存不足会限制预取，导致 GPU 频繁等待。
我遇到过一次速度异常慢的情况，排查半天发现是内存不足导致系统频繁换页，把预取缓冲挤到了 swap 里。加了内存之后速度立刻恢复正常。这个坑很隐蔽，因为表面上看是"推理慢"，实际根因在系统层面。
6.4 输出质量下降：压缩的副作用
用了 4bit 压缩之后，如果发现输出质量明显下降，比如逻辑混乱、重复、答非所问，那大概率是压缩导致的。这时候可以退回 8bit 或 FP16 对比一下。
需要提醒的是，airllm 的分层加载本身不改变数值精度，质量下降只可能来自压缩。如果你用的是 FP16 且没开压缩，输出质量应该和常规推理一致。如果这时候质量还有问题，那要检查是不是模型本身的问题，或者输入格式不对。
7. 我对这套方案的真实看法
airllm 这个项目最打动我的地方，是它把一个看似无解的问题——"显存装不下模型"——用一种极其朴素的方式绕了过去。分层加载不是什么高深的技术，Transformer 的层式结构本来就摆在那里，但能把工程细节打磨到"几行代码就能跑"，这背后是大量的调度优化和边界处理。
它不适合所有人，也不该被当成通用推理方案。但如果你正好卡在"想跑大模型但显存不够"这个尴尬位置，它几乎是目前最省心的选择。我的建议是：把它当成一个"验证工具"和"学习工具"，而不是"生产工具"。用它来确认某个大模型的效果、研究逐层计算的机制、或者在资源受限时应急，都是很合适的。
最后分享一个我自己的使用习惯：跑 airllm 时，我会把生成长度设得很小（比如 32），先确认模型能正常输出，再逐步加大。这样能快速定位问题，避免一上来就跑长文本、等半天才发现配置错了。另外，第一次切分模型时，我会盯着磁盘空间和进度，切分完成后立刻备份一份缓存目录，这样即使后续环境出问题，也不用重新切分。
