AirLLM 只用 4GB 显存跑超大模型？逐层推理原理与代价

AirLLM 的确能执行远大于 GPU 显存的模型。但这不代表模型被装进了显卡。完整 checkpoint 仍在存储中，AirLLM 按需加载当前层或选中的专家，完成计算后释放显存，再进入下一步。它用更频繁的数据移动换取更低的权重驻留。

因此，4GB 峰值只是起点。它没有回答磁盘要多大、首次拆分要多久、首 token 等多久、长 context 是否可用，以及能服务多少用户。本文于 2026 年 8 月 20 日核查资料，只回答一个狭窄 intent：AirLLM 的低显存推理如何工作，企业何时值得试点。如果你只是想找一款能正常适配现有电脑的模型，请先看本地 LLM 硬件适配指南。

AirLLM 是什么？

AirLLM 是采用 Apache 2.0 许可证的 Python 推理库。它把兼容的 transformer checkpoint 拆成更小的 shard，并在需要时加载。AirLLM 官方仓库列出 Llama、Qwen、DeepSeek、Mistral、Phi、Gemma、Kimi K3 等模型家族，并通过 AutoModel 提供入口。项目还支持可选的 4-bit 或 8-bit 权重压缩、CPU、Apple Silicon 和有限 prefetch。

它的核心价值是可达性。原本会因显存不足而加载失败的 checkpoint，现在至少可以被研究和评估。核心代价则是重复传输。常规 GPU server 让权重长期驻留，并为多个 token 和请求复用。AirLLM 反复从慢得多的存储层取回权重，因为它优先解决容量，而不是吞吐。

逐层推理如何降低显存？

1. 拆分 checkpoint。AirLLM 为每层生成文件。首次处理时，原始模型与转换副本可能同时占用磁盘。
2. 保留运行状态。Activation、attention、KV cache 与 framework buffer 仍需 RAM 或 VRAM。
3. 加载当前层。把 transformer block 送入计算设备，执行后释放权重内存。
4. 每生成一个 token 都重复。自回归 decode 会再次穿过模型，没有命中缓存的权重必须重新读取。

所以显存峰值取决于最大单层、activation 与 workspace，不取决于全部参数之和。磁盘占用仍跟随完整 checkpoint。长 context、大 batch 与多个并发请求也会增加运行内存。

为什么 2.8T 的 Kimi K3 反而报告更低显存？

Kimi K3 不是 2.8 万亿参数的 dense model。Kimi K3 官方仓库记录了 93 层、896 个路由专家、每 token 选择 16 个专家，以及 1040 亿 active parameters。AirLLM 针对 K3 只流式加载路由选中的专家。它的瞬时 working set 可能小于一个 dense 70B layer，尽管完整专家库大得多。

显存峰值低不代表下载变小。公开 checkpoint 约为 1.6TB。Moonshot 推荐的生产引擎是 vLLM、SGLang 与 TokenSpeed。AirLLM 是实验性的模型访问路径，不是官方标准 serving 方案。

“无需量化”需要纠正

AirLLM 不要求每个 checkpoint 都经过它自己的量化步骤，这部分没错。但 Kimi K3 从 SFT 阶段就采用 quantization-aware training，公开权重为 MXFP4，activation 为 MXFP8。热门说法把 runtime 额外压缩与下载模型本身的格式混为一谈。

模型参数也要放在架构中解释。DeepSeek-V3 官方仓库给出主模型 671B、每 token 激活 37B，另有 14B 参数属于 multi-token prediction module。“12GB 运行 671B”描述的是 VRAM 峰值，不是 671B 权重全部驻留。

4GB 显存数字隐藏了什么？

• 磁盘：原始 checkpoint 与 layer shard 可能同时存在。Kimi K3 的源模型就约 1.6TB。
• I/O：冷层与冷专家要经过存储、RAM 和 PCIe。Prefetch 无法把 NVMe 变成 GPU memory。
• 速度：README 没有为热门型号提供可复现的 tokens/s 表。
• Context：KV cache、activation 与 batching 仍消耗内存。

仓库中的一份公开证据审计还指出，405B notebook 没有执行后的计时和显存输出，并且使用预量化 4-bit 模型。在固定 checkpoint、revision、prompt、context、硬件与输出长度之前，速度应标为未知。

AirLLM 与真正适配硬件的模型怎么选？

Disk offload 先解决容量，系统设计再努力追回速度。PRIMA.CPP 论文针对 30B 到 70B 模型使用 memory mapping、pipeline、prefetch 与设备感知层分配。它不是 AirLLM benchmark，但说明“能跑”与“实用”之间是完整的推理架构问题。

什么时候值得做商业试点？

AirLLM 适合偶尔离线访问、模型架构研究、大 batch 实验或硬件受限的教学。若客户要求交互响应、多个用户同时访问、受监管数据尚未完成安全审查，或 7B 到 70B 的量化模型已经通过同一任务 eval，就不应增加这套复杂度。

面向决策的 benchmark 清单

1. 固定模型 ID、revision、权重格式、AirLLM commit 与全部 runtime 版本。
2. 测量 VRAM 峰值、RAM、swap、原始模型、shard 与临时空间。
3. 分别记录下载、拆分、冷启动、prefill、首 token 与 decode。
4. 使用真实 context、tools、语言、batch 与并发。
5. 按成功任务比较质量与总成本，不按参数量或单 token 价格。

完成实测后，再套用本地模型与 API 盈亏平衡框架。如果决策重点是 Kimi K3 的采购、API 条款与数据位置，请看Kimi K3 欧洲企业生产评测。另一种带公开速度数据的 NVMe 专家流式架构，可参考Colibri 硬件分析。

来源边界

AirLLM 提供功能与显存峰值说法；Moonshot 记录 K3 架构与 MXFP4；DeepSeek 提供 V3 参数；公开审计记录 405B notebook 的证据缺口；PRIMA.CPP 提供独立背景，但不验证 AirLLM 数字。Wavect 没有为本文下载 TB 级 checkpoint，也没有复现这些峰值。