Kimi K3 训练篇：一文详解 2.8 万亿参数的K3模型如何训练

万事可爱^

385人浏览 · 2026-08-08 11:03:09

万事可爱^ · 2026-08-08 11:03:09 发布

K3 训练时创建了 5121 万个沙箱。不是为了炫规模，而是只有高保真环境，才能让 RL 学会真实世界里的活儿。

架构篇聊了 K3 的「身体结构」。但一个模型强不强，身体只占一半，另一半是「怎么喂数据、怎么调教」。这篇讲训练。

我读报告时有个越来越强的感受：K3 真正想做的事，不是「在榜单上刷分」，而是「训出一个能在长上下文里真正使用工具、写代码、做研究的 agent」。所以训练这一半的篇幅，比架构还长，而且大量笔墨花在「让训练环境像真实世界」上。这对我们做工程的其实更有启发：很多时候模型不行，不是网络不够深，是训练数据和环境太假。
在这里插入图片描述

图：K3 的训练是一条完整的流水线：语料 → 原生多模态 → 长上下文课程 → 后训练三段式 → 白盒环境、知识图谱、可验证奖励、沙箱四大支撑系统。

下面分几块讲：预训练数据、长上下文怎么训出来、后训练三段式（SFT→RL→蒸馏）、以及最精彩的「白盒环境 + 知识图谱任务合成」。

预训练数据：四域 + 视觉，重点是「改写要保真」

K3 的预训练语料覆盖四个文本域：网页、代码、数学、知识，再加一大块视觉语料（图像描述、图文文档、OCR、视频、甚至视觉编程数据）。

数据管线本身不稀奇：规则过滤、分类器打分、去重，采样率靠在小模型上做消融定。但有一个细节我觉得值得记：他们对「知识」和「数学」语料做了改写（rephrasing），用风格和视角多样的 prompt 来做 chunk 级自回归生成，并且要拿生成结果和原始文档做「保真校验」。

为什么这个重要？因为直接抓来的网页和数学材料质量参差，简单去重后还是有很多噪声。改写能把同一份知识用不同说法表达，等于做了一次数据增强；但如果不校验，模型就会「学歪」，记住改写引入的错误。他们专门加了一道 fidelity verification，确保改写没篡改原意。这其实是数据工程里最容易被偷懒跳过、却最影响上限的一步。我自己做训练数据时也踩过这个坑：不校验的增强，短期 loss 好看，长期净是幻觉。

视觉数据里有个点我挺喜欢：他们大量合成了「代码段 + 它渲染出来的图」这种配对，覆盖 SVG、3D、网页、游戏、CAD。这意味着模型从预训练起就见过「写一段代码会画出什么」，对后面做前端、做可视化是直接的养分。

原生多模态：从第一步就联合，而不是事后嫁接

很多多模态模型的做法是：先训一个纯语言大模型，再把视觉编码器「接」上去做对齐（post-hoc alignment）。K3 选了原生多模态策略：训练一开始，语言和视觉就在同一个 next-token 预测目标下联合优化，文字 token 和视觉 token 交错着喂。

好处是共享 backbone 从最早期就学到统一的多模态表示，而不是「语言归语言、视觉归视觉、最后拼一下」。代价是工程上更难（视觉编码器的计算量会卡在关键路径上），报告后面用一整套流水线气泡隐藏技术把这块开销压下去了。我写部署篇会展开。

顺带提一句 MoonViT-V2（架构篇讲过），它的视觉编码器是从零用 next-token prediction 训出来的，不需要对比预训练，优化过程比对比学习稳。这点和传统 CLIP 路线很不一样，值得单拎出来记。

一个诚实的 scaling law 研究：比较要公平

报告里有段关于学习率调度（cosine decay vs WSD）的讨论，看似琐碎，但我认为是整篇最有「工程师脾性」的地方。

WSD（Warmup-Stable-Decay）之前被一些工作说成能打平甚至超过 cosine decay。K3 团队发现，这两种调度在各自的最优超参下表现完全不同：即便模型大小和训练 token 数一样，它们的峰值学习率、batch size 最优值差很远。所以「用同一组超参去比两种调度」本身就是不公平的，结果谁好谁坏全看那组超参更偏向谁。

