企业官网建设流程全解析

1. 项目缘起与核心思路拆解

1.1 这个项目到底在解决什么问题

大模型推理这件事，卡脖子的地方往往不在算力峰值，而在显存容量。一个 70B 参数量的模型，如果以 FP16 精度加载，光权重就要吃掉大约 140GB 显存，这还没算 KV Cache 和中间激活值。现实情况是，绝大多数个人开发者和中小团队手里只有一张 24GB 甚至 12GB 显存的卡，想跑大模型基本等于痴人说梦。

airllm 这个项目切入的正是这个痛点。它的核心目标非常明确：让显存有限的机器也能跑起大参数量的语言模型。注意，它追求的不是高吞吐、低延迟的生产级推理，而是“能跑起来”这个最低门槛。这个定位很关键，因为它决定了整个方案的设计取舍——用时间换空间，用磁盘 I/O 换显存占用。

我第一次接触这个思路的时候，直觉是“这不就是拿硬盘当显存用吗”。没错，本质上就是这么回事，但实现起来远没有一句话那么简单。模型权重的加载、层的调度、计算的流水线组织，每一步都有大量工程细节需要处理。airllm 把这些细节封装成了相对易用的接口，让使用者不需要自己去写复杂的调度逻辑。

适合读这篇内容的人大概分三类：一是手里只有消费级显卡、想本地跑大模型的个人开发者；二是想理解大模型推理底层机制、不想只停留在调 API 层面的工程师；三是在资源受限环境下做模型验证、需要快速搭原型的研究人员。如果你属于这三类中的任何一类，接下来的内容应该对你有实际帮助。

1.2 为什么选择“分层加载”这条路线

大模型推理的显存优化方案其实有好几条路可以走。常见的有量化压缩（把 FP16 降到 INT8 甚至 INT4）、模型蒸馏（用小模型学大模型的行为）、以及这里要聊的分层加载。airllm 选了最后一条，这个选择背后的逻辑值得掰开说。

量化的思路是把每个参数占用的比特数降下来，比如从 16 位降到 4 位，理论上显存占用能降到原来的四分之一。但量化有个绕不开的问题：精度损失。尤其是对参数量本来就大的模型，量化后的效果下降在某些任务上会非常明显。而且量化本身也需要额外的校准过程，不是拿来就能用的。

分层加载的思路完全不同。它不改变模型本身的精度，而是改变模型在推理时“驻留”在显存中的方式。具体来说，Transformer 架构的模型天然就是一层一层堆叠起来的，第 N 层的计算只依赖第 N-1 层的输出。这意味着你不需要同时把所有层都放在显存里，完全可以算完一层、把这一层从显存里挪走、再加载下一层进来。

这个思路的优势在于精度无损。模型还是那个模型，权重一个比特都没变，只是加载策略变了。代价也很明显：每算一层就要从磁盘读一次权重，磁盘 I/O 会成为整个推理过程的瓶颈。所以 airllm 的适用场景是“偶尔跑一次、对速度不敏感”的情况，而不是高并发的在线服务。

注意：分层加载的前提是模型架构支持逐层独立计算。Transformer 的解码器结构天然满足这个条件，但有些特殊架构（比如某些混合专家模型）可能需要额外处理。

1.3 整体架构的层次划分

airllm 的内部实现可以粗略分成三个层次来理解。最底层是权重存储层，负责把模型权重按层切分并持久化到磁盘上，通常是用 safetensors 格式保存，因为它的加载速度比 pickle 快，而且内存映射友好。中间层是调度层，负责管理“当前哪一层在显存里、下一层什么时候加载进来”这个流水线。最上层是接口层，对外暴露类似generate这样的调用方式，让使用者感觉不到底层的复杂性。

调度层是整个项目最核心的部分。它需要解决一个经典的生产者-消费者问题：磁盘读取是生产者，GPU 计算是消费者。如果读取太慢，GPU 就会空转；如果读取太快，显存又放不下。airllm 的做法是维护一个滑动窗口，只保留当前计算层和预取层在显存中，其余层全部留在磁盘上。

这个滑动窗口的大小是可以调的。窗口越大，预取越充分，GPU 等待时间越短，但显存占用也越高。窗口越小，显存越省，但 I/O 等待会更频繁。实际使用中需要根据自己的显存大小和磁盘速度来权衡。我一般建议从窗口大小为 1 开始试，也就是只保留当前层，如果显存还有富余再往上加。

