AirLLM：4GB 显存跑 2.8T 大模型——大模型推理的硬件门槛正在被调度算法打破

Fri, 23 Oct 2026 20:50:00 +0800

先给结论：AirLLM 证明了一个被行业长期回避的问题——“能不能让每个人用消费级硬件跑大模型”——答案是可以的，代价是速度。

它让 70B 模型跑在 4GB 显存、2.8T 的 Kimi K3 跑在 3.72GB 显存——不量化、不蒸馏、不剪枝。只改了一件事：推理时，一次只把一个 Transformer 层放进 GPU。

项目 40,000+ Star，从 2023 年 11 月到 2026 年 10 月，三年间把"不可能"的边界从 70B 推到了 2.8T。

一、一个显存问题

大模型推理的显存瓶颈是老问题。一个 70B 参数的 Llama 模型，FP16 下需要 140GB+ 显存。这意味着你要么租 A100/H100 集群，要么量化到 4bit 用 llama.cpp，要么放弃本地部署。

AirLLM 走了第四条路：不改模型，改调度。

二、逐层推理：一层一层来

标准 Transformer 推理中，所有层的权重必须同时驻留 GPU 显存——因为每个 token 要顺序穿过每一层。

AirLLM 把这一假设打破了：

flowchart LR
 subgraph GPU["GPU (4GB)"]
 direction TB
 L1["Layer 1"]
 L2["Layer 2"]
 Ln["Layer N"]
 end
 Disk["磁盘 (完整模型)"]
 Act["中间激活 (hidden state, 很小)"]

 Disk -->|"加载 layer 1"| L1
 L1 -->|"前向传播"| Act
 L1 -.->|"卸载"| GPU
 Disk -->|"加载 layer 2"| L2
 L2 -->|"前向传播"| Act
 L2 -.->|"卸载"| GPU
 Act -->|"…继续"| Ln

核心循环：

for layer in model.layers:
 1. 从磁盘加载 layer 权重 → GPU
 2. 在当前 hidden state 上执行前向传播
 3. 卸载 layer 权重（释放显存）
 4. 保留中间激活（只有 hidden state，很小）

峰值显存 = 一层权重 + KV cache + 中间激活。

70B 模型 80 层，每层约 875M 参数，FP16 下约 1.75GB。加上 KV cache 和激活，轻松塞进 4GB。

代价是速度——每层都要做一次磁盘到显存的搬运。逐 token 延迟从毫秒级变成秒级。但对批处理、离线分析、代码审查这类场景，这个 trade-off 完全可接受。

三、MoE 的进一步压缩

对 MoE 模型，AirLLM 做了 per-expert streaming：只加载当前 token 实际路由到的 expert 权重。

Kimi K3 是 2.8T 参数的 MoE 模型，但每个 token 实际触发的 expert 只有很小一部分。通过 per-expert streaming，2.8T 模型被压到了 3.72GB 显存——这让它成为目前开源模型中最大的单卡推理案例（2026 年 7 月上线）。

Qwen3.8-Flash-Next (125B MoE + 51B PLE n-gram 嵌入) 的显存需求是 5.95GB。其中 n-gram 表通过 file-mapped 方式留在宿主内存（64GB 机器即可），decoder 层流式调度。

四、实测数据：从 8B 到 2.8T

模型	参数量	所需显存	测试硬件
Qwen3 / Mistral / Phi	≈8B	~1–2 GB	—
Qwen3-30B / Mixtral (MoE)	30–47B	~1–3 GB	—
Qwen3.8-27B (dense VL)	27B	3.33 GB	RTX 3090
Qwen3.8-Flash-Next (MoE + PLE)	~180B	5.95 GB	RTX 4090
Qwen3-235B (MoE)	235B	~3 GB	—
Llama 3.x 70B (全精度)	70B	~4 GB	—
Llama 3.1 405B	405B	~8 GB	—
DeepSeek-V3	671B	~12 GB	—
Kimi K3	2.8T	3.72 GB	RTX 6000 Ada

所有模型同一条 API：AutoModel.from_pretrained(...)，不需要特殊配置。

五、从推理到训练：小显存微调大模型

2026 年 9 月新增的能力：在 6GB 显存下 LoRA 微调 125B 模型。

from airllm import AirLLMLoRAQwen4Exp

