30K星airllm：4GB显存跑70B模型，2.8T的Kimi K3也能塞进去
30K星airllm：4GB显存跑70B模型，2.8T的Kimi K3也能塞进去
先收藏，回头一定用得上。
4GB 显存能跑什么大模型？
如果你用常规方式加载，4GB 连 7B 模型的完整权重都放不下。但 airllm 的答案是：70B。没错，七十亿参数的模型，4GB 显存就能推理。不需要量化、不需要蒸馏、不需要剪枝--模型权重是完整精度的。
更离谱的是，2026 年 7 月它更新了对 Kimi K3 的支持--这是一个 2.8 万亿参数（2.8T）的模型，迄今最大的开源模型。airllm 让它在单张 RTX 6000 Ada 上跑，显存占用 3.72GB。
这不是魔法，是一个简单但巧妙的工程思路：不把整个模型塞进显存，而是每次只加载一层。
本文提纲
- 核心原理：逐层流式加载
- 为什么显存需求取决于层大小而非模型大小
- MoE 模型的额外优势：专家流式
- 压缩加速：3 倍推理提速
- 支持的模型和硬件
- 代价是什么：速度
- 什么时候该用，什么时候不该用
核心原理：逐层流式加载
常规 LLM 推理的方式是把整个模型的权重加载到 GPU 显存里。一个 70B 模型在 FP16 下需要约 140GB 显存，相当于 2 张 A100 80GB。这对大多数人来说是不现实的。
airllm 的思路完全不同：模型放在硬盘/CPU 内存里，推理时每次只把当前层加载到 GPU，算完就丢弃，加载下一层。
graph LR
A["Disk / CPU RAM
Full Model Weights"] -->|load layer 1| B["GPU VRAM
Layer 1 only"]
B -->|compute| C["Forward Pass
Layer 1"]
C -->|discard| D["Free VRAM"]
D -->|load layer 2| E["GPU VRAM
Layer 2 only"]
E -->|compute| F["Forward Pass
Layer 2"]
F -->|discard| G["Free VRAM"]
G -->|load layer N| H["...continue"]
style A fill:#FF6B6B,color:#000000
style B fill:#4ECDC4,color:#000000
style C fill:#4ECDC4,color:#000000
style D fill:#FFEAA7,color:#000000
style E fill:#45B7D1,color:#000000
style F fill:#45B7D1,color:#000000
style G fill:#FFEAA7,color:#000000
style H fill:#96CEB4,color:#000000Transformer 模型是逐层计算的：输入先过第 1 层，输出传给第 2 层，再传给第 3 层……直到最后一层。既然每层的计算只依赖上一层的输出，那同一时刻 GPU 里只需要有一层权重就够了。
这就像读书--你不需要把整本书的每一页同时摊在桌上，一次翻开一页读完翻下一页就行。airllm 做的就是这件事，只不过翻的是神经网络层。
预取优化。 airllm 还加了 prefetching（预取）机制：在 GPU 计算当前层的同时，CPU 从磁盘预加载下一层的权重到内存。计算和加载重叠执行，节省了约 10% 的时间。这个优化目前只在 Llama2 类模型上支持。
为什么显存需求取决于层大小而非模型大小
这是 airllm 最关键的洞察。
一个 70B 模型有 80 层，每层约 1.75GB。常规加载需要 140GB 显存（80 层 × 1.75GB）。但 airllm 每次只加载一层，所以显存需求只有约 4GB--足够放下一层权重 + KV cache + 中间激活值。
这就是为什么 airllm 的显存表是这样的：
| 模型 | 总参数量 | 显存需求 |
|---|---|---|
| Qwen3 / Mistral / Phi (~8B) | 8B | ~1-2 GB |
| Qwen3-30B / Mixtral (MoE) | 30-47B | ~1-3 GB |
| 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 |
注意 Kimi K3 那一行：2.8T 参数的模型，显存只要 3.72GB，比 70B 的 Llama 还少。这不是笔误，是 MoE 架构带来的额外优势。
MoE 模型的额外优势：专家流式
MoE（Mixture of Experts）模型有一个特点：每个 token 只激活少数几个专家（expert），不是全部。DeepSeek-V3 有 256 个专家但每个 token 只用 8 个，Kimi K3 的路由比例类似。
常规推理时，你需要把所有专家的权重都加载到显存里--即使大部分专家这次推理根本用不上。这就是 MoE 模型虽然"激活参数"少但"总参数"巨大的原因。
airllm 对 MoE 做了针对性优化：per-expert streaming（逐专家流式加载）。 既然每个 token 只路由到少数专家，那就只加载这些被激活的专家权重，不加载其余的。
这对 Kimi K3 这种超大 MoE 模型效果尤其显著。2.8T 参数里，每个 token 实际只激活几十 B 的参数。airllm 只加载这些激活的专家，所以显存可以压到 3.72GB。
这个优化让 MoE 模型在 airllm 上的性价比远超 dense 模型。同样是 ~4GB 显存，dense 模型只能跑到 70B，MoE 模型可以跑到 2.8T。当然，2.8T 的"有效参数量"远小于 2.8T，但推理质量确实在 70B dense 之上。
压缩加速：3 倍推理提速
逐层加载解决了显存问题，但速度瓶颈转移到了磁盘 I/O--每层都要从磁盘读到内存再传到 GPU。
airllm 的解法是 block-wise quantization 压缩。和常规量化不同，它只量化权重，不量化激活值：
model = AutoModel.from_pretrained("Qwen/Qwen3-235B-A22B",
compression='4bit' # or '8bit'
)为什么只量化权重？ 常规量化需要同时量化权重和激活值才能加速计算，但激活值量化很难保持精度，因为输入的 outlier 分布不可控。
airllm 的瓶颈不在计算而在加载，所以只需要把权重文件变小来减少 I/O 量。只量化权重更容易保证精度--权重是固定的，outlier 分布可控。README 原话："almost ignorable accuracy loss"（几乎可以忽略的精度损失）。
效果：4bit 压缩可以带来最高 3 倍推理加速。对于一个本来就很慢的方案（逐层加载），这个提速是实打实的。
支持的模型和硬件
模型覆盖极广。 airllm 用 AutoModel 自动检测模型类型，一行代码加载，覆盖所有主流开源模型：
- Llama：2 / 3 / 3.1 / 3.3 / 4
- Qwen：1 / 2 / 2.5 / 3，含 MoE 和 FP8 变体
- DeepSeek：V2 / V3 / R1
- Mistral / Mixtral
- Phi / Gemma / ChatGLM / Baichuan / InternLM / Yi
而且对新模型的支持基本是"发布当天就能用"--因为它的逐层加载机制是模型架构无关的，只要 Hugging Face 上有模型权重就能加载。
硬件支持：
- Linux + NVIDIA GPU：主要支持平台
- CPU 推理：v2.10.1 起支持，不需要 GPU 也能跑（当然更慢）
- macOS + Apple Silicon：通过 MLX 后端支持，M 系列芯片的统一内存天然适合这种方案
安装和使用极简：
from airllm import AutoModel
# 一行加载，70B 模型在 4GB 显存上跑
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
input_tokens = model.tokenizer(["What is the capital of United States?"],
return_tensors="pt", return_attention_mask=False, truncation=True, max_length=128)
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 和 Hugging Face transformers 几乎一样，迁移成本为零。
Kimi K3 的特殊要求。 2.8T 模型不是无脑就能跑的，README 列了三个前置条件：
pip install compressed-tensors flash-attn（K3 的模型代码强制要求 flash attention）- CUDA 12 的 torch 构建（目前没有 CUDA 13 的预编译 flash-attn wheel）
- transformers 4.56.x（K3 的 remote code 在 5.x 上加载不了）
代价是什么：速度
airllm 不是银弹。显存省了，代价是速度。
逐层加载意味着每次前向传播都要从磁盘读取整个模型。一个 70B 模型 140GB 权重，即使用 NVMe SSD（读取速度约 3GB/s），光加载就要 47 秒。加上计算时间，生成一个 token 可能需要几秒甚至十几秒。
对比一下：
- 常规加载（A100 × 2）：70B 模型，生成速度约 30-50 tokens/s
- airllm（4GB GPU + NVMe）：70B 模型，生成速度约 1-3 tokens/s
- airllm + 4bit 压缩：约 3-9 tokens/s
速度差了一个数量级。这就是 airllm 的核心 tradeoff：用时间换空间。
这意味着 airllm 不适合需要实时交互的场景--聊天对话、代码补全、API 服务这些场景的延迟要求它达不到。它适合的是：
- 离线批处理：跑一批 prompt，不急等结果
- 资源受限环境：只有消费级 GPU 或 MacBook，但想体验大模型
- 原型验证：想试试 70B 或 671B 模型在你的任务上效果如何，再决定是否租 A100
- 研究实验：需要跑不同大模型做对比，不想每次都租多卡服务器
一个实际场景：你在做一个 RAG 系统，想测试用 70B 模型做 reranker 效果好不好。用 airllm 在你现有的 4GB GPU 上跑一批测试数据，虽然慢但能出结果。如果效果好，再花钱租 A100 做生产部署。如果效果不好，一分钱没花就排除了一个方案。
什么时候该用，什么时候不该用
该用 airllm 的场景：
- 没有 A100/H100，但有消费级 GPU。RTX 3060 12GB、RTX 4060 8GB、甚至 4GB 的老卡，都能跑 70B+ 的模型。
- macOS + Apple Silicon 用户。M 系列芯片的统一内存（16GB-128GB）天然适合 airllm 的流式加载方案，而且 MLX 后端针对 Apple Silicon 做了优化。
- 需要跑超大的 MoE 模型。Kimi K3 2.8T、DeepSeek-V3 671B 这些模型，即使用 airllm 在消费级硬件上也能跑，这是其他方案做不到的。
- 离线场景，对延迟不敏感。批处理、实验验证、数据标注这些场景，慢一点没关系，关键是能跑起来。
不该用 airllm 的场景：
- 需要实时响应。1-3 tokens/s 的速度做聊天或代码补全，用户体验会很差。
- 有充足的 GPU 资源。如果你有 A100 或 H100，直接常规加载更快，airllm 的流式加载反而增加了 overhead。
- 高并发服务。airllm 是单请求串行处理，不支持并发推理。做 API 服务用 vLLM 或 TGI 更合适。
- 对速度有要求的批处理。如果要处理百万级 prompt，即使离线，airllm 的速度也可能让总时间不可接受。
和量化方案的对比。 很多人会问：为什么不直接用 4-bit 量化？GPTQ、AWQ 这些方案也能把 70B 压到 35GB 左右。
答案是定位不同。量化方案把模型压小后还是整体加载到显存，需要 35GB 显存。airllm 不量化也能在 4GB 上跑，量化后（4bit compression）还能再提速 3 倍。两者可以叠加使用，不是互斥的。
如果你有 40GB+ 显存（比如 A100 40GB），量化方案更合适--速度快得多。如果你只有 4-8GB 显存，airllm 是唯一能跑 70B+ 模型的方案。
一个容易忽略的细节：airllm 首次加载时需要把模型分解成逐层存储的格式，这个过程很吃磁盘空间（大概需要模型原始大小的同等空间）。如果你磁盘空间紧张，可以设置 delete_original=True 在分解完成后删除原始文件，节省一半空间。
30K star 不是白拿的。airllm 解决了一个真实痛点：让没有企业级 GPU 的人也能跑大模型。它不追求快，追求的是"能跑"。在很多场景下，"能跑"比"跑得快"更重要。
参考文档与链接
- GitHub: lyogavin/airllm - 30943 star，Apache 2.0，逐层流式加载推理框架
- airllm PyPI - pip install airllm，安装包
- Block-wise Quantization 论文 - airllm 压缩加速所基于的 block-wise 量化论文
- Kimi K3 模型 - 2.8T 参数 MoE 模型，airllm 支持的最大模型
- DeepSeek-V3 模型 - 671B 参数 MoE 模型，airllm 上 ~12GB 显存可跑
- Hugging Face Transformers - airllm 的 API 设计基于 transformers，迁移成本低
- MLX - Apple Silicon ML 框架 - airllm macOS 后端使用的框架
- bitsandbytes - airllm 压缩加速使用的量化库
- Gavin Li 博客 - airllm 作者的技术博客，含设计思路和更新说明
- airllm Colab 示例 - 在 Google Colab 上运行各类模型的示例 notebook
你的显卡多大显存？跑过最大的模型是什么？评论区聊聊。觉得有用点个赞让更多人看到。
作者: itech001 来源: 公众号：AI人工智能时代 网站: https://www.theaiera.cn/ 每日分享最前沿的AI新闻资讯和技术研究。
本文首发于 AI人工智能时代，转载请注明出处。
