--- 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" --- [**返回**](/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年8月20日 [**下一篇**](/zh/blog/moneyprinterturbo-review-2026/) # AirLLM 只用 4GB 显存跑超大模型？逐层推理原理与代价 要点速览 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/) 。 ## 来源边界 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/) - [Qwen3.8-27B：自托管电脑操作智能体，截图不出内网](/zh/blog/qwen3-8-27b-self-hosted-computer-use-agents/) - [Netflix 的 vLLM 与 Triton 推理栈：7 个生产经验](/zh/blog/netflix-vllm-triton-inference-stack/) - [Transformers.js 浏览器本地 AI：什么时候适合放进产品](/zh/blog/transformers-js-browser-ai-guide/) - [LiteLLM 生产级自托管指南：2026 架构与安全](/zh/blog/self-host-litellm-production-2026/) - [AI 就绪企业 Wiki：架构与实施指南](/zh/blog/ai-ready-company-wiki/) 只收重要内容 ## 关注与你相关的内容 每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。 [**返回**](/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年8月20日 [**下一篇**](/zh/blog/moneyprinterturbo-review-2026/) 邮件订阅新文章 × × 通过邮件获取新文章 我们发布时给你一封简短邮件。免费，不做跟踪。 ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/airllm-layer-wise-inference-low-vram/#webpage", "@type": "WebPage", "dateModified": "2026-08-20", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-20", "url": "https://wavect.io/zh/blog/airllm-layer-wise-inference-low-vram/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "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 做实测比较。", "articleBody": " 博客概览/AI 与智能体/模型与基础设施 AirLLM 只用 4GB 显存跑超大模型？逐层推理原理与代价 要点速览 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 硬件适配指南。 AirLLM 热门说法与决策级解读 说法现有证据支持什么没有证明什么 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 官方仓库列出 Llama、Qwen、DeepSeek、Mistral、Phi、Gemma、Kimi K3 等模型家族，并通过 AutoModel 提供入口。项目还支持可选的 4-bit 或 8-bit 权重压缩、CPU、Apple Silicon 和有限 prefetch。 它的核心价值是可达性。原本会因显存不足而加载失败的 checkpoint，现在至少可以被研究和评估。核心代价则是重复传输。常规 GPU server 让权重长期驻留，并为多个 token 和请求复用。AirLLM 反复从慢得多的存储层取回权重，因为它优先解决容量，而不是吞吐。 逐层推理如何降低显存？ 拆分 checkpoint。AirLLM 为每层生成文件。首次处理时，原始模型与转换副本可能同时占用磁盘。 保留运行状态。Activation、attention、KV cache 与 framework buffer 仍需 RAM 或 VRAM。 加载当前层。把 transformer block 送入计算设备，执行后释放权重内存。 每生成一个 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 与真正适配硬件的模型怎么选？ 需求更合理的默认选择原因 偶尔检查一个巨大 checkpointAirLLM 试点能访问比响应时间更重要 私人本地聊天更小的量化模型权重驻留通常有更好延迟 多用户 APIvLLM、SGLang 或托管 APIBatching 与 scheduling 是核心能力 离线 batch两者都测一次加载可以处理多个 sequence 生产系统通过 eval 的最小模型成功任务比参数量重要 Disk offload 先解决容量，系统设计再努力追回速度。PRIMA.CPP 论文针对 30B 到 70B 模型使用 memory mapping、pipeline、prefetch 与设备感知层分配。它不是 AirLLM benchmark，但说明“能跑”与“实用”之间是完整的推理架构问题。 什么时候值得做商业试点？ AirLLM 适合偶尔离线访问、模型架构研究、大 batch 实验或硬件受限的教学。若客户要求交互响应、多个用户同时访问、受监管数据尚未完成安全审查，或 7B 到 70B 的量化模型已经通过同一任务 eval，就不应增加这套复杂度。 面向决策的 benchmark 清单 固定模型 ID、revision、权重格式、AirLLM commit 与全部 runtime 版本。 测量 VRAM 峰值、RAM、swap、原始模型、shard 与临时空间。 分别记录下载、拆分、冷启动、prefill、首 token 与 decode。 使用真实 context、tools、语言、batch 与并发。 按成功任务比较质量与总成本，不按参数量或单 token 价格。 完成实测后，再套用本地模型与 API 盈亏平衡框架。如果决策重点是 Kimi K3 的采购、API 条款与数据位置，请看Kimi K3 欧洲企业生产评测。另一种带公开速度数据的 NVMe 专家流式架构，可参考Colibri 硬件分析。 来源边界 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 适配你的硬件？ 先筛选正常适配的模型，再决定是否测试极端逐层流式方案。 本地模型还是 API 实测延迟、利用率与工程成本后再计算自托管价值。 模型与基础设施 继续浏览此集群 模型选择、推理经济性、本地部署、压缩与服务架构。 从核心文章开始在欧盟自托管 LLM：开放权重模型何时才真正划算 Qwen3.8-27B：自托管电脑操作智能体，截图不出内网 Netflix 的 vLLM 与 Triton 推理栈：7 个生产经验 Transformers.js 浏览器本地 AI：什么时候适合放进产品 LiteLLM 生产级自托管指南：2026 架构与安全 AI 就绪企业 Wiki：架构与实施指南 集群中的下一篇Qwen3.8-27B：自托管电脑操作智能体，截图不出内网 可选服务路径： 软件开发 看看生产环境中的应用: 债券分析平台 先做决定: 如何挑选软件开发公司 只收重要内容 关注与你相关的内容 每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。 Company 电子邮箱 你希望接收哪些内容？ 完整的 Wavect 博客接收六个主题下的每一篇新文章。 仅接收所选主题请在下方选择一个或多个分类。 选择主题 AI 与智能体 产品与 MVP 交付与 QA 领导力与团队 商业与监管 Web3 与隐私 我希望接收所选的 Wavect 博客邮件，并已阅读 隐私信息。我可以随时退订。 发送确认邮件→ 免费、双重确认、不使用跟踪像素。 ", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "AirLLM 官方仓库", "url": "https://github.com/lyogavin/airllm" }, { "@type": "WebPage", "name": "Kimi K3 官方仓库", "url": "https://github.com/MoonshotAI/Kimi-K3" }, { "@type": "WebPage", "name": "DeepSeek-V3 官方仓库", "url": "https://github.com/deepseek-ai/DeepSeek-V3" }, { "@type": "WebPage", "name": "公开证据审计", "url": "https://github.com/lyogavin/airllm/issues/295" }, { "@type": "WebPage", "name": "PRIMA.CPP 论文", "url": "https://arxiv.org/abs/2504.08791" } ], "dateModified": "2026-08-20", "datePublished": "2026-08-20", "description": "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 做实测比较。", "headline": "AirLLM 只用 4GB 显存跑超大模型？逐层推理原理与代价", "image": "https://wavect.io/img/blog/headers/header_airllm-layer-wise-inference-low-vram.svg", "inLanguage": "zh", "keywords": "AirLLM, 本地大模型, GPU 推理", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/airllm-layer-wise-inference-low-vram/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/airllm-layer-wise-inference-low-vram/", "wordCount": 505 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/ai-agents/", "name": "AI 与智能体", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/models-infrastructure/", "name": "模型与基础设施", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/airllm-layer-wise-inference-low-vram/", "name": "AirLLM 4GB 显存运行超大模型：逐层推理解读 | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "兼容 checkpoint 可以通过逐层加载实现较低的显存峰值。完整模型仍在存储中，4GB 并不保证交互速度。" }, "name": "AirLLM 真能用 4GB 显存运行 70B 吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "它把 checkpoint 拆成 layer shard，加载当前层、处理 activation 后释放权重。兼容的 sparse model 还可流式加载路由专家。" }, "name": "AirLLM 如何工作？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "AirLLM 提供可选 4-bit 与 8-bit 压缩。Kimi K3 本身就是原生 MXFP4 权重，因此 3.72GB 案例不是未量化 checkpoint。" }, "name": "AirLLM 使用量化吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "热门型号没有可复现的官方 tokens/s 表。请在确切模型上测量冷启动、首 token 与 decode 速度。" }, "name": "AirLLM 有多快？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "在自有测试证明延迟、吞吐、质量、可靠性与运维之前，应把它视为研究和访问工具。" }, "name": "AirLLM 适合生产吗？" } ] } ```