필사 모드: 从公开的训练案例中学习 —— 试过什么,又是什么失败了

• 引言 —— 该从报告里读出的不是成绩单
• 挑选的案例与核实标准
• Llama 3 405B —— 在故障是常数的规模下做设计
• DeepSeek-V3 与 Kimi K2 —— 消灭尖峰的两个层次
• Olmo 系列 —— 稳定性修复留在架构里的痕迹
• OPT-175B 与 BLOOM —— 记录失败这种文化的原型
• SmolLM3 与 Marin —— 在较小规模上公开的实验笔记
• 横向对比阅读 —— 反复出现的,以及始终不会出现的
• 结语 —— 知道哪些无法复现,才是读报告的技术

引言 —— 该从报告里读出的不是成绩单

如果只看基准测试表就把技术报告合上,几乎学不到什么。分数搬不到你自己的场景里,但哪里出了问题、怎么修的却可以跨规模搬运。

本文就从公开报告与日志本里只抽取这一部分:损失尖峰及其应对、硬件故障率与检查点周期的关系、训练中途更换数据配比的效果,以及扩展决策背后的依据。每个案例结尾都单独记录了报告没有说的东西。判断可复现性时,那部分反而更重要。

挑选的案例与核实标准

全部链接均于 2026 年 8 月 2 日确认。引用的数字取自原文,或直接引用原文的报道;无法核实的地方已在正文中注明。

Llama 3 405B —— 在故障是常数的规模下做设计

这份报告里最值得引用的是它的中断统计。用 16,384 张 H100 80GB 跑了 54 天,期间发生了419 次意外中断,报告将其中 78% 归类为已确认或疑似的硬件问题。根据引用了报告原表的数据中心行业报道,详细分类如下。

54 天里 419 次,平均每 3.1 小时就有一次。在这个规模下,故障不是例外,而是常数。 所以设计也随之而变:靠人工介入重启的运维方式已经不成立,故障检测、节点替换、恢复都必须自动运转。

由此直接推出的一个实务计算就是检查点周期。平均故障间隔 3.1 小时、保存耗时 5 分钟,最优周期大约是 43 分钟——即便如此,总时间的 20% 以上依然会消耗在保存与重新计算上。完整的推导过程整理在《LLM Ops 实践》一文里。

并行策略用的是张量、上下文、流水线、数据四个维度的组合,BF16 下的模型 FLOPs 利用率报告在 38%–43% 区间。这个数字值得记住:即便是调优得当的大规模训练,也用不到理论性能的一半。 自家集群跑出 30% 出头,并不代表一定哪里出了问题。

报告没有说的:训练数据的精确构成比例和过滤分类器的阈值、失败后被丢弃的前期实验,以及负责故障检测和自动恢复的内部运维软件的具体实现。统计数字公开了,但产生这些统计的工具没有公开。

DeepSeek-V3 与 Kimi K2 —— 消灭尖峰的两个层次

把两份报告放在一起读,能看出应对损失尖峰的两种不同策略。

DeepSeek-V3 训练了一个 671B 参数、每个 token 激活 37B 的 MoE 模型,用了 14.8T token,报告称整个训练消耗了 2.788M H800 GPU 小时——其中包含上下文扩展的 119K 小时和后训练的 5K 小时。报告里还有这样一句话:整个训练过程中从未遇到过无法恢复的损失尖峰,也没有执行过回滚。

这份稳定性从何而来,报告本身没有直接下结论。但与之并列描述的内容给出了线索。他们引入了 FP8 混合精度训练,同时把对精度敏感的运算保留在高精度;用 DualPipe 让计算与通信重叠,以减少流水线气泡;并且在没有辅助损失的情况下处理 MoE 的负载均衡。最后这一点尤其关键——用辅助损失去均衡专家使用率时,那个损失项会与主目标函数相互竞争,从而制造不稳定,而他们直接去掉了这一项。

后续的回顾性论文 Insights into DeepSeek-V3 讨论了硬件层面的设计。文中给出的数字是:多头潜在注意力(MLA)把每 token 的 KV cache 压到了 70.272KB,同一张表里 Llama-3.1 405B 是 516.096KB。文中还提到集群网络使用了多平面胖树(fat-tree)拓扑。这是一个模型架构决策直接等同于基础设施决策的案例。

