企业官网建设流程全解析

第一次听说 AirLLM 这个项目时，我正好为手头一张老显卡发愁。机器上挂着 8GB 显存的卡，想跑开源 70B 级别的大模型，正常加载 fp16 权重就要 140GB 以上，量化之后也还差着五六十 GB，根本想都不用想。AirLLM 给出的答案很直接：不用换卡，不用改模型代码，只要把模型按层切好，一层一层搬到显存里算，算完就放回内存。这个思路让我眼前一亮，实测下来对低显存玩家来说确实是一条成本最低的路。

到今天 AirLLM 已经是社区里很有代表性的低显存推理方案之一。它的适用人群非常明确：手里只有普通消费级显卡、又想在本地跑开源大模型的技术爱好者、研究者、独立开发者，以及那些想在没有昂贵服务器的环境下完成大模型实验的人。这篇博文我会从原理、实操、报错排查到进阶玩法全部走一遍，尤其会把分层推理为什么能省显存、省在哪里、代价是什么这些关键点讲透。

1. 为什么分层推理能救活手里的显卡：核心思路拆解

1.1 显存瓶颈到底是怎么形成的

要理解分层推理的价值，先得搞清楚大模型推理时显存都花在哪。一个最朴素的事实是：模型权重必须被加载到计算设备上才能参与运算。对于一个 7B 参数的模型，fp16 精度下权重就占 7 × 2 = 14GB；换成 70B 就变成 140GB。市面上大多数消费级显卡显存是 12GB 或 24GB，连 7B 都勉强，70B 更是天文数字。

除了权重，推理过程还有两笔开销经常被忽略。一笔是 KV Cache，也就是注意力计算时缓存的 Key 和 Value 向量，它和序列长度、batch size 成正比；另一笔是中间激活值，包括每一层输出的 hidden states、各算子计算产生的临时张量。这两部分叠加起来，即使权重已经量化到 4bit，一个 70B 模型完整加载仍然需要几十 GB 级别的显存。

所以说到低显存运行大模型，本质上要回答一个问题：能不能让模型权重不完整常驻显存，而是只在真正需要计算的那一刻才出现。AirLLM 的切入点就在这。

1.2 常见低显存方案的代价

在那之前，社区里已经有几条路线在尝试解决这个矛盾。量化最容易理解，把 fp16 权重压缩成 8bit 甚至 4bit，权重占用直接降到原来的四分之一到八分之一。但量化有两个绕不开的成本：一是需要校准数据来降低精度损失，二是某些动态量化算子在不同显卡上兼容性一般，偶尔会出现推理结果异常或者算子不支持的情况。

其次是模型蒸馏和剪枝。把大模型的能力蒸馏到一个小模型里，或者剪掉冗余层，效果听起来很美，实际上需要重新训练或至少做大量微调，数据、算力、时间一样都缺不了。对多数只想在本地跑个模型的人来说，这个门槛太高了。

还有一种是多卡方案，把权重切到多张显卡上并行计算。除非你本身就有多卡环境，否则光靠买卡的成本就已经让"低显存"失去了意义。相比之下，AirLLM 选择了一条更简单粗暴的路：直接把 transformer 拆成一层一层串行计算。它不重训练、不校准、不额外买卡，只需要牺牲一部分推理时间。

1.3 一次只算一层：AirLLM 的选择

AirLLM 的核心思路可以浓缩成一句话：无论模型有多少层，同一时刻只让一层的权重占用显存。Transformer 模型天生就是一层接一层串行的结构，第一层算完才能算第二层，既然如此，为什么要把所有层的权重同时放在显存里？

实际执行时，模型先把输入转换成 hidden states，然后从第一层开始循环：把这一层权重从内存加载到显存，计算出这一层的输出，再把权重释放掉，换下一层。GPU 显存里同时存在的永远只有当前层的权重、输入输出 hidden states、以及必要的 KV Cache。这个方案没有任何推理精度损失，也完全不改模型结构，对开源社区里各种 transformer 架构模型都有很好的适配性。

对这种设计，我自己的理解是：它用时间换空间，但换得非常值。普通用户手头缺的从来不是时间，而是显存。一个离线任务跑几十分钟甚至一两个小时完全可以接受，但让他在现有硬件上根本跑不起来，那就是 0 和 1 的区别。

2. 分层推理原理：一次只算一层，显存到底省在哪

2.1 从 transformer 的一次完整前向说起

要搞清楚分层推理省显存的具体原理，得先知道 transformer 正常推理时一个 batch 的数据是怎么流动的。假设输入一句话，token 化后变成一个形状为[batch_size, seq_len]的整数序列。模型首先查 embedding 表，把它变成[batch_size, seq_len, hidden_size]的向量序列，这就是最初的 hidden states。

