airllm 这个名字，如果你关注过开源大模型推理方向，应该多少见过。它解决的是一个特别现实又有点憋屈的问题——模型权重明明只有 14GB，我的显卡却只有 8GB 显存，难道就只能看着别人跑大模型？在 airllm 这类分层推理工具出现之前，普通人想在低显存设备上跑大模型，基本只有两条路：要么买更贵的卡，要么换用云端服务。airllm 提供了一个更省钱的选择：它不要求模型一次性全部进入显存，而是让 Transformer 一层一层地算，哪层需要哪层加载，显存只需要装下“当前层”就够。
这篇文章我不打算做官方文档复述，而是从“显存到底去哪了”、“分层推理为什么可行”、“具体怎么跑起来”以及“常见坑怎么避开”这几个角度，把 airllm 这条技术路线讲透。适合手头只有 6~8GB 显存显卡的用户，也适合没有独显、只能用 CPU 硬扛的朋友。你不需要提前背很多理论，我会尽量用大白话讲清楚背后的原理，再给出一套可以直接参考的操作路子。
1. 为什么大模型跑不动：显存黑洞到底出在哪
1.1 大多数人不是买不起模型，是显存装不下
很多人第一次下载完成一个开源 7B 模型时，都会愣一下：权重文件加起来差不多 13~14GB，而常见消费级显卡只有 8GB 或 12GB 显存，装都装不进去，更别说跑了。
这里需要先分清楚“显存”和“内存”。显存是显卡自带的高速存储，和 CPU 内存是两套空间。传统推理框架加载模型时，会把整个权重文件从磁盘读入 CPU 内存，再复制到显存里。如果显存容量小于权重体积，第一步就会报错。就算显存刚好装下权重，后面生成的 token 还会不断往显存里写临时数据，那部分空间依然不够，最终结果就是 CUDA 频繁报 OOM。
我常拿装货来打比方：模型权重是整车货，传统方案要求仓库能一次性放下整辆车，仓库小了就只能干瞪眼。airllm 的思路则是把仓库门口改成一条传送带，一次只搬一层货物进仓库，算完一层送走一层，仓库不需要很大，只有货够不够多、传送带快不快的问题。
1.2 为什么“一层层算”在数学上行得通：Transformer 本来就是排队加工
让很多人疑惑的是：模型不是整体才能出结果吗？为什么可以拆开一层层算？答案是 Transformer 天然就是一层接一层顺序执行的。
现代大模型大多是 Transformer 结构，输入 token 先变成向量，经过若干个相同的“块”逐层加工。每一块的输入是上一块的输出，块和块之间不存在跨层并行需求。这意味着，理论上我只要保留当前块的权重，计算出结果，马上丢掉当前块，再加载下一块，就能保证最终输出的数学结果和一次性加载所有层完全相同。
举个例子，假设模型有 32 层，传统方法把 32 层权重全放显存，逐层计算。airllm 的方法是先把第 0 层放到显存，算完第 0 层的输出，将其留在内存或继续传给下一层，然后释放第 0 层权重，加载第 1 层，再算。显存峰值从“整个模型”降到了“一两层模型”，差别就是这么来的。
这个思路听起来简单，但工程上很难，因为神经网络的每一层都包含大量矩阵乘法，如果把权重从内存搬到显存的速度太慢，计算效率会完全被 I/O 拖死。所以 airllm 真正的技术含量，在于搬运和计算的调度安排，而不只是“卸载”这个动作。
2. airllm 核心技术点：分层推理不只是“卸载”这么简单
2.1 预取与计算重叠：让 GPU 不等数据
最笨的逐层卸载流程是：加载第 0 层、算第 0 层、再加载第 1 层、算第 1 层。这种方式下，GPU 大部分时间闲着，CPU 和内存一直在搬数据。airllm 这类成熟实现会做“预取”，在当前层计算的同时，后台线程已经把下一层权重从 CPU 内存或磁盘搬到显存里排队。这样搬运时间和计算时间重叠，等效速度会明显好于同步加载。
引用一句话来理解：分层推理省的是显存，花的是时间。能不能把时间代价压到最低，就看预取策略和调度粒度。有些版本支持把权重按 layer 粒度拆分，有些还会进一步把 layer 内的张量分段处理。粒度越细，峰值显存越低，但调度开销越大，所以默认参数是在显存占用和速度间取平衡。
我在实际操作中的体会是：如果工具只在单卡上做同步 offload，效果会比较感人；但如果你观察到生成过程中显卡利用率不再是偶尔跳动，而是一直维持在较稳定的区间，那就说明预取已经生效了。跑长文本尤其能感觉出差别，第一二个 token 慢，之后节奏会稳下来。
2.2 显存、内存、磁盘三级接力
既然目标是“用低显存跑大模型”，那内存和磁盘也必须参与进来。airllm 通常采用三层存储结构：显存、CPU 内存、磁盘。显存放正在计算的层，内存放等待计算的层，磁盘放还没有被用到的层。
当模型很大，比如 70B 级权重超过 130GB，即便 CPU 内存有 32GB 也放不下，就必须有一部分留在磁盘。从磁盘加载比从内存加载慢一个数量级，所以很多实现会优先把“最常需要访问的前几层”放在内存，把后面权重按顺序从磁盘读取。加上操作系统的文件缓存，重复运行同一个模型时二次加载速度会明显快过第一次，这也是为什么第一次推理会特别慢、甚至看起来像卡死。
所以，如果你打算用 airllm 跑大模型，我非常建议把权重放在 SSD 上，机械硬盘那种随机读取速度会把分层推理的体验拉低到完全不可用。这不是玄学，是 I/O 瓶颈决定的。
2.3 KV Cache 的取舍：显存里还有一块隐形消耗
很多人只盯着模型权重，却忽视了 KV Cache。每生成一个新 token，注意力层都要计算当前 token 与前面所有 token 之间的关系，并把中间结果缓存下来。这个缓存的体积和“模型层数 × 注意力头数 × 序列长度”成正比。
也就是说，哪怕模型权重通过分层推理已经不需要全部驻留显存，KV Cache 依然会随着生成长度持续膨胀。airllm 这类工具不会放任缓存无限增长，常见的做法是限制 max_new_tokens，或者使用更省显存的 Attention 实现，例如 page attention 或 fused kernel。有些版本还会支持动态缓存，只在必要时分配空间。
这就解释了为什么用 airllm 跑超长文本仍然可能 OOM：不是权重爆了，是缓存爆了。想让一个低显存环境同时跑 7B 模型和超长上下文，通常需要结合量化、缓存限制、以及 smaller batch 共同完成。
2.4 和量化组合：省钱省体积的黄金搭档
airllm 适合和模型量化一起用。量化就是把模型权重压缩到更低的数值精度，例如从 16-bit 压到 4-bit，这样 7B 模型的权重可以从约 14GB 缩到约 4GB，加载和搬运的数据量都小得多，推理速度也会更快。
我第一次跑通 7B 模型时用的是 fp16 权重加分层推理，当时显存占用大约 4~5GB，已经觉得很厉害了。后来换量化权重，同样环境生成速度提升了一倍以上，显存占用反而更低。代价是输出质量略有下降，对一般测试和玩票场景几乎不影响，但如果你要用模型跑严肃的代码生成或数学题，最好先拿同一段 prompt 对比几个模型格式的输出再做决定。
组合使用的时候特别要注意“支持一致性”。不是所有模型都能直接切成 4-bit，你最好选用社区里已经转换好的权重格式，或者用当前主流量化工具先做离线转换，再配置 airllm。否则运行时可能会遇到变量名不匹配或逐层读取失败的情况。
3. airllm 实操部署：从环境准备到跑通一次推理
3.1 环境与依赖检查
基于我的经验，airllm 对硬件的要求可以分成三个级别：
- 最低配：纯 CPU + 16GB 内存，可以跑中小规模模型，速度很慢但能出结果。
- 推荐配：一张 6GB 以上显存的显卡 + 32GB CPU 内存。此时跑 7B 级别模型体验已经可接受。
- 舒适配：12GB 以上显存 + 64GB 内存，不仅可以跑 13B，还能留出 KV Cache 余量。
软件环境方面，Python 3.8 以上基本没问题，PyTorch 建议用新版本，因为新版本自带了优化过的注意力算子，能大幅降低显存占用。如果你的显卡较老，需要注意驱动支持，否则装完也无法调用 GPU。
安装方式一般很直白：有的版本可以直接用 pip 安装，有的则需要从代码仓库克隆后手动安装依赖。我不建议你在没看 README 的前提下直接 pip install，因为不同分支可能对应不同 API 风格。先确认清楚你要跑的模型架构，再选 airllm 版本，能省很多折腾时间。
3.2 核心调用流程：参考写法与版本差异
airllm 不同版本的 API 可能会有差异，所以我不写死每一个参数。下面是一个从社区常见用法中提炼出的流程，关键点是：加载模型时打开“按层加载”/“磁盘映射”选项，而不是把模型一次性读入显存。
# 注意：以下为参考写法，具体参数名请以你安装版本的文档为准 import torch from airllm import AutoModelForCausalLM model_id = "你的模型权重路径" model = AutoModelForCausalLM.from_pretrained( model_id, load_weights_on_disk=True, # 让权重按需从硬盘/内存加载 dtype=torch.float16, # 显存紧张就用更低精度 device="cuda" ) prompt = "请用一句话解释什么是分层推理。" outputs = model.generate( prompt, max_new_tokens=32, do_sample=False, ) print(outputs)这段流程里有几个细节值得展开。第一，load_weights_on_disk=True的意思不是把权重放磁盘就完了，而是让推理运行时按层读取，而不是一次性加载全部。第二，dtype选择影响很大，如果你的显卡是十几 GB 显存，可以尝试 fp16；如果只有 6GB，建议使用已经量化好的权重，不要运行时分精度。第三，max_new_tokens第一次别设太大，32 或 64 足够验证流程，等跑通后再逐步增加。
如果你发现启动时无响应，多半是在做首次权重格式转换。很多实现会在首次加载时把原始模型权重转换成更利于分层读取的格式，这个过程可能长达几十分钟。遇到这种情况，正确做法是耐心等待，或者提前找一个已经转换好的版本跳过这个时间。
3.3 关键参数选择与调优
跑通是第一步，调参是第二步。我总结几个会用到的参数经验：
- batch size 保持 1。分层推理的定位是低资源离线推理，不是为了高吞吐，batch 调大不仅不会快，还可能直接显存溢出。
- max_new_tokens 和 max_length 要从小开始。序列越长，KV Cache 越大。如果你想生成一千字，先试 128，再逐步加到 256，观察显存余量。
do_sample=False时速度更快，因为可以走贪心解码；需要多样效果时再开采样。- 如果你的实现支持“保留顶层在 GPU”，建议打开。最后几层权重很小且频繁使用，常驻显存能减少反复搬运。直观效果是生成后半段速度变快。
- 环境变量里固定可见显卡。如果你电脑有多张显卡，不确定 airllm 是否正确选中目标卡，会导致它默认注册到显存更小的卡上。用常规的 CUDA_VISIBLE_DEVICES 指定即可。
调参本质上是在和显存做动态平衡。我建议你打开显卡占用监控，实时观察显存变化。看到显存在推理过程中来回跳动，说明分层加载发挥作用；看到显存一直保持高位并最终报错，说明有东西没有按预期卸载。
3.4 CPU 模式和大显存模式该怎么选
如果你的机器没有可用 GPU，airllm 大概率也能跑，只是会退化为纯 CPU 推理。对 7B 模型，CPU 推理速度大约只有不到每秒 1~2 token，生成一小段话就要等几分钟。此时最关键的是 CPU 内存要足够，建议不低于权重的两倍大小。例如 7B fp16 权重 14GB，最好有 32GB 内存。
反过来，如果你的显卡显存其实可以装下完整模型，那我不建议强行用 airllm。完整驻留显存的方式少了一层搬运，速度会快很多。只有当模型权重超过显存容量时，airllm 才真正值得。例如 6GB 显卡跑 7B，差距是“跑不了”和“能跑”的区别；而 24GB 显卡跑 7B，没必要牺牲性能换省显存。
很多第一次用的人会犯一个误区：以为 airllm 是无损加速工具。它不是。它是牺牲一点速度来换显存容量，核心价值是“把不可能变成可能”，不是“把慢变成快”。
4. 实测记录：低配置机器从 OOM 到成功出结果
4.1 我的测试环境与初始状态
为了验证这套思路，我专门找了一台很贴近大多数人的旧机器：一块 6GB 显存的显卡，32GB CPU 内存，系统盘是 SSD。目标是运行一个 7B 参数的开源对话模型，权重大约 14GB，从任何角度来说，传统方式都不可能把它塞进 6GB 显存。
第一次我用常规 Transformers 风格代码直接加载，在生成前就报了 CUDA OOM。这个结果完全符合预期：权重 14GB，加上加载时期的临时活动，显存瞬间爆满。随后我更换模型调用入口，打开分层加载开关，同时把模型格式从 fp16 换成了社区预转换好的 4-bit 权重，大小约 4.5GB。
这里要说明一点：4-bit 量化后权重是变小了，但 6GB 显存仍然装不下完整 4-bit 模型的全部中间激活和 KV Cache，所以分层加载依然开着。两者不是互斥，而是叠加，这也是低显存玩家最实用的组合。
4.2 推理速度与资源占用
模型加载完成后，第一次生成 32 个 token 耗时大约 40 秒，后续继续生成的稳定速度大概在每秒 3~5 个 token。这个速度拿来写段小作文、跑跑示例完全够用，但如果你想做长篇小说级生成，建议先睡一觉再说。
显存占用方面，最高冲到 5GB 左右，离 6GB 临界线不远。CPU 内存在推理期间会持续占用约 10~12GB，因为未用的层都暂存在内存里。让我意外的是，磁盘占用反而不是最大的问题，真正限制继续增加上下文的是 KV Cache：当 max_new_tokens 从 32 提到 128 时，显存占用明显又涨了一截。
整个过程让我确认了一个结论：低显存跑大模型不是魔法，关键是让数据按照“磁盘 → 内存 → 显存”的路径有序流动。只要每一层在正确的时间出现在正确的位置，OOM 就可以避免。
4.3 三个让我差点放弃的细节
第一次跑没有成功生成任何内容，模型加载完就报错说内存不足。仔细排查才发现，不是显存不够，而是 CPU 内存不够。因为分层推理要把其余层放在内存里，14GB 权重加上 Python 和 PyTorch 的运行时开销，16GB 内存根本不够用。换成 32GB 后问题解决。
第二个问题是“假死”。加载量化权重后，终端没有任何输出，我以为卡住了，就按了 Ctrl+C。后来才意识到它是在做权重格式转换，硬盘灯一直亮着。以后遇到这种情况，我会先看任务管理器和硬盘 I/O，再决定要不要中断。
第三个问题是输出中文会“断字”。airllm 分层推理本身不会导致结果变差，但模型 tokenizer 在低温度下偶尔会输出不完整的词。我的处理方法是适当调高temperature，并用 repeat penalty 让句子更完整。如果你用量化模型，这种情况会更多见，属于正常精度损失，不用太慌。
5. airllm 常见问题排查与避坑手册
5.1 问题速查表
这里把我踩过和见过的问题整理成一张表，方便直接对照：
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
| 一启动就 CUDA OOM | 没开分层加载，或 KV Cache 设置过大 | 检查加载选项，减小 max_new_tokens |
| 加载过程很慢、像卡死 | 首次加载在做权重预处理与转换 | 等待硬盘 I/O 结束，或提前预转换 |
| 生成速度极慢 | 权重在磁盘上反复读取，预取未生效 | 把权重放到 SSD，增加系统内存 |
| 输出乱码或文字残缺 | 量化精度损失、温度过低、tokenizer 问题 | 调高温度，开启重复惩罚，尝试非量化原始权重 |
| CPU 内存直接占满 | 权重被全部放到内存，内存不足 | 减少驻留层数，或使用量化权重 |
| 第二次加载比第一次慢 | 系统文件缓存被清空或换盘 | 预转换后不要频繁移动文件位置 |
这些坑都有一个共同点：报错信息不会直接告诉你“内存不足”还是“显存不足”。所以我强烈建议在运行 airllm 时同时开一个资源监控面板，把显存、内存、磁盘队列都显示出来，出问题一眼就能定位。
5.2 避坑实操技巧
除了上面那张表，我还想分享几个实用性极强的习惯。
第一，跑大模型前先把无关程序关掉。浏览器多开十几个标签页，内存占用轻松到好几GB，直接压缩了可用资源的余量。尤其在使用 CPU 内存承载分层权重时，系统内存紧张会引发 swap，速度瞬间崩盘。
第二，不要同时启动多个推理任务。airllm 单机单任务体验尚可，同时跑两个模型会让内存翻倍，而且两个任务竞争磁盘和内存带宽，最后两个都变慢。
第三，给系统预留足够内存。很多人看到权重 14GB，就买 16GB 内存机器以为够了，结果加载完模型，操作系统已经几乎没有内存可用。建议内存容量至少是权重的 2 倍，再算上系统占用的余量。32GB 是比较稳妥的起点。
第四，检查你的显存是否被其他程序占用。某些桌面环境会固定占用一部分显存，导致你实际可用的显存比标称值少。官方显示的 6GB 可能在登录图形界面后只剩 5GB。
第五，记录第一次预转换后的 cache 路径。很多工具会把转换后的权重放在 cache 目录，如果你不小心清了缓存，下次加载又得重新等待。需要换路径时最好通过软链接迁移。
5.3 什么时候不该用 airllm
工具和人一样，都有自己的舒适区。airllm 非常适用于离线单用户、低显存、低成本跑大模型的场景，但在下面三种情况下，我一般会建议换方案。
第一种是模型不大但显存足够。如果 7B 模型能原样加载进显存，就没必要分层加载，完整驻留更简单更快。
第二种是追求高并发线上服务。分层推理的每 token 延迟较高，且批量并行能力弱。线上服务需要稳定低延迟和较高吞吐，用专门的推理框架更好，airllm 的定位不是那个方向。
第三种是模型超大且需要频繁推理。当模型超过百B级，即便用分层推理能跑，磁盘和内存的数据搬运也会非常可观。如果只是偶尔尝鲜可以，如果作为日常工作流程，时间成本可能高到让人崩溃。
在选型时记得一句话：用最小的成本解决手头问题。airllm 的价值下限很低，一台上网本都能跑起来一个模型，但它的速度上限也有限。明白自己在哪个场景，才能做出合适选择。
6. 后续还能怎么折腾：让 airllm 体验再上一层
6.1 结合外部缓存与交换分区加速
如果你是纯 CPU 用户，一个比较有效的技巧是：在 Linux 下把模型权重放到带 ZRAM 或足够大 swap 的空间里。听起来很反直觉，但某些情况下，操作系统的页缓存可以让同一层权重在多次访问之间留在物理内存里，避免反复从 SSD 读盘。
原理是操作系统会把最近读过的文件内容缓存在未使用的内存区域。当同一层权重跑第二次时，就能直接从内存命中，速度从磁盘级提速到厘米级。所以不要让系统 swap 被禁掉，也不要让可用内存被塞得一点不剩，否则这个缓存红利就吃不到。
6.2 尝试不同模型架构和层设计
不是所有模型都适合分层推理。不同模型层的计算量和权重分布差别很大，有些模型的 embedding 词表非常大，即使只加载一层，embedding 表也可能占用数个GB。如果你在选择模型时遇到显存不够，可以优先关注“embedding 比较小”的架构，或对词表做裁剪。
反过来，层数越多，逐层加载带来的调度开销占比越少。70B 模型的单层参数比 7B 模型的单层参数大很多，搬运同样次数，单位搬运效率更高。所以分层推理在超大规模模型上往往意外地比中型模型更“划算”。
6.3 进一步优化注意力层缓存
很多 airllm 使用者在跑长文本时遇到瓶颈，根源是 KV Cache 增长不受控。你可以尝试以下策略：减少上下文长度、使用支持滑动窗口注意力的模型架构、或者换用显存优化更激进的 backend。如果工具允许自定义 Attention 实现，选择融合 kernel 通常会带来比纯 PyTorch 低得多的显存占用。
我个人习惯是在 prompt 里尽量精简输入，不要一股脑把几百页资料塞进去。对低显存环境来说，上下文就是奢侈品。控制输入长度，是最简单也最有效的 KV Cache 优化。
6.4 写一个简单的脚本化监控
跑长任务时，我会在后台记录显存和内存曲线，方便判断瓶颈。一个简单的做法是每隔几秒读取系统信息，把结果输出到文本文件。这样即使任务结束后，我也能回头分析是加载阶段慢还是生成阶段慢，而不是靠感觉猜。
有了监控数据，再做参数调整就非常有依据。比如发现显存余量一直很充足，就可以把更大的 batch 或更长上下文加进去。发现 CPU 内存一直满，就考虑减少驻留层或换量化格式。这种“数据驱动”的调参方式，远比随机试参数可靠。
这个工具本身没有太多花哨功能，但只要你理解了分层加载的工作方式，就能在“低配置”这个约束下玩出不少花样。我最后一次实际使用 airllm 时，甚至在一台只有 8GB 内存的轻薄笔记本上跑出了一个 3B 模型，速度虽然一般，但产出内容完全可用。看到明明硬件不够一台机器却把模型跑起来的那一刻，会特别有成就感。
