企业官网建设流程全解析

如果你手头只有一张 8GB 显存的显卡，却想把 70B 级别的大模型跑起来，大概率会被当成白日梦。但这个白日梦在 airllm 出现之后变成了可能。airllm 是一套面向大模型的分层推理方案，核心思路很简单：模型还是那个模型，但它不再要求你一次性把所有权重塞进显存，而是按层加载、算完就走。这篇内容就是冲着“把大模型在低显存上跑通”这个目标来的，我会把 airllm 的原理、部署过程、参数调整和实际踩过的坑逐一拆开讲。无论你是正在本地折腾大模型部署，还是被显存耗尽折磨得想换机器，这篇内容应该能帮你省下不少时间。

1. 为什么需要 airllm：大模型推理的显存困局

1.1 显存墙：先算一笔账

先别急着聊优化，我们得先把问题说透。一个 70B 参数的大模型，如果用 FP16 精度保存参数，单是模型权重就需要大约 140GB 存储空间。这是什么概念？很多人的整台机器磁盘都不一定有 140GB 空闲。而显存呢？市面上消费级显卡主流是 8GB、12GB、16GB，哪怕你咬牙上了 24GB 的旗舰卡，离 140GB 也差着一个数量级。

更麻烦的是，模型推理过程中不是只有权重占显存。当模型开始生成 token 的时候，还要产生 KV cache、中间激活值、临时计算缓冲，这些开销加起来又会占用几个 GB。所以常规做法是先把模型加载起来，再跑推理，而这一步就把绝大多数玩家挡在了门外。我给过一个朋友算账，他想在一张 8GB 显存的卡上跑 70B 模型，用标准加载方式，程序启动后不到三秒就报“CUDA out of memory”，这是硬性物理资源不够，不是写代码能解决的问题。

1.2 分层推理：一次只拿一层上桌

既然一次性装不下，那就拆开用。Transformer 模型的结构是层层堆叠的，数据必须依次通过第 1 层、第 2 层、第 3 层，直到最后一层。每一层都有自己的权重，而且层与层之间的依赖是顺序的：你现在在计算第 N 层的时候，完全不需要第 N+1 层的权重，只有当第 N 层计算完，数据才会传给第 N+1 层。

这个特性给了我们一个可乘之机：为什么不把模型拆成一层一层，在计算每一层时才把这一层的权重搬进显存，计算完立刻搬出去？就像你读书的时候，不需要把整本书所有页都摊在桌面上，一次翻一页，读完再翻下一页就行。airllm 的核心就是这个层级粒度的调度策略，它把“模型占用显存”的问题，转化成了“模型在 CPU 内存和 GPU 显存之间的流动”问题。显存只需要容纳当前层、来自上一层的中间结果、以及必要的缓存就够了。

1.3 只靠量化还不够

很多人会问：我直接用 4bit 量化不行吗？我们同样算一笔账。70B 模型用 4bit 量化后，权重大约需要 35GB，还是远超 8GB 显存。量化可以降低显存压力，但不能消除“整模型常驻”这个前提。还有一类做法是把模型整体放在 CPU 内存里，需要时把某个算子搬到 GPU 上算。这种方式的问题是粒度太粗，整个模型在 CPU 和 GPU 之间反复横跳，传输量巨大，而且每跳一次都要等同步，效率很低。

airllm 的思路是把“一次搬一块”的粒度从整模型细化到单层。单层权重通常只有几百 MB 到 1～2GB，在 PCIe 总线上传输的时间可以控制在几十毫秒级别。如果再配合异步预取，下一层权重在当前层计算时就已经在路上了，这样实际等待时间能进一步压缩。这个设计不是量化替代品，而是和量化正交的优化维度。

2. airllm 的核心机制与设计思路

2.1 CPU 负责存储，GPU 负责计算

airllm 最大的设计特点是 GPU 和 CPU 角色彻底分工。GPU 不再是一个“大仓库”，而是一个“计算单元”。模型全部权重一开始驻留在 CPU 的内存里，甚至在你显存极度紧张时可以驻留在磁盘上。推理开始后，airllm 会按顺序计算出当前需要哪一层的参数，然后将这层参数从 CPU 搬运到 GPU 的显存缓冲区，执行前向计算，计算完毕再把缓冲区释放掉，腾出空间给下一层。

