企业官网建设流程全解析

1. 当大模型装不进显卡时，我在想什么

第一次看到 airllm 这个项目名，我脑子里蹦出来的不是“又一个推理框架”，而是一个很具体的画面：一台只有单张消费级显卡的机器，想跑一个参数量远超显存容量的模型，然后有人告诉你——不用量化到面目全非，不用换卡，也能跑起来。

这就是 airllm 最核心的价值主张：让大模型在显存不足的硬件上依然能够完成推理。它解决的不是“如何让模型跑得更快”，而是“如何让模型先跑得起来”。这两件事的优先级完全不同。前者是优化问题，后者是可行性问题。

我接触这个方向，是因为身边太多人卡在同一个坎上：手里有一张 8GB 或 12GB 显存的卡，想本地跑一个 7B、13B 甚至 70B 级别的模型，结果要么 OOM（显存溢出），要么被迫用量化版本牺牲精度。airllm 给出的思路是另一条路——把模型按层拆分，让每一层在需要计算时才加载进显存，算完就释放。本质上是用时间换空间，用磁盘 I/O 换显存占用。

这篇文章适合三类人看：第一类是想在有限硬件上跑大模型的个人开发者；第二类是对分层加载、按需推理这类工程思路感兴趣的技术人；第三类是想理解“推理框架到底在解决什么问题”的入门者。我会从它的核心机制讲起，拆解分层加载的实现逻辑，补充实际部署中的参数配置、踩坑经验和性能权衡，最后聊聊这类方案适合什么场景、不适合什么场景。

需要提前说明的是，airllm 这类方案的核心思想并不复杂，难的是工程细节——层怎么切、什么时候加载、什么时候释放、如何避免频繁 I/O 拖垮整体速度。这些细节决定了它是“能跑”还是“能用”。

2. 分层加载到底是怎么把大模型塞进小显存的

2.1 传统推理的显存瓶颈出在哪

要理解 airllm 的价值，得先搞清楚常规推理为什么吃显存。一个 Transformer 模型在推理时，显存占用主要来自三块：模型权重本身、激活值（中间计算结果）、以及 KV Cache。

模型权重是大头。以 FP16 精度为例，一个 7B 参数的模型，光权重就要占大约 14GB 显存（7B × 2 字节）。13B 就是 26GB，70B 就是 140GB。这还没算激活值和 KV Cache。所以一张 12GB 的卡，连 7B 模型的权重都放不下，更别说更大的模型。

常规做法是量化——把 FP16 压到 INT8 或 INT4，权重占用能降到原来的 1/2 或 1/4。但量化会带来精度损失，而且有些模型量化后效果下降明显。airllm 走的是另一条路：不压缩权重，而是改变权重的驻留策略。

2.2 按层加载的核心逻辑

Transformer 模型的结构是层叠的——一层接一层，数据从底层流向顶层。关键洞察在于：在任意时刻，真正参与计算的只有当前这一层。其他层的权重虽然存在，但并不需要同时待在显存里。

airllm 的做法就是利用这个特性：把模型按层切分，每一层的权重单独存放在磁盘上。推理时，只把当前需要计算的那一层加载进显存，算完之后立刻释放，再加载下一层。这样，显存的峰值占用就只取决于单层的大小，而不是整个模型的大小。

一个 70B 的模型，如果切成 80 层，每层大约 0.875B 参数，FP16 下约 1.75GB。也就是说，理论上只要有 2GB 左右的可用显存，就能跑起来。这就是它能把大模型塞进小显存的核心原因。

注意：这里的“单层大小”是理论值，实际还要加上激活值、KV Cache 和框架开销。所以真实显存需求会比单层权重大一些，但量级上仍然是可控的。

2.3 时间换空间的代价

这个方案不是没有代价的。每次加载一层都要从磁盘读取权重，这个 I/O 开销是实打实的。如果磁盘是机械硬盘，读取速度可能只有 100-200MB/s，加载一层 1.75GB 的权重就要十几秒，80 层就是十几分钟——这显然不可接受。

所以 airllm 的实际可用性高度依赖存储介质。NVMe SSD 是基本门槛，读取速度能到 2-7GB/s，加载一层的时间能压到 1 秒以内。如果能把模型放在内存盘（RAM Disk）上，速度还能更快，但内存盘容量有限，大模型放不下。

另一个优化点是预加载。在计算当前层的时候，可以异步预加载下一层的权重，让 I/O 和计算重叠起来。这样整体耗时就不是“加载时间 + 计算时间”的简单累加，而是接近两者中的较大值。这个优化对实际体验影响很大。

2.4 和量化方案的对比

这两条路不是互斥的。实际中也可以先量化再分层加载，进一步降低单层大小。但那样就叠加了两种方案的代价，需要根据具体场景权衡。

