单卡显存不足如何跑大模型？airllm分层加载与预取优化实战

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

第一次看到 airllm 这个项目的时候，我正在一台只有单张消费级显卡的机器上折腾一个 70B 级别的模型。显存报错几乎是必然的，OOM 的红色提示刷了满屏，那种感觉就像你明明有一整间仓库的货，却只有一扇小门能往里搬。airllm 想解决的就是这个矛盾：在显存极其有限的单卡环境下，把远超显存容量的大模型跑起来。

它的核心思路并不神秘，一句话概括就是分层加载、按需换入换出。模型权重平时躺在内存或者磁盘上，推理到哪一层，就把哪一层搬进显存，算完立刻挪走，给下一层腾地方。听起来像是把"一次性全塞进去"改成了"流水线搬运"，但真正落地时，搬运的时机、粒度、缓存策略，每一步都决定了你是能跑起来还是卡成幻灯片。

这篇文章适合几类人看：手里只有一张卡、显存捉襟见肘，却想本地跑大模型的开发者；对推理框架底层调度机制好奇、想自己动手改一版的技术爱好者；以及被显存墙反复劝退、想搞清楚"到底能不能省、能省多少"的实践派。我会把 airllm 的设计取舍、关键参数、实操步骤、踩坑记录都摊开讲，尽量让你看完就能在自己的机器上复现一遍。

需要先说明的是，airllm 不是魔法。它用时间换空间，省下的是显存，付出的是推理速度。理解这一点，后面所有的参数调优和预期管理都会顺理成章。

2. 核心设计思路拆解：为什么是"分层换入换出"

2.1 显存墙的本质：权重、激活与 KV Cache 的三重挤压

要理解 airllm 为什么这么设计，得先搞清楚显存到底被谁吃掉了。跑一个大模型，显存开销主要来自三块：模型权重、前向激活值、KV Cache。

模型权重是最直观的一块。一个 70B 参数的模型，如果用 FP16 存储，光权重就要 140GB 左右，这还没算任何中间计算。单张 24GB 的卡连零头都放不下。激活值是前向传播过程中每一层产生的中间结果，层数越深、batch 越大，占用越高。KV Cache 则是自回归生成时的历史键值缓存，序列越长它越膨胀，长上下文场景下甚至能超过权重本身。

airllm 主要针对的是权重这一块。它的判断很务实：激活和 KV Cache 跟你的输入长度、batch 强相关，不好一刀切；但权重是固定的，而且占了绝对大头。把权重从"常驻显存"改成"按需加载"，就能把显存占用从"模型总大小"压到"单层大小 + 少量缓存"，这是数量级的差别。

提示：分层加载解决的是权重占用，如果你的场景是超长上下文导致 KV Cache 爆炸，airllm 帮不了太多，那属于另一个优化方向。

2.2 分层粒度的选择：为什么按 Transformer 层切

模型切分有好几种粒度：按张量切、按层切、按模块切。airllm 选择的是按 Transformer 层（layer）切分，这个选择背后有明确的工程考量。

按张量切分（比如把单个矩阵拆成几块）粒度太细，会导致频繁的小块数据传输，PCIe 带宽利用率极低，调度开销反而吃掉收益。按更大的模块切分（比如整个 encoder 或 decoder 堆叠）粒度又太粗，单块可能还是放不进显存。Transformer 的每一层结构高度一致、大小相近，天然适合作为搬运单元。一层的大小大致等于(注意力参数 + FFN 参数) × 精度字节数，对主流模型来说通常在几百 MB 到 2GB 之间，正好能塞进消费级显卡的剩余显存。

这种"整齐切块"还有个好处：调度逻辑简单。你不需要为每一层写特殊的加载代码，一个循环遍历所有层就行。工程上越简单的东西越不容易出 bug，也越容易做预取优化。

2.3 时间换空间的账怎么算

很多人第一次用 airllm 会被速度劝退，觉得"这也太慢了"。但如果你把账算清楚，会发现这个交换在特定场景下是划算的。

假设模型有 N 层，每层大小 S，显存能放下 k 层。理想情况下，如果完全不重叠，每生成一个 token 需要把所有层从内存搬进显存一次，总传输量是 N×S。以 70B 模型为例，权重约 140GB，如果内存到显存的带宽是 20GB/s，那么每 token 光传输就要 7 秒。这显然不能接受。