2. 核心细节解析与实操要点

2.1 权重切分与存储格式的选择

airllm 在第一次加载模型时，会做一件很重要的事：把原始的模型权重文件按层切分成独立的文件。这个切分过程只需要做一次，之后每次推理都直接读取切分好的文件。切分的粒度通常是按 Transformer 的层来，每一层保存成一个单独的 safetensors 文件。

为什么选 safetensors 而不是传统的 pickle 格式？这里有几个实际考量。第一，safetensors 支持零拷贝加载，也就是说它可以直接把文件内容映射到内存，不需要额外的反序列化过程。第二，safetensors 的加载速度明显快于 pickle，在大文件场景下差距更明显。第三，safetensors 格式本身更安全，不会像 pickle 那样在加载时执行任意代码。

切分后的文件目录结构大概是这样的：每一层一个文件，文件名里包含层号，另外还有单独的 embedding 层和 lm_head 层。这种结构的好处是加载时可以直接按需读取，不需要先加载整个模型再切分。对于 70B 的模型，切分后大概会有 80 个左右的文件，每个文件几百 MB 到 1GB 不等。

提示：切分过程需要额外的磁盘空间，大概是原始模型大小的 1.1 倍左右。如果磁盘空间紧张，可以在切分完成后删掉原始权重文件。

2.2 显存与磁盘的流水线调度

流水线调度是 airllm 性能表现的关键。理想情况下，当 GPU 在计算第 N 层的时候，磁盘应该在同时读取第 N+1 层的权重。这样当第 N 层计算完成时，第 N+1 层的权重已经准备好了，GPU 可以立刻开始下一层的计算，不需要等待。

但现实往往没那么理想。磁盘读取速度是第一个瓶颈。一块普通的 SATA SSD 顺序读取速度大概在 500MB/s 左右，而 NVMe SSD 能到 3GB/s 以上。对于 70B 模型，每层权重大概 1.7GB（FP16 精度），用 SATA SSD 读取一层需要 3.4 秒，用 NVMe 大概 0.6 秒。而 GPU 计算一层的时间通常在几十毫秒量级。也就是说，I/O 时间远远超过计算时间，GPU 大部分时间都在等数据。

这个数字对比很能说明问题：分层加载方案下，推理速度的瓶颈几乎完全在磁盘 I/O 上。所以如果你打算用 airllm，一块高速 NVMe SSD 是必须的，用机械硬盘基本没法用。另外，把模型文件放在内存文件系统（比如 tmpfs）上也能显著提速，前提是你的内存足够大。

调度层还需要处理一个细节：层的依赖关系。Transformer 的每一层计算需要用到上一层的输出，但权重之间没有依赖。这意味着权重的预取可以很激进，只要显存放得下，可以提前加载好几层。airllm 通过配置参数来控制预取层数，默认值比较保守，实际使用中可以根据显存情况调大。

2.3 精度保持与计算一致性

前面提到分层加载是精度无损的，但这个“无损”需要一些额外保障。最大的风险点在于：当权重从磁盘加载到显存时，数据类型转换可能引入误差。比如磁盘上存的是 FP16，加载到显存后如果被转成了 FP32 再转回 FP16，中间可能会有舍入误差。

airllm 在这方面的处理是尽量保持数据类型一致。加载时直接以目标精度读取，避免不必要的转换。另外，对于某些对精度敏感的操作（比如 LayerNorm），计算过程中会临时提升到 FP32 再降回来，这是标准做法，和模型是否分层加载无关。

还有一个容易被忽略的点：KV Cache 的管理。在自回归生成过程中，每一层都需要缓存之前 token 的 Key 和 Value。如果模型是分层加载的，KV Cache 也需要跟着层走。airllm 的做法是把 KV Cache 也放在显存里，但只保留当前层的部分。这意味着生成每个 token 时，之前所有层的 KV 都需要重新计算或者从磁盘读取。这进一步加剧了 I/O 压力，也是分层加载方案速度慢的另一个原因。

注意：如果你的任务是长文本生成，KV Cache 的反复读写会让速度进一步下降。这种情况下可以考虑限制生成长度，或者接受更慢的推理速度。

2.4 配置参数的实际含义

