显存不够也能跑70B大模型：airllm分层加载推理实战指南

前两天有个朋友问我，手里只有一块老显卡，显存也不过4GB，能不能跑一下现在社区里那些70B参数级别的大模型。我一听就知道，他想问的是那种“卡不够，但很想本地推理”的场景。我的回答是：能，用airllm就能跑，体验谈不上丝滑，但至少能把模型真正跑起来，而且不用租云服务器。

airllm是个开源的大模型推理项目，核心卖点只有一个：让普通消费级显卡也能加载超大模型。它解决的是本地推理最头疼的显存问题，不需要高端多卡集群，不需要复杂的集群调度，装好环境之后几行代码就能把70B级别的开源模型跑起来。这篇文章我会从原理到实操一条线讲清楚，包括我实测中踩过的坑和调优经验，适合那些显存有限、但想碰一碰大模型的开发者，也适合想理解“分层加载推理”这类方案的人。

1. airllm在解决什么核心问题

1.1 大模型推理的显存困境：为什么模型参数放不进显存

大模型推理最基础的一个公式是：模型能跑起来，前提是模型权重能被塞进显存。一个70B参数量的模型，如果以fp16精度加载，光权重就占掉大约140GB显存；就算用8bit量化，也要70GB左右；4bit量化可以压到35GB上下。这个数字对大多数人来说，根本是遥不可及的。

我自己刚接触大模型推理的时候也天真地以为，只要模型是开源的，下载下来就能在本地跑。实际一试才发现，显存门槛直接把99%的个人设备挡在门外。有人会选择用CPU推理，但CPU跑大模型的速度又太慢，很多场景下完全不能接受。也有人会选择把模型切分到多张卡上，但普通人哪有那么多卡。

这个问题的本质是显存（GPU显存）和内存（系统内存）之间的容量差距。一张消费级显卡的显存往往只有8GB、12GB，但一台普通电脑的内存随便就有32GB、64GB。如果能把一部分权重临时放到内存里，用的时候再搬进显存，理论上就可以用内存“换取”显存，让大模型在一个低配环境里跑起来。airllm的思路就是沿着这个方向走的。

1.2 airllm的破局思路：让容量不再是门槛

airllm的核心思想可以概括成一句话：不一次性加载整个模型，而是按层加载、按需释放。传统推理框架在初始化时会把模型全部权重搬到显存，之后所有计算都在显存里完成；airllm则反着来，它把模型在层之间“切”开，一次只在显存里放一层的权重，计算完这一层就立刻释放，再去加载下一层。

这样下来，显存里的峰值占用就只取决于单层权重的体积，而不取决于整个模型有多大。一个70B模型哪怕整体有100多GB，拆到每一层上可能只有几百MB到1GB左右，一张老显卡也能装得下。代价是速度和吞吐量：每跑一个token都要经历一次从内存到显存的加载、计算、卸载循环，整体速度肯定比传统方案慢不少。

在我实际的使用体验里，airllm的定位很明确：它不是用来做高并发服务的，也不是用来追求极致生成速度的，而是给“显存不够但就是想本地跑大模型”的人提供一种可用方案。这种思路很适合做技术验证、跑小样本Demo、测试模型效果，甚至用来写一个单用户的小工具。

2. 核心设计拆解：分层加载与按需释放

2.1 一次推理的完整加载流程

要真正理解airllm，得先明白它“偷”显存的具体操作链路。以一次对话生成为例，整个流程大概是这样的：

1. 用户输入一段文本，被tokenizer切成token序列。
2. 模型开始逐层执行前向计算。airllm先从磁盘的模型权重文件里读取第一层的权重，加载到显存。
3. 计算完第一层之后，最迟在进入第二层之前，第一层的显存缓存被主动释放。
4. 重复这个“加载一层、计算一层、卸载一层”的循环，直到所有层都跑完。
5. 最终输出层给出预测的token概率，采样得到当前token，再拼到输入序列末尾，重复上述步骤生成下一个token。

这就是它能把70B模型跑在4GB显存上的底层原因。显存里始终只存在“当前正在计算的那一层”，而不是整个模型。系统内存只要能够容下完整模型权重即可，同时在生成过程中还会把权重按需从磁盘读入内存，真正做到“小显存也能算大模型”。

