Kimi K3、DeepSeek V4 与 GLM：训练报告里的算力、数据和环境

这篇整理 Kimi K3（arXiv 2607.24653，47 页）、DeepSeek V4（arXiv 2606.19348，58 页）和 GLM 系列的训练材料。GLM-5.2 没有在本文材料中对应一份独立报告，相关说明来自 GLM-5 报告与官方 research 页。V4 后半部分曾提取失败，因此下文不能视作三份报告逐页完整核验的结果；存疑字段保留标记。

K3 的算力表有一个值得展开的比例：按表中 FLOPs 计算，后训练约占总量的 75.6%，相应阶段 MFU 为 27%。后文先拆这份账本，再对照数据来源、累计消融和环境规模。

先列出后文会用到的三个 K3 数字；它们采用的统计口径分别是计算量、利用率和数据构成：

• K3 后训练 token 量（14.6T）≈ 预训练 token 量（15.6T），但后训练算力占比高达 75.6%
• V4 在 1M 上下文下只需稠密 MLA 约 1/10 的计算量
• K3 后训练数据 93.13% 是合成数据

0 · 三个模型，一张总表

表中几款模型都有 MoE 和长上下文配置，但注意力实现、激活参数、训练流程及许可证条款并不相同。共同的配置标签不足以证明架构不再影响效果或成本。

1 · 架构细节与消融

1.1 K3：KDA + GMLA 混合注意力，MoE 做了四件事

K3 的注意力是 KDA（Kimi Delta Attention）+ GMLA 的混合：69 层 KDA + 24 层 GMLA = 93 层。Model Card 里写的 n_layers 3,168 与这个 93 明显矛盾——这是我无法自洽解释的一处，存疑，我倾向 93 是正确值、3,168 是笔误或别的口径，但报告没给说明。

其余 Model Card 关键字段（事实）：

• n_vocab 164,096（BBPE、NFC 归一化）
• head_dim 128，n_heads 64，n_kv_heads 8
• QK norm = true，RoPE = none（不用旋转位置编码）
• 激活函数 SiTU，归一化 RMSNorm
• Stable LatentMoE：384 个专家选 8 个，每块（block）24 个专家
• MLA latent 4,096，head input 256 / output 512

下表保留本文摘录的消融结果。比较时要看对应实验规模和任务，不直接外推到全部部署负载：

在这组消融中，量化精度对不同层和任务的影响不一样。因此部署时还需要用目标负载检查质量损失与吞吐，表里的 PPL 不能替代全部任务评估。

1.2 V4：DSA 稀疏注意力，为 1M 上下文而生

V4 的核心是 DSA（DeepSeek Sparse Attention），由两部分组成（事实）：

• DLA（DeepSeek Linear Attention）：lightning attention + gated delta net 混合，top-k 稀疏比约 1%
• VLA（Vectorized Latent Attention）：用 lightning indexer 做细粒度稀疏，分 intra-block 和 inter-block 两种 kernel

报告中列出的比较是：在 1M 上下文条件下，DSA 计算量约为稠密 MLA 的 1/10。这里的分母是对应注意力实现，不能把它直接当作整次训练或推理的总成本降幅。

架构超参（Table 16，只列我有把握的行——Pro 的部分字段提取顺序存疑，宁缺毋滥）：

材料还列出了 Muon 和 QK-norm。这些相同的选择可以继续按训练条件和消融结果对照。

1.3 GLM：先区分报告与产品版本

本文使用 GLM-5 报告、GLM-5.2 的产品说明和权重配置，它们不是同一份材料。表中的 744B/40B、上下文与许可证字段仍需对应到具体版本，不能据此补出一份 GLM-5.2 的完整训练账本。

1.4 各自需要核对的架构问题

2 · K3 的训练算力账本

K3 的 Table 5 把不同阶段的计算量和利用率列在一起。下面沿用本文摘录，重点看同一份账本内部怎样分配成本：

按上表口径计算，可以得到以下差异。比例是表内推算，造成差异的原因需要另有证据：

• K3 表内后训练占总 FLOPs 约 75.6%。1,190,757,067 / 1,575,421,683 ≈ 75.6%；按 PFU-days 计算也约为 75%。这个比例限于该报告的阶段划分。
• 后训练与预训练的 token 量接近（14.6T 与 15.6T），每 token 对应计算量不同。按表内口径推算，分别约为 2.2e11 和 6.7e10 FLOPs/token。RL 中的采样与多次前向可能参与这一差异，但表格没有单独拆出各项贡献。
• K3 后训练 MFU 为 27%，预训练为 54%。两者相差一半。要判断环境等待、rollout 和调度分别造成多少损失，还需要阶段内的性能剖析。

