「2.8T 参数，104B 激活，100 万 token 上下文，一次开放日把模型权重和训练 Infra 一起甩出来。」

这不是在讲科幻。2026 年 7 月底，月之暗面把 Kimi K3 放进了开源池。上一次我看到这种阵仗，还是 DeepSeek-R1 把推理模型成本打穿的时候。但 Kimi K3 这次不太一样，它不只是扔了一个 checkpoint，而是把 Agent 训练所需的一整套基建都摆到了台面上。

我在读完 47 页技术报告和 GitHub 上 AgentENV 的 README 之后，脑子里反复只剩一个问题，开源大模型的竞争，是不是已经从「谁参数多」转向了「谁能把 Agent 训练的成本和工程门槛打下来」？

坦率的讲，这个问题我现在也答不完整。但我可以把这次开源里真正值得看的东西，一层一层剥给你。

一、模型本身，已经不是故事的全部

先说说最显眼的数字。Kimi K3 总参数量 2.8T，激活参数 104B，93 层，896 个 routed expert，每次 token 激活 16 个，上下文窗口 1048576 token。 vision encoder 是 MoonViT-V2，401M 参数，原生多模态，MXFP4 权重配 MXFP8 激活。

这些数字放在一起什么意思？

它意味着 Kimi K3 是目前公开可下载的最大规模开源模型，而且不是那种「论文里开源、权重藏半年」的玩法，是 Hugging Face 上直接能拉的权重。但这个其实不算最让我意外的部分。

真正让我愣住的是，它把 scale efficiency 较 Kimi K2 提升了大约 2.5 倍。注意，不是 loss 降了 2.5 倍，是整体 scaling efficiency。你想想看，在同样的算力和数据预算下，K3 能用更少的实际开销跑出更强的能力。这个指标对研究机构和小团队来说，比单纯的总参数量重要得多。

怎么做到的？

核心是三张牌，Kimi Delta Attention（KDA）、Attention Residuals（AttnRes）和 Stable LatentMoE。

KDA 是一种线性注意力变体，用固定大小的循环状态替代传统 softmax attention 里随着序列长度线性增长的 key-value cache。序列越长，省下的内存和通信量越夸张。AttnRes 则让每一层都能选择性地关注前面所有层的表示，相当于给深度网络加了一层「跨层回溯」的能力。Stable LatentMoE 把 routed expert 扩到 896 个，每次只激活 16 个，配合 Quantile Balancing 和 SiTU-GLU，解决了超稀疏 MoE 训练容易崩的老毛病。

这三样东西单独看都各有论文，但一起塞进一个 2.8T 的模型里还能稳定训练，就是另一回事了。

二、让 KDA 跑起来，才是真的工程硬仗

做算法的人容易忽略一个事实，一个新 attention 机制能不能落地，70% 取决于有没有配套的 kernel 和并行策略。

KDA 的状态是循环更新的，天然有串行依赖，GPU 最烦的就是这个。Kimi 团队为此做了三件事。

第一件是 FlashKDA。这是一个基于 CUTLASS 的 chunkwise kernel，把 chunk 内的并行计算和跨 chunk 的状态传播重叠起来， token-parallel 阶段和 head-parallel 递归阶段独立调度。技术报告里说，它比 Triton 参考实现快很多。具体数字我没拿到，但这种级别的 kernel 优化通常意味着几倍甚至数量级的吞吐提升。

第二件是 KDA Context Parallelism。当序列长到一百万 token 时，单纯靠 tensor parallelism 切 head 已经不够，因为每个 rank 只分到几个 head，prefill 时大量 SM 空转。KCP 的做法是把序列在单个 rank 的 SM 之间再切一段，各自算完状态再合并，跨设备的 KCP 负责节点间通信。这样 intra-device 和 inter-device 两条线同时并行。

第三件是 state-aware prefix caching。KDA 的循环状态是固定大小的，天然适合缓存和复用。对于多轮对话、代码仓库反复读取、Agent 工具链调用这些前缀高度重叠的场景，这一招能把长上下文推理的成本再往下压。

说真的，看到这里我已经有点累了。不是因为复杂，是因为这些工程细节每一块都够一个团队啃半年。月之暗面把它们全开源出来，等于把竞争对手的模仿门槛从「复现模型结构」提到了「复现整个训练和服务体系」。

三、MoonEP，2.8T MoE 训练的平衡术

如果说 KDA 是算得快，那 MoonEP 就是算得稳。

2.8T 的 MoE 做 expert parallelism，最大的噩梦是负载不均衡。不同 expert 的激活分布随时在变，今天 hot 的 expert 明天可能就冷了，静态切分会导致某些 GPU 累瘫、某些 GPU 摸鱼。

