AirLLM 让 70B 模型跑进 4GB 显存：从原理到实战

AirLLM 的 README 开头有一句听起来难以置信的话：

AirLLM 大幅降低了推理时的内存占用，让 70B 大语言模型可以在单张 4GB GPU 上运行——无需量化、蒸馏或剪枝。

那我们就来实际验证一下。这个说法是真的吗？该如何配置？还有一个很少有人认真追问的问题——你真的应该这么做吗？

TL;DR：从技术上看，这个说法是真的，背后的工程实现也确实可靠。

原理，用一段话讲清楚

Transformer 本质上就是由一层层网络堆叠而成，并且按照顺序逐层运行。

Input → Layer 1 → Layer 2 → Layer 3 → ... → Layer 80 → Output

当 Layer 1 正在计算时，Layer 2 到 Layer 80 只是……待在你的 VRAM 里。什么也不做，却一直占用空间。

常规推理会把全部 80 层都加载进 GPU 显存，因为将它们留在显存中速度最快。AirLLM 接着提出了一个显而易见的问题：如果不这么做呢？加载 Layer 1，运行，然后丢弃；再加载 Layer 2，运行，然后丢弃。

这样一来，你需要的 VRAM 就不再是“整个模型的大小”，而是“最大单层的大小”。

对于一个使用完整 FP16 精度的 70B 模型，每层大约需要 1.75GB，放进 4GB 显存绰绰有余。整个模型依然有 140GB——只不过它待在磁盘里，而不是 GPU 上，并且每次只流式加载其中的一小部分。

就是这样。这就是它的全部思路。而且它确实能运行。

事实核查：这个说法是真的吗？

是的——但后面要加一个和模型本身一样大的星号。

我们逐条分析这些说法。

“在单张 4GB GPU 上运行 70B”

是真的。计算结果对得上（FP16 下每层约 1.75GB），而且已经有足够多的人独立复现，因此这一点没有争议。

“无需量化、蒸馏或剪枝”

是真的，而这才是真正有意思的部分。大多数“在小型硬件上运行大模型”的技巧，都是通过牺牲模型质量实现的——例如把权重从 16 bit 压缩到 4 bit，这会损失一部分准确率。AirLLM 不必这么做。你可以使用真正未经修改的全精度模型。

（这里也可以选择量化——你可以传入 compression='4bit' 来提高速度。但这不是必需的，而这正是他们想强调的区别。）

更大的模型也一样

README 中的扩展规模表看起来很离谱，但它遵循的是同一套逻辑：

有没有注意到一个奇怪的地方？拥有 2.8 万亿参数的模型，需要的 VRAM 反而比 671B 模型更少。

这不是错误。它们是 Mixture-of-Experts 模型。一个 MoE 层包含数百个“专家”子网络，但每个 token 只会被路由到其中少数几个。根据 v3.1.0 的 release notes，Kimi K3 每层拥有 896 个专家，每个 token 只会路由到其中 16 个——因此，尽管完整一层的所有专家展开后约为 55GB，单个 token 实际只需要其中约 1GB。AirLLM 只会流式加载这些被选中的专家，而不是加载整个层。

模型越稀疏 → 工作集越小 → 所需 VRAM 越少。虽然反直觉，但确实如此。

标题没有告诉你的事

下面这部分不会出现在醒目的粗体宣传语里。根据 AirLLM 自己的 v3.1.0 release notes，在 RTX 6000 Ada 上测得：

明确说一下这意味着什么：生成一段 100 个 token 的回复，需要略多于 8 小时。

该肯定的地方还是要肯定——维护者在 release notes 中如实公布了这个数据。只不过营销宣传语里没有提到它。

在更常见的配置下，社区报告的数据大致落在以下范围：

70B 模型运行在性能不错的 NVMe 上：每个 token 大约需要 5～35 秒

70B 模型运行在 MacBook 上：有报告低至约 0.07 tokens/sec（约 14 s/token）

作为对比，使用 llama.cpp 在 RTX 4090 上运行量化后的 70B 模型：每秒 8～15 个 token

因此，更诚实的说法应该是：

AirLLM 并没有让 70B 模型在 4GB GPU 上跑得很快。它只是让 70B 模型在 4GB GPU 上运行成为可能。

为什么这么慢（只要算一次，以后你就不会再困惑）

这一点值得真正理解，因为它可以解释所有问题，而且并不复杂。

为了生成一个 token，模型必须运行每一层。这意味着 AirLLM 每生成一个 token，都必须从磁盘读取整个模型。

seconds per token ≈ model size on disk ÷ disk read speed

代入一个 FP16 的 70B 模型（约 140GB）：

你的磁盘就是推理引擎。GPU 几乎没怎么工作——它大部分时间都在空闲等待数据。这就是为什么 AirLLM 用户会报告风扇狂转、笔记本几乎无法使用：瓶颈在 I/O 和 CPU，而不是计算能力。

从这个公式可以直接推导出两个结论：

使用 compression='4bit'。它会将需要读取的数据量缩小约 4 倍。README 宣称速度最高可提升 3 倍，现在你也清楚原因了——这并不是计算变快了，而是需要搬运的数据变少了。

