Kimi K3 开源最大的好处，不是给你下载来用

Kimi K3 正式开源以后，最先冲到 Hugging Face 准备下载的人，滑不了几下，就会看到一个数字：2.8T。

Hugging Face 仓库当前约 1.56 TB，包含 96 个 safetensors 权重分片，单片大多约 16GB。Kimi 官方建议，这台模型最好运行在由 64 个或更多加速器组成的超级节点上。

光看这些数字，可能还不足以死心，DeepSeek 当年都可以自己部署，K3 就一点都不行吗？那么就只能算账了——

堆 Mac mini 也没用的一集

说起来像一个悖论，过去说起开源软件，人们想到的是把模型下载下来，自己安装、调试和运行；开源模型最初进入大众视野时，也伴随着类似想象。

如果仍沿用之前一度很流行的「买一台Mac mini，在本地跑DeepSeek」这套想象，我们可以来算一下：

2024 款 M4 Pro Mac mini 最高可以配置64GB统一内存，拿仓库体积 1.56TB 的 K3 权重做一个极粗略的除法，至少需要 25 台，才刚刚能把权重全部塞进内存（考虑到操作系统、推理框架、KV 缓存和必要的运行余量，实际还得再备几台）。

更何况，这些 Mac mini的内存并不会自动拼成一个巨大的内存池：896 个专家的权重需要在机器之间不断调度，而 Mac mini 没有数据中心 GPU 集群使用的高带宽互连。即使真的把二三十台机器堆满一张架子，也不意味着 K3 已经能以可用的速度运行。

这和当年 DeepSeek-R1 开源时掀起的自部署潮形成了鲜明对比，也反映出，当时人们所说的自部署，多数并不是在运行 671B 参数的完整 R1，而是官方同时发布的 1.5B、7B、8B、14B、32B 和 70B 蒸馏模型。

一台 Mac mini 就可以运行其中的 7B 或 14B 版本，内存更大的机器甚至可以尝试 32B；安装 Ollama、输入一行命令，普通用户确实能够得到一台完全离线的 AI。

K3目前开放的是2.8T完整权重，没有提供一套从小到大的官方蒸馏版本，自部署的单位因此从「一台Mac mini」变成了「至少二三十台Mac mini组成的集群」——前者还勉强可以说是 AI 狂热 fomo 患者的治疗项目，后者已经接近一项机房工程。

显然，「开放」不是面向一台普通电脑的，既然用户无法直接拥有它，那么，2.8T 的模型究竟开给了谁？

开源了，但它不是一台个人电脑上的模型

答案并不神秘：云计算厂商、推理服务商、企业和应用开发者。

K3 拥有 2.8 万亿总参数，是目前首个开放权重的 3T 级模型，它同时具备原生视觉能力和 100 万 token 上下文窗口，面向长程编程、知识工作和需要持续调用工具的智能体任务。

为了把如此庞大的模型真正跑起来，K3 采用了 MoE，也就是混合专家架构，可以把这个架构想象成一家公司。公司一共有 896 个专业部门，但每处理一个 token，只会根据任务叫来其中 16 个部门，再加上共享专家共同工作。

这样一来，K3 每次实际参与计算的参数约为 1040 亿，而不是完整的 2.8 万亿，计算成本因此大幅下降。但「每次只调用 16 个部门」，不等于整栋办公楼可以不存在。896 个专家的权重仍然需要被保存，并在多个加速器之间快速调度。 MoE 减少的是每一步推理要进行的计算，不是把一台 2.8 万亿参数模型变成了一台 1040 亿参数模型。

K3 还加入了 Kimi Delta Attention、Attention Residuals 和 Stable LatentMoE 等新架构，它们分别处理长上下文中的注意力效率、深层网络中的信息流动，以及极高稀疏度下专家如何稳定分工。Moonshot 给出的结论是，相比 K2，这些变化让 K3 获得了大约 2.5 倍的整体扩展效率。