MoonEP 的做法是动态冗余专家。它在正向传播时在线规划冗余 expert 的分布，把负载重的专家多复制几份放到不同设备上，通信保持零拷贝。技术报告里用了「perfectly balanced expert execution」这种很硬的词，配合 static computation shapes，意思是即使 expert 激活分布波动，计算图形状也保持稳定，避免动态 shape 带来的编译和调度灾难。

这套东西对预训练至关重要，因为 MoE 的规模一大，任何不均衡都会被算力账单放大。但更让我在意的是它对下游的暗示，如果 MoonEP 后续真的开源，社区跑 2.8T 模型的预训练或者继续预训练，才称得上可行。

不过这里我得诚实地说一句，截至我写文章时，MoonEP 和 FlashKDA 的 GitHub 仓库还没公开。AgentENV 已经能拉到代码和文档，后两者只在技术报告里做了详细描述。所以我上面写的 MoonEP 细节，全部来自报告原文，而不是我亲手跑过的代码。

四、AgentENV，这次开源里最被低估的一块

好，终于说到我最感兴趣的部分。

AgentENV 是一个给 Agent 训练用的 microVM 沙盒系统，基于 Firecracker。它和 Kimi K3 的训练是绑在一起的，技术报告里说整个训练周期里跑了超过 5100 万个 sandbox。

为什么要用 microVM？

传统的容器沙盒我也用过，跑 LangGraph 的 tool call、跑代码执行、跑浏览器自动化，都还行。但当我真的试过让 Agent 在容器里自由探索时，问题就出来了。Agent 会 mount 磁盘、会起新的容器、会改内核参数、会触发各种 edge case。容器共享宿主机内核，一旦 Agent 做了不该做的事，宿主机可能直接 panic 或者死锁。

AgentENV 的解决思路很直接，给每个 Agent 一个真正的虚拟机，Firecracker 启动，50 毫秒以内完成 boot 或 resume，pause 不到 100 毫秒。隔离级别上去了，Agent 想怎么折腾就怎么折腾，甚至可以在沙盒里再起虚拟机。

更狠的是它的生命周期管理。AgentENV 支持三种操作。

Pause 和 Resume。Agent 等大模型推理结果的时间，可能占整个 sandbox 生命周期的 98%。暂停时释放 CPU 和内存，推理完再恢复，资源利用率一下就拉开了。

Fork。从当前 sandbox 状态分出一个完全一样的副本，同时保持原沙盒继续跑。这在 RL 里做 reward judging 特别有用，同一个状态派生多个轨迹，互不影响。

Snapshot。增量保存脏内存页，checkpoint 133 毫秒，resume 49 毫秒。长程任务中途出错可以从快照恢复，不用从头再来。

还有一个容易被忽略的点，OverlayBD 和 ublk。AgentENV 能同时启动上万个不同镜像的沙盒，靠的就是 overlaybd 的按需加载和 P2P 分发，本地盘只做热缓存。复制写内存和页缓存共享把内存超配比推到了 6.5 倍。这个数字对大规模 RL rollout 来说是生死线。

我跟你说，这部分我读了好几遍。不是因为难懂，是因为我太清楚一个痛点，现在做 Agent 训练的人，90% 的时间花在沙盒稳定性、状态恢复和资源调度上，而不是模型本身。AgentENV 如果能在社区里跑起来，省下的不只是 GPU 钱，是头发。

五、百万 token 的 Agentic RL，是怎么练出来的

有了沙盒，还要解决一个更狠的问题，怎么在可控成本内，给 2.8T 的模型做百万 token 的强化学习。

Kimi K3 的做法是 co-located RL。训练 rollout 和模型更新放在同一批 GPU 上，不用把数据搬来搬去。配合 partial rollout，把超长的轨迹切成段，避免一条长轨迹把整批卡的 tail latency 拉爆。

但 co-located 带来一个内存死结，下一迭代需要复用这一轮的 KV cache，而训练本身也要吃大量显存。Kimi 的解法是做 external KV-cache pool，把 prefix 的 KV cache 缓存起来，miss 的时候代价极高，所以命中率是核心优化目标。再加上自适应 throttle 和 resumable sandbox，百万 token 的 RL 实验能在几百张 GPU 内完成。

技术报告里没有给出具体的训练成本数字，但几百张 GPU 跑 1M context 的 RL，本身已经说明他们把 infra 压缩到了极致。

这段训练的意义不止是 Kimi K3 变强了。它证明了一件事，未来 frontier 模型的 post-training，将越来越多地是「长程 Agent 任务 + 沙盒反馈 + 超长上下文 RL」的组合。纯文本 SFT 的天花板，已经肉眼可见。

六、跑分和真实的差距

说完工程，我带你看看分数，但不想只念 leaderboard。

Kimi K3 在多个 coding benchmark 上排在第一梯队。DeepSWE 67.5，Terminal-Bench 2.1 88.3，ProgramBench 77.8，FrontierSWE 81.2，SWE-Marathon 42.0。在 Agentic 侧，BrowseComp 91.2，MCPMark-Verified 94.5，AutomationBench 30.8，JobBench 54.3。 vision 方面，OmniDocBench 91.1，Video-MME 90.0。