本文没有取得 V4、GLM 同口径的完整算力账本，V4 后半部分还存在提取缺口。因此这里先解释 K3 自身各阶段的比例，不做三家总训练成本排名。

3 · 训练数据

3.1 规模对比

更正：K3 Table 1 和 Table 4 已列出语料构成与 token 账本，早先“未披露数据量”的表述不准确。本文据此补入表格。

3.2 K3 语料构成（Table 1 + Table 25 + Appendix I，事实）

这张表描述 K3 预训练数据的配比。它不能说明某个来源已经用尽，也不能替代后训练阶段的数据账本；下面另看合成数据占比。

3.3 后训练数据：93% 是合成的

K3 Table 4 列出的后训练合成数据占比为 93.13%，对应 13.66T：

• 预训练靠爬来的互联网语料（Web 70%）
• 后训练几乎全靠模型自己生成 / 蒸馏出来的数据

这个比例说明合成数据在该训练流程中的份额很高。生成、筛选和验证各自需要多少算力，还需要单独的成本数据，不能由 token 占比反推。

3.4 长上下文：候选池、实际用量与课程

K3 材料中的扩展候选池为 31.5T，实际用于扩展的量为 108B；本文摘录的 Table 16 比较了 80K→240K→480K 等课程安排。要解释长上下文效果，需要同时看采样和课程消融，不能只比较最终标注的窗口长度。

4 · 端到端管线走查：数据 → 预训练 → mid-train → post-train → checkpoint

下面按数据、训练阶段和产物整理已有材料。没有取得同等细节的位置保留空缺，不替报告补齐。

4.1 K3：报告列出的阶段与 token 用量

数据:   23T 预训练语料（Web 70% / Code&STEM 15% / 合成 8%）
预训练: 15.6T tokens，MFU 54%
上下文: 从 31.5T 候选池选 108B，课程 80K→240K→480K，MFU 62%
mid:    489B tokens
post:   SFT 259B → MOPD 11.3T → Agentic 2.47T
        → 交错推理&agent 2.4T → 并行 RL 670B（MFU 仅 27%）
量化:   QAT，按层敏感度区别对待（早期层优先保）
checkpoint: Base / Instruct / Thinking

token 账本（Table 4，事实）逐项：预训练 15.6T / 上下文扩展 108B / mid 489B / SFT 259B / MOPD 11.3T / Agentic 2.47T / 交错 2.4T / 并行 RL 670B。

一处存疑：这些分项加起来约 33.3T，而报告口径的总消耗是 30.4T，两者对不齐。可能是部分阶段 token 重复计数口径不同。我无法确认原因，如实标注。

4.2 V4：主模型与 draft 模型分别计成本

架构:   DSA（DLA+VLA）稀疏注意力，1M 计算量约稠密 MLA 的 1/10
优化:   Muon + QK-norm
post:   SFT 30 万样本 → rubric RL（详见第 5 节）
蒸馏:   R1 / V3.2 作为 teacher 做跨代知识蒸馏，抬高 SFT/RL 起点
部署:   DSA 与 MTP 不兼容 → 额外训一个稠密 draft 模型
        （6 层 Flash 式稠密 MLA + 稠密 FFN，V4 权重初始化 + 100B token 继续训练）
checkpoint: Pro / Flash 两个尺寸

V4 材料中使用单独的稠密 draft 模型支持投机解码。评估总成本时，除了主模型的注意力计算，还要计入 draft 的训练、内存和调度，并在相同负载下比较。

4.3 GLM：本文材料中的版本缺口

这里没有与 K3 同口径的完整 token 账本。GLM-5 报告、GLM-5.2 research 页和具体 checkpoint 的字段也不能直接合并成一条已核验的训练流程。需要核对某项改动时，应回到对应版本的原始说明。

5 · RL 与后训练深挖

这一节查看后训练阶段、累计消融和环境规模。它们能说明报告测到了哪些变化，不能据此给三家团队排出整体高下。

5.1 K3：后训练是一条多阶段流水线

K3 的后训练 token 分配（事实，Table 4）：

• SFT：259B
• MOPD（混合 on-policy 蒸馏）：11.3T —— 最大头
• Agentic：2.47T
• 交错推理 & agent：2.4T
• 并行 RL：670B

