夜雨聆风
Scaling Law 没崩,但 OpenAI 当年的“扩模型公式”可能真的算错了
作者 Diogo Almeida 曾在 OpenAI 从事大语言模型优化相关工作。他在文章开头直接给出了一个相当尖锐的判断：2020 年那套经典 Scaling Law，因为一个 Bug，得出了错误的结论。
随后，DeepMind 研究员 Sander Dieleman 转发了这篇文章，并认为错误的 scaling recipe 可能让行业在一批“模型过大、训练不足”的大模型上浪费了大量计算资源。
消息传到中文社区后，很快被概括成一句更有传播力的话：
Scaling Law 塌房了。
但真正读完 Almeida 的文章，再回头看 2020 年 OpenAI 的 Scaling Law 论文和 2022 年 DeepMind 的 Chinchilla，会发现事情没有这么简单。
Scaling Law 本身并没有被推翻。
真正受到质疑的，是一个更加具体，同时也更加关键的问题：
在固定算力预算下，计算资源究竟应该更多用来扩大模型参数，还是增加训练数据？
换句话说，问题不是“Scaling 有没有用”，而是“算力应该怎么花”。
而 OpenAI 2020 年给出的答案，很可能确实偏了。
从 Scaling Law 说起
2020 年，OpenAI 的 Jared Kaplan 等人发表论文《Scaling Laws for Neural Language Models》。
这篇论文系统研究了模型参数量 N、训练数据量D 和计算量 C 与语言模型 Loss 之间的关系。
研究人员发现，在相当大的实验范围内，随着模型、数据和计算规模增加，语言模型的 Loss 呈现出稳定的幂律下降趋势。简单来说，就是：
当横轴和纵轴取对数后，大量实验点会形成接近直线的关系。
这件事今天看起来已经非常熟悉，但在 2020 年意义巨大。
因为训练大模型是一项极其昂贵的工程。真正开始训练一个千亿参数模型之前，研究人员最想知道的并不是“模型扩大后大概率会变好”，而是更加实际的问题：
我有这么多 GPU。这么多 FLOPs。这么多训练时间。模型到底应该做多大？训练多少数据？
Scaling Law 的价值，就在于允许研究人员先训练大量较小模型，再根据实验曲线预测更大规模下的模型表现。
Kaplan 论文关于幂律关系的核心观察，直到今天依然是大模型研究的重要基础之一。
真正的问题出现在下一步。
假设现在有固定的训练算力。
粗略忽略模型架构等因素，可以把训练计算量理解成：
也就是说，在计算预算基本固定的情况下，模型参数量和训练 token 数之间需要进行取舍。
一种方案是把模型做得非常大，但训练数据少一些：
另一种方案则是模型小一些，但训练更多数据：
究竟哪一种更加划算？
Kaplan 2020 给出的答案明显偏向第一种。
论文认为，更大的模型具有更高的 sample efficiency。因此，在追求 compute-efficient training 时，应该优先训练非常大的模型，使用相对有限的数据，并且没有必要等模型完全收敛后再停止训练。
后来 DeepMind 在 Chinchilla 论文中，将 Kaplan 的 compute-optimal scaling 结果概括为：
这个指数非常关键。
它意味着当计算预算增加时，大部分新增算力应该用于扩大模型参数，而训练数据只需要缓慢增长。
于是整个行业很自然地走向了一条路线：
模型越做越大。
GPT-3 有 175B 参数，训练约 300B tokens。
Jurassic-1 有 178B 参数，同样训练约 300B tokens。
Gopher 更进一步，达到 280B 参数，但训练数据仍然只有约 300B tokens。
MT-NLG 甚至扩展到 530B 参数，训练 token 数依然停留在数百 B 的数量级。
模型参数迅速从百亿走向千亿，甚至开始讨论万亿参数。
相比之下，数据规模增长得非常缓慢。
这种路线与 Kaplan Scaling Law 给出的 compute-optimal recipe 高度一致：
有更多算力，就优先把模型做大。
“Scaling is all you need”也逐渐成为大模型时代最有代表性的行业信仰之一。
直到 2022 年，DeepMind 发布 Chinchilla。
Chinchilla 给出了完全不同的答案
2022 年，DeepMind 发布论文《Training Compute-Optimal Large Language Models》。
研究团队训练了超过 400 个不同规模的语言模型，模型参数覆盖 70M 到 16B 以上，训练数据规模覆盖 5B 到 500B tokens。
他们重新研究了 Kaplan 当年那个最核心的问题：
固定 FLOPs 下，模型到底应该做多大，又应该训练多少 tokens？
最终得到的结果与 Kaplan 明显不同。
DeepMind 发现，compute-optimal training 下，模型参数量和训练数据量应该大致同比例增长：
也就是说，如果计算预算增加四倍，模型参数量大约增加两倍，训练 token 数也应该增加两倍。
这与 Kaplan 的“算力主要投入参数规模”完全不同。
为了验证这个结论，DeepMind 直接重新设计了一个模型。
此前他们训练过 Gopher：
280B 参数，300B tokens。
按照新的 Scaling Law，在相似训练算力下，模型根本没有必要做到 280B 参数。更合理的方案应该是减小模型，把节省下来的计算资源用于训练更多数据。
于是 Chinchilla 出现了。
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
Chinchilla 只有 70B 参数，不到 Gopher 的四分之一，却训练了大约 1.4 万亿 tokens。
两者使用接近的训练计算预算。
结果 Chinchilla 在大量下游任务中超过 Gopher，同时也超过 GPT-3、Jurassic-1 和 MT-NLG。
而由于模型参数更少，Chinchilla 在推理和微调阶段的计算成本也明显更低。
这个结果直接暴露出一个问题：
过去很多大模型，可能做得太大了。
它们并不是模型容量不够，而是拥有大量参数，却没有看到足够多的数据。
DeepMind 对此用了一个非常直接的词：
undertrained，训练不足。
于是一个更加尖锐的问题出现了。
为什么 Kaplan 和 Chinchilla 对同一个问题，会得到差异如此巨大的答案？
Kaplan 认为新增算力应该主要用于扩大参数。
Chinchilla 却认为参数和数据应该同步增长。
这已经不是一点实验误差，而是两条完全不同的大模型设计路线。
Diogo Almeida 2026 年的文章，就是在重新回答这个问题。
一个可能被忽略多年的 Bug
Almeida 认为，Kaplan 与 Chinchilla 的差异并不只是“不同团队采用不同实验方法，因此得到不同经验公式”。
在他看来，Kaplan 原始 Scaling Law 的实验设计中存在一个系统性 Bug。
整个问题可以从训练数据的设置说起。
Kaplan 的大量实验中，不同规模的模型使用接近固定的训练 horizon，训练 token 上限大约位于 130B tokens 附近。
表面上看，这是一种非常公平的实验设计。
100M 模型训练 130B tokens。
1B 模型训练 130B tokens。
10B 模型也训练 130B tokens。
所有模型看到相同数量的数据，然后比较表现。
但问题在于，不同容量的模型对于数据的需求并不相同。
一个较小模型容量有限，训练到 130B tokens 时，可能已经得到了非常充分的优化。
但一个更大的模型拥有更强的数据吸收能力。130B tokens 对它来说可能远远不够。
换句话说，同样的训练 token 数，对小模型意味着“已经训练充分”，对大模型却可能意味着“刚刚开始进入状态”。
如果所有模型都在同一个数据上限停止训练，那么最终看到的结果就会系统性偏向大模型。
因为大模型尚未充分利用数据扩展带来的收益。
但仅仅固定训练 token 数，还不足以让这个问题如此难以发现。
Almeida 特别强调了第二个因素：学习率调度。
Kaplan 的默认训练策略是先进行 3000 step warmup，然后使用 cosine learning rate decay，并在训练终点附近将学习率逐渐衰减到零。
Cosine Decay 本身没有问题。
直到今天，它依然是深度学习训练中最常见的学习率调度方法之一。
问题在于，这里的 learning rate schedule 与固定训练 horizon 绑定在了一起。
随着模型逐渐接近目标 token 数，学习率不断降低，参数更新越来越小。
最终：
模型基本停止学习。
于是训练曲线会出现一种非常自然的现象。
Loss 一开始快速下降，随后下降速度逐渐减慢，最后进入平台期。
从曲线上看，模型似乎已经“接近收敛”。
研究人员很容易得出一个结论：
继续增加训练数据，收益可能已经很小。
但 Almeida 提出了另一种解释。
也许不是数据已经没有用了，而是 learning rate 已经主动下降到了接近零。
模型不是学不会，而是训练策略不再允许模型进行足够大的参数更新。
固定 training horizon 与 cosine decay 叠加后，大模型在训练终点附近会表现得像“数据已经饱和”。
于是继续增加数据的价值被低估。
Kaplan 论文中还有一句很重要的话。
研究人员表示，他们尝试了不同 learning rate 和 schedule，并发现模型最终收敛结果 largely independent of learning rate schedule。
Almeida 认为，这句话放在固定训练 horizon 的实验条件下可能没有问题。
如果问题是：
模型最多训练 130B tokens，不同 schedule 最终结果差多少？
那么很多 learning rate schedule 最终确实可能得到接近的结果。
但 Scaling Law 想回答的是一个更加一般的问题：
随着训练数据规模持续增加，模型性能如何变化？
这是两个不同的问题。
前者有一个固定训练终点。
后者试图预测更加长期的 scaling behavior。
Almeida 的观点是，Kaplan 在固定 token 上限下得到的 learning rate 结论，被带入了更一般的 scaling 分析。
于是整个偏差链条形成了。
固定 training tokens，使大模型训练不足。
Cosine decay 在训练终点附近降低 learning rate。
Loss 曲线因此逐渐进入平台期。
研究人员观察到继续训练似乎收益有限。
数据量 D 的价值被低估。
Compute-optimal scaling formula 因此更加偏向模型参数量 N。
最终得到：
模型越来越大，数据增长却相对缓慢。
这就是 Almeida 所说的 Bug。
但事情还没有这么简单
如果文章写到这里，很容易得出一个新的简单结论：
Cosine Decay 导致 OpenAI Scaling Law 算错了。
但这种说法同样过度简化。
因为在 Almeida 发表这篇博客之前，学界已经有人系统研究过 Kaplan 与 Chinchilla 的 scaling discrepancy。
2024 年，一篇名为《Resolving Discrepancies in Compute-Optimal Scaling of Language Models》的论文专门重新研究了这个问题，并成为 NeurIPS 2024 Spotlight。
研究人员在 OpenWebText2 和 RefinedWeb 数据集上重新复现 Kaplan Scaling Law。
他们最终认为，Kaplan 与 Chinchilla 之间的差异主要来自三个因素：
last-layer computational cost。
warmup duration。
scale-dependent optimizer tuning。
修正这些因素后，实验结果开始接近 Chinchilla Scaling Law。
更值得注意的是，这项研究明确指出，精细的 learning rate decay 并不是得到 Chinchilla 式 scaling 结果的必要条件。
也就是说，关于“Cosine Decay 是否是整个问题的核心 Bug”，目前仍然存在不同技术解释。
Almeida 更强调固定 training horizon 和 learning rate schedule 的联合作用。
Porian 等人的研究则更强调计算量统计、warmup 设置和不同模型规模下 optimizer 参数没有正确 scaling。
两种解释并不完全相同。
但它们最终指向同一个结果：
Kaplan 2020 给出的 compute-optimal scaling recipe 确实存在系统性偏差。
这也是为什么“Scaling Law 塌房了”并不是一个准确的总结。
真正受到挑战的不是 Scaling Law 本身，而是早期关于 compute allocation 的结论。
Scaling Law 到底错没错？
现在可以回答这个问题了。
Scaling Law 没有被推翻。
Kaplan 论文最重要的经验观察依然成立。
随着模型参数、训练数据和计算量增加，语言模型 Loss 在较大的实验范围内呈现相对稳定的 power-law scaling。
事实上，Chinchilla 本身也是 Scaling Law。
它并不是反 Scaling。
它是在重新计算 Scaling。
真正发生变化的是资源分配公式。
Kaplan 的路线可以概括为：
Chinchilla 的路线则是：
因此，这次事件最准确的说法不是：
“Scaling Law 错了。”
而是：OpenAI 早期 Scaling Law 给出的 compute-optimal 资源分配公式，很可能存在系统性错误。
这依然是一件影响深远的事情。
因为 Scaling Law 真正的工程意义，并不是告诉研究人员“模型变大一般会更好”。
所有人都知道更大的模型、更大的数据和更多算力通常能够带来更好的结果。
真正困难的问题是：
有固定的 
FLOPs，模型应该做多大？
训练多少 tokens？
Learning Rate 怎么设置？
Warmup 多长？
Batch Size 如何变化？
训练什么时候停止？
这些问题最终共同决定一个模型是否真正 compute optimal。
一个 scaling exponent 看起来只差 0.2。
但当它被外推到千亿参数、数万张 GPU 和数亿美元训练预算时，最终得到的可能是完全不同的模型。
行业真的因此浪费了大量算力吗？
这是目前讨论中最容易被夸大的部分。
没有可靠数据能够证明 Kaplan Scaling Law 究竟造成了多少 GPU hours 浪费。
更没有任何严谨统计能够支持“整个 AI 行业白烧了万亿算力”这种说法。
Sander Dieleman 的表述同样是一种推测。
他认为错误的原始 Scaling Law 可能导致大量计算资源被投入 oversized、undertrained models。
这里的关键词是：可能。
但从技术逻辑看，这种影响确实存在。
Chinchilla 早在 2022 年就已经证明，在相同训练计算预算下，更小的模型配合更多训练 tokens，能够取得更好的效果。
而且模型更小还意味着更低的推理成本。
因此，一套错误的 compute-optimal recipe 可能产生两层成本。
第一层是训练成本。
算力没有按照最优比例分配。
第二层是长期推理成本。
最终得到的模型本来不需要那么大。
模型训练只进行一次。
但一个商业模型可能需要执行数十亿甚至数百亿次 inference。
每一次推理，都需要为额外参数支付显存、带宽、延迟和计算成本。
因此，从整个模型生命周期来看，参数规模偏大带来的影响，可能远远超过一次预训练本身。
真正值得反思的，不是 Scaling，而是我们如何理解 Scaling
Scaling Law 最吸引人的地方，是那些非常漂亮的直线。
横轴取 log。
纵轴取 log。
大量不同规模的模型落在一条近似直线上。
当一个经验规律表现得足够稳定时，人们很容易产生一种错觉：
规律已经被找到了。
接下来只需要沿着曲线继续外推。
但这次争议再次提醒我们：
Scaling Law 是 empirical law。
它不是物理定律。
它来自实验，而实验一定依赖具体条件。
-
数据分布。
-
Tokenizer。
-
模型架构。
-
Optimizer。
-
Learning Rate。
-
Warmup。
-
Batch Size。
-
训练 horizon。
-
Compute accounting。
-
甚至如何定义 parameter count。
这些变量中的任何一个，都可能随着模型规模变化而产生新的影响。
Kaplan 论文自己其实也承认，当时并没有对 Scaling Law 的完整理论解释。研究人员无法严格证明这些 power-law relationships 为什么出现，也无法保证所有 scaling relationship 都能够无限外推。
现在回头再看，这恰恰是最值得重视的部分。
模型 Scale 了。
数据 Scale 了。
Compute Scale 了。
但很多训练超参数，同样需要 Scale。
一个在 100M 参数模型上合理的 warmup，在 10B 模型上未必仍然合理。
一个固定 130B token 的 training horizon，在不同模型容量下代表的训练充分程度完全不同。
一个在小模型上调好的 optimizer 配置，也不应该理所当然地复制到更大的模型。
Scaling Law 最大的风险，从来不是模型规模扩大。
真正的风险是：
当曲线足够漂亮时，我们可能忘记曲线下面仍然存在一整套实验条件。
今天的 Scaling，早就不只是“堆参数”
Chinchilla 之后，大模型行业明显提高了对训练数据规模和训练充分程度的重视。
与此同时，Scaling 本身也在发生变化。
Pre-training Scaling。
Post-training Scaling。
Reinforcement Learning Scaling。
Synthetic Data Scaling。
Context Scaling。
Inference-time Scaling。
Test-time Compute。
今天再讨论 Scaling，已经很难简单概括成一句“模型参数再扩大十倍”。
甚至 Chinchilla 也不是最终答案。
因为 Chinchilla 优化的主要目标是 training compute。
但真实商业系统还需要考虑 inference compute。
假设一个模型训练完成后需要服务数亿用户，那么企业可能愿意在训练阶段多花一些算力，把一个较小模型训练得更加充分。
这种方案可能偏离严格意义上的 training-compute optimal frontier。
但它能够降低未来每一次 inference 的成本。
训练只有一次。
推理却可能发生数十亿次。
因此现实中的 Scaling，本质上已经变成一个多目标优化问题：
同时受到以下条件约束：
不同的商业场景、硬件条件和数据规模，会得到不同的最优解。
这也是为什么 Scaling Law 永远不应该被理解成一条简单的“模型越大越好”公式。
结语
Diogo Almeida 的《Scaling Laws, Honestly》真正有价值的地方，不是宣布 Scaling Law 已死。
恰恰相反。
它再次证明了 Scaling Law 为什么如此重要。
一个 scaling exponent 的偏差。
一个固定 training horizon。
一个看起来普通的 learning rate schedule。
一个没有随着模型规模重新调整的 optimizer 参数。
在小规模实验里，它们可能只是几条 Loss 曲线之间的差异。
但当这些结论被外推到千亿参数、数万张 GPU 和数亿美元训练预算时，微小的方法论偏差会被规模本身同步放大。
从 2020 年 Kaplan Scaling Law，到 2022 年 Chinchilla，再到 2024 年对 compute-optimal discrepancy 的系统复现，以及 2026 年 Diogo Almeida 对这段历史的重新复盘。
这不是 Scaling 的失败。
而是科学和工程最正常的过程。
提出规律，扩大规模，发现异常，重新复现，修正方法，然后继续 Scaling。
所以，这次事件最准确的总结也许只有一句：
Scaling 没死。
死掉的是“参数越大越划算”这种过度简化的理解。
真正的大模型 Scaling，从来不是无脑堆参数。
而是在有限算力下，不断寻找参数、数据、训练和推理之间新的最优解。