4GB显存跑70B大模型？AirLLM分层加载推理实践

如果你和我一样，手里的显卡只有 4GB 显存，却又想跑跑 70B 级别的开源大模型，airllm 可能是目前最省事的思路之一。我最早看到这个项目时，下意识以为它又是某个靠量化压缩来硬塞模型的工具，毕竟低显存跑大模型的常规套路就是把精度从 fp16 一路砍到 int4。但实际跑过一次之后我发现，它走的是另一条完全不同的路径：不急着把权重缩小，而是把模型按层拆开，算完一层立刻换下一层，用时间换空间。这篇文章记录我在 4GB 显存机器上从安装到跑通的完整过程，包括背后的推理原理、性能表现和几个文档里没写清楚的坑。

1. AirLLM 解决的核心问题：显存不够，就别把整个模型塞进显存

传统大模型推理为什么吃显存？简单说，模型权重必须待在显存里，因为 GPU 只认自己的显存。一个 70B 参数模型，如果用半精度保存，光是权重就要 140GB 左右；即使格式转换成 8bit，也要大概 70GB。普通消费级显卡的 8GB、12GB 显存连零头都不够。于是大多数方案想到的是“减小模型体积”——量化、蒸馏、剪枝。airllm 的思路不太一样：既然装不下，那就不装了，每次只把当前计算需要的部分放进显存。

为了理解这句话，我们要看 transformer 模型的数据流。无论模型的参数是 70B 还是 1B，它的前向计算都可以切成一层一层。数据先经过第一层，输出传给第二层，再传给第三层，逐层往后走。层和层之间是强依赖关系，上一层不结束，下一层不能开始，但单个时刻真正在 GPU 上活的权重，其实只有一层。airllm 把这个特性做到了极致：前向传播时，把第 k 层搬到显存，计算完生成中间结果，立刻把第 k 层的权重从显存挪走，接着把第 k+1 层加载进来。整个过程中，显存只需要容纳一层权重和这一层的激活值。

1.1 我为什么会遇到 70B 模型跑不动的尴尬

我自己常要处理长文本生成任务，习惯了本地私有化部署模型。之前为了跑一个大模型，试过租远程实例、换新卡，但这些方案要么贵，要么受网络影响，模型权重也被带着跑来跑去。一次临时需求需要在完全离线的环境下做推理，手里只有一台 16GB 内存、4GB 显存的机器。按照常规思路，结局是“装不下”三个字。airllm 是我在翻开源项目时偶然看到的，它不要求我把模型权重量化到面目全非，而是用分层加载、逐层交换的方式把 70B 模型放在普通机器上跑，这直接解决了我最大的痛点。

1.2 分层推理的朴素原理

打个比方，读一套一百本的大部头，不需要把全套书一次摊在桌上。你只需要从书架取下当前要读的那本，读完放回去，再取下下一本。空中飞过的时间变多了，但一套书最终能读完。airllm 也是这个逻辑：GPU 是书桌，CPU 内存和硬盘是书架，模型一层层的权重就是一套书。权重不常驻显存，而是一层一层被取出来、用完、放回去。相比一次加载全部权重，速度必然会慢，因为它把昂贵的显存空间换成了可接受的运行时间。

不过这里有个容易被忽略的点：虽然显存占用大幅降低，但 CPU 内存和磁盘 IO 会变成新的瓶颈。因为每一层都要从内存搬到显存，搬完之后再搬回来，如此反复几十次。如果 CPU 内存不足或者硬盘速度慢，整体时间会成倍增长。所以 airllm 不是单纯把压力从显卡转移到内存，它实际上是在做三层存储的协同：显存放当前层，内存放下一个需要预取的层，磁盘放暂时不需要的权重。这三层之间的搬运速度，直接决定了最终生成速度。

2. 安装与准备：版本、依赖和一个容易忽略的存储目录

