1. 当大模型装不进显卡时我在想什么第一次看到 airllm 这个项目名我脑子里蹦出来的不是“又一个推理框架”而是一个很具体的画面一台只有单张消费级显卡的机器想跑一个参数量远超显存容量的模型然后有人告诉你——不用量化到面目全非不用换卡也能跑起来。这就是 airllm 最核心的价值主张让大模型在显存不足的硬件上依然能够完成推理。它解决的不是“如何让模型跑得更快”而是“如何让模型先跑得起来”。这两件事的优先级完全不同。前者是优化问题后者是可行性问题。我接触这个方向是因为身边太多人卡在同一个坎上手里有一张 8GB 或 12GB 显存的卡想本地跑一个 7B、13B 甚至 70B 级别的模型结果要么 OOM显存溢出要么被迫用量化版本牺牲精度。airllm 给出的思路是另一条路——把模型按层拆分让每一层在需要计算时才加载进显存算完就释放。本质上是用时间换空间用磁盘 I/O 换显存占用。这篇文章适合三类人看第一类是想在有限硬件上跑大模型的个人开发者第二类是对分层加载、按需推理这类工程思路感兴趣的技术人第三类是想理解“推理框架到底在解决什么问题”的入门者。我会从它的核心机制讲起拆解分层加载的实现逻辑补充实际部署中的参数配置、踩坑经验和性能权衡最后聊聊这类方案适合什么场景、不适合什么场景。需要提前说明的是airllm 这类方案的核心思想并不复杂难的是工程细节——层怎么切、什么时候加载、什么时候释放、如何避免频繁 I/O 拖垮整体速度。这些细节决定了它是“能跑”还是“能用”。2. 分层加载到底是怎么把大模型塞进小显存的2.1 传统推理的显存瓶颈出在哪要理解 airllm 的价值得先搞清楚常规推理为什么吃显存。一个 Transformer 模型在推理时显存占用主要来自三块模型权重本身、激活值中间计算结果、以及 KV Cache。模型权重是大头。以 FP16 精度为例一个 7B 参数的模型光权重就要占大约 14GB 显存7B × 2 字节。13B 就是 26GB70B 就是 140GB。这还没算激活值和 KV Cache。所以一张 12GB 的卡连 7B 模型的权重都放不下更别说更大的模型。常规做法是量化——把 FP16 压到 INT8 或 INT4权重占用能降到原来的 1/2 或 1/4。但量化会带来精度损失而且有些模型量化后效果下降明显。airllm 走的是另一条路不压缩权重而是改变权重的驻留策略。2.2 按层加载的核心逻辑Transformer 模型的结构是层叠的——一层接一层数据从底层流向顶层。关键洞察在于在任意时刻真正参与计算的只有当前这一层。其他层的权重虽然存在但并不需要同时待在显存里。airllm 的做法就是利用这个特性把模型按层切分每一层的权重单独存放在磁盘上。推理时只把当前需要计算的那一层加载进显存算完之后立刻释放再加载下一层。这样显存的峰值占用就只取决于单层的大小而不是整个模型的大小。一个 70B 的模型如果切成 80 层每层大约 0.875B 参数FP16 下约 1.75GB。也就是说理论上只要有 2GB 左右的可用显存就能跑起来。这就是它能把大模型塞进小显存的核心原因。注意这里的“单层大小”是理论值实际还要加上激活值、KV Cache 和框架开销。所以真实显存需求会比单层权重大一些但量级上仍然是可控的。2.3 时间换空间的代价这个方案不是没有代价的。每次加载一层都要从磁盘读取权重这个 I/O 开销是实打实的。如果磁盘是机械硬盘读取速度可能只有 100-200MB/s加载一层 1.75GB 的权重就要十几秒80 层就是十几分钟——这显然不可接受。所以 airllm 的实际可用性高度依赖存储介质。NVMe SSD 是基本门槛读取速度能到 2-7GB/s加载一层的时间能压到 1 秒以内。如果能把模型放在内存盘RAM Disk上速度还能更快但内存盘容量有限大模型放不下。另一个优化点是预加载。在计算当前层的时候可以异步预加载下一层的权重让 I/O 和计算重叠起来。这样整体耗时就不是“加载时间 计算时间”的简单累加而是接近两者中的较大值。这个优化对实际体验影响很大。2.4 和量化方案的对比维度airllm 分层加载量化方案精度损失无保持原始精度有取决于量化位数显存需求取决于单层大小取决于量化后总大小推理速度受 I/O 限制较慢较快硬件门槛需要快速 SSD显存够大即可适用场景显存小但存储快显存中等、追求速度这两条路不是互斥的。实际中也可以先量化再分层加载进一步降低单层大小。但那样就叠加了两种方案的代价需要根据具体场景权衡。3. 实际部署时参数配置和存储选择怎么定3.1 环境准备中最容易被忽略的一步部署 airllm 之前很多人会直接 pip install 然后跑 demo结果发现速度慢得离谱。问题往往不在代码而在模型权重的存储位置。默认情况下模型权重会下载到用户目录下的缓存文件夹。如果这个目录在机械硬盘上那分层加载的 I/O 瓶颈会非常明显。我的建议是在开始之前先把模型权重放到 NVMe SSD 上并且确认这个分区的读取速度。可以用一个简单的命令测一下磁盘读取速度# 测试磁盘顺序读取速度 dd if/path/to/model/weights of/dev/null bs1M count2048如果输出显示速度低于 500MB/s那基本可以确定瓶颈在磁盘上。这种情况下要么换盘要么考虑把模型放到内存盘上如果内存足够大。3.2 分层粒度的选择airllm 默认会按 Transformer 的层来切分但实际使用中层的大小并不完全均匀。有些模型的前几层和后几层参数量差异较大。如果某一层特别大它就会成为显存占用的峰值。一个实用的技巧是先跑一次观察每层加载时的显存峰值。如果发现某一层明显偏大可以考虑把它进一步拆分或者调整加载策略。不过大多数主流模型的分层已经比较均匀不需要手动干预。另一个参数是预加载的层数。预加载太多会占用额外显存预加载太少又起不到重叠 I/O 的效果。一般建议预加载 1-2 层具体取决于显存余量和磁盘速度。显存充裕、磁盘慢的情况下可以多预加载几层。3.3 推理参数的调整分层加载模式下一些常规推理参数需要重新考虑。比如batch size在显存紧张的情况下batch size 只能设为 1。因为每一层的激活值也要占显存batch 越大激活值越大峰值显存就越高。还有max sequence length。序列越长KV Cache 越大。在分层加载模式下KV Cache 是跨层保留的不会随层释放。所以长序列会显著增加显存占用。如果显存实在紧张可以适当限制输入长度。# 典型的推理配置示例 config { batch_size: 1, # 显存紧张时只能为1 max_seq_len: 512, # 根据显存调整 prefetch_layers: 2, # 预加载层数 device: cuda:0, # 指定显卡 }3.4 存储方案的取舍前面提到 NVMe SSD 是基本门槛但具体选哪种存储还要看模型大小和使用频率。如果只是偶尔跑一次NVMe SSD 足够了。如果是频繁使用可以考虑把模型放在内存盘上。Linux 下可以用 tmpfs 创建内存盘# 创建 64GB 的内存盘 mkdir /mnt/ramdisk mount -t tmpfs -o size64G tmpfs /mnt/ramdisk然后把模型权重复制进去。这样加载速度能到 10GB/s 以上基本消除了 I/O 瓶颈。但代价是内存被占用而且重启后数据丢失。所以适合内存充足比如 128GB 以上且频繁使用的场景。还有一种折中方案用高速缓存盘。一些主板支持把 NVMe SSD 作为缓存加速机械硬盘的读取。这样既有大容量又有不错的读取速度。不过配置起来稍复杂适合有一定硬件基础的人。4. 跑通之后才会遇到的坑速度、显存与稳定性4.1 为什么第一次推理特别慢很多人跑通 airllm 后的第一个感受是第一次推理慢得让人怀疑人生。这其实是正常的。第一次运行时模型权重需要从磁盘加载而且没有预加载优化每一层都是“加载-计算-释放”的串行流程。从第二次开始如果操作系统有文件缓存部分权重可能还在内存里速度会快一些。但真正稳定的速度取决于磁盘的持续读取能力。我的实测经验是NVMe SSD 上70B 模型的分层推理速度大约是常规推理的 1/5 到 1/10。这个差距主要来自 I/O 等待。如果觉得太慢可以尝试几个优化一是增加预加载层数让 I/O 和计算重叠二是把模型放到内存盘三是减少 max sequence length降低单次计算量。4.2 显存峰值的波动分层加载的显存占用不是恒定的而是随层波动的。有些层的激活值大有些层小。如果观察到显存峰值接近上限可以尝试限制预加载层数或者在层间主动释放缓存。PyTorch 下可以用torch.cuda.empty_cache()手动释放未使用的显存。但要注意频繁调用这个函数本身有开销不建议每层都调。可以在显存接近上限时调用或者每隔几层调一次。另一个容易忽略的点是CUDA 上下文本身的显存占用。即使什么都不算CUDA 上下文也要占几百 MB。所以实际可用显存要比标称值少一些。规划时要留出余量。4.3 模型格式与兼容性airllm 对模型格式有一定要求。它需要能够按层拆分模型权重所以最好使用标准的 Hugging Face 格式safetensors 或 pytorch bin。如果模型是 GGUF 或其他量化格式可能需要先转换。另外不同模型架构的层结构不同。有些模型有特殊的层比如 MoE 架构的专家层分层逻辑需要相应调整。airllm 对主流架构LLaMA、GPT、BLOOM 等支持较好但冷门架构可能需要自己改代码。提示在下载模型之前先确认 airllm 是否支持该架构。可以查看项目的文档或源码中的模型支持列表。如果不支持要么换模型要么自己实现分层逻辑。4.4 长时间运行的稳定性分层加载模式下推理时间被拉长长时间运行的稳定性就变得重要。我遇到过几个问题一是磁盘过热导致读取速度下降二是内存泄漏导致显存逐渐被占满三是长时间运行后系统进入休眠中断推理。针对这些问题可以做一些防护确保机箱散热良好尤其是 NVMe SSD 的散热在代码里定期检查显存占用必要时重启推理进程关闭系统休眠或者用工具保持系统唤醒。5. 这类方案真正适合的场景以及它的边界5.1 适合的场景显存受限但存储充裕airllm 最适合的场景很明确显存小但存储快且容量大。比如一张 8GB 的卡配一块 1TB 的 NVMe SSD想跑 13B 或 30B 的模型。这种情况下常规方案要么跑不起来要么量化后效果打折而分层加载能保持原始精度跑起来。另一个适合的场景是多模型切换。因为模型权重存在磁盘上切换模型只需要换一个目录不需要重新加载到显存。这对于需要频繁切换不同模型的场景比如对比测试比较友好。还有一个场景是教学和演示。在资源有限的环境里想演示大模型的推理过程分层加载能让更多人看到实际效果而不只是纸上谈兵。5.2 不适合的场景追求速度和并发如果追求推理速度airllm 不是好选择。它的速度受 I/O 限制比常规推理慢一个数量级。对于需要低延迟的场景比如实时对话体验会比较差。如果要做并发推理airllm 也不合适。因为每一层都要加载和释放多个请求同时进来会导致 I/O 竞争速度进一步下降。这种情况下要么用更大的显存跑常规推理要么用专门的推理服务框架。还有一个不适合的场景是频繁的小批量推理。如果每次只推理几个 token那加载整层权重的开销就显得特别大性价比很低。分层加载更适合一次性生成较长文本的场景。5.3 和其他显存优化方案的组合airllm 不是孤立的方案它可以和其他显存优化技术组合使用。比如量化 分层加载先量化降低单层大小再分层加载进一步降低峰值显存。代价是精度损失和速度下降叠加。梯度检查点 分层加载梯度检查点主要用于训练但推理时也可以用类似思路减少激活值占用。CPU offload 分层加载把部分层放在 CPU 内存里需要时再传到 GPU。这和分层加载思路类似但粒度更细。这些组合方案各有取舍需要根据具体硬件和需求来选。我的建议是先用最简单的方案跑通再根据瓶颈逐步优化。不要一上来就堆砌各种技术那样调试起来很痛苦。5.4 我对这类方案的实际体会用了一段时间 airllm 之后我最大的体会是它解决的是“有没有”的问题而不是“好不好”的问题。在显存受限的情况下它让原本跑不起来的模型跑起来了这个价值是实实在在的。但如果显存足够我不会选它因为速度差距太明显。另一个体会是存储介质的选择比参数调优更重要。同样的代码放在机械硬盘和 NVMe SSD 上速度可能差十倍。所以如果决定用这类方案先把存储升级到位比调任何参数都有效。最后一点这类方案适合个人开发者和小团队做实验、做 demo但不适合生产环境的高并发服务。生产环境下要么用足够的显存跑常规推理要么用专门的推理优化框架。分层加载的定位是“资源受限时的可行方案”而不是“通用最优解”。如果你也在显存受限的环境下折腾大模型不妨试试这个思路。它不一定是最快的但可能是最能让你“先跑起来”的。跑起来之后再根据实际瓶颈去优化比一开始就追求完美要务实得多。