AirLLM：单张 4GB 显卡推理 2.8T 大模型的开源方案-字节棱镜 (Byte Prism)

AirLLM 用逐层加载把 70B、405B 甚至 2.8T 的 Kimi K3 塞进单张 4GB 消费级显卡，无需量化、蒸馏或剪枝，Apache-2.0 开源。

如果你手里只有一张 4GB 的 GTX 1060 或 RTX 3050，过去基本只能看着 70B 大模型的 README 叹气——常规加载需要约 140GB 显存（FP16，80 层 × 1.75GB），相当于两张 A100 80GB，普通人根本摸不到门槛 [3][5]。AirLLM 的思路是：装不下没关系，跑得慢可以接受。它不压缩模型权重，而是把”全模型常驻显存”换成”一次只放一层”，于是显存占用从此和模型总参数脱钩，只和单层大小挂钩 [1][3][5]。代价是 token/s 远低于全量加载模式，属于典型的”用时间换空间” [2]。

对 MoE（混合专家）模型，AirLLM 做了专项优化：每个 token 只路由到少数专家，那就只加载被激活的那几个，其余不加载。2026 年 7 月它更新了对 Kimi K3（2.8T 参数，月之暗面 Moonshot AI 发布）的支持，在单张 RTX 6000 Ada 上实测显存占用 3.72GB，于是跑进了 4GB 卡的范围 [3]。GitHub 上项目 star 数从最初的 26K 一路涨到 30K 左右 [1][3][5]，说明这种”用工程手段换硬件”的方向确实覆盖了一大批没有集群的个人开发者的需求。

一、把”装不下”变成”跑得慢”

AirLLM 的核心思路简单但反直觉：Transformer 是逐层计算的，第 N 层的输入只依赖第 N-1 层的输出，所以同一时刻 GPU 里只需要保留一层的权重 [3][5]。AirLLM 把模型按层切分成多个独立 shard 文件存到磁盘，推理时只把当前计算的那一层加载到显存，算完就丢弃，再加载下一层。任意时刻 GPU 上只有当前层，加上 KV cache 和中间激活值，70B 模型的显存需求就从约 140GB 降到了大约 4GB——刚好够放下单层权重 [3]。

这个思路在概念上有点像操作系统的虚拟内存 + 分页调度：把不活跃的”页”换出到磁盘，只保留活跃页在内存里。GPU 显存就好比内存，磁盘上的模型权重就好比硬盘。代价当然是性能——每算完一层都要从磁盘或内存读下一层，I/O 开销是实打实的。AirLLM 在 v2.5 之后加了 prefetching（预取）机制：在 GPU 计算当前层的同时，CPU 提前把下一层从磁盘读到内存，让加载和计算重叠执行，README 称能节省约 10% 的时间 [1][3][5]。不过这个优化目前主要在 Llama2 类模型上完整支持，其他架构可能部分开了 [1]。

二、不压缩模型，只调度显存

AirLLM 和 llama.cpp、AutoGPTQ 走的是完全相反的路线。后者的核心问题是怎么把模型变小——量化、蒸馏、剪枝，每一种都要在精度和体积之间做取舍。AirLLM 不问这个问题，它问的是”能不能不改模型，只改加载策略”——所以权重保持全精度，没有任何精度损失 [1][5]。

代价是速度。纯逐层加载的速度比全量加载慢得多，因为层间 I/O 是串行瓶颈。AirLLM 在 v2.0 之后做了一个折中：只量化权重、不量化激活值——把权重用更低精度加载，但计算时反量化回原精度再做激活。这种做法精度损失几乎可以忽略，速度最高能提升到原来的 3 倍 [1]。这种”分级浮点”的设计很务实：对想跑大模型但没有量化环境的人，它提供了一条几乎无精度损失的快速通道；对想完全无损的人，它仍然能跑，只是慢一点。

这种路线选择的本质是承认一个事实：硬件便宜，但精度丢不起。对学术研究、模型对比测试这类对输出质量极敏感的场景，AirLLM 的”全精度优先 + 慢速跑”路线反而比”4bit 量化优先 + 快”路线更合适。

三、MoE 流式加载：2.8T 的 Kimi K3 是怎么挤进 4GB 的

MoE 模型有一个看起来反直觉的特性：激活参数远少于总参数。DeepSeek-V3 有 256 个专家，但每个 token 只用 8 个；Kimi K3 的路由比例类似 [3]。但传统推理时你仍然要把所有专家的权重都加载到显存——即使大部分专家这次根本用不上。这就是 MoE 模型”激活参数少但总参数巨大”的原因。

