AirLLM：低显存设备跑70B大模型的分层推理方案

1. AirLLM是什么：一台低配电脑跑70B大模型的思路

1.1 从一次折腾说起：显存不够怎么办

我接触大模型推理比较早，但绝大多数时间都被同一个问题卡住：显存不够。常见的中型开源模型也有几十亿参数，按FP16精度计算，一个30B模型光权重就要占60GB左右，更别提激活值和临时缓冲区。我手头这台笔记本只有4GB显存，连一个13B模型都塞不进去，当时想跑更大的模型，基本只有两条路：要么租高价服务器，要么忍住。说实话，那种被硬件卡住的感觉非常难受。

后来我换了个思路：真的有必要把整个模型一次性加载到显存里吗？带着这个疑问，我找到了airllm。它解决的核心问题就是：当你的硬件远小于模型体积时，怎么尽可能地把模型跑起来。它不是把模型变“小”，而是改变模型加载一次性的方式，让显存的占用只跟模型的“一层”有关，而不是整个模型。这样一来，一个参数规模在70B级别的开源大模型，居然在我这台4GB显存的机器上跑通了。说这是“戏法”有点夸张，但确实让我对推理的认知刷新了一层。

1.2 AirLLM的核心定位：边缘设备上做LLM推理

AirLLM是一个面向边缘设备的大模型推理优化方案。所谓“边缘设备”，其实就是我们不那么高配的本地机器，不像数据中心那样堆GPU。它提供的是一套“分层推理”机制：把模型按照Transformer的层级切分，每一层计算时才把该层的参数从内存/磁盘搬到计算设备上，计算完再换下一层。我一开始听到这个机制时，本能地觉得“这不就是牺牲速度换容量吗”。实测后确实如此，但它换来的是“普通人也跑得动超大模型”的可能性，这本身就是很大的价值。

为方便描述，我用“CPU/内存”表示非GPU侧，用“GPU显存”表示计算侧。airllm的思路就是让计算侧每次只保留一层的权重和中间激活，其余全部放在非GPU侧。这样在资源和性能之间做了一个相当务实的选择：不追求极致的吞吐，只追求“能跑起来、结果可用”。

这一节我们把“能跑起来”这句话拆开：它意味着你不需要修改模型文件，不需要手工做网络结构改造，只需要调用库提供的接口去加载和生成。对普通开发者来说，这一点体验上很舒服，相当于把一个原本需要研究几天的问题变成了几行代码。对一个想快速验证模型效果的人来说，这种低门槛极其重要。

2. 分层推理机制：为什么显存占用能这么低

2.1 模型推理的内存模型：加载整个模型与逐层加载的区别

先从Transformer模型的基本结构说起。一个典型的大模型由若干层堆叠而成，每一层基本结构类似：层归一化、自注意力、前馈网络等等。推理时，数据从第一层流到最后一层，每一层只在自己的权重上做计算，和下一层的权重没有直接关系。这意味着“按层切分、逐层加载”在原理上是可行的，层与层之间只需要传递张量，而不需要同时驻留所有层的参数。

传统的加载方式，是把全部权重放进显存。一个700亿参数模型，即使只算模型权重部分，FP16精度下大概是140GB。即使使用8bit量化，也要70GB左右。普通消费级显卡根本装不下。airllm的做法是降低“同时存放在显存中的权重体积”：先把第一层权重搬到显存，计算完产生中间结果后，把这一层权重放回内存/磁盘，再加载第二层。显存峰值大约等于“最大单层权重 + 激活 + 临时缓冲区”，而不是“全部权重”。

这里有个很关键的细节：模型虽然大，但单层权重并不大。以70B模型为例，如果层数在80层左右，单层权重平均下来可能在1GB上下。只要单层权重不超过显存上限，理论上就能跑。这也是为什么airllm能让小显存设备跑超大模型的真正原因：它把“一层”作为显存资源调度的基本单位。

2.2 计算过程与CPU-GPU协同：数据流动的完整链路

实际运行时，数据流动是这样的：模型权重一开始都保存在内存或磁盘上，模型结构则常驻内存。每次前向传播时，对于第i层，系统把它的权重拷贝到显存，在GPU上完成计算，生成的中间激活可以从显存拷贝回内存供下一层使用。下一层重复这个流程。这一层的权重计算完，不再需要时，系统就可以释放显存，给下一层腾地方。

