AirLLM：一张 4GB 显卡跑 70B 大模型，2.8T 的 Kimi K3 也只要 3.7GB 显存

原文来源：AirLLM GitHub 仓库 — 通过分层流式推理，让 70B 大模型在单张 4GB 显卡上运行，无需量化、蒸馏或剪枝，本月已支持 2.8T 参数的 Kimi K3。

本地跑大模型，最劝退的就是显存：70B 参数的模型光权重就要 140GB，消费级显卡根本装不下。AirLLM 这个开源项目想解决的就是这个问题——它让 70B 模型跑在单张 4GB 显卡上，不做量化、不蒸馏、不剪枝。项目在 GitHub 上已有 26.6k stars、2.9k forks，Apache-2.0 协议，作者是 Gavin Li（lyogavin），本月（2026 年 7 月）刚发布 3.1.0 版本。

它能跑多大的模型

AirLLM 的核心卖点是「小显存跑大模型」，直接看官方数据：

注意最后一行：2.8T 参数的 Kimi K3，目前最大的开源模型，AirLLM 在单卡上用 3.72GB 显存跑通了——这是 2026 年 7 月 3.1.0 版本加入的能力。对只有几张老显卡的开发者来说，这个数字意味着「本地跑旗舰模型」从幻想变成了可选方案。

原理：把「装不下」变成「流式加载」

AirLLM 不靠量化，靠的是分层流式推理（layer streaming）。思路很直接：

传统推理要把整个模型加载进显存，70B 模型权重太大装不下。AirLLM 把模型按层拆分，一次只加载一层到显存计算，算完卸载，再加载下一层。显存只需要容纳一层权重加上激活值，而不是整个模型——这就是 4GB 跑 70B 的底层逻辑。

2026 年的 v3.0 进一步加了 FP8 支持，并针对 MoE 架构做了优化：稀疏 MoE 模型（DeepSeek-V3、Kimi K3 都是）不用按整层加载，而是按专家（expert）流式加载——一个 token 路由到哪个专家，就只加载那个专家。Kimi K3 的 2.8T 参数能压进 3.72GB，靠的就是这个「逐专家流式」机制。

代价当然也有：速度慢。层与层之间不断加载卸载，吞吐远低于完整驻留显存的方式。它解决的是「能不能跑」的问题，不是「跑得快不快」的问题。适合离线任务、实验、开发调试，不适合高并发生产服务。

上手：三行代码

安装和推理都极其简单，pip 装包后直接像普通 transformers 一样用：

pip install airllm

from airllm import AutoModel
 
MAX_LENGTH = 128
 
# 传 Hugging Face repo id 即可，几乎支持所有主流模型
model = AutoModel.from_pretrained("Qwen/Qwen3-32B")
 
# 也支持本地路径和分片保存路径
# model = AutoModel.from_pretrained("/path/to/model", layer_shards_saving_path="/path/to/shards")
 
input_text = "天空为什么是蓝色的？"
input_tokens = model.tokenizer(input_text, 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=MAX_LENGTH,
    do_sample=False,
    return_dict_in_generate=True,
    output_scores=False,
)
print(model.tokenizer.decode(generation_output.sequences[0]))

AutoModel 会自动检测模型类型，不用手动指定类。分片后的模型会缓存到本地（layer_shards_saving_path），第二次加载就不用重复切分。它还支持 8bit/4bit 量化（可选叠加）、CPU 推理、macOS 上跑 70B，覆盖面很广。

适合谁，不适合谁

适合：

• 显存小的玩家：只有 4GB、8GB 显卡，想本地跑 70B 以上模型做实验和开发调试。
• 隐私敏感场景：数据不能出本机，需要本地推理但买不起大显存卡。
• 做模型对比评测：想快速在本地试不同架构的模型（Llama、Qwen、DeepSeek、Kimi K3、GLM 等都支持）。
• 学习推理原理：想看透 MoE 流式加载、分层推理机制的开发者，代码结构清晰，是个不错的参考实现。

不适合：

• 生产级高并发服务：流式加载的吞吐撑不住线上请求。
• 追求速度的场景：同显存下，量化 + 小模型通常比流式加载快得多。
• 没有耐心的人：70B 模型分层流式推理，一次生成可能要等很久，适合离线跑批。

和同类方案的对比

• llama.cpp（GGUF 量化）：靠量化把模型压进显存，速度快、生态成熟，但大模型量化后仍有显存上限，70B 量化后仍需 40GB 左右（Q4），4GB 卡依然无解。
• Ollama：基于 llama.cpp 的易用封装，同样受量化显存上限约束。
• vLLM / TensorRT-LLM：面向生产的高性能推理，优化目标是吞吐和延迟，显存要求高，不适合小显存个人场景。
• AirLLM：走的是完全不同的路线——不压权重，改流水线，用时间换空间。4GB 卡的场景下它是少数能跑的方案。

一些提醒

AirLLM 的 README 里有几个需要留意的点：Kimi K3 支持有硬性依赖（pip install compressed-tensors flash-attn、CUDA 12 的 torch、transformers 4.56.x），不是装上就能跑；README 里还挂着第三方广告位（AI agent 推荐、赞助链接），阅读时注意区分项目本身和推广内容。另外项目更新节奏并不规律，老代码库（2023 年起步）配合活跃维护，用之前建议看下最近的 issue 讨论。

一句话总结：如果你的瓶颈是显存而不是时间，AirLLM 是当前最值得试的本地大模型方案之一——尤其 3.1.0 之后，Kimi K3 这类 2.8T 旗舰都能塞进 4GB 显卡，小显存玩家的天花板被抬高了不止一截。