这种分工的好处是，显存的“容量天花板”被完全绕开了。你不再需要显存大过模型，只要显存能装得下一层权重、KV cache 和计算开销，就能跑。我实际测试的时候，用一张 8GB 显存显卡，跑一个 70B 模型，显存占用峰值稳定在 6～7GB 左右。当然，CPU 内存的负担会重很多，因为所有参数都要放在内存里，70B 模型 FP16 需要 140GB 内存，这也不是每个人都有的配置。所以 airllm 还支持把部分权重放到磁盘上，相当于用磁盘空间换内存空间。

2.2 异步预取：让搬运和计算重叠

如果只是“按需加载”，那速度会非常难看。因为每一层都要等前一层算完才开始搬运，整个推理过程会变成“计算→等待搬运→计算→等待搬运”的串行链条。airllm 不是这么傻等，它做了一层异步预取：当 GPU 正在计算第 N 层时，CPU 侧已经在后台把第 N+1 层的权重搬到了靠近显存的地方，或者直接放到一个预留的显存缓冲区里。

这有点像咖啡店做手冲咖啡：顾客还在喝上一杯的时候，咖啡师已经提前把下一杯的豆子磨好了。只要预取距离足够远，传输时间就能被计算时间完全掩盖。理论上，如果 PCIe 带宽允许，单层传输耗时低于单层计算耗时，那整体推理速度就几乎不受搬移影响。当然，70B 层数很多，单层计算量不小，所以即使有些延迟，推理仍然能进行。异步预取最核心的价值在于，它把“每层都要等”的悲观情况变成了“大部分时间都在算”，这是 airllm 在低显存设备上依然能维持可用速度的关键。

2.3 层粒度切分和 KV cache 的取舍

airllm 默认在 Transformer 的 block 层粒度做切分，而不是更细的算子级别。这个粒度选择是为了平衡调度开销和灵活性。如果粒度太细，比如按矩阵乘法算子切，调度的开销会超过传输节省的时间；如果粒度太粗，比如把整个模型切成两半，显存压力又降不下来。按 block 层切，既能保证每层权重独立、不互相依赖，又能把调度频率控制在合理范围内。

KV cache 是另一个需要注意的点。生成每个 token 时，需要保存所有历史层的 key 和 value 向量。在分层推理的场景下，KV cache 不能简单丢在 GPU 上，因为它可能被后续所有层访问。airllm 通常将 KV cache 放在 CPU 内存，需要时再加载。这就带来一个权衡：KV cache 越大，显存占用越小，但访问延迟越高。好在 KV cache 的数据量比权重小一个量级，即使从 CPU 读取，也不会成为主要瓶颈。实际调参时，可以通过缩短生成长度、限制 batch 大小来控制 KV cache 规模。

3. 实操：从安装到跑通一个 70B 模型

3.1 环境准备：虚拟环境、Python 版本和依赖

先说明一点：airllm 对硬件平台相对友好，不需要多卡集群，也不需要特殊网络设备，普通台式机就能跑。但在软件层面，有几个前提条件需要提前确认。我建议使用 Python 3.10 版本，创建一个独立的虚拟环境，避免系统不同项目之间的依赖冲突。

conda create -n airllm python=3.10 conda activate airllm pip install airllm

执行完 pip install 之后，airllm 会自动安装 PyTorch、transformers 等相关依赖。不过这里有第一个值得注意的点：如果你机器上已经有了自定义编译的 PyTorch（比如为了配合某个特定 CUDA 版本），建议先单独安装匹配的 PyTorch，再安装 airllm，否则 pip 可能会拉取一版新的 PyTorch 覆盖掉你的环境。我的做法是，先创建虚拟环境，然后单独用官方命令安装与显卡驱动匹配的 PyTorch，确认torch.cuda.is_available()返回 True 之后，再安装 airllm。这样能把很多莫名其妙的兼容问题提前扼杀。

3.2 最小推理示例：把模型加载接口跑通

安装完成后，可以写一个最简单的推理脚本。airllm 提供了类似 transformers 的加载接口，下面这段代码是我实际测试时用过的：

from airllm import AutoModel from transformers import AutoTokenizer model_path = "/path/to/your/70b-model" tokenizer = AutoTokenizer.from_pretrained(model_path) model = AutoModel.from_pretrained(model_path) input_text = "人工智能的未来在于" inputs = tokenizer(input_text, return_tensors="pt") outputs = model.generate( inputs.input_ids.cuda(), max_new_tokens=64, do_sample=True, temperature=0.7, ) print(tokenizer.decode(outputs[0], skip_special_tokens=True))

AutoModel.from_pretrained接受一个本地模型路径。加载过程并不会一次性把所有权重塞进显存，它会在后台建立权重索引、读取元数据，并把参数分配到 CPU 内存或磁盘缓存中。这个初始化过程可能比较长，如果模型很大，比如 70B，从磁盘读取元数据就要花好几分钟。你看到程序在加载，不要急着中断，给它一点时间。