第一次安装 airllm 之前，我建议先确认自己的软件环境。它本质上是给主流深度学习框架套了一层新的推理接口，所以框架版本和 GPU 计算库版本是否匹配很重要。我在 Linux 环境下用的是 Python 3.10，先建好虚拟环境，再安装依赖。如果你用的是 Windows，理论上也支持，但 GPU 相关组件要更小心一点，容易在底层库版本上踩坑。

2.1 最小安装命令与硬件前提

安装核心包很简单，就一条命令：

pip install airllm

但我在实际过程中发现，这条命令并不代表万事大吉。airllm 运行时会自动探测可用的推理后端，如果你的框架版本是纯 CPU 版，它可能根本不会启用 GPU，而是退回纯 CPU 推理，速度会慢到让人怀疑人生。所以安装前最好先确认深度学习框架能否正常调用显卡：

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

如果输出 True 和你的显卡型号，说明环境基本可用。如果不是，需要重新安装带有正确加速支持的框架版本。

硬件层面，我的结论是：显存 4GB 可以跑，但建议至少 16GB 系统内存。因为分层推理需要把大量中间结果暂存在内存里，内存不足时系统会疯狂使用交换分区，那种情况下速度不是变慢，而是几乎停滞。硬盘方面，SSD 是刚需，机械硬盘顺序读写吞吐太低，会直接卡死在层交换阶段。

2.2 权重缓存目录：为什么磁盘空间反而比显存更重要

很多人关注显存，却忽略了模型权重文件的落地目录。airllm 跑起来之前，会把权重从模型仓库下载到本地缓存目录。70B 模型即使是 4bit 压缩后的权重，也常常需要几十 GB 的磁盘空间；如果用无压缩模式，半精度权重体积接近 140GB。我第一次部署时，默认缓存目录所在分区只剩 30GB 空间，结果加载到一半直接报错，我还以为是显存问题，排查了半天才发现是磁盘满了。

所以建议显式指定缓存目录，放到剩余空间最大的分区：

export AIRLLM_CACHE_DIR=/path/to/your/large/disk

顺便说一句，如果你有足够内存，airllm 可以把权重一次性加载到内存里，这样省去一部分磁盘重复读取，速度会快不少。内存 16GB 跑无压缩 70B 模型会非常吃紧，但 4bit 压缩后一般没问题。预算足够的话，32GB 内存的体验会好很多。

3. 用代码跑通第一个模型：从加载到生成只需要十几行

安装好之后，我建议先用一个小模型验证流程，而不是直接上 70B。因为 70B 权重下载时间长，如果代码或环境有问题，来回折腾会让人崩溃。先跑通一个 1B 左右的模型，熟悉接口，再切换成大权重。

3.1 一个最小可运行的推理脚本

下面这段代码是 airllm 最典型的用法：