trainer = AirLLMLoRAQwen4Exp(
 "Qwen/Qwen3.8-Flash-Next",
 max_seq_len=512,
 lora_r=16,
 delete_original=True,
)

原理：冻结的基座权重逐层从磁盘流式读取，只有 LoRA adapter 驻留显存。Qwen3.8-Flash-Next (125B) 在 6GB 下可训练，Qwen3.8-27B 在 ~2GB 下可训练。

这不是 Hugging Face Trainer + bitsandbytes QLoRA——它是自己实现的推理-训练混合调度。训练数据可以是 .jsonl（每行一个 JSON object）、指令-补全对，或者 .txt 文件。

六、项目结构与代码质量

从仓库结构看，这是一个持续维护、有清晰架构的项目：

air_llm/
├── airllm/
│ ├── airllm_base.py # 基类：逐层加载 + 卸载的核心逻辑
│ ├── airllm.py # Llama 系列实现
│ ├── airllm_qwen*.py # Qwen 各代适配
│ ├── airllm_mistral.py # Mistral / Mixtral
│ ├── airllm_chatglm.py # ChatGLM
│ ├── airllm_baichuan.py # Baichuan
│ ├── airllm_internlm.py # InternLM
│ ├── airllm_kimi_k3.py # Kimi K3 (per-expert streaming)
│ ├── airllm_llama_mlx.py # MacOS MLX 后端
│ ├── airllm_lora.py # LoRA 训练框架
│ ├── auto_model.py # 自动检测模型类型
│ ├── persist/ # 模型持久化 (safetensors / MLX)
│ └── utils.py
├── examples/ # 推理示例、训练脚本
└── tests/ # 单元测试 + notebook 测试

关键工程特征：

AutoModel 自动检测模型类型，不需要手动指定 class
prefetching 重叠加载与计算，10% 的速度提升
模型压缩（block-wise quantization），推理速度提升 3x
MacOS MLX 后端，Apple Silicon 原生支持 70B
test suite 覆盖多 transformers 版本和 torch 版本，包括 notebook 回归测试

代码风格偏 Kaggle 风格（项目致谢 SimJeg 的 Kaggle 竞赛代码），但架构清晰、分层合理。

七、三年演进

时间	里程碑
2023/11	初始版本，70B @ 4GB
2023/12	v2.0 压缩加速 3x；AutoModel；ChatGLM/QWen/Baichuan/Mistral/InternLM
2024/04	Llama3 70B @ 4GB
2024/07	Llama3.1 405B @ 8GB；8bit/4bit 量化
2024/08	Qwen2.5；CPU 推理
2026/06	v3.0：FP8 支持，DeepSeek-V3 671B @ ~12GB，Qwen3-235B @ ~3GB
2026/07	Kimi K3 (2.8T) @ 3.72GB
2026/08	Qwen3.8-27B dense VL @ 3.33GB；Qwen3.8-Flash-Next (125B) @ 5.95GB
2026/09	小显存训练：125B LoRA @ 6GB

从 70B@4GB 到 2.8T@3.72GB，边界推了 40 倍。

八、该用还是不该用

适用场景：

本地代码审查：MacBook Air 上跑 Llama 70B 做 code review
离线文档处理：预算服务器上跑大模型做批量分析
模型评测：不用云 GPU 跑 benchmark
教育/研究：低成本实验大模型行为
隐私敏感场景：数据不出本地
小显存微调：6GB 下 LoRA 训练 125B 模型

不适用场景：

实时推理（逐 token 秒级延迟，不是毫秒级）
高并发服务（单卡串行调度）
对延迟敏感的在线产品

与 llama.cpp / GGUF 的关系是互补：追求速度选 llama.cpp，追求模型规模和精度选 AirLLM。

总结

AirLLM 回答了一个被回避的问题：模型规模的瓶颈正在从硬件转向调度算法。 当 2.8T 模型能在 3.72GB 显存上跑起来时，“我没有 A100 所以跑不了大模型"这个借口就不存在了。

代价是速度。但"能跑"和"跑得快"是两个不同的问题——AirLLM 解决了前者。后者，留给硬件迭代。

@software{airllm2023,
 author = {Gavin Li},
 title = {AirLLM: scaling large language models on low-end commodity computers},
 url = {https://github.com/lyogavin/airllm/},
 year = {2023},
}

显存优化 on 我的博客