后训练消融（Table 21，事实）逐阶段叠加的效果：

表中加入 Agent 阶段后，相关分数从 7.6 变为 41.6。由于各行是逐阶段累计的结果，不能把它当作完全隔离其他因素的单项因果实验，也不能仅凭末行推断 Thinking 与 Instruct 的全部训练差别。

5.2 K3：环境规模化（Table 22，事实）

并行环境从 256 扩到 65,536：

在列出的实验范围内，扩展环境数量对 BrowseComp、Terminal-Bench 等项目的影响不同。要判断收益来自并行数、更多 rollout 还是总训练量，还需要实验中其他条件的控制信息。

5.3 V4：rubric-based RL 与环境规模实验

V4 第 4 章把后训练拆得很清楚（事实）：

• SFT：30 万样本
• rubric-based RL：26 万条 rubrics + 35 万个可验证任务
• 四阶段课程：推理 → 非推理/写作 → agent → 跨域联合
• 沙箱：CodeSandbox + 终端沙箱（容器池 + 快照）
• 奖励：规则奖励 + rubric 奖励模型，两者结合
• 动态采样：过滤全对 / 全错的 rollout，只留有信息量的样本
• 跨代蒸馏：R1 / V3.2 当 teacher，抬高 SFT / RL 起点

Figure 10 比较了从 1K 到 100K 的并行环境，展示范围内的分数随规模增长。材料还列出 6 万 SWE rollout、10 万并行环境和 3,600+ SWE rubrics，它们分别描述样本量、环境规模与评分要求。

这组结果值得继续追踪，但曲线在已测区间没有饱和，不代表扩到任意规模都继续有效。环境扩展、数据生成与硬件利用率应一起计成本；K3 的 MFU 数据也不能直接用来解释 V4 的收益。

5.4 V4 自己承认的三个局限（第 6 章，事实）

• DSA intra-block 局部性偏弱
• rubric 生成的算力成本高
• 长程任务的 RL reward hacking

其中 reward hacking 与长程任务的验证方式有关。比较 agentic benchmark 时，需要看验证器覆盖了哪些要求、有没有检查利用评分规则取得高分的情况。

6 · Benchmark 交叉核对

以下分数按报告摘录，存疑字段继续作标记。由于测试协议与模型版本可能不同，表格用于寻找需要核对的任务差异，不合成为总榜。

跨报告比较还有两个限制：

• K3 的 SWE-bench Verified 要区分版本：Instruct 66.4，Thinking 71.3，别混用。
• V4 的 76.7 在提取文本里没有明确标签，是我按表格位置推断的，采信时请打折。V4 在 OpenAI DeepSearch 上 56.7 vs GPT-5.4 的 74.0，Tool-Decathlon 46.3 vs 78.1——长程工具任务是 V4 的明显短板。

7 · 这些材料能支持哪些判断

K3 的账本给出了后训练计算量、利用率与合成数据占比，V4 的材料进一步涉及环境规模与评分要求。它们可以帮助确定下一步该查哪些训练成本，但目前没有同口径数据可比较三家的总效率。

对部署与选型，仍要回到任务表现、许可证、资源需求和可复现材料。报告中的一个高比例或一条上升曲线，只回答其对应实验的问题。

附录 · 数据可信度声明

• 表格沿用三份技术报告的摘录（K3 arXiv 2607.24653、V4 arXiv 2606.19348、GLM arXiv 2602.15763），提取缺口和存疑字段列于下方。
• 明确存疑项：① K3 Model Card n_layers 3,168 与 93 层矛盾；② K3 token 分项合计与总口径对不齐；③ V4 的 SWE-bench Verified 76.7 为位置推断；④ V4 Table 16 Pro 列部分字段提取顺序存疑，本文只保留高置信行。
• 未能获取：V4 报告后半部分（约 34–58 页）PDF 提取失败，可能含部分算力 / 部署附录数据，本文相关结论以能提取的部分为准。
• benchmark 均为各家自报，未做独立复测。
• 文中 4 张插图为 AI 生成的示意图（gpt-image-2），仅用于概念可视化，不含真实数据。

参考：Kimi K3 Technical Report — arXiv 2607.24653 · DeepSeek V4 Technical Report — arXiv 2606.19348 · GLM-5 Technical Report — arXiv 2602.15763 · 各家 HuggingFace 权重仓库