1. 单卡跑大模型这件事到底卡在哪显存不够这件事折腾过本地推理的人都懂。想在一张消费级显卡上跑一个 70B 参数量的模型光是权重加载这一关就过不去——FP16 精度下 70B 模型大约需要 140GB 显存这还没算 KV Cache 和中间激活值。而一张 24GB 显存的卡连零头都装不下。airllm 这个项目就是冲着这个矛盾来的。它的核心思路非常直接既然显存装不下整个模型那就不要一次性装进去。把模型按层切分推理时只把当前需要的层加载到显存里用完就释放下一层再加载。这样显存占用从“整个模型”降到“单层参数”70B 模型在 4GB 显存上跑起来在理论上就成立了。这个方案解决的核心问题是显存墙。它适合手里只有一张消费级显卡、但想跑大参数模型的开发者也适合想理解分层加载推理机制的学习者。代价也很明显——推理速度会大幅下降因为每生成一个 token 都要把所有层重新过一遍层与层之间的加载和卸载成了瓶颈。我实测下来airllm 的定位很清晰它不是用来替代 vLLM 这类高吞吐推理框架的而是在硬件资源极度受限时的一个“能跑起来”的方案。理解这一点后面的所有设计取舍就都说得通了。2. 分层加载的设计逻辑与关键取舍2.1 为什么是“按层切分”而不是别的切法模型并行和流水线并行是常见的两种大模型分布式方案但它们都假设你有多张卡。airllm 面对的是单卡场景所以它选择了按 Transformer 层做粒度切分。Transformer 架构有个天然优势层与层之间是顺序依赖的第 N 层的输出就是第 N1 层的输入不存在跨层的并行计算需求。这意味着你完全可以“加载第 1 层 → 算完 → 卸载第 1 层 → 加载第 2 层”这样串行执行。每一时刻显存里只需要驻留一层参数显存占用就被压到了单层级别。那为什么不切得更细比如按矩阵切因为按层切分的边界最干净。一层内部的注意力计算和前馈网络是紧密耦合的拆开反而引入大量中间状态的搬运开销。按层切每层算完只需要传递一个 hidden states 张量给下一层数据搬运量最小。2.2 分层加载的代价时间换空间这个方案的本质是用磁盘 I/O 和内存带宽换显存。每生成一个 token模型的所有层都要被加载一遍。一个 70B 模型通常有 80 层左右也就是说每生成一个 token 要触发 80 次层的加载。如果模型权重放在普通机械硬盘上每次加载一层可能要几百毫秒80 层就是几十秒一个 token这显然不可接受。所以 airllm 的实际部署中模型权重通常放在 SSD 上甚至用内存映射的方式让操作系统缓存部分层。即便如此速度仍然远低于把整个模型放进显存的做法。这里有个关键参数需要理解层加载的预取策略。如果严格串行——加载第 N 层、算完、再加载第 N1 层——那么计算单元在加载期间是完全空闲的。优化的做法是在计算第 N 层的同时异步预取第 N1 层到显存。airllm 支持配置预取层数预取越多计算和加载的重叠越好但显存占用也会相应增加。预取 1 层意味着显存里同时有 2 层参数预取 2 层就是 3 层。2.3 量化在其中的角色光靠分层加载单层参数量仍然可能超出小显存。比如一个 70B 模型如果某些层特别大单层 FP16 可能就要 1-2GB。airllm 配合量化使用效果更好——把权重压到 4bit 或 8bit单层占用直接降到原来的四分之一到一半。量化和分层加载是互补的量化降低单层体积分层加载降低同时驻留的层数。两者叠加才能让 70B 模型在 4GB 显存上跑起来。不过量化本身会带来精度损失4bit 量化在部分任务上会有可感知的质量下降这个后面会细说。注意分层加载 量化的组合显存占用的计算公式是单层量化后大小 × (1 预取层数) KV Cache 中间激活。估算时别漏掉 KV Cache长上下文场景下它可能比单层参数还大。3. 从零跑通一个分层加载推理的完整过程3.1 环境准备与依赖安装先确认基础环境。Python 版本建议 3.9 以上PyTorch 需要和你的 CUDA 版本匹配。airllm 本身依赖 transformers、accelerate、bitsandbytes 这几个库量化功能靠 bitsandbytes 实现。pip install airllm pip install torch transformers accelerate bitsandbytes安装完先验证一下 bitsandbytes 能否正常调用 GPUimport torch import bitsandbytes as bnb print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))如果torch.cuda.is_available()返回 False说明 CUDA 环境没配好后面所有步骤都跑不通。这一步别跳过我见过太多人卡在这里以为是 airllm 的问题。3.2 模型权重的存放位置选择这是整个方案里最容易被忽视但影响最大的环节。模型权重放在哪里直接决定了推理速度。存放位置加载速度适用场景备注机械硬盘极慢不推荐每层加载数百毫秒基本不可用SATA SSD中等临时测试勉强能跑速度仍不理想NVMe SSD较快推荐方案加载延迟大幅降低内存盘最快内存充足时把权重放 tmpfs速度接近内存带宽我的做法是把模型权重放在 NVMe SSD 上如果内存够大比如 128GB直接开一个 tmpfs 把权重拷进去加载速度会有质的提升。70B 模型 4bit 量化后大约 35GB128GB 内存完全放得下。3.3 核心推理代码的编写与参数说明airllm 的 API 设计得比较简洁核心就是加载模型和调用生成。下面是一段可直接参考的代码from airllm import AutoModel MAX_LENGTH 128 model AutoModel.from_pretrained( 模型路径, compression4bit, layer_shards_saving_path/tmp/airllm_shards ) input_text [请用一句话解释什么是分层加载] input_tokens model.tokenizer( input_text, return_tensorspt, return_attention_maskFalse, truncationTrue, max_lengthMAX_LENGTH, paddingFalse ) generation_output model.generate( input_tokens[input_ids].cuda(), max_new_tokens20, use_cacheTrue, return_dict_in_generateTrue ) output model.tokenizer.decode(generation_output.sequences[0]) print(output)几个参数需要重点说明。compression4bit开启 4bit 量化这是小显存能跑起来的关键。layer_shards_saving_path是分层切片的缓存目录第一次运行会把模型按层切分并保存到这里后续运行直接读缓存省去重复切分的时间。max_new_tokens控制生成长度这个值越大分层加载的次数越多耗时线性增长。use_cacheTrue开启 KV Cache能避免重复计算已生成 token 的注意力对速度有正面影响但会占用额外显存。如果显存实在紧张可以关掉代价是速度进一步下降。3.4 首次运行的切分过程与耗时预期第一次运行 airllm 时它会做一件比较重的事把原始模型权重按层拆分成独立文件。这个过程需要读取整个模型、按层切分、再写回磁盘耗时取决于模型大小和磁盘速度。70B 模型 4bit 量化后约 35GB切分过程在 NVMe SSD 上大概需要十几分钟到半小时。切分完成后layer_shards_saving_path目录下会出现按层编号的文件后续每次推理都直接读这些文件不再重复切分。提示切分目录不要放在会被系统清理的临时目录里否则下次运行又要重新切分。建议放在固定的数据盘路径下。3.5 实测速度与显存占用记录我在一张 8GB 显存的卡上跑了一个 13B 模型4bit 量化记录如下单层参数量约 0.4GB预取层数1峰值显存占用约 1.2GB含 KV Cache 和激活值生成速度约 1.5 token/秒同样的模型如果完整加载到显存生成速度能到 20 token/秒以上。差距是十倍级别这就是分层加载的代价。但关键在于——完整加载根本装不下而分层加载让它跑起来了。换成 70B 模型单层约 0.5GB4bit峰值显存约 1.5GB生成速度降到约 0.3 token/秒。这个速度用来做交互式对话基本不现实但用来做离线批处理或者验证模型效果是够用的。4. 踩过的坑与常见问题排查4.1 显存溢出但报错信息不明确最常见的问题是显存溢出但报错往往指向别的地方比如 CUDA kernel 执行失败或者张量形状不匹配。遇到这类报错先怀疑显存。排查方法在生成前后打印torch.cuda.memory_allocated()和torch.cuda.max_memory_allocated()看峰值是否接近显卡上限。如果接近降低预取层数、缩短max_new_tokens、或者关掉 KV Cache。4.2 生成结果质量下降明显如果开了 4bit 量化后发现输出质量比预期差很多先确认是不是量化导致的。把compression改成8bit对比一下如果 8bit 明显更好说明 4bit 量化对这个模型损伤较大。不同模型对量化的敏感度差异很大。有些模型 4bit 几乎无损有些模型 4bit 后逻辑能力明显下降。这个没有通用规律只能实测。我的经验是参数量越大的模型对量化越鲁棒70B 的 4bit 通常比 13B 的 4bit 质量更好。4.3 首次加载特别慢甚至卡死如果第一次运行卡在切分阶段很久没动静检查两件事磁盘剩余空间是否足够切分后的文件总大小和原模型相当以及切分目录是否有写入权限。另一个可能是模型下载不完整。airllm 依赖 transformers 的模型加载如果模型文件有缺失切分过程会报错。建议先用 transformers 单独加载一次模型确认模型本身没问题再用 airllm。4.4 常见问题速查表现象可能原因解决方向CUDA out of memory预取层数过多或 KV Cache 过大降低预取层数缩短生成长度生成速度极慢权重在机械硬盘或未开量化换 NVMe SSD开启 4bit 量化输出乱码或重复量化损伤或 tokenizer 配置问题换 8bit 对比检查 tokenizer首次运行卡死磁盘空间不足或权限问题检查空间和权限确认模型完整报错找不到层文件切分目录被清理重新切分换固定目录4.5 几个实操中总结的小技巧第一个技巧预热。第一次生成往往比后续慢因为操作系统还没把层文件缓存到内存。可以先跑一次短生成做预热再跑正式任务。第二个技巧批量生成时复用模型对象。不要每次生成都重新from_pretrained模型对象创建一次多次调用generate。切分缓存和部分内存缓存都能复用。第三个技巧监控磁盘 I/O。如果发现生成速度波动很大用系统监控工具看磁盘 I/O 是否打满。如果打满说明瓶颈在磁盘换更快的存储或者把权重放内存盘。第四个技巧长文本场景单独估算 KV Cache。分层加载省的是权重显存但 KV Cache 随上下文长度线性增长。处理长文本时KV Cache 可能成为新的显存瓶颈这时候需要单独考虑 KV Cache 的量化或分页方案。5. 这个方案适合什么、不适合什么airllm 的价值在于它把“不可能”变成了“可能”。在只有一张小显存显卡的情况下它让你能跑起原本完全跑不动的大模型。这个“能跑”本身对很多场景就有意义——比如验证一个模型在特定任务上的表现或者做小批量的离线推理。但它不适合需要高吞吐、低延迟的场景。如果你要做在线服务、要支持多并发、要快速响应分层加载的速度完全不够看。这类场景应该考虑多卡方案或者更专业的推理框架。另外airllm 的分层加载思路本身很有学习价值。理解它之后你会对模型的内存布局、计算与加载的重叠、量化与显存的权衡有更具体的认识。这些认识在优化其他推理方案时同样用得上。我个人在实际操作中的体会是airllm 最适合作为“资源受限下的兜底方案”和“理解大模型推理机制的教学工具”。把它用在合适的场景里它能解决真问题用错场景就会觉得它慢得没法用。判断标准很简单你的任务能不能接受秒级甚至十秒级的单 token 延迟能接受它就能帮你省下一张显卡的钱。