Appearance
预训练：数据与训练
这一页只看第一阶段：
预训练阶段，预算、参数量、token 和数据质量到底是什么关系。
Chinchilla 真正在解什么题
在 GPT-3 时代，一个常见做法是：
- 做更大的 dense 模型
- 训练相对没那么多 token
DeepMind 在 Chinchilla 论文 里给出的关键结论是：
- 在固定训练算力预算下
- 更小一些的模型
- 配上更多训练 token
- 往往比“超大参数但训练不够”的模型更优
最核心的问题其实是：
如果训练预算是 C，什么样的参数量 N 和训练 token 数 D 最合适？
dense 文本预训练里的经典比例
对 dense Transformer 预训练，常见的粗略估算是：
text
训练 FLOPs ≈ 6 * N * D其中：
N是参数量D是训练 token 数
而 Chinchilla 给出的经典近似是：
text
D* ≈ 20 * N也就是在 dense 文本预训练的经典区间里，
最优训练 token 数大致是 参数量的 20 倍。
这页最重要的比例就是：
在 dense + 文本 + 从零预训练 这条经典路线里，先把 D/N 看成约 20:1。
它不是永恒常数，但它是第一版预算最有用的起点。
从预算反推参数量和训练 token
把两个式子合在一起，就得到一个很有用的预算视角：
text
C ≈ 6 * N * D
且 D ≈ 20N
=> C ≈ 120N²
=> N* ≈ sqrt(C / 120)
=> D* ≈ 20 * sqrt(C / 120)这套推导最重要的意义不是算得极准，而是给你一个工程判断框架：
- 先有预算
C - 再反推出合适的
N - 再得到配套的
D
而不是先拍脑袋定一个超大参数量，再去想办法补数据。
一个够用的预算表
下面这个表不追求精确到小数点，它只是把这套关系变成直觉：
训练预算 C | 建议参数量 N* | 建议训练 token D* |
|---|---|---|
1e23 FLOPs | 约 29B | 约 0.58T |
3e23 FLOPs | 约 50B | 约 1.0T |
1e24 FLOPs | 约 91B | 约 1.8T |
真正该记住的不是这几个数字本身，而是：
- 预算翻
10x，参数量不会翻10x - 合适参数量大致按
sqrt(C)长 - 训练 token 也跟着长，但要和参数量一起长
用 GPT-3 / Chinchilla 看这件事
最经典的对照仍然是 GPT-3 时代和 Chinchilla 自己：
- GPT-3：
175B参数，300Btoken - 同量级训练计算下，Chinchilla 发现更接近最优的点，大概会落在
50B级参数和1T左右 token - Chinchilla 自己的公开例子则是：
70B参数，1.3Ttoken，在和 Gopher 接近的训练计算下表现更好
这件事真正说明的是：
预算固定时，过大的模型会吃掉本该给数据的计算。
MoE 会怎样改写这道题
MoE 没有推翻 Chinchilla，但它改变了“应该把哪个参数量放进公式”。
text
对 MoE，单 token 训练计算更接近 active params，而不是 total params这意味着在固定预算下，MoE 的常见做法不是：
- 直接继续放大 dense 参数
而是：
- 先决定每 token 愿意激活多少参数
A - 再让总参数
T通过稀疏专家继续变大 - 用更大的总容量换更强的表示能力
从预算角度看，更接近下面这个思路：
text
C ≈ 6 * A * D这里真正和预算线性相关的，更像是 active params A。
而 total params T 更像是在增加模型容量和专家分工。
这会带来三个重要变化。
1. total params 不再是最直接的算力口径
如果你还拿 total params 去套 20 token / 参数，很容易马上失真。
MoE 里更该先看的，是：
- 每 token 激活多少参数
- 路由是否稳定
- 专家是否真的学出了分工
2. 总容量变大后，数据多样性反而更重要
MoE 让你能把总参数做得很大，
但这不等于 token 可以随便少。
专家越多、容量越大，往往越需要：
- 更广的数据覆盖
- 更强的领域多样性
- 更稳定的路由和负载均衡
否则就会出现“参数很多，但部分专家没吃饱”的问题。
3. 20 token / 参数 更像是对 active compute 的经典基线
今天在 MoE 时代，更稳的理解不是：
20 token / total params
而是：
先拿 active compute 做第一版预算，再看 total capacity 要不要继续放大
也就是说：
- Chinchilla 仍然给你
active compute的第一性约束 - MoE 再帮助你在不线性抬高每 token 计算的前提下继续扩容
多模态会怎样改写这道题
多模态也没有推翻 Chinchilla，但它把“数据量”这个概念改复杂了。
纯文本里，D 基本可以直接理解成训练 token。
到了多模态，问题会变成：
- 文本 token 和视觉 token 怎么一起算
- 音频、视频的时间结构怎么对齐
- 成本瓶颈在数量，还是在对齐质量
所以多模态时代更像是在处理：
等效训练信息量
而不只是一个简单的文本 token 数。
数据为什么会越来越贵
1. 原始成本
原始成本通常包括：
- 抓取与购买
- 存储与带宽
- 解析、去重、清洗
- 版权、授权与合规
token 规模越往上走，光是“搬运、存储、筛掉垃圾”就已经不是小钱。
2. 质量成本
真正更贵的通常是质量成本：
- 领域筛选
- 专家标注
- 难例挖掘
- 合成数据生成
- 自动验证
- 数据回放与回归
很多 frontier 模型真正拉开差距的地方，不是它们拿到了多少原始网页，而是它们如何把：
- 代码
- 数学
- PDF / 文档文本抽取
- agent 轨迹
- 长上下文样本
- 多模态对齐样本
做成可训练、可验证、可复用的高质量数据工厂。
用公开案例把这件事看具体
Qwen3：今天的大模型训练已经是 staged program
Qwen3 技术报告给出的公开信息很关键：
- 旗舰模型
Qwen3-235B-A22B 235B total / 22B active- 预训练总规模
36Ttoken - 三阶段预训练：
30T+通用阶段、约 5T高质量 STEM / code / reasoning 阶段、数千亿 token的长上下文阶段 - 还用
Qwen2.5-VL从大量 PDF 文档里抽取高质量文本，再叠加数学和代码合成数据
这说明今天的 frontier 训练，已经不是“抓网页然后一口气喂完”，而是：
- 先做大规模通用底座
- 再用更贵的高质量数据强化特定能力
- 最后单独为长上下文再开一段预算
Gemma 3：多模态会直接改写 token 预算的含义
Gemma 3 技术报告给出了一个很干净的公开例子：
27B版本预训练14Ttoken12B版本预训练12Ttoken- 训练预算比 Gemma 2 更大，官方明确说明这和
images + text的混合预训练有关 - 结构上引入共享视觉编码器，并把图像压成固定数量的视觉向量
它说明多模态时代至少有三件事变了：
- 数据不再只是网页文本，还要加图文配对、视觉理解和多语言样本
- token 预算增加，不只是因为“文本更多”，而是因为模态更复杂
- 训练设计里会多出视觉编码器、模态对齐和长上下文内存控制这些额外约束
NVIDIA Nemotron 3 Super：MoE 省的是 active compute，不是数据工厂
NVIDIA Nemotron 3 Super 的官方模型卡同时披露了架构和训练数据口径：
120B total / 12B active- 预训练
25T+token - 公开训练语料总规模
约 15.6Ttoken - 数据里明确包含 code、math、science、general knowledge，以及大量合成和验证链路
这个例子最能说明：
- MoE 的确能把单 token 计算压到更低
- 但 frontier 模型并没有因此减少数据投入
- 相反，它们通常会把钱继续花到更强的数据筛选、合成和验证上
DeepSeek V4：frontier 的竞争点已经变成 active size、长上下文和结构效率
DeepSeek V4 公开信息里最突出的信号是：
DeepSeek-V4-Pro：1.6T total / 49B active1Mcontext- 重点强调
Token-wise compression和长上下文结构
这说明在最新一代 MoE frontier 里，公开口径已经明显从“总参数到底多大”，转向：
- active size 到底多大
- 长上下文怎样训练和保持效率
- 结构设计能不能把算力更有效地花掉
结论
- 这一阶段最核心的问题，是
预算怎样分给参数量、token 和数据质量 - 对 dense 文本预训练，第一版最有用的口径仍然是：
D/N ≈ 20 - MoE 把重点从
total params改成了active params - 多模态把“token 数量”进一步改写成“等效信息量和对齐质量”
- 今天真正成熟的训练设计，已经是
预算 + 结构 + 数据工厂一起看