你可以把它理解为“接力赛”：每一棒只拿一小段接力棒，跑完就交给下一个人。虽然每个人的路程相同，但手上拿的东西永远很少。airllm需要精打细算的是：什么时候预取下一层权重、什么时候释放当前层、中间激活放在哪里，这些调度策略直接影响速度和稳定性。实际实现里还会考虑分块传输、内存碎片等因素，否则频繁申请和释放大块内存会让系统越来越卡。

为了让流程更稳定，airllm通常会把权重以特定格式组织好放在本地文件中，每次读取固定大小的分块。这样既避免了内存随机访问的低效，也减少了频繁申请释放大块内存导致的内存碎片。我实际观察过系统状态，推理过程中内存在有节奏地上升和回落，显存则始终维持在一个很稳定的低水位。这种调度机制如果靠手工实现，恐怕要写很多底层代码，而现在只需要调用高层接口。

2.3 与其他卸载方案的对比：AirLLM的取舍

这个思路并不是airllm独有，很多推理框架都支持参数卸载。区别在于侧重点。传统离线卸载会把部分层固定放在显存，部分层放在内存，计算时跨设备激活，这种做法显存占用仍然与模型整体规模线性相关，只是系数变小。另一种常见的ZeRO系列优化，主要面向多卡训练，强调通信优化，对单卡低显存场景不是最优解。airllm的分层加载，显存占用和单层参数强相关，和层数基本无关，所以它能跑特别大的模型，但代价是每层都要经历一次传输，总耗时显著增加。

我整理了一张对比表，方便理解不同方案的适用场景：

因此airllm更适合“显存严重不足但允许较慢推理”的场景。它把“能不能跑”排在“跑得快不快”前面。如果你本来就有充足显存，那没必要用它；但如果你和我一样，只有一块低端显卡，又特别想体验大模型的能力，那它几乎是最省事的入口。

3. 环境准备与安装：从零开始搭建可运行环境

3.1 硬件要求与依赖清单

先说硬件底线。我实际测试的配置如下：

• 内存：16GB DDR4
• 显卡：入门级显卡，显存4GB
• 系统：Linux，Python 3.10

airllm允许在显存比较小的情况下运行，但如果内存太小，也要慎重。原因很简单：虽然显存占用低，但中转数据需要先把整层权重放在内存里，再由内存搬到显存，内存至少要能容纳当前层权重加上操作系统和其他进程的开销。按我跑70B模型的经验，16GB内存比较紧张但不至于崩，如果能把模型精度降到8bit或4bit，内存占用会更低，整体流程也稳很多。

依赖方面，主要是PyTorch和相关的模型加载库。这里有一点要注意：安装前先确认你的CUDA版本和PyTorch版本匹配，否则即使库装好了，推理时一跑就会报设备相关错误。我一开始就吃过这个亏，装完airllm后跑模型，报错提示CUDA driver和runtime版本不一致，最后只能重新装对应版本的PyTorch。所以在你执行任何安装命令之前，先看一眼自己的显卡驱动支持的CUDA版本，这样能省下大量排查时间。

3.2 安装步骤与模型权重准备

安装airllm本身不难。可以把它看作一个Python包，直接装就行。我最开始用的环境里已经有PyTorch，所以省了一步。建议用虚拟环境隔离，避免把系统环境搞乱。这里给出一个典型流程：

python -m venv airllm-env source airllm-env/bin/activate pip install --upgrade pip pip install airllm

如果PyTorch还没有装，建议先根据你的CUDA版本安装对应版本的PyTorch，再装airllm。官方维护的依赖列表通常会在安装时自动拉齐，但如果你手动装了奇怪的版本，可能会遇到接口不兼容的问题。

安装后，需要准备模型权重。airllm并不直接给你模型，它只是一个推理引擎，模型本身要从模型仓库拉取或手动下载。如果你是第一次用，建议先用一个7B级别的模型做端到端验证，跑通了再换70B级别的模型。这里给一个顺序：

1. 建一个目录存放模型权重。
2. 从模型仓库把模型权重文件和配置文件下载到本地。
3. 检查模型格式是否被airllm支持，通常是支持常见开源模型的checkpoint格式。
4. 写一个最小调用脚本，验证能否正常加载和生成。

我建议第一次验证时不要一上来就加载70B模型，因为如果代码有问题，你会浪费大量时间等待文件读取。用一个更小的模型快速走通全流程，确认代码没问题，再切换到大模型，效率会高很多。

3.3 一个容易忽略的配置：环境变量与缓存目录

