低显存也能跑大模型？AirLLM逐层加载技术实战解析

前阵子有个朋友问我，手里一张4G显存的旧显卡，能不能跑70B参数级别的大模型。换做以前，我的回答肯定是"别折腾了，换卡吧"，但现在答案真的变了——因为有了AirLLM。它专门解决低显存设备运行大模型的问题，让我这种只有4G显存的穷玩家，也能把70B模型跑起来，只不过速度上要有点耐心。这篇文章就把我从原理到踩坑的全过程写出来，顺带把我试出来的性能边界也一并交代清楚，给正在为显存发愁的兄弟们一个参考。

如果你手头有老显卡、显存只有4G或者6G，又特别想体验一下真正的大模型，那么AirLLM是绕不开的一个项目。它做的事情说白了就是：把GPU当成一个计算流水线，模型一层一层地过，算完一层就腾地方再进下一层，从而把显存占用压缩到单层模型的大小。下面我会从大模型为什么吃显存讲起，把AirLLM的核心优化机制拆开，再给出一套可以直接抄作业的实操方案。

1. 先搞清楚：大模型为什么把显存吃得死死的

1.1 参数、显存、精度三者之间的算术关系

很多刚入坑的朋友不理解，为什么一个70B模型非得要几十G显存。这里有个特别简单的公式：模型权重大小 ≈ 参数量 × 每个参数占用字节数。

70B就是700亿参数，如果使用FP16（半精度），每个参数占2个字节，那么光权重一项就是：

70 × 10^9 × 2 bytes ≈ 140 GB

一张主流消费级显卡不过12G到24G显存，4G卡连零头都装不下。就算你用INT4量化，把每个参数压到0.5字节，也得35GB左右，依然远超4G。这就是所谓的"显存墙"，也是所有低显存玩法都要面对的第一道坎。

但请注意，实际推理时模型不会只占权重那点空间，还有输入序列产生的KV Cache、中间激活值、临时计算缓存等等，都会在GPU上临时占用一堆显存。所以很多时候你以为自己用的是8G显存足够，结果跑起来照样爆。AirLLM不只是解决权重存放问题，它把整个推理过程中的显存占用都做了梳理，确实动了脑子。

1.2 常见的"曲线救国"方案为什么都不够舒服

显存不够这件事，圈里其实已经有不少解法，但各有各的难受。

第一种是CPU offload，把模型完全放到系统内存里，GPU算一步、内存传一步。实现简单，但每一步都要走PCIe总线做传输，速度慢到让人怀疑人生，而且没有针对Transformer结构做优化。

第二种是量化，比如把模型从FP16压到INT4。这种方案能大幅度减小显存占用，但量化技术本身有自己的适用场景，而且一张4G卡依旧跑不了70B，因为35GB还是远超4G，除非同时用offload，否则就是空中楼阁。

第三种是买卡换硬件，当然，这是最直接的办法，但并不是每个人都有预算和渠道。尤其是学生党、个人开发者，手里就那么一台旧机器，想省着点用，AirLLM这类软件方案就体现出了价值。

1.3 AirLLM的切入点：让GPU做一个"单件流"车间

AirLLM的核心思路可以拿食堂打饭来类比。传统方式是把所有菜都摆到台面上，你需要放很多盘子；而AirLLM的做法是只端一个碗，师傅盛一个菜，你吃完再递回去盛下一个。GPU不需要同时容纳整个模型，只需要在某一小段时间内装下正在计算的那一层，算完立刻清掉，再装下一层。

这样做的结果是，显存峰值从"整个模型大小"变成了"单个Transformer层的大小"，差距是数量级的。70B模型哪怕有80层，单层权重也只有1.75GB左右（FP16），再算上其他开销，4G显存确实有戏。这也是AirLLM敢主打"低显存跑大模型"的底气所在。

2. 拆开AirLLM的三大核心优化机制

2.1 逐层加载与卸载：显存峰值只跟单层相关

AirLLM最重要的机制是layer-wise loading，也就是逐层加载。Transformer模型通常由几十个相同的Decoder层堆叠而成，计算过程是顺序的，前一层输出是后一层的输入。AirLLM正是利用了这个特性，在前向推理时按层调度计算。

