LLM 预训练全景：数据管道、Scaling Laws 与训练稳定性
📅 创建时间：2026-07-29 🏷️ 标签：#PreTraining #ScalingLaws #DataPipeline #TrainingStability #MixedPrecision #Checkpoint 📚 前置知识：[[11-training-primer]]（知道训练循环的四步曲）[[08-transformer-by-hand]]（知道 Transformer 前向传播怎么算）
📋 本章目标
- 理解预训练在整个 LLM 生命周期中的位置——它是工厂，不是装修
- 掌握训练数据的完整 Pipeline：从原始网页到可以喂给模型的 token 序列
- 理解 Scaling Laws 的核心结论：多大的模型配多少数据才划算
- 能够手算一个给定参数量的模型的 Chinchilla 最优数据量和训练 FLOPs
- 理解为什么大模型训练容易崩：Loss Spike、混合精度、学习率预热
- 理解 Checkpoint 机制和训练恢复流程
- 建立预训练成本的直观认知：从 GPT-3 的 $4.6M 到 GPT-4 的 $100M+
- 看完这篇，你能理解为什么全球只有少数几家公司能从零训练大模型
第0部分：Pre-Training 在整个 LLM 生命周期中的位置
0.1 两阶段范式
现代 LLM 的创建分为两个大阶段：
┌─────────────────────────────────────────────────────────────┐
│ LLM 完整生命周期——两阶段范式 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ 数据收集 │───→│ 数据清洗 │───→│ Tokenization │ │
│ │ (Raw Data) │ │ (Clean Data) │ │ (Token IDs) │ │
│ └──────────────┘ └──────────────┘ └──────┬───────┘ │
│ │ │
│ ╔══════════════════════════════════════════════╪══════╗ │
│ ║ 阶段一：Pre-Training（工厂） │ ║ │
│ ║ ↓ ║ │
│ ║ ┌─────────────────────────────────────────────┐ ║ │
│ ║ │ Pre-Training（预训练） │ ║ │
│ ║ │ • 目标：学习语言的统计规律 │ ║ │
│ ║ │ • 任务：Next Token Prediction │ ║ │
│ ║ │ • 数据：数万亿 token 的原始文本 │ ║ │
│ ║ │ • 时长：数周到数月 │ ║ │
│ ║ │ • 成本：数百万到数亿美元 │ ║ │
│ ║ └────────────────────┬────────────────────────┘ ║ │
│ ║ │ ║ │
│ ║ ↓ ║ │
│ ║ ┌──────────────┐ ║ │
│ ║ │ Base Model │ ← 预训练的产物 ║ │
│ ║ │ (原始能力) │ 还没法直接对话 ║ │
│ ║ └──────┬───────┘ ║ │
│ ╚══════════════════════╪═════════════════════════════╝ │
│ │ │
│ ╔══════════════════════╪═════════════════════════════╗ │
│ ║ 阶段二：Post-Training（装修） ║ │
│ ║ ↓ ║ │
│ ║ ┌─────────────────────────────────────────────┐ ║ │
│ ║ │ SFT（监督微调）→ Reward Modeling │ ║ │
│ ║ │ → RLHF/DPO（人类偏好对齐） │ ║ │
│ ║ └────────────────────┬────────────────────────┘ ║ │
│ ║ │ ║ │
│ ║ ↓ ║ │
│ ║ ┌──────────────┐ ║ │
│ ║ │ Chat Model │ ← 可以对话了 ║ │
│ ║ │ (对齐后) │ ║ │
│ ║ └──────────────┘ ║ │
│ ╚═════════════════════════════════════════════════════╝ │
│ │
│ 关键认知： │
│ • Base Model 不是 Chat Model——它只会续写，不会对话 │
│ • Pre-Training 决定了模型的能力上限 │
│ • Post-Training 只是把能力"激发"出来，不能创造新能力 │
│ • 一个差的 Base Model，无论怎么对齐都没用 │
│ │
└─────────────────────────────────────────────────────────────┘0.2 Base Model vs Chat Model——一个直观的例子
假如你给 Base Model（GPT-3 预训练后、没做任何对齐）输入：
问：什么是光合作用？
答：Base Model 可能会续写：
问：什么是光合作用？
答：这是一个常见的生物学问题。光合作用是指植物利用光能...
问：什么是呼吸作用？
答：呼吸作用是细胞...它不会停！因为它在训练时学的就是"不停续写"。它不知道"答完问题就该停"——这是 Post-Training 教给它的。
Pre-Training 教模型"语言"，Post-Training 教模型"对话"。
第1部分：训练数据——模型"吃"什么
1.1 数据来源全景
┌─────────────────────────────────────────────────────────────┐
│ 预训练数据的主要来源 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 数据源 │ 规模估计 │ 质量 │ 用途 │
│ ───────────────────┼────────────────┼───────┼────────── │
│ Common Crawl │ 数 PB / 万亿词 │ 低-中 │ 广泛知识 │
│ Wikipedia │ ~6M 英文文章 │ 高 │ 事实知识 │
│ Books (Books3等) │ ~200K 本书 │ 高 │ 长文本理解 │
│ Code (The Stack) │ ~6TB 代码 │ 中-高 │ 推理/代码 │
│ Academic Papers │ 数百万篇 │ 高 │ 科学知识 │
│ Reddit / 社交媒体 │ 数十亿条 │ 低-中 │ 对话风格 │
│ GitHub Issues/PRs │ 数百万条 │ 中 │ 技术讨论 │
│ ArXiv / PubMed │ 数百万篇 │ 很高 │ 学术推理 │
│ News Articles │ 数千万篇 │ 高 │ 事实/时效 │
│ │
│ 核心原则：多样性 > 单一来源的绝对质量 │
│ → 模型需要见识足够多的写作风格、领域和格式 │
│ │
└─────────────────────────────────────────────────────────────┘1.2 数据 Pipeline——从原始网页到训练样本
这是预训练中最容易被低估的部分。处理数 TB 的原始网页数据，需要一整套工业级 Pipeline：
┌─────────────────────────────────────────────────────────────┐
│ 数据 Pipeline：从 URL 到 Token 序列 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 阶段1：数据收集 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Crawl 数百亿网页 → 提取正文（去除 HTML/CSS/JS） │ │
│ │ → 语言检测（只保留目标语言的文本） │ │
│ │ → 输出：海量原始文本 (~数十TB) │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ 阶段2：去重（Deduplication） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • 文档级去重：MinHash / SimHash → 相似文档去重 │ │
│ │ • 段落级去重：删除重复出现的模板文字（如网站页脚） │ │
│ │ • 精确去重：相同 URL / 相同 hash 直接删除 │ │
│ │ │ │
│ │ 重要发现：Common Crawl 中有 ~50% 的重复内容！ │ │
│ │ 不去重 = 浪费 50% 的计算资源 + 过拟合风险 │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ 阶段3：过滤（Filtering） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • 长度过滤：删除 < 100 字符或 > 100K 字符的文档 │ │
│ │ • 困惑度过滤：用一个小模型打分，删除低质量文本 │ │
│ │ • 启发式规则：删除含大量特殊字符/乱码/非自然语言 │ │
│ │ • 毒性/色情/暴力过滤：用分类器筛除有害内容 │ │
│ │ • 个人信息过滤：删除邮箱、电话、身份证号等 PII │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ 阶段4：质量评分（Quality Scoring） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • 用分类器（如 fastText / KenLM 模型）打分 │ │
│ │ • 评估维度：语法正确性、信息密度、格式规范性 │ │
│ │ • 只保留高分文档（如 > 0.5 分） │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ 阶段5：数据配比（Data Mix） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 不是所有数据等量使用。需要按比例混合： │ │
│ │ │ │
│ │ 典型配比（LLaMA 风格）： │ │
│ │ • Common Crawl 过滤后：67% │ │
│ │ • 书籍：5% │ │
│ │ • Wikipedia：4.5% │ │
│ │ • GitHub/Code：15% │ │
│ │ • 学术论文：2.5% │ │
│ │ • Reddit/对话：5% │ │
│ │ │ │
│ │ 不同配比 → 不同能力侧重 │ │
│ │ 代码多 → 推理能力强 │ │
│ │ 书籍多 → 长文本理解强 │ │
│ │ 对话多 → 口语化能力好 │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ 阶段6：Tokenization → 最终训练数据 │
│ │
└─────────────────────────────────────────────────────────────┘1.3 数据配比为什么重要——几个经典案例
┌─────────────────────────────────────────────────────────────┐
│ 不同模型的数据配比策略及效果 │
├─────────────────────────────────────────────────────────────┤
│ │
│ The Pile (EleutherAI, 2020): │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 22 个精选数据集，学术导向 │ │
│ │ 包括 PubMed, ArXiv, GitHub, StackExchange, Books3 │ │
│ │ │ │
│ │ 贡献：证明"精选混合"远优于"随机大量" │ │
│ │ → GPT-Neo/GPT-J 的基础训练数据 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ LLaMA (Meta, 2023): │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 只使用公开可用数据，不用用户数据 │ │
│ │ 强调代码数据（15%）→ 推理能力显著提升 │ │
│ │ 发现：即使训练 token 数远超 Chinchilla optimal， │ │
│ │ 小模型（7B/13B）仍然在持续提升 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ DeepSeek (2024-2025): │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 极大比例的高质量数学/代码数据 │ │
│ │ 中文数据占比高（相比 LLaMA 几乎无中文） │ │
│ │ → DeepSeek 的数学能力和代码能力位居开源模型前列 │ │
│ │ │ │
│ │ 核心洞察：数学+代码数据 = 推理能力 │ │
│ │ 纯文本讨论再多的推理，不如让模型在代码中实践逻辑 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 关键教训： │
│ • 数据配比是"食谱"，不同"食谱"产出的模型能力不同 │
│ • 代码数据是"秘密武器"——它教会模型逻辑和分步推理 │
│ • 数据配比是高度保密的商业机密 │
│ │
└─────────────────────────────────────────────────────────────┘1.4 需要多少数据？——从 Chinchilla 到 Llama 3
┌─────────────────────────────────────────────────────────────┐
│ 训练数据量：理论最优 vs 工业实践 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Chinchilla 最优 (DeepMind, 2022): │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 公式：D_optimal ≈ 20 × N │ │
│ │ 其中 D = 训练 token 数，N = 模型参数数 │ │
│ │ │ │
│ │ • 1B 参数 → 200亿 tokens │ │
│ │ • 7B 参数 → 1400亿 tokens │ │
│ │ • 70B 参数 → 1.4万亿 tokens │ │
│ │ • 175B 参数→ 3.5万亿 tokens │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 工业实践（远超 Chinchilla）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 模型 │ 参数量 │ 训练Tokens │ 倍数(C-opt) │ │
│ │ ─────────────┼─────────┼───────────┼────────────── │ │
│ │ GPT-3 │ 175B │ 300B │ 0.09× (严重不足)│ │
│ │ Chinchilla │ 70B │ 1.4T │ 1.0× (恰好) │ │
│ │ LLaMA-1-7B │ 7B │ 1.0T │ 7.1× │ │
│ │ LLaMA-2-70B │ 70B │ 2.0T │ 1.4× │ │
│ │ Llama 3-8B │ 8B │ 15T │ 93.8× ！ │ │
│ │ Llama 3-70B │ 70B │ 15T │ 10.7× │ │
│ │ DeepSeek-V3 │ 671B MoE│ 14.8T │ ~37× (按激活)│ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 为什么远超 Chinchilla？ │
│ • Chinchilla 是在固定计算预算下的最优解 │
│ • 但如果你有更多算力，继续喂更多数据，模型还会变好 │
│ • Llama 3 证明：即使到了 15T tokens，8B 模型仍没饱和 │
│ • 小模型 + 海量数据 >> 大模型 + 少量数据（同计算预算下） │
│ │
└─────────────────────────────────────────────────────────────┘1.5 数据质量 vs 数据数量——永恒的 tradeoff
┌─────────────────────────────────────────────────────────────┐
│ 数据质量 vs 数量的权衡 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 问题： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 你有 100 万 GPU-小时的计算预算。 │ │
│ │ 方案 A：用 100B 高质量 token（如精选书籍+论文） │ │
│ │ 方案 B：用 1T 中等质量 token（如过滤后的网页） │ │
│ │ │ │
│ │ 选哪个？ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 研究发现： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • 在计算预算受限时：质量 > 数量 │ │
│ │ LLaMA 只用了 1T tokens 但精选数据，效果碾压 │ │
│ │ 那些用了更多数据但质量较差的模型 │ │
│ │ │ │
│ │ • 当数据量极大时：多样性 > 纯度 │ │
│ │ 过度过滤会导致模型没见过"脏数据"，推理时遇到 │ │
│ │ 打字错误或非正式表达时表现差 │ │
│ │ │ │
│ │ • 中等质量数据的重复：有害 │ │
│ │ 同一数据重复训练超过 4-5 个 epoch → 过拟合 │ │
│ │ │ │
│ │ • 高质量数据的重复：没那么有害，但收益递减 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 实践建议（综合各团队的共识）： │
│ 1. 先用质量过滤（去掉垃圾） │
│ 2. 再保证多样性（不要只留"教科书式"的文本） │
│ 3. 每个数据源最多重复 4 个 epoch │
│ 4. 如果预算允许，加更多高质量数据，而不是重复旧数据 │
│ │
└─────────────────────────────────────────────────────────────┘第2部分：Scaling Laws——更大的模型需要多少数据和算力
2.1 什么是 Scaling Laws
Scaling Laws 回答一个核心问题：给定计算预算，我应该把资源分配给更大的模型还是更多的数据？
┌─────────────────────────────────────────────────────────────┐
│ Scaling Laws 的核心问题 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 你有 B 美元的计算预算。 │
│ │
│ 选项 A：建一个大模型，用少量数据训练 │
│ → GPT-3 风格：175B 参数，只训练 300B tokens │
│ │
│ 选项 B：建一个小模型，用海量数据训练 │
│ → Llama 3 风格：8B 参数，训练 15T tokens │
│ │
│ 选项 C：建一个中等模型，用中等数据训练 │
│ → Chinchilla 风格：70B 参数，训练 1.4T tokens │
│ │
│ 哪一个最终模型效果最好？ │
│ │
└─────────────────────────────────────────────────────────────┘2.2 Kaplan et al. (OpenAI, 2020)——第一个 Scaling Law
┌─────────────────────────────────────────────────────────────┐
│ Kaplan Scaling Law（OpenAI, 2020） │
├─────────────────────────────────────────────────────────────┤
│ │
│ 核心结论：当计算预算增加时，应该把大部分资源分给模型大小 │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 给定计算预算 C： │ │
│ │ • N (模型参数) ∝ C^0.73 │ │
│ │ • D (数据量) ∝ C^0.27 │ │
│ │ │ │
│ │ 翻译：计算预算增加 10 倍 → 模型变大 5.3 倍，数据只多 1.9 倍│ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 这就是为什么 GPT-3 这么大（175B）但只训练了 300B tokens： │
│ → OpenAI 当时相信"模型大比分重要" │
│ │
└─────────────────────────────────────────────────────────────┘2.3 Chinchilla (DeepMind, 2022)——推翻 Kaplan
┌─────────────────────────────────────────────────────────────┐
│ Chinchilla Scaling Law（DeepMind, 2022） │
├─────────────────────────────────────────────────────────────┤
│ │
│ DeepMind 训练了 400+ 个不同大小的模型（70M 到 16B）， │
│ 系统性地研究了模型大小和数据量的最优配比。 │
│ │
│ 核心发现：Kaplan 错了。模型大小和数据量应该等比例增长。 │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 给定计算预算 C： │ │
│ │ • N (模型参数) ∝ C^0.50 │ │
│ │ • D (数据量) ∝ C^0.50 │ │
│ │ │ │
│ │ 翻译：计算预算增加 10 倍 → 模型和数据各涨 3.16 倍 │ │
│ │ │ │
│ │ Chinchilla 最优公式：D ≈ 20 × N │ │
│ │ 一个 70B 的模型，应该用 1.4T tokens 训练 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 实验验证： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ DeepMind 训练了 Chinchilla（70B 参数，1.4T tokens） │ │
│ │ 对比 Gopher（280B 参数，300B tokens） │ │
│ │ │ │
│ │ 结果：Chinchilla 在所有 benchmark 上都碾压 Gopher！ │ │
│ │ • Chinchilla: 70B 参数 │ │
│ │ • Gopher: 280B 参数 │ │
│ │ │ │
│ │ 训练成本相近，但小 4 倍的 Chinchilla 赢了。 │ │
│ │ → 因为数据给够了！ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 重要纠正： │
│ GPT-3 只有 300B tokens 训练 175B 参数 │
│ → D/N = 300B/175B = 1.7（远低于 Chinchilla 的 20） │
│ → GPT-3 严重"欠训练"（undertrained） │
│ → 如果重新分配计算预算，一个更小的模型+更多数据效果更好 │
│ │
└─────────────────────────────────────────────────────────────┘2.4 用 Chinchilla 公式做具体计算
┌─────────────────────────────────────────────────────────────┐
│ 手算 Chinchilla 最优值——你需要多大数据？ │
├─────────────────────────────────────────────────────────────┤
│ │
│ Chinchilla 核心公式：D_optimal ≈ 20 × N │
│ │
│ 你的模型参数量 N → 最优训练 Token 数 D │
│ ───────────────────────────────────────────── │
│ 100M (0.1B) → 2B tokens │
│ 1B → 20B tokens │
│ 7B (LLaMA-7B) → 140B tokens │
│ 13B (LLaMA-13B) → 260B tokens │
│ 34B (Code Llama 34B) → 680B tokens │
│ 70B (LLaMA-2-70B) → 1.4T tokens │
│ 175B (GPT-3) → 3.5T tokens │
│ 405B (Llama 3.1 405B) → 8.1T tokens │
│ 671B (DeepSeek-V3, MoE) → 按 37B 激活: 740B tokens │
│ │
│ 注意：这只是"最优"的理论值。 │
│ 实际中很多模型远超这个数，效果继续变好。 │
│ │
└─────────────────────────────────────────────────────────────┘2.5 FLOPs 估算——训练需要多少计算量
Transformer 训练的 FLOPs 可以用一个简洁的公式近似：
┌─────────────────────────────────────────────────────────────┐
│ 训练 FLOPs 估算公式 │
├─────────────────────────────────────────────────────────────┤
│ │
│ FLOPs_total ≈ 6 × N × D │
│ │
│ 其中： │
│ N = 模型参数数量 │
│ D = 训练 token 数量 │
│ 6 = 每个参数每个 token 的 FLOPs（前向2 + 反向4） │
│ │
│ 推导简述（Transformer 一次前向传播）： │
│ • 每个 token 每个参数：~2 FLOPs（一次乘一次加） │
│ • 反向传播：~4 FLOPs（约为前向的 2 倍） │
│ • 总：~6 FLOPs/token/param │
│ │
└─────────────────────────────────────────────────────────────┘具体计算示例——GPT-3：
GPT-3: N = 175B, D = 300B tokens
FLOPs = 6 × 175 × 10^9 × 300 × 10^9
= 6 × 175 × 300 × 10^18
= 315,000 × 10^18
= 3.15 × 10^23 FLOPs
换算：
3.15 × 10^23 FLOPs ÷ 10,000 张 V100
V100 FP16: ~125 TFLOPS = 1.25 × 10^14 FLOPs/s (理论)
实际利用率 ~50%: ~6.25 × 10^13 FLOPs/s
总时间 = 3.15 × 10^23 ÷ (10,000 × 6.25 × 10^13)
= 3.15 × 10^23 ÷ 6.25 × 10^17
≈ 5.04 × 10^5 秒
≈ 140 小时
≈ 5.8 天（假设 100% 利用率、无故障）
实际需要约 14.8 天（利用率更低、有故障恢复）具体计算示例——Chinchilla 最优的 70B 模型：
Chinchilla optimal 70B: N = 70B, D = 1.4T
FLOPs = 6 × 70 × 10^9 × 1.4 × 10^12
= 6 × 98 × 10^21
= 5.88 × 10^23 FLOPs
对比 GPT-3: 3.15 × 10^23 FLOPs
Chinchilla 70B 的训练 FLOPs 几乎是 GPT-3 的 2 倍！
→ Chinchilla 虽小但训练更贵（因为数据多得多）
→ 但最终效果好得多具体计算示例——Llama 3-70B（远超 Chinchilla）：
Llama 3-70B: N = 70B, D = 15T
FLOPs = 6 × 70 × 10^9 × 15 × 10^12
= 6 × 1050 × 10^21
= 6.3 × 10^24 FLOPs
这是 Chinchilla 最优 70B 的 ~10.7 倍 FLOPs！
→ 远超 Chinchilla 的"最优"，但效果显著更好
→ "Chinchilla 最优"只是计算预算固定时的最优，预算可以更多2.6 Beyond Chinchilla——新共识
┌─────────────────────────────────────────────────────────────┐
│ 超越 Chinchilla：工业界的新共识 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Chinchilla 结论（2022）：D ≈ 20 × N 是最优的 │
│ │
│ 2024-2025 实践：D ≈ 100× 甚至 1000× N 仍然有效 │
│ │
│ 为什么？ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 1. Chinchilla 在固定计算预算下优化 │ │
│ │ 现实是：大公司不在乎"最优"——它们要"最好" │ │
│ │ │ │
│ │ 2. 更多数据总是有帮助的（收益递减，但还没到零） │ │
│ │ Llama 3-8B 训练到 15T tokens，loss 还在下降 │ │
│ │ │ │
│ │ 3. 小模型+海量数据有工程优势 │ │
│ │ • 推理更快、更便宜 │ │
│ │ • 部署成本低 │ │
│ │ • 用户愿意等更久的训练，但不愿等更久的推理 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 新共识： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • "Chinchilla optimal" → "只要数据够多就继续训" │ │
│ │ • D >> 20 × N 不再被认为是"浪费" │ │
│ │ • 数据质量 >> 数据数量（但数量仍然重要） │ │
│ │ • 最终瓶颈可能是"能找到多少高质量数据"，而不是算力 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘第3部分：训练稳定性——为什么大模型训练容易崩
3.1 Loss Spike——训练时的"心脏病发作"
┌─────────────────────────────────────────────────────────────┐
│ Loss Spike：大模型训练的噩梦 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 训练 Loss 曲线（正常）： │
│ │
│ Loss │
│ │ │
│ 8 ┤╲ │
│ │ ╲ │
│ 6 ┤ ╲______ │
│ │ ╲___ │
│ 4 ┤ ╲___ │
│ │ ╲___ │
│ 2 ┤ ╲___ │
│ │ ╲___ │
│ └──────────────────────────────────→ Steps │
│ │
│ 训练 Loss 曲线（出现 Loss Spike）： │
│ │
│ Loss │
│ │ ↑ spike! │
│ 8 ┤╲ │ │
│ │ ╲ │ │
│ 6 ┤ ╲______ │ │
│ │ ╲___ │ │
│ 4 ┤ ╲___ ╱────╯ │
│ │ ╲╱╲ ╲___ │
│ 2 ┤ ╲________╲___ │
│ │ │
│ └──────────────────────────────────→ Steps │
│ │
│ 一旦出现大 Spike，Loss 可能： │
│ • 跳到 NaN → 训练崩溃，彻底失败 │
│ • 跳高后回落 → 但模型质量永久受损 │
│ • 跳高后回落但不恢复 → Loss 停滞在较高水平 │
│ │
└─────────────────────────────────────────────────────────────┘3.2 Loss Spike 的常见原因
┌─────────────────────────────────────────────────────────────┐
│ Loss Spike 五大常见原因及对策 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 原因1：坏数据批次（Bad Data Batch） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 某一批训练数据极其异常： │ │
│ │ • 全是特殊字符或乱码 │ │
│ │ • 全是重复 token（如 2048 个 "the"） │ │
│ │ • 语言突然切换（英文中混入一整段二进制） │ │
│ │ │ │
│ │ 对策：数据质量过滤在前（见第1部分），但总有漏网之鱼 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 原因2：梯度爆炸（Gradient Explosion） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 某些参数梯度过大，一次更新把权重推到极端值 │ │
│ │ → 后续前向传播产生巨大激活值 │ │
│ │ → Loss 暴增 │ │
│ │ │ │
│ │ 对策：Gradient Clipping（梯度裁剪） │ │
│ │ 把梯度的 L2 范数限制在一个阈值内（如 1.0） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 原因3：混合精度数值问题 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ FP16 的范围很小（最大 65504），梯度或激活值溢出 │ │
│ │ │ │
│ │ 对策：使用 BF16（范围 = FP32，只是精度低） │ │
│ │ 或用 Loss Scaling（把 Loss 放大再缩小） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 原因4：优化器状态损坏 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Adam 的 m（动量）和 v（二阶矩）积累了异常值 │ │
│ │ 一旦某个参数梯度的 EMA 变得极大 → 更新步巨大 │ │
│ │ │ │
│ │ 对策：从 Spike 前的 Checkpoint 恢复，丢弃损坏的状态 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 原因5：硬件故障（Silent Data Corruption） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ GPU 内存位翻转、网络传输错误、NVLink 故障 │ │
│ │ 在大规模训练中，硬件故障不是"是否"的问题，而是"何时" │ │
│ │ │ │
│ │ 对策：ECC 内存、Checkpoint、冗余检查 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘3.3 梯度裁剪（Gradient Clipping）——稳定训练的第一道防线
┌─────────────────────────────────────────────────────────────┐
│ 梯度裁剪：防止单步更新过大 │
├─────────────────────────────────────────────────────────────┤
│ │
│ g = 计算出的梯度向量（所有参数的梯度拼成一个大向量） │
│ │
│ 如果 ||g||₂ > max_norm（比如 1.0）： │
│ g_clipped = g × (max_norm / ||g||₂) │
│ 否则： │
│ g_clipped = g │
│ │
│ 直观： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 原始梯度（太大）： │ │
│ │ ═══════════════════════════════════════════→ │ │
│ │ │ │
│ │ 裁剪后（方向相同，长度受限）： │ │
│ │ ═══════→ │ │
│ │ │ │
│ │ 方向保持不变（梯度告诉我们的方向是对的） │ │
│ │ 但步长被限制（防止一步踩太远掉进坑里） │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 典型设置：max_norm = 1.0 │
│ GPT-3 用了 max_norm = 1.0 │
│ LLaMA 用了 max_norm = 1.0 │
│ │
└─────────────────────────────────────────────────────────────┘3.4 混合精度训练——FP16、BF16 和 FP32
┌─────────────────────────────────────────────────────────────┐
│ 混合精度训练：为什么、怎么用、各格式的区别 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 为什么需要混合精度？ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ FP32（32位浮点数）： │ │
│ │ • 每个参数占 4 字节 │ │
│ │ • 175B 参数 × 4 bytes = 700 GB（仅模型权重） │ │
│ │ • 加上优化器状态（Adam 需要 8 bytes/param） │ │
│ │ → 总计 ~2.1 TB 显存 │ │
│ │ • 远超单卡显存（A100-80GB 只有 80GB） │ │
│ │ │ │
│ │ FP16/BF16（16位浮点数）： │ │
│ │ • 每个参数占 2 字节 → 显存需求直接减半 │ │
│ │ • 计算速度翻倍（Tensor Core 对 FP16 有专门加速） │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 三种浮点格式对比： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 格式 │ 总位数 │ 符号 │ 指数 │ 尾数 │ 数值范围 │ │
│ │ ───────┼────────┼──────┼──────┼──────┼─────────── │ │
│ │ FP32 │ 32 │ 1 │ 8 │ 23 │ ~10^±38 │ │
│ │ FP16 │ 16 │ 1 │ 5 │ 10 │ ~10^±4.8 │ │
│ │ BF16 │ 16 │ 1 │ 8 │ 7 │ ~10^±38 │ │
│ │ │ │
│ │ FP16 的问题：范围太小 │ │
│ │ • 最大值只有 65504 │ │
│ │ • 梯度或激活值容易溢出 → Inf/NaN │ │
│ │ │ │
│ │ BF16 的优势：范围 = FP32，精度比 FP16 低但够用 │ │
│ │ • 指数位和 FP32 一样多（8 bits） │ │
│ │ • 不会溢出！ │ │
│ │ • 尾数少 16 bits（精度低），但对训练来说足够 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 混合精度训练的典型配置（AMP - Automatic Mixed Precision）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ • 前向传播：FP16/BF16（快，省显存） │ │
│ │ • 反向传播：FP16/BF16（快，省显存） │ │
│ │ • 权重主副本：FP32（保证精度累积） │ │
│ │ • 优化器状态（Adam m, v）：FP32 │ │
│ │ │ │
│ │ 流程： │ │
│ │ FP32 Weight ──→ cast to FP16/BF16 ──→ Forward │ │
│ │ → Backward │ │
│ │ FP16/BF16 Gradient ──→ cast to FP32 ──→ Update │ │
│ │ │ │
│ │ 每个 step 前后做两次精度转换，几乎不影响速度 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Loss Scaling（FP16 时代必需，BF16 时代可有可无）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ FP16 下很多梯度值非常小（< 2^-24），会被截断为 0 │ │
│ │ → 把 Loss 乘以一个大数（如 1024），梯度也跟着放大 │ │
│ │ → 更新前把梯度除以同一个数 │ │
│ │ │ │
│ │ BF16 为什么不需要？ │ │
│ │ → BF16 的指数范围大，小梯度不会下溢 │ │
│ │ → 这是 BF16 成为 LLM 训练标准的关键原因之一 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘3.5 学习率调度——Warmup 为什么救命
┌─────────────────────────────────────────────────────────────┐
│ 学习率调度：Warmup → Cosine Decay │
├─────────────────────────────────────────────────────────────┤
│ │
│ 学习率曲线： │
│ │
│ LR │
│ │ │
│ │ ╱╲ │
│ │ ╱ ╲ │
│ │ ╱ ╲ │
│ │ ╱ ╲_____________ │
│ │ ╱ ╲___ │
│ │╱ warmup ╲___ cosine decay │
│ └────────────────────────────────────→ Steps │
│ │
│ 三个阶段： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 1. Warmup（预热）： │ │
│ │ LR 从 0 线性增长到 peak LR │ │
│ │ 通常持续 2000-4000 steps │ │
│ │ │ │
│ │ 为什么需要 Warmup？ │ │
│ │ → 训练刚开始时，权重是随机的 │ │
│ │ → 梯度方向不稳定（今天往东，明天往西） │ │
│ │ → 如果直接上大学习率，一步可能把权重推到 │ │
│ │ 一个无法恢复的位置 │ │
│ │ → Warmup 让模型先"找到北"，再加速 │ │
│ │ │ │
│ │ 2. 峰值区（可选，不是所有方案都用）： │ │
│ │ LR 保持在 peak LR 一段时间 │ │
│ │ 一些训练方案（如 Llama 3）有短暂的 Constant │ │
│ │ │ │
│ │ 3. Cosine Decay（余弦衰减）： │ │
│ │ LR 按余弦曲线降到 peak LR 的 ~10% 或 0 │ │
│ │ → 后期用小学习率做"精细调整" │ │
│ │ → 比起线性或阶梯衰减，余弦衰减更平滑 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 典型设置： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ GPT-3: peak LR = 6×10^-5, warmup = 375M tokens │ │
│ │ LLaMA: peak LR = 3×10^-4, warmup = 2000 steps │ │
│ │ Chinchilla: peak LR = 1×10^-4, warmup = 1000 steps │ │
│ │ DeepSeek: peak LR = 2×10^-4, warmup = 2000 steps │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 经验法则：模型越大，peak LR 越小，warmup 越长 │
│ │
└─────────────────────────────────────────────────────────────┘第4部分：Checkpoint 与恢复——训练不是一次性的
4.1 为什么 Checkpoint 是必需品
┌─────────────────────────────────────────────────────────────┐
│ Checkpoint：训练的生命保险系统 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 训练一个 175B 模型需要数周到数月。在这个过程中： │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 硬件层面的故障（必然会遇到）： │ │
│ │ • GPU 故障/过热 → 单卡宕机 │ │
│ │ • 网络故障（NCCL） → 多卡通信中断 │ │
│ │ • 存储故障 → 数据读不出来 │ │
│ │ • 机房电力问题 → 整个集群掉电 │ │
│ │ • 光纤/交换机故障 → 通信带宽骤降 │ │
│ │ │ │
│ │ 软件层面的问题（也很常见）： │ │
│ │ • Loss Spike → 需要回滚到 Spike 之前 │ │
│ │ • OOM (Out of Memory) → 需要减小 batch size 后重启 │ │
│ │ • CUDA 错误 → 驱动/NCCL 版本不兼容 │ │
│ │ • 代码 bug → 修好后需要从上一个正常点继续 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 核心原则： │
│ "训练不是从零开始的。训练是从上一个 Checkpoint 开始的。" │
│ │
│ → 没有 Checkpoint = 任何故障都意味着从头来过 │
│ → 保存频率 = 故障恢复的代价 │
│ │
└─────────────────────────────────────────────────────────────┘4.2 Checkpoint 里存什么
┌─────────────────────────────────────────────────────────────┐
│ Checkpoint 包含的内容 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 一个完整的 Checkpoint 包含： │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 1. 模型权重（Model Weights） │ │
│ │ • 所有层的参数矩阵 │ │
│ │ • 这是最大的部分 │ │
│ │ • 175B 模型 FP32：~700 GB │ │
│ │ • 175B 模型 FP16：~350 GB │ │
│ │ │ │
│ │ 2. 优化器状态（Optimizer States） │ │
│ │ • Adam m (动量, first moment)：每个参数一个值 │ │
│ │ • Adam v (二阶矩, second moment)：每个参数一个值 │ │
│ │ • FP32 精度 → 每个参数 8 bytes (m+v) │ │
│ │ • 175B × 8 = 1.4 TB │ │
│ │ │ │
│ │ 3. 学习率调度器状态 │ │
│ │ • 当前 Step 数 │ │
│ │ • 当前学习率 │ │
│ │ • Warmup 是否已完成 │ │
│ │ │ │
│ │ 4. 数据迭代器状态 │ │
│ │ • 数据 shuffle 的随机种子 │ │
│ │ • 当前读到哪个文件/哪个位置 │ │
│ │ • → 保证恢复后不会重复训练或漏掉数据 │ │
│ │ │ │
│ │ 5. RNG 状态（随机数生成器状态） │ │
│ │ • Python random, NumPy random, PyTorch random │ │
│ │ • Dropout 的 mask 生成依赖这些 │ │
│ │ • → 保证恢复后结果完全一致（deterministic） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 一个 175B 模型的 Checkpoint 总大小（含优化器状态）： │
│ 模型权重（FP16）： ~350 GB │
│ 优化器状态（FP32）： ~1400 GB │
│ 其他： ~1 GB │
│ 总计： ~1.75 TB │
│ │
│ 这就是为什么训练大模型需要 PB 级的存储系统 │
│ │
└─────────────────────────────────────────────────────────────┘4.3 分布式训练中的 Checkpoint 复杂性
┌─────────────────────────────────────────────────────────────┐
│ 分布式环境下的 Checkpoint 挑战 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 在分布式训练中，模型权重被切分到多个 GPU 上： │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 模型被切分的方式（回顾 [[13-distributed-training]]）：│ │
│ │ │ │
│ │ Data Parallelism (DP)： │ │
│ │ GPU 0: 完整模型副本 0 ← 各有一份完整权重 │ │
│ │ GPU 1: 完整模型副本 1 │ │
│ │ GPU 2: 完整模型副本 2 │ │
│ │ → Checkpoint 好做：每个 GPU 都有完整模型 │ │
│ │ │ │
│ │ Tensor Parallelism (TP) + Pipeline Parallelism (PP)：│ │
│ │ GPU 0: Layer 0-7 的前半部分 │ │
│ │ GPU 1: Layer 0-7 的后半部分 │ │
│ │ GPU 2: Layer 8-15 的前半部分 │ │
│ │ GPU 3: Layer 8-15 的后半部分 │ │
│ │ → Checkpoint 复杂：需要把碎片拼回完整模型 │ │
│ │ → 保存时：每个 GPU 写自己的分片（快） │ │
│ │ → 加载时：每个 GPU 读自己的分片（快） │ │
│ │ → 但如果要合并成一个完整 Checkpoint（推理用）： │ │
│ │ 需要 Gather 所有分片 → 耗时、耗存储 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 常见策略： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • 分片存储（Sharded Checkpoint）： │ │
│ │ 每个 GPU 保存自己的分片，加载时各读各的 │ │
│ │ → 不需要 Gather，速度快 │ │
│ │ → 但 Checkpoint 绑定到特定的并行拓扑 │ │
│ │ │ │
│ │ • 合并存储（Consolidated Checkpoint）： │ │
│ │ 把所有分片 Gather 成一个完整文件 │ │
│ │ → 独立于并行拓扑，方便推理/Debug │ │
│ │ → 但保存和加载都慢很多 │ │
│ │ │ │
│ │ 实践：训练时用分片 Checkpoint（高频保存）， │ │
│ │ 训练完成后导出合并 Checkpoint（只做一次） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘4.4 Checkpoint 保存频率与策略
┌─────────────────────────────────────────────────────────────┐
│ Checkpoint 保存策略 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 常见策略： │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • 按时间间隔：每 N 分钟保存一次 │ │
│ │ 典型：每 30 分钟 ~ 每 4 小时 │ │
│ │ │ │
│ │ • 按 Step 间隔：每 N 个 step 保存一次 │ │
│ │ 典型：每 1000 ~ 10000 steps │ │
│ │ │ │
│ │ • 保留策略： │ │
│ │ ─ 保留最近 K 个 Checkpoint（如 5 个） │ │
│ │ ─ 保留每 M 步的历史 Checkpoint（用于回溯） │ │
│ │ ─ 最佳实践：按指数间隔保留 │ │
│ │ （最新的保存密一些，旧的保存稀一些） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 恢复流程： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 1. 检测到故障（或人工停止） │ │
│ │ 2. 找到最新的有效 Checkpoint │ │
│ │ 3. 加载模型权重 + 优化器状态 │ │
│ │ 4. 恢复数据迭代器位置 │ │
│ │ 5. 恢复 RNG 状态 │ │
│ │ 6. 重新验证（跑几个 step 确认 Loss 正常） │ │
│ │ 7. 继续训练 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 关键陷阱：如果出现 Loss Spike，不要用最新的 Checkpoint！ │
│ → 往回找，找到 Spike 之前的一个 Checkpoint │
│ → 从那里恢复，跳过导致 Spike 的那批数据 │
│ → 这就是保留历史 Checkpoint 的意义 │
│ │
└─────────────────────────────────────────────────────────────┘第5部分：Pre-Training 成本估算——钱都花在哪了
5.1 几个代表性模型的训练成本
┌─────────────────────────────────────────────────────────────┐
│ 代表性模型的 Pre-Training 成本 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 模型 │ 年份 │ 参数量 │ GPU-小时 │ 估算成本 │
│ ───────────────┼─────┼──────────┼────────────┼───────── │
│ GPT-3 │2020 │ 175B │ 3.6M V100-h │ ~$4.6M │
│ Gopher │2021 │ 280B │ 7.1M TPUv3-h│ ~$10M+ │
│ Chinchilla │2022 │ 70B │ 6.8M TPUv3-h│ ~$8M+ │
│ LLaMA-1-65B │2023 │ 65B │ 1.0M A100-h │ ~$2M │
│ LLaMA-2-70B │2023 │ 70B │ 1.7M A100-h │ ~$3.5M │
│ Falcon-180B │2023 │ 180B │ 7.0M A100-h │ ~$14M │
│ Llama 3-70B │2024 │ 70B │ ~7M H100-h │ ~$15M+ │
│ Llama 3-405B │2024 │ 405B │ ~31M H100-h │ ~$65M+ │
│ DeepSeek-V3 │2024 │ 671B MoE │ 2.8M H800-h │ ~$5.6M │
│ GPT-4 (估算) │2023 │ ~1.8T MoE│ ~200M A100-h│ ~$80-100M│
│ │
│ 注意： │
│ • 成本只计算 GPU 租赁费用，不包括： │
│ - 人员工资（数十到数百名工程师，月薪 $10K-$50K+） │
│ - 数据采集和处理成本 │
│ - 存储/网络基础设施 │
│ - 失败的实验（模型训崩了，钱就白花了） │
│ • 实际总成本通常是 GPU 成本的 2-5 倍 │
│ │
└─────────────────────────────────────────────────────────────┘5.2 成本怎么算——GPU-小时的单价
┌─────────────────────────────────────────────────────────────┐
│ GPU 租赁价格参考（2024 年云服务价格） │
├─────────────────────────────────────────────────────────────┤
│ │
│ GPU │ 显存 │ FP16 TFLOPS │ 租赁价/小时 (云) │
│ ──────────┼────────┼────────────┼────────────────────── │
│ V100-32GB │ 32 GB │ ~125 │ ~$2-3 │
│ A100-40GB │ 40 GB │ ~312 │ ~$3-4 │
│ A100-80GB │ 80 GB │ ~312 │ ~$4-5 │
│ H100-80GB │ 80 GB │ ~990 │ ~$5-8 │
│ H800-80GB │ 80 GB │ ~990 │ ~$4-6 (中国特供) │
│ H200-141GB │ 141 GB │ ~990 │ ~$6-10 │
│ │
│ 典型训练集群规模： │
│ • GPT-3: 10,000 V100 │
│ • LLaMA-2: 2,000 A100-80GB │
│ • Llama 3: ~16,000 H100 │
│ │
│ 计算训练成本： │
│ cost = GPU数量 × 训练时间(h) × 单价($/GPU-h) │
│ │
│ 示例：LLaMA-2-70B │
│ 2000 A100-80GB × 850h × $4/h = $6.8M（估算上限） │
│ （实际约 1.7M GPU-hours × $2/h ≈ $3.4M） │
│ │
└─────────────────────────────────────────────────────────────┘5.3 DeepSeek-V3 的极致性价比——为什么能做到 $5.6M
┌─────────────────────────────────────────────────────────────┐
│ DeepSeek-V3：用极致工程优化把成本打下来 │
├─────────────────────────────────────────────────────────────┤
│ │
│ DeepSeek-V3 的关键数字： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • 总参数：671B（MoE，每次只激活 37B） │ │
│ │ • 训练 Token：14.8T │ │
│ │ • GPU-小时：2.8M H800-hours │ │
│ │ • 估算成本：~$5.6M │ │
│ │ │ │
│ │ 对比：Llama 3-405B 用了 ~31M H100-hours │ │
│ │ → DeepSeek 用不到 1/10 的 GPU 时训出了可比模型 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 他们是怎么做到的？（公开技术报告中披露的） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 1. MoE 架构（Mixture-of-Experts） │ │
│ │ 671B 总参数，但每次前向只激活 37B │ │
│ │ 训练 FLOPs 按激活参数算，不是按总参数算 │ │
│ │ │ │
│ │ 2. FP8 混合精度训练 │ │
│ │ 比 FP16/BF16 又省了一半显存和计算 │ │
│ │ DeepSeek 是最早在超大规模上成功用 FP8 的团队之一 │ │
│ │ │ │
│ │ 3. Multi-Token Prediction (MTP) │ │
│ │ 不仅预测下一个 token，还预测下 2-4 个 token │ │
│ │ → 更密集的训练信号，收敛更快 │ │
│ │ │ │
│ │ 4. DualPipe 流水线并行 │ │
│ │ 自研的 Pipeline Parallelism 算法 │ │
│ │ → 减少 GPU 空闲时间（bubble time） │ │
│ │ │ │
│ │ 5. 极致通信优化 │ │
│ │ Cross-node All-to-All 通信的定制优化 │ │
│ │ → MoE 的最大瓶颈是 Expert 之间的路由通信 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 启示： │
│ • 大模型成本不是固定的——工程创新可以大幅降低成本 │
│ • 中国团队受限于 GPU 性能（H800 比 H100 弱）， │
│ 倒逼出了更高效的训练方案 │
│ • MoE + FP8 + 更好的 Pipeline = 1/10 的成本 │
│ │
└─────────────────────────────────────────────────────────────┘5.4 预训练经济学——为什么只有少数公司玩得起
┌─────────────────────────────────────────────────────────────┐
│ 预训练的经济壁垒 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 入门级（~$1M - 5M）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 7B-13B 参数，1-5T tokens │ │
│ │ 需要：~256-512 张 A100/H100，训练 1-2 个月 │ │
│ │ 代表：开源社区、中小公司可以承担 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 竞赛级（~$10M - 50M）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 70B-100B 参数，3-15T tokens │ │
│ │ 需要：~2000-4000 张 H100，训练 2-4 个月 │ │
│ │ 代表：Mistral, Cohere, 01.AI, 大型企业 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 前沿级（~$50M - $200M+）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 400B+ 参数或 MoE 万亿参数，15T+ tokens │ │
│ │ 需要：~16000+ 张 H100/B200，训练 3-6 个月 │ │
│ │ 代表：OpenAI, Google, Anthropic, Meta │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 全成本清单（不止 GPU）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • GPU 集群租赁/购置：$5M - $200M+ │ │
│ │ • 数据采集和清洗：$1M - $10M │ │
│ │ • 工程团队（10-100人×$200K-$500K/年）：$2M-$50M/年 │ │
│ │ • 电力/冷却/机房：GPU 成本的 10-20% │ │
│ │ • 失败的实验：可能占总预算的 30-50% │ │
│ │ • 存储（PB 级）：$100K-$1M/年 │ │
│ │ │ │
│ │ 真实全成本 ≈ GPU 成本的 2-5 倍 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 为什么失败实验这么贵？ │
│ • 数据配比不对 → 训完发现效果差 → 钱白花了 │
│ • 训练中 Loss Spike 无法恢复 → 从 Checkpoint 回滚 → │
│ 几十万 GPU-小时打水漂 │
│ • 架构设计有问题（如 MoE 路由策略）→ 训练到一半发现不行 │
│ • Scaling Law 预测不准 → 训到一半发现 Loss 不降了 │
│ │
│ 结论：预训练是高风险的资本密集型活动。 │
│ 每一次从头训练都是一次"赌博"。 │
│ │
└─────────────────────────────────────────────────────────────┘核心总结
总结1：Pre-Training 是工厂，Post-Training 是装修
Pre-Training 决定了模型能力的上限。Post-Training 只能激发已有能力，不能凭空创造。一个 Base Model 如果没有在预训练中学过某种知识，后续无论如何对齐（SFT/RLHF）都不会让它突然"学会"这个知识。Base Model = 原始能力，Chat Model = 能力包装成对话形式。
总结2：数据是预训练的第一性原理
数据质量、数量和配比直接决定模型质量。Common Crawl 是主体（量大），但需要大量清洗。代码数据是提升推理能力的"秘密武器"。数据配比是商业机密——不同的配比产生不同能力特长的模型。
总结3：Scaling Laws 给出了计算预算的分配公式
- Kaplan (2020)：模型比数据重要——错了
- Chinchilla (2022)：模型和数据同等重要——D_optimal ≈ 20N
- 2024+ 实践：只要还有高质量数据，继续喂，模型继续变好——D >> 20N 不再是浪费
训练 FLOPs ≈ 6ND，这个公式让你能快速估算任何模型的训练成本。
总结4：训练稳定性是大规模训练的最大工程挑战
Loss Spike 会导致训练崩溃。五道防线：数据质量过滤、梯度裁剪、BF16 替代 FP16、Warmup 学习率、频繁 Checkpoint。BF16 的"范围=FP32，精度低但够用"特性使其成为 LLM 训练的事实标准。
总结5：Checkpoint = 生命线
训练不是从 0 开始的，是从上一个 Checkpoint 开始的。保存频率决定了故障恢复的代价。分布式训练中，分片存储是效率首选。遇到 Loss Spike，回滚到 Spike 前的 Checkpoint 是唯一的拯救方案。
总结6：预训练成本门槛极高
从 $2M（7B 模型）到 $100M+（前沿模型），预训练是"富人俱乐部"。但工程优化（MoE + FP8 + MTP + Pipeline）可以将成本降低 10 倍。DeepSeek-V3 证明：聪明的设计可以部分弥补硬件劣势。
章节测试
测试1：Base Model 和 Chat Model 的根本区别是什么？
A. Base Model 参数更少 B. Base Model 只会续写，不会对话；Chat Model 经过 Post-Training 学会了对话格式 C. Base Model 用的是 CPU 训练 D. Base Model 不能处理中文
测试2：Chinchilla Scaling Law 的核心结论是什么？
A. 模型参数量越大越好，数据量不重要 B. 数据量越大越好，模型大小不重要 C. 模型大小和数据量应该等比例增长，D_optimal ≈ 20N D. 只要模型够大，不需要预训练数据
测试3：GPT-3（175B 参数，300B tokens）的 D/N 比值是多少？按照 Chinchilla 标准，它是什么状态？
A. D/N = 20，达到最优 B. D/N = 1.7，严重欠训练（undertrained） C. D/N = 100，远超最优 D. D/N = 0.1，刚好够
测试4：BF16 相比 FP16 的最大优势是什么？
A. 精度更高（更多尾数位） B. 数值范围更大（和 FP32 一样大），不会溢出 C. 计算速度更快 D. 显存占用更少
测试5：为什么训练开始时需要 Warmup？
A. 让 GPU 预热到工作温度 B. 训练开始时梯度方向不稳定，大学习率可能把权重推到不可恢复的位置 C. 为了让数据加载跟上计算速度 D. 纯属惯例，没有实际作用
测试6：训练出现 Loss Spike 后，应该怎么做？
A. 继续训练，Loss 自己会降下来 B. 增大学习率，加速跳过这个区域 C. 从 Spike 前的 Checkpoint 恢复，跳过导致 Spike 的那批数据 D. 重新随机初始化模型，从头训练
测试7：一个 7B 参数的模型，按照 Chinchilla 公式，需要多少训练 tokens？训练 FLOPs 大约是多少？
参考答案
测试1答案
答案：B。Base Model 经过 Pre-Training 只会做 Next Token Prediction——给定前缀，续写后面的内容。它不知道什么是"对话"。Chat Model 经过了 SFT（教它对话格式）和 RLHF/DPO（教它人类偏好），才知道"用户问一句，我答一句"的互动模式。Base Model 的能力上限决定了 Chat Model 的天花板。
测试2答案
答案：C。Chinchilla 推翻了 Kaplan 的结论（Kaplan 认为模型大小增长应该快于数据量增长）。Chinchilla 通过 400+ 次实验证明：在固定计算预算下，模型大小和数据量应该等比例增长，最优配比约为 D ≈ 20N。
测试3答案
答案：B。D/N = 300B / 175B ≈ 1.7，远低于 Chinchilla 最优的 20。GPT-3 严重欠训练——如果重新分配计算预算，一个更小的模型配合更多数据可以达到更好的效果。Chinchilla（70B/1.4T）就用更少的计算预算碾压了 Gopher（280B/300B）。
测试4答案
答案：B。BF16 和 FP16 都是 16 位浮点数，显存占用相同。区别在于：BF16 用 8 位指数（= FP32 的指数位数），范围可达 ~10^±38，但精度低（7 位尾数）；FP16 用 5 位指数，范围只有 ~10^±4.8，但精度更高（10 位尾数）。对训练来说，范围 > 精度——FP16 的梯度/激活值经常溢出，BF16 不会。因此 BF16 已成为 LLM 训练的事实标准。
测试5答案
答案：B。训练刚开始时模型权重是随机初始化的，各层的激活值分布还很不稳定。此时梯度方向在各 step 之间变化剧烈。如果直接使用大学习率，一个 step 就可能把参数推到极端区域（梯度消失或爆炸），后续再也回不来。Warmup 在最初几千步内从小学习率开始，让模型"找到方向"，再逐渐加速。
测试6答案
答案：C。一旦出现大 Loss Spike，说明某个批次的数据或某次参数更新破坏了模型。继续训练或增大学习率只会让情况更糟。正确做法是回到 Spike 之前的 Checkpoint，从那里换一批数据继续。这也是为什么要保留多个历史 Checkpoint 的原因。
测试7答案
Chinchilla 最优数据量：D ≈ 20 × 7B = 140B tokens。
训练 FLOPs ≈ 6 × N × D = 6 × 7×10^9 × 140×10^9 = 6 × 980 × 10^18 = 5.88 × 10^21 FLOPs。
如果用 256 张 A100（FP16 ~312 TFLOPS，实际利用率 ~50%，即 ~78 TFLOPS/卡），总吞吐 ~20 PFLOPs/s = 2×10^16 FLOPs/s。大约需要 5.88×10^21 / 2×10^16 ≈ 2.94×10^5 秒 ≈ 82 小时 ≈ 3.4 天。（注：实际工业实践中很多远超 Chinchilla，如 Llama 3-8B 训了 15T tokens。）
相关笔记
- [[11-training-primer]] — 训练循环四步曲：Forward → Loss → Backward → Update
- [[13-distributed-training]] — 从单卡到千卡集群：DP、TP、PP、ZeRO
- [[08-transformer-by-hand]] — 手算 Transformer 前向传播
- [[10-training-vs-inference]] — 训练和推理的完整对比
- [[14-post-training-overview]] — Post-Training：SFT → Reward → RLHF/DPO
下一步学习
- [ ] 阅读 [[13-distributed-training]]，理解预训练在工程上如何从单卡扩展到千卡集群
- [ ] 用 Chinchilla 公式算一算：如果要训练一个 34B 的模型，按照 Chinchilla 最优、工业实践（LLaMA 风格）、超大数据（Llama 3 风格）三种方案分别需要多少数据
- [ ] 阅读 DeepSeek-V3 技术报告，理解 MTP 和 DualPipe 如何把训练成本降了 10 倍
- [ ] 选择一个开源的预训练代码库（如 TinyLlama 或 LitGPT），理解训练循环的具体实现
学习状态：🟡 开始学习