airllm 暴露出来的配置参数不多，但每一个都直接影响使用体验。最关键的几个参数包括：layer_shards_saving_path（切分后权重的保存路径）、prefetching（是否开启预取）、max_seq_len（最大序列长度）、以及device（计算设备）。

prefetching这个参数值得单独说。开启后，调度器会在计算当前层的同时异步读取下一层。这需要额外的显存来存放预取的权重，所以如果你的显存非常紧张，可能需要关掉它。但关掉之后速度会明显下降，因为 GPU 会频繁空等。我的建议是：如果显存允许，一定要开启预取。

max_seq_len影响的是 KV Cache 的大小。设置得越大，KV Cache 占用的显存越多。对于分层加载方案，KV Cache 的显存占用可能比单层权重还大。所以这个值需要根据实际任务来设，不要盲目设得很大。

device参数一般不需要改，默认会用第一块 GPU。如果你有多块卡，可以指定用哪一块。但 airllm 本身不支持多卡并行，它只会在单卡上运行。多卡场景下需要自己在上层做模型并行，这超出了 airllm 的处理范围。

3. 实操过程与核心环节实现

3.1 环境准备与依赖安装

开始之前需要确认几个前提条件。Python 版本建议 3.8 以上，PyTorch 需要和你的 CUDA 版本匹配。磁盘空间方面，以 70B 模型为例，原始权重约 140GB，切分后还需要额外 140GB 左右，所以至少准备 300GB 的可用空间。如果磁盘紧张，可以在切分后删掉原始文件，这样峰值占用能降到 150GB 左右。

安装 airllm 本身很简单，一条 pip 命令就能搞定。但它依赖的一些库需要留意版本兼容性，特别是 transformers 和 accelerate。我遇到过因为 transformers 版本太新导致加载失败的情况，后来锁定到某个稳定版本才解决。建议在虚拟环境里安装，避免和系统里其他项目的依赖冲突。

python -m venv airllm_env source airllm_env/bin/activate pip install airllm pip install torch --index-url https://download.pytorch.org/whl/cu118

CUDA 版本需要根据你的驱动来选，上面只是示例。安装完成后可以用nvidia-smi确认 GPU 能被正确识别，用python -c "import torch; print(torch.cuda.is_available())"确认 PyTorch 能调用 CUDA。

3.2 模型切分与首次加载

第一次使用某个模型时，airllm 会自动做切分。这个过程比较耗时，70B 模型大概需要 20 到 40 分钟，取决于磁盘速度。切分过程中会占用大量内存，因为需要先把整个模型加载到内存里再逐层保存。如果内存不够，可以考虑用low_cpu_mem_usage选项，它会用内存映射的方式加载，降低内存峰值。

from airllm import AutoModel model = AutoModel.from_pretrained( "meta-llama/Llama-2-70b-hf", layer_shards_saving_path="/path/to/shards", prefetching=True, max_seq_len=512 )

上面这段代码第一次运行时会触发切分。切分完成后，后续再加载就直接读切分好的文件，速度快很多。切分后的文件会一直保留在指定路径下，除非手动删除。如果你要换模型，记得把旧的分片文件清理掉，不然磁盘很快会被占满。

提示：切分过程中如果中断，可能会留下不完整的分片文件。重新运行前最好把目标目录清空，避免加载到损坏的文件。

3.3 推理调用的完整流程

模型加载完成后，推理调用和普通 transformers 的用法很接近。构造输入、调用 generate、解析输出，三步走。但有几个细节需要注意。

input_text = "请解释一下什么是机器学习" input_ids = model.tokenizer(input_text, return_tensors="pt").input_ids output = model.generate( input_ids, max_new_tokens=128, do_sample=False ) print(model.tokenizer.decode(output[0], skip_special_tokens=True))

max_new_tokens控制生成的最大 token 数。这个值设得越大，生成时间越长，因为每个 token 都需要走一遍完整的层加载流程。实际测试中，70B 模型在 NVMe SSD 上生成一个 token 大概需要 2 到 5 秒，具体取决于预取配置和序列长度。所以生成 128 个 token 可能需要 5 到 10 分钟，这个速度需要有心理预期。

do_sample=False表示用贪心解码，速度最快。如果开启采样，每个 token 都需要额外的随机数生成和概率计算，会稍微慢一点。对于分层加载方案，我建议先用贪心解码验证流程能跑通，再根据需求调整解码策略。