这些数字里最让我注意的是 SWE-Marathon 42.0。这个 benchmark 测的是长程软件工程马拉松，Kimi K3 超过了 Fable 5 的 35.0 和 GPT-5.6 Sol 的 39.0。这不是短平快的代码补全，而是持续数小时甚至数天的工程任务。K3 在这里领先，说明它的长程一致性和沙盒交互能力是真的有东西。

但技术报告自己也说了，Overall performance still trails the most powerful proprietary models, namely Claude Fable 5 and GPT-5.6 Sol。我没有把这句话删掉，因为诚实比漂亮重要。Kimi K3 很强，但不是无敌。它在某些 coding 和 agentic 任务上追平甚至超过最强闭源模型，但在另一些任务比如 CritPt 和 GDPval-AA 上还有差距。

开源模型做到这个份上，其实已经不需要在每项都拿第一了。它的价值是「可下载、可部署、可二次训练」。闭源模型再强，你也只能调用 API。K3 是把 frontier 能力放到了你自己的服务器上。

七、对 LangGraph 和 Agent 开发者来说

写到这里，我想把镜头从论文拉回到我自己熟悉的领域。

我过去一年写了不少 LangGraph 和 AI Agent 相关的东西，最大的感受是，模型能力只是 Agent 系统的冰山一角。Agent 能不能稳定跑长程任务，取决于工具调用是否可靠、状态管理是否清晰、沙盒是否安全、上下文窗口是否够长、成本是否可控。

Kimi K3 这一轮开源，恰好把这些拼图里的几块给补上了。

上下文窗口到 1M token，意味着你可以把整份代码库、多轮对话历史、大量工具返回结果一次性塞进 prompt。以前做复杂 Agent 要拼命切分、摘要、rag，现在可以先把完整上下文喂进去再说。

原生多模态意味着 Agent 可以直接读图、读视频、读 UI。做自动化测试、做界面操作、做文档理解，不再需要先把视觉信息转成文字描述。

AgentENV 意味着你可以拥有一个和 Kimi K3 训练时同款的沙盒环境。虽然现在它还主要服务于 RL 训练场景，但它的 E2B-compatible API 暗示了未来可以直接当通用 Agent runtime 用。

我跟你说，我已经开始想一些邪门用法。比如让 LangGraph 的 ReAct Agent 跑在 AgentENV 里，每次 tool call 都在 Firecracker 里执行，出错就 snapshot 回滚。或者拿 Kimi K3 做 long-horizon coding 的 supervisor，让多个子 Agent 在隔离沙盒里并行改代码，最后合并 PR。

这些想法我现在还没时间一一验证，但光是想想就挺兴奋的。

八、开源模型竞争的下一幕

如果把 2025 年初 DeepSeek-R1 的开源定义为「推理成本革命」，那 Kimi K3 这一轮更像是「Agent 基建革命」。

它传递了一个信号，未来的开源竞争不再只是比谁的模型更大、谁的 benchmark 更高，而是比谁能让开发者更便宜、更稳定、更安全地训练和使用 long-horizon Agent。模型权重只是门票，infra、kernel、沙盒、RL 系统才是护城河。

这对中小团队是利好，也是压力。

利好在于，你可以站在 Kimi K3 的肩膀上继续训练领域模型，不用从零预训练一个 2.8T 的怪兽。压力在于，大家都能拿到的底座，拼的就是你对应用场景的理解、你的数据飞轮、你的 Agent 编排能力。

你想想看，模型能力开始商品化了。真正的差异化会回到工程、产品和数据上。

九、写在最后

回到文章开头那个问题，开源大模型的竞争，是不是已经从「谁参数多」转向了「谁能把 Agent 训练的成本和工程门槛打下来」？

我的答案是，是的，而且这个转折比很多人以为的来得更快。

Kimi K3 2.8T 的参数确实很唬人，但它真正给我的冲击不是那个数字，而是它把一套完整的 Agent 训练流水线摊开在了阳光下。从 KDA 到 FlashKDA，从 MoonEP 到 AgentENV，从 co-located RL 到百万 token 的 partial rollout，这些东西单独看都是工程细节，合起来却是一套新范式的地基。

当然，我也得承认，我现在还没跑过 Kimi K3 的权重，AgentENV 也还没在我自己的机器上起起来。上面很多判断来自论文、README 和公开 benchmark，不是一手实验。如果你后续真的去部署了，遇到一些我没想到的坑，那太正常了。

但不管怎么样，有一群人在认真地把 frontier 模型的训练和服务成本往下砸，这件事本身就值得我们关注。

毕竟，下一次 AI 应用的爆发，很可能不是来自某个更厉害的 API，而是来自某个开发者在自己服务器上跑起来的一整套 Agent。