接下来，这个 hidden states 会依次穿过模型的所有 transformer 层。每一层做的事大致是一样的：先做 layer norm，然后进多头注意力，和 KV Cache 结合算出新的表示，再过 FFN 两个线性变换，中间穿插激活函数和残差连接。全部层跑完后，再经过最后的 norm 和输出投影，得到每个位置、每个词表上的 logits。

在传统推理方式下，为了完成这个过程，所有层的权重一次性进显存，并且在整个生成过程中常驻。每个 token 生成时，都要重复跑一次所有层，权重一直在那等着。这对显存非常不友好，因为真正参与计算的数据量通常远小于权重量。

2.2 分层推理时显存里的画面

AirLLM 的做法相当于把上面这条流水线改造成了一个"串行循环"。伪逻辑大概是这样的：

1. embedding 层把输入 token 转成 hidden states，放到显存里；
2. 遍历模型的每一层，每次只从内存加载这一层的权重到 GPU；
3. 当前层完成计算，得到新的 hidden states；
4. 立刻释放当前层权重，接着加载下一层；
5. 所有层都跑完，再做输出层计算。

关键点在哪？在任意一个瞬间，显卡上只有一层权重。拿一个 32 层、7B 参数的模型举例，平均每层参数大约 7B / 32 ≈ 0.22B，fp16 权重大约是 0.44GB。这个量级对于绝大多数消费级显卡来说毫无压力。即使 70B 模型拆成 80 层，单层权重也就 1.75GB 左右，8GB 显存照样放得下。

激活值的部分也值得多说一句。分层推理不需要像传统方式那样把每一层的激活都保存下来用于反向传播，因为推理阶段根本没有反向传播。它只需要保留当前层的输入输出，每次循环时用一个新输出覆盖旧输出即可。KV Cache 虽然还在，但可以通过控制 batch size 和序列长度来控制上限。整体看，显存占用从"整个模型大小"降到了"单层模型大小 + 单层激活 + KV Cache"，这个数量级的下降是颠覆性的。

2.3 时间换空间的代价和优化空间

你可能已经想到，把权重一次次搬进搬出，时间肯定比权重常驻要慢。这是不可避免的，问题的关键是怎么让慢变得可接受。

数据搬运的瓶颈主要在内存和 GPU 之间。权重从内存到显存要经过 PCIe 总线，带宽通常远小于显存内部带宽。为了缓解这一点，可以做两件事：一是让权重在内存里尽可能连续存放，减少随机寻址开销；二是预取，当前层计算的同时，把下一层权重提前搬到显存里，让搬运和计算重叠起来。

还有一个容易忽略的点：显存不够的时候，很多人会忘了检查内存是否够大。AirLLM 这类方案没有把权重放在显存里，那它们放在哪里？就是系统内存。内存越大，模型各层权重越能整体缓存在内存里，每次循环都是直接从内存读，而不是反复从磁盘读。我自己实测过，如果模型权重放在机械硬盘上，每次加载一层都像挤牙膏，速度惨不忍睹；换成固态硬盘后流畅非常多，再配合内存缓存，体验提升非常明显。

所以，分层推理工程上真正吃紧的资源是系统内存和磁盘 IO 速度，而不是显存。准备用这个方案之前，先检查机器内存够不够，这比纠结显卡显存更重要。

3. 5分钟跑通 AirLLM 最小示例：安装、代码、资源估算

3.1 环境准备与依赖关系

AirLLM 的使用门槛不高，但环境要求需要提前确认。首先是 Python 版本，建议 3.9 以上；其次需要常见的深度学习框架作为底层支撑，AirLLM 的 API 风格很像 Transformers 库，所以最好把 Transformers、Tokenizer 等基础组件也装上，很多开源模型仓库的权重下载和 tokenizer 加载都要用到。

安装过程非常简单，直接用包管理器装就行。装完以后可以用一行代码验证是否成功，如果能看到版本号输出就说明依赖基本 OK。如果这一行验证都报错，大概率是深度学习框架版本太旧或者 CUDA 版本和显卡驱动不匹配，先把这两件事对齐再继续。

pip install airllm

import airllm print(airllm.__version__)

这里提一个我自己踩过的坑：如果机器上同时装了多套环境，不同项目的依赖经常互相顶撞。建议新建一个独立执行环境来跑 AirLLM，不要直接在系统环境里装。否则很容易出现装完 AirLLM 之后原有的某个库突然失效，排查半天才发现是依赖版本被改动。

3.2 加载模型并运行生成的最小代码

AirLLM 对外暴露的 API 和 Transformers 非常像，如果你用过常见的开源模型加载工具，几乎可以零成本上手。下面是一个非常精简的示例，目的是跑通流程：

