1. 当大模型装不进显卡时，我在想什么

第一次看到 airllm 这个项目名的时候，我正对着自己那台只有 8GB 显存的机器发愁。想跑一个 70B 参数级别的大语言模型做推理测试，结果模型权重文件动辄上百 GB，光是加载就把显存撑爆了。那段时间我试过量化、试过模型切分、试过各种推理框架，但要么精度掉得厉害，要么配置复杂到让人想放弃。airllm 这个标题吸引我的地方在于，它暗示了一种"让模型在有限硬件上跑起来"的思路——不是靠堆硬件，而是靠调度策略。

airllm 本质上解决的是一个非常现实的问题：大模型推理时的显存瓶颈。传统做法是把整个模型加载到显存里，参数量一大就必然爆显存。airllm 的核心思路是分层加载、按需调度——把模型按层拆开，推理时只把当前计算需要的层放进显存，算完就换出去。这听起来简单，但里面涉及的内存管理、IO 调度、计算重叠等细节，才是真正决定它能不能跑得快、跑得稳的关键。

这篇文章适合几类人看：手里只有消费级显卡但想跑大模型的开发者、对推理优化感兴趣但不知道从哪下手的学生、以及被显存问题折磨过想找替代方案的工程师。我会从 airllm 的核心机制讲起，拆解它为什么能省显存、省到什么程度、代价是什么，然后给出完整的实操步骤和我在测试中踩过的坑。全文基于我对这类分层推理方案的通用理解来展开，具体参数和代码以实际项目为准。

2. airllm 的分层加载机制到底在做什么

2.1 从"全量加载"到"逐层流转"的转变

要理解 airllm 的价值，得先明白传统推理为什么吃显存。一个 Transformer 架构的大模型，每一层都包含注意力权重、前馈网络权重、LayerNorm 参数等。假设一个 70B 参数的模型用 FP16 存储，光权重就占 140GB 左右。推理时如果要把整个模型放进显存，至少需要 140GB 以上的显存容量，这还没算激活值、KV Cache 和中间计算结果。消费级显卡普遍在 8GB 到 24GB 之间，差距是数量级的。

airllm 的做法是把模型按层切开，每一层单独存成一个文件或一个内存块。推理的时候，它只把当前正在计算的那一层加载到显存里，算完之后把这一层的显存释放掉，再加载下一层。这样一来，显存里同时存在的只有一层或少数几层的权重，显存占用从"模型总大小"降到了"单层大小乘以一个很小的系数"。对于 70B 模型来说，单层可能只有几百 MB 到 1GB 左右，8GB 显存完全够用。

这个思路和操作系统的虚拟内存有点像：物理内存不够的时候，把不常用的数据换出到磁盘，需要的时候再换进来。区别在于 airllm 是在推理过程中主动做这个调度，而且调度的粒度是模型层。

2.2 分层调度的三个关键决策

分层加载说起来容易，但实际做的时候有三个关键决策点，每一个都直接影响推理速度和稳定性。

第一个决策是层的划分粒度。是按 Transformer 的每一层来切，还是把几层合并成一个块？切得太细，IO 次数多，每次加载的数据量小，调度开销占比高；切得太粗，单次加载的数据量大，显存峰值高，可能又装不下。airllm 默认按单层切分，这是一个比较平衡的选择。我在测试中发现，如果显存特别紧张，可以尝试把层再拆细一点，比如把注意力部分和前馈部分分开加载，但这样会增加调度复杂度。

第二个决策是加载时机。是在需要计算某一层之前才加载，还是提前预加载下一层？前者显存占用最低，但计算和 IO 完全串行，速度慢；后者可以在计算当前层的同时异步加载下一层，实现计算和 IO 的重叠，速度更快，但显存里需要同时容纳两层。airllm 支持预加载策略，具体预加载几层可以通过参数控制。我的经验是，如果显存有富余，预加载 1 到 2 层能明显提升吞吐；如果显存卡得很死，就老老实实串行加载。

第三个决策是权重的存储格式。是存 FP16 还是 INT8 还是 INT4？存储精度直接影响文件大小和加载速度。FP16 精度最好但文件最大，INT4 文件最小但精度损失明显。airllm 本身不强制量化，但可以和量化方案结合使用。我一般建议先用 FP16 跑通流程，确认没问题之后再尝试量化版本，这样出问题的时候容易定位是调度问题还是量化问题。

