Kimi 发布的 K2 模型最近在国外科技社区好评不断。
Openrouter 首页推荐，Hugging Face、Perplexity CEO 发文称赞，最近又刚成为 LMArena 竞技场排名第一的开源模型。Cursor、Cline、VS Code 都接入了 K2。
作为月之暗面的首个开源旗舰模型，K2 这次的变化很大——万亿参数的 MoE 模型、非思考模型、主打 Agent Tool Use 能力和 Coding 能力，架构上也做了很多创新。
目前看各家 Coding 产品的争相接入，K2 的 Coding 能力应该是得到了认可。
憋了半年推出的这款模型，目前看来，K2 应该是成了。
K2 发布后，Kimi 的技术员们在知乎上发了不少讲解 K2 构架、以及为何押注 Agent 的文章，我们选了一些比较有价值的，从中可以看到，月之暗面对于今天的基础模型的想法和规划。
文章基于知乎回答贴中答主 Justin Wong、刘少伟的回答进行整理，Founder Park 有删减。
原贴地址：https://www.zhihu.com/question/1927140506573435010
Founder Park 联合外滩大会组委会、将门创投，征集能真正改变生活的 AI 硬件，寻找 AI 硬件的新可能。
-
30 万大赛奖金
-
创业扶持礼包
-
更多头部资源链接机会
扫码即可报名
01
关于 Tool Use & Agent
年初 MCP 开始流行，当时我们就想能不能让 Kimi 也通过 MCP 接入各种第三方工具。当时我们在 K1.5 研发过程中通过 RLVR （Reinforcement Learning with Verifiable Rewards） 取得了相当不错的效果，就想着复刻这套方法，搞它一堆真实的 MCP Server 直接接进 RL 环境中联合训练。
这条路很快撞墙，首先是部署麻烦，例如 Blender MCP 对于已经有 blender 的用户很容易，但在 RL 环境中装上 blender 就是一个负担；其次也是更致命的，不少第三方工具需要登录使用，你总不能为了训练 Notion MCP 使用而去注册一堆 Notion 账号吧？
但是我们换个思路，我的假设是：模型在预训练中已经知道工具该怎么用了，我们只需要把这个能力激发出来。这个假设的的基础很容易理解：预训练见过大量的代码数据，其中有大量的、用各种语言和表达方式的 API call， 如果把每个 API call 都当成一种工具，那么模型早就该会用了。另一个基础是，预训练模型本身就掌握了丰富的世界知识，比如你让他角色扮演一个 Linux Terminal，它完全能和你像模像样的交互一番， 那么显然对于 terminal tool 调用应当只需要少量数据就可以激发出来。
因此我们设计了一个比较精巧的 workflow，让模型自己合成海量的 Tool Spec 和使用场景，通过 multiagent 的方式合成了非常 diverse 的工具调用类数据，果然效果不错。
对于 Agent，我的理解就是，如果一个模型能做到这样，它就是个不错的 Agentic Model:
task = get_user_input()history = [task, ]while True:resp = model(history, toolset)history.append(resp)if not resp.tool_calls:breakfor tool_call in tool_calls:result = call_tool(tool_call)history.append(result)
当然这个流程还可以更高级一些，比如 toolset 可以让模型自己动态生成（参考 alita）。
在训练的视角，这样的数据也并不难合成，只要想办法把一段长长的任务改写成探索、思考、工具调用、环境反馈、错误重试、输出内容等不同形式交织轨迹，就不难激发出这样的能力。
我认为现阶段我们对模型 Agent 能力的开发还在早期，有不少数据在预训练阶段是缺失的（比如那些难以言语描述的经验/体验），下一代预训练模型仍然大有可为。
02
关于「写前端」
从 Claude 3.5 Sonnet 开始，AI 写前端到达了可以实用的程度，此后几乎所有新出的模型都会秀一下自己写前端的能力，Kimi K2 当然也不能免俗。 这里，我想 share 一下个人对此的思考。
一直以来各种文本 AI 都是默认输出 Markdown， 产品都是高级的 ChatBot，人们对一个 ChatBot 的期待无非就是能回答问题、写写文章、像人一样提供情绪价值。 有一次我在用户反馈中看到有用户要求 Kimi 「把文章重新排版，要放进一页 A4 纸」，这个在纯文本模式显然是无法实现的，我还把这个 case 当作一种产品经理与程序员的笑话一笑了之。
在大约今年 3 月的时候，Kimi Researcher 立项开发，当时无论是 Open AI 还是 Gemini 的 Deep Research 最终交付物都是一份纯文字的研究报告， 我们就想能不能做得不一样一些，借助当时已经不错的前端编程能力，给用户最终输出一份更丰富多彩的交互式报告。这个 idea 的最终形态 在 Kimi Researcher 上线之后已经和公众见面了，收获了不少好评。
但当我看到这个 idea 之后，脑中浮现了完全不一样的东西：没有人规定文本 AI 必须输出 markdown，如果「前端编程」成为 AI 默认的交互方式， 产品形态会变成什么样？
也就是说，把人与 AI 的交互方式，从 chat-first 变成 artifact-first：你和 AI 交互的过程不是为了它直接输出一段内容，而是它理解用户的需求后 立刻开启一个小工程，交付一个前端应用出来，用户可以继续追问、修改、迭代，但这些都围绕着一份交付物进行。
眼尖的朋友可能已经发现，这不就是个 cursor / aider / openhands 么？没错，从实现方式来说这就是 AI 编程干的事情，但如果在产品上精妙设计一下， 把写代码的过程藏起来，对于不懂编程的用户，这就是 「我和 AI 说句话，它竟然直接给我做了个 PPT / 画了个流程图 / 写了个小游戏」， 这一次，AI 不仅能 「把文章重新排版放进 A4 纸」 里，还能给你变换颜色甚至加上动效，这是完全超越传统 ChatBot 的体验。
于是我趁着清明假期肝了一天，从 aider 抄了 workflow 和 prompt 做了个 demo 出来，交互仍然是 ChatBot 的形式， 但当用户问 「介绍一下小米 Su7」 时，普通的 chatbot 会给出一段文字简介， 我这个 demo 会直接输出一份图文并茂、可以交互的 PPT 一样的网页出来， 用户还可以继续提要求修改，什么「背景改成黑色」，「再补充介绍一下 Su7 Ultra」 之类的。
我拿着这个 demo 到产品部门 sell idea，大家都表示很有意思，但是活实在太多，下次一定，下次一定。现在 K2 已经发布，Kimi Researcher 也已上线，相信 kimi 产品 也会很快有一些令人惊奇的变化。
记得 2009 年，我大二的那一年，有个师兄说：「也许 20 年后的编译器，就是程序员说‘我要一个 firefox’，然后编译器哼哧哼哧算了 2 天，拿出一个 firefox 来。」 当时我们拿这个当笑话和幻想，现在看来，甚至不到 20 年。
03
为什么开源
首先当然是为了赚个名声，如果 K2 只是一个闭源服务，现在一定没有这么多关注和讨论，搞不好还会像 Grok4 一样明明做得很好却要承担不少苛责。
其次是可以借助很多社区的力量完善技术生态，在我们开源不到 24 小时就看到有社区做出 K2 的 MLX 实现、4bit 量化等等，这些凭我们这点人力真的做不出来。
但更重要的是：开源意味着更高的技术标准，会倒逼我们做出更好的模型，与 AGI 的目标更一致。
这一点不是很容易理解，不就是把 model weights 放出来吗，为什么会「倒逼模型进步」呢？
其实答案很简单，开源了就意味着第一方再也不能用各种 hack 的方式粉饰效果，必须拿出足够通用、任何第三方拿到同样的 weights 都要能很简单地复现出你的效果才行。
对于一个闭源的 ChatBot 服务，用户压根不知道背后是什么样的 workflow、有几个模型，我有听说过一些 rumor 说有的大厂的入口背后是几十个模型、数百种场景分类和数不清的 workflow，还美其名曰这是「MoE 模型」。 在「应用优先」或者「用户体验优先」的价值观下，这种做法非常自然，而且是性价比远远优于单一模型的选择，但这显然不是 AGI 该有的样子，对于 Kimi 这样的创业公司来说， 这种做法不但会让自己越来越平庸，极大阻碍技术进步，而且也不可能拼得过每个按钮都有个 PM 雕花的大厂们。
所以，当开源要求你不能走捷径的时候，反而更有利于做出更好的模型和产品。（如果有人用 Kimi K2 做出了比 Kimi 更有意思的应用，我一定会去 PUA 产品部门的。)
04
绝大多数 Agent 产品，
离了 Claude 什么都不是
去年 Kimi 大规模投流引起不少争议，乃至到现在还有很多 diss 的声音。
哈哈，我只是个小程序员，这个背后的决策逻辑咱也不知道，咱也不乱讲。
我只说一个客观的事情： 在年初我们停止投流之后， 国内不少应用商店搜索 kimi 甚至第一页都看不见， 在苹果 App Store 搜 kimi 会推荐豆包， 在某度搜 kimi 会推荐 「某度 DeepSeek-R1 满血版」。
即使在如此恶劣的互联网环境之下，Kimi 也没有恢复投流。
年初 DeepSeek-R1 暴涨之后，很多人说 kimi 是不是不行了，你们是不是恨死 DeepSeek 了？恰恰相反，不少同事都认为 DeepSeek-R1 的爆火是个大好事， 它证明了硬实力就是最好的推广，只要模型做的好，就会获得市场认可；他证明了那条我们相信的路不仅能走通，而且是一条康庄大道。 唯一的遗憾就是：这条路不是我们走通的。
在年初的反思会上，我提出了一些相当激进的建议，没想到植麟后续的行动比我想的还要激进，比如不再更新 K1 系列模型，集中资源搞基础算法和 K2（还有更多不能说的按下不表）。
前一段时间各种 Agent 产品很火，我看到不少声音说 Kimi 不应该卷大模型，应该去做 Agent 产品，我想说：绝大多数 Agent 产品，离了 Claude 以后，什么都不是。Windsurf 遭 Claude 断供的事情更加证明了这一点。 2025 年，智能的上限仍然完全由模型决定，作为一家以 AGI 为目标的公司，如果不去追求智能的上限，那我一天也不会多呆下去。
05
K2 模型结构的详细解释
在启动 K2 训练之前，我们进行了大量模型结构相关的 scaling 实验，结果是，所有当时 propose 的、与 DSv3 不同的结构，没有一个能真正打败他的（顶多旗鼓相当）。因此，问题就变成了，我们要不要为了与 DeepSeek 不同，强行选择一个没有优势但不一样的结构，最终的答案是 no。原因也很简单：DSv3 的结构是经过验证，在 large scale 上依然有效的，而我们的「新结构」还并没有经历过足够大规模的验证。在已经有 muon 优化器和更大参数量两个巨大变量的前提下，我们并不想引入没有明确收益的额外变量来「标新立异」。于是，就有了第一个约束条件：完全继承 DSv3 的结构，调整适合我们的模型结构参数。
而第二个约束条件就是成本，包含训练成本和推理成本。原因很简单，作为一家小公司，我们的训练和推理资源都是非常有限的。在 DSv3 推出之后，我们经过认真评估，认为它的训练成本和推理成本，都比较接近我们当前能承受的上限。因此，我们需要将 K2 的训练和推理成本，尽量控制在与（我们自己训推）DSv3 持平的水平。
综上所述，模型结构的设计问题就变成了： 在给定 DSv3 结构的框架之下，如何选择合适的参数，使得模型在训练、推理成本与 DSv3 相当的前提下，获得明显更低的 loss。其中训练成本方面本文不会详细展开（才不会承认因为我也是一知半解），我们会在我们之后发布的 tech report 中介绍 K2 的训练方案与优化，敬请期待：）
5.1 具体改动和动机
图片来自@rasbt from X：https://x.com/rasbt/status/1944056316424577525
正如很多人对比两份 config 文件所观察到的，我们在模型结构参数上，具体的改动主要包含： （1） expert 数量 （2） attention head 数 （3） 前面的 dense 层数只有 1 层 （4） 无分组的简化版 router。接下来我会按这个顺序，从模型推理的角度介绍它们背后的考量。本次推理方案完全沿用 DeepSeek 的 tech report [1] 和 OpenDay [2] 中提到的 EP+DP 方案，理论分析暂不含通信（假设通信可被推理层面尽可能 overlap 掉）。
5.2 num_experts = 384
这条结论来自 pretrain 团队的 sparsity scaling law，是 K2 项目从 pretrain 阶段开始的主要驱动力之一（另一个当然是 MuonClip）。简而言之，我们验证了在固定 # activate params 不变的前提下，单纯增长 MoE 总参数量，scaling law 依然成立，且不论训练 loss 还是验证 loss，结论始终保持，也就是无需担心增大总参数量会过拟合。因此，num_experts=384 承担了降低模型 loss 的核心任务。
对推理的影响：
-
prefill 阶段：如果 prefill 节点数能做到和 num_experts=256 时一样大，且 prefill 的 seqlen 足够长，耗时基本无明显增长，因为此时的 prefill 是 compute bound 的任务，我们的激活参数量不变，MoE 环节的总 FLOPS 也不变。
-
decode 阶段：由于需考虑线上实际的 TBOT 指标，我们无法无限增大推理时的 batch size（虽然现在已经被狂喷慢慢慢了 orz）。因此可以粗略地认为 MoE 阶段的 GEMM 仍是 memory bound，那么 MoE 参数量增大到 1.5×，相关计算的耗时也就变成了 1.5×。以 EP=128 为例（128 是我们的 384 和 DSv3 的 256 的最大公约数，方便比较），对 DSv3 来说，每个 EP rank 上会存放 2 个路由专家和 1 个共享专家，大约 7.5 GB 的 MLP weights（不计算 EPLB 方案 的冗余专家）；而 K2 则需要大约 10 G，大了 2.5G。
5.3 num_attention_heads = 64
MoE 阶段实打实地变慢（贵）了，我们就得考虑能否从其他环节找补回来，attention 的 head 数是第一个想到的切入点。原因在于 MLA 的论文中，DeepSeek 为了让 MLA 尽可能充分利用访存带宽，相比 MHA 常见 attention heads ≈ layer 数的设计，把 head 数翻倍，也确实带来轻微涨点，但也带来两个问题：prefill 和 decode 实际上都变贵了。相比之下，如果我们将 attention head 数量重新变回 64：
-
prefill 阶段：
（1） MLA attention 计算量为 2hs²（d_nope + d_rope + dv），h 是 head 数，s 是序列长度，三个 d 分别为 128，64,128。而整个模型其他部分基本都是矩阵乘法，计算量的公式为 2Ns，其中 N 是所有矩阵乘法相关参数的参数量。注意到，attention 计算量与 seqlen 成平方关系，而其余矩阵乘法则为线性关系，即随输入序列长度增大，attention 在 prefill 阶段耗时占比越大。而 K2 的目标场景（agent、vibe coding）中，长序列是标准的使用形态，正好被这个问题直戳痛点。而将 head 数砍半，则可以一定程度上削减这个快速增长的平方项对整体耗时造成的影响。
（2） 除此之外，attention 前后还有 QKVO projection，这几个矩阵乘的参数量与 head 数线性相关。大家应该也能看到 DSv3 的激活参数 37 B，而 K2 只有 32 B，差的 5 B 就来自这里。粗略来看，DSv3 激活的 37 B 中，QKVO projection 占 10 B，K2 只有 5 B，随着参数量的减少，这几个 projection 在 prefill 阶段的 FLOPS 消耗也随之减少，K2 再胜一局。
-
decode 阶段： attention core 的计算耗时主要取决于 KV cache 大小，这一点 K2 和 DSv3 完全相同，平手。但 QKVO projection 部分 与 prefill 阶段 类似，实打实地把 10 GB 的访存量降到了 5 GB。更关键的是，在 DP Attention 下，QKVO projection 会在所有 rank 上 replicate，因此这 5 GB 的差距不会像 TP 那样，随并行度增大而摊薄。因此不管 EP size 多大，每个 rank 都有 5GB 的仿存减少。回顾前面 MoE 的差距，EP128 下我们总参数量增大到 1TB，每个 rank 才多了 2.5 GB 访存，而这里 head 数从 128 降到 64，就能省下 5 GB，瞬间感觉自己很赚。
综上，降低 head 数可以瞬间把 MoE 参数增大亏掉的部分全部补回来，还有富余。我们最担心的只剩下这样对模型效果是否有明显的负影响。算法同学通过充分对比实验，确认了把 head 数还原到接近层数的「baseline」设置对 loss 的负影响要远远小于 MoE 参数增大的正影响，于是，num_heads=64 就这么愉快地决定了。（留一道思考题：减少 attention head 数，还可以为 Speculative Decoding 留下了更多提速空间。)
5.4 first_k_dense = 1
与 DeepSeek 的观察类似，我们也同样在训练中发现第一层 MoE 的 router 很难做到负载均衡，但不同的是第二层之后并没有发现什么大问题。为了更充分利用 MoE 优势，我们只保留第一层 dense，其余全用 MoE。这个操作对 prefill 几乎无影响，对 decode 每个 rank 大约增加几百 MB 访存，可以忽略不计。
5.5 n_group = 1（expert 无分组）
expert 分组的最大价值是当一个 rank 上存在多个 expert 时，可以让它们同组，在 device（GPU） level 让 MoE 计算更均衡。但在当前模型的参数规模下，我们不得不使用很大的 EP，每个 device 上只剩少量、甚至只有一个 expert，group level 的均衡则从 GPU 层面转换到了节点层面。而即便节点层面能够做到相对均衡，但每个节点内部遇到所有 token 都被 route 到当前 group 的同一个 expert 上这种最坏情况下，MoE 计算耗时仍然不会理想。因此，EPLB 方案里面的动态重排和冗余专家对于当前设定下的负载均衡问题相对来说要更为关键一些。而更自由的 router 方案能让 expert 的组合空间显著增大，从而进一步提升模型能力。
以上就是 K2 模型结构参数被设定为当前这个状态，来自推理侧的完整思维链了。综合以上四个相比 DSv3 的改动，我们能够得到一个在相同 EP 数量下，虽然总参数增大到 1.5 倍，但除去通信部分，理论的 prefill 和 decode 耗时都更小的推理方案。即使考虑与通信 overlap 等复杂因素，这个方案也不会比 DSv3 有显著的成本增加。可以自豪的说，虽然只有小小的 4 个参数的改动，但每一个决策的背后都有充足的理论分析和实验验证。也希望模型开源后，能有更多的推理厂商和框架共同帮我们验证前面分析的正确性。
（文：Founder Park）