单卡显存不足如何跑大模型？airllm分层加载推理实战指南

1. 单卡跑大模型这件事，到底卡在哪

先把结论摆在前面：airllm这个项目解决的核心问题，是让显存不够的普通显卡也能推理参数量远超显存容量的大语言模型。它做的事情不是把模型压缩、不是量化到面目全非，而是用一种“分层加载、逐层计算”的思路，把模型权重按层拆开，需要哪一层就把哪一层搬进显存，算完就释放，再换下一层。听起来简单，但真正落地要处理的问题非常多：层与层之间的数据怎么传递、注意力机制的 KV 缓存怎么管理、磁盘 IO 会不会成为瓶颈、精度怎么保持、不同模型架构怎么适配。

我第一次接触这个思路是在一台只有单张消费级显卡的机器上，当时想跑一个 70B 级别的模型，显存只有 24GB，按常规做法根本加载不进去。量化到 4bit 之后勉强能塞进去，但输出质量下降明显，尤其是长文本推理时逻辑开始发散。后来看到 airllm 这类方案，才意识到“显存不够”这件事不一定非要靠压缩模型来解决，换一种加载和计算的组织方式，同样能绕过去。

这篇文章适合几类人看：手里只有一张中低端显卡、想跑大模型但不想牺牲太多精度的开发者；对模型推理底层机制感兴趣、想搞清楚“分层加载”到底怎么实现的技术爱好者；以及正在做本地化部署、需要在有限硬件上跑通推理链路的工程人员。我会从设计思路、核心原理、实操步骤、参数计算、常见问题几个维度把它拆开讲清楚，尽量让不同基础的人都能看懂、能复现。

需要提前说明的是，airllm 这类方案的本质是用时间换空间。它不会让你的显卡突然变强，而是把“显存装不下”这个硬约束，转化成“磁盘读取慢一点、推理时间长一点”这个软约束。理解这一点，后面所有的取舍和优化方向就都顺了。

2. 分层加载的核心设计思路拆解

2.1 为什么是“按层拆”而不是“按参数拆”

大语言模型的结构有一个天然优势：它是高度层叠的。一个典型的 Transformer 模型由几十层甚至上百层相同的块堆叠而成，每一层的计算只依赖上一层的输出，层与层之间是串行关系。这意味着你完全可以把模型看成一条流水线，任何时刻只有一层在参与计算，其余层都在“待命”。

airllm 正是抓住了这个特性。它把模型权重按层切分成独立的文件或分片，推理时只把当前层加载到显存，算完这一层就把显存释放，再加载下一层。这样一来，显存占用从“整个模型的参数量”降到“单层参数量加上中间激活值”，量级上差了几十倍。

为什么不是按参数拆？因为按参数拆会破坏矩阵运算的完整性。一层里的权重矩阵如果被拆散，做矩阵乘法时要么需要频繁跨设备通信，要么需要重新拼接，开销反而更大。按层拆则保持了每层内部运算的完整性，只在层边界做数据搬运，这是最自然的切分点。

2.2 时间换空间的具体代价

分层加载的代价主要体现在两个地方：磁盘 IO 和计算等待。

假设一个 70B 模型，按 FP16 存储大约需要 140GB 的磁盘空间。如果分成 80 层，每层大约 1.75GB。推理一个 token 需要把所有层过一遍，也就是要读取 140GB 的数据。哪怕用高速固态硬盘，顺序读取速度按 3GB/s 算，光读取就要 40 多秒。这还没算计算时间。

所以 airllm 在实际使用中，通常会配合几个优化手段：一是把权重预先转换成适合快速读取的格式，减少解析开销；二是利用操作系统的页缓存，让重复读取的层尽量命中内存；三是支持把部分层常驻显存，减少搬运次数。这些优化后面会详细讲。

注意：分层加载的推理速度和你硬盘的读取速度强相关。机械硬盘基本没法用，普通 SATA 固态也很勉强，NVMe 固态是起步配置。这一点在动手之前必须确认清楚，否则跑起来会慢到怀疑人生。

2.3 和量化方案的本质区别

