2026/08/01

Kimi K3 在 4GB GPU 上运行的真相：2.8 万亿参数成本分析

Kimi K3 能在 4GB GPU 上运行吗？掌握 1.4TB 显存数学、层级卸载工作原理、当前工具支持状态与实用 API 方案。

Kimi K3 能在 4GB GPU 上本地运行吗？按"通常意义的本地运行"来说，不能。 Kimi K3 的原生 MXFP4 权重需要约 1.4 TB 存储空间（不含元数据和运行时开销）。4GB 显卡只能充当一个小型缓冲设备，如果软件从磁盘或主机内存中流式传输模型的微小片段。这在技术上很有趣，但不等同于把 Kimi K3 加载到 4GB 显存中，目前没有主流 Kimi K3 方案让它成为实用设置。^[1]^[2]

这个区别很重要，因为三个真实的事实经常被混合成一个误导性结论：Kimi K3 是稀疏模型，每个 token 只激活 104B 参数，层级卸载工具曾在 4GB GPU 上运行过较小的 70B 模型。这些事实都不能让 2.8T 检查点塞进 4GB。本指南详细计算了显存需求，解释卸载真正改变了什么，检查了当前软件支持，并展示了今天有效的低硬件方案。

快速概述

Kimi K3 真的有 2.8T 总参数。 它是一个稀疏混合专家（MoE）模型，每个 token 激活 104B 参数，93 层，896 个专家，支持 1M token 的上下文窗口。^[1]
MXFP4 并不会让它变小。 每个参数 4 比特意味着原始权重下限约 1.4 TB（十进制）或 1.27 TiB，这还不含量化尺度、元数据、非 4 比特张量和运行时状态。
104B 活跃参数是计算指标，不是存储指标。 路由器可以为下一个 token 选择不同的专家，所以所有专家必须在某个地方保持可访问。
4GB GPU 只能是暂存区。 磁盘或 CPU 卸载将模型片段移动通过显存；它不能消除存储完整模型的需求。
AirLLM 目前没有记录 Kimi K3 支持。 其已发布的 4GB 示例针对 Llama 3 70B，而 Kimi K3 采用全新的自定义多模态 MoE 架构。^[4]
实用方案是 API。 低端笔记本可以通过 OpenAI 兼容端点调用 Kimi K3，让模型在远程基础设施上运行。

Kimi K3 硬件现状速览

项目	Kimi K3
总参数	2.8 万亿
每个 token 激活参数	1040 亿
架构	稀疏 MoE 配 KDA 和 Gated MLA 注意力
路由专家	896 个，每个 token 选 16 个
层数	93
原生权重格式	MXFP4 权重
激活格式	MXFP8
上下文窗口	1,048,576 tokens
原始 4 比特权重下限	约 1.4 TB（十进制）/ 1.27 TiB
4GB GPU 评估	无法容纳模型；仅实验级暂存

Moonshot 将 Kimi K3 描述为一个开源权重、原生多模态智能体模型，基于 Kimi Delta Attention、Attention Residuals 和 Stable LatentMoE 构建。它激活 896 个路由专家中的 16 个，包括 MoonViT-V2 视觉编码器。^[1]^[2]

这些架构选择降低了计算和长上下文成本。它们不能把万亿级检查点变成消费级 GPU 模型。

为什么 2.8 万亿 MXFP4 参数仍需约 1.4 TB

首先是简单计算：

2.8 万亿参数 × 4 比特
= 11.2 万亿比特
= 1.4 万亿字节
= 约 1.27 TiB

这是一个下限，不是完整部署估计。实际检查点还包含量化尺度、索引、配置、嵌入、以其他精度存储的张量和 401M 参数的视觉编码器。运行时增加激活、选中专家的工作内存、注意力状态、CUDA 或 NPU 内核，以及根据并发和上下文设置增长的 KV 或递归状态预算。^[1]