他们的做法是：对每种调度都独立做一次 scaling law 搜索，找到各自的最优超参，再比。在各自的甜点上，cosine decay 的最终 loss 稳定更低，于是 K3 默认用 cosine decay。

这个思路可以照搬到你自己的调参里：比较两个方案，先保证各自都调到最好，再比。拿「都还凑合的超参」去比，结论基本是噪声。我见过太多「我们试了 A 和 B，A 更好」的汇报，点到为止一问，B 用的是 A 调剩下的超参。

长上下文怎么训出来：四阶段课程，外加「合成长文档」

K3 支持一百万 token 上下文。报告里讲了两层设计。

第一层是 NoPE（上一篇讲过）：因为位置信息靠递归门控隐式表达，所以扩展上下文时不用改任何位置编码参数，外推几乎免费。这是架构给训练铺好的路。

第二层是渐进式课程。上下文窗口不是一上来就 1M，而是跟着训练进度分阶段拉长：预训练阶段从 8k 涨到 64k，cooldown（退火）阶段再从 256k 拉到 1M。把最贵的长序列计算集中在训练预算的一小段里，既便宜又让模型逐步适应更长的依赖。

但光把窗口拉大没用，报告很诚实地指出：自然界里真正长且连贯的文档、视频太少了，而且长素材里充斥着近似重复、二进制块、截断文件、机器生成的废日志。所以他们对长素材做了专门的清洗（精确 + 模糊去重、视频帧感知哈希、质量过滤），还刻意上采样长文档，免得被短文本淹没。

更关键的一步是「合成长上下文数据」：他们小心地重新排列、拼接多模态文档和子任务，使得嵌在里面的任务，必须跨越整整一百万 token 去注意分散在各处的信息才能解。否则模型会偷懒退化成只看局部。这一点特别像我们做检索系统时的教训：光给长文本不够，得构造「不全局看就答不对」的任务，模型才会真的用上长上下文。

后训练三段式：SFT → RL → 多教师蒸馏

K3 的后训练是一条清晰的三段流水线：

监督微调（SFT）：用高质量轨迹给模型一个冷启动策略；
强化学习（RL）：在三个大域上把推理和执行的上限拉高；
多教师在线策略蒸馏（MOPD）：把上一步训出的一堆「领域专家」合并回一个统一模型。

图：SFT 做冷启动，RL 在 3 域 × 3 力度上拉出 9 个专家，MOPD 把 9 个专家蒸馏回一个统一模型。

SFT：把复杂 agent 轨迹序列化

SFT 阶段他们扩展了数据集，重点覆盖复杂的 agentic 任务。做法是：用上一代 Kimi 的领域专用模型合成轨迹，再做多轮验证 + 人工标注。所有轨迹用一套叫 XTML 的 chat 模板序列化（eXtensible Token Markup Language，可以理解为给 token 加结构标记的对话格式，类似给对话流打上工具调用、观察、思考的分层标签）。

还有个对部署很关键的决定：从 SFT 阶段起就做量化感知训练（QAT），权重用 MXFP4、激活用 MXFP8。也就是说，模型从微调第一天就知道「我最后要被压成 4-bit 跑」，提前适应精度损失。这种「训练就为部署量身定做」的思路，我写部署篇会详聊——它直接决定了 K3 能不能把 2.8 万亿压成 4-bit 还不崩。

RL：三域 × 三推理力度 = 九个专家

RL 阶段他们没有给每个具体任务训一个专用模型，而是铺了三个大域：通用任务（含视觉、推理、搜索、知识工作）、通用 agent（长程助理、深度研究、写作）、编码 agent（软件工程、内核、Web 开发）。每个域又按「推理力度」分 low / high / max 三档，于是交叉出 9 个专家模型。
在这里插入图片描述

图：三个大域 × 低/高/max 三档推理力度，交叉出 9 个专家。推理力度预算 λ 退火控制成本。

这里有两个工程细节我很欣赏。

一是 partial rollout（部分回滚）。长程 agent 任务的轨迹可能拖得很长，如果等非得等所有 rollout 跑完才更新，会有大量「慢轨迹」拖垮整批。他们的做法是：每轮迭代只等一定比例（比如 NK 个）的轨迹完成就先开始优化，没跑完的排队，下轮优先续跑。代价是数据会变「陈旧」（off-policy），但他们用 per-token 的正则化把这种极端 off-policy 稳住了。这对我们做异步系统的也是现成经验：别等最慢的，先推进，再用正则兜住一致性。

