AirLLM 技术拆解：单张 4GB GPU 如何跑 70B 大模型

核心判断

AirLLM 不是把模型"塞进"显存，而是把模型"流过"显存。它把 70B（700 亿）参数的模型按 Transformer 层切分后存放在磁盘上，推理时只把当前计算层加载进 GPU，算完就丢弃，再加载下一层。因此 GPU 显存只需容纳单层参数——这是它能在 4GB 显存上跑 70B 模型的根本原因，也是它和 vLLM、TGI、TensorRT-LLM 这类"整模型驻留显存"路线的本质分歧。

代价同样明确：层与层之间的磁盘 I/O 和模型加载开销会显著拉高单 token 的首字延迟（time-to-first-token），并限制吞吐。AirLLM 适合显存受限但对延迟不敏感的场景（离线批处理、研究复现、个人开发者跑大模型），不适合在线实时对话。

下文拆解它如何做到这一点，又在哪里付出了代价。

问题背景：大模型推理的显存墙

大模型推理的显存占用主要由四部分组成：

1. 模型权重：FP16（16 位浮点）下每参数占 2 字节，70B 模型约 140GB；BF16/FP16 是当下主流精度。
2. KV Cache（键值缓存）：推理时为避免重复计算注意力键值而缓存的中间状态，长序列下随上下文长度线性增长。
3. 激活值（activation）：前向计算过程中的中间张量，受 batch size 与序列长度影响。
4. 运行时开销：CUDA context、框架运行时、显存碎片等。

业界的主流优化方向几乎都集中在让 1 和 2 更小：

• 量化（quantization）：把 FP16 压到 INT8（8 位整数）、INT4、FP8（8 位浮点），用精度换显存。代表：GPTQ、AWQ、BNB（bitsandbytes）nf4。
• 剪枝（pruning）：砍掉不重要的权重或层。
• 蒸馏（distillation）：用小模型模仿大模型的行为。
• PagedAttention：vLLM 的方案，把 KV Cache 像虚拟内存一样分页管理，减少碎片。
• 张量并行 / 流水线并行：把模型拆到多卡上。

AirLLM 走的是另一条路——逐层加载（layer-wise loading）：不改模型精度、不改模型结构、不改并行拓扑，只是把"整模型驻留显存"这个隐含假设替换为"一次只驻留一层"。权重总数没变，磁盘占用没变，但峰值显存需求被压到单层大小。

核心原理：逐层加载如何突破显存限制

一、传统推理的显存模式

主流推理框架（HuggingFace Transformers、vLLM、TGI）加载模型时，会在初始化阶段把所有权重从磁盘读入 GPU 显存并驻留。70B FP16 模型约 140GB，这就是为什么一般要求多张 A100/H100 或者至少一张 80GB 的 A800。

二、AirLLM 的层流式模型

AirLLM 重新组织了加载流程：

1. 磁盘存储：模型按 Transformer layer（解码器层）切分，每个 layer 的权重（attention + FFN，即前馈网络）单独保存为 safetensors（一种安全的张量存储格式）分片。
2. 推理循环：每生成一个 token，依次执行每一层——
   • 把当前 layer 的权重从磁盘读入 GPU 显存；
   • 完成该层的前向计算；
   • 释放该层权重（Python 引用解除，触发显存回收）；
   • 加载下一层。
3. 流水线掩盖 I/O：为了不让磁盘读取成为纯阻塞开销，AirLLM 使用异步预取（asynchronous prefetch）把下一层的加载与当前层的计算重叠——一边算当前层，一边把下一层往 GPU 上搬。

对 70B 模型，FP16 下大约有 80 层（以 Llama 3 70B 为例），每层权重约 1.7GB 左右。算上 attention 计算中的临时激活和 KV Cache，峰值显存基本由"单层权重 + 当前层的 KV Cache + 激活"决定，这就是 4GB 跑 70B 的来源。

三、和主流方案的对比

逐层加载没有量化精度损失，不依赖特殊硬件，对显存极小的设备（消费级 GPU、Apple Silicon 入门款）特别友好。

压缩加速：4bit/8bit block-wise quantization 的 3x 加速

逐层加载解决了"显存放不下"的问题，但代价是吞吐下降——每一层都要做一次磁盘→GPU 的搬运。AirLLM v2 引入了**块级量化（block-wise quantization）**作为可选的"加速档"。

一、压缩机制

• 4bit/8bit block-wise quantization（块级量化）：在逐层加载的基础上，对每层权重再做 4bit 或 8bit 量化。量化在加载过程中完成（即"边加载边反量化"），所以显存里驻留的仍然是反量化后的 FP16/BF16 张量，计算图保持 FP16 精度。
• 压缩效果是把磁盘上的层大小减到原来的 1/4（4bit）或 1/2（8bit），意味着单层加载时间成比例下降。

二、3x 加速的来源

官方声称的"最高 3x 推理加速"主要来自三处叠加：

1. I/O 时间缩短：权重体积变小，磁盘读取和 PCIe（GPU 与 CPU/磁盘之间的高速总线）传输的字节数变少，瓶颈被压缩。
2. 更激进的多层预取：层变小了，磁盘带宽允许同时预取更多层到 host memory（主机内存）或 pinned memory（页锁定内存，加快 CPU↔GPU 拷贝），流水线更容易"喂饱" GPU。
3. 冷启动延迟降低：模型初始化阶段不必把所有权重加载进显存，可以一边推理一边从量化分片中按需恢复。