官方 Hugging Face 检查点被分割成许多大型 safetensor 分片；单个列出的分片测量为数十 GB。一个分片可能就超过 4GB 显卡的全部容量，推理引擎还没分配单个激活缓冲区。^[3]

相比之下，4GB 显卡理论上可以容纳约 80 亿个纯 4 比特参数，前提是每个字节都用于权重。实际上它能容纳更少，因为运行时也需要内存。Kimi K3 按总参数计数大约大 350 倍。

为什么"104B 活跃参数"不意味着 52GB 模型

MoE 稀疏性降低了计算量，而不是必须保持可用的检查点。Kimi K3 为每个 token 路由通过其 896 个专家中的一个小子集，所以只有 104B（占 2.8T）参数参与该 token 的前向传递。每个 4 比特，104B 参数本身代表约 52GB 的权重数据（不含运行时开销）。

即使这个 52GB 估计也不应被误认为是静态迷你检查点。下一个 token 可能选择不同的专家集。除非工作负载固定专家选择——这会改变模型行为——运行时需要访问整个序列中完整的专家池。

有三个不同的数字：

2.8T 总参数 决定完整检查点存储。
104B 活跃参数 近似每个 token 的计算和数据访问。
4GB 显存 仅是 GPU 在一个时刻能驻留的大小。

稀疏激活让 Kimi K3 比密集 2.8T 模型更高效。它不会让完整模型变成 104B 下载，104B 仍远超 4GB GPU。

层级卸载如何使用 4GB GPU

Kimi K3 从磁盘和主机内存卸载到 4GB GPU 暂存区

层级卸载改变了权重等待的位置，而不是有多少权重。一个基础卸载循环看起来像这样：

将大多数模型权重保持在 SSD 或系统 RAM 中。
将下一个需要的层或专家块加载到 GPU 内存中。
运行该部分前向传递。
驱逐该块并加载下一个。
对每一层和每个生成的 token 重复该序列。

这是大于 VRAM 的模型能执行的方式。AirLLM 用 Llama 3 70B 在 4GB GPU 上的演示推广了该模式，将模型分解成按层的分片并重叠加载与计算。^[4]

Kimi K3 使该模式难得多。它有 93 层、数百个可能的专家、自定义 KDA/Gated-MLA 注意力栈、原生多模态和超过 1TB 的量化权重。一个完整的 MoE 层本身可能大于 4GB，所以一个兼容引擎需要子层或专家级流式传输——不仅仅是普通层卸载。

性能瓶颈则变成数据移动。生成一个 token 可能触发许多跨数十层的随机或半随机专家读取。即使是快速 NVMe SSD 也比加速器内存慢几个数量级，下一个 token 会重复相同过程。卸载可以让实验启动；它不会让它具有交互性。

你能今天用 AirLLM 在 4GB GPU 上运行 Kimi K3 吗？

根据其发布的支持和示例（截至 2026 年 8 月 1 日），不能。 AirLLM 记录了 Llama、Mixtral、Qwen、ChatGLM、Baichuan、Mistral、InternLM 和相关模型族。其头条 4GB 结果是 Llama 3 70B，不是 Kimi K3。^[4]

这个缺失很重要。Kimi K3 不是现有加载器能自动识别的较大 Llama 检查点。一个有效的实现必须理解：

Kimi K3 的自定义模型配置和张量名称；
跨 896 个专家的 Stable LatentMoE 路由；
原生 MXFP4 权重和 MXFP8 激活；
KDA 和周期 Gated MLA 注意力层；
保留的推理输出和多模态视觉塔；
足够小以适应可用显存的专家感知分区。

Moonshot 目前推荐 vLLM、SGLang 和 TokenSpeed 用于 Kimi K3 部署。它不把 AirLLM 列为支持引擎。^[1]

这不能证明社区 4GB 移植是不可能的。它意味着复制的 AirLLM Llama 示例今天不是可复现的 Kimi K3 教程。一个可信的声明应该提供公共分支、确切提交、存储和 RAM 详情、提示、输出、每秒 token 数和使用完整官方权重的证明。