2.3 显存节省的量化估算

为了让你对 airllm 的显存节省效果有个直观感受，我列一个简单的估算表。假设模型是 70B 参数，FP16 存储，总权重大约 140GB，共 80 层，每层平均 1.75GB。

这个表是粗略估算，实际显存占用还受 batch size、序列长度、KV Cache 策略等因素影响。但核心结论是清楚的：分层加载把显存需求从"模型总大小"降到了"单层大小"这个量级，这是它最大的价值。

注意：显存够用不代表速度快。分层加载的代价是大量的磁盘 IO 或内存拷贝，推理速度会比全量加载慢很多。airllm 适合的是"显存不够但想跑起来"的场景，不是"追求极致吞吐"的场景。

3. 把 airllm 跑起来：从环境准备到第一次推理

3.1 环境准备中最容易忽略的细节

airllm 的安装本身不复杂，但环境准备有几个细节如果没注意，后面会浪费很多时间。

首先是Python 版本和 PyTorch 版本的匹配。airllm 依赖 PyTorch 做底层计算，PyTorch 版本和 CUDA 版本、显卡驱动版本之间有一层套一层的兼容关系。我的建议是先用nvidia-smi确认驱动支持的 CUDA 最高版本，然后去 PyTorch 官网查对应的安装命令，不要凭记忆写。我见过太多人因为 CUDA 版本不匹配，报了一堆看不懂的错，最后发现只是装错了 PyTorch 版本。

其次是磁盘空间和磁盘类型。分层加载意味着模型权重需要存在磁盘上，推理时反复读取。70B 模型 FP16 大约 140GB，加上临时文件和系统占用，建议预留 200GB 以上空间。更重要的是磁盘类型：NVMe SSD 和机械硬盘的加载速度差距可能是几十倍。我用机械硬盘测试的时候，每层加载要等好几秒，整个推理过程慢到无法接受；换成 NVMe SSD 之后，每层加载降到几百毫秒，体验完全不一样。

第三是内存容量。airllm 在加载层的时候，可能会先把数据读到内存再传到显存。如果内存太小，系统会频繁使用交换分区，速度会急剧下降。建议内存至少是单层大小的几倍，比如 16GB 起步，32GB 更稳妥。

3.2 模型权重的准备与格式转换

airllm 需要把模型权重按层拆分成单独的文件。如果你从模型仓库下载的是完整的权重文件，可能需要先做一次转换。转换的过程本质上是读取原始权重，按层切分，然后分别保存。

这里有个经验：转换过程本身很吃磁盘 IO 和内存，建议在磁盘空间充足、没有其他重负载任务的时候做。转换完成后，检查一下生成的文件数量和模型层数是否一致，文件大小是否合理。我曾经因为转换中途磁盘满了，生成了几个不完整的层文件，推理的时候报错信息很不直观，排查了很久才发现是文件损坏。

另外，如果你打算用量化版本，转换的时候就要确定量化精度。不同量化方案对层权重的处理方式可能不同，中途换量化精度可能需要重新转换。

3.3 第一次推理：参数怎么设

第一次跑 airllm 的时候，建议用最小的配置：batch size 设为 1，序列长度设短一点，预加载层数设为 0 或 1。目的是先确认流程能跑通，而不是追求速度。

关键参数我列一下：

• 预加载层数：控制提前加载几层。设为 0 就是完全串行，显存占用最低；设为 1 或 2 可以提升速度，但显存占用增加。
• 设备：指定用哪块显卡。多卡机器上要确认选的是显存够用的那块。
• 数据类型：FP16 还是量化类型。第一次跑建议用 FP16，排除量化引入的问题。
• 最大序列长度：影响 KV Cache 大小和激活值大小。第一次跑设小一点，比如 512。

跑通之后，你可以逐步增加序列长度和预加载层数，观察显存占用和推理速度的变化，找到适合自己硬件的平衡点。

3.4 一个最小可运行示例的结构说明

由于 airllm 的具体 API 可能随版本变化，我不贴具体代码，而是说明一个最小示例的结构。通常你需要做这几件事：