Kimi K2 在另一个层面解决同一个问题。训练了一个总参数 1.04T、激活 32B 的 MoE 模型,用了 15.5T token,报告称没有观测到损失尖峰,而实现手段是优化器。他们把 QK-Clip 与 Muon 优化器结合成 MuonClip,在每次更新后立即重新调整 attention 的 query 和 key 权重,以抑制 logit 爆炸。学习率日程属于 WSD 系列:500 步预热后,以恒定学习率跑 10T token,剩下的 5.5T 用余弦衰减。预训练的上下文长度是 4,096。

把两种做法的差异整理如下。

报告没有说的:两份报告都只描述了成功的最终配置。在引入 FP8 的过程中哪一层先出问题、MuonClip 的裁剪阈值是怎么找到的、在此之前失败过多少次训练——这些都没有出现。而且两边都没有公开数据构成。

Olmo 系列 —— 稳定性修复留在架构里的痕迹

Allen AI 的 Olmo 3 在发布 7B 与 32B 模型的同时,把检查点、数据集乃至依赖项的整条开发流水线都公开了。这种完全开放之所以重要,并不是因为基准分数,而是因为它是第三方能够直接审计数据污染与来源的唯一形式。

从技术角度值得关注的是,稳定性修复最终落在了架构里,而不是超参数里。Olmo 3 保留了 OLMo 2 中被确认为稳定性改进的配置:使用 RMSNorm 但把归一化位置放在后面,在 attention 计算前对 query 和 key 再做一次归一化,并且对 embedding 不施加权重衰减。

这三项都是一旦开始预训练就无法更改的决定。所以这个案例给出的教训在实务上相当冷峻:应对不稳定的最佳时机,是在第一次尖峰出现之前。 已经跑完 3T token 之后,再想改归一化的位置,这个选项根本不存在。

报告没有说的:数据和检查点是公开的,但大多数机构没有重新跑一遍这个规模的算力。"完全开放"给出的是可审计性,不是可复现性。这个区分最好保持清楚。

OPT-175B 与 BLOOM —— 记录失败这种文化的原型

如果说今天的技术报告是打磨过的终稿,那 2022 年的这两个案例就是未经加工的原始记录。

OPT-175B 的 chronicles 目录里存放着完整的日志本 PDF,以及进度 10%、27%、56% 和最终阶段的更新笔记。仓库的说明把它称为"我们用于训练 OPT-175B 的完整日志本,以及记录过程中所遇困难的笔记"。日志本里带着日期记录了反复的重启、损失发散、训练过程中的超参数调整,以及硬件更换。

从这里该学到的不是某项具体技术,而是记录本身就是一项产出物这种态度。训练过程中做出某个决定的原因,如果当时没有被记下来,两个月后就没人能重新拼出来。

BLOOM 在法国的 Jean Zay 超级计算机上训练,用了 48 个节点、每节点 8 张 A100 80GB,共 384 张卡,历时约 3.5 个月,消耗了 1,082,990 个计算小时。在资源规划上值得注意的一点是:他们专门留出了 4 个备用节点,原因就是硬件可能会出故障。 节点间连接是每节点 4 条 100Gbps 的 Omni-Path 链路;因为是共享超算,文件系统也和其他用户共用。

在 384 张卡的规模上留出约 8% 作为备用节点,这个决定可以原样搬到实务中用。资源申请书里如果不留备用节点,一旦有一个节点挂掉,整个训练就会被打回排队队列的末尾。

报告没有说的:这两个案例都建立在当时的软件栈之上(旧版 Megatron-DeepSpeed、旧版 PyTorch),代码已经无法直接运行。而且日志本中的判断都受限于当时的硬件与框架约束,应该拿走的是思考过程,而不是结论本身。

SmolLM3 与 Marin —— 在较小规模上公开的实验笔记

前面这些案例都是大多数机构模仿不来的规模。所以再补充两个更实用的案例。

SmolLM3 在用 11.2T token 训练一个 3B 模型的同时,公开了数据配比是如何决定的。他们采用三阶段预训练,逐阶段改变 web、代码、数学数据的比例,而这些比例是用 3B 模型在 50B 到 100B token 规模上做小规模实验决定的。第一阶段的构成甚至给出了具体数字:web 占 85%(其中多语言占 12%)、代码占 12%,以此类推。

