★ FEATURED ARTICLE 搞大模型这几年几乎每周都有人拿着曲线图来问我参数加到多少才够用训练数据堆到多少才不浪费算力问的人多了我发现大家纠结的其实都是同一件事——扩展律Scaling Law和模型规模化之间的关系。我这个从十亿参数一直折腾到百亿级的实践者想用一篇文章把这个问题彻底讲透扩展律到底是一条什么规律怎么用它来安排参数、数据和计算量以及实际操作中那些论文里不会写的坑。适合准备做预训练、或者想评估模型扩展投入产出比的朋友。1. 扩展律究竟在说什么1.1 一句话版本性能不是线性的而是“平方根游戏”扩展律最核心的表述并不复杂在其他条件相近时模型的最终损失会随着参数量、训练数据量、总计算量的增加而按幂律下降。用一个简化公式来表示就是 L(N) ≈ A / N^α L0其中 N 是参数量α 是某个小于 1 的正指数L0 是一个不可继续下降的常数。类似的式子也可以写在数据量 D 和计算量 C 上。这个关系最反直觉的地方在于它不是线性的而是“收益递减”的。你从 1 亿参数涨到 4 亿参数效果提升可能非常明显但从 40 亿参数涨到 160 亿参数同样的 4 倍规模收益绝不会是之前那个 4 倍。用生活里的例子来说这就像背单词从 2000 词补到 4000 词能解决很多交流问题但从 2 万词补到 4 万词日常对话体感几乎没有差别。扩展律就是在用一组数学公式告诉我们这笔账不是拍脑袋而是可以算出来的。我最早看到这个结论时第一反应是“那模型是不是不用无限做大了”后来想明白它的价值恰恰在这里它让你在动手之前就知道把预算从 1 倍加到 4 倍预期收益大概是多少值不值得。这不是让你停止扩大规模而是让你别再“盲目”扩大规模。1.2 公式背后不可忽视的常数 L0很多人看扩展律只看 A / N^α 部分忽略了后面那个 L0。其实 L0 才是真正决定规模上限的东西。它代表的是模型在这个数据集、这个任务体系下“不可约”的损失数据本身有噪声同样的内容可以有多种表达标签可能互相矛盾甚至 token 序列本身的信息熵就摆在那里。无论你把模型撑到多大L0 都像一面墙一样挡在前面。这解释了为什么“更大”不是永远有效。假设你的训练语料里 30% 是重复或低质内容那模型的天花板会被这批数据拉得很低。你把参数从 10 亿加到 50 亿可能只是把洗澡水里的泡沫吹得更多水本身的脏度一点没变。反过来如果数据足够干净、信息密度足够高扩大模型容量才真正能接住“更多的信息”。实际做项目时我会先在小批量数据上做一次“瓶颈排查”同一种数据分别拿 1000 条和 1 万条去训练一个小模型如果损失差距很小说明当前问题很可能卡在容量上如果损失差距很大说明数据质量或覆盖度才是瓶颈。这一步看起来土却很管用能帮你决定下一轮到底该加数据还是加参数。1.3 扩展律不是“模型越大越厉害”的护身符我见过不少团队手里一旦有算力第一反应就是“把模型做大两倍”。结果训练到一半发现损失下降曲线比预期平缓很多最后做出来跟小模型加更多数据的效果差不多。原因很简单扩展律说的是“在计算量最优分配下的收益”而不是“单独增大任何一个变量都能带来线性提升”。换句话说它是三维的参数、数据、计算量三者互相耦合。你只把参数翻倍数据不动计算量的确会上去但模型很容易记住训练集中的表面规律遇到新分布时毫无招架之力。你只把数据翻倍参数不动那多出来的数据只是让模型在一组固定容量里反复折返跑边际贡献同样快速衰减。真正的模型规模化永远是参数的扩展、数据的扩展、算力预算的扩展三者一起规划而不是单独某一项的军备竞赛。2. 模型规模化的三个支点数据、算力与参数2.1 数据一直是被低估的杠杆这些年聊规模化大家默认先谈参数。但我的体感刚好相反数据才是大多数项目里最硬的约束。原因有两个第一高质量数据的获取成本远高于 GPU 成本第二数据规模不够大时参数规模越大过拟合风险反而越高最后验证集损失会直接“抬不起头”。具体看一组数据效果在固定模型大小的情况下训练数据量 D 的扩展律同样服从幂律。哪怕只是一个挂着几层注意力的小模型当语料从 1 亿 token 涨到 10 亿 token 时下游任务指标通常都会有可观提升。而有些团队明明有 50 亿参数的大模型却只喂了 20 亿 token等于让一个高精度天平去称一堆沙容量全部浪费。所以我在规划任何一次预训练前都会先把“可用数据总量”放在第一位。这里的可用数据不是磁盘里有多少原始文本而是经过去重、清洗、过滤、配比之后真正能进训练管道的干净 token 数。如果这个数字撑不起目标参数规模的建议数据量那就老老实实调低参数目标或者先去扩充数据生产线否则训练出来的模型大概率是个“虚胖”模型。2.2 算力规模化不是钱的问题是效率的问题算力预算通常用总 FLOPs 来形容。很多人以为算力多就是显卡多、跑得久但在规模化实践中更关键的是“有效算力利用率”。我在早期做过一次对比同一份代码、同样的模型某厂商框架默认配置跑出来的模型 FLOPs 利用率和手工调过并行策略、通信算子后的版本相比差了接近一倍。也就是说你花的钱里可能有一半都变成了等待和无效计算。扩展律公式里用到的 C 是“有效计算量”不是“账单上的计算量”。如果你的框架里存在严重的通信瓶颈、频繁的 checkpoint 开销、数据加载卡顿那你在扩展律曲线上看到的实际位置会比理论位置偏右很多明明打了 10 的 22 次方 FLOPs真实模型却只吃到了 10 的 21 次方的学习量。因此我建议在正式做大规模全量训练之前先做一次小规模的“效率体检”固定跑 1000 步统计有效 token 吞吐、模型 FLOPs 利用率、卡间通信占比。这个体检结果决定了你的算力预算该乘以 1 还是乘以 0.6。千万别拿着一个低效框架直接冲大模型否则浪费的不只是钱还有整个团队的时间窗口。2.3 参数容量和优化难度的平衡参数规模的扩展不像堆乐高多一块是一块。每增加一批参数模型容量在变大但优化难度也在变大。更深的网络、更多的注意力头、更大的词表意味着梯度信号要穿过更长的路径学习率、初始化、归一化方式都得更小心。从扩展律的角度看参数和数据量的关系更像是一个联立方程当一个维度过大时另一维度会被迫成为瓶颈。业界广泛流传的“最优配置经验”是在给定计算预算下参数量和数据量应当同步增长而不是谁盖过谁。如果预算相对有限我会倾向多留一点给数据因为数据的边际收益在早期非常陡如果预算非常充足则需要认真做一次不同参数比例的小规模对比用外推曲线来决定最终配比。我自己的经验是参数增加带来的收益曲线通常比数据增加的收益曲线更早进入平台期。所以除非你的数据管线已经充裕到用不完否则别急着把模型从 30 亿改成 100 亿。先把那批参数换成更长的训练步数和更多的高质量 token往往效果更稳。3. 从公式到实操怎么按扩展律规划一次规模化训练3.1 先定预算再反推参数量和训练数据量很多人做模型扩展是“先定参数量再凑数据”这其实把顺序搞反了。更合理的方式是先确定总计算预算 C然后用扩展律反解参数量 N 和训练数据量 D。前向反向计算量大致满足工程近似式C ≈ 6ND。其中 6 这个常数来自一次前向约 2 倍参数量 FLOPs一次反向约 4 倍参数量 FLOPs。扩展律告诉我们在计算最优的配置附近数据量 D 和参数量 N 的比例大致会落在一个稳定区间常见经验值约为 D ≈ 20N。于是可以解N ≈ sqrt(C / 120)D ≈ 20N举个例子假设你的算力预算大约是 10 的 23 次方 FLOPs那 N ≈ sqrt(10^23 / 120) ≈ 2.9 × 10^10也就是 29B 参数对应的 D ≈ 580B token。这个配置看起来有点“数据特别多”但这恰恰是扩展律给出的重要提醒在现有常见框架下大模型吃数据的能力远比你想象得大只喂几十亿 token 是远远不够的。当然这个比例不是绝对真理不同任务、不同架构、不同数据质量下会有偏移。但至少它给了你一个可验证的起点。你可以在小规模上先跑几个 10 亿到 30 亿参数的对比实验分别按 10、20、40 的 token/参数比配置数据看哪个组合外推后更符合预期再决定全量训练的比例。3.2 三步定配置预算、曲线、小规模验证第一步把总预算换算成有效 FLOPs。别只看买了多少卡还要乘以预估的模型 FLOPs 利用率。如果当前利用率只有 40%那理论百万卡时也要打六折算。第二步按扩展律解出 N 和 D 的初始值。上面 3.1 的式子是起点实际操作中我会同时准备三组候选配置一组偏参数一组偏数据一组居中。然后用同样的训练步数和学习率在 0.1% 数据量的小规模上快速跑出损失曲线拟合出当前数据的扩展律参数。第三步做一次“外推检查”。把小规模的损失曲线按幂律外推到大预算下的期望损失如果外推结果明显不符合团队的目标指标那就需要回头检查数据质量或目标定位而不是硬着头皮扩大规模。我在一次模拟项目 X 里就是这么干的外推后发现哪怕预算翻三倍期望损失也只会下降几个百分点于是直接把预算砍回了原来的 2/3把多出来的资源拿去做数据清洗最终效果反而更好。3.3 训练中的动态调整别忽略 Batch Size 和学习率扩展律通常会假设超参数已经调到接近最优但现实里很多规模化训练并没有做到这一点。常见问题是模型规模变大训练步数变长但 Batch Size 却还在用原来那一套导致吞吐上不去扩展曲线失真。比较稳的做法是按总计算预算确定训练步数后把 Batch Size 尽量推到“临界批量”附近。所谓临界批量是指在这个批量以上增加批量带来的梯度噪声降低收益开始明显减弱。如果显存允许我倾向于每 5 到 10 次训练涨一次有效批量同时按比例调高学习率。学习率的粗略经验是批量从 B 涨到 kB学习率可以从 lr 调到 sqrt(k) 倍左右而不是线性放大。这样能显著缩短训练步数但不牺牲稳定性。这块最容易翻车的点在于梯度累积。很多分布式训练用梯度累积来模拟大批量却忘了同步学习率缩放和 warmup 策略。结果就是有效批量变大后模型前几步的梯度统计还没稳损失直接飞了。我踩过一次之后每次做配置都会先在一个小模型上重放相同批量、相同学习率策略确认损失曲线平稳了再启动大规模训练。4. 规模化过程中踩过的坑与排查实录4.1 数据重复带来的虚胖我见过一个很典型的案例某团队要把模型从 30 亿扩到 100 亿训练数据也加了但验证损失始终降不下去。后来把训练数据按内容哈希做了重复率统计发现所谓“新数据”里超过三成是旧数据的改写或拼接变体。模型用很大一部分算力在反复学习同一批模式参数规模再大也没有真正接触到新知识。扩展律能测出“规模不够”但测不出“数据污染”。我建议每次规模化前都做三件事第一按句子和文档粒度分别去重第二计算训练集与验证集的 n-gram 重叠度第三检测标签或文本中的异常重复片段。这些检查本身不贵却能避免后面几十万卡时的浪费。如果已经训练到一半才发现数据重复严重也不要立刻销毁 checkpoint。先看重复数据在分批采样中的占比通过调整采样权重把重复部分压下去再继续训练。运气好时模型能在之后几百步里逐步修正回来如果损失已经彻底发散那还是回到最近一次干净 checkpoint重新配数据管线再跑。4.2 训练 Loss 像过山车先查三项规模化训练中Loss 突然飙升是每个人都遇到过的事。我自己的排查顺序是固定的先看是不是某个 batch 里出现了异常数据比如超长序列截断错误、标签错位、数值溢出的特殊 token再看学习率是不是在 batch 增大后没有同步调整最后查混合精度下的 loss scale 是否异常。有一次我们盯着 Loss 曲线发现每过一个固定步数就出现一个尖峰像是有人在背后定时捣乱。后来定位到是数据 pipeline 中某个正则匹配导致一批样本被错误截断喂进模型后产生了极大梯度。这个问题靠看训练日志根本发现不了必须对 checkpoint 里的梯度范数分桶统计一旦发现某个 worker 或某种数据模式的梯度范数持续偏高基本就能锁定问题源。所以在规模化训练里我给团队立的规矩是Loss 曲线不是用来“看”的是用来“触发调查”的。任何连续 10 步损失不降或上升都要停止盲目调参先做根因分析。否则很容易把训练问题归因成“扩展律失效”实际上是工程 bug 在捣乱。4.3 扩展律外推在小规模上会骗人扩展律最吸引人的地方在于你可以在小规模上验证然后外推到大规模。但外推不是无条件的。最容易翻车的三种情况我都见过第一小规模实验的损失还没收敛就开始拟合拿到了虚假的曲线斜率外推结果自然差得离谱。必须每个规模都训练到接近收敛哪怕要点算力换可信度。第二小规模和大规模的数据配比不一致。小实验里网络文本占比 50%放大到全量训练却把书籍类数据提到 70%扩展曲线当然会断崖式变化。第三小规模时超参数没有重新优化。比如学习率在 100M 模型上最优但在 1B 模型上不一定拿同一套超参数拟合外推会严重低估大模型能力。我现在的做法是至少做四个规模点的扫描覆盖目标规模的 1/100 到 1/10每个点都单独调一下学习率和批量然后再做幂律拟合。宁可多烧一点小规模算力也要让外推公式的系数尽量准确。毕竟全量训练一旦启动就不是靠“感觉”就能挽救回来的。5. 规模化之外效率革命与后训练5.1 让效果再涨一截的训练后阶段扩展律主要关心的预训练阶段的损失下降但一个模型真正落地还得看训练后阶段指令微调、偏好对齐、上下文扩展、推理侧优化。这一段做得好不好有时候比预训练多堆 20% 参数更影响实际体验。我常跟朋友说预训练把“知识水位”抬起来后训练决定“水位能不能流到用户嘴边”。同样是损失曲线达标的两个模型一个在微调数据上做了严格去重和难度分层另一个只是把公开指令集随机混合最终人工评测差距可以拉开到肉眼可见。所以做规模化预算时别把全部资源都圈在预训练里要给后训练留出至少两到三轮完整实验的余量。5.2 让算力花得更值的结构设计扩展律还有一个延伸方向通过稀疏激活或专家结构在相同总参数量下降低每个 token 的实际激活计算量。就是说模型总规模很大但推理或训练时只激活其中一部分参数单位 FLOPs 能带来的效果密度更高。这种设计并不是绕过扩展律而是改变扩展律公式里的“有效系数”让同样预算能买到更多能力。这也给团队提了个醒谈规模化不要只盯着“总参数量”还要看“激活参数量”和“总计算量”的组合。两个模型总参数相近一个全部参与计算另一个只激活 30%那么后者在推理成本上明显占优扩展路径也更灵活。我在实际选择架构时会把推理侧的吞吐预算放在与训练预算同等重要的位置因为规模化之后真正烧钱的往往不只是训练还有持续不断的在线服务成本。5.3 别忽视推理侧的规模化红利模型规模化到后期解码批量、缓存策略、量化精度都会显著影响单位成本下的服务能力。一个 100B 模型如果能用 4-bit 量化加高效缓存压到单卡可服务比那个 50B 但只能全精度跑慢速推理的模型反而更有竞争力。扩展律帮我们选定了模型大小但工程上的“压缩扩展律”又是一套完全不同的优化曲线。我个人体会最深的是“效果、速度、成本”三角里模型规模只是最显眼的一项。真正让规模化产生商业价值靠的是整条链路一起扩展。预训练按扩展律算清楚参数和数据的最佳比例后训练把能力引导到真实任务上推理侧再把每一分 FLOPs 都榨干这套组合拳打下来才能让大规模模型不只是“看起来厉害”而是“用得起来”。最后再分享一个实际经验别把扩展律当成万能水晶球它更像一张地图帮你避开“盲目加参数”和“浪费数据”这两个大坑。真正动手时还是要靠小规模实验、严格的数据体检和一次次损失曲线的根因分析来校准方向。模型规模化这条路步子大不大不是第一位的每一步踩得实不实才是。
阅读完成 · 觉得有帮助？