3. 实际部署时，参数配置和存储选择怎么定

3.1 环境准备中最容易被忽略的一步

部署 airllm 之前，很多人会直接 pip install 然后跑 demo，结果发现速度慢得离谱。问题往往不在代码，而在模型权重的存储位置。

默认情况下，模型权重会下载到用户目录下的缓存文件夹。如果这个目录在机械硬盘上，那分层加载的 I/O 瓶颈会非常明显。我的建议是：在开始之前，先把模型权重放到 NVMe SSD 上，并且确认这个分区的读取速度。

可以用一个简单的命令测一下磁盘读取速度：

# 测试磁盘顺序读取速度 dd if=/path/to/model/weights of=/dev/null bs=1M count=2048

如果输出显示速度低于 500MB/s，那基本可以确定瓶颈在磁盘上。这种情况下，要么换盘，要么考虑把模型放到内存盘上（如果内存足够大）。

3.2 分层粒度的选择

airllm 默认会按 Transformer 的层来切分，但实际使用中，层的大小并不完全均匀。有些模型的前几层和后几层参数量差异较大。如果某一层特别大，它就会成为显存占用的峰值。

一个实用的技巧是：先跑一次，观察每层加载时的显存峰值。如果发现某一层明显偏大，可以考虑把它进一步拆分，或者调整加载策略。不过大多数主流模型的分层已经比较均匀，不需要手动干预。

另一个参数是预加载的层数。预加载太多会占用额外显存，预加载太少又起不到重叠 I/O 的效果。一般建议预加载 1-2 层，具体取决于显存余量和磁盘速度。显存充裕、磁盘慢的情况下，可以多预加载几层。

3.3 推理参数的调整

分层加载模式下，一些常规推理参数需要重新考虑。比如batch size，在显存紧张的情况下，batch size 只能设为 1。因为每一层的激活值也要占显存，batch 越大，激活值越大，峰值显存就越高。

还有max sequence length。序列越长，KV Cache 越大。在分层加载模式下，KV Cache 是跨层保留的，不会随层释放。所以长序列会显著增加显存占用。如果显存实在紧张，可以适当限制输入长度。

# 典型的推理配置示例 config = { "batch_size": 1, # 显存紧张时只能为1 "max_seq_len": 512, # 根据显存调整 "prefetch_layers": 2, # 预加载层数 "device": "cuda:0", # 指定显卡 }

3.4 存储方案的取舍

前面提到 NVMe SSD 是基本门槛，但具体选哪种存储，还要看模型大小和使用频率。

如果只是偶尔跑一次，NVMe SSD 足够了。如果是频繁使用，可以考虑把模型放在内存盘上。Linux 下可以用 tmpfs 创建内存盘：

# 创建 64GB 的内存盘 mkdir /mnt/ramdisk mount -t tmpfs -o size=64G tmpfs /mnt/ramdisk

然后把模型权重复制进去。这样加载速度能到 10GB/s 以上，基本消除了 I/O 瓶颈。但代价是内存被占用，而且重启后数据丢失。所以适合内存充足（比如 128GB 以上）且频繁使用的场景。

还有一种折中方案：用高速缓存盘。一些主板支持把 NVMe SSD 作为缓存，加速机械硬盘的读取。这样既有大容量，又有不错的读取速度。不过配置起来稍复杂，适合有一定硬件基础的人。

4. 跑通之后才会遇到的坑：速度、显存与稳定性

4.1 为什么第一次推理特别慢

很多人跑通 airllm 后的第一个感受是：第一次推理慢得让人怀疑人生。这其实是正常的。第一次运行时，模型权重需要从磁盘加载，而且没有预加载优化，每一层都是“加载-计算-释放”的串行流程。

从第二次开始，如果操作系统有文件缓存，部分权重可能还在内存里，速度会快一些。但真正稳定的速度，取决于磁盘的持续读取能力。我的实测经验是：NVMe SSD 上，70B 模型的分层推理速度大约是常规推理的 1/5 到 1/10。这个差距主要来自 I/O 等待。

如果觉得太慢，可以尝试几个优化：一是增加预加载层数，让 I/O 和计算重叠；二是把模型放到内存盘；三是减少 max sequence length，降低单次计算量。

4.2 显存峰值的波动

分层加载的显存占用不是恒定的，而是随层波动的。有些层的激活值大，有些层小。如果观察到显存峰值接近上限，可以尝试限制预加载层数，或者在层间主动释放缓存。

PyTorch 下可以用torch.cuda.empty_cache()手动释放未使用的显存。但要注意，频繁调用这个函数本身有开销，不建议每层都调。可以在显存接近上限时调用，或者每隔几层调一次。

