单卡跑70B大模型：airllm分层加载实战与优化指南

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

第一次听说有人想在单张消费级显卡上跑 70B 参数级别的大语言模型，我的反应和大多数人一样：这不是开玩笑吗。按 FP16 精度算，70B 参数的模型光权重就要吃掉 140GB 显存，而一张主流消费卡的显存普遍在 8GB 到 24GB 之间，中间差着五六倍。这个数字鸿沟不是靠调调参数就能糊弄过去的，它是硬性的物理约束。

但 airllm 这个项目做的事情，恰恰就是在这个鸿沟上架了一座桥。它的核心思路说起来并不复杂：既然显存装不下整个模型，那就不要一次性装进去。把模型按层切开，用哪层加载哪层，用完就释放，让显存里始终只保留当前计算需要的那一小部分权重。这个思路在业界叫分层推理或者逐层加载，airllm 把它做成了一套开箱即用的工具，让没有多卡集群的普通开发者也能在本地跑起大模型。

这篇文章适合几类人看：手头只有一张消费级显卡、想跑大模型但被显存劝退的开发者；对推理优化感兴趣、想理解分层加载原理的技术爱好者；以及已经在用 airllm 但遇到速度慢、配置报错等问题、想找到优化方向的人。我会从设计思路讲到实操细节，再到踩坑经验，尽量把每个环节的“为什么”说清楚，让你不只是会跑，还知道它为什么能跑起来、瓶颈在哪里、怎么调更顺。

需要提前说明的是，airllm 解决的是“能不能跑”的问题，不是“跑得多快”的问题。它的定位是让显存不够的人也能用上大模型，代价是推理速度会明显慢于模型全部驻留显存的情况。理解这个定位，后面的很多设计取舍就都能想通了。

2. 分层加载的设计逻辑与方案取舍

2.1 为什么是“分层”而不是“量化”

面对显存不足，业界有两条主流路线。一条是量化压缩，把 FP16 的权重压成 INT8、INT4 甚至更低，用精度换空间。另一条就是 airllm 走的分层加载，不改变权重精度，而是改变权重的驻留策略。

这两条路线的取舍很值得说道。量化的问题在于，它是有损的。4bit 量化虽然能把显存占用降到原来的四分之一左右，但模型在某些任务上的表现会打折扣，尤其是需要精细推理的场景。而且量化本身需要额外的校准过程，不同模型、不同量化方案的效果差异很大，对普通用户来说调优成本不低。

分层加载的好处是无损。权重还是原来的 FP16，计算精度不打折，模型能力完整保留。代价是速度。因为每一层都要从磁盘读进显存，计算完再释放，磁盘 IO 成了新的瓶颈。airllm 的聪明之处在于，它把这个 IO 过程做了优化，让速度慢得没那么离谱。

我个人的判断是：如果你对输出质量要求高、能接受慢一点，分层加载更稳妥；如果你追求速度、能接受轻微的质量损失，量化可能更合适。airllm 选的是前者，这个定位很清晰。

2.2 逐层加载的核心机制

理解 airllm 的关键，是理解 Transformer 模型的结构特点。一个标准的大语言模型是由几十层结构相同的 Transformer Block 堆叠而成的，每一层包含自注意力、前馈网络等模块。推理时，数据是从第一层依次流向最后一层，层与层之间是串行关系。

这个串行特性给了分层加载可乘之机。既然计算是逐层进行的，那完全没必要让所有层同时待在显存里。airllm 的做法是：把每一层的权重单独存成一个文件，推理到第 N 层时，才把第 N 层的权重从磁盘加载到显存，算完立刻释放，接着加载第 N+1 层。

用一个生活化的类比：这就像你要做一道需要几十种调料的菜，但厨房台面（显存）只放得下两三种。传统做法是把所有调料都堆在台面上，台面不够就做不了。airllm 的做法是每次只从橱柜（磁盘）里拿当前要用的那一种，用完放回去再拿下一种。台面永远够用，代价是来回跑橱柜的次数多了。