3.4 性能实测与参数调优

我在一台配置为单卡 24GB 显存、NVMe SSD、64GB 内存的机器上做过一组对比测试。模型用的是 70B 参数量的版本，序列长度 512，生成 64 个 token。测试结果如下：

从数据能看出几个规律。开启预取后速度几乎翻倍，因为 GPU 等待时间大幅减少。把分片文件放到内存文件系统上又能再快接近一倍，因为内存的读取速度远高于 SSD。但 tmpfs 会占用内存，70B 模型的分片大概 140GB，除非你有足够大的内存，否则放不下。

显存峰值方面，开启预取后从 18GB 涨到了 21GB，接近 24GB 卡的上限。如果你的卡显存更小，可能需要关掉预取，或者用更小的模型。另外，序列长度对显存的影响也很大，512 长度下 KV Cache 占用还不算夸张，如果开到 2048，显存可能直接爆掉。

注意：上面的数据是基于特定硬件配置的实测结果，你的实际表现会因硬件不同而有差异。关键是理解各个参数对性能的影响方向，然后根据自己的硬件做调整。

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

4.1 加载失败与显存溢出

最常见的问题是在加载阶段就报显存不足。错误信息通常是 CUDA out of memory，但具体原因可能有好几种。第一种可能是预取层数设得太多，显存里同时存在多层权重。解决办法是把预取关掉，或者减少预取层数。第二种可能是 KV Cache 占用过大，尤其是当你设置了很长的 max_seq_len 时。解决办法是降低 max_seq_len，或者限制生成的最大 token 数。

还有一种比较隐蔽的情况：显存碎片化。长时间运行后，显存里可能存在很多不连续的小块，虽然总空闲显存够，但没有一块连续的空间能放下新加载的层。这种情况下可以尝试在加载前调用torch.cuda.empty_cache()，或者重启进程。

如果显存实在不够，最后的办法是换更小的模型。airllm 支持从 7B 到 70B 甚至更大的模型，但显存需求是跟着模型走的。7B 模型在 8GB 显存上就能跑，13B 大概需要 12GB，70B 至少需要 20GB 以上。选模型的时候要对自己的硬件有清醒认识。

4.2 推理速度异常缓慢的排查

速度慢是分层加载方案的固有特点，但如果慢到不可接受，就需要排查原因。第一步是确认磁盘类型。用lsblk -d -o name,rota可以看磁盘是不是旋转设备（rota 为 1 表示机械硬盘）。如果是机械硬盘，那速度慢是必然的，换 SSD 是唯一解。

第二步是检查预取是否生效。可以在代码里加一些日志，看权重加载和计算是否真的在并行。如果发现加载和计算是串行的，那预取可能没起作用。常见原因是预取线程被 Python 的 GIL 阻塞了，这种情况下可以尝试用多进程代替多线程来做预取。

第三步是看 CPU 是否成为瓶颈。safetensors 的加载虽然快，但也需要 CPU 参与。如果 CPU 核心数太少或者主频太低，加载速度也会受限。用htop看一下推理过程中 CPU 的占用情况，如果某个核心跑满了，那可能就是 CPU 瓶颈。

4.3 生成质量与预期不符

有时候模型能跑起来，但生成的内容质量很差，比如重复、乱码、或者答非所问。这种情况首先要排除是不是模型本身的问题。同样的输入用普通加载方式跑一遍，如果输出正常，那说明分层加载引入了问题。

一个可能的原因是数据类型转换。检查一下加载后的权重类型是否和原始模型一致。可以用model.model.layers[0].self_attn.q_proj.weight.dtype来查看。如果发现是 FP32 而原始模型是 FP16，那可能是加载时做了不必要的转换。

另一个原因是 KV Cache 的管理出了问题。分层加载下，KV Cache 需要和层一起调度。如果调度逻辑有 bug，可能导致某些层的 KV 丢失或者错位。这种情况下生成的文本会表现出明显的逻辑断裂。排查方法是先用很短的序列（比如 10 个 token）测试，看输出是否正常，再逐步加长。

4.4 常见问题速查表

4.5 几个容易被忽略的实操心得