我在第一次使用时就遇到一个问题：脚本跑起来以后，它一直在下载东西，然后下载到一半失败。后来发现它默认的缓存目录空间不够。模型权重文件动辄几十GB，如果放在系统盘，很容易把盘塞满。建议提前把缓存目录或下载目录改到大磁盘分区。

具体做法是在运行前设置环境变量，把下载缓存重定向到你有足够空间的路径。以Linux为例，可以这样：

export AIRLLM_CACHE_DIR=/data/airllm_cache export MODEL_CACHE_DIR=/data/models

当然不同版本使用的环境变量名可能不同，但核心思路是一样的：别让默认路径把你系统盘撑爆。另外，如果你下载的是超大模型，建议先确认磁盘剩余空间至少是模型文件体积的1.5倍，因为解压和转换过程中会产生临时文件。

4. 实操演练：加载模型、生成文本与参数调优

4.1 最小可运行代码：三步完成一次推理

下面这个是我在本地验证过的最小示例，用当前版本的接口写出来大概是这样：

from airllm import AutoModel # 指向本地模型权重目录 model_path = "/data/models/your-70b-model" model = AutoModel.from_pretrained(model_path) prompt = "Explain how airplanes fly in simple terms." output = model.generate(prompt, max_new_tokens=256) print(output)

这段代码里，from_pretrained负责把模型结构加载到内存，并按airllm的格式准备好权重，此时并不需要大量显存。generate时才触发分层加载，逐层完成前向计算。我第一次跑的时候，看到控制台不断出现“layer x loading”类似的日志，才意识到它确实在一层一层地处理。

这里想提醒一个容易踩的点：首次调用generate可能会明显慢，因为它要做文件读取、权重格式转换、设备预热等操作。不要因为日志看起来很慢就以为卡死，可以先等一两分钟。我后来养成一个习惯：如果脚本超过三分钟没有任何输出，我才会去排查是不是卡住，而不是一看到慢就立刻终止。

4.2 常用生成参数与效果对照

推理时我调过的几个参数：

• max_new_tokens：控制生成长度，太大容易拖慢总耗时。
• temperature：控制随机性，0表示偏向确定，1附近更随机。
• top_p：核采样，配合temperature使用。
• do_sample：是否采样，默认可能是贪婪解码，想看到多样性就需要打开。

我做过一个小对照，同样一句prompt，采样参数不同输出风格差别很大。下面表格是我个人心得：

注意，参数不是越大越好。我在测试时把temperature调太高，模型开始输出很多不相关内容，对需要一致性回答的任务反而有害。你如果想让airllm处理的是结构化任务，比如摘要、分类、抽取，那么把temperature调低甚至关闭采样，效果会更可控。

4.3 量化配置：4bit推理如何进一步压低显存

模型体积主要是权重决定的，airllm支持把权重做低比特量化，比如4bit，这样单个模型在磁盘和内存里可以缩小到原来的四分之一左右。推理速度也会有一定提升，因为需要搬运的数据量变小了。这个优化对低显存设备非常关键，我实际使用70B模型时，如果不量化，内存搬运压力很大，整个推理过程变得很吃力；开启4bit后，明显更顺畅。

量化配置通常在加载模型前后设置，具体取决于接口。我当时的做法是实例化模型后调用配置接口，然后重新加载。简单示例如下：

from airllm import AutoModel, QuantizationConfig model = AutoModel.from_pretrained(model_path) quant_config = QuantizationConfig(bit=4, group_size=128) model.set_quantization_config(quant_config)

需要提醒，4bit量化会带来一定精度损失，尤其在专业问答、数学推理任务上，模型答案可能变得不够精确。所以不是所有场景都无脑开4bit，建议根据你的输出质量要求来做取舍。我自己的经验是：如果只是写代码、做总结，4bit完全够用；如果要做严谨的数学推理或复杂逻辑，8bit更稳妥。

5. 我踩过的坑：内存碎片、速度瓶颈与精度损失

5.1 首轮推理异常慢：这不是卡死，是预热

如果你第一次运行模型，发现几十秒都没有输出，先别急着杀掉进程。airllm的每个推理流程里，权重要从内存搬到显存，如果是70B级的模型，哪怕量化以后也有十几GB的数据要逐步处理。遇到这种情况，建议观察日志和资源占用：如果CPU使用率很高，内存持续增长，说明它在正常干活。我用70B模型时，首轮生成一个短句子都要接近半分钟，后面轮次会稍微快一点，因为有一些层的数据可能留在了内存缓存里。

我还发现一个规律：如果长时间没有执行生成，再下一次生成时，速度又会变慢。原因是系统把部分缓存释放掉了，需要重新加载。所以在做连续对话时，尽量把多轮请求放在一个进程里连续执行，不要频繁重启服务。