经过验证的 Kimi K3 部署看起来是什么样

生产 Kimi K3 配方在集群规模运行。一个当前 vLLM-Ascend 指南验证了跨四个 Atlas 800 A3 节点的 131K 上下文部署，每个节点有 16 个 64GB NPU。其 1M 上下文配置至少需要 8 个这样的节点。^[5]

这不是通用最小值——不同加速器、引擎、并发和上下文限制改变需求——但它是一个有用的现实检查。经过验证的配置衡量聚合加速器内存为万亿字节，不是千兆字节。

目标	明智的方案
从低端 PC 测试模型行为	使用托管 API
运行生产推理	遵循官方 vLLM、SGLang 或 TokenSpeed 集群配方
研究极端卸载	预期自定义引擎工作、>1.4TB 存储和非常低的速度
在消费硬件上完全离线运行	选择小得多的模型
在 4GB GPU 上使用交互式本地助手	使用 3B–7B 量化模型，而不是 Kimi K3

正确的硬件答案取决于目标是执行证明、交互式使用、多用户服务还是生产吞吐量。"在 4GB 上运行"这个短语没有该目标就毫无意义。

评估任何 4GB Kimi K3 声明的检查清单

在遵循教程之前，寻找回答这些问题的证据：

是官方 2.8T 检查点吗？ 携带 Kimi 名称的蒸馏、代理或较小模型不是 Kimi K3。
完整权重存储在哪里？ 答案应该说明超过 1TB 的本地或网络存储。
需要多少系统 RAM？ "4GB GPU"对 512GB 或 1TB 主机内存说不了什么。
哪个推理引擎提交支持 K3？ 一个通用 pip install 命令不足以用于新架构。
支持视觉还是仅语言？ 跳过 401M 视觉编码器改变了测试的模型表面。
使用了什么上下文长度？ 64 token 演示和 1M token 会话有根本不同的运行时需求。
测得的吞吐量是多少？ 要求每秒 token 数——或每分钟——加上首个 token 的时间。
答案经过验证了吗？ 一个进程成功启动不是证明它加载了正确权重或生成了连贯 K3 输出。

如果一篇帖子只报告显存，它遗漏了使这个技巧成为可能的资源。

从 4GB GPU 计算机使用 Kimi K3 的实用方式

今天有效的方案是保持推理远程并使用低端计算机作为客户端。本地 GPU 无关紧要；它只需要网络连接和 API 密钥。

reAPI 通过 OpenAI 兼容的 Chat Completions 端点公开 Kimi K3：

curl https://api.reapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $REAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "kimi-k3",
    "messages": [
      {
        "role": "user",
        "content": "Explain how expert routing changes memory access in a sparse MoE model."
      }
    ],
    "reasoning_effort": "high",
    "stream": true
  }'

这不是本地推理，不应被宣传为如此。这是希望 Kimi K3 能力而无需获取和运营多节点加速器集群的开发者的实用答案。完整请求契约在 Kimi K3 API 文档中，实时费率在模型页面。^[6]

如果你仍想尝试本地卸载

把它当作系统研究，而不是一条命令安装。一个现实的起飞前清单是：

至少 1.5–2TB 的快速空闲存储用于检查点、缓存和转换工件；
足够的带宽和耐心来下载许多大型分片；
明确支持 Kimi K3 的架构和 MXFP4 格式的推理引擎分支；
主机 RAM、内存映射、页面缓存和 SSD 耐用性的计划；
如果实验运行时尚未实现视觉，则仅语言模式；
第一次验证的短上下文和微小输出；
磁盘读取、GPU 利用率、首个 token 的时间和输出正确性的工具。

不要通过用 moonshotai/Kimi-K3 替换 Llama 模型 ID 来发明有效的命令。直到卸载引擎明确支持 K3，最可能的结果是不支持的配置、张量不匹配或转换期间的内存溢出失败。

