第 4 章 · 小结与自测
全章鸟瞰
把这一章串成一条生产线，就是「原料 → 预算 → 产线 → 长跑」：
一段话说完本章：互联网原始文本经过几十道清洗工序，只有百分之几能入库（4.1）；模型在这些文本上做的唯一一件事仍是预测下一个词，知识与推理是这个目标逼出来的副产品（4.2）；参数开多大、数据喂多少，Scaling Laws 让这笔几亿元的账可以提前算（4.3）；训练态显存 = 参数 × 16 字节，一张卡装不下，就用 TP、PP、DP/ZeRO 组合拳切开分摊（4.4）；最后靠混合精度、梯度裁剪和 checkpoint 容灾，扛住数月长跑里平均几小时一次的故障（4.5）。 产出的 base 模型，就是下一章后训练的起 点。
要点回顾
| 小节 | 两行记住它 |
|---|---|
| 4.1 数据从哪来 | 互联网是垃圾场，清洗流水线决定模型上限；去重防「背题」，配比是秘方。 |
| 4.2 配比、打包与数据边界 | 配比：机密的是数字不是方法（消融/DoReMi/退火探针），且它是条曲线不是一个数；打包把利用率从 40% 提到 97%，代价是跨文档污染，靠文档级注意力隔断消除；知识截止是模糊下界；中文语料池小一个量级、来源结构也不同。 |
| 4.3 训练目标 | 还是「预测下一个词」：答案藏在文本自身；把预测做好，就被迫学会语法、事实和推理。 |
| 4.4 Scaling Laws | C ≈ 6ND，损失按幂律可预测下降；Chinchilla 最优约 20 token/参数，2024 后主流故意「过训练」换推理省钱。 |
| 4.5 并行训练 | 显存大头是优化器状态（12/16 字节）；DP 提速不省显存，TP 凶通信限机内，PP 有气泡，ZeRO 切三大件。 |
| 4.6 训练稳定性 | bf16 干活 + fp32 记账；梯度裁剪限速；loss spike 就回滚跳过；高频 checkpoint 是生命线。 |
综合自测
📝 动手自测0/6
1. 训练语料里如果混入大量重复文档，主要危害是什么？
2. 用粗账 C ≈ 6·N·D 算：70B 参数模型训 1.4T token，总计算量大约是多少 FLOPs？
3. 关于 Chinchilla 定律和 2024 年后的「过训练」潮流，哪个说法正确？
4. 模型一张卡放不下，同事建议「上数据并行（DP）就行」。这个建议错在哪？
5. bf16 + Adam 训练态的每参数约 16 字节显存中，占比最大的是？
6. 凌晨三点 loss 从 2.1 飙到 7.4（loss spike），值班工程师的标准操作是？
下一章
几个亿烧完，你得到的是一个 base 模型——读过整个互联网的「最强接话茬选手」。但问它「中国的首都是哪里？」，它可能回你十个类似的问题，而不是一个答案。
它会说话，但还不会说人话。让它听懂指令、好好回答、拒绝危险请求，是另一条完全不同的流水线：