5.2 量化后输出质量下降：如何选择量化位宽

量化虽然省资源，但会让模型在一定程度上“失真”。我做过一个对比：8bit和4bit在同一问题上的回答，8bit明显更贴近原模型，4bit则会偶尔出现逻辑混乱。如果你的任务对答案质量要求很高，建议优先用8bit，或者干脆不量化；如果只是为了验证效果和跑通流程，4bit也可以接受。

这里给出一个选择方向：

• 2bit：能跑，但输出质量明显下滑，基本只适合功能演示。
• 4bit：适合日常对话、文本补全、大部分生成任务。
• 8bit：适合更严肃的任务，比如事实问答、代码生成。
• 16bit：条件允许时优先，但显存和内存压力会成倍增加。

还有一个细节是：量化配置不要随意切换。如果你在同一个进程里反复切换8bit和4bit，可能导致权重缓存失效，之后每次生成都重新加载，整体体验会更卡。我一般在开始推理之前就设定好量化档位，后面不再改。

5.3 并发与多轮对话场景下的资源管理

airllm主要面向单次推理优化，如果同时并发多个请求，每一路都会重复读取权重，内存和磁盘IO压力会成倍放大。我在测试里同时开两路生成，结果生成速度掉得非常厉害，因为两条链路都在抢同一块显存和磁盘带宽。如果你做的是服务端应用，建议要么在airllm外层加一个串行队列，要么换成更偏吞吐优化的推理框架。

多轮对话也有类似问题。每次对话生成完，模型内部状态如果不清理，下一轮可能继续占用大量内存。我的习惯是每完成一轮完整任务，就主动释放模型对象，必要时重启进程，保持内存干净。如果要用它做长期服务，最好定期监控内存占用曲线，一旦发现异常，及时处理。

6. 什么场景适合用AirLLM：我的真实判断

6.1 适合的硬件配置与任务类型

从我的实际体验看，airllm比较适合这几类情况：

• 机器显存4GB-8GB，内存16GB-32GB，跑不了显存密集型推理。
• 任务以离线批量生成、学术研究、个人学习为主，对延迟不敏感。
• 不想买多卡设备，但又想看更大模型的效果。

如果你的目标是“快速测试某个大模型的下游任务表现”，airllm是个不错的起点。它把环境门槛拉低，让更多人可以亲手尝试超大参数模型，而不是只能看别人的推理截图。我身边有朋友拿它做文本分类实验，也有一名开发者用它对接自己工作中的长文档摘要需求，效果都还过得去。对于这些场景，慢一点不是核心问题，真正解决问题才是。

6.2 不适合的场景：延迟敏感型应用要三思

如果你要做在线API，用户点一下就要几秒内出结果，airllm可能不合适。分层推理天然存在多次搬运，延迟比一次性载入模型高出一个数量级。这种情况下更合理的方案是租用高显存服务器，或者使用模型压缩到足够小的方案。

另外，如果你面对的是超长上下文任务，比如几万token的文档分析，airllm的中间激活也可能成为瓶颈。因为激活值通常不能像权重一样随意卸载，显存占用可能随之升高。我在个人测试中跑短文本很稳，跑几千token的长文本时明显变慢，偶尔还会出现内存吃紧。这类需求建议用针对长上下文优化过的推理方案，而不是强行用airllm来做。

6.3 后续扩展思路：结合其他优化手段

如果你在某些场景里还是觉得慢，可以把它和其他优化手段结合使用：

• 模型剪枝或蒸馏：先把模型变小，再用airllm推理，能明显降低内存压力。
• 流式输出：让generate配合流式接口，用户不用等全部生成完，体验会好很多。
• 按批次做长任务调度：把多个请求排好队，轮流使用推理资源。

把这些组合起来，airllm就不是一个只能“看看”的玩具，而是一个真正能放在工作流里的底座。我在自己的离线分析任务里，已经稳定跑了两周，中间没有出现内存泄漏或模型崩溃的问题。可以说，它帮我完成了一件以前需要一台高配设备才能完成的事：在普通电脑上，认真体验并评测一个庞大的开源模型。

最后再说一个小技巧：如果你是第一次尝试，建议准备一个专门的测试目录，把模型、脚本、输出日志分开存放。这样既方便对比不同参数下的效果，也能在遇到问题时快速定位原因。毕竟跑大模型本身就是在和资源瓶颈打交道，能省一点排查时间，都是实实在在的收益。