1. 单卡跑大模型这件事到底卡在哪第一次看到 airllm 这个项目的时候我正在一台只有单张消费级显卡的机器上折腾一个 70B 级别的模型。显存报错几乎是必然的OOM 的红色提示刷了满屏那种感觉就像你明明有一整柜的书却只有一张巴掌大的书桌想同时摊开三本书都做不到。airllm 想解决的就是这个矛盾让显存不够的普通设备也能把参数量远超显存容量的大模型跑起来。它的核心思路并不神秘一句话概括就是用时间换空间——把模型按层切开需要哪一层就把哪一层加载进显存算完立刻释放再加载下一层。听起来简单但真正落地要处理一堆细节怎么切、什么时候加载、怎么避免反复读写拖垮速度、量化怎么配合、不同模型结构怎么兼容。airllm 把这些脏活累活封装成了一个相对好用的接口让单卡推理大模型从一句口号变成了能跑通的工程方案。这篇文章适合几类人看手里只有一张显存不大的卡、却想本地跑大模型的开发者想理解分层加载推理原理、准备自己造轮子的工程师以及被 OOM 折磨过、想找个务实方案先把东西跑起来的人。我不会只讲它怎么用更想讲清楚它为什么这么设计、每一步背后的取舍以及我在实际跑的时候踩过的那些坑。毕竟这类工具官方文档告诉你能跑但真正让你跑顺的往往是文档里没写的那些经验。2. 分层加载推理的整体设计与取舍逻辑2.1 为什么是分层而不是分片大模型推理吃显存主要吃在两块模型权重和中间激活值。一个 70B 的模型光权重用 FP16 存就要 140GB 左右这还没算 KV Cache 和激活。普通消费卡动辄 8G、12G、24G差距是数量级的。面对这个差距业界有几条路。一条是模型并行/张量并行把权重切到多张卡上但前提是你得有多张卡单卡场景直接出局。另一条是量化把 FP16 压到 INT8、INT4能省 2 到 4 倍但 70B 压到 INT4 也还有 35GB 左右单张 24G 卡依然放不下。还有一条就是 airllm 走的分层加载不要求所有权重同时驻留显存而是把模型按 Transformer 的层layer拆开一次只让一层待在显存里。为什么按层切是最自然的因为 Transformer 的结构本身就是层叠的第 N 层的输出就是第 N1 层的输入层与层之间是严格的串行依赖。这意味着你算完第 N 层它的权重就再也用不到了可以安全释放。这种串行、无回溯的特性让分层加载在逻辑上非常干净——不需要复杂的调度只要按顺序来就行。代价也很明确每一层都要从存储内存或磁盘搬到显存算完再搬走。如果模型放在内存里这个搬运是内存到显存的拷贝如果内存也放不下就得放磁盘那就是磁盘 IO。搬运本身不产生计算价值纯粹是开销所以分层加载的推理速度一定比全量驻留显存慢。这就是用时间换空间的字面含义。2.2 内存、显存、磁盘三级存储的权衡airllm 实际运行时权重可以放在三个地方对应三种速度和容量组合理解这个分层是理解整个方案的关键。存储位置容量访问速度适用场景显存最小8-24G 常见极快当前正在计算的那一层内存中等32-128G 常见较快存放全部或部分层权重磁盘最大TB 级慢内存也放不下时的兜底最理想的配置是权重全放内存逐层搬进显存。这样每层的加载是内存到显存的拷贝速度可以接受整体推理虽然慢于全量驻留但还在可用范围。我实测过一个 13B 的模型权重 FP16 约 26GB放在 64G 内存的机器上逐层加载到 12G 显存单次生成的速度大概是全量驻留的几分之一但确实能跑而且不 OOM。如果内存也不够airllm 支持把权重存到磁盘运行时从磁盘读。这时候瓶颈就变成磁盘 IO 了机械硬盘基本没法用NVMe 固态勉强能撑。我的建议是能用内存就别用磁盘磁盘方案是最后的兜底不是常规选择。很多人一上来就把模型丢磁盘然后抱怨慢得没法用其实是没搞清楚瓶颈在哪。2.3 量化在分层方案里的角色分层加载解决的是放不下的问题量化解决的是放得下但想更快的问题。两者是正交的可以叠加。airllm 支持在分层的基础上做量化常见的是 4bit 量化。量化在这里的价值有两层。第一层是减小每层的体积让单层加载更快、占用显存更少这样即使是显存很小的卡也能容纳单层。第二层是减小总存储占用让更多层能塞进内存减少磁盘 IO 的概率。一个 70B 模型 FP16 是 140GB4bit 量化后大约 35GB这个体积放进 64G 内存就轻松多了整个方案从磁盘兜底升级成内存驻留速度提升是数量级的。但量化不是免费的。4bit 量化会带来一定的精度损失具体损失多少取决于量化方法和模型本身。我的经验是对于生成类任务4bit 量化的质量下降通常可以接受但对于需要精确数值推理的任务就要谨慎。airllm 里量化是可选配置我一般建议先用 FP16 跑通流程确认没问题再上量化压体积。2.4 这套方案不适合什么场景任何方案都有边界分层加载也不例外说清楚它不适合什么比吹它能做什么更有价值。不适合高并发服务。分层加载的推理是串行的一次只能处理一个请求的一层吞吐量天然上不去。如果你要做一个面向很多用户的在线服务这套方案基本不适用那是 vLLM 这类专注吞吐的框架的战场。不适合低延迟交互。因为每层都要搬运首 token 延迟和生成速度都比全量驻留慢。如果你追求的是秒回那得先把模型塞进显存或者用更小的模型。不适合频繁切换模型。每次切换都要重新加载权重开销很大。它更适合选定一个模型长时间反复用的场景。反过来它最适合的是个人开发者、研究场景、本地实验、显存受限但想跑大模型。这些场景对吞吐和延迟不敏感对能不能跑起来极度敏感正好是分层加载的甜区。3. 核心机制拆解与关键实操要点3.1 模型是怎么被切开的要理解 airllm 怎么工作得先知道它切的是什么。以常见的 Transformer 解码器结构为例一个模型大致是这样组织的嵌入层、若干个结构相同的解码器层每层包含自注意力、前馈网络、若干归一化、最后的输出层。airllm 主要切的是中间那一堆重复的解码器层因为它们是模型体积的绝对大头而且结构规整、便于逐个处理。切分发生在模型加载阶段。airllm 会把每一层的权重单独保存成一个文件或内存块并记录层的顺序。推理时它维护一个当前层的指针按顺序把层加载进来、计算、释放。这个过程的本质是把一个整体加载的模型改造成一个流式加载的模型。这里有个容易忽略的细节不是所有部分都适合分层。嵌入层和输出层通常只加载一次因为它们要么在开头要么在结尾且往往和词表大小相关体积相对固定。真正需要逐层流式处理的是中间的解码器层。理解这个区分对排查问题很有帮助——如果报错发生在嵌入层那多半不是分层逻辑的问题而是模型格式或词表的问题。3.2 逐层加载的执行流程把整个推理流程拆开看大概是这么几步我按实际执行的顺序讲。第一步是模型准备。首次使用时airllm 会把原始模型转换成它自己的分层格式这个过程叫切分或拆分。它读取原始权重按层切好保存到指定目录。这一步只做一次之后复用。切分后的目录里每一层是独立的文件还有一个描述层结构的元数据文件。第二步是推理初始化。加载元数据确定层数、每层的结构、量化配置等。这时候不会把所有层都读进来只准备好调度逻辑。第三步是逐层前向。对于输入先过嵌入层得到初始隐藏状态然后进入循环加载第 0 层权重到显存计算释放加载第 1 层计算释放以此类推直到最后一层。每层的计算就是标准的 Transformer 层前向没什么特殊。第四步是输出处理。最后一层的输出经过输出层和采样逻辑得到下一个 token然后进入下一轮生成。生成是自回归的每生成一个 token 都要把所有层再走一遍所以层数越多、生成越长总耗时越大。这个流程里加载和释放的时机是关键。加载太早会占着显存不放加载太晚会让计算等 IO。airllm 内部做了预取优化会在计算当前层的同时异步加载下一层把 IO 和计算重叠起来。这个优化对速度影响很大也是它比朴素逐层加载快的原因之一。3.3 量化配置怎么选量化配置是 airllm 里最需要动脑的地方选错了要么跑不动要么质量崩。我把它拆成几个决策点。要不要量化。如果内存足够放下 FP16 的全部权重优先不量化质量最好。如果内存不够或者想留出余量给其他程序那就量化。判断标准很简单算一下模型 FP16 的体积和你的可用内存比一比。量化到几位。常见的是 4bit 和 8bit。8bit 质量损失小体积减半4bit 体积减到约四分之一质量损失相对明显但通常可接受。我的建议是先用 8bit如果还是放不下再上 4bit。不要一上来就 4bit除非你明确知道质量损失可接受。量化方法。不同量化方法在精度和速度上各有侧重airllm 通常集成了几种常见方案。选择时看两点一是你的硬件是否支持对应的加速指令二是该方法在你的任务上实测的质量。这个没有万能答案得自己试。提示量化后的模型体积估算有个粗略公式——参数量 × 位数 / 8。比如 70B 参数、4bit约等于 70 × 10^9 × 4 / 8 字节约 35GB。用这个公式可以快速判断你的内存够不够。3.4 存储路径与 IO 优化存储路径的选择直接决定速度上限这块值得单独说。优先放内存盘。如果机器内存足够大可以把切分后的模型放到内存文件系统比如 Linux 下的 tmpfs里这样磁盘读取实际上变成了内存读取速度飞快。代价是内存被占用重启后丢失需要重新切分。对于反复使用的场景这个投入很值。其次放 NVMe 固态。如果内存不够至少要用 NVMe 固态别用机械硬盘。机械硬盘的随机读性能太差逐层加载会慢到无法忍受。顺序读机械盘还行但分层加载的访问模式更接近随机读所以固态是底线。避免网络存储。把模型放在网络挂载的存储上逐层加载会引入网络延迟速度会惨不忍睹。除非是万兆内网加高速缓存否则不要这么干。切分目录和运行目录分开。切分后的模型是只读的可以放在一个稳定的位置运行时产生的临时文件、缓存放在另一个位置避免互相干扰也方便清理。4. 从零跑通一个分层推理的完整过程4.1 环境准备与依赖确认动手之前先把环境理清楚能省掉后面一大堆莫名其妙的报错。硬件底线。一张支持 CUDA 的显卡是必须的显存大小决定了单层能不能放下。一般来说单层体积 模型总参数 / 层数 × 每参数字节数。比如 70B 模型 80 层FP16 每参数 2 字节单层约 70e9 / 80 × 2 ≈ 1.75GB。加上激活和临时缓冲显存至少要有单层的两三倍才稳妥。所以 8G 显存跑 70B 的分层推理是可行的但会很紧张。软件依赖。Python 环境、PyTorch要和 CUDA 版本匹配、transformers 库、以及 airllm 本身。版本匹配是重灾区PyTorch 和 CUDA 对不上会直接报错transformers 版本太新或太旧也可能和 airllm 不兼容。我的做法是先建一个干净的虚拟环境按 airllm 文档推荐的版本装不要图省事用系统里已有的乱七八糟的环境。磁盘空间。切分后的模型体积和原始模型差不多甚至略大因为多了元数据。所以准备至少 1.5 倍原始模型大小的磁盘空间。如果原始模型是 140GB那就准备 200GB 以上。4.2 模型切分与首次加载环境好了第一步是把模型切成 airllm 能用的格式。这个过程我习惯叫预处理因为它只做一次。from airllm import AutoModel # 指定原始模型路径和切分后的保存路径 model AutoModel.from_pretrained( your-model-path, # 切分后的层保存位置 layer_shards_saving_path/path/to/shards, # 量化配置先不量化跑通流程 compressionNone, )第一次运行这段代码时它会读取原始权重按层切分保存到指定路径。这个过程比较慢取决于模型大小和磁盘速度70B 的模型可能要几十分钟。切分完成后后续再加载就直接用切分好的文件快很多。这里有个坑切分过程中如果中断可能留下不完整的文件。下次加载会报错而且错误信息不一定明确指向文件不完整。遇到奇怪的加载失败先检查切分目录里的文件数量对不对和模型的层数是否匹配。4.3 推理参数配置与生成切分好之后就可以配置推理参数并生成内容了。核心参数有这么几个。max_new_tokens生成的最大 token 数。这个直接决定耗时因为每生成一个 token 都要把所有层走一遍。设太大等得久设太小内容不完整。根据任务需要设一般 128 到 512 之间。compression量化配置。前面讲过先 None 跑通再按需上量化。layer_shards_saving_path切分文件的位置要和切分时一致。一个典型的生成调用大概是这样input_text 请用几句话解释什么是分层加载推理。 input_tokens model.tokenizer( [input_text], return_tensorspt, return_attention_maskFalse, truncationTrue, max_length128, paddingFalse, ).input_ids generation_output model.generate( input_tokens, max_new_tokens128, use_cacheTrue, return_dict_in_generateTrue, ) output model.tokenizer.decode(generation_output.sequences[0]) print(output)跑起来之后你会看到显存占用保持在一个很低的水平不会随着模型大小暴涨这就是分层加载的效果。但生成速度会明显慢于全量驻留这是必然的代价。4.4 速度与显存的实测观察我在一台 12G 显存、64G 内存的机器上跑过一个 13B 的模型FP16 不量化权重全放内存。观察到的现象是显存占用稳定在 3-4G 左右远低于模型体积生成速度大约是每秒几个 token比全量驻留慢了好几倍但确实能连续生成不中断。换成 4bit 量化后内存占用从约 26G 降到约 7G显存占用进一步降低速度略有提升因为每层加载的数据量小了。质量上我让模型做了一些常识问答和文本续写肉眼没看出明显退化但更精细的任务没测。如果内存不够、被迫用磁盘速度会再降一个档次。我试过把切分文件放机械硬盘生成速度慢到几乎不可用换成 NVMe 后才勉强能接受。这个对比很直观地说明了 IO 是瓶颈。注意实测速度受很多因素影响——模型大小、层数、量化、存储介质、CPU 性能、是否开启预取。别人的速度数据只能参考一定要在自己的机器上实测。5. 常见问题与排查技巧实录5.1 加载阶段的典型报错报错一找不到层文件或元数据。这通常是切分没完成或者路径配错了。检查切分目录里有没有元数据文件层文件数量是否和模型层数一致。如果切分中途断过建议删掉重切别试图修补。报错二版本不兼容。表现是导入 airllm 就报错或者加载模型时提示某个函数不存在。这基本是依赖版本问题。解决办法是建干净环境按文档推荐的版本装别混用。报错三显存不足即使单层也放不下。这说明你的显存连一层都容不下。要么换更小的模型要么上量化把单层压小要么换显存更大的卡。没有别的办法这是硬约束。5.2 推理阶段的性能问题问题一速度慢到无法接受。先定位瓶颈在哪。如果显存占用很低但速度慢多半是 IO 瓶颈检查模型是不是放在机械硬盘或网络存储上。如果显存占用接近上限可能是显存不够导致频繁换入换出考虑量化或换卡。问题二生成到一半卡住。可能是某一层加载失败或者内存不足触发了交换。看系统日志检查内存和磁盘使用情况。内存不足时操作系统会疯狂换页表现就是卡顿甚至假死。问题三输出质量差。如果用了量化先怀疑量化。把量化关掉再跑一次对比质量。如果关掉量化质量正常那就是量化损失太大换更温和的量化方法或位数。5.3 一份速查表现象可能原因排查方向加载即报错切分不完整/路径错检查切分目录文件数与元数据导入报错依赖版本冲突建干净环境按推荐版本装单层都放不下显存太小量化或换模型/换卡速度极慢IO 瓶颈换 NVMe 或内存盘生成中断内存不足加内存或量化质量下降量化损失关量化对比换量化方案显存不释放缓存未清理检查是否手动持有引用5.4 几条踩坑心得先小后大。别一上来就拿最大的模型试先用一个小模型比如 7B把整个流程跑通确认环境、切分、推理都没问题再换大模型。这样出问题时容易定位。量化是最后手段。能用 FP16 跑通就别急着量化量化会引入额外变量让排查变复杂。等流程稳定了再考虑量化压体积。内存比显存更关键。很多人只盯着显存其实分层方案里内存才是决定速度的关键。内存够权重全驻留速度尚可内存不够被迫用磁盘速度崩盘。配机器时内存要给足。别频繁重启。每次重启都要重新加载模型开销大。如果要做多轮实验尽量在一个进程里连续跑复用已加载的模型。记录你的配置。模型版本、量化配置、切分路径、依赖版本这些都要记下来。出问题时能快速复现和对比。我吃过亏改了一堆配置后忘了原来能跑的配置是什么白白浪费半天。6. 这套方案还能怎么扩展分层加载推理跑通之后其实还有不少可以深挖的方向。比如预取策略的优化当前层在算的时候提前把下一层甚至下下层加载进来把 IO 和计算重叠得更充分这能明显提升速度。再比如混合精度不同层用不同的精度敏感的层用高精度不敏感的层用低精度在质量和体积之间找更好的平衡。还有一个方向是和缓存机制结合。自回归生成时KV Cache 会随生成长度增长如果能把 KV Cache 也做分层管理进一步压显存那能支持更长的上下文。这块比较复杂但思路是通的。如果你只是想先把东西跑起来那不用想这么多按前面的流程走一遍能生成内容就算成功。等跑顺了再根据实际瓶颈去优化。工程上的事永远是先能用再好用最后才是快。我个人的体会是分层加载这类方案最大的价值不是性能而是把不可能变成了可能——让原本因为显存不够而完全跑不了的大模型至少能跑起来。这个从 0 到 1 的意义比从 1 到 10 的速度优化更实在。