FAQ

Kimi K3 真的能在 4GB GPU 上运行吗？

不能作为自成一体、实用的本地模型。未来的专业运行时可以使用 4GB 显存作为暂存缓冲区，同时从更大的存储或 RAM 流式传输权重，但完整模型不适合，当前主流 4GB 配方不记录 Kimi K3 支持。

Kimi K3 的权重有多大？

2.8T 参数中每四比特的理论下限是约 1.4 TB（十进制）或 1.27 TiB。实际检查点和运行时需要更多，因为量化元数据、非 4 比特张量、视觉编码器和执行状态。

Kimi K3 为什么说只有 104B 参数活跃？

Kimi K3 是稀疏 MoE 模型。每个 token 使用专家子集，降低计算，但未来 token 可以选择不同的专家。完整的 2.8T 专家池仍需保持可访问。

MXFP4 意味着任何有 4GB 显卡的 GPU 都能运行它吗？

不。MXFP4 意味着主权重使用大约每个值 4 比特。4 比特乘以 2.8 万亿仍约 1.4 TB（不含开销）。

AirLLM 能运行 Kimi K3 吗？

AirLLM 目前不在其记录的模型族中列出 Kimi K3，也不提供 Kimi K3 配方。它的 4GB 示例用于 Llama 3 70B。支持可能稍后添加，但不应从通用模型加载器中假设。

使用 Kimi K3 的最便宜实用方式是什么？

对于偶发或开发用途，使用托管按 token API。自托管仅当控制、持续量或数据位置需求证明多节点硬件和运维工作时才合理。

我能在本地运行 Kimi K3 的较小版本吗？

社区蒸馏可能会出现，但它们是具有不同权重和能力的独立模型。如果要求是 4GB 本地助手，选择为该内存预算设计的模型并准确标记它。

在 4GB GPU 上运行 Kimi K3 的诚实含义

在 4GB GPU 上运行 Kimi K3 仅在狭隘定义下可信：GPU 容纳一个小片段，而约 1.4TB 检查点的其余部分存储在其他地方并通过它流式传输。这可能成为一个有价值的研究演示，但今天不是实用本地部署。

标题不可信，因为它忽略了 GPU 周围的机器：SSD、系统 RAM、自定义运行时、传输时间，通常还有远程基础设施。在判断声明前计数所有这些资源。如果目标是使用 Kimi K3 而不是研究极端卸载，API 是现在在 4GB 笔记本上运行的方案。

披露： reAPI 发布了本文并提供托管 Kimi K3 API 访问。架构和量化事实来自 Moonshot 的官方存储库和技术报告。4GB 评估源自这些规格、当前引擎文档和基本存储算术；它不是 reAPI 在 4GB GPU 上复现完整 Kimi K3 生成的声明。

参考资料

Moonshot AI. Kimi K3 官方存储库——架构、模型摘要、原生 MXFP4 和推荐推理引擎。 检索于 2026 年 8 月 1 日。github.com/MoonshotAI/Kimi-K3
Kimi Team. Kimi K3: Open Frontier Intelligence. 发布于 2026 年 7 月。arxiv.org/abs/2607.24653
Moonshot AI. Kimi K3 官方权重和模型卡。 检索于 2026 年 8 月 1 日。huggingface.co/moonshotai/Kimi-K3
AirLLM. 支持的模型族和 4GB Llama 3 70B 层卸载示例。 检索于 2026 年 8 月 1 日。github.com/lyogavin/airllm
vLLM Ascend. 经过验证的 Kimi K3 多节点部署指南。 检索于 2026 年 8 月 1 日。docs.vllm.ai/projects/ascend/tutorials/models/Kimi-K3
reAPI. Kimi K3 API 参考和当前模型页面。 检索于 2026 年 8 月 1 日。reapi.ai/docs/kimi-k3 和 reapi.ai/models/kimi-k3