先给结论：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 把这一假设打破了：
核心循环：
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},
}