另一个容易忽略的点是CUDA 上下文本身的显存占用。即使什么都不算，CUDA 上下文也要占几百 MB。所以实际可用显存要比标称值少一些。规划时要留出余量。

4.3 模型格式与兼容性

airllm 对模型格式有一定要求。它需要能够按层拆分模型权重，所以最好使用标准的 Hugging Face 格式（safetensors 或 pytorch bin）。如果模型是 GGUF 或其他量化格式，可能需要先转换。

另外，不同模型架构的层结构不同。有些模型有特殊的层（比如 MoE 架构的专家层），分层逻辑需要相应调整。airllm 对主流架构（LLaMA、GPT、BLOOM 等）支持较好，但冷门架构可能需要自己改代码。

提示：在下载模型之前，先确认 airllm 是否支持该架构。可以查看项目的文档或源码中的模型支持列表。如果不支持，要么换模型，要么自己实现分层逻辑。

4.4 长时间运行的稳定性

分层加载模式下，推理时间被拉长，长时间运行的稳定性就变得重要。我遇到过几个问题：一是磁盘过热导致读取速度下降；二是内存泄漏导致显存逐渐被占满；三是长时间运行后系统进入休眠，中断推理。

针对这些问题，可以做一些防护：确保机箱散热良好，尤其是 NVMe SSD 的散热；在代码里定期检查显存占用，必要时重启推理进程；关闭系统休眠，或者用工具保持系统唤醒。

5. 这类方案真正适合的场景，以及它的边界

5.1 适合的场景：显存受限但存储充裕

airllm 最适合的场景很明确：显存小，但存储快且容量大。比如一张 8GB 的卡，配一块 1TB 的 NVMe SSD，想跑 13B 或 30B 的模型。这种情况下，常规方案要么跑不起来，要么量化后效果打折，而分层加载能保持原始精度跑起来。

另一个适合的场景是多模型切换。因为模型权重存在磁盘上，切换模型只需要换一个目录，不需要重新加载到显存。这对于需要频繁切换不同模型的场景（比如对比测试）比较友好。

还有一个场景是教学和演示。在资源有限的环境里，想演示大模型的推理过程，分层加载能让更多人看到实际效果，而不只是纸上谈兵。

5.2 不适合的场景：追求速度和并发

如果追求推理速度，airllm 不是好选择。它的速度受 I/O 限制，比常规推理慢一个数量级。对于需要低延迟的场景（比如实时对话），体验会比较差。

如果要做并发推理，airllm 也不合适。因为每一层都要加载和释放，多个请求同时进来会导致 I/O 竞争，速度进一步下降。这种情况下，要么用更大的显存跑常规推理，要么用专门的推理服务框架。

还有一个不适合的场景是频繁的小批量推理。如果每次只推理几个 token，那加载整层权重的开销就显得特别大，性价比很低。分层加载更适合一次性生成较长文本的场景。

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

airllm 不是孤立的方案，它可以和其他显存优化技术组合使用。比如：

• 量化 + 分层加载：先量化降低单层大小，再分层加载进一步降低峰值显存。代价是精度损失和速度下降叠加。
• 梯度检查点 + 分层加载：梯度检查点主要用于训练，但推理时也可以用类似思路减少激活值占用。
• CPU offload + 分层加载：把部分层放在 CPU 内存里，需要时再传到 GPU。这和分层加载思路类似，但粒度更细。

这些组合方案各有取舍，需要根据具体硬件和需求来选。我的建议是：先用最简单的方案跑通，再根据瓶颈逐步优化。不要一上来就堆砌各种技术，那样调试起来很痛苦。

5.4 我对这类方案的实际体会

用了一段时间 airllm 之后，我最大的体会是：它解决的是“有没有”的问题，而不是“好不好”的问题。在显存受限的情况下，它让原本跑不起来的模型跑起来了，这个价值是实实在在的。但如果显存足够，我不会选它，因为速度差距太明显。

另一个体会是：存储介质的选择比参数调优更重要。同样的代码，放在机械硬盘和 NVMe SSD 上，速度可能差十倍。所以如果决定用这类方案，先把存储升级到位，比调任何参数都有效。

最后一点：这类方案适合个人开发者和小团队做实验、做 demo，但不适合生产环境的高并发服务。生产环境下，要么用足够的显存跑常规推理，要么用专门的推理优化框架。分层加载的定位是“资源受限时的可行方案”，而不是“通用最优解”。

如果你也在显存受限的环境下折腾大模型，不妨试试这个思路。它不一定是最快的，但可能是最能让你“先跑起来”的。跑起来之后，再根据实际瓶颈去优化，比一开始就追求完美要务实得多。