低显存怎么跑大模型？AirLLM分层推理原理与实操指南

上周我用一台只有 4GB 显存的旧机器，把一个 7B 参数规模的开源语言模型跑了起来。一开始队友说这不现实，因为单算模型权重，7B 半精度就要占大概 14GB 显存。但实际跑通之后，我发现这件事确实有路可走，而这条路就是我想聊的 AirLLM。

AirLLM 不是一个压缩模型的工具，也不是一个需要重新训练的蒸馏框架。它改变的是推理时的资源分配方式。传统推理要先把整个模型放进显存，AirLLM 则让自己把模型按层拆分，一层层加载、计算、释放。这套思路让低显存设备跑大模型变成了现实，代价是推理速度慢一点，但至少能跑。

如果你也手头只有一张老显卡，或者想在本地设备上做隐私推理，这篇文章应该能帮到你。我会从核心原理、实际部署、调优和踩坑几个角度，把 AirLLM 这个项目讲透。

1. 为什么模型“塞不进去”：显存、权重和理解开销

1.1 模型的体积到底是怎么算出来的

一个语言模型并不只是“一堆参数”那么简单。假设一个模型有 7B（70亿）个参数，每个参数用 2 字节（半精度浮点数）保存，那模型权重的体积大约是：

7B × 2 = 14GB

这 14GB 还只是“权重”。推理过程中还有激活值、KV Cache（键值缓存）、临时计算结果。它们都要占显存。所以如果你只有 4GB 显存，常规思路确实装不下 7B 模型。

很多人的第一反应是量化。把权重从 2 字节压缩到 1 字节甚至 0.5 字节，模型占用可以降一半以上。但量化有代价，比如精度损失、需要校准数据，有些低比特量化还会让模型输出质量打折扣。虽然现在已经有很多不错的量化方案，但对一些严肃应用场景来说，能不做量化还是尽量不做。

AirLLM 的切入点不是在“数字精度”上省，而是在“驻留位置”上省。它不改变权重的数值，只改变权重在推理过程中的存放位置。

1.2 显存和内存之间的“水位差”

现代消费级设备通常有几个内存层级：寄存器、显存（VRAM）、系统内存（RAM）、硬盘。显存快，但容量小；RAM 容量大，但速度稍慢；硬盘容量最大，速度更慢。

通常推理框架认为“显存必须足够装下整个模型”，这是个很奢侈的前提。AirLLM 则把问题重新定义：如果显存不够装整个模型，那就让显存只装“当前正在计算的那一小块”。其它暂时不用的块，放在 RAM 里。等需要的时候再搬运到显存里。

这就是关键思路：用通信带宽换显存容量。它没有魔改模型结构，也从源头绕开了显存不够的问题。

1.3 为什么不是所有层都常驻显存

很多刚开始接触的人会问：既然每层都要算，为什么不把常用层常驻？这个问题的答案很直接：因为放不下。

一个 transformer 模型的结构通常是：嵌入层（embedding）、几十个 transformer 层、最后的输出层。每一层里包含自注意力、前馈网络、归一化层等子模块。整个模型一起加载是最快的，但在低显存设备上根本没有这个资格。

AirLLM 会把模型切分成若干个“层块”。如果显存只能容纳一个块，那就一次只加载一个块。算完这一块，把结果传到 RAM，再把下一个块加载进来。比如一个 30 层的模型，你可以切分成 30 个小块，也可以每两层合并成一个大块。合并的好处是减少搬运次数，坏处是所需显存更大。这个参数后面实操部分还会具体讲。

2. AirLLM 核心原理：分层加载的推理路径

2.1 推理过程怎么变成“边搬边算”

语言模型生成一个 token 的过程，简单说就是：输入一段文本，模型按层依次处理，最后一层输出一个概率分布，从里面挑一个 token，再把这个 token 拼回输入，继续下一轮。

每一层推理都需要两部分数据：输入激活值（上一层的输出）和当前层的权重。AirLLM 的做法是，在每一轮生成开始时，先从 RAM 把当前层的权重搬运到显存，然后计算，算完立即把权重释放掉，再把结果传出去。

流程可以简化为：

1. 输入 token 序列进入嵌入层
2. 从 RAM 加载第 1 层权重到显存
3. 计算第 1 层的输出
4. 释放第 1 层权重，保留输出激活值
5. 从 RAM 加载第 2 层权重到显存
6. 计算第 2 层，继续往下
7. 最后一层输出概率，采样得到新 token

整个过程里，显存里永远只有“一层或一个层块”的权重，而不是整个模型。这样就算显存只有 4GB，也能跑权重 14GB 的模型。

2.2 为什么这听起来简单，实现起来却不简单

你可能觉得这无非就是循环加载权重，没什么大不了。但真的做起来，有几个难点。

第一，管理搬运时机。权重从 RAM 搬到显存不是瞬时完成的，需要时间。在 GPU 计算过程中，如果下一层还没有搬完，计算单元就会空转。AirLLM 需要比较精细的调度，尽可能把搬运和计算重叠起来。