这里有个很容易被忽略的细节：airllm虽然大幅降低显存需求，但对系统内存的要求依然很高。一个70B模型如果用4bit压缩，权重文件可能还有35GB左右，你需要至少有这个数量级的内存来承载它。很多人以为airllm可以什么都不管直接跑，结果一执行就发现系统内存满了、Swap狂涨、速度断崖式下降，这些都是没有理解内存这个前提导致的问题。

2.2 量化与压缩：两个影响成败的开关

airllm内置了权重压缩机制，通过一个compression参数控制。这个参数在实际使用中非常关键，因为“模型能不能加载”和“模型加载后效果行不行”都跟它有关。

从概念上讲，compression可以理解为权重存储的压缩倍数。我实测过的常见取值有4和8，分别对应4bit左右和8bit左右的压缩推理精度。取值越低，模型占用的内存越小，但精度损失相对变大；取值越高，内存开销更大，精度保持得更好。

选择compression值时有一个核心权衡：你的内存够不够。假设你有一个70B模型，fp16原始权重大约140GB，用compression=4压缩后大约35GB，用compression=8压缩后大约70GB。如果你的电脑只有32GB内存，那compression=8大概率跑不起来，compression=4也接近极限；反过来，如果你内存很充裕，比如128GB，那就可以尝试compression=8甚至直接不压缩，换取更好的生成质量。

这个开关的重要性在于，很多人第一次跑airllm失败，不是代码写错了，而是选了不合适的压缩参数。我记得第一次跑一个开源模型时，自以为compression设得越低越好，直接填了4，结果模型能加载但生成内容明显不对劲，后来把compression调到8，效果立刻正常了很多。内存够用的情况下，千万别为了“省空间”而牺牲质量。

2.3 代码接口是如何对应底层行为的

airllm用起来非常像Hugging Face风格的Transformers库，关键类是AirLLMLlama2、AirLLMMistral这类按架构区分的模型类。如果你要跑一个Llama架构的模型，就用AirLLMLlama2；如果模型是Mistral架构，就选AirLLMMistral。具体选哪个类，取决于模型本身的架构类型，而不是模型的名字。

构造模型时只需要传入模型路径和compression两个核心参数。模型加载完成之后，调用generate方法和Transformers的体验几乎一样，传prompt、max_new_tokens等就能生成文本。后面我会放一个完整的可运行示例。

这里的底层行为其实很有意思：airllm并不是像标准推理框架那样在model = Model(...)这一步把所有权重读进显存，而是以“按需加载权重文件”的方式来组织计算。构造函数只做初始化、配置读取和模型结构声明，真的跑到某层时才会把那一层的权重从磁盘拉到内存、再从内存搬运到显存。理解这一点，你就能明白为什么首次启动通常会比较慢，因为要准备权重索引；也就能理解为什么生成速度主要取决于内存带宽和磁盘读取速度，而不是单纯的GPU算力。

3. 实操：从安装到跑通第一个70B模型

3.1 环境准备与依赖安装

先说说环境。airllm本质上是基于PyTorch的推理库，所以你需要一个能跑CUDA的PyTorch环境。我建议直接用虚拟环境，避免把系统环境搞乱，尤其是不想破坏已有PyTorch项目的情况下，虚拟环境几乎是最稳妥的选择。

安装命令非常简单，直接走pip。装完之后建议确认一下torch和CUDA版本是否匹配，这一点坑过不少人。如果你之前装的PyTorch是CPU版本的，那后面跑airllm的时候会发现模型加载特别慢，因为计算全部落在CPU上。可以用一个简单的命令来检查当前环境是否启用了CUDA：

python -c "import torch; print(torch.cuda.is_available())"

如果输出是True，说明CUDA环境没问题。如果输出False，先检查一下自己装的是不是CPU版PyTorch，或者CUDA驱动版本是不是太老。推荐的做法是先装好匹配的CUDA版本PyTorch，再装airllm，顺序不要搞反。

3.2 最小化推理代码

跑一个模型，核心代码量其实很小。下面这段代码是我实测后确定的最小可用版本，你只需要替换成自己的模型路径就能跑：

