1. 单卡跑大模型这件事，到底卡在哪
第一次看到 airllm 这个项目的时候，我正在一台只有单张消费级显卡的机器上折腾一个 70B 级别的模型。显存报错、进程被杀、系统卡死，这些场景轮番上演。当时我的第一反应是：这玩意儿到底怎么做到的？毕竟按照常规认知，70B 参数的模型光是权重加载就需要超过 100GB 的显存，而一张普通显卡的显存通常只有 8GB 到 24GB。airllm 给出的答案是：分层推理，用时间换空间。
这个项目的核心价值非常直接——它让普通开发者用一张显存有限的显卡，就能跑起参数量远超显存容量的模型。它解决的不是推理速度问题，而是“能不能跑起来”的问题。适合谁看？适合手头只有单卡、想本地跑大模型做实验、做验证、做原型开发的人。如果你追求高并发、低延迟的生产级推理，那这个方案不适合你，但如果你想在有限硬件条件下把模型跑通，airllm 的思路值得仔细拆一拆。
我前后在几个不同规模的模型上试过这套方案，踩了不少坑，也总结了一些文档里不会写的细节。下面我从设计思路、核心机制、实操过程、问题排查几个维度，把整个东西讲透。
2. 核心设计思路拆解：为什么是分层加载
2.1 显存不够这件事的本质
要理解 airllm 为什么这么设计，得先搞清楚大模型推理时显存到底被什么占用了。一个 Transformer 模型的显存开销主要分三块：模型权重、激活值、KV Cache。其中模型权重是大头，参数量乘以精度字节数就是权重大小。比如一个 70B 模型用 FP16 存储，光权重就要 140GB 左右。激活值和 KV Cache 跟输入长度和 batch size 相关，但通常远小于权重占用。
常规做法是把整个模型一次性加载到显存里，然后做前向计算。显存不够就直接 OOM。airllm 的思路是：既然显存装不下整个模型，那就一次只加载一层，算完这一层就把这层的权重从显存里释放掉，再加载下一层。这样显存占用就只跟单层的大小有关，而不是整个模型的大小。
这个思路听起来简单，但实现起来有几个关键问题要解决：层与层之间的数据怎么传递？权重从哪加载？加载速度怎么保证？这些问题的答案构成了 airllm 的核心设计。
2.2 分层推理的取舍逻辑
分层推理本质上是一种时间换空间的策略。正常推理时，所有权重都在显存里，计算单元可以连续不断地读取权重做矩阵运算，速度很快。分层加载之后，每算一层都要等权重从磁盘或内存传到显存，这个传输时间就成了瓶颈。
我实测下来，70B 模型在单张 24GB 显卡上，用 airllm 跑一个 token 大概需要几秒到十几秒，具体取决于磁盘读取速度和层数。这个速度做交互式对话肯定不行，但做批量离线推理、做效果验证、做小规模实验是够用的。
那为什么不用量化？量化确实能降低显存占用，比如 4-bit 量化能把 70B 模型压到 35GB 左右，但普通消费级显卡还是装不下。而且量化会带来精度损失，有些任务对精度敏感。airllm 的方案不改变模型精度，它是用调度策略来解决问题，这是它和量化方案的本质区别。
另一个选择是 CPU 推理。CPU 内存大，可以装下整个模型，但计算速度慢。airllm 的方案是 GPU 计算加分层加载，计算本身还是用 GPU，只是权重不在显存里常驻。这样比纯 CPU 推理快，又比全量加载省显存。
2.3 权重存储与加载策略
airllm 默认会把模型权重按层拆分，存成单独的文件。这样做的好处是加载时可以精确读取某一层的权重，不需要把整个模型文件读进来再切分。拆分后的文件通常放在本地磁盘上，加载时从磁盘读到内存，再从内存传到显存。
这里有个关键细节：磁盘读取速度直接影响推理速度。如果你把权重放在机械硬盘上，那每层加载都要等磁盘寻道，速度会非常慢。我试过放在机械盘上，一个 token 要等将近半分钟。换成固态硬盘之后，速度提升非常明显。如果内存足够大，把权重文件放到内存文件系统里，速度还能再上一个台阶。
注意：权重文件的存储位置对推理速度影响极大，建议放在固态硬盘上，有条件的话用内存盘。
3. 核心机制与关键细节解析
3.1 分层加载的具体流程
整个推理流程可以拆成几个步骤。第一步是模型初始化，这时候 airllm 会读取模型的配置文件，确定有多少层、每层的结构是什么、权重文件在哪。第二步是逐层推理，对于每一层，它会把该层的权重从存储位置加载到显存，执行该层的计算，然后把计算结果传给下一层，同时释放当前层的显存占用。
这个过程听起来是串行的，但实际上有一些优化空间。比如可以预加载下一层的权重，在当前层计算的同时就把下一层的数据传过来，这样能掩盖一部分传输时间。airllm 在这方面做了一些调度优化，但具体效果取决于硬件配置。
还有一个细节是KV Cache 的处理。在生成式推理中，KV Cache 会随着生成长度增长。如果 KV Cache 也放在显存里，那随着生成过程推进，显存占用会越来越大。airllm 对 KV Cache 的处理方式会影响它能支持的最大生成长度。我实测发现，生成长度较长时，KV Cache 的显存占用不可忽视，需要根据显卡显存大小调整生成长度上限。
3.2 精度与性能的平衡
airllm 支持不同的精度模式。默认情况下它可能用 FP16 或 BF16，这两种精度在显存占用和计算速度之间比较平衡。如果显存实在紧张，也可以考虑用 8-bit 或 4-bit 量化加载，但这需要额外的量化工具支持，而且会带来精度损失。
我的建议是：先尝试不量化跑通，再根据显存情况决定是否量化。因为分层加载本身已经大幅降低了显存需求，很多时候不需要再量化就能跑起来。量化应该是最后的手段，而不是第一选择。
另外要注意的是，不同精度模式下，层与层之间的数据传输量也不同。FP16 每层权重占用的空间是 FP32 的一半，传输时间也相应减少。所以在显存允许的情况下，用低精度存储权重、高精度计算，是一个常见的优化手段。
3.3 模型兼容性与层拆分逻辑
airllm 对模型架构有一定要求。它主要支持基于 Transformer 架构的模型，因为这类模型天然是分层结构，容易做层拆分。对于非 Transformer 架构或者层结构不规则的模型，支持程度可能有限。
层拆分的逻辑通常是按照模型的layers或blocks属性来切分。不同模型框架的层命名方式不一样，airllm 需要适配这些差异。我在试一些非主流模型时，遇到过层识别错误的问题，需要手动指定层结构或者调整拆分逻辑。
提示：使用前先确认模型架构是否被支持，可以先用小模型验证流程，再上大模型。
4. 实操过程：从零跑通一个分层推理模型
4.1 环境准备与依赖安装
先说环境。我用的是一台 Linux 机器，显卡是一张 24GB 显存的消费级卡，内存 64GB，系统盘是固态硬盘。Python 环境用 3.10 版本，CUDA 版本跟显卡驱动匹配。
安装 airllm 本身不复杂，用 pip 就能装。但它依赖的一些库需要注意版本兼容性，特别是跟深度学习框架相关的包。我建议先创建一个干净的虚拟环境，避免跟系统里已有的包冲突。
python -m venv airllm_env source airllm_env/bin/activate pip install airllm安装完成后，可以先跑一个简单的导入测试，确认没有报错。如果报错，大概率是依赖版本问题，根据报错信息调整对应包的版本即可。
4.2 模型下载与权重拆分
airllm 支持从模型仓库直接加载，也支持加载本地已经下载好的模型。如果网络条件允许，直接指定模型名称让它自动下载是最省事的。但大模型动辄几十上百 GB，下载时间可能很长，而且中途断线会很麻烦。
我的做法是先用其他工具把模型权重下载到本地，然后用 airllm 加载本地路径。下载的时候要注意，有些模型仓库会把权重分成多个文件，需要全部下载完整。下载完成后，airllm 会在第一次加载时做权重拆分，把整个模型按层拆成单独的文件。
拆分过程需要额外的磁盘空间，大概是原模型大小的 1.5 到 2 倍。拆分完成后，原始的大文件可以删掉，只保留拆分后的分层文件。拆分后的目录结构通常是按层编号组织的，每一层一个文件或者一组文件。
from airllm import AutoModel model = AutoModel.from_pretrained( "/path/to/local/model", layer_shards_saving_path="/path/to/shards" )这段代码会触发权重拆分。第一次运行会花一些时间，取决于模型大小和磁盘速度。拆分完成后，后续加载就直接用拆分好的文件，速度快很多。
4.3 推理参数配置与显存控制
推理时的参数配置直接影响显存占用和生成速度。几个关键参数需要关注：最大生成长度、batch size、精度模式。
最大生成长度决定了 KV Cache 的上限。如果设得太大，KV Cache 会占用过多显存，可能导致 OOM。我一般先设一个较小的值，比如 128 或 256，跑通之后再逐步调大，观察显存占用变化。
batch size 在分层推理场景下通常设为 1，因为 batch size 增大会成倍增加激活值和 KV Cache 的显存占用。如果显存有富余，可以尝试设为 2 或 4，但收益不一定明显，因为瓶颈主要在权重加载上。
精度模式的选择前面说过了，优先用 FP16 或 BF16，显存不够再考虑量化。
output = model.generate( input_ids, max_new_tokens=128, use_cache=True, do_sample=False )use_cache=True会启用 KV Cache，这对生成式推理是必要的，否则每生成一个 token 都要重新计算前面所有 token 的 KV，速度会慢很多。
4.4 实际运行记录与性能观察
我第一次跑 70B 模型的时候，用的是 24GB 显卡加 64GB 内存，权重放在固态硬盘上。启动加载花了大概几分钟，主要是拆分权重和初始化。第一个 token 生成花了十几秒，后续 token 速度稳定在每秒几个 token 左右。
观察显存占用，峰值大概在 20GB 左右，接近显卡上限但没有 OOM。如果生成长度设得更大，显存占用会进一步上升。后来我把权重文件放到内存盘上，token 生成速度有明显提升，因为磁盘读取瓶颈被消除了。
还有一个观察是：模型层数越多，分层加载的开销越大。因为每层都要做一次加载和释放，层数多意味着调度次数多。所以对于层数特别多的模型，分层推理的速度劣势会更明显。
5. 常见问题与排查技巧实录
5.1 显存溢出与内存不足的区分
很多人遇到报错就以为是显存不够，其实有时候是内存不够。分层加载的过程中，权重先从磁盘读到内存，再从内存传到显存。如果内存不够大，读进来的权重没地方放，就会报内存错误。
区分方法很简单：看报错信息里是 CUDA out of memory 还是系统层面的内存分配失败。前者是显存问题，后者是内存问题。显存问题可以通过减小生成长度、降低精度、减小 batch size 来缓解。内存问题则需要减小同时加载的层数，或者增加系统内存。
我遇到过一种情况是显存和内存都够，但虚拟内存不够。Linux 系统在物理内存不足时会用交换分区，如果交换分区太小，也会导致分配失败。这种情况需要调整系统交换分区大小。
5.2 推理速度过慢的优化方向
速度慢是分层推理的固有代价，但可以通过一些手段优化。第一个方向是提升存储速度，把权重放在更快的存储介质上。第二个方向是预加载，在当前层计算时提前加载下一层。第三个方向是减少层数，用层数更少的模型。
还有一个容易被忽略的点是CPU 到 GPU 的数据传输。如果 CPU 和 GPU 之间的传输带宽不够，加载速度也会受限。确保用的是 PCIe 3.0 以上的接口，带宽会好一些。
我实测下来，从机械硬盘换到固态硬盘，速度提升大概有两三倍。从固态硬盘换到内存盘，又能提升一倍左右。所以存储介质的选择非常关键。
5.3 模型加载失败的常见原因
模型加载失败的原因有很多，常见的有：权重文件不完整、层结构不匹配、依赖库版本冲突、路径权限问题。
权重文件不完整通常发生在下载中断的情况下。解决办法是重新下载或者校验文件完整性。层结构不匹配通常发生在非标准模型上，需要手动指定层结构或者换一个支持的模型。依赖库版本冲突需要根据报错信息逐个排查，有时候需要降级或升级某个包。路径权限问题在 Linux 系统上比较常见，确保运行用户对模型路径有读取权限。
下面这个表格整理了我遇到过的典型问题和对应解法：
| 问题现象 | 可能原因 | 排查方法 | 解决方向 |
|---|---|---|---|
| CUDA out of memory | 显存不足 | 查看显存占用峰值 | 减小生成长度或降低精度 |
| 内存分配失败 | 系统内存不足 | 查看内存使用情况 | 减小同时加载层数或加内存 |
| 加载速度极慢 | 存储介质慢 | 测试磁盘读取速度 | 换固态硬盘或内存盘 |
| 层识别错误 | 模型架构不匹配 | 检查模型层结构 | 手动指定层结构或换模型 |
| 权重文件缺失 | 下载不完整 | 校验文件完整性 | 重新下载缺失文件 |
| 依赖报错 | 版本冲突 | 查看报错堆栈 | 调整依赖包版本 |
5.4 实操避坑经验汇总
第一个坑是磁盘空间不够。权重拆分需要额外空间，如果磁盘本来就快满了，拆分到一半会失败。建议预留至少两倍模型大小的空间。
第二个坑是内存盘大小限制。内存盘虽然快，但大小受物理内存限制。如果模型太大，内存盘放不下，就只能放一部分层，或者用固态硬盘。
第三个坑是生成长度设得太大。刚开始跑的时候，我设了一个很大的生成长度，结果跑到一半 OOM 了。后来改成从小长度开始，逐步增加，就稳定多了。
第四个坑是忽略 KV Cache 的显存占用。KV Cache 是随生成长度增长的，短输入时可能不明显，长输入时占用会很大。需要在显存规划时把这块算进去。
提示：第一次跑一个新模型时，先用小生成长度验证流程，确认没问题再逐步调大。
6. 这套方案适合什么场景，不适合什么场景
分层推理这个思路，本质上是在硬件受限的情况下做妥协。它适合的场景很明确：单卡、显存有限、想跑大模型、对速度不敏感。比如做模型效果验证、做小规模实验、做离线批量推理，这些场景下速度慢一点可以接受，关键是能跑起来。
不适合的场景也很明确：高并发、低延迟、生产级服务。这些场景需要模型常驻显存，需要快速响应，分层加载的开销无法接受。另外，如果显存足够大，能直接装下整个模型，那也没必要用分层加载，直接全量加载速度更快。
还有一个中间场景是多卡推理。如果有多张显卡，可以把不同层分配到不同显卡上，这样每张显卡只需要装一部分层，也能跑起大模型。这种方案比单卡分层加载速度快，但需要多卡硬件支持。
从技术演进的角度看，分层加载是一种过渡方案。随着显存越来越大、量化技术越来越成熟、模型架构越来越高效，这种方案的必要性可能会降低。但在当前阶段，对于手头硬件有限的开发者来说，它仍然是一个实用的选择。
我个人在实际操作中的体会是：先明确自己的约束条件，再选择方案。如果显存是主要瓶颈，分层加载值得一试。如果速度是主要瓶颈，那可能需要考虑其他方案。没有万能方案，只有适合当前约束的方案。airllm 给了我们多一个选择，这本身就是它的价值。