另外，我建议在正式跑大模型之前，先拿一个小的 7B 模型做冒烟测试。把同样的脚本换到小模型上，确认整个链路能通，再切回 70B。这样排查问题会快很多，不然一次加载就花十几分钟，心态容易崩。

3.3 关键参数与运行配置

airllm 的使用不是直接运行就完事，有几个参数会影响稳定性和速度。我把实际调优中感受最深的几个列在这里。

生成长度和 batch size

生成长度（max_new_tokens）直接影响 KV cache 大小。生成越长，KV cache 越大，显存占用越高。airllm 场景下建议保持 batch size 为 1，因为 batch 大于 1 时，多个序列会同时需要多份中间状态，显存压力会以倍数增长。如果你确实需要批量处理，需要调低生成长度，并且预留足够的 CPU 内存来存放 KV cache。

精度选择

模型加载时可以通过 dtype 参数指定浮点格式。FP16 速度最快，显存占用中等；如果模型权重本来就以 FP32 存储，可以先用 FP16 转一下，能省一半显存。当显存极度紧张时，可以考虑使用量化版的加载方式。airllm 会读取模型的量化配置，把每层权重转成更紧凑的格式。量化后每层体积变小，搬运时间也随之变短，但推理质量会有一定下降，这个取舍要结合你的实际任务判断。

磁盘缓存路径

如果 CPU 内存不够放下全部权重，airllm 会把部分层放磁盘。这时候磁盘速度就成了关键瓶颈。我建议把权重缓存放到 NVMe 固态硬盘上，不要放在机械硬盘上。机械硬盘顺序读取速度可能只有几百 MB/s，而 PCIe 4.0 NVMe 能到几 GB/s，这之间的差异直接反映在每层加载时间上。如果模型权重在内存放不下，磁盘路径选择不当，airllm 的执行速度会慢到几乎没法用。

异步开关和预取窗口

有些版本的 airllm 支持配置预取层数，也就是提前多少层开始搬运。默认值通常是 1～2 层，如果你的 PCIe 带宽较宽，适当调大预取窗口可以更好地掩盖传输延迟。但太大也没用，因为计算和传输的资源是有限的，盲目增大预取只会增加 CPU 内存压力。

3.4 我的一次实跑记录

下面是一组我近期在本地实测的数据，供参考。机器配置很简单：一张 8GB 显存的消费级显卡，CPU 内存 64GB，系统盘和模型盘都是 NVMe 固态。跑的模型是 70B 参数级别，加载时为 FP16 精度，没有额外量化。

看到这个速度你先别笑，1.4 token/s 确实不算快，但它能在一个以前完全不可能运行的硬件上跑出一个 70B 模型的真实输出，很多模型效果验证场景不需要实时交互，慢一点完全能接受。如果是 4bit 量化后的同样模型，速度可以提升到 2.5 token/s 左右，同时显存占用进一步降到 4GB 以内。也就是说，airllm 把“能不能跑”的问题先解决了，之后优化“跑多快”就有得玩。

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

4.1 加载过程中依然遇到 OOM

很多人会误以为用了 airllm 就绝对不可能 OOM，但实际情况没那么简单。就算权重不常驻显存，模型初始化阶段仍可能需要加载 embedding 表或者语言模型头。如果模型词表很大，这几个组件的体积也不小。另外，如果你在加载模型前已经用 PyTorch 初始化了一个大张量，显存里残留了其他进程的占用，也有可能把空间挤爆。

排查方法很简单，先运行nvidia-smi看看显存当前被谁占着，然后尽量保持环境干净。在代码里，我建议在加载模型之前执行一下：

import torch torch.cuda.empty_cache()

但empty_cache只能清理 PyTorch 自己缓存的碎片，不能释放别的进程占用的显存。如果显存还是不够，优先检查模型加载时是否设置了low_cpu_mem_usage或者是否局部加载了 embedding。实在不行就开启量化模式，把每一层的物理体积降下来，OOM 概率会小很多。

4.2 推理速度慢到难以接受

这是 airllm 最常见的吐槽点。速度慢的根本原因在于数据搬运开销没有被完全掩盖。如果你发现速度远低于预期，先检查权重存放介质。模型权重如果在磁盘里，每次加载一层都要读一次磁盘，哪怕 NVMe 也扛不住高频随机读取。解决办法很简单：把模型文件预先读入操作系统页缓存，或者明确让 airllm 使用 CPU 内存作为主缓存，让后台预取尽量从内存中读取。