很多人会把 airllm 和量化混为一谈，其实两者解决的是不同维度的问题。

量化是降低每个参数的存储位宽，比如从 16 位降到 4 位，模型体积直接缩小到四分之一。它的代价是精度损失，而且量化本身需要校准，不同模型、不同任务对量化的敏感度不一样。

分层加载不改变参数的位宽，精度保持原样，它改变的是“同一时刻有多少参数需要待在显存里”。两者完全可以叠加使用：先量化把每层体积变小，再用分层加载把显存占用进一步压低。实际项目中，我见过有人用 4bit 量化加分层加载，在 8GB 显存的卡上跑起了 70B 模型，虽然速度很慢，但确实能跑通。

选择哪种方案，取决于你的优先级：如果追求输出质量，优先分层加载；如果追求速度且能接受精度损失，优先量化；如果显存实在太小，两者一起上。

3. 核心机制与关键细节解析

3.1 权重分片的存储格式

airllm 在第一次加载模型时，会做一次预处理：把原始权重按层拆分，每一层存成独立的文件。这个预处理只做一次，之后每次推理都直接读取分片文件。

分片文件的格式选择很关键。如果直接用 PyTorch 的默认序列化格式，每次读取都要反序列化，开销不小。更高效的做法是用内存映射或者裸二进制格式，让读取操作尽量接近“直接读字节”。实际实现中，常见的选择是 safetensors 格式，它支持零拷贝加载，读取速度快，而且安全性好，不会执行任意代码。

分片的粒度也需要权衡。分得太细，文件数量多，文件系统元数据开销大；分得太粗，单次加载的数据量大，显存峰值高。一般按 Transformer 的层来分是比较自然的，如果单层太大，可以再把单层内的几个大矩阵拆开。

3.2 层间数据传递与 KV 缓存

分层加载时，层与层之间传递的是激活值，也就是这一层的输出张量。这个张量的尺寸取决于批次大小、序列长度和隐藏维度。对于长序列推理，激活值本身也可能很大，需要留意。

更麻烦的是注意力机制里的 KV 缓存。在自回归生成中，每生成一个新 token，都需要用到之前所有 token 的键值对。如果每层算完就把缓存丢掉，那生成下一个 token 时又要重新计算所有历史 token 的 KV，计算量会爆炸。

所以 airllm 必须把 KV 缓存保留在显存或内存中，不能随层释放。KV 缓存的尺寸和层数、注意力头数、序列长度都相关。以 70B 模型为例，80 层、64 个头、头维度 128，序列长度 2048，FP16 存储，KV 缓存大约需要 80 × 2 × 64 × 128 × 2048 × 2 字节，算下来是 5GB 左右。这部分是硬性占用，没法通过分层加载省掉。

实操心得：如果你的显存刚好卡在临界点，优先压缩 KV 缓存而不是压缩权重。比如用分组查询注意力、或者限制最大序列长度，效果往往比折腾权重加载更明显。

3.3 预取与流水线优化

纯串行的分层加载有个明显问题：加载第 N 层的时候，显卡在等数据，计算单元闲置；算第 N 层的时候，磁盘在闲着。两者没有重叠，效率低。

优化的思路是预取：在计算第 N 层的同时，后台线程提前把第 N+1 层读进来。这样计算和 IO 就能重叠起来，整体耗时取决于两者中较慢的那个，而不是两者之和。

再进一步，可以做双缓冲：准备两块显存区域，一块用于当前计算，一块用于预取下一层，算完就交换。这样能把流水线填满，吞吐量提升明显。airllm 的实现里就包含了这类机制，具体开启方式后面实操部分会讲。

预取的深度也可以调。预取一层是最基本的，预取两层或更多可以进一步平滑 IO 波动，但会占用更多显存。这个参数需要根据你的显存余量和硬盘速度来调。

4. 实操过程与关键环节实现

4.1 环境准备与依赖确认

动手之前，先把环境确认清楚。以下是我在实际项目中总结的检查清单：

