企业官网建设流程全解析

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 层的输出就是第 N+1 层的输入，层与层之间是严格的串行依赖。这意味着你算完第 N 层，它的权重就再也用不到了，可以安全释放。这种串行、无回溯的特性，让分层加载在逻辑上非常干净——不需要复杂的调度，只要按顺序来就行。

代价也很明确：每一层都要从存储（内存或磁盘）搬到显存，算完再搬走。如果模型放在内存里，这个搬运是内存到显存的拷贝；如果内存也放不下，就得放磁盘，那就是磁盘 IO。搬运本身不产生计算价值，纯粹是开销，所以分层加载的推理速度一定比"全量驻留显存"慢。这就是"用时间换空间"的字面含义。

2.2 内存、显存、磁盘三级存储的权衡

airllm 实际运行时，权重可以放在三个地方，对应三种速度和容量组合，理解这个分层是理解整个方案的关键。

最理想的配置是权重全放内存，逐层搬进显存。这样每层的加载是内存到显存的拷贝，速度可以接受，整体推理虽然慢于全量驻留，但还在可用范围。我实测过一个 13B 的模型，权重 FP16 约 26GB，放在 64G 内存的机器上，逐层加载到 12G 显存，单次生成的速度大概是全量驻留的几分之一，但确实能跑，而且不 OOM。

如果内存也不够，airllm 支持把权重存到磁盘，运行时从磁盘读。这时候瓶颈就变成磁盘 IO 了，机械硬盘基本没法用，NVMe 固态勉强能撑。我的建议是：能用内存就别用磁盘，磁盘方案是最后的兜底，不是常规选择。很多人一上来就把模型丢磁盘，然后抱怨慢得没法用，其实是没搞清楚瓶颈在哪。

2.3 量化在分层方案里的角色

分层加载解决的是"放不下"的问题，量化解决的是"放得下但想更快"的问题。两者是正交的，可以叠加。airllm 支持在分层的基础上做量化，常见的是 4bit 量化。

量化在这里的价值有两层。第一层是减小每层的体积，让单层加载更快、占用显存更少，这样即使是显存很小的卡也能容纳单层。第二层是减小总存储占用，让更多层能塞进内存，减少磁盘 IO 的概率。一个 70B 模型 FP16 是 140GB，4bit 量化后大约 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", # 量化配置，先不量化跑通流程 compression=None, )

第一次运行这段代码时，它会读取原始权重，按层切分，保存到指定路径。这个过程比较慢，取决于模型大小和磁盘速度，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_tensors="pt", return_attention_mask=False, truncation=True, max_length=128, padding=False, ).input_ids generation_output = model.generate( input_tokens, max_new_tokens=128, use_cache=True, return_dict_in_generate=True, ) 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 一份速查表

5.4 几条踩坑心得

先小后大。别一上来就拿最大的模型试，先用一个小模型（比如 7B）把整个流程跑通，确认环境、切分、推理都没问题，再换大模型。这样出问题时容易定位。

量化是最后手段。能用 FP16 跑通就别急着量化，量化会引入额外变量，让排查变复杂。等流程稳定了，再考虑量化压体积。

内存比显存更关键。很多人只盯着显存，其实分层方案里内存才是决定速度的关键。内存够，权重全驻留，速度尚可；内存不够，被迫用磁盘，速度崩盘。配机器时，内存要给足。

别频繁重启。每次重启都要重新加载模型，开销大。如果要做多轮实验，尽量在一个进程里连续跑，复用已加载的模型。

记录你的配置。模型版本、量化配置、切分路径、依赖版本，这些都要记下来。出问题时，能快速复现和对比。我吃过亏，改了一堆配置后忘了原来能跑的配置是什么，白白浪费半天。

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

分层加载推理跑通之后，其实还有不少可以深挖的方向。比如预取策略的优化，当前层在算的时候，提前把下一层甚至下下层加载进来，把 IO 和计算重叠得更充分，这能明显提升速度。再比如混合精度，不同层用不同的精度，敏感的层用高精度，不敏感的层用低精度，在质量和体积之间找更好的平衡。

还有一个方向是和缓存机制结合。自回归生成时，KV Cache 会随生成长度增长，如果能把 KV Cache 也做分层管理，进一步压显存，那能支持更长的上下文。这块比较复杂，但思路是通的。

如果你只是想先把东西跑起来，那不用想这么多，按前面的流程走一遍，能生成内容就算成功。等跑顺了，再根据实际瓶颈去优化。工程上的事，永远是先能用，再好用，最后才是快。我个人的体会是，分层加载这类方案最大的价值不是性能，而是把"不可能"变成了"可能"——让原本因为显存不够而完全跑不了的大模型，至少能跑起来。这个从 0 到 1 的意义，比从 1 到 10 的速度优化更实在。