--- title: "AirLLM 4GB 显存运行超大模型：逐层推理解读" canonical: https://wavect.io/zh/blog/airllm-layer-wise-inference-low-vram/ language: zh description: "AirLLM 真能用 4GB 显存运行 70B 到 2.8T 模型吗？解析逐层推理、专家流式加载、磁盘与速度成本，以及企业试点条件。" image: "https://wavect.io/img/blog/headers/header_airllm-layer-wise-inference-low-vram.png" author: ["Kevin Riedl"] published: "2026-08-20" updated: "2026-09-02" reviewed: "2026-09-02" --- # AirLLM 只用 4GB 显存跑超大模型？逐层推理原理与代价 [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 9 分钟 阅读 · 2026年8月20日 最近审核 2026年9月2日 [**下一篇**](/zh/blog/moneyprinterturbo-review-2026/) 要点速览 AirLLM 只把当前层加载到 GPU，对受支持的稀疏模型则只加载路由选中的专家，因此能显著降低显存峰值。项目仓库报告 70B 约需 4GB 显存、Llama 3.1 405B 约需 8GB、DeepSeek-V3 约需 12GB、Kimi K3 实测 3.72GB。但这些数字证明的是模型可以执行和显存峰值较低，不代表生产吞吐。完整 checkpoint 仍需存储，每个生成 token 都可能触发新的权重传输，上下文和运行时 buffer 也继续占用内存。项目尚未为这些标题型号发布可复现的 tokens/s benchmark。Kimi K3 本身采用原生 MXFP4 权重，因此“无需量化”也不适用于该例。AirLLM 更适合研究、离线评估和模型可达性实验。面向客户上线前，必须把首 token 延迟、decode 速度、磁盘占用、并发、质量与总成本，同更小的量化模型或 API 做实测比较。 **AirLLM 的确能执行远大于 GPU 显存的模型。**但这不代表模型被装进了显卡。完整 checkpoint 仍在存储中，AirLLM 按需加载当前层或选中的专家，完成计算后释放显存，再进入下一步。它用更频繁的数据移动换取更低的权重驻留。 因此，4GB 峰值只是起点。它没有回答磁盘要多大、首次拆分要多久、首 token 等多久、长 context 是否可用，以及能服务多少用户。本文于 **2026 年 8 月 20 日**核查资料，只回答一个狭窄 intent：AirLLM 的低显存推理如何工作，企业何时值得试点。如果你只是想找一款能正常适配现有电脑的模型，请先看 [本地 LLM 硬件适配指南](/zh/blog/llmfit-local-llm-hardware-guide/) 。 | 说法 | 现有证据支持什么 | 没有证明什么 | | --- | --- | --- | | 4GB 显存运行 70B | 一次只驻留一层权重 | 交互式速度 | | 8GB 运行 Llama 3.1 405B | 项目提供代码路径与 notebook | 可复现的全精度 benchmark | | 约 12GB 运行 DeepSeek-V3 | 当前支持与显存峰值说法 | 延迟、并发与可靠性 | | 3.72GB 运行 Kimi K3 2.8T | 维护者在 RTX 6000 Ada 上报告的峰值 | 约 1.6TB checkpoint 仍需存储 | | 无需量化 | AirLLM 不强制再次压缩部分模型 | Kimi K3 本身采用原生 MXFP4 | ## AirLLM 是什么？ AirLLM 是采用 Apache 2.0 许可证的 Python 推理库。它把兼容的 transformer checkpoint 拆成更小的 shard，并在需要时加载。 [AirLLM 官方仓库](https://github.com/lyogavin/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 官方仓库](https://github.com/MoonshotAI/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 官方仓库](https://github.com/deepseek-ai/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 仍消耗内存。 仓库中的一份 [公开证据审计](https://github.com/lyogavin/airllm/issues/295) 还指出，405B notebook 没有执行后的计时和显存输出，并且使用预量化 4-bit 模型。在固定 checkpoint、revision、prompt、context、硬件与输出长度之前，速度应标为未知。 ## AirLLM 与真正适配硬件的模型怎么选？ | 需求 | 更合理的默认选择 | 原因 | | --- | --- | --- | | 偶尔检查一个巨大 checkpoint | AirLLM 试点 | 能访问比响应时间更重要 | | 私人本地聊天 | 更小的量化模型 | 权重驻留通常有更好延迟 | | 多用户 API | vLLM、SGLang 或托管 API | Batching 与 scheduling 是核心能力 | | 离线 batch | 两者都测 | 一次加载可以处理多个 sequence | | 生产系统 | 通过 eval 的最小模型 | 成功任务比参数量重要 | Disk offload 先解决容量，系统设计再努力追回速度。 [PRIMA.CPP 论文](https://arxiv.org/abs/2504.08791) 针对 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 盈亏平衡框架](/zh/blog/local-models-vs-apis-break-even-eu-2026/) 。如果决策重点是 Kimi K3 的采购、API 条款与数据位置，请看 [Kimi K3 欧洲企业生产评测](/zh/blog/kimi-k3-eu-api-production-review/) 。另一种带公开速度数据的 NVMe 专家流式架构，可参考 [Colibri 硬件分析](/zh/blog/colibri-glm-5-2-consumer-hardware/) 。 对受支持的 MoE 模型，FreeToken 采用不同路径：完整专家池留在 host RAM，GPU 使用 LRU 专家缓存，剩余工作由带宽自适应 CPU-GPU 执行。在选择逐层流式推理或 edge-native 专家 serving 前，可阅读 [FreeToken AI 硬件与 benchmark 评测](/zh/blog/freetoken-ai-inference-engine-review/) 对比两种思路。 ## 来源边界 AirLLM 提供功能与显存峰值说法；Moonshot 记录 K3 架构与 MXFP4；DeepSeek 提供 V3 参数；公开审计记录 405B notebook 的证据缺口；PRIMA.CPP 提供独立背景，但不验证 AirLLM 数字。Wavect 没有为本文下载 TB 级 checkpoint，也没有复现这些峰值。 ## 常见问题 ### AirLLM 真能用 4GB 显存运行 70B 吗？ 兼容 checkpoint 可以通过逐层加载实现较低的显存峰值。完整模型仍在存储中，4GB 并不保证交互速度。 ### AirLLM 如何工作？ 它把 checkpoint 拆成 layer shard，加载当前层、处理 activation 后释放权重。兼容的 sparse model 还可流式加载路由专家。 ### AirLLM 使用量化吗？ AirLLM 提供可选 4-bit 与 8-bit 压缩。Kimi K3 本身就是原生 MXFP4 权重，因此 3.72GB 案例不是未量化 checkpoint。 ### AirLLM 有多快？ 热门型号没有可复现的官方 tokens/s 表。请在确切模型上测量冷启动、首 token 与 decode 速度。 ### AirLLM 适合生产吗？ 在自有测试证明延迟、吞吐、质量、可靠性与运维之前，应把它视为研究和访问工具。 ## 最终思考 AirLLM 让无法驻留 GPU 的 checkpoint 得以执行。4GB、8GB、12GB 与 3.72GB 描述的是项目报告的峰值，不会缩小 checkpoint，也不会让存储自动变快。 确认权重格式，为原始模型和 shard 预留空间，测量生成的每个阶段，再按成功任务成本与更小的驻留模型或 API 比较。能启动的最大模型，通常不是最该上线的系统。 ## 你可能也喜欢.. [**哪款本地 LLM 适配你的硬件？** 先筛选正常适配的模型，再决定是否测试极端逐层流式方案。](/zh/blog/llmfit-local-llm-hardware-guide/) [**本地模型还是 API** 实测延迟、利用率与工程成本后再计算自托管价值。](/zh/blog/local-models-vs-apis-break-even-eu-2026/) 模型与基础设施 ## 接下来读什么 模型选择、推理经济性、本地部署、压缩与服务架构。 [从这里开始**在欧盟自托管 LLM：开放权重模型何时才真正划算**](/zh/blog/self-hosting-llms-eu-cost/) - [Cue 轮次检测：电话号码采集、基准测试与局限](/zh/blog/cue-turn-detection-phone-numbers/) - [Google SAM 现名 Agent Mesh：跨机器调用 MCP 工具](/zh/blog/google-sam-agent-mesh-mcp-tools/) - [EdgeQuake：用 PostgreSQL GraphRAG 构建 MCP 智能体记忆](/zh/blog/edgequake-postgresql-graphrag-mcp-agent-memory/) - [BitNet CPU 推理：2B4T 的实际内存需求与 100B 说法](/zh/blog/bitnet-cpu-llm-ram-requirements/) - [SuperPenguin：按 PR、客户和功能核算 AI 成本](/zh/blog/superpenguin-ai-roi-cost-per-pr-customer/) [上一篇文章**Thunder Compute 获 1300 万美元融资：企业 GPU 虚拟化采购指南**](/zh/blog/thunder-compute-gpu-virtualization-series-a/) [下一篇文章**Qwen3.8-27B：自托管电脑操作智能体，截图不出内网**](/zh/blog/qwen3-8-27b-self-hosted-computer-use-agents/) [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 9 分钟 阅读 · 2026年8月20日 最近审核 2026年9月2日 [**下一篇**](/zh/blog/moneyprinterturbo-review-2026/)