这套方法论才是关键。 一个涉及 11.2T token 的决策,是用一个 100B token 的实验做出的。先定几个候选配比,在小规模上跑一遍做比较,再应用到正式训练——这套流程无论在 3B 还是 30B 上都同样适用。一并公开的 Smol Training Playbook 还讨论了不会写进论文里的内容,比如在 384 张卡的任务上调试损失尖峰的过程。384 张卡是很多机构实际能碰到的规模。

Marin 是从斯坦福发起的一个公开实验室,所有研究尝试都先以 GitHub issue 的形式登记,这个 issue 起到一种预注册的作用。在把一个 8B 模型训练到 12T token 以上的过程中,他们持续打磨数据配比,并把后期冷却阶段——一边降低学习率一边把数据转向更高质量——的做法写进了一份回顾文档里。

预注册这种做法特别值得借鉴。看到实验结果之后再写假设,几乎所有结果看起来都会像是成功的。 光是在开跑之前把预期写下来,就能大幅削减这种偏差。

报告没有说的:SmolLM3 的小规模代理实验对正式规模的预测效果有多好,并没有得到定量验证。小规模实验无法迁移到大规模的情况确实存在,所以这套方法论更适合被当作"比毫无依据的猜测更好的流程",而不是"完美的预测"。

横向对比阅读 —— 反复出现的,以及始终不会出现的

把七个案例叠在一起看,能看到五个反复出现的模式。

1. 应对损失尖峰有四个层次,越靠下越便宜,越靠上越迟。 干预成本按目标函数设计、架构、优化器、运维的顺序递增。可大多数团队只在成本最高的运维层去应对。
2. 故障率与 GPU 数量成正比,决定了检查点周期和自动化水平。 384 张卡时备用节点就够了,16,384 张卡时自动检测和替换是必需品。规模变成十倍,运维方式也必须随之改变。
3. 数据配比从头到尾都不是固定不变的。 多个案例都描述了分阶段配比,以及后期冷却区间向高质量数据的转换。"定好数据集再开始训练"这种模型,和现实不符。
4. 扩展决策来自小规模代理实验。 决策越大,支撑它的实验反而越小。这正是实验设计能力比 GPU 数量更重要的地方。
5. 模型架构决策就是基础设施决策。 一种能缩小 KV cache 的 attention 设计会改变服务成本,MoE 的选择会改变对网络拓扑的要求。

反过来,也整理一下几乎所有报告里始终不会出现的内容。知道这份清单,才不会对报告过度信任。

• 失败训练的次数与成本。 最终那次训练的 GPU 小时会公布,但为了走到那一步烧掉的资源几乎从不公开。如果直接拿公布的 GPU 小时数当预算依据,会严重低估。
• 数据的精确构成与过滤阈值。 比例会给出来,但原始来源、去重参数、质量分类器的截断线通常都被省略。
• 超参数搜索过程。 只给出最终值,不说是怎么找到的。
• 运维人力与工具。 多少人、倒了几班、用了什么内部工具来检测故障——都缺失。这在实际中反而是最大的准入门槛。
• 评估集污染检查的细节。 通常只有一句"已经检查过",很少写清楚方法、阈值,以及发现的重叠规模。

结语 —— 知道哪些无法复现,才是读报告的技术

一份公开报告不是成功的设计图,而是一个团队在特定约束下所做决策的记录。在 16,384 张卡上有效的自动恢复设计,放到 8 张卡的节点上就是过度设计;在 384 张卡上行得通的人工应对方式,放到 16,384 张卡上根本不成立。

所以正确的阅读方式可以这样概括:数字是绑定在那个团队的规模上的,不要照搬;要拿走的是决策背后的依据。为什么在这个时间点定下检查点周期,为什么选择在这个层次阻止不稳定,为什么这个实验导向了那个决策。同时,永远随身带着报告里没有写的那份清单。只有知道缺了什么的人,才能拿这份报告去做真正的规划。

并行化的基础知识整理在《多 GPU 训练的四种并行方式》里,而执行这些决策所需的工具则整理在《LLM 训练技术栈地图》和《Slurm 实务指南》里。