企业官网建设流程全解析

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

第一次看到 airllm 这个项目的时候，我正在一台只有单张消费级显卡的机器上折腾一个 70B 级别的模型。显存报错刷了满屏，那种感觉就像你买了一整头牛，结果发现家里的锅只能装下一块牛排。airllm 这个标题背后指向的核心，就是用极低的显存把超大参数量的语言模型跑起来，它解决的不是训练问题，而是推理阶段的显存墙问题。

说白了，airllm 做的事情是让一个原本需要多张高端卡才能装下的模型，在单张卡甚至显存很有限的卡上完成推理。它的目标用户很明确：手里只有一张卡、但想跑大模型的开发者，做本地推理验证的研究者，以及想在边缘设备上部署模型但被显存劝退的工程人员。哪怕你是个刚入门的新手，只要你能跑通一个普通的模型推理脚本，这篇文章里的思路和操作你都能跟着复现。

我先把结论摆在前面：airllm 的核心思路不是把模型变小，而是把模型分层拆开，让每一层在需要的时候才被加载进显存，用完就释放。这个思路听起来简单，但真正落地要解决一堆工程细节，比如层与层之间的数据怎么传递、磁盘 IO 怎么不拖垮速度、量化怎么配合、缓存怎么设计。下面我会把这些东西一层层拆开讲清楚，包括我自己踩过的坑和实测下来的参数选择。

2. 核心思路拆解：为什么是分层加载而不是量化压缩

2.1 显存墙的本质：参数量与显存的关系

要理解 airllm 为什么这么做，得先算一笔账。一个模型在推理时占用的显存，主要来自三部分：模型权重、激活值（中间计算结果）、以及 KV Cache。其中权重是大头。以 FP16 精度为例，每个参数占 2 字节，一个 70B 参数的模型，光权重就是 70 × 10^9 × 2 字节，约等于 140GB。这还没算激活和缓存，一张 24GB 显存的卡根本装不下。

传统的解法有两条路。第一条是量化，把 FP16 压到 INT8 甚至 INT4，权重体积能降到原来的四分之一甚至八分之一，70B 模型 INT4 之后大约 35GB，还是超过 24GB。第二条是模型并行，把模型切到多张卡上，但这要求你有足够多的卡，成本和门槛都上去了。

airllm 走的是第三条路：不改变模型精度，而是改变权重的驻留策略。它把模型按层切分，每一层的权重单独存放在磁盘上，推理时只把当前需要的那一层读进显存，算完就释放，再读下一层。这样一来，显存里同时只存在一层的权重，峰值显存占用大幅下降。

2.2 分层加载的代价与取舍

这个方案不是没有代价的。最大的代价是磁盘 IO 变成了瓶颈。原本权重都在显存里，读取是纳秒级；现在每算一层都要从磁盘读一次权重，如果是机械硬盘，那速度会慢到让你怀疑人生。所以 airllm 在实际使用中强烈依赖高速存储，SSD 是基本要求，NVMe 更好。

第二个代价是层间数据传递。模型是一层接一层算的，上一层的输出要作为下一层的输入。如果每层权重加载完就释放，那中间结果必须保留在显存或内存里。airllm 的做法是把中间激活值留在显存，只把权重做换入换出，这样避免了频繁搬运激活值带来的额外开销。

第三个取舍是速度与显存的平衡。你可以选择一次预读多层，减少 IO 次数，但显存占用会上升；也可以选择每次只读一层，显存最省，但 IO 最频繁。airllm 提供了配置项让你在这两者之间调节，后面我会讲具体怎么调。

这里有个常见的误解：很多人以为 airllm 是某种量化技术，其实它和量化是正交的。你完全可以在 airllm 的基础上再叠加量化，进一步降低显存和 IO 压力。

2.3 和量化方案的本质区别

量化是从数值精度上做减法，把每个参数的表示位数减少，代价是精度损失。airllm 是从驻留策略上做调度，参数的精度不变，只是不在显存里常驻。这两者的适用场景不同：如果你追求极致速度且能接受精度损失，量化更合适；如果你要保精度、显存又实在不够，airllm 更合适。

我实测下来的感受是，airllm 更适合做验证性推理和低频调用，比如你想确认一个 70B 模型在你的任务上效果如何，跑几条样本看看，这个场景下速度慢一点可以接受。但如果你要做高并发的在线服务，airllm 的 IO 开销会成为硬伤，这时候还是得靠多卡或者量化。

3. 核心细节解析：分层加载背后的工程实现

3.1 模型切分与权重落盘

airllm 的第一步是把模型权重从原来的单文件或分片文件，重新组织成按层存储的格式。原始的大模型权重通常是一个或几个大的 safetensors 或 bin 文件，里面按参数名存放所有层的权重。airllm 会读取这些文件，然后按照层的顺序，把每一层的权重单独写成一个文件，存到指定的目录下。