1. 导入 airllm 的推理类或函数。
2. 指定模型权重的路径，也就是你转换好的分层权重目录。
3. 配置推理参数，包括设备、数据类型、预加载层数等。
4. 准备输入文本，做 tokenize。
5. 调用推理接口，拿到输出。
6. 把输出 token 解码成文本。

这个流程和普通推理框架差不多，区别在于 airllm 在背后做了分层调度。你不需要手动管理层的加载和释放，但需要理解这些参数的含义，才能调出合适的配置。

4. 速度与显存的博弈：实测中的取舍经验

4.1 为什么分层加载会慢，慢在哪里

分层加载的推理速度瓶颈主要在IO。每次计算一层，都要把这一层的权重从磁盘读到内存，再从内存传到显存。如果磁盘读取速度是 3GB/s，单层大小是 1.75GB，那么读一层就要大约 0.6 秒。80 层就是 48 秒，这还只是 IO 时间，没算计算时间。相比之下，全量加载的模型所有层都在显存里，计算一层可能只要几十毫秒。

所以 airllm 的定位很明确：用时间换空间。它让你在显存不够的机器上能跑大模型，但代价是推理速度大幅下降。如果你的场景对延迟敏感，比如实时对话，airllm 可能不是最佳选择；如果你的场景是离线批处理、实验验证、或者只是想把模型跑起来看看效果，airllm 就很有价值。

4.2 预加载层数怎么选：一个实测对比

预加载层数是影响速度的关键参数。我做过一组对比测试，模型是 13B 参数，FP16，单层约 0.3GB，磁盘是 NVMe SSD，显卡是 8GB 显存。测试结果大致如下：

从这组数据能看出两个规律：预加载 1 到 2 层收益最大，再往上加，速度提升有限但显存占用线性增长。所以我的建议是，先看显存余量，如果显存能承受，设 2 层预加载是比较划算的；如果显存紧张，设 1 层或者 0 层。

4.3 磁盘类型对速度的影响被严重低估

很多人讨论 airllm 的时候只关注显存和显卡，忽略了磁盘。但实测下来，磁盘类型对 airllm 推理速度的影响可能比显卡还大。

我用同一台机器、同一块显卡，分别用 NVMe SSD 和 SATA SSD 跑同一个模型。NVMe 的顺序读取速度大约是 SATA 的 5 到 6 倍，结果推理速度差了将近 4 倍。如果用机械硬盘，差距会更大。原因很简单：airllm 的瓶颈在 IO，磁盘越快，IO 等待时间越短，整体速度就越快。

所以如果你打算认真用 airllm，优先把钱花在 NVMe SSD 上，而不是升级显卡。一块大容量 NVMe SSD 带来的速度提升，可能比换一块更高端的显卡更明显。

4.4 量化：省显存也省 IO，但精度要盯住

量化对 airllm 来说是一举两得：既减少显存占用，又减少 IO 数据量。INT8 量化能把权重文件缩小一半，INT4 能缩小到四分之一。文件小了，加载就快，显存占用也低。

但量化的代价是精度损失。INT8 通常精度损失较小，很多场景下可以接受；INT4 精度损失就比较明显了，尤其是对生成质量要求高的任务。我的建议是：先跑 FP16 确认效果，再试 INT8 看精度是否可接受，INT4 只在极端显存受限的情况下考虑。而且量化之后要重新评估输出质量，不能只看能不能跑。

5. 踩过的坑与排查思路

5.1 显存明明够却报 OOM

这是我最开始遇到的一个反直觉问题：明明算下来单层只有 1GB 多，8GB 显存应该够，但就是报显存不足。排查之后发现几个原因。

第一个原因是激活值和 KV Cache 占用了额外显存。分层加载省的是权重显存，但推理过程中的激活值和 KV Cache 还是实打实占显存的。序列长度越长、batch size 越大，这部分占用越多。解决办法是减小序列长度或 batch size。

第二个原因是显存碎片。反复加载和释放不同大小的层，可能导致显存碎片化，虽然总空闲显存够，但没有一块连续的空间能放下当前层。解决办法是尽量让各层大小均匀，或者定期清理显存缓存。

第三个原因是预加载层数设多了。预加载 2 层意味着显存里同时有 2 层权重，加上激活值，可能就超了。把预加载层数降到 1 或 0 试试。

5.2 推理结果乱码或重复