airllm 的优化点在于预取（prefetch）：在计算第 i 层的时候，后台线程已经在把第 i+1 层往显存里搬。这样传输和计算重叠，实际耗时取决于两者中较慢的那个。如果计算时间大于传输时间，传输就被"藏"起来了，速度损失可控。这也是为什么 airllm 在层数多、单层计算量大的模型上表现更好——计算越重，越能掩盖搬运的开销。

这张表基本概括了 airllm 的定位：它落在第三行，通过预取把速度从"不可用"拉回"能用"。

3. 关键机制与参数实操要点

3.1 权重存储格式：为什么建议先转成 safetensors

airllm 加载模型时，权重的存储格式直接影响加载速度和内存占用。原始的多文件 bin 格式在读取时需要反序列化，速度慢且内存峰值高。safetensors格式则是内存映射友好的，读取时不需要把整个文件读进内存再解析，可以直接按需映射。

实操上，我建议在正式跑 airllm 之前，先把模型转成 safetensors 格式。转换本身不复杂，用官方提供的转换脚本或者框架自带的保存接口都行。转换后你会发现，同样的模型，加载阶段的卡顿明显减少，尤其是第一次冷启动的时候。

注意：转换过程需要足够的磁盘空间，因为要同时存在原格式和新格式。建议预留模型大小 2.5 倍以上的空间。

3.2 分层加载的核心参数：layer 缓存与预取深度

airllm 暴露出来的可调参数不算多，但每一个都关键。最核心的是缓存层数和预取深度。

缓存层数决定了显存里同时保留几层。设成 1 就是最激进的省显存模式，算完一层立刻丢；设成 2 或 3 可以保留最近用过的层，在某些重复调用的场景下减少搬运。但缓存越多，显存占用越高，需要你自己权衡。

预取深度控制后台提前搬运几层。深度为 1 表示只预取下一层，深度为 2 表示提前搬两层。深度越大，对传输带宽的利用越充分，但也越容易在显存里堆积未使用的层，反而挤占空间。我的经验是，预取深度设为 1 到 2 之间最稳，再大收益递减明显。

# 伪代码示意，展示分层加载的核心循环逻辑 for layer_idx in range(num_layers): # 预取下一层到显存 if layer_idx + 1 < num_layers: prefetch_to_gpu(layer_idx + 1) # 当前层计算 hidden_states = layers[layer_idx](hidden_states) # 释放当前层显存（如果缓存策略允许） if layer_idx not in cache_window: free_gpu_memory(layer_idx)

这段逻辑看着简单，但实际实现里，预取和释放的时机差一点点，就可能导致显存峰值超标或者传输空转。

3.3 精度选择：FP16、INT8 与 INT4 的取舍

airllm 支持不同的精度加载，这直接决定了显存占用和输出质量。FP16 是默认选项，质量最好但占用最高。INT8 能把权重压到一半，质量损失通常很小，是性价比很高的选择。INT4 压得更狠，但质量下降开始变得可感知，尤其是对数值敏感的推理任务。

我的建议是：先用 INT8 试，如果显存还是不够再降到 INT4。不要一上来就 INT4，因为量化损失在长文本生成里会累积，表现为重复、跑题或者逻辑断裂。另外，量化后的模型在分层加载时，单层体积更小，预取更容易藏进计算时间里，速度反而可能比 FP16 更快。

4. 完整实操流程：从零把大模型跑起来

4.1 环境准备与依赖安装

先把基础环境搭好。Python 版本建议 3.9 以上，太低会遇到一些库的兼容问题。CUDA 版本要和你的显卡驱动匹配，这个不用多说，装错了后面全是坑。

安装 airllm 本身很直接，用 pip 就行。但它依赖的一些底层库，比如加速传输和量化的组件，可能需要单独确认版本。我踩过的坑是：某个量化库的版本和 PyTorch 版本不匹配，导致加载 INT4 模型时直接崩溃，报的错还特别隐晦。所以装完之后，先跑一个最小示例验证环境，别急着上大模型。

# 基础依赖安装示意 pip install airllm pip install torch --index-url [对应CUDA版本的源] # 量化支持（按需） pip install bitsandbytes

提示：如果你的机器内存也不大，加载大模型时可能触发内存 OOM。这时候可以考虑把权重放在磁盘上，用内存映射方式读取，代价是速度进一步下降。

4.2 模型加载与首次推理验证