RAM 才是你真正值得升级的东西。如果系统 RAM 能容纳模型的很大一部分，操作系统的 page cache 就可以直接从内存提供这些层，而不是从磁盘读取。这就是为什么拥有 128GB 内存的用户，报告的性能会远好于根据纯磁盘速度计算出的结果。

开始之前，请先阅读这些要求

磁盘空间是最容易坑到你的地方。AirLLM 会先下载模型，然后把它拆分成按层存储的分片。在一段时间内，这两份数据会同时存在于磁盘上。

对于一个 FP16 的 70B 模型，请预留：

~140GB (original download)
+ ~140GB (layer shards)
= ~280GB free space

仓库 FAQ 中最常见的错误——safetensors_rust.SafetensorError: Error while deserializing header: MetadataIncompleteBuffer——根据维护者的说法，几乎总是因为磁盘空间耗尽。

一块 NVMe SSD（不要用 SATA，更不要用 HDD）

尽可能多的系统 RAM

对于 Llama 之类的 gated models，需要准备 Hugging Face token

耐心。真正、发自内心的耐心。

pip install airllm

如果要获得 4-bit 压缩带来的速度提升（推荐——原因参见上面的计算）：

pip install -U bitsandbytes

from airllm import AutoModel

model = AutoModel.from_pretrained(
    "Qwen/Qwen3-32B",
    compression='4bit',        # ~3x faster; skip for full precision
    delete_original=True,      # deletes the original after splitting — saves ~50% disk
    profiling_mode=True,       # logs per-layer timing so you can see the bottleneck
)

input_text = ['What is the capital of United States?']

input_tokens = model.tokenizer(
    input_text,
    return_tensors="pt",
    return_attention_mask=False,
    truncation=True,
    max_length=128,
    padding=False,             # avoids a common tokenizer error
)

generation_output = model.generate(
    input_tokens['input_ids'].cuda(),
    max_new_tokens=20,
    use_cache=True,
    return_dict_in_generate=True,
)

print(model.tokenizer.decode(generation_output.sequences[0]))

这就是完整的 API。切换到 671B 模型只需要修改一行：

model = AutoModel.from_pretrained("deepseek-ai/DeepSeek-V3")   # 671B, ~12GB VRAM

请从小模型开始。先运行一个 8B 模型，验证你的环境配置是否正确，然后再投入 280GB 磁盘空间和几个小时去下载 70B 模型。

3. 实用配置项

常见错误解析

仅适用于 Apple Silicon。安装 mlx 和 torch，并确保你使用的是原生 Python，而不是通过 Rosetta 运行的 Python。除此之外，代码保持不变。

值得尝试吗？

这完全取决于你属于下面哪一种人。

如果你只是想和大模型聊天，那就跳过它

这是最容易吸引人入坑的幻想，但它根本行不通。交互式聊天需要大约 20+ tokens/sec。AirLLM 每生成一个 token 却需要几秒甚至几分钟。你不可能用它进行正常对话。

如果你要处理大量任务，也请跳过它

每生成一个 token，都要从 SSD 读取数十 GB 的数据。消费级 NVMe 硬盘的可写入总量是有限的；让它持续读取完整模型并反复重写分片，并不是它原本被设计来承受的工作负载。此外，在运行期间，你的机器实际上也会变得无法正常使用。

它确实非常适合离线批处理任务

这才是它真正的使用场景，而且其价值被低估了。

最关键的洞察在于：昂贵的是加载一层，而不是使用这一层。因此，如果你加载 Layer 1 后，先让 50 个 prompt 都通过这一层，再继续处理下一层，就可以把加载成本分摊到 50 个任务上。

一项公开的 benchmark 显示：处理单个 prompt 时需要 35 s/token，而批量处理 50 个 prompt 时只需要 5.3 s/token——无需额外成本就获得了 6.6 倍的提升。

所以，如果你有 10,000 份文档需要在一夜之间完成分类，同时又没有 GPU 预算，那么 AirLLM 确实是一个合理的工具。当没有人在等待结果时，延迟就不再重要。

如果你明确需要完整精度，它也非常有价值

例如研究量化带来的影响、保证数值可复现性，或者按照模型发布时的原始状态进行评估——在这些场景中，使用 4-bit 近似模型会直接违背任务目的。AirLLM 几乎是唯一能让你在现有硬件上完成这些工作的方案。

这个说法是真的：4GB VRAM 运行 70B 模型，使用完整精度，也没有任何带有“欺骗”性质的花招。它的工程设计很巧妙，MoE 专家流式加载的实现也确实令人印象深刻。

问题在于它的宣传方式。“在 4GB GPU 上运行 70B 模型”会让人以为，只用廉价硬件就能获得 70B 模型质量的回答。而你实际得到的是：最终确实能获得 70B 模型质量的回答——但速度要用“每个 token 几分钟”来衡量，真正充当引擎的是 SSD，GPU 大部分时间都处于空闲状态。

AirLLM 并没有消除运行巨型模型的成本。它只是转移了成本——把成本从 VRAM 转移到了时间和磁盘 I/O 上。这笔交换是否划算，完全取决于你拥有的时间是否比金钱更多。

你真的在实体硬件上运行过它吗？欢迎在评论区分享你的 tokens/sec 和磁盘配置——社区报告的数据差异非常大，更多真实数据会很有帮助。

如果需要采取进一步措施，你可以考虑屏蔽此人和/或举报其滥用行为。