二是推理力度预算控制（reasoning effort budget）。他们对每个问题估一个初始 token 预算 b0，超过 λ·b0 的轨迹直接判 -1 分。先训一个预算宽松的 max 变体，再逐步把 λ 退火到小值，得到 high 和 low 专家。本质是用奖励信号防止模型「想太多」，在能力和 token 效率间取平衡。我们线上服务也常遇到这问题：模型能答，但啰嗦到成本爆炸，得用预算把嘴缝上。

奖励模型怎么防作弊：Agentic GRM 四步协议

奖励模型本身也防作弊，这里值得多写几句。非可验证的任务用 Agentic GRM（生成式奖励模型），它强制走一个四步协议：

读产物（read the artifact）：先真正看模型交出来的东西；
生成评分标准（generate rubric）：针对这个具体任务，临时写出打分维度；
按 rubric 打分（score by rubric）：逐条对照给分；
写进 scorepad（write to scorepad）：把评分过程和结论记下来，可追溯。

并且对输出长度设上限，超了就判输，专门对付「越长越啰嗦越能骗分」的 reward hacking。这套设计很像一个严谨的阅卷老师：先看卷子，再自己列评分标准，然后按标准打分，最后留痕。比那种「给个分数完事」的奖励模型难钻空子。

MOPD：把九个专家蒸馏回一个

9 个专家很好，但线上不能部署 9 个模型。MOPD（Multi-Teacher On-Policy Distillation）把不同域、不同推理力度的能力合并回一个模型：对某个 (域, 力度) 组合，用对应的教师模型给学生的每 token 输出打一个 OPD 奖励（带 clip 截断，避免极端优势信号把 RL 搞崩），这个稠密奖励直接融进 RL 框架。报告说他们试过更细的 top-k 蒸馏目标，没看到明显好处，就用了这个更简单的。

这点也值得记：很多时候「更复杂的蒸馏目标」并不比「朴素目标 + 好基础设施」强，别过度设计。我自己也常犯这毛病，想着「既然能更细，那肯定更好」，结果在简单方案上多花一周，benchmark 没动。

白盒 RL 环境：别让模型只认一种 harness

这是我最想单独拿出来说的设计。

如果 RL 只在一个固定的 agent harness（比如某套固定的工具 schema、system prompt、上下文管理）里训，模型会过拟合那一套约定，换个别的框架就懵。K3 的做法是搞一个「统一白盒 RL 环境」：把 harness 表示成一堆可配置、可组合的模块（工具接口、system prompt、上下文管理、skills、记忆、子 agent 等），通过配置就能实例化出 Kimi Code、Claude Code、Codex、OpenClaw、Hermes 等主流 harness，甚至完全新的。
在这里插入图片描述

图：把 harness 拆成可配置模块，按需组合成不同 agent 框架。模型见够多样性，就不会只认一种约定。

训练时对不同任务组动态拼出不同 harness 配置，让模型见到这些模块的各式组合，而不是某一个 harness 的套路。顺带提一句，报告里点名的 OpenClaw 正好是我自己也在跟的一个项目，看到它能直接当 RL 环境的「标准模块」被实例化，还挺惊喜的，说明这类开源 harness 的生态位正在被认真当回事。

这种「把环境做成可组合模块」的思路，和我们搭测试基建时「用 fixture 抽象掉具体依赖」是一个道理：模型见的多样性够了，泛化才稳。

需要诚实地说一句：K3 这次同步开源了 MoonEP、FlashKDA、AgentEnv 这三项 Infra，但报告里描述的训练数据、任务合成流水线和 RL recipe 本身并没有一并开源。也就是说，我们能复现的是它「怎么跑」，不是它「喂了什么」。

知识图谱引导的任务合成：让训练任务自己长出来

训练任务从哪来？K3 建了一个自演化、分层组织的知识图谱。做法很像一个有意思的 agent 系统：