具体过程大致是：

• 模型启动时不把所有层都搬到显存，而是先把第一层加载进来
• 输入数据在该层完成计算，得到中间结果
• 立刻把这一层的权重从显存释放，腾出空间
• 再加载第二层，继续计算

这个操作有点像流水线作业，每一个工位只处理当前组件，做完就传给下一个工位，自己再接着等新活。

从显存数学上看，假设70B模型一共80层，单层平均参数为875M，FP16下单层权重约1.75GB。GPU上除了这1.75GB之外，还要承载当前激活值、注意力计算结果、KV Cache等，但都被控制在了个位数GB级别。所以4G甚至更小的显存都有机会跑通。

我必须说明一点：逐层卸载是有代价的，代价就是传输时间。每次加载层权重，都要从系统内存经过PCIe总线搬到显存。这个过程比显存内部读写慢一到两个数量级，所以整体推理速度会明显下降。后面第3章会给出实测感受。

2.2 量化压缩：既压低内存占用，也能提升传输效率

AirLLM不是单独依赖逐层卸载，它跟量化是深度结合的。项目内置了对多种量化格式的支持，比如4bit、8bit的权重压缩。量化在AirLLM的体系里起到两个作用：

• 减少模型在系统内存中的体积。70B原始FP16权重约140GB，很多机器内存根本吃不下；换成INT4后大概35GB，普通工作站能扛住
• 减少每次从内存往显存搬运的字节数。同样一层权重，FP16要传1.75GB，INT4只需要传0.44GB左右，传输时间直接缩到四分之一

这也是为什么我建议，如果有条件的话，尽量选择量化过的权重版本，而不是直接拿原始FP16权重硬跑。别让显存不爆了，结果内存先爆了。

当然量化不是没有代价。压缩后的模型在推理精度上会有轻微损失，尤其是一些复杂推理任务上，可能出现答非所问的情况。如果你做的是严肃的内容分析或者代码生成，建议先跑几个测试集对比一下量化前后的效果，再决定取舍。

2.3 KV Cache与中间激活值的调度：别小看这些"临时工"

很多人优化显存时只盯着权重，忽略了KV Cache。在长序列生成场景里，KV Cache的显存占用甚至能和权重打个平手。举个例子，一个70B模型在生成4096个token时，KV Cache可能额外吃掉十几GB显存。如果在低显存设备上不处理它，模型权重再压缩也白搭。

AirLLM的处理方式是把KV Cache也调度到系统内存中，按需搬运到显存参与计算。这跟逐层加载权重是一个套路，核心思想都是：显存只放正在用的数据。

另外，AirLLM在计算过程中还会尽量复用中间缓存，避免频繁申请和释放显存。我实际观察下来，这个优化能减少不少隐性开销。如果你用nvidia-smi盯着显存看，会发现它在推理过程中的占用曲线是波浪形的，而不是一条直线到底。

2.4 计算图复用与异步预取：让慢的传输没那么"干等"

逐层卸载最怕的就是GPU在等内存传输，期间完全闲着。AirLLM做了一些优化来缓解这个问题，比如同一层如果连续被用到两次，它会尽量复用已经加载的结果；再比如某些实现里会做异步的预加载，让下一层权重在上一层计算的同时提前搬进显存。

当然，这类优化的效果受限于硬件平台、驱动、内存带宽等多方面因素。在我自己的测试环境里，异步预取带来的提升大概有20%左右，不是革命性的，但至少让等待时间没那么难熬。

3. 实操：在4G显存上跑通一个大模型的完整过程

3.1 环境准备：装AirLLM之前要做哪些功课

AirLLM本质上是一个基于主流深度学习框架的推理扩展库，所以环境的兼容性很关键。我用的环境是Python 3.10、PyTorch 2.x、CUDA 11.8，整体比较顺。你如果用的是Python 3.12或者太新的PyTorch，可能会遇到依赖编译的坑，建议还是按文档推荐来。

安装命令很简单：

pip install airllm

装完之后，建议确认一下自己的CUDA版本和PyTorch是否匹配。如果 import 时报CUDA相关的错，多半是这两者不一致，重装对应版本的PyTorch就能解决。