这个过程的意图很明确：让每一层的权重在物理上就是独立的，这样加载的时候只需要读对应的那个文件，不用把整个模型文件都映射进来。我试过在一个 70B 模型上做这个切分，切完之后目录里会有几十到上百个文件，每个文件对应一层或几层。

这里有个细节要注意：切分后的目录会占用和原模型差不多的磁盘空间，因为权重是复制出来的，不是移动。所以你得预留足够的磁盘。如果磁盘紧张，可以在切分完成后删掉原始权重文件，但建议先确认切分后的模型能正常加载再删。

3.2 推理时的层调度逻辑

推理开始后，airllm 的调度逻辑大致是这样的：先加载嵌入层，把输入 token 转成向量；然后进入 Transformer 层循环，每一层从磁盘读取权重到显存，执行前向计算，计算完成后释放这一层的权重；最后经过输出层得到 logits。

这个循环里最关键的是权重加载和计算的重叠。如果老老实实等一层权重完全加载完再算，那 GPU 会有大量时间在等 IO。airllm 的做法是尽量让加载和计算流水线化，比如在算第 N 层的时候，预读第 N+1 层的权重。这个预读的层数就是前面提到的可调参数。

我实测下来，预读层数设成 1 到 2 是比较稳妥的。设成 0 就是完全不预读，速度最慢但显存最省；设成 3 以上，显存占用会明显上升，而且如果 IO 速度跟不上，预读的权重还得在显存里等着，反而浪费。

3.3 量化与压缩的配合方式

airllm 本身支持在加载权重时做量化。也就是说，磁盘上存的是 FP16 权重，读进显存的时候转成 INT8 或 INT4。这样做的好处是磁盘占用不变，但显存占用和计算量都降下来了。

不过这里有个权衡：量化转换本身需要计算，如果每层都做一次转换，会增加额外开销。我的建议是，如果你的显存实在紧张，可以开启量化；如果显存够用，就保持 FP16，省掉转换的开销。另外，量化后的精度损失在分层加载的场景下会被放大，因为每层都独立量化，误差会累积，这一点要有心理预期。

3.4 缓存机制的设计

airllm 还引入了一个缓存机制，用来减少重复的 IO。具体来说，如果某些层在多次推理中被反复使用，可以把这些层的权重缓存在显存或内存里，不用每次都从磁盘读。这个机制对于多轮对话场景特别有用，因为对话的很多层计算是重复的。

缓存的容量需要根据你的显存和内存来定。缓存太小起不到作用，缓存太大又会挤占本来就不多的显存。我的经验是，先把缓存关掉跑一遍，看看峰值显存和速度，然后逐步增加缓存容量，找到一个速度和显存的平衡点。

4. 实操过程：从零跑通一个分层加载的推理

4.1 环境准备与依赖安装

先把基础环境搭起来。你需要一台有独立显卡的机器，显卡显存不限，但建议至少 8GB 以上，太小的话连单层权重都装不下。存储方面，强烈建议用 NVMe SSD，机械硬盘基本没法用。内存建议 32GB 以上，因为中间激活值和缓存会占用不少内存。

依赖安装这块，核心是深度学习框架和 airllm 本身。我用的是 PyTorch 配合 CUDA，版本要和你显卡驱动匹配。安装命令大致如下：

pip install torch --index-url https://download.pytorch.org/whl/cu118 pip install airllm pip install transformers accelerate safetensors

注意：CUDA 版本一定要和你的驱动对应，版本不匹配会直接报错。装完之后用torch.cuda.is_available()确认一下 GPU 能被识别。

4.2 模型切分与目录组织

环境好了之后，第一步是把模型切分。假设你已经从模型仓库下载了原始权重，放在某个目录下。切分的操作通常是调用 airllm 提供的接口，指定原始模型路径和切分后的输出路径。

from airllm import AutoModel model = AutoModel.from_pretrained( "your-model-path", layer_shards_saving_path="/path/to/sharded_model" )

这段代码会读取原始权重，按层切分后写到指定目录。切分过程比较耗时，70B 模型可能要几十分钟到几个小时，取决于磁盘速度。切分的时候可以观察输出目录，文件会一个个出现，每个文件对应一层。

切分完成后，建议先检查一下文件数量和大小是否合理。一般来说，层数越多，文件越多。如果发现文件数量明显不对，可能是切分过程中断了，需要重新来。

4.3 推理参数配置与首次运行

切分完成后就可以做推理了。推理时的关键参数有几个：预读层数、是否量化、缓存大小、最大生成长度。我一般会先用一组保守参数跑通，再逐步调优。