环境好了之后，先拿一个小模型验证流程通不通。别一上来就 70B，那样出错了你都不知道是环境问题还是模型问题。用一个 7B 左右的模型跑通加载、推理、输出这条链路，确认没问题再换大的。

加载时注意观察显存占用曲线。正常情况下，显存应该稳定在一个较低的水平，而不是随着推理逐渐爬升。如果发现显存持续增长，大概率是某一层的缓存没释放干净，需要检查缓存策略的配置。

首次推理会特别慢，因为要经历冷启动、权重映射、预取预热等过程。第一次的输出慢不代表最终速度，多跑几轮取稳定值才有参考意义。

4.3 参数调优与速度实测

跑通之后就是调优。我一般按这个顺序来：先固定精度，调预取深度；再固定预取深度，调缓存层数；最后看要不要上量化。

实测下来，预取深度从 0 调到 1 的提速最明显，可能有一倍以上的提升；从 1 调到 2 提升就小很多了。缓存层数从 1 调到 2 对速度帮助有限，但显存占用增加明显，所以除非你有反复调用同一段前缀的需求，否则保持 1 就行。

速度的衡量建议用每 token 耗时而不是总耗时，因为总耗时受输出长度影响太大。记录稳定状态下的每 token 耗时，才能横向对比不同参数的效果。

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

5.1 显存还是爆了怎么办

这是最高频的问题。明明用了分层加载，为什么还是 OOM？常见原因有几个：一是预取深度设太大，显存里堆积了多层；二是 KV Cache 没控制，长序列下它自己就撑爆了；三是激活值在 batch 较大时占用飙升。

排查顺序建议：先把预取深度降到 0，看还爆不爆。如果不爆了，说明是预取堆积，逐步往上加找到临界点。如果还爆，检查输入序列长度和 batch，把它们降下来再试。最后才考虑降精度。

5.2 速度慢到无法接受

速度问题要先定位瓶颈在传输还是计算。一个简单的判断方法：看 GPU 利用率。如果利用率很低，说明大部分时间在等数据传输，瓶颈在 PCIe 或内存带宽；如果利用率很高但速度还是慢，那就是计算本身重，只能靠降精度或者换更强的卡。

传输瓶颈的优化空间有限，能做的就是确保预取生效、减少不必要的层搬运、用更快的存储（比如把权重放在 SSD 而不是机械盘上）。

5.3 输出质量异常

如果发现输出重复、逻辑混乱，先排除是不是量化导致的。把精度换回 FP16 再跑一遍，如果正常了，那就是量化损失，考虑换 INT8 或者调整量化配置。如果 FP16 也异常，检查模型文件是否完整、加载过程有没有报错被忽略。

5.4 几个容易被忽略的细节

第一个是磁盘 IO。如果你的权重放在机械硬盘上，分层加载会频繁读取，机械盘的随机读性能会成为严重瓶颈。换成 SSD 后速度可能有质的提升。

第二个是内存容量。airllm 虽然省显存，但权重在换入显存前通常要先经过内存。如果内存也不够，就得用磁盘映射，速度再降一档。所以内存建议至少能放下整个模型。

第三个是首次加载的耐心。冷启动时各种缓存都是空的，慢是正常的。别因为第一次慢就否定整个方案，跑几轮再看。

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

airllm 的价值边界其实很清晰。它适合显存受限但时间相对宽裕的场景：本地实验、个人研究、小规模验证、对延迟不敏感的批处理任务。在这些场景下，能用比不能用重要得多，慢一点完全可以接受。

它不适合高并发、低延迟的生产服务。分层加载的吞吐量摆在那里，你没法靠它撑起一个实时响应的在线系统。那种场景需要的是多卡并行、张量并行或者专门的推理服务框架，airllm 的定位不在这里。

我自己在实际操作中的体会是：airllm 更像是一把"应急钥匙"，它帮你打开那扇被显存锁住的门，让你能进去看看。至于进去之后是慢慢逛还是快步跑，取决于你手里的硬件和时间预算。把预期放对位置，它就是个很实用的工具；预期错了，就会觉得它哪哪都不行。

最后分享一个小技巧：如果你只是想做一次性验证，比如确认某个模型能不能处理你的任务，那用 airllm 跑一个短输出就够了，没必要追求速度。但如果你要反复迭代 prompt 或者做对比实验，那每次几秒的延迟累积起来很可观，这时候值得花时间把预取和量化调到最优，甚至考虑换一张显存更大的卡。工具是死的，场景是活的，怎么用还是看你自己。