图谱是有向无环图（DAG），边永远从粗概念指向细概念；
给每个节点派一个 agent，让它做多次网络搜索去探究这个概念；
加新节点前，先让 agent 去现有图里找等价或相关的，能复用就复用，减少重复；
一个分支探索到「这个概念已经够原子了」就停。

图：粗概念 → 细概念 → 原子概念，边永远从粗到细；每个节点由 agent 探究，新节点先查重再复用。

然后按想要的域/任务类型分布，采样不同粒度的节点（单个或成组相关节点），用节点关键词 + 祖先节点的上下文去构造网络查询，抓真实公开材料（论文、博客、代码仓库），再由一个合成 agent 产出训练任务（编码类、知识类、视觉类等）。

我喜欢这个设计是因为它把「训练数据从哪来」从一个静态语料库，变成了一个会自己生长的系统。模型越强，图谱越厚，能造的任务越刁钻，形成正反馈。这比「人工写几千条题」更像是在养一片森林，而不是摆一盆花。

可验证环境：从 kernel 优化到「假装上班」

光有任务还不够，奖励得可验证，否则 RL 学歪。报告列了几类我很服的环境：

内核优化任务：从单算子到融合 mega-kernel，覆盖 CUDA、Triton、CuTe DSL、ThunderKittens、TileLang，数值格式含 BF16/FP8/FP4。奖励同时看正确性和性能：有 PyTorch 参考实现，数值误差超阈直接 0 分；性能对照专家实现，摸到硬件 roofline 奖励趋近 1。还专门搞了「hacking 检测」，惩罚 CUDA graph 重放、输入缓存、降精度这类钻空子的招，而且新花招一出现就加进检测。
个人助理任务：用 Gmail、Notion、Slack、Canvas 的真·mock 实现（保留核心语义但不依赖外部 API），让 agent 在「跨好几天、事件互相依赖」的持久环境里干活，单次 rollout 能到上千次工具调用、几百万上下文 token。
自主执行任务（AET）：每个任务给定初始状态、受限目标、工具空间、预算，和一个独立验证器。agent 只看到目标和约束，看不到参考轨迹，必须自己分解、选工具、规划、从错误里恢复、自己决定何时停。奖励基于验证器对「最终环境状态」的评估，而不是 agent 自报「我完成了」。还用「公开验证器给诊断反馈 + 隐藏验证器测留出场景」来防作弊。
Web 开发任务：从一句话到多段规格都有，产物涵盖网站、游戏、3D/WebGL、数据可视化、SVG、全栈应用，全在容器沙箱里跑，用确定性检查 + 模型评判双重打分，构建失败或「假装实现」直接 0 分。

这些环境的共同点是：奖励扎根在「可观测的最终状态」上，而不是「过程看起来对」。这恰好是 RL 里最该守住的底线。我见过太多 agent 评测，agent 把「我已经完成了」写进回复就拿到高分，结果产物根本跑不起来。K3 这套把验证器当成一等公民，是对的。

沙箱基础设施：AgentENV

长程 agent 训练要跑海量沙箱。K3 用了一个叫 AgentENV 的 microVM 沙箱（基于 Firecracker，这次是与 KVCache.ai 合作开发的），三个设计目标很实在：

高保真隔离：容器跑 agent 时出过 kernel panic 和死锁，microVM 隔离级别高得多，又允许 agent 大胆探索（挂盘、跑容器、甚至起虚拟机）；
灵活的沙箱生命周期：支持增量检查点/恢复（checkpoint 和 resume 延迟低到 133ms / 49ms）、暂停（暂停的沙箱不占内存 CPU，而 agent 等模型推理能占掉 98% 的生命周期，这下省大了）、fork（从原状态克隆一个新沙箱做无副作用的奖励评判）、snapshot（定期快照做错误恢复）；
高密度：用 OverlayBD 镜像 + 自定义 ublk 驱动 + 写时复制内存，实测内存超配比能到 6.5 倍。

整轮训练评测里，他们一共创建了 5121 万个沙箱、跨 150 万多个镜像。

我特别服 checkpoint/resume 那组数字：133ms 存、49ms 恢复。这意味着一个跑了几百万 token 的长程任务，可以在任意点冻住、挪到别处、再续上，几乎不花时间。没有这个能力，长程 agent RL 根本玩不转——你想想，一个任务跑三天，中途机器要维护，没法续就全废了。