2.3 显存与磁盘的权衡账

这里有一笔账要算清楚。假设一个 70B 模型，FP16 精度下总权重大约 140GB。如果切成 80 层，每层大约 1.75GB。那么推理时显存里同时只需要容纳一层权重加上激活值、KV Cache 等开销，峰值显存可能控制在 4GB 到 6GB 左右。这就是为什么 8GB 显存的卡也能跑起来。

但磁盘这边压力就大了。每生成一个 token，都要把所有层完整过一遍，也就是要把 140GB 的权重从磁盘读一遍。如果磁盘读取速度是 2GB/s，光读权重就要 70 秒。这还没算计算时间。所以 airllm 的速度瓶颈几乎完全在磁盘 IO 上，这也是为什么官方反复强调要用高速固态硬盘。

提示：机械硬盘基本不用考虑，读取速度会成为灾难级瓶颈。NVMe 固态是底线，读取速度越快，整体推理速度提升越明显。

2.4 与其它显存优化方案的对比

除了量化和分层加载，还有几种常见的显存优化手段，放在一起对比更清楚 airllm 的位置。

梯度检查点主要用于训练阶段，推理阶段用处不大。模型并行需要多张卡，门槛高。所以对于单卡用户来说，真正可选的其实就是量化和分层加载两条路。airllm 把分层加载这条路走通了、封装好了，这是它的核心价值。

3. 核心细节解析与实操要点

3.1 模型分片是怎么切出来的

airllm 在第一次加载模型时，会做一件重要的事情：把原始的大模型文件拆分成按层组织的多个小文件。这个过程叫分片或者切片。它会读取模型的权重文件，按照层的边界把权重切分开，每一层存成一个独立的文件，同时保存一份索引记录每层对应的文件位置。

这个分片过程只需要做一次。第一次运行会慢一些，因为要读取完整的模型并重新写入磁盘，之后再用就直接读分片好的文件，省去了重复切分的开销。分片后的文件通常放在一个专门的缓存目录里，你可以指定这个目录的位置。

这里有个实操要点：分片目录最好放在读取速度最快的磁盘上。如果你系统盘是 NVMe 而数据盘是机械盘，一定要把分片目录指到系统盘。我见过有人把分片放在机械盘上，结果推理速度慢到怀疑人生，排查半天才发现是磁盘的问题。

3.2 压缩选项的取舍

airllm 提供了可选的压缩功能，可以在分片时对权重做压缩，进一步减小磁盘占用。这个功能对磁盘空间紧张的人有用，但要注意它和量化不是一回事。这里的压缩主要是为了减少磁盘占用和 IO 数据量，解压后权重精度不变。

压缩的代价是每次加载都要解压，会消耗一点 CPU 时间。如果你的 CPU 比较弱，或者磁盘空间充足，可以不开压缩。如果磁盘紧张，或者想通过减少 IO 数据量来提速，可以开启。实测下来，压缩对速度的影响是双向的：IO 数据量小了可能更快，但解压本身要花时间，最终效果取决于你的 CPU 和磁盘哪个是瓶颈。

3.3 分层加载的显存占用估算

很多人关心到底需要多少显存。这里给一个粗略的估算方法。假设模型有 L 层，总参数量为 P，FP16 精度下每参数占 2 字节，那么单层权重大约是 2P/L 字节。显存峰值大致等于单层权重加上激活值和 KV Cache 的开销。

以 70B 模型、80 层为例，单层权重约 1.75GB。激活值和 KV Cache 取决于你的上下文长度和 batch size，短上下文下可能 1GB 到 2GB。所以峰值显存大概在 3GB 到 4GB。留点余量，8GB 显存的卡跑起来是比较从容的。

但要注意，如果你把上下文设得很长，KV Cache 会线性增长，显存占用也会水涨船高。所以分层加载虽然省显存，但也不是无底洞，长上下文场景还是要留意。

3.4 推理速度的影响因素

前面说了速度瓶颈在磁盘 IO，但实际情况更复杂一些。影响速度的因素主要有这么几个：