from airllm import AirLLMLlama2 model_path = "your-org/your-70b-model" model = AirLLMLlama2(model_path, compression=8) prompt = "讲一个关于人工智能的小故事" inputs = tokenizer(prompt, return_tensors="pt").to("cuda") output = model.generate(inputs.input_ids, max_new_tokens=256) print(tokenizer.decode(output[0], skip_special_tokens=True))

代码本身不复杂，但有几个细节值得说。第一，model_path是在本地已经下载好的模型路径，airllm不会自动帮你下载权重，所以你要先把模型权重下载到本地，或者通过模型仓库工具把权重同步下来。第二，对应不同的模型架构要选择不同的模型类，Llama架构选AirLLMLlama2，Mistral架构选AirLLMMistral，如果你的模型架构不在内置类里，可以先转成支持的架构格式再用。第三，tokenizer需要用模型仓库里配套的tokenizer文件，airllm本身不负责加载tokenizer，但generate的时候需要。

跑起来之后，你会看到控制台不断输出每层加载、卸载的日志，整个生成过程会明显比常规推理慢。以我的实测数据，在一个4GB显存、32GB内存的环境里跑70B模型，大概每秒只能生成几个token，但这个结果本身已经足够让人接受了：毕竟硬件摆在那里，能跑已经算赢。

3.3 性能调优的三种手段

airllm默认配置能跑，但性能通常不是最优状态。我在实际使用中试过很多调整项，有三类手段效果最明显。

第一，控制输入和输出长度。如果你把max_new_tokens设成2048，那就要做好等待很久的心理准备，因为每生成一个token就要跑完整模型。选择一个合理的长度能大幅降低等待时间，日常调试建议先用32或者64，确认效果再放大。输入长度也一样，过长的prompt会显著拖慢首token的生成速度，尽量精简上下文。

第二，调整PyTorch显存分配策略。在代码开头设置环境变量PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True可以改善显存碎片问题。airllm在运行时反复加载和卸载层权重，显存分配和释放非常频繁，如果PyTorch使用默认的分配策略，容易产生大量碎片，导致实际显存并没空闲多少却分配失败。这个设置是我试过最有效的“白嫖”优化手段之一。

第三，做一次“冷启动”热身。首次加载模型时权重索引、缓存等都没有就绪，整体会慢很多。我的习惯是先让模型生成一个极短的输出，把该加载的资源都加载好，再进行正式推理，后续调用的延迟会明显降低。当然，这种优化只对单次启动后的多次推理有效，不会改变逐层加载的本质瓶颈。

4. 常见问题与避坑记录

4.1 高频报错速查表

使用airllm的过程中，报错几乎是不可避免的。我把遇到过的、以及周边朋友遇到的问题整理成了一张速查表，按报错现象来排查会快很多。

这张表里最容易被误解的是第一行。airllm首次加载模型时，如果权重文件很大，它要先建立内存映射、构建层索引，这个过程可能持续几十秒甚至几分钟，很多人误以为程序卡死了。解决方法是耐心等待，或者先用一个小模型验证环境是否正常，确认不是代码问题后再换大模型。

4.2 速度慢得离谱时的排查思路

速度慢是airllm的固有属性，但“慢”和“离谱的慢”是两回事。如果你感觉生成速度已经慢到完全无法忍受，先不要急着下结论说是airllm本身不行，大概率是你哪里没配好。

我排查速度问题时一般会按顺序问自己几个问题。第一，模型和权重是不是放在机械硬盘上？机械硬盘的随机读取速度远低于固态硬盘，而airllm每一层都要从磁盘读取权重，磁盘IO对整个推理速度的影响被放大到极致。把权重放到固态硬盘上，通常能带来几倍的提升。第二，系统内存是不是已经溢出到Swap分区了？如果你的物理内存不够，权重会在内存和磁盘之间反复交换，速度会断崖式下跌。可以用系统监控工具看一下内存占用，如果Swap占用持续上涨，说明内存已经成了瓶颈。第三，是不是CPU在参与计算？如果PyTorch没有正确启用CUDA，整个流程退化成CPU推理，速度比GPU慢一个数量级还多，这个一定要优先排除。