另一个容易被忽略的点是 PCIe 通道配置。如果显卡插在 PCIe 3.0 x8 的插槽上，带宽比 PCIe 4.0 x16 低不少，传输一层权重就要多花一倍时间。可以查一下系统日志，确认显卡工作在正确的链路宽度。如果带宽已经是极限，那只能从减小传输量入手：量化、剪枝、甚至用更短的生成长度，都是有效手段。

4.3 模型下载中断或者文件损坏

很多开源模型体积极大，下载过程容易中断，或者下完以后文件不完整。airllm 在加载时如果读取到损坏的分片，通常会抛出一个解析异常。不要盲目重下整个模型，先检查模型目录下的分片文件大小和 SHA 校验值是否和源仓库一致。有条件的话，优先使用支持断点续传的下载工具，把模型完整落盘后再开始加载。

如果加载过程中报“unexpected EOF”或者“safetensors metadata read failed”，基本可以确定是文件问题。把所有分片文件删除重新下载，不要只补缺失的那一份，因为部分分片虽然看起来在，但可能已经损坏。截断的文件有时候系统不会报错，但模型加载时就会出现各种莫名奇妙的维度不匹配。

4.4 量化后模型输出劣化

当显存实不够时，量化是必然选择，但量化会让模型精度折损。不同任务对量化敏感度不一样，生成代码、数学推理这类任务通常更敏感，而闲聊、文本摘要这类任务影响相对小。我踩过的坑是同一套量化配置在不同模型架构上表现差异巨大，比如有的模型 embedding 层对量化特别敏感，稍微一量化，输出就开始胡言乱语。

遇到这种情况，建议先浏览算法层量化，保留 embedding 层和最后的 lm_head 层为 FP16。airllm 的加载接口一般支持细粒度配置，可以单独指定某些层不予量化。如果模型文件里已经包含量化权重，那你在推理时精度就基本固定了，只能换一种量化方案或使用混合精度策略。

5. 这套方案能走多远：使用体会和扩展建议

5.1 适合场景和不适合场景

airllm 不是万能药，它有非常明确的适用边界。如果你需要高并发、低延迟的生产级推理，AirLLM 完全不合适。它的本质是用时间换空间，吞吐能力有限，每生成一个 token 都要经历权重调度，不可能跟全显存驻留的方案拼速度。但如果你是以下场景，airllm 会非常香：本地开发调试、模型效果验证、教学演示、小团队推理实验、以及资源受限的边缘设备。

我自己用下来的体会是，airllm 最适合的定位是“模型试玩器”。比如你想对比两个 70B 模型的回答风格，又不想租好几张 A100，那 airllm 完全可以帮你把跑通流程走一遍。它不是生产环境的主角，却是开发阶段最省钱的临时替代品。

5.2 后续可以扩展的方向

空气llm 的分层理念还可以跟很多技术组合。比如结合投机采样，让一个小模型在本地生成草稿 token，大模型用小批量校验，能显著提高单位时间有效 token 数。再比如结合 KV cache 量化，把每层生成的缓存进一步压缩，减少 CPU 和 GPU 之间的交换量。还有一个思路是做多级流水：把模型按 block 分组，不同组分布在不同的计算设备上，消除单设备的调度瓶颈。

这些扩展方向听起来复杂，但都是建立在“分层加载”这个基础上的。airllm 其实打开了一个思路：不要总想着把模型整个塞进硬件，而是让数据流组织方式去适配硬件。这个思路在大模型越来越大的今天，会越来越有价值。

5.3 我给新手的几句实在话

第一，务必先用小模型跑通流程。我见过很多朋友一上来就搞 70B，结果环境问题、路径问题、显存问题混在一起，根本分不清是谁的锅。第二，记录好日志和运行耗时。airllm 的每个阶段都有信息输出，仔细观察是卡在加载还是卡在生成，能帮你快速定位瓶颈。第三，不要迷信“显存越大越好”，在分层推理的架构下，CPU 内存和磁盘速度同样重要。第四，如果生成速度实在太慢，宁愿先量化再跑，也不要把没量化的模型硬塞给机械硬盘。

最后再分享一个小技巧：在跑长时间生成任务时，可以手动设置PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True，这个环境变量能让 PyTorch 的显存分配更灵活，减少碎片化。配合 airllm 的分层加载，显存峰值能再稳一点。技术选型没有绝对好与坏，airllm 的存在只是证明了，硬件限制不应该是放弃大模型的唯一理由。