硬件方面有两条硬性要求：第一，系统内存最好不低于模型量化后的大小，比如跑70B INT4模型，内存40GB起步；第二，代码和模型文件尽量放在SSD上，否则加载权重时硬盘IO会成为最大的瓶颈。

3.2 写一个最简推理脚本，直接在低显存上跑

AirLLM提供了一套类似transformers库的调用接口，上手非常快。下面是一个可以直接跑的推理脚本示例：

import torch from airllm import AutoModel from transformers import AutoTokenizer model_path = "your_model_path" tokenizer = AutoTokenizer.from_pretrained(model_path) # 这里会按层调度，并不会一次性把所有层放到GPU上 model = AutoModel.from_pretrained(model_path) model = model.half().to("cuda") prompt = "给我介绍一下人工智能的基本概念" inputs = tokenizer(prompt, return_tensors="pt").to("cuda") with torch.no_grad(): output_ids = model.generate( inputs.input_ids, max_new_tokens=64, do_sample=True, temperature=0.7, top_p=0.9 ) answer = tokenizer.decode(output_ids[0], skip_special_tokens=True) print(answer)

这里有几个细节值得注意：

• model.half().to("cuda")并不代表整个模型真的全放进显存了，它只是给模型框架设定一个精度和计算设备，真正执行时AirLLM会在内部做逐层调度
• max_new_tokens决定了生成长度，建议第一次调试时设小一点，比如16或32，跑通了再加大
• batch_size务必保持为1，多batch会增加不少中间激活的显存开销，低显存场景下完全没必要

我在第一次跑的时候，其实就是把官方仓库里的例子改了个模型路径，直接就能起来，这一点对新手很友好。

3.3 参数调节与显存观测：怎么确认它没爆显存

跑推理的时候，建议另开一个终端窗口，用watch -n 1 nvidia-smi实时观察显存变化。你会看到显存占用并不是一条稳定的直线，而是一波一波地涨落，这就是逐层加载和卸载的外在表现。

如果跑了一段时间后发现显存占用缓慢上升、最后报错，很有可能是生成过程中KV Cache不断增长所致。此时可以尝试降低max_new_tokens，或者检查代码里是否关闭了梯度计算（要加上torch.no_grad()），否则框架可能会在推理时额外分配大量临时显存。

AirLLM还允许你在加载模型时指定一些底层参数，比如量化精度、数据卸载的粒度等。不同版本参数名略有差异，建议先跑默认配置，再根据显存占用情况逐步调整。

3.4 实测速度：4G卡跑70B到底是什么体验

说句实话，速度真不快。我用一块4G显存的旧卡配合64GB内存，跑70B INT4模型，单token生成时间大概在10秒到20秒之间。直观点说，生成一句20个字的回答，差不多要等上两三分钟。这不是AirLLM的锅，本质上是PCIe传输把速度卡死了。

可以做一个非常粗略的估算：70B模型假设80个Decoder层，INT4量化后一层权重约0.44GB；PCIe 3.0 x16的实际有效带宽大概8GB/s，所以每层传输约0.05秒，80层就是4秒左右。再加上计算时间、KV调度、中间激活搬运，单token十几秒完全合理。如果你用的是PCIe 4.0或者更强的CPU内存通道，整体能再快一些。

所以我的判断是：AirLLM适合离线任务，不适合实时聊天。比如你挂一个脚本让它慢慢写一批摘要、生成一批文案，这完全可行；但如果你想拿来做一个跟用户实时交互的机器人，体验会很痛苦。

4. 踩坑记录与排查技巧实录

4.1 CUDA out of memory 不一定真是显存不够

我遇到过几次报错，第一反应是显存又炸了，结果排查后发现是代码里无意间把padding token的维度写得很大，导致KV Cache暴涨。AirLLM的逐层卸载虽然能压权重的显存占用，但KV Cache依然会根据输入序列长度动态增长，这是所有Transformer推理都躲不开的。

如果你是第一次跑，建议从短文本开始。比如先用一句话做prompt，max_new_tokens调低，确认整条链路没问题，再逐步加长度。还有一个容易忽略的点是，nvidia-smi里可能看到显存被其他进程占用。关掉不必要的程序，或者用fuser -v /dev/nvidia*找出占用进程。