from airllm import AutoModel model_path = "/data/models/my-open-7b" model = AutoModel.from_pretrained(model_path) inputs = model.tokenizer( "介绍一下分层推理的原理。", return_tensors="pt", ) output = model.generate( inputs.input_ids.to(model.device), max_new_tokens=256, do_sample=True, temperature=0.7, ) text = model.tokenizer.decode(output[0], skip_special_tokens=True) print(text)

这段代码里，model_path指向你已经下载好的开源模型权重目录，目录里应该有模型配置文件、权重文件、tokenizer 文件等。AutoModel.from_pretrained会负责读取模型结构并初始化分层推理环境，第一次执行时可能需要做一些索引和分片准备，日志会输出相关提示。

model.tokenizer内置了一个可以直接使用的 tokenizer。generate的用法和常规接口一致，max_new_tokens控制生成的最大新 token 数，temperature控制采样随机性。整体调用方式和平时跑社区模型几乎没区别，这正是 AirLLM 最大的优势：对用户来说，感受不到分层推理的存在，代码不需要改动。

3.3 第一次运行时发生了什么

我建议第一次跑的时候不要只盯着输出，打开后台的显存监控工具，把显存占用和内存占用都录下来看一遍。你会发现显存曲线非常有意思：每次只涨到当前层所需的量，然后掉下来，再涨上去，呈现一个接一个的峰值，而不是传统推理那种一上去就再也没下来过的平线。

这正是分层推理生效的直接证据。当时我看到那个锯齿状的显存曲线，心里对方案的理解立刻深了一层：本质上就是在用轮换策略代替同时驻留。只要峰值不超过显存上限，理论上模型再大也能跑。唯一要留意的是内存监控，几十 GB 的模型权重会全部躺在内存里，这类运行方式会导致内存占用居高不下。

3.4 显存和内存的估算方法

动手之前，建议你先做一个简单的资源评估。公式并不复杂：模型显存峰值大概等于"单层权重大小 + hidden states + 当前层的临时激活 + KV Cache"，再留 10% 到 20% 的余量。而系统内存需求则基本接近整个模型权重的大小，因为你还是得把所有层都放进内存才能逐层加载。

上面这个表是经验参考值，不是死规矩，不同模型结构的层数和 hidden_size 差异挺大。但你能看到一个大趋势：模型规模越大，对内存容量的要求越苛刻，对显存的要求反而没那么夸张。这也是为什么有人戏称这个方案"把显存压力转移给了内存条"。

4. 新手必看：AirLLM 高频报错排查与提速技巧

4.1 显存还是溢出了怎么办

照理说分层推理已经把显存压得很低，但遇到显存溢出还是有可能的，主要原因通常不在权重，而在激活值和 KV Cache。模型单层权重可以算出来，但 batch size 和序列长度变大时，激活值会跟着涨，KV Cache 更明显，和序列长度是线性关系。

遇到这种情况，先按优先级做三件事。第一，把 batch size 降到 1；第二，缩短生成的最大序列长度；第三，观察是否还有其它进程占用了显存。很多时候所谓"显存不足"其实是机器上同时跑了好几个任务，或者浏览器加速导致显存碎片化。把这些因素清掉之后，一个 8GB 显卡跑 13B 模型是经常见到的配置。

如果这些操作都做完了仍然溢出，就需要考虑降低精度了。让模型权重变成 8bit 或 4bit，或者尝试更激进的量化模式。量化之后单层权重更小，峰值自然更低。

4.2 加载模型时报错频繁

加载阶段的问题，八成出在模型路径或者权重格式上。AirLLM 要求传入的目录结构是规范的，至少包含模型配置文件、权重文件和 tokenizer 相关文件。只要缺少其中一个，或者权重格式和库预期不一致，就会在from_pretrained这一步直接报错。

我遇到过的典型场景是：从网盘下载的权重不完整，或者下载器把文件后缀弄丢了。建议下载完成后先核对文件数量和大小，再放到标准目录结构里。另外，不要图省事直接把它指向一个只包含权重文件的裸目录，规范做法是保持模型仓库原本的层级结构。

4.3 推理速度慢到怀疑人生

慢，是分层推理最常被吐槽的点，也是这个方案唯一的命门。想提速，先分清瓶颈在哪里。如果显存监控显示每次峰值之间有明显的空闲间隔，说明搬运没有和计算重叠好，数据加载慢于计算。这时候优先检查磁盘类型，机械硬盘换固态硬盘是立竿见影的升级。

如果内存容量足够，系统会把热门权重缓存在内存里，后续加载会快很多。所以另一个提速手段是：让模型权重尽量留在内存缓存中，不要被系统换出。这听起来有点像废话，但实际执行上的含义是，不要在同一个机器上同时开太多吃内存的应用，否则内存缓存会被挤掉。