需要强调的是，3x 是上限值，受磁盘速度（NVMe SSD 优于机械硬盘）、PCIe 世代（PCIe 4.0/5.0）、CPU 解压能力影响很大。机械硬盘或慢速网络盘上做逐层加载，速度会被 I/O 直接打回原形。

三、v3.0 的新能力

2026 年 6 月发布的 v3.0 把这条路线继续推进：

• FP8 模型原生支持：原生加载 FP8 精度的预训练模型，权重体积比 FP16 再小一半。
• DeepSeek-V3（671B）：MoE（Mixture of Experts，混合专家）架构的 671B 模型，FP8 下通过逐层加载只需约 12GB 显存。
• Qwen3-235B：235B 参数的稠密模型，只需约 3GB 显存。
• 更强的预取调度：对 MoE 模型的"专家路由（expert routing，每次前向只激活部分专家）“做了优化，避免预取未激活的专家层。

性能权衡：延迟 vs 显存的取舍

逐层加载本质上是用延迟换显存。理解这条曲线有助于判断它是否适合你的场景。

一、首字延迟显著放大

以 70B FP16、4GB GPU、单层 ~1.7GB 为例：

• 每生成一个 token，要依次加载 80 层，每层都涉及磁盘读 + PCIe 传 + GPU 初始化。
• 即使有预取掩盖，纯 I/O 等待也会让单 token 时间从几十毫秒（整模型加载下）上升到几百毫秒甚至秒级。
• 对交互式对话（用户期望 100ms–500ms 首字响应），这个延迟通常不可接受。

二、吞吐受限但可批处理

• 单流推理下，逐层加载的吞吐主要受 I/O 限制，硬件不变情况下很难进一步压低单 token 时间。
• 但 AirLLM 支持多流批处理（multi-stream batching）——同一时刻跑多个独立推理流，每一层的计算和另一流的 I/O 可以错峰，对总吞吐有改善。
• 离线场景（一次性生成几千条数据、长文摘要、数据集标注）下，这种取舍是划算的。

三、磁盘是新的"显存”

可以理解为：AirLLM 把显存约束转嫁到了磁盘带宽和容量。模型权重的"工作集"仍然在磁盘上，只是把"全量驻留显存"换成了"按层滚动"。这意味着：

• 模型文件必须常驻本地磁盘，不能放在慢速网络盘。
• NVMe SSD 几乎是必需品，SATA SSD 也能跑但延迟更高。
• Apple Silicon（M1/M2/M3/M4）走 unified memory（统一内存）架构，把磁盘 I/O 走 SSD，吞吐也不错。

适用场景与边界

一、典型适用场景

• 个人开发者在小显存设备上跑大模型：MacBook 16GB、Apple Silicon、单张消费级显卡（3060/4060 8GB、3060 12GB 等）。
• 离线批量推理：数据标注、批量摘要、长文档分析，对单条延迟不敏感。
• 研究和复现：低预算实验室验证 70B+ 模型行为。
• 资源受限环境部署：在没有 80GB 级显卡的边缘节点或开发机上提供大模型能力。
• 显存扩容前的临时方案：采购 80GB 显卡前先用 AirLLM 跑起来。

二、不适合的场景

• 实时对话 / 聊天产品：首字延迟太高。
• 高并发在线服务：逐层 I/O 会成为瓶颈，QPS（每秒查询数）受限。
• 需要低延迟流式输出（streaming）逐字显示的场景：可以输出流式，但每个字的间隔仍受逐层加载影响。
• 极慢磁盘或网络盘：I/O 会被打回原形。

三、安装与上手

pip install airllm

from airllm import AutoModel

# 单卡 4GB 即可加载 70B 模型
model = AutoModel.from_pretrained(
    "meta-llama/Meta-Llama-3-70B-Instruct"
)

# 单次推理，按层加载、生成
input_ids = ...
output = model.generate(
    input_ids,
    max_new_tokens=128,
)

AirLLM 同样支持 macOS Apple Silicon，原生兼容 Linux + macOS 双平台。模型清单覆盖 Llama 3.x/4、Qwen3、DeepSeek V2/V3、Phi-4、Gemma、ChatGLM、Mistral 等主流架构。

结论

AirLLM 给出了一条与众不同的推理路线：不压模型、只压显存驻留时间。它的本质是把整模型加载变成了 Transformer 层的流式管道，用磁盘带宽和异步预取掩盖单层加载开销，换来极低的峰值显存需求。

这条路线在 v2 引入块级量化后变得更实用，在 v3 加入 FP8 与 MoE 路由优化后扩展到了 671B 级别。对于显存受限、延迟不敏感的离线推理与研究场景，AirLLM 是当下最务实的选择之一；对于实时在线服务，它并不是合适的技术栈——这时 vLLM、TGI、TensorRT-LLM 仍是更优解。

理解 AirLLM 的关键不在于它"用了什么魔法"，而在于它重新定义了推理过程中的显存假设：GPU 显存不需要装得下整个模型，只需要装得下一层。