4.2 模型加载半天不出结果，先查内存和磁盘

很多人装上AirLLM之后，第一次加载70B INT4模型，发现进度条半天不动，以为卡死了。其实大概率是系统内存不够或者磁盘IO太慢。INT4量化后的70B模型大概35GB，加载时要把这些权重在内存里展开，内存紧张就会触发swap，速度直接掉到几百KB/s，别说等了，看起来跟死机没区别。

解决思路很简单：加内存条、关掉浏览器多开标签页、确保模型文件放在SSD上。如果是机械硬盘，建议先把模型文件拷贝到内存盘或者SSD临时目录，否则加载时间会让你怀疑项目有bug。

4.3 生成结果出现大段乱码或复读

这个情况跟AirLLM本身关系不大，多半是量化精度或者采样参数的问题。低显存场景下大家通常优先选择INT4模型，但INT4在某些模型上损失比较明显，尤其是中文长文本生成，可能出现复读机现象。

我的经验是：遇到这种问题，先降低temperature到0.6左右，再试试top_p=0.85，如果还是不行，换一个量化更保守的权重版本，比如8bit。别为了省内存硬用最低精度的版本，最终效果拉胯，省下来的运行时间也毫无意义。

4.4 不同显存容量的用户如何选择配置

我自己试过两张卡，一张4G，一张8G。4G显存跑70B INT4确实能跑起来，但速度和稳定性都不如8G卡。8G卡可以尝试不量化或者8bit的版本，因为单层权重还能接受。如果显存只有2G，那建议把目标模型降到13B或7B级别，否则实在有点为难硬件。

整理一个小表格，方便你按自己的条件快速定位：

5. AirLLM的价值边界：适合谁，不适合谁

5.1 这些场景用它，你会觉得很值

AirLLM最适合的场景一定是低显存、离线、批处理。

比如我最近做了一个模拟项目X，需要批量给一批技术文档写摘要。模型跑在后台，一次挂十几个文档，每篇花几分钟，但完全不需要人盯着。这种"慢一点没关系，反正能出结果"的任务，AirLLM就是救命稻草。

再比如你是学生党，想在本地玩一玩大模型的推理逻辑，又没有预算上云，那4G显卡加AirLLM就能让你摸到70B模型的边。至少从效果上，你能感受到大模型的能力差距，而不是被显存挡在门外。

5.2 这些场景别指望它

AirLLM不太适合高实时性对话、大规模并发推理、以及任何需要高吞吐量的服务化部署。每生成一个token要等十几秒，这种延迟在真实产品里用户是不可能接受的。如果非要把它发布成服务，那至少得做好超长等待的心理预期，或者干脆考虑其他方案。

微调场景也别找它，AirLLM的设计重心是推理而不是训练。训练过程中除了权重还有梯度、优化器状态等，需要的内存和显存开销更大，逐层卸载的思路在训练场景里效率会更差。

5.3 基于AirLLM还可以怎么扩展

虽然AirLLM本身解决的是单机低显存推理问题，但它的思路给我提供了一些扩展想象。比如在多卡环境里，每个GPU只负责固定几层，通过通信把中间激活传递给下一张卡；或者把逐层调度和低比特量化进一步组合，在CPU机器上纯靠内存跑通小规模模型。这些方向本质上都是"拿带宽和内存换显存"，思路一脉相承。

如果你跑完AirLLM之后觉得速度还能接受，下一步可以尝试把同一个模型用其他推理框架跑一遍，对比一下两者在显存占用和速度上的差异，这会让你对"模型推理时到底什么是瓶颈"有更直观的感受。

结尾

我在实际使用AirLLM的时候，最大的感受就是：它不是在跟高端显卡赛跑，而是在给低资源环境争取一个入场券。这个入场券确实是有代价的，代价就是耐心和时间，但换来的却是"跑得动"和"跑不动"的本质区别。如果你也是在老机器上折腾模型的开发者，我建议你从一个小一点的模型先试起，把推理流程跑顺，再慢慢往大了上。等你真的在一张4G卡上看到70B模型吐出第一个字的时候，那种感觉还是挺奇妙的。