还有个小技巧是减少不必要的日志输出。日志打印本身会干扰执行流，虽然单次影响不大，但逐层循环个几十上百次，累计起来也是个不小的开销。把日志级别调高一点，推理过程会更顺。

4.4 生成结果明显不对怎么查

有时候模型能跑通，但是输出完全是乱的，比如中英文混杂严重、重复性极高、或者生成突然截断。这通常不是分层推理本身的问题，而是模型与 tokenizer 不匹配，或者采样参数设置不合适。

先检查加载的 tokenizer 是否和模型配套，很多模型换了分词器之后效果会急剧恶化。再检查temperature和top_p这类采样参数，温度太高会随机到离谱，太低会陷入重复循环。对中文生成任务，我个人习惯是把temperature设置在 0.6 到 0.8 之间，同时把重复惩罚项稍微调大一点，效果会稳定很多。

还有一点容易被忽略：上下文长度不要堆太长。分层推理下，每多一个 token，KV Cache 都会多占一点显存，而且长上下文会放大早期 token 的权重误差，导致回答质量下降。按任务需要控制输入长度，比一味拉长窗口更实用。

5. 进阶玩法：配合量化、扩展任务与我总结的边界

5.1 分层推理加量化：双管齐下的效果

AirLLM 这类分层推理方案和量化并不冲突，反而可以叠着用。量化先把权重压小，分层推理再把权重搬来搬去，二者结合之后，显存峰值能被压到非常可观的程度。一个 70B 模型如果先量化到 4bit，再分层加载，理论上单次驻留显存只需要 1GB 级别，这在以前想都不敢想。

但我要提醒一句：量化和分层结合时，要留意精度损失是否叠加。分层推理本身是不损失精度的，逐层计算只是换了时间安排，数学结果和普通推理一模一样；量化则实实在在改变了权重数值。如果量化校准做得好，精度下降可以控制得很小；如果校准数据不合适，可能出现某些层误差被后期放大，生成结果越来越跑偏。从实践中看，对生成类任务，4bit 加分层推理仍然可用，但对需要精确数值输出的任务要谨慎。

5.2 扩展：同一套思路能承载更多任务

分层推理的本质是按需加载，所以它不仅适用于文本生成，也可以推广到许多基于 transformer 的任务上。只要模型结构允许逐层执行，这个思路就成立。举例来说，embedding 检索模型、序列分类模型、甚至一些多模态项目的文本编码部分，都可以借鉴这套内存管理策略。

我建议你在自己的场景里先做一个小实验：找一个小型 transformer 模型，用 AirLLM 的 API 加载，看看显存峰值和推理时间是否符合预期。如果顺手，再尝试把更大的模型塞进去。这种渐进式验证比直接上最大的模型更稳妥，因为小模型跑起来快，便于验证环境配置和代码逻辑，等到大模型时只需要关注资源问题。

5.3 使用边界：什么场景不适合分层推理

分层推理不是银弹，它的短板集中在三点。第一是实时性要求高的场景，比如在线聊天机器人，如果每个回复都要等上一段时间，用户体验会非常差，这类场景更适合购买高性能方案或用更高配置的机器。第二是高吞吐场景，比如批量处理海量文本，分层推理的串行特性决定了吞吐上不去，这时候权重常驻显存更合适。第三是显存和内存都不大的机器，如果内存只有 16GB，还想跑 70B 模型，那就算显存能被压住，内存也不够放权重，整个方案就失去意义。

所以在决定用 AirLLM 之前，先对着自己的硬件盘一下账：内存容量是第一道门槛，磁盘速度是第二道门槛，显存反而排在后面。这个判断顺序和我一开始的直觉完全相反，但实测下来就是这么回事。

5.4 我总结的几个关键经验

最后分享几条我在多次实践里沉淀下来的经验，供你直接抄作业。一是首次运行时要盯紧日志里每一步的耗时，哪一层明显慢就说明当前层权重可能不在内存缓存里，需要检查磁盘速度或其它程序干扰。二是尽量保持模型权重文件的连续性，不要用零散下载的碎片文件，离散的磁盘块会让逐层加载的时间显著增大。三是如果模型已经量化过，不必再额外做二次校准，直接套用原量化配置就好。

我个人的态度是：在你还没有条件和预算去上更大的显卡之前，AirLLM 这种方案非常值得作为主力推理手段来使用。它不优雅，甚至有点笨，但它极其务实地解决了"手里有什么就用什么"的问题。我在实际使用中最大的体会是，很多所谓跑不动的模型，其实只是加载方式不对。换一种思路，用内存空间去置换显存压力，模型照样能转起来。以后如果你的工作流对实时性要求进一步提高，完全可以把这个方案作为备份，遇到交互要求高的场景再切换到更强硬件，两条路并行不冲突。