4GB 显卡跑 2.8T 大模型：AirLLM 用“逐层加载”终结显存焦虑，日榜第七新增 879 星

核心信息速览

一、问题：显存是本地大模型推理的硬墙

本地运行大模型时，显存容量是第一个绕不过去的物理限制。一个 70B 参数的模型，即使使用 FP16 精度，全量加载也需要约 140 GB 显存。消费级显卡的显存通常在 4 GB 到 24 GB 之间，常规做法只有量化、蒸馏或剪枝——用精度换空间。

AirLLM 的切入角度不同：它不试图让模型变小，而是改变模型在显存中的加载方式。项目的自我描述非常直接：“显著降低推理内存占用，让 70B 大模型在单张 4GB GPU 上运行——无需量化、蒸馏或剪枝”。

二、技术原理：GPU 上永远只留一层

AirLLM 的核心思路可以概括为一句话：显存占用取决于“单层大小”，而非“模型总参数量”。

传统推理把整个模型的权重一次性加载进显存。AirLLM 的做法是逐层加载：一次只把模型的一层（或一个 Transformer 块）放进 GPU 显存，完成该层的计算后立即释放，再换入下一层。任意时刻，GPU 上只驻留一层所需的权重和中间激活。

这一机制直接解耦了显存需求与模型规模。70B 模型的全精度单层大小约为 4 GB，因此 4GB 显卡就具备了运行条件。

2.1 预取优化：让 I/O 与计算重叠

逐层加载的一个直接副作用是：如果“加载 → 计算 → 再加载”串行执行，GPU 会在等待磁盘 I/O 时处于空闲状态。AirLLM 通过预取（prefetching）解决这个问题：在计算当前层的同时，提前把下一层的权重从磁盘读入内存（或显存缓存），使 I/O 和计算尽可能重叠。项目文档称这一优化带来约 10% 的速度提升。

2.2 MoE 专家流式加载：2.8T 的关键

对于 Kimi K3（2.8T）这类稀疏 MoE 模型，AirLLM 进一步细化了加载粒度。它不会加载整个 Transformer 层，而是按 token 实际路由到的专家（expert）进行流式加载——只把当前计算真正需要的那几个专家权重搬入显存。这是 Kimi K3 能在 3.72 GB 显存下运行的关键：2.8T 是总参数量，但单次前向传播激活的专家子集远小于此。

2.3 可选块量化：速度换精度

AirLLM 默认不量化。但它同时提供了块级量化选项：compression='4bit' 或 compression='8bit'。量化仅作用于权重，不量化激活，官方称精度损失“几乎可忽略”，速度最高可提升 3 倍（v2.0+）。对于更看重吞吐而非绝对精度的场景，这是一个可选的加速路径。

三、实测显存占用矩阵

AirLLM 官方 README 和多个技术博客给出了不同模型在 AirLLM 下的实测显存占用。以下数据来自项目文档和第三方实测：

Kimi K3 的 3.72 GB 是项目文档中记录的端到端实测值（RTX 6000 Ada），不是理论估算。这说明“4GB 显卡跑 2.8T”在特定 MoE 架构上已经得到了验证，而非营销口号。

四、接口与安装：像 Transformers 一样使用

AirLLM 的设计目标之一是保持极低的使用门槛。它的 AutoModel 接口与 HuggingFace Transformers 高度相似，更换模型只需要改一个模型 ID。

4.1 安装

pip install airllm

4.2 最小推理示例

from airllm import AutoModel

model = AutoModel.from_pretrained("Qwen/Qwen3-32B")
input_text = ["What is the capital of United States?"]
input_tokens = model.tokenizer(
    input_text,
    return_tensors="pt",
    return_attention_mask=False,
    truncation=True,
    max_length=128,
    padding=False
)
generation_output = model.generate(
    input_tokens["input_ids"].cuda(),
    max_new_tokens=20
)

这段代码直接来自项目 README 和多个技术教程。关键参数是 compression：默认 None（不量化），可设为 '4bit' 或 '8bit' 以启用块量化并提速。

4.3 首次运行的预处理

首次加载某个模型时，AirLLM 会把 HuggingFace 格式的 checkpoint 按层切分为多个 safetensors 分片，存入本地 splitted_model/ 目录。这一预处理只需要执行一次，后续复用。代价是磁盘空间：分片后的模型通常与原始 checkpoint 体量相当，部分大模型可能需要数百 GB 的磁盘（例如 Qwen3.8-Flash-Next 125B 的 checkpoint 约 360 GB，设置 delete_original=True 可以在切分完成后回收原始文件）。

五、性能取舍与适用边界

AirLLM 解决的是“能不能跑”的问题，而不是“跑得有多快”。逐层加载的本质是用磁盘 I/O 和延迟换显存容量。它的推理速度会显著低于全量加载到显存（或使用量化后的高效推理框架）的方案，具体差距取决于磁盘读写速度、模型层数、预取策略和是否启用压缩。

因此，它最适合以下场景：

• 在消费级硬件上验证超大模型的行为：手里只有 4–8 GB 显存的显卡，但想实际运行 70B、405B 甚至 MoE 级别模型。
• 精度敏感、不愿量化：需要尽可能保留原模型精度，不能接受量化带来的分布偏移。
• 离线/本地推理环境：数据不能离开本机，且硬件预算有限。

不适合的场景包括：高吞吐在线服务、对延迟敏感的交互式应用、以及显存充足（例如 80 GB A100/H100）且追求最大推理速度的部署。

六、小结

AirLLM 的工程价值在于它把“显存墙”从一个不可协商的硬件约束，变成了一个可以用磁盘 I/O 和调度策略来绕过的工程问题。逐层加载、MoE 专家流式、预取重叠和可选块量化，四个机制组合起来，让 4GB 显卡运行 Kimi K3 这样的 2.8T MoE 模型从不可能变为可复现的实测结果（3.72 GB）。

需要客观指出的是，AirLLM 的“4GB 跑 2.8T”建立在稀疏 MoE 架构之上——密集模型（如 Llama 3 70B）的 4GB 占用对应的是 70B 量级，而非 2.8T。此外，首次运行的模型分片会消耗可观的磁盘空间，推理速度受 I/O 限制明显。但对于显存受限的本地推理场景，AirLLM 提供了一条不需要牺牲精度的可行路径。

附录：资源列表

作者简介：橘子，计算机视觉方向工程师，深耕 AIGC 与多媒体处理领域，专注技术实用化落地。

本文为原创内容，转载请注明来源与作者。

CSDN 首发 | 版权所有 © 2026

📢 温馨提示：AirLLM 为 Apache-2.0 协议开源项目，使用前请阅读仓库 LICENSE 文件。显存占用数据来自项目文档和第三方实测，实际表现可能因硬件、模型版本和配置而异。首次运行需要充足的磁盘空间进行模型分片。功能与参数更新较快，建议以 GitHub 仓库最新 README 为准。