这里的关键词是「效率」，K3 使用 MXFP4 权重和 MXFP8 激活，已经通过量化进一步压缩模型，并针对大规模推理优化专家通信和缓存；但官方依然建议使用 64 个以上加速器组成的高带宽超级节点。

「官方建议」通常听听就好，毕竟，能有这些钱的，也不太需要官方建议了……

总体上 K3 的开源需要稍微换一种理解：它是一次完整的开放权重，任何人都可以查看、部署、修改和开发衍生产品，但「任何人都可以」指的是权利上的开放，并不意味着每个人都具备运行它的基础设施和条件。

因此，恰恰是云厂商和推理服务商可以部署 K3，把它作为 API 提供给开发者；企业可以在自己的基础设施上运行或微调模型，把内部数据和工作流程接进去；做编程、研究、设计、游戏或办公产品的团队，也可以把 K3 嵌入某项具体功能，而不必从零训练一台前沿模型。

K3 的自定义许可证甚至专门区分了两类业务。一类是直接向第三方出售模型推理或微调能力，也就是「模型即服务」；另一类是把模型能力嵌入某项具体功能或 harness 的终端产品。前者在收入超过一定规模后需要与月之暗面另行签约，后者则不被视为纯粹的模型服务。

这个看似法律化的定义，其实透露出非常清楚的产品方向：月之暗面不只是希望别人把 K3 原封不动地包装成另一个聊天接口，也希望开发者围绕它建立新的工作环境和具体应用。

同一个 K3，不同的产品

对普通用户来说，K3 开源后最直接的变化，可能不是桌面上多出一个可以本地安装的软件，而是在越来越多产品里间接遇到它。

AI 行业常把模型外面的产品叫作「壳」，这个说法多少带有贬义色彩，好像只要接入一个 API、套上一层界面，就能假装拥有自己的技术。

这种产品当然存在，但在智能体和长程任务里，模型外面的 harness 已经远远不只是一层聊天界面。

它决定模型能不能读取整个代码仓库，能不能打开终端、运行程序和查看报错，能不能访问浏览器、文件系统与外部工具；它也决定 100 万 token 的上下文如何分配，旧内容什么时候被压缩，任务进行到一半时如何保存状态，以及模型准备删除文件、发送邮件或执行付款前，是否必须得到用户确认。

模型提供的是一组潜在能力，harness 负责把这些能力组织成一套可以工作的流程。一个工具权限不完整、上下文管理混乱的环境，足以让同一个模型表现得像换了一副脑子。

K3 自己的官方评测，就提供了很直观的例子。技术报告中的编程和智能体成绩，并不是让所有模型在同一个空白聊天框里回答问题，而是分别放进 Kimi Code、Claude Code、Codex 等不同运行环境中。

K3 在部分测试中使用自家的 Kimi Code，在另一些测试中则使用 Claude Code；同一项 Kimi Code Bench 2.0 里，K3 使用 Kimi Code 得到 72.9 分，放进 Claude Code 时则达到 73.7 分。权重没有改变，改变的是模型周围的工具、提示、上下文管理和执行循环。

K3 在这方面还有一个非常具体的要求：它采用「保留思考历史」的训练模式，在多轮对话和工具调用中，harness 必须把模型此前返回的完整消息原样传回，包括推理内容和工具调用记录，而不能只保留用户最后看到的答案。

100 万 token 上下文同样如此，拥有一个足够大的上下文窗口，不代表把所有东西一股脑塞进去就是最优方案。K3 在 BrowseComp 评测中也展示了同一模型在不同运行配置下的差异。更高的计算和上下文预算可以换来更好的成绩，但成本也随之上升；官方在部分配置中会在上下文达到 30万 token 时主动压缩，而不是机械地把 100 万 token 窗口全部用满。窗口大小是模型参数，什么时候整理、保留和遗忘，则是 harness 的工作。