• 磁盘读取速度：这是最关键的。NVMe 固态能到 3GB/s 以上，SATA 固态大概 500MB/s，机械盘可能只有 100MB/s 出头。差距是数量级的。
• 模型层数和总参数量：层数越多、参数越大，每生成一个 token 要读的数据越多，自然越慢。
• CPU 解压能力：如果开了压缩，CPU 要负责解压，弱 CPU 会成为瓶颈。
• 显存带宽：权重加载进显存后，计算过程受显存带宽影响，但这个通常不是主要瓶颈。

理解这些因素，你就能判断自己的配置大概能跑到什么速度，以及该往哪个方向优化。

4. 实操过程与核心环节实现

4.1 环境准备与依赖安装

先把基础环境搭起来。airllm 是 Python 包，通过 pip 安装即可。建议用独立的虚拟环境，避免和系统里的其它包冲突。

python -m venv airllm_env source airllm_env/bin/activate pip install airllm

如果你要用 GPU 加速，需要确保 PyTorch 的 CUDA 版本和你的显卡驱动匹配。这一步很多人会踩坑，装了个 CPU 版的 PyTorch，结果跑起来发现用的是 CPU，慢得离谱。装完后可以用一行代码验证 CUDA 是否可用：

import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))

输出 True 和你的显卡型号，说明 GPU 环境没问题。如果输出 False，就要检查 PyTorch 版本和驱动了。

4.2 加载模型与首次分片

环境好了就可以加载模型。airllm 的接口设计得很简洁，基本就是把 HuggingFace 的模型名传进去。

from airllm import AutoModel model = AutoModel.from_pretrained("模型名称或本地路径")

第一次加载时，它会自动做分片。这个过程会读取完整的模型权重，按层切分后写入缓存目录。如果你的模型是从网上下载的，这一步还会包含下载时间。分片完成后，后续加载就直接用分片文件，快很多。

分片目录默认在用户目录下的某个缓存路径，你可以通过参数指定到别的位置。我建议显式指定到一个高速固态盘上的目录，避免默认路径落在慢盘上。

model = AutoModel.from_pretrained( "模型名称或本地路径", layer_shards_saving_path="/你的高速固态盘/airllm_cache" )

4.3 执行推理与参数设置

模型加载好后就可以推理了。airllm 的推理接口和 HuggingFace 的用法类似，构造输入、调用生成、解码输出。

input_text = "你的提示词" input_ids = model.tokenizer( [input_text], return_tensors="pt", return_attention_mask=False ).input_ids output = model.generate( input_ids, max_new_tokens=128, do_sample=False ) output_text = model.tokenizer.decode(output[0]) print(output_text)

这里有几个参数值得注意。max_new_tokens控制生成的最大长度，设得越大生成时间越长，因为每多生成一个 token 就要把所有层再过一遍。do_sample控制是否采样，设为 False 就是贪心解码，输出更确定，适合测试。实际使用中可以根据需要调整。

4.4 速度实测与预期管理

我拿一个中等规模的模型在 NVMe 固态上做过测试，生成速度大概在每秒几个 token 的量级。这个速度用来做交互式对话会比较煎熬，但用来做批量的文本处理、离线生成任务是可以接受的。

这里要给大家做个预期管理。airllm 的速度和“模型全部驻留显存”的推理完全不在一个量级。后者可能每秒几十个 token，airllm 可能只有它的十分之一甚至更低。所以如果你的场景对实时性要求高，airllm 可能不是最佳选择。但如果你只是偶尔跑跑、或者做离线任务，这个速度是可以忍的。

提示：第一次跑建议先用小模型验证流程通不通，别一上来就上最大的模型。小模型分片快、加载快，能让你快速确认环境没问题，再换大模型。

4.5 批量推理的注意事项

如果你要处理多条输入，不要一条一条循环调用。airllm 支持批量输入，把多条文本组成一个列表传进去，可以摊薄每层的加载开销。因为加载一层权重后，可以同时处理这一层上的多个样本，IO 成本被分摊了。