另外，生成预算也要合理。airllm的推理成本是很线性的，比如每秒生成3个token，生成512个token大约需要170秒。如果你要生成几千个字，就该考虑分批处理或者降低输出长度，而不是让程序硬跑。这个前提心里有数，就不会觉得airllm“坏掉了”。

4.3 显存、内存、磁盘三者的正确分配

airllm能把显存需求压下来，但并没有消除对内存和磁盘的需求，很多人在这里踩坑。一个理想的环境应该是：显存用来放当前层，内存用来放整个模型，磁盘用来放模型文件，三者各司其职。

显存方面，只要足够放单层权重和当前激活值即可，不需要留出整个模型的空间。以70B模型为例，单层权重在压缩后一般不超过1GB，所以4GB显存基本够用。内存方面，你必须保证内存容量大于模型压缩后的整体大小，这是硬性要求。磁盘方面，除了放原始权重文件之外，最好留出至少和权重文件等大的临时空间，因为加载流程中可能产生临时缓存。

这个三者分配关系理解了，你就能在部署前先估算自己的设备能不能跑。我在部署前会先做一次“容量预算”：确认模型大小、压缩倍数、内存大小、显存大小，如果内存和显存两项都达标，再花时间下载权重和环境配置。提前算清楚，避免花了半天时间下载一个跑不动的模型。

5. airllm与其他推理方案的选型建议

5.1 不同方案的本质差异

现在大模型本地推理的方案非常多，各家的优化思路差异很大。常见的主流路线大致可以分成三类：一是airllm这种“换显存空间”的按需加载方案，二是把模型量化到4bit并借用CPU卸载能力来运行的方案，三是面向高吞吐服务的高性能推理方案。

量化方案的思路是“把模型变小”，通过低比特权重让模型整体塞进显存，然后正常做自回归推理。好处是速度快，生成Token的延迟低，但前提是你的显存能够容纳量化后的完整模型。一个70B模型即使量化到4bit，也要35GB左右显存，很多人的卡依然装不下。airllm的思路则是“用小空间分时复用”，不追求模型完全驻留，而是用时间换空间。高吞吐服务方案的思路是“把显存利用到极致”，通过连续批处理、KV Cache优化等手段增加吞吐量，但这些方案要求模型必须完整驻留在显存里，对硬件要求更高。

这三类方案不是互相取代的关系，而是适用于不同硬件条件和不同使用场景。你在选型的时候，首先要回答的不是“哪个快”，而是“我的硬件条件能接受哪个”。如果显存足够，直接走量化推理；如果显存完全不够，airllm才有用武之地。

5.2 基于我的经验怎么选

我的选型经验基本可以归纳成三个场景。

场景一，显卡比较新且显存充足，比如24GB显存。这种情况我一般不会用airllm，因为显存足够容纳大多数量化后的开源模型，直接走量化推理能获得更好的速度和体验。airllm在显存充足时反而会让推理变慢，属于“被动妥协”方案。

场景二，显卡很老或显存很小，比如4GB、6GB老卡。这种情况airllm几乎是唯一能把70B跑起来的选择。我实测过它在这种环境下的稳定性和可用性，虽然速度不快，但至少能完成推理任务，用来做研究和验证是完全够的。

场景三，不需要追求实时性，只是离线批量推理。即使显存中等，如果对单条输出的延迟不敏感，airllm也是一个不错的选择。它不需要你专门买新硬件，也不需要做复杂的模型切分，配置简单、依赖简单，适合快速落地一个Demo。

当然，airllm并不是万能的。如果要做高并发服务，或者需要每秒几十个Token的高流畅体验，还是要考虑更专业的推理方案。选型的关键是认清自己的瓶颈：是显存不够，还是整体算力不够，还是并发需求高。搞清楚这一点，大部分选型问题都能迎刃而解。

最后提一句，airllm这种分层加载方案的后续发展方向其实很值得期待。比如随着模型权重量化技术和内存映射机制的进一步优化，混合推理的效率和适用范围还有很大提升空间。我自己在用过一段时间的airllm之后，最大的体会是“显存焦虑”真的可以被缓解：哪怕硬件不顶级，也能在自己的设备上直接实验最前沿的大模型。这不是鼓吹airllm无所不能，而是它的确给个人开发者开了一扇门：先让模型跑起来，然后再谈优化和体验。