分层加载本身不应该影响计算结果，因为每一层的权重还是原来的权重，只是加载时机不同。但如果出现输出乱码、重复、不连贯，可能是这几个原因。

权重文件损坏或不完整。转换过程中如果中断，可能生成不完整的层文件。检查文件大小是否一致，重新转换一次。

层顺序错乱。如果加载的时候层顺序搞错了，计算结果肯定不对。检查配置文件或代码里的层顺序是否和原始模型一致。

量化精度问题。如果用了量化，可能是量化方案和模型不匹配，或者量化参数设错了。换回 FP16 测试，如果正常，就是量化的问题。

5.3 速度慢到无法接受

速度慢是 airllm 的固有代价，但如果慢到完全不能用，可以按这个顺序排查：

1. 确认磁盘类型：是不是机械硬盘？换成 NVMe SSD 试试。
2. 确认预加载设置：预加载层数是不是 0？试着加到 1 或 2。
3. 确认是否有其他 IO 竞争：后台是不是有下载、拷贝等任务在抢磁盘带宽？
4. 确认内存是否够：内存不足会导致交换，速度急剧下降。
5. 确认显卡是否被其他任务占用：多任务共享显卡会拖慢推理。

5.4 多卡环境下的设备选择

如果你有多块显卡，airllm 默认可能不会选你期望的那块。要显式指定设备。另外，多卡环境下如果其他卡在跑任务，可能会影响磁盘和内存带宽，间接影响 airllm 的速度。我的经验是，跑 airllm 的时候尽量让机器专注，不要同时跑其他重负载任务。

6. 这套方案适合谁，不适合谁

6.1 适合的场景

airllm 最适合的是显存受限但想跑大模型的场景。比如：

• 个人开发者只有一张消费级显卡，想体验大模型推理。
• 实验室或小团队想验证某个大模型的效果，但暂时没有高端显卡。
• 教学场景下，让学生理解大模型推理的显存管理和调度机制。
• 离线批处理任务，对延迟不敏感，但对显存有硬性限制。

这些场景的共同点是：能跑起来比跑得快更重要。airllm 用速度换空间，正好匹配这类需求。

6.2 不适合的场景

反过来，如果你的场景对推理速度有要求，airllm 就不合适。比如：

• 实时对话系统，用户等几秒就会不耐烦。
• 高并发服务，需要同时处理多个请求。
• 对生成质量要求极高的任务，量化带来的精度损失不可接受。

这些场景下，要么升级硬件，要么用其他优化方案，比如模型并行、张量并行等。airllm 不是万能的，它只是工具箱里的一把螺丝刀，适合拧特定的螺丝。

6.3 和其他显存优化方案的对比

为了让你更清楚 airllm 的定位，我把它和几种常见的显存优化方案做个对比。

从表里能看出，airllm 的显存节省幅度最大，但速度影响也最大。实际选择的时候，可以组合使用，比如 airllm 加量化，进一步降低显存需求。

7. 我对这类分层推理方案的一些个人体会

折腾 airllm 这段时间，我最大的感受是：显存优化没有银弹，只有取舍。每一种方案都是在显存、速度、精度、成本之间做权衡。airllm 选择了极致的显存节省，代价是速度；量化选择了精度换显存和速度；模型并行选择了成本换显存和速度。没有哪种方案全面占优，关键看你的约束条件是什么。

另一个体会是，IO 优化的重要性被严重低估。很多人一提到大模型推理就只想到显卡，但实际上在分层加载场景下，磁盘速度、内存带宽、PCIe 带宽都可能成为瓶颈。我在升级 NVMe SSD 之后，同样的显卡、同样的模型，推理速度提升了好几倍。所以如果你打算用 airllm，先把存储和内存搞好，可能比换显卡更有效。

最后分享一个小技巧：先用小模型验证流程，再用大模型跑正式任务。airllm 的配置参数不少，直接用大模型调试，每次加载都要等很久，效率很低。先用一个几 B 参数的小模型把流程跑通，确认参数配置正确，再换成大模型，能省很多时间。而且小模型上遇到的问题，大模型上大概率也会遇到，提前解决掉，后面就顺了。

这个方向后续还可以继续挖，比如把 airllm 和推理服务框架结合，做请求级别的调度；或者针对特定模型结构做更细粒度的层切分。但那是另一个话题了，先把基础流程跑稳，再考虑进阶优化。