input_texts = ["第一条输入", "第二条输入", "第三条输入"] input_ids = model.tokenizer( input_texts, return_tensors="pt", padding=True, return_attention_mask=False ).input_ids output = model.generate(input_ids, max_new_tokens=64)

批量大小要看你显存能承受多少。批量越大，激活值和 KV Cache 占用越多，显存压力越大。找到一个平衡点，既能摊薄 IO 又不至于爆显存。

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

5.1 加载报错与依赖冲突

最常见的问题是加载模型时报错，提示缺少某个依赖或者版本不兼容。airllm 依赖 transformers、torch 等库，这些库的版本之间有时会有冲突。遇到这种情况，先看报错信息里提到的库和版本，然后针对性调整。

一个实用的排查思路是：先在一个干净的环境里只装 airllm，让它自己拉取兼容的依赖版本，不要手动装一堆可能冲突的包。如果确实需要特定版本的某个库，再单独处理。

5.2 显存不足的排查

虽然 airllm 已经大幅降低了显存需求，但配置不当还是可能爆显存。常见原因有几个：批量设得太大、上下文太长、或者模型本身单层就很大。

排查方法是逐步减小批量大小和上下文长度，看显存占用变化。如果减小到 1 和很短的上下文还是爆，那可能是模型单层权重就超过了你的显存，这种情况只能换更小的模型或者用更激进的压缩。

5.3 速度异常缓慢的定位

速度慢是最常见的问题，但原因可能不同。定位方法是从磁盘、CPU、GPU 三个方向逐一排查。

先看磁盘。用系统工具监控推理时的磁盘读取速度，如果远低于磁盘标称速度，可能是磁盘本身慢或者有其它程序在抢 IO。再看 CPU，如果开了压缩，看 CPU 占用是不是满了，满了说明解压是瓶颈。最后看 GPU，如果 GPU 利用率很低，说明大部分时间在等数据，瓶颈在 IO 侧。

5.4 常见问题速查表

5.5 几个踩坑经验

第一个坑是分片目录的位置。默认路径可能在你没注意的慢盘上，一定要显式指定到高速盘。我一开始没注意，跑得慢还以为是模型太大，后来发现是分片存在了机械盘上。

第二个坑是第一次运行的耐心。首次分片要读取完整模型并重写，大模型可能要花不少时间。别以为卡死了就中断，中断了下次还得重来。找个空闲时间让它跑完。

第三个坑是别用太老的显卡驱动。有些新版本的 PyTorch 对驱动版本有要求，驱动太老可能导致 CUDA 不可用或者运行不稳定。保持驱动相对新一点，能省不少麻烦。

第四个坑是内存也要够。分层加载虽然省显存，但系统内存还是要能装下解压后的数据。如果系统内存太小，可能会用交换分区，那速度就彻底崩了。建议系统内存至少和模型大小相当。

6. 这套方案还能怎么用

airllm 的价值不只是“让单卡能跑大模型”，它打开了一些之前被显存门槛挡住的玩法。比如你可以在本地做模型的对比测试，同时准备几个不同的大模型，需要哪个加载哪个，不用为了跑一个模型去租昂贵的多卡机器。再比如做离线数据标注，用大模型批量处理文本，速度慢点没关系，反正挂着跑就行。

从技术演进的角度看，分层加载这个思路还有优化空间。比如预取，在计算第 N 层的时候提前把第 N+1 层读进来，用计算时间掩盖 IO 时间。再比如把常用的层缓存在显存里，减少重复读取。这些方向社区里都有人在尝试，未来速度应该还有提升空间。

我个人在实际操作中的体会是，airllm 最适合的场景是“偶尔用用大模型、但不想为此投入多卡硬件”的开发者。它用速度换来了门槛的降低，这个交换对很多人来说是划算的。你要做的，就是搞清楚自己的场景更看重什么，然后决定要不要接受这个交换。如果接受，把磁盘和内存配好，它能稳定地帮你把大模型跑起来。