AirLLM：让 70B 大模型塞进 4GB 显存，Kimi K3 2.8T 也只要 3.72GB

发表于 分类于 ，
今天 GitHub Trending 上一款让社区反复刷屏的开源项目：仅靠「分层推理」把 70B 模型塞进单张 4GB 显卡，更支持 405B Llama 3.1、671B DeepSeek-V3，甚至把 2.8T 参数的 Kimi K3 跑到 3.72GB——这是把"大模型本地化"门槛彻底砸穿的一次工程胜利。

一张 4GB 显卡，能跑 70B 模型吗？

上个月我帮朋友搭一个本地 RAG，原计划很朴素：拿一张矿潮后的二手 RTX 3060（12GB 显存，三千元价位），跑一个 70B 的 Llama 3 拿来读他那一箱 PDF。结果真机一上手，整套流程在加载阶段就 OUT OF MEMORY——70B 的全精度权重光是搬到显存就要 140GB。

退而求其次，4-bit 量化到 35GB，依然塞不进 12GB；GGUF + 部分 CPU 卸载倒是能跑，但吞吐跌到每 token 几秒，朋友体验完只回了一句” 算了吧，我还是用 ChatGPT”。

直到刷到 GitHub Trending 上一个名叫 AirLLM 的项目，作者 Gavin Li 在 README 里写了一句让人瞳孔地震的话：

Run 70B large language models on a single 4GB GPU card — without quantization, distillation, or pruning.

不用量化、不用蒸馏、不用剪枝 —— 单张 4GB 显卡跑 70B。它是怎么做到的？这事为什么能跑得通、为什么不牺牲精度、又为什么能撑到 2.8T 规模的 Kimi K3？这篇文章就把 AirLLM 一次拆透。

项目背景：70B 模型到底卡在哪

要谈 AirLLM 的解法，先得看问题的反面 —— 为什么 70B 模型传统上” 必须” 装在高端卡上？

一个标准的 70B 模型以 FP16 精度保存，需要 140GB 磁盘，全部加载进显存也要 140GB VRAM。这就是 4-bit、3-bit、1-bit 量化技术之所以在过去两年成为显学：大家都在跟显存死磕。

但量化的代价是” 沉默的成本”——

  • 精度塌陷：4-bit 之下的量化在小模型还行，在 70B 这种” 全靠细节取胜” 的规模下，会有可感知的逻辑与数学下降；
  • 硬件门槛虚高：加载阶段 OOM 的问题被” 模型必须留 30% 余量” 反复放大，让” 我能跑 7B / 13B” 和” 我能跑 70B” 之间出现一道硬墙；
  • 冷启动昂贵：分布式多卡推理需要 NVLink、InfiniBand、统一的并行框架，对单机玩家极不友好。

Gavin Li 在 Hugging Face 博客里给出一个相当反直觉的观察：

A very large transformer is made of an embedding layer, many repeated transformer layers, and output layers. During inference, those layers are executed sequentially. Because only one layer is actively executing at a time, there is no need to keep the entire model resident in GPU memory simultaneously.

翻译一下就是：推理时 transformer 是一层一层串行执行的，任意时刻真正需要驻留在显存里的，其实只有” 当前那一片层”。剩下几十 GB 的” 沉睡权重”，完全可以放在磁盘或内存里等着被换入。

AirLLM 把这个观察工程化了 —— 核心思路就叫 Layer-wise Inference（分层推理）。

核心功能：AirLLM 的三层武器

1. 分层加载：显存需求 = 一片层大小，不 = 总体积

AirLLM 的关键代码只有几行（来自官方 README）：

1
2
3
4
5
6
7
from airllm import AutoModel

model = AutoModel.from_pretrained("Qwen/Qwen3-32B")

# 想再大？换一行就行：
# model = AutoModel.from_pretrained("Qwen/Qwen3-235B-A22B")  # 235B 模型，~3GB
# model = AutoModel.from_pretrained("deepseek-ai/DeepSeek-V3")  # 671B 模型，~12GB

它本质上是把 transformers 的模型预训练权重按层切成 sharded 文件（layer_shards_saving_path 可指定路径），第一次 from_pretrained 时只把当前 layer 装进 GPU、跑完前向、卸载、加载下一层。KV-cache 也会做精细的 layer-wise 管理，避免重复占用。

代价是吞吐：每生成一个 token，要在磁盘和显存之间来回倒。Gavin 在博客里也直说” 低端卡会很慢，更适合离线场景而不是对话机器人”。

2. 块状量化压缩：磁盘 IO 不是计算的瓶颈，是推理的瓶颈

分层推理的瓶颈被搬到磁盘 IO 上，所以单纯” 少装一层” 并不能压缩耗时。AirLLM v2.0 之后引入了 基于块状量化（block-wise quantization）的模型压缩（参考论文 arXiv 2212.09720）：

1
2
3
4
model = AutoModel.from_pretrained(
    "garage-bAInd/Platypus2-70B-instruct",
    compression="4bit",   # 或 "8bit"
)

为什么不做标准的 activation-aware 量化？因为 AirLLM 瓶颈在加载而不是计算 —— 只需要压缩” 权重” 就能提速，激活保持 FP16 不变。这意味着 loss 几乎不可察觉地上升，但推理速度可以提升 3 倍。

这也是 AirLLM 区别于 GPTQ/AWQ 的关键：它不打算让 GPU 算得更快，而是让 GPU 不必一直等磁盘。

3. MoE 流式加载：把 2.8T 模型也压进 3.72GB

2026 年 7 月的这次更新最炸裂 ——AirLLM 加入了 Kimi K3（2.8T） 支持，能在单张 RTX 6000 Ada（48GB 显存）上只用 3.72GB VRAM 就跑起来。

