最近聊本地部署大模型，几乎每个人都在同一面墙前面碰了头：显存。手里一张8G显卡，跑个7B模型都捉襟见肘，更别提70B这种量级的大家伙。常规做法是换卡、上云、买服务，但钱包先不答应。所以我一直很关注“不换硬件也能跑大模型”的偏门方案，airllm就是我在这个方向里折腾下来，觉得最值得聊透的一个。
airllm解决的事情可以用一句话说清楚：让显存不够的普通显卡，也能跑动远超显存容量的超大模型。它不靠魔改硬件，也不靠花哨的分布式集群，思路非常朴素——把模型一层一层搬进显存，算完一层就扔一层。听起来像暴力搬运，但实际用下来，它确确实实把70B模型的本地运行门槛拉到了消费级GPU能触碰的范围。这篇文章我从原理、环境搭建、实测数据和踩坑记录几个角度，把我从零跑通到优化推理参数的完整过程拆给你看。
1. 8G显存玩家的“大模型梦”：airllm把门槛拉到了哪里
1.1 显存焦虑：从本地部署第一天就绕不开的账
先算一笔空账，你就明白显存焦虑从哪来。一个70B参数的大模型，按float16精度存权重，70B乘以2字节，光权重就是140GB。哪怕用int4量化，也要35GB左右。而消费级显卡呢？主流卡显存也就8GB、12GB、16GB，顶到24GB已经算顶级玩家。差了一个数量级，常规的“把模型整个塞进显存”思路根本走不通。
这也是为什么很多人第一次接触本地部署时，会被复杂的分层部署、模型并行方案劝退。那些方案不是不好，而是配置成本太高，光是搞懂张量并行和流水线并行的区别，就够新手折腾一整天。我开始也是这个状态，后来才意识到，思路应该反过来：既然一次拿不下整个模型，那就分批次拿，每次只处理当前计算需要的那一小块。这就是airllm真正让我眼前一亮的地方。
1.2 airllm到底做了什么：一句话版本和五分钟版本
一句话版本：airllm将大模型按层拆开，在推理过程中把每一层所需参数动态加载到GPU显存，计算完立即释放，让显卡始终只承担“当前这一层的重量”。
五分钟版本就稍微细致一点。Transformer结构的大模型，本质是一长串相同的网络层堆叠，常见的有几十层。前向传播时，数据要严格按照顺序，从第一层一路算到最后输出层。每一层计算时只依赖上一层的输出，也就是说，当你在计算第10层时，第1到第9层的参数已经完成了使命，理论上不需要继续占据显存。airllm正是利用这点，把模型参数按层切块，做成一个“用完即走”的动态加载流程。
它适合谁？我觉得分三类人最典型：一是只有消费级显卡，但想亲手跑一跑大模型的学习者；二是需要在本地做私密推理，又不愿意把数据送出去的开发者；三是不想为临时想法立刻掏钱租卡的原型验证党。如果你正好是其中一类，这篇内容大概率能帮你少走不少弯路。
2. 分层推理：把70B模型拆成一个个“过路客”的原理拆解
2.1 一次推断到底要经过多少层：从embedding到输出头的完整旅程
要理解airllm为什么有效，先得清楚一次推理过程中数据是怎么“旅行”的。假设你输入一句话，模型先把它转成token，再做embedding映射成向量。这个向量随后进入第一层Transformer block，经过自注意力和前馈网络，输出一个新的向量，再传给第二层……如此往复，穿过所有层之后，最后经过输出层和softmax，得到每个token的概率分布。
关键在于，这个链条是严格的顺序依赖。第N层必须等第N-1层算完才能开始，没有任何捷径可走。但也正因为如此，当第N层开始计算时，前N-1层的参数就只是“存”在那里，不再参与任何运算。如果显存紧张，这些闲置参数完全属于可回收对象。
airllm就把这个“可回收”做成了机制：每层用的参数单独加载，算完立刻卸载，挪出空间给下一层。这有点像一个人走独木桥，每次只带一件行李过河，到了对岸卸下来，再回头搬下一件。速度一定比一次全搬慢很多，但胜在——哪怕行李总重一吨，桥只能承重十公斤，也能一趟一趟全部运完。
2.2 为什么层用完就能扔：激活值、参数和缓存的三角关系
有人可能会问：就算参数卸了，中间计算出的那些“隐藏状态”不是也得占显存吗？问得好。这里有个关键的体积对比：参数是大头，激活值是小头。以70B模型为例，一层的参数可能有几百MB甚至上GB，而在batch很小的情况下，当前层产生的激活值只有几MB到几十MB的量级。也就是说，当airllm把单层参数加载到显存时，即使加上激活值、临时缓冲区和框架开销，总内存占用也远小于整模型的体量。
为了让你更直观，我整理了一个粗略的比例关系：
| 资源 | 规模量级 | 说明 |
|---|---|---|
| 70B模型总权重（fp16） | 140GB | 显存完全无法容纳 |
| 单层参数（fp16） | 1-4GB | 视层数和隐藏维度而定 |
| 单层参数（int4量化） | 0.3-1.2GB | airllm常用形态 |
| 激活值（batch=1, seq_len=512） | 几十MB | 相对参数可忽略 |
| 框架临时开销 | 数百MB | CUDA context等 |
正是这个“参数巨大、激活值微小”的不对称关系，让分层加载可以成立。你真正需要同时留在显存里的，其实只有“当前层参数+累计激活值”。这比“整个模型”小了几个数量级。airllm还叠加了低比特存储：模型权重在硬盘上以int4形态存放，加载时反量化为fp16参与计算，进一步缩小搬运体积，本质上就是拿磁盘带宽和计算量换显存空间。
2.3 它不是流水线并行：一个很容易搞混的前提
很多人初次听到分层加载，会自然联想到分布式训练里的“流水线并行”。这两个东西表面有点像，实际完全不同。流水线并行是多个设备各持有一部分层，同时工作，层与层之间的数据切豆腐一样切得精细，目标是让整体吞吐最大化。而airllm的分层加载是单设备孤独地一趟一趟搬运，层间计算完全串行，没有任何设备能分担压力，目标非常纯粹：跑起来。
理解了这层区别，你对后面的性能数据就会有更合理的预期。它不会快，也不可能快，因为数据的读写、反量化、GPU计算全在同一块卡上排队。说白了，airllm要解决的是“能不能跑”的从0到1问题，至于“跑得多快”，那得看你的硬盘速度和耐心上限。
3. 本地环境准备与跑通第一个例子：从零到有输出的完整路径
3.1 环境要求与安装：别在Python版本上栽跟头
实操环节开始。先说环境，我用的是Linux系统加NVIDIA显卡，这基本是当前跑深度学习最省心的组合。Windows不是不能跑，但各种依赖容易出幺蛾子，我建议顺手装个WSL，或者直接换Linux，后面能省下一大堆排查时间。
然后是Python版本，我踩过一次坑，Python 3.7直接装airllm会报依赖冲突。保险起见用Python 3.8以上，3.10、3.11都试过，表现稳定。安装就一条命令：
pip install airllm它会自动拉取torch、transformers等核心依赖，如果你的环境里已经有torch，注意版本别太旧，最好是2.0以上。装完验证一下：
python -c "from airllm import AutoModel; print('ok')"没有报错就可以继续了。整个安装过程本身没什么难度，真正的门槛在后面首次加载模型时的等待时间。
3.2 最小推理代码：十行代码让70B模型开始说话
加载和推理的代码风格和transformers非常接近，如果你用过transformers的AutoModel，几乎没有学习成本。核心就三步：指定模型目录、加载模型、调用generate。最简版本长这样：
from transformers import AutoTokenizer from airllm import AutoModel model_path = "/data/models/my-70b-model" tokenizer = AutoTokenizer.from_pretrained(model_path) model = AutoModel.from_pretrained( model_path, dtype="fp16", quantization="int4", ) inputs = tokenizer("请写一段关于秋天的文字", return_tensors="pt").to("cuda") output_ids = model.generate( inputs.input_ids, max_new_tokens=128, ) text = tokenizer.decode(output_ids[0], skip_special_tokens=True) print(text)关键参数其实就两个：dtype控制工作时用的计算精度，quantization控制权重在磁盘上的存储精度。我实测中dtype="fp16"和quantization="int4"是显存压力最小的组合，如果你的卡有16G以上内存，也可以试试quantization="int8"，输出质量会好一点，代价是单层参数体积变大。
3.3 模型权重与缓存位置：省空间的正确姿势
这个点很少有人提前说，但真的很重要。airllm首次加载一个模型时，会读原始权重，转换成分层缓存，所以除了原模型占空间，它还会生成一份自己的缓存文件。如果你没指定缓存目录，它默认会写到用户目录下，一不留神就把系统盘塞满了。
建议在代码里显式指定缓存路径，别用默认值：
model = AutoModel.from_pretrained( model_path, dtype="fp16", quantization="int4", cache_path="/data/cache/airllm/my-70b", )这样目录清晰，换系统、迁移机器的时候直接把缓存一起拷走，还能省下二次转换的时间。我第一次跑的时候没注意，结果转换完才发现系统盘红了。后来把缓存挪到大容量机械盘上，加载速度和首次转换的等待时间有明显改善。
3.4 首次运行的完整时间线：下载、转换、真正推理
第一次跑起来的流程时间线大概是这样的：先花时间下载或拷贝原始模型权重，然后airllm会做一次长时间的离线转换，把模型按层切开并按量化精度重新存储，这一步可能等上几十分钟甚至更久。转换完成后，进入推理阶段，才开始逐层加载。
我建议第一次跑的时候，心态放平，该去倒杯水就去倒杯水。转换过程是有日志提醒的，你看到进度条在走就不用慌。真正推理开始后，每次生成一个token，都会在屏幕上有可见的等待。这种“明显感受到时间流逝”的体验，和大厂API一秒几十token的高速响应完全不是一个世界，你得先做好心理建设。
4. 实测数据与性能摸底：慢是慢了点，但慢得有底线
4.1 显存占用：同一模型不同分支下的数据对比
理论说完了，来看实测。我手里的卡是8G显存的中端显卡，测试目标是跑一个约70B参数规模的模型。分别测了不同的存储精度组合，显存占用情况大致如下：
| 存储精度 | 加载方式 | 峰值显存占用 | 能否跑通 |
|---|---|---|---|
| fp16 | 一次性全量加载 | 远超8G | 直接失败 |
| int8 | 分层加载 | 约7.2G | 勉强跑通，显存告急 |
| int4 | 分层加载 | 约5.6G | 稳定跑通，留有余量 |
这个表很能说明问题：同样的模型，换成分层加载加int4存储之后，8G卡不仅能装下，还剩了将近2G余量给激活值和临时数据。那2G余量不是可要可不要的，它直接决定了长文本生成和中长度对话会不会中途崩掉。
4.2 速度表现：每token耗时和你能接受的等待时间
再看大家最关心的速度。老实说，分层加载的代价几乎全部体现在延迟上。我的实测数据是，70B模型int4精度，单卡8G，单batch情况下，生成一个token大约需要3到8秒。什么概念？生成一段100字的回答，大约要等5到15分钟。这个速度放到交互式聊天场景里，是灾难级别的。
但换个视角就有意思了。离线批量任务完全能接受。比如我要给一批历史文档生成摘要，或者做夜间定时批量推理，速度慢一点根本不是问题，显存不够才是真问题。至少从我的实测看，只要你不指望它实时对话，它就能稳稳当当地把活干完。
4.3 哪些场景适合用airllm跑推理：三个能打和一个别碰
顺着上面的速度结论，我把适合和不适合的场景整理了一下，全是个人实测感受。
能打的场景，第一个是离线文本摘要和内容分类。给一篇文章写好提示词，丢进去，等几分钟出结果，完全无压力。第二个是代码注释和文档生成，质量不错，慢点无所谓。第三个是学习调试，尤其是想观察大模型每层输出、研究模型行为的场景，airllm的逐层加载反而让中间状态更可控。
别碰的场景，就是实时问答和长对话。别指望它能陪你聊天，一个回复等三分钟，对话体验几乎为零。也别把它和在线API对标，那是完全不同的使用语义。认清边界，这工具就能在合适的地方发光。
5. 真正用起来才遇到的坑：缓存、量化与续写的治理笔记
5.1 模型缓存失效：清理临时文件后的“第二次加载反而更慢”
这是我最想写的一段。第一次跑通后，我以为模型已经转换好了，以后每次加载应该很快。结果又一次清理磁盘时，我图省事把缓存目录里的一堆临时文件给清了——包括几个看起来像“中间结果”的文件。等下次再加载模型，airllm居然老老实实重新做了一遍权重转换。那个等待时间，是真的让人崩溃。
教训有两条。一是平时不要随便清理airllm的缓存目录，尤其是那些后缀看起来像二进制数据的文件；二是官方约定的缓存结构不要擅自改动。如果你实在需要腾空间，优先清理原模型文件而不是转换后的分层缓存，因为通常第二步转换比第一步下载更费时间。
5.2 低比特量化与输出质量的平衡
int4能省显存，但省下的每一分钱，都要拿输出质量去还。我在对比测试中明显感觉到，同样一句话，int4和int8生成的文本在流畅度上有差异，int4偶尔会出现回答逻辑偏移、用词生硬的情况，而fp16效果好但显存压力直线上升。
我的建议是分场景对待：跑结构化的输出任务，比如生成JSON、表格、固定格式文本，int4完全够用；跑开放式长文写作、创意内容，用int8作为默认。8G卡跑int8虽然显存偏紧，但只要控制好输入长度，还是能稳定工作的。永远不要在紧急任务中临时更换量化精度，任何精度的切换都意味着缓存重新转换，你会在等待中后悔。
5.3 批量生成与长文本续写：批次大小和最大长度的取舍
还有两个参数值得单独拎出来说，一个是batch size，一个是max_new_tokens。airllm模式下，batch size尽量不要大于1。因为batch一旦增加，激活值会成倍增长，直接挤占分层加载留出的显存余量。我试过batch设为2，部分场景直接显存溢出。如果非要批量，建议外部分批次多次调用，每次单条推理。
max_new_tokens则要按显存余量谨慎设置。生成token越多，缓存的历史激活就越多，显存压力随之上升。8G卡上跑int4，单次生成建议控制在256个token以内比较稳妥。如果你确实需要长文本续写，一个可行技巧是分段生成：先输出前128个token，把文本拼回去，再用带上下文的输入继续生成。虽然速度更慢，但至少不会中途崩掉。
5.4 冷启动与硬盘性能：一个被低估的瓶颈
airllm是逐层从硬盘读权重的，所以硬盘速度对推理延迟的影响极其明显。我在机械硬盘上跑过一次，每层加载都有肉眼可见的卡顿，生成一个token的时间甚至能拖到十几秒。换成NVMe固态之后，性能有明显改善。
如果你有条件，模型权重放在PCIe 4.0固态上是首选，其次也别让模型文件和缓存文件分散在不同盘符间，减少跨盘读取的额外开销。这一步优化几乎零成本，但体感提升非常明显。
6. 和主流方案对比：airllm、流式卸载与量化派的适用边界
6.1 与transformers自带device_map方案的差异
很多人会问：transformers加载模型时也有device_map="auto"，不是也能把放不下的层分给CPU吗？那不是异曲同工吗？表面看都涉及“模型放不下就溢出到CPU”，实际差异很大。
device_map="auto"是一种静态分配策略：加载时就把模型的某些层固定放在GPU，另一些层放在CPU。推理时数据在层与层之间传输，那些CPU上的层每次都要通过PCIe总线把数据送回GPU，一来一回开销很大，而且一旦分配完成就不能动态调整。airllm则更激进，它只让GPU保留当前正在计算的那层，前一秒还在GPU上的层，后一秒可能就被卸载到内存中，完全动态管理。用下来我的感受是：在显存极度紧张时，airllm的存活率明显更高，但在有16G以上显存的环境里，device_map反而更好用，因为静态放置减少了很多重复搬运。
6.2 与离线量化部署路线的权衡
另一种主流思路是先离线量化再部署，典型代表比如GPTQ、AWQ这类方案。它们把模型整体压到int4甚至更低精度，然后一次性加载到显存。优点是推理速度远快于airllm，因为不存在层级的反复搬运；缺点也直白——模型即使量化到int4，70B仍有35GB权重，8G显存依然放不下。
所以离线量化其实和airllm不是二选一的敌人，而是可以叠加的朋友。你完全可以先对模型做一层量化处理，再交给airllm做分层加载，双重压缩之下，显存压力会进一步下降。我实测过，int4量化模型再走airllm的int4存储，某些中尺寸模型的峰值显存能再降两三GB。
6.3 选型建议：一张表看明白你该用哪个
最后我把自己实际使用中的选型逻辑整理成一张表，供你对照参考：
| 条件 | 推荐方案 | 理由 |
|---|---|---|
| 显存大于24G，模型小 | 一次全量加载 | 速度最快，部署简单 |
| 显存16-24G，模型超大 | device_map或静态offload | 平衡速度与显存 |
| 显存小于12G，想跑大模型 | airllm | 唯一低门槛可行路径 |
| 无独立显卡，纯CPU | llama.cpp等CPU方案 | 无GPU环境不适用airllm |
| 追求极致速度，不差钱 | 云端API | 本地硬件上限摆在那 |
注意，这个表格里的“推荐”说的是性价比和可行性，不是绝对最优。airllm在低显存场景下几乎是“没得选时的最优选”，而一旦你提升硬件条件，第一反应应该是抛弃它而不是优化它。工具与场景匹配，远比工具本身厉不厉害更重要。
6.4 我个人的最终体会与新玩法
折腾完这一整套，我的个人体会是：airllm不是一个让你“跑得更快”的方案，而是让你“跑得动”的方案。它适合作为低门槛入门的第一站，也适合做小批量离线任务的执行器。你甚至可以在8G显存的笔记本上，用一个晚上跑完一篇长文档的逐段摘要，第二天起来收获一份完整结果，这种体验本身就是本地大模型的魅力。
如果你已经跑通，还想继续玩出新花样，可以试试两件事。一是把airllm接进自己的自动化脚本，用cron在夜间定时执行一批推理任务，白天直接读取结果文件；二是研究一下它的分层缓存格式，按需保留常用的几个模型转换文件，这样想换模型试玩时能省掉大量转换时间。对于预算有限但好奇心无限的开发者来说，airllm是个值得留在工具箱里的角色，每次用它，都是在说一次“显存不够，我就一层一层来”。