安装依赖时，核心是 PyTorch 和 airllm 本身。PyTorch 的版本要和 CUDA 版本对应，这个不用多说。airllm 的安装比较直接，用 pip 就能装。但要注意，它依赖的一些加速库可能需要单独编译，如果编译失败，先确认系统里有没有对应的编译工具链。

# 创建独立环境，避免污染主环境 python -m venv airllm_env source airllm_env/bin/activate # 安装 PyTorch，根据你的 CUDA 版本选择对应命令 pip install torch --index-url https://download.pytorch.org/whl/cu121 # 安装 airllm pip install airllm

注意：不要在一个环境里混装多个版本的 PyTorch，也不要在系统 Python 里直接装。我踩过这个坑，依赖冲突排查起来非常费时间。

4.2 模型预处理与分片生成

第一次使用某个模型时，需要先做预处理，把原始权重拆成分片。这一步比较耗时，取决于模型大小和硬盘速度。70B 模型大概需要几十分钟到一小时不等。

预处理的核心逻辑是：读取原始权重文件，按层遍历，把每一层的参数单独保存成文件，同时生成一个索引文件记录层与文件的对应关系。索引文件很重要，推理时靠它来定位每一层的位置。

from airllm import AutoModel # 指定模型路径，首次调用会自动触发预处理 model = AutoModel.from_pretrained("your-model-path") # 预处理完成后，会在模型目录下生成分片文件和索引

预处理过程中有几个细节值得注意。一是要确保磁盘空间充足，预处理会同时存在原始权重和分片文件，空间不够会中途失败。二是预处理完成后，原始权重可以删掉，只保留分片，能省不少空间。三是如果中途中断，最好清空输出目录重新来，避免残留文件导致索引错乱。

4.3 推理参数配置与显存计算

推理时的参数配置直接决定了速度和稳定性。核心参数有这么几个：

• max_seq_len：最大序列长度。这个参数直接影响 KV 缓存大小，进而影响显存占用。设得越大，能处理的上下文越长，但显存压力也越大。
• layer_shards_saving_path：分片文件路径。指向预处理生成的目录。
• prefetch：是否开启预取。开启后速度提升明显，但会多占一点显存。
• compression：是否启用压缩。如果显存实在紧张，可以开启，但会牺牲一些速度。

显存占用的估算公式大致是这样的：

显存占用 ≈ 单层权重大小 + KV缓存 + 激活值 + 预取缓冲

以 70B 模型、FP16、80 层为例，单层权重大约 1.75GB。KV 缓存按前面算的约 5GB。激活值取决于批次和序列长度，一般几百 MB。预取缓冲如果开一层，再加 1.75GB。总计大约 9GB 左右。这意味着 8GB 显存的卡跑起来会很吃力，需要开启压缩或者减小序列长度。

# 推理配置示例 generation_config = { "max_new_tokens": 128, "do_sample": True, "temperature": 0.7, "top_p": 0.9, } # 输入构造 input_text = "请解释一下分层加载的原理" input_ids = tokenizer(input_text, return_tensors="pt").input_ids # 生成 output = model.generate( input_ids, max_new_tokens=128, use_cache=True, )

4.4 速度实测与瓶颈定位

我在一台配置为单张 24GB 显卡、64GB 内存、NVMe 固态的机器上做过实测。跑一个 70B 模型，FP16 精度，序列长度 512，生成 128 个 token，总耗时大约 8 分钟。平均每个 token 接近 4 秒。这个速度对于交互式对话来说很慢，但对于离线批处理任务是可以接受的。

瓶颈定位的方法很简单：用系统监控工具看推理过程中的硬盘读取速度和显卡利用率。如果硬盘读取速度跑满了，显卡利用率很低，说明瓶颈在 IO；如果显卡利用率高，硬盘没跑满，说明瓶颈在计算。大多数情况下，分层加载的瓶颈都在 IO。

优化 IO 的手段有几个：换更快的硬盘、开启预取、增加页缓存命中率、减少分片文件数量。其中页缓存命中率的提升最容易被忽视。如果系统内存足够大，把整个模型的分片都缓存到内存里，第二次推理时就不用读硬盘了，速度会有质的飞跃。

5. 常见问题与排查技巧实录