第二，激活值存放。每一层的输出不能丢。如果这些激活值全放在显存里，可能又会把显存撑爆。所以 AirLLM 也要管理激活值，多少留在显存、多少传到 RAM，都需要按当前任务动态调整。

第三，层块的切分。不是所有层都一样大，嵌入层和输出层体积不一定相同。如果切分不合适，有的块特别大，显存还是不够；有的块特别小，搬运次数多，速度更慢。所以实际的层切分策略很关键。

AirLLM 处理这些问题的思路，我认为比较务实：先解决“能不能跑”，再解决“跑得快不快”。所以它默认的配置不会追求极限速度，而是追求稳定和通用。

2.3 它跟量化、蒸馏是什么关系

这里要澄清一个容易混淆的点。AirLLM 不是替代量化，也不是替代蒸馏。它跟这些技术是正交的。

量化是把权重的位宽降低，让同样一份显存能塞下更多权重；蒸馏是把大模型学到的能力搬到一个小模型里，减少参数量。AirLLM 不做这些事，它保留原始权重，只是让权重在推理时“流动”起来。

正因为这样，它很适合跟量化结合。先量化，再分层加载，可以进一步降低显存压力。比如一个 7B 模型量化到 4bit 后权重只有约 4GB，再加上分层加载，甚至可能在一张 2GB 显存的设备上跑。这个组合我后续会专门提一下。

3. 实操：如何在 4GB 显存设备上跑起一个 7B 模型

3.1 准备环境

AirLLM 是个推理项目，实际部署前先保证基础环境没问题。

你需要准备：

• 一台至少 16GB 物理内存的设备，我推荐 32GB。因为模型权重在 RAM 里，RAM 不够会直接卡死。
• 一块支持基本矩阵运算的显卡，显存 4GB 左右即可，2GB 也可以试。
• Python 环境和常见的深度学习依赖。
• 模型权重文件，最好是已经整理好的无加密的 checkpoint，否则需要先转换格式。

创建虚拟环境：

python -m venv airllm_env source airllm_env/bin/activate pip install airllm

这一步装的是核心推理依赖。如果你的网络环境特殊，可能需要设置镜像源，但这不是 AirLLM 特有的问题。

3.2 写一个最小推理脚本

AirLLM 的 API 设计比较接近普通推理库。下面是一个简化的最小脚本，我用通用代码来说明实际使用时的核心调用方式。不同版本 API 可能有差异，以你安装的版本文档为准。

import torch from airllm import AirLLM # 模型路径：指向你本地存放权重的目录 model_path = "/data/models/7b-chat" # 加载模型 model = AirLLM.from_pretrained( model_path, device="cuda:0", max_seq_len=512, compression=2, ) # 假设你已经有分词器，得到输入 id input_ids = torch.tensor([[101, 2023, 2444]]).to("cuda:0") # 生成 output_ids = model.generate( input_ids, max_new_tokens=200, temperature=0.7, top_p=0.9, ) # output_ids 就是生成结果

这里要强调几个参数的含义。

compression是个很关键的参数。它表示把多少层合并成一个块。compression=2表示每两层作为一个整体加载，加载次数减半，但是单次需要的显存变大。显存越小，compression 应该设得越小；如果显存稍微宽裕，可以适当提高 compression 来提速。

max_seq_len是上下文长度。低显存场景建议别开太长。512 已经是我能接受的默认值，再大会让 KV Cache 变大，反而容易在生成时突然爆显存。

temperature和top_p是常见的采样参数，跟 AirLLM 本身关系不大，但会影响生成效果。

3.3 验证部署是否成功

脚本跑起来后，如果没报显存不足，就说明分层加载生效了。常见的验证方式是：

• 用一段固定 prompt 生成多个结果
• 观察显存占用是否稳定在一个低水位
• 观察日志中加载层的信息

我记得第一次跑的时候，显存占用一直稳定在 3GB 左右，但 GPU 利用率并不高。因为大部分时间花在搬运权重上了。这个现象是正常的，不是 bug。

如果你也遇到 GPU 利用率低、内存带宽占用高，说明 AirLLM 正在按计划工作。

4. 参数调优与性能表现：不是跑通就算完

4.1 性能瓶颈在哪里

AirLLM 的推理速度不可能跟全显存加载相比，因为它把“读取权重”从显存内部访问变成了“跨总线搬运”。每次搬运权重都要经过 PCIe，这个带宽比显存带宽低一个数量级。

举个例子：一张 4GB 显存的显卡，内部带宽可以到 200GB/s 以上，而 PCIe 传输带宽可能只有 10GB/s 左右。所以每搬运一层权重，就要多花好几倍的时间。随着模型层数变多，搬运次数增加，速度自然就慢下来。

所以，如果要在 AirLLM 下追求可用速度，目标并不是把 GPU 跑满，而是尽量减少搬运次数、减少激活值体积。

4.2 调优的正确姿势

第一个建议是尽量调大compression，但不要大到显存放不下。比如显存 4GB，跑 7B 模型，compression=2是一个比较平衡的点；如果显存 6GB，可以尝试compression=4。

第二个建议是控制上下文长度。这个项目对长文本非常不友好。上下文越长，KV Cache 越大，激活值也大，可能导致显存在某个瞬间溢出。我实际测试时，从 512 降到 256，生成稳定性提升非常明显，速度也更快。