第一个心得是关于磁盘选择的。很多人觉得只要是个 SSD 就行，但实际上 SATA SSD 和 NVMe SSD 在这个场景下差距巨大。我实测过同一台机器上换盘的效果，NVMe 比 SATA 快了将近三倍。如果预算允许，一定要上 NVMe。

第二个心得是关于模型选择的。不是所有模型都适合分层加载。有些模型在架构上做了特殊设计，比如用了稀疏注意力或者动态路由，这些模型的层之间依赖关系更复杂，分层加载的效果会打折扣。选模型之前最好先看看它的架构是否规整。

第三个心得是关于温度控制的。分层加载会让推理时间拉长，GPU 长时间处于高负载状态，散热压力很大。如果散热不好，GPU 会降频，速度进一步下降。确保机箱风道通畅，必要时可以手动调高风扇转速。

第四个心得是关于日志的。airllm 默认的日志级别比较高，很多有用的信息看不到。可以在代码开头加import logging; logging.basicConfig(level=logging.DEBUG)来打开详细日志。这样能看到每一层的加载时间、计算时间，方便定位瓶颈。

5. 适用边界与扩展思路

5.1 什么场景适合用这个方案

分层加载不是万能的，它有明确的适用边界。最适合的场景是：偶尔跑一次大模型、对延迟不敏感、但显存有限。比如个人开发者想在自己的机器上验证一个想法，或者研究人员需要快速测试某个 prompt 的效果。这些场景下，等几分钟甚至十几分钟是可以接受的。

不适合的场景也很明确：高并发在线服务、实时交互应用、需要快速迭代的实验。这些场景对延迟有硬性要求，分层加载的速度根本达不到。另外，如果任务本身需要频繁调用模型（比如批量处理几千条数据），用这个方案的时间成本会高到无法接受。

一个折中的思路是：用分层加载做原型验证，验证通过后再把模型部署到有足够显存的机器上做正式服务。这样既利用了分层加载的低门槛优势，又避免了它在生产环境中的性能短板。

5.2 可以继续优化的方向

如果想让 airllm 跑得更快，有几个方向可以尝试。第一个是混合精度策略：把一部分层放在显存里常驻，另一部分层做分层加载。比如把 embedding 层和 lm_head 层常驻显存，中间的 Transformer 层做分层加载。这样能减少一部分 I/O 开销。

第二个方向是用更快的存储介质。除了 NVMe SSD，还可以考虑用持久内存（PMem）或者大容量内存做缓存。如果机器内存足够大，可以把整个模型的分片都放到 tmpfs 上，这样加载速度就是内存速度，比任何 SSD 都快。

第三个方向是优化调度算法。当前的预取策略比较固定，可以根据实际 I/O 延迟动态调整预取层数。如果磁盘响应快，就多预取几层；如果磁盘忙，就少预取几层。这种自适应策略能更好地利用硬件资源。

5.3 和其他显存优化方案的组合

分层加载可以和量化组合使用。先用量化把模型压到 INT8 或 INT4，再用分层加载进一步降低显存需求。这样理论上能在 8GB 显存上跑 70B 模型。但量化本身有精度损失，分层加载又有速度损失，两者叠加后效果如何需要实际测试。

另一个组合思路是和 CPU 卸载结合。有些框架支持把部分层放在 CPU 上计算，部分层放在 GPU 上。airllm 的分层加载本质上也是一种卸载，只不过卸载到了磁盘而不是 CPU。如果 CPU 内存足够大，把分片放在内存里会比放在磁盘上快很多。

最后，如果对速度有更高要求，可以考虑模型并行。把模型的不同层分配到不同的 GPU 上，每块卡只负责一部分层。这样每块卡的显存需求都降低了，而且层之间的数据传输可以通过高速互联完成，比磁盘 I/O 快得多。但这需要多块 GPU，门槛比 airllm 高不少。

我在实际使用中的体会是，airllm 最大的价值在于它把“不可能”变成了“可能”。在它出现之前，显存不够就是不够，没有任何讨价还价的余地。现在至少有了一个选择，虽然慢，但能跑。对于很多个人开发者和研究者来说，这个“能跑”本身就是最重要的。至于速度，随着存储硬件的进步和调度算法的优化，相信会越来越好。如果你现在就想试试，建议从 7B 或 13B 模型开始，跑通了再往上加，这样踩坑的成本最低。