AirLLM以专家流式加载把峰值显存压至3.72GB，但每个Token约需5分钟。
冷月清谈：
怜星夜思：
2、磁盘I/O成为瓶颈后，专家缓存、预测预取或更快SSD，哪个方向最可能让它接近实用？
3、如果生成一个Token要5分钟，哪些真实任务仍值得本地运行，而不是直接调用API或租用GPU？
原文标题：独家丨难以置信！单张4GB显存GPU运行2.8万亿参数Kimi K3模型
原文作者：数据派THU
原文内容
作者：Gavin Li翻译：王岚校对：尹悦本文约3100字，建议阅读5分钟
这款开源新王者仅落后Claude三分。下面教你如何在台式机的单张4GB显存显卡上运行它。
关键词：人工智能、大型语言模型、开源、开源人工智能、LLM推断
本文介绍了如何使用 AirLLM 在显存峰值占用仅 3.72GB 的情况下运行 Kimi K3——一个拥有 2.8 万亿参数的开源混合专家（MoE）大语言模型。Kimi K3 在 Artificial Analysis 智能指数上得分 57，仅落后 Claude 三分，是目前最接近专有前沿模型的开源权重模型。然而，其完整检查点达 1.56TB，常规加载方式需要约 40 张 H200 显卡。文章详细阐述了传统逐层推理方法在极端 MoE 架构上失效的原因，并介绍了 AirLLM 的逐专家流式加载技术：仅在路由器选中某个专家时才加载其权重，将单层内存需求从约 56GB 降至约 1GB。此外，文章还探讨了保持 MXFP4 压缩格式直至 GPU 端再解压、通过硬链接避免重复存储等优化策略。实测表明，在单张 RTX 6000 Ada 上，每个 token 生成约需 5 分钟，适用于离线批量分析等对延迟不敏感的场景。文章最后指出，这一突破使“前沿开源模型”与“学生拥有的硬件”之间的差距，从资金问题变成了耐心问题。
译注：本文将原题 “Unbelievable! Run Kimi K3–2.8 Trillion Parameters — on a Single 4GB GPU” 译为“难以置信！单张4GB显存GPU运行2.8万亿参数Kimi K3模型”，以突出超大参数模型与极低显存硬件之间违背常识的技术突破，点明这一技术成果的颠覆性。
仅用 3.72GB 显存 GPU，借助 AirLLM 运行 2.8 万亿参数的 Kimi K3
7 月 16 日，月之暗面（Moonshot AI）发布 Kimi K3 模型。在Artificial Analysis评测中，Kimi K3 得分为 57 分；Claude Fable 5 为 60 分，GPT‑5.6 Sol 为 59 分。排名最接近的其他开源权重模型 GLM-5.2，得分仅为 51
再看看这个分数差距：仅仅相差 3 分。并且在多项基准测试中，Kimi K3 不仅没有落后，反而取得领先。
前沿大模型不再只能通过 API 接口才能使用。
但它依然受制于另一个条件：硬件。Kimi K3 拥有 2.8 万亿参数，发布的模型检查点文件大小达 1.56TB。按照常规方式加载，大约需要 40 张 H200 显卡，这是数据中心级别的配置，不是娱乐性质（随便玩玩）的。
所以值得探讨的问题不是 Kimi K3 性能强不强，而是普通用户究竟能不能跑得动这个模型。
我们做到了。仅使用单张 GPU，显存占用仅 3.72GB。
这不是蒸馏后的小模型，也不是模型的简化版，是完整的 2.8 万亿参数原版检查点，并且可以正常生成文本 token。
下面介绍具体方法。
01 — 传统方案为什么失效
两年前我写过一篇文章，介绍如何利用分层推理技术（layer-wise inference），在 4GB 显存显卡上运行 70B 参数模型。核心思路十分简单：分而治之。Transformer 模型会按顺序逐层运算，每一层的输入就是上一层的输出。因此你并不需要把全部层一次性载入内存。从磁盘读取一层，计算，释放内存，再处理下一层。这套方案把 70B 模型原本 130GB 的内存需求，压缩到仅 1.6GB。
该技术是 AirLLM 的底层基础，过去两年里一直有效运作，先后支持 405B 参数 Llama、671B 参数 DeepSeek‑V3 等超大模型。
但这套方法在 Kimi K3 上行不通。
根源在于 Kimi K3 的模型架构，它属于规模极其庞大的混合专家（MoE）模型。模型一共 93 层，每一层包含 896 个独立专家网络。如果完整加载 Kimi K3 的一整层，就需要把全部 896 个专家全部读入内存。
简单算一笔账：Kimi K3 单层存储大小约 17GB，展开用于计算后会膨胀至约 56GB。而我们使用的显卡显存只有 48GB。这种 “逐层加载” 的经典老方法，连完整一层都放不下。
02 — 全新技术：按专家粒度流式加载
混合专家模型有一个关键特性：每一层虽然有 896 个专家，但单个 token 并不会调用全部专家。
Kimi K3在处理每个token的时候，会从总共 896 个专家里挑出16个专家来负责计算这一段内容。这就是该架构的设计精髓：模型总参数达到 2.8 万亿，但处理任意一个 token 时，实际激活的参数大约只有 1040 亿。对于当前输入 token 来说，该层其余 98% 的参数都是无效冗余。
既然如此，就不再按层加载，改为按专家加载。
AirLLM 不再为每一层设置一个钩子，而是为每一个独立专家都挂载钩子，整个模型总计 82432 个钩子。当路由模块选定某个专家，就加载该专家的权重，完成计算，立刻将其从显存清除。该 token 不需要用到的其余 880 个专家，完全不会从磁盘读取。
提升效果不是小幅迭代，而是量级上的改变：
• Kimi K3 单层全部专家展开后占用显存：约 55GB
• 单个 token 实际运行所需显存：约 1GB
这就是整套方案的核心。相比之前，分治策略的粒度再往下深挖一层。上一代 AirLLM 思考的是 “当前处理到哪一层”，新版则思考 “路由模块实际调用了哪一个专家”。
03 — 保持权重压缩存储，延迟解压
Kimi K3 的专家权重采用 MXFP4（4位格式）存储。处理该格式的库会在模型运行前，就把权重解压为全精度格式。
这对 Kimi K3 来说是致命的。提前解压全部专家，就是单层从 17GB 膨胀到 56GB 的根源，会直接超出显卡的容量。
因此 AirLLM 尽可能长时间保留权重的压缩状态。4位字节压缩数据经由 PCIe 总线从磁盘传输，全程不解压；只有数据传输到 GPU 显存之后，才逐个对专家进行解压。
这一处改动带来双重收益。内存峰值不会出现在扩展层阶段，同时总线传输的数据量缩减为原来的四分之一。当磁盘吞吐量成为整套系统性能瓶颈时，这点优化至关重要。
04 — 在 3TB 磁盘上存放 1.56TB 的模型
我们遇到了一个未曾预料的难题。
AirLLM 预处理模型检查点时，会对模型做分片重处理：每个层单独生成一个文件，加载某一层时只会读取对应文件，不会读取其他数据。磁盘读取是整套流程中速度最慢的环节，该优化意义重大。
但分片重处理会生成一份完整副本。原始文件 1.56TB，分片副本同样 1.56TB，合计需要 3.12TB 存储空间，而我们的磁盘只有 3TB，存储空间缺口达到 50GB，这几乎无法完成。
突破口来自仔细研究月之暗面（Moonshot AI）的权重打包方式。Kimi K3 原始分片文件十分纯粹，每个文件只存放一个模块，不存在混杂其他内容。这意味着分片重处理环节根本不需要改动、重新排布数据。
于是 AirLLM 识别该特殊场景，改用硬链接而非复制文件。分片后的层文件直接指向原始数据，磁盘占用依旧维持 1.56TB。原本需要数小时拷贝的预处理流程，几秒即可完成。
05 — 实测数据
在单张 RTX 6000 Ada（48GB 显存）显卡上，基于完整 1.56TB 原版检查点进行端到端实测，实现真实 token 生成。
这里必须明确承认这套方案的真实代价：速度很慢，生成单个 token 大约需要五分钟。瓶颈并不在算力，而在磁盘。每生成一个 token，都要遍历 1.56TB 的权重文件，再精妙的内存管理也无法改变固态硬盘本身的读取速度上限。
因此它并不适合拿来做实时对话聊天。它的适用场景和 70B 大模型本地运行的场景一致：不要求低延迟，但看重输出质量的离线任务。例如批量文本分析、文档处理；评估 Kimi K3 是否值得租赁像样的硬件；开展前沿模型的科研工作，研究原本难以接触的模型；对可解析的模型架构开展微调实验。
更广泛的意义在于：3.72GB显存门槛并不算高，普通笔记本显卡都能达到这一水平（译者注：标题中4GB GPU”为吸引注意力的简化表述。实际测试使用RTX 6000 Ada专业显卡（48GB显存），峰值占用3.72GB，但完整运行仍需约1.6TB高速SSD存储空间，普通笔记本难以满足整体硬件要求。）。前沿开源大模型和学生可拥有的硬件之间的差距，从资金问题变成了耐心问题。
06 — 动手实操运行
pip install airllm compressed-tensors flash-attn
from airllm import AutoModel
model = AutoModel.from_pretrained("moonshotai/Kimi-K3")
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,
use_cache=True,
return_dict_in_generate=True)
print(model.tokenizer.decode(generation_output.sequences[0]))
以上就是全部代码。AirLLM 会自动识别模型架构，首次运行时完成检查点分片，并自动开启专家流式加载，无需手动配置。
运行 Kimi K3 有三项特定要求，缺一不可：
-
必须安装 flash‑attn。Kimi K3 模型代码会覆盖用户指定的注意力实现方案，缺少该库无法运行。
-
PyTorch 需要为 CUDA12 编译版本，flash‑attn 目前没有适配 CUDA13 的预编译包。
-
transformers 版本锁定 4.56.x，5.x 版本无法加载 Kimi K3 的远端代码。
-
同时你还需要高速存储设备，预留约 1.6TB 磁盘空间。磁盘读写速度是决定 token 生成耗时最关键的因素。
07 — 这一切意味着什么
过去两年来，本地大模型的发展叙事始终一成不变：开源模型能力持续变强，但运行所需硬件遥不可及。所以大多数人只能租用 API 服务，祈祷服务条款不会发生变动。
Kimi K3 的出现，让局面迎来转折点。该模型真正站在行业前沿，与顶尖闭源模型仅相差 3 分，在智能代理、代码任务上的表现还更好，同时权重完全公开。
谁掌握模型权重，谁就制定规则。 可以离线运行、自行微调、解析模型内部、研究模型工作原理。
过去这些操作必须依托数据中心，如今只需要一块显卡和一点耐心。
原文标题：
Unbelievable! Run Kimi K3–2.8 Trillion Parameters — on a Single 4GB GPU原文链接：
https://aiadvances.org/unbelievable-run-kimi-k3-2-8-trillion-parameters-on-a-single-4gb-gpu-23590e7a16c2
译者简介
作者简介
王岚，本科就读于天津外国语大学国际组织与全球治理专业，正在攻读香港城市大学国际研究硕士，雅思7.0。
曾在罗马尼亚孔子学院担任中文助教，负责演讲稿、新闻稿等多类文本翻译归档，具备跨文化文本处理经验。获普译奖英语写作二等奖、BETT杯英语词汇大赛二等奖，英语读写功底扎实。
在校参与外交学会、辩论队，熟悉线上团队协作，做事严谨守时。对社科、国际议题内容抱有兴趣。
翻译组招募信息
工作内容：需要一颗细致的心，将选取好的外文文章翻译成流畅的中文。如果你是数据科学/统计学/计算机类的留学生，或在海外从事相关工作，或对自己外语水平有信心的朋友欢迎加入翻译小组。
你能得到：定期的翻译培训提高志愿者的翻译水平，提高对于数据科学前沿的认知，海外的朋友可以和国内技术应用发展保持联系，THU数据派产学研的背景为志愿者带来好的发展机遇。
其他福利：来自于名企的数据科学工作者，北大清华以及海外等名校学生他们都将成为你在翻译小组的伙伴。
点击文末“阅读原文”加入数据派团队~
转载须知
如需转载，请在开篇显著位置注明作者和出处（转自：数据派ID：DatapiTHU），并在文章结尾放置数据派醒目二维码。有原创标识文章，请发送【文章名称-待授权公众号名称及ID】至联系邮箱，申请白名单授权并按要求编辑。
发布后请将链接反馈至联系邮箱（见下方）。未经许可的转载以及改编者，我们将依法追究其法律责任。