第三个建议是优先保证 CPU 内存充裕。AirLLM 把大量权重放在 RAM 里，如果你的 RAM 不够，操作系统会把部分数据交换到硬盘，那性能会断崖式下降。这比任何调参都致命。

第四个建议是御载不需要的显存缓存。如果同一台机器上跑多个进程，显存碎片会让 AirLLM 误判可用空间。可以先清掉后台进程再跑。

4.3 性能表现的横向对照

我用一台老设备做过简单对照。同样一个 7B 模型，全部加载到 24GB 显存时，生成速度大概是每秒几十个 token；而用 AirLLM 在 4GB 显存上跑，速度大约是每秒 1 到 3 个 token。速度差异很大，但对一些离线生成任务来说，这个速度并不是不能接受。

我把不同配置的感受整理成下面这张表，仅供参考：

这个表的结论是：显存和速度永远是跷跷板。你要明确自己的目标。如果只是想验证模型能不能跑、输出对不对，就选最稳妥的配置。如果想放到生产环境，建议加预算上大显存，或者搭配其它加速方案。

4.4 跟量化组合的实战思路

如果你想让 AirLLM 跑更大的模型，或者让显存压力更低，可以考虑先量化再分层。比如把权重从半精度转成 4bit，模型体积直接减半。这样原来只能跑 7B 的设备，可能变成能跑 13B 模型。

不过要提醒一句：量化后模型输出会和原始权重有细微差别。如果你只是测试效果，问题不大；如果做严谨的质量评估，建议先跑原始权重作为 baseline，再做量化对比。

5. 踩坑记录：那些文档里不会写、只能试出来的问题

5.1 明明显存够，但偶尔还是爆显存

AirLLM 的分层加载只能保证权重放进显存的时间很短，但推理过程中会出现瞬时峰值。尤其是生成长文本时，KV Cache 会随生成长度线性增长。如果一开始上下文设得太大，到后半程就可能突然报显存不足。

我的建议是最开始用max_seq_len=128做测试，跑通后再慢慢调大。不要一上来就追求 2048，那在低显存设备上大概率会失败。

5.2 速度慢到像“挂起”

有几次我以为程序卡死了，其实是速度太慢。尤其是在compression=1且模型很大的时候，光搬运权重的时间就够你喝几口水。

排查方法很简单：看任务管理器或者资源监视器中的内存占用和网络/总线带宽。如果你看到 CPU 内存持续高占用，并且 GPU 利用率只有个位数，说明它正在搬运权重，不是卡死。

如果你必须做交互式任务，建议把 prompt 长度压缩到最小，生成长度也控制住，否则体验会很煎熬。

5.3 模型加载阶段非常长

AirLLM 第一次加载模型时，往往需要把权重文件读入内存。如果权重文件在机械硬盘上，这一步会特别慢。我建议把模型放在 SSD 上，或者至少在跑推理前手动把文件读入系统缓存。

如果你有足够 RAM，可以先把权重文件拷贝到/dev/shm这类虚拟内存盘上，加载速度会快不少。但要注意 RAM 占用，别把系统内存吃满。

5.4 生成质量不如原始模型

这个现象通常不是 AirLLM 的 bug，而是因为上下文被截断，或者采样参数设置不合适。分层加载本身不改变权重数值，所以理论输出应该跟原始模型一致。实际会有微小差异，主要来自浮点数运算顺序不同，但差别很小。

如果你发现输出明显变差，大概率是 KV Cache 或激活值在搬运过程中被截断。这时检查精度设置，尽量保持和基线一致。

我把常见问题整理成一个速查表：

6. 我如何看 AirLLM 这一类方案

6.1 分层推理对边缘设备的意义

消费级设备和边缘设备的内存容量有限，AirLLM 这类方案把“能不能运行大模型”的边界往前推了一大步。它不需要特别高端的硬件，也不需要牺牲模型精度，就能让本地推理成为可能。

这在私密性要求高的场景里非常重要。我们很多开发者习惯把数据传到远程接口去处理，但有些数据是不想离开本机的。有了 AirLLM，即使设备显存很小，也能在本地完成推理，虽然慢，但放心。

6.2 未来可能的演进方向

我觉得分层推理这个思路可以继续演进。比如自动切分策略：根据当前显存和内存状态动态决定每个层块的大小，而不是靠用户手调 compression。再比如与更细粒度的稀疏计算结合：某些层只需要少量权重参与计算，那就可以做到更小的搬运量。

AirLLM 现在更多是面向“能不能跑”的工程验证，但它打开了一个想象力：模型不是非要装进显存才能用，它可以像流水线一样在内存层级间流动。这个方向对低成本 AI 推理很有意义。

最后分享一个实际经验：如果要第一次试 AirLLM，别急着开各种优化。先用默认配置把一个 7B 小模型跑通，理解每一步的搬运逻辑，再慢慢加压力、调参数。踩过几次坑之后，你会对显存、内存、带宽之间的关系有非常直观的认识，这种认识是看再多文档也换不来的。