AirLLM 对 MoE 做了针对性优化，叫 per-expert streaming（逐专家流式加载）：既然每个 token 只路由到少数专家，那就只加载被激活的那几个专家权重，不加载其余的 [1][2][3]。这个优化对超大 MoE 模型效果最显著——Kimi K3 的 2.8T 总参数里，每个 token 实际只激活几十 B 的参数，AirLLM 只加载这些激活的专家，所以显存可以压到 3.72GB [3]。

这带来了一个意外的结果：2.8T 的 Kimi K3 显存占用反而比 70B 的 Llama 还小 [3]。Kimi K3 是稀疏 MoE，每个 token 实际激活的参数规模本来就比 70B 稠密模型小，只是总参数因为专家数量多而显得巨大。AirLLM 让 MoE 模型的”总参数”和”显存占用”之间建立了和稠密模型一样的脱钩关系，并且由于 MoE 的天然稀疏性，激活参数比同体积稠密模型还少。

四、三行代码换一个模型 ID：上手实测

AirLLM 的接口设计刻意贴近 HuggingFace Transformers：

from airllm import AutoModel
model = AutoModel.from_pretrained("Qwen/Qwen3-32B")

换 Llama、Qwen、DeepSeek、Mistral、Gemma、ChatGLM 等只需要改模型 ID，常见的新模型自动适配 [1][4]。这意味着如果已经熟悉 Transformers，几乎零学习成本。

首次加载时，AirLLM 会把 HuggingFace 下载的模型按层切分成多个独立文件，存在本地 HuggingFace 缓存里，这个预处理只需要做一次 [5]。所以第一次跑某个模型会显著更慢——慢主要在切分和 I/O 上。需要预留足够的磁盘空间存放模型全量权重 + 切分后的 shard 文件 [2]。

五、用时间换空间：你必须接受的几个现实

AirLLM 不是银弹。它把硬件门槛降到极低，但代价写在代码里：频繁的层间 I/O 让 token/s 远低于全量加载模式 [2]。对一个 70B 模型，输出速度可能从全量加载的每秒几十 token 降到个位数。如果做交互式体验，体感会明显偏慢；如果是离线分析、批量评估，速度的影响相对可以接受。

几个现实约束：
– 内存（RAM）建议 ≥ 16GB，因为模型权重虽然不常驻显存，但要常驻内存做中转 [2]
– 磁盘需要足够大，模型全量权重 + 切分后的 shard 文件都要存
– prefetching（预取）目前主要在 Llama2 类模型上完整支持，其他架构可能享受不到那 10% 的加速 [3]

从目标用户上看，AirLLM 不是生产级推理方案——它的定位是让学者、个人开发者在有限硬件下研究超大模型、测试 prompt 工程、验证产品想法 [2]。需要低延迟在线服务的场景，它不合适；想体验前沿模型、跑通 demo、评估效果，它是目前门槛最低的方案之一。开源协议是 Apache-2.0，可以放心二次开发和商用 [1]。

FAQ

AirLLM 和 llama.cpp、AutoGPTQ 等量化方案怎么取舍？

量化方案速度更快，但会损失精度，精度敏感的任务里这种损失能感觉到；AirLLM 保持全精度权重，但速度慢得多 [1][5]。如果你需要在线服务或者批量处理、对延迟敏感，量化路线更合适；如果你想跑某个 70B / 405B 模型、对输出质量极敏感、对延迟不敏感，AirLLM 是硬件门槛最低的方案。v2.0+ 的”只量化权重不量化激活”是两者之间的折中：精度损失几乎可忽略，速度最高提升 3 倍 [1]。

为什么第一次加载模型非常慢，之后会快很多？

首次加载时 AirLLM 要把 HuggingFace 下载的模型按层切分成多个独立 shard 文件存进本地缓存，这个预处理是一次性的 [5]。之后运行同一个模型直接复用切分好的文件，主要开销就是层间 I/O 和计算了。所以同一个模型反复跑，体验会逐步稳定在一个速度上。

AirLLM 当前支持哪些模型架构？新模型多久能跟进？

官方支持的架构覆盖 Llama、Qwen、DeepSeek、Mistral、Gemma、ChatGLM 等主流系列 [1]。新模型发布后常常能做到当天跟进支持，这得益于接口设计贴近 Transformers——只要新模型能用 Transformers 加载，迁移到 AirLLM 的工作量相对可控 [1]。