诀窍在于 K3 是稀疏 MoE—— 一个 token 只路由到少数几个专家。AirLLM 因此只需要把” 被路由到的那部分专家权重” 流式加载进显存，而不是整层模型：

  • 235B 的 Qwen3 MoE → ~3GB VRAM；
  • 671B 的 DeepSeek-V3 → ~12GB VRAM；
  • 2.8T 的 Kimi K3 → 3.72GB VRAM。

官方 README 把这一句摆在最显眼的位置：

Sparse MoE models stream one expert at a time rather than a whole layer.

这种” 按需流式” 的设计，让” 消费级显卡跑超大规模 MoE” 从一个梗变成了可复现的工具。

实战示例：30 秒启动自己的本地 70B

我把在自己机器上跑通的最简流程贴出来（macOS Apple Silicon 也支持，但要装 mlx）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# 1. 准备环境（建议 Python 3.10+，CUDA ≥ 11.7）
python -m venv .venv && source .venv/bin/activate
pip install -U airllm

# 2. 写下 inference.py
cat > inference.py <<'PY'
from airllm import AutoModel

MAX_LENGTH = 128
model = AutoModel.from_pretrained(
    "Qwen/Qwen3-32B",          # 任何 HF repo ID
    profiling_mode=True,        # 想看每层耗时打开这个
    delete_original=True,      # 磁盘吃紧就开，删掉切分前的原权重
)

prompt = "用一段话总结大模型推理显存优化的关键思路。"
input_tokens = model.tokenizer(
    prompt,
    return_tensors="pt",
    return_attention_mask=False,
    truncation=True,
    max_length=MAX_LENGTH,
    padding=False,
)
generation_output = model.generate(
    input_tokens["input_ids"].cuda(),
    max_new_tokens=128,
    use_cache=True,
    return_dict_in_generate=True,
)
print(model.tokenizer.decode(generation_output.sequences[0]))
PY

# 3. 跑（第一次会按层切分权重，第二次就快了）
python inference.py

第一次运行 from_pretrained 会把整个原始权重切分成 layer-wise shards，务必保证 HuggingFace cache 目录有足够磁盘 ——Qwen3-32B 大约 65GB，原权重要空间，shards 也要空间。

如果嫌慢，可以加 compression="4bit"：

1
2
3
4
model = AutoModel.from_pretrained(
    "garage-bAInd/Platypus2-70B-instruct",
    compression="4bit",
)

或者直接选一个本来就小的模型试水 ——Qwen3-8B、Phi-3、Mistral-7B 都能在～1–2GB VRAM 里跑。

适用场景和限制：看清边界再用

真正适合的场景

  • 本地离线 RAG / 长文档分析：朋友那个 PDF 仓库场景就属于这一类，吞吐量不重要，能在 4GB 卡上跑出 70B 质量是关键；
  • 学术研究和消融实验：要在不同大小的模型上做 ablation，又不想反复租 A100，AirLLM 把” 小机器也能跑大模型” 变成事实；
  • 企业内网私有化部署：数据不能出域、预算又不允许上 H100，AirLLM + 量化压缩能在 2–3 张消费级卡上把 70B 服务起来；
  • Apple Silicon 上的原型验证：配合 mlx，AirLLM 也能在 M2/M3/M4 上跑 70B，只是更慢，适合” 先验证、后选型”。

必须清楚的限制

  • 吞吐天花板低：单 token 需要一次” 换层”，所以单请求延迟远高于 vLLM/TensorRT-LLM。Gavin 自己说” 低端卡不适合对话机器人”；
  • 不能用来训练：训练需要每一层前向 + 反向的中间激活，不能只保留一层。AirLLM 是纯推理工具；
  • 首次分层慢：切权重是 IO 密集型操作，磁的 NVMe 是底线，HDD 不建议；
  • 闪存寿命：把百 GB 模型反复从 SSD 加载会显著消耗写入寿命，企业级 SSD 更合适；
  • 依赖版本敏感：最新 Kimi K3 支持需要 CUDA 12 的 torch、transformers 4.56.x、compressed-tensors、flash-attn，少一个就跑不起来。

如果你的场景是” 在线对话、低延迟、高并发”，请直接看 vLLM / SGLang / TensorRT-LLM；如果你想的是” 在 4GB 显存里把 70B 跑起来给老板交差”，AirLLM 现在是最务实的选择。

写在最后：把” 大模型普及” 的天花板抬高一截

AirLLM 不是要把 4GB GPU 变成 A100 集群，它的真实价值在于把” 硬件能力够用” 和” 模型规模必须用” 之间的耦合拆开 —— 一个 70B 模型不再需要一整张 H100，也不再需要退到 3-bit 量化丢精度，它只需要一张 4GB 卡和一份被工程化好的” 分层调度”。

更深一层看，AirLLM 的方向呼应了一个正在被反复验证的判断：

大模型的瓶颈，正在从” 算力” 转向” 调度与内存”。

当模型规模每几个月翻一倍，单卡显存却按年缓慢增长，谁能把” 算 vs 换” 的调度做漂亮，谁就能把更多模型拖进普通玩家的桌面。这一波从 AirLLM、到 vLLM 的 PagedAttention、再到 FlexGen，本质都是同一条主线上的工程回答。

如果你今天手头只有一张老旧显卡，又想做点严肃的本地推理，建议直接 pip install airllm 跑一下 —— 大概率会被那种” 它居然真的跑起来了” 的体验震到。

📌 项目主页：github.com/lyogavin/airllm
📖 作者博客：HuggingFace Blog: AirLLM
📚 关键论文：Block-wise Quantization (arXiv 2212.09720)