from airllm import AutoModelForCausalLM model = AutoModelForCausalLM.from_pretrained( "your-org/your-1b-model", # 先用小模型 compression="fourbit" # 先把体积压一压 ) input_text = "用一句话解释什么是递归。" inputs = model.tokenizer(input_text, return_tensors="pt") output = model.generate( inputs.input_ids, max_new_tokens=64, do_sample=True, temperature=0.7 ) print(model.tokenizer.decode(output[0], skip_special_tokens=True))

如果你的模型名是本地路径，也可以直接把路径传给 from_pretrained。它能自动判断是走网络下载还是读本地目录，整个过程对使用者几乎透明。

3.2 逐行解释：加载、压缩、生成各自在做什么

from_pretrained 这一行并不像它看起来那么轻量。它会先检查本地缓存有没有完整权重，如果没有，就开始下载；下载完成后，它不会像常规推理框架那样把权重全部放上 GPU，而是建立一个分层索引，记录每一层权重对应的存储位置。compression="fourbit" 的作用是把在线加载的权重做 4bit 压缩，进一步减少需要搬运的数据量。注意，这里的压缩和解压发生在加载过程中，不是提前转换文件格式，所以使用起来非常方便，也不需要额外维护一个转换后的模型副本。

接下来 tokenizer 把输入文本切成 token。generate 是真正耗时的部分：它会在循环里逐层加载、逐层计算、采样下一个 token，然后把新 token 接回输入，再进入下一轮生成。使用 max_new_tokens 限制生成长度很重要，因为模型每生成一个新 token，都要完整地跑一遍所有层。生成 100 个 token 意味着要把几十层网络来回搬运 100 次，限制越长，等待越久。

另外，如果你的业务场景只是做分类或提取 embedding，airllm 也支持只跑前向而不调用 generate。这种情况下，分层推理的优势更明显，因为你只需要一次完整的前向传播，不涉及多次迭代，等待时间会比生成式任务短很多。

4. 实测表现：4GB 显卡上跑 70B 模型的真实体感

说再多原理，都不如直接给一组实测数据。我的测试环境是 4GB 显存显卡、16GB 系统内存、PCIe 3.0 SSD。跑的是 70B 参数模型，分别对比无压缩和 4bit 压缩两种模式。这里的数字只代表个人硬件，不同机器差异会很大，但相对趋势可以参考。

4.1 显存、内存、磁盘的三级协作

先说显存。在 4GB 显存的环境下，airllm 无压缩模式跑 70B 模型，显存占用峰值大约在 3.5GB 左右，留了一点余量给系统的其他显示需求。4bit 压缩模式更低，通常在 2GB 上下。系统内存则是另一个关键指标：无压缩模式因为需要暂存完整权重，16GB 会被吃得很满，我甚至观察到接近 15GB 的占用；4bit 模式就从容很多，大概在 8 到 10GB。磁盘这一层主要承担冷备存储，权重文件越大，首次读取越慢。

实际跑起来后，最明显的感受是风扇狂转。因为 CPU 和 GPU 几乎同时在忙：GPU 负责计算当前层，CPU 负责准备下一层并搬运中间结果。老实说，这种模式下的显卡利用率并不高，计算单元在等数据搬运的情况很常见。airllm 会做预取优化，让下一层权重提前进入到内存的待命区，但受限于总线带宽，依然会有明显停顿。

4.2 生成速度和精度实测记录

我记录了一组粗略数据，统一生成 128 个 token，温度设为 0.7：

需要强调，这是一个量级参考。实际速度还取决于模型的层数、输入长度、CPU 单核性能和磁盘随机读取速度。输入长度对耗时的影响尤其明显，因为每生成一个 token 都要重新计算历史输入的所有层，如果给模型喂了几千字的上下文，生成速度会显著下降。

精度方面，4bit 压缩下的生成结果整体仍能保持语义连贯，但在事实性细节上确实会有偏差。比如问它一个明确的日期，它可能给出接近但不是完全正确的答案。如果对精度要求高，我建议至少用 8bit 压缩或无压缩模式。没有魔法，空间换时间，精度换速度，规则和传统量化类似。

5. 参数调优与踩坑：让模型跑得更快更稳

跑通之后，真正麻烦的问题才开始出现。熟悉 airllm 的接口之后，我花了不少时间在参数调优和问题排查上。下面这几个开关和坑，是我认为对实际使用最有帮助的。

5.1 影响速度的开关有哪些

首先，生成长度 max_new_tokens 是最直接的控制参数。如果只是做摘要提取，128 足够；如果是写长文，512 会等得让人没耐心。我的经验是先把业务需求拆成小任务，单次生成控制在 256 token 以内，体验会舒服很多。

其次，compression 参数很关键。fourbit 能让数据搬运量最小，但会引入额外解压计算；无压缩模式精度最好，但内存和带宽压力大。如果你的显卡显存低于 6GB，我建议无脑选 fourbit；显存在 8GB 以上，可以试试不压缩，配合更大的内存，效果会更稳。

另外，airllm 的配置对象里可以开启自动压缩模式。大致思路是让模型根据当前设备的显存剩余量，自动决定某几层是否压缩。这个功能适合硬件配置不稳定、经常换机器的情况。如果你的机器是固定配置，手动指定 compression 反而更可控。

还有一个容易忽略的细节：关闭输入文本中多余的空格和格式符。模型输入 token 越少，计算量越小。批量处理时，尽可能把输入 padding 到相同的短长度，不要无脑对齐到最大长度。

5.2 三个我差点放弃的坑

第一个坑是模型权重下载断线。70B 权重体积大，从远程仓库拉取时经常中途断掉。airllm 本身支持断点续传逻辑，但如果网络质量差，还是可能反复重试。我的解决方法是先单独下载权重文件放到本地目录，再通过 from_pretrained 传入本地路径，彻底绕开下载环节。

第二个坑是 CPU 内存不足导致的卡死。有一次我在无压缩模式下直接跑 70B，系统内存只有 16GB，运行到一半开始疯狂使用交换分区，整个机器几乎失去响应。后来把 compression 改成 fourbit，并且减小 max_new_tokens，问题才缓解。如果条件允许，把内存升级到 32GB 是最省心的方案。

第三个坑是加速后端不匹配。airllm 在启动时会检测可用的计算设备，如果机器里同时有核显和独显，或者驱动版本太旧，它可能选错设备，或者直接退回 CPU。排查办法是在脚本最开始打印可用设备列表，确保模型真正落在了 GPU 上。

6. 下一步玩法：低配电脑上的私有助手

跑通基础推理之后，airllm 的潜力不止于“能跑”。我目前最常用的场景是把它接成一个小型私有问答助手，后端用向量检索把相关资料捞出来，拼进上下文，再交给 airllm 生成回答。这样既不用把大模型接入任何外部服务，也能在本地资料库上获得可用的问答能力。

6.1 用本地向量库给模型加“外挂”

思路是把文档切块，用一个小型嵌入模型转成向量存到本地向量库。用户提问时，先对问题做向量检索，找出最相关的几段文本，放进 prompt，再交给 airllm。这样做的好处是模型不需要记住全部细节，只需要根据给定资料做归纳和总结，输出质量反而更高，生成的 token 数也能控制住。

因为 airllm 本身的 API 风格和常见推理接口很接近，接入检索流程并不难。核心代码如下示例：

# 伪代码：检索增强生成 docs = vector_db.search(question, top_k=3) prompt = "根据以下资料回答问题：\n\n" + "\n".join(docs) inputs = model.tokenizer(prompt, return_tensors="pt") answer = model.generate( inputs.input_ids, max_new_tokens=256, do_sample=True, temperature=0.3 ) print(model.tokenizer.decode(answer[0], skip_special_tokens=True))

temperature 在问答场景建议调低，减少自由发挥，答案会更可控。这个组合对硬件要求不高，因为向量库和嵌入模型都很小，真正吃资源的部分仍然只有 airllm 所在的推理层。

6.2 还能不能微调？边界在哪里

经常有人问我，airllm 能不能做微调。我的理解是，它主要是为推理场景设计的分层加载方案，反向传播天然需要每一层的梯度，这就要求权重和梯度同时可用，这跟“只用一层就换下一层”的模式存在根本矛盾。所以想拿它做全参数量微调，基本行不通。如果只是做小规模适配，可以考虑只冻结大部分层的参数，只对最后一两层做学习，但这也需要额外的内存管理，一般不建议在低显存设备上尝试。

更好的路径是先用常规工具在服务器上把模型微调好，再导出权重，最后用 airllm 在本地跑推理。这个模式下，airllm 扮演的是“穷人版推理服务器”的角色，它在本地承担了模型运行时的重量，把训练和推理的硬件需求彻底分开。

最后说一点个人体会。如果你追求的是每秒几十 token 的生产力工具，airllm 在低显存机器上确实有点慢。但如果你的需求是在一台不联网、配置不高、甚至只有 4GB 显存的电脑上把 70B 模型跑起来，这个项目提供了一个真实可行的路径。我在实际使用中最喜欢的点是它保留了模型的原始精度选项，不用为了速度把模型改得面目全非。先跑通，再慢慢调，这套思路比一开始就追求极限配置要务实得多。