5.1 加载失败与显存溢出

最常见的问题是加载到一半报显存不足。这种情况通常不是单层太大，而是 KV 缓存或者预取缓冲把显存吃掉了。

排查思路：先把 max_seq_len 调到最小，关闭预取，看能不能跑通。如果能跑通，再逐步往上加参数，找到临界点。如果最小配置都跑不通，说明单层权重本身就超过了显存，这时候只能上量化或者换更小的模型。

还有一个隐蔽的坑是显存碎片。长时间运行后，显存里会有很多不连续的小块，虽然总量够，但分配不出连续的大块。解决办法是定期重启进程，或者用支持显存池化的框架。

5.2 推理速度异常缓慢

速度慢的原因很多，按可能性排序：硬盘太慢、预取没开、页缓存没命中、序列太长、批次太大。

我遇到过一次速度突然变慢的情况，排查后发现是硬盘快满了，剩余空间不足导致写入临时文件时频繁等待。清理空间后恢复正常。所以硬盘剩余空间最好保持在 20% 以上。

另一个常见原因是第一次推理特别慢，后面就快了。这是正常的，因为第一次要把分片读一遍，后面有页缓存。如果你发现每次都一样慢，说明内存不够，页缓存存不下，需要加内存。

5.3 输出质量与精度问题

分层加载本身不损失精度，但如果你同时开了量化或者压缩，质量就可能下降。判断方法很简单：用同一组输入，分别跑分层加载和常规加载，对比输出。如果差异明显，说明是量化或压缩的问题，不是分层加载的问题。

还有一种情况是输出重复或者乱码。这通常是 KV 缓存管理出了问题，比如缓存被意外清空，或者序列位置编码错乱。检查 use_cache 参数是否正确设置，以及序列长度是否超过了模型的最大位置编码范围。

5.4 常见问题速查表

实操心得：遇到问题先做减法，把所有优化参数关掉，用最小配置跑通，再逐个开启优化。这样能快速定位是哪个参数导致的。我见过太多人一上来就开满优化，结果出问题后完全不知道从哪查起。

6. 适用场景与选型建议

6.1 什么场景适合用分层加载

分层加载最适合的场景是离线批处理。比如你要用大模型批量处理一批文档，对速度不敏感，但对输出质量要求高，不想用量化。这种情况下，分层加载几乎是唯一的选择。

另一个适合的场景是研究和实验。你想对比不同模型在某个任务上的表现，但手头只有一张卡，不可能同时装下多个模型。分层加载让你可以按需加载，跑完一个换一个，硬盘上存着就行。

不太适合的场景是实时交互。如果你要做对话应用，用户等几秒都嫌久，分层加载的速度很难满足要求。这种情况下，要么用量化把模型塞进显存，要么用更小的模型，要么上多卡。

6.2 和其他方案的对比

选型的核心是明确你的约束条件：显存有多少、能接受多慢、精度要求多高。三个条件里通常只能满足两个，想清楚哪个可以妥协，方案自然就出来了。

6.3 后续优化方向

如果分层加载的速度还是不能满足需求，有几个方向可以继续优化。

一是混合策略：把频繁使用的层常驻显存，不常用的层走分层加载。比如前几层和后几层常驻，中间层动态加载。这样能减少一部分搬运。

二是模型架构适配：有些新模型架构对分层加载更友好，比如层数更多但每层更小的设计。选模型时可以把这一点纳入考虑。

三是硬件升级：加内存让页缓存命中率更高，换更快的硬盘减少 IO 等待。这两项升级的性价比通常比换显卡高。

四是推理框架优化：不同的推理框架对分层加载的支持程度不一样，有的做了更激进的预取和流水线优化。多试几个框架，找到最适合你硬件组合的那个。

我在实际项目中的体会是，分层加载不是一个“银弹”，它是一个在特定约束下的务实选择。它的价值在于让原本跑不起来的模型跑起来了，代价是速度。如果你的场景能接受这个代价，它就是最优解；如果不能，那就得从别的维度想办法。技术选型从来都是权衡，没有绝对的好坏，只有合不合适。