from airllm import AutoModel model = AutoModel.from_pretrained( "/path/to/sharded_model", max_seq_len=512, layer_shards_saving_path="/path/to/sharded_model", compression="4bit", prefetching=True ) input_text = ["请用一句话解释什么是分层加载。"] input_tokens = model.tokenizer( input_text, return_tensors="pt", return_attention_mask=False, truncation=True, max_length=512 ).input_ids.cuda() generation_output = model.generate( input_tokens, max_new_tokens=64, use_cache=True, return_dict_in_generate=True ) print(model.tokenizer.decode(generation_output.sequences[0]))

第一次运行的时候，你会看到显存占用曲线是锯齿状的：加载一层，显存上升；算完释放，显存下降；再加载下一层，再上升。这个锯齿就是分层加载的典型特征。如果显存曲线是平的，那说明权重没有真正释放，需要检查配置。

4.4 速度与显存的实测记录

我在一张 24GB 显存的卡上跑一个 70B 模型，用 4bit 量化加分层加载，峰值显存大概在 10GB 左右，留了不少余量。速度方面，生成 64 个 token 大概需要几十秒，平均下来每个 token 接近一秒。这个速度确实不快，但考虑到是在单卡上跑 70B，已经算是能用了。

如果不做量化，峰值显存会上升到 18GB 左右，速度会快一些，因为省掉了量化转换的开销。如果关掉预读，显存能再降 2GB 左右，但速度会慢 20% 到 30%。这些数字不是绝对的，和你的磁盘速度、CPU、内存都有关系，但量级上可以作为参考。

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

5.1 加载报错与路径问题

最常见的问题是路径写错。切分后的模型目录和原始模型目录是两个不同的东西，推理时要指向切分后的目录。如果指向了原始目录，airllm 会尝试重新切分，或者直接报错找不到层文件。

另一个常见问题是权限。如果切分目录没有写权限，切分会失败；如果推理时没有读权限，加载会失败。这类问题排查起来很简单，看一眼报错信息里的路径，手动去那个路径下确认文件是否存在、权限是否正确。

5.2 显存溢出与释放失败

显存溢出通常发生在两个地方：一是单层权重太大，加载进来就爆了；二是缓存或激活值累积，把显存吃光了。前者需要开启量化或者换更小的模型；后者需要调小缓存、调小 max_seq_len，或者关掉预读。

释放失败的表现是显存曲线一直上升不下降。这通常是因为某些张量被意外持有，没有释放。排查方法是检查代码里有没有全局变量持有中间结果，或者有没有在循环里不断往列表里塞张量。PyTorch 的显存管理有时候会有碎片，可以用torch.cuda.empty_cache()手动清理一下，但不要频繁调用，会影响性能。

5.3 速度过慢的优化方向

速度慢的原因基本可以归为三类：磁盘 IO 慢、预读没生效、量化转换开销大。磁盘 IO 慢的话，换 NVMe SSD 是最直接的；预读没生效的话，检查配置里 prefetching 是不是打开了；量化开销大的话，可以试试关掉量化，看看速度是不是反而快了。

还有一个容易被忽略的点是CPU 到 GPU 的数据传输。如果权重是先读到内存再传到显存，那内存带宽和 PCIe 带宽都会成为瓶颈。airllm 在这方面做了优化，尽量直接从磁盘读到显存，但具体效果取决于实现和硬件。

5.4 常见问题速查表

我个人踩过最坑的一次是切分目录和原始目录放在同一个磁盘分区，切分过程中磁盘满了，切分中断但没报错，结果推理时加载到一半失败。后来我把切分目录单独放到一个大容量 SSD 上，问题就没了。所以磁盘空间一定要提前规划好。

6. 这套方案还能怎么扩展

airllm 的分层加载思路其实可以延伸到很多场景。比如你可以把不同层的权重放在不同的存储介质上，热层放 SSD，冷层放普通硬盘，进一步降低成本。也可以结合模型剪枝，把不重要的层直接跳过，减少加载次数。

另一个方向是和推理服务框架结合。airllm 目前更偏向单次推理，如果要做成服务，需要自己包一层请求队列和批处理逻辑。批处理能摊薄 IO 开销，因为一次加载的权重可以服务多个请求。这个思路我在一个小规模内部工具上试过，效果还不错，但要注意批处理会增大激活值显存，需要重新平衡参数。

最后再分享一个小技巧：如果你只是想做效果验证，不需要完整生成，可以把 max_new_tokens 设得很小，比如 16 或 32，这样能快速看到模型对输入的反应，节省大量时间。等确认模型没问题了，再放开长度做完整生成。这个习惯帮我省下了不少等待时间。