Scaling Law 这个词这两年在做模型训练的人嘴里出现频率极高但真正动手拟合过曲线的人并不多。我第一次把它当工程工具用是在一个中等规模预训练项目上手里只有一小块算力预算会上被问的不是“讲讲幂律”而是“参数翻一倍loss 能降多少这笔钱值不值”。那一刻我才明白Scaling Law 解析的核心不是背公式而是回答资源分配的边际收益问题。它本质上是一组描述模型损失随参数量、训练数据量、计算量变化的经验规律能帮你在动手之前估算投入产出适合做预训练规划、算力预算审批、模型选型也适合刚接触大模型训练、想搞明白“为什么大家都在堆规模”的工程师。下面我按自己踩过的顺序把这套东西拆开讲。1. 先把 Scaling Law 到底是什么说清楚1.1 它不是一个公式而是一组可检验的工程假设很多人把 Scaling Law 理解成一条“参数越大loss越低”的曲线这个理解不算错但太粗。更准确地说它是一组带参数的函数形式用来描述验证集损失如何随模型参数量、训练 token 数、计算量变化。最常见的写法是把损失拆成三块一块是不可约损失也就是在当前数据分布和任务定义下任何模型都降不下去的下限一块是参数不足带来的损失一块是数据不足带来的损失。三块叠加才构成你观测到的总损失。这个拆法很重要因为如果你只盯总损失很容易把数据不够导致的欠训练误判成参数不够。我习惯用一个做菜的类比来解释锅的大小相当于参数量食材总量相当于训练 token 数火候和时间相当于计算量。锅再大食材不够做出来的菜量还是上不去食材再多锅太小也装不下。不可约损失则像菜谱本身的上限你换再好的锅也突破不了菜谱定义的天花板。这个类比不严谨但它能帮你记住一件事三个自变量是耦合的不能单独看。还有一点必须强调Scaling Law 是经验规律不是物理定律。它的系数依赖数据分布、模型结构、优化器、学习率调度、序列长度甚至依赖你用什么 tokenizer。换一套数据管线指数可能就变了。所以我在项目里从来不直接套别人论文里的系数最多拿它当初始猜测然后用自己的小规模扫参重新校准。这一点后面会展开讲因为它是踩坑最多的地方。1.2 三个自变量和它们之间的耦合关系参数量 N、训练 token 数 D、计算量 C这三个量不是独立的。对于标准的稠密 Transformer 类结构一次前向传播的计算量大约是 2ND反向传播大约是 4ND合起来训练一个 token 大约需要 6ND 次浮点运算。这个 6 不是精确值它忽略了注意力机制里随序列长度增长的部分也忽略了激活重计算、通信开销等工程因素但在做预算估算时足够用。记住这个关系你才能在“给定算力”的条件下反推参数和数据的配比。耦合关系体现在两个方向。第一个方向是参数涨了、数据不涨模型会进入欠训练状态表现是训练损失还能降但验证损失提前抬头或者验证损失降得越来越慢。第二个方向是数据涨了、参数不涨模型容量不够多出来的数据只能被反复咀嚼收益迅速衰减。我见过一个项目数据量翻了四倍参数没动最后验证损失只降了不到百分之二团队一度以为是数据清洗出了问题其实是模型容量已经饱和。还有一个容易被忽略的耦合项是序列长度。同样叫“一个 token”在长上下文任务里注意力计算占比会显著上升6ND 这个近似会偏乐观。如果你的项目涉及长文档、代码仓库级别的输入做算力预算时要把这部分额外开销单独留出来否则你会发现自己算出来的训练步数根本跑不完。我的做法是在小规模扫参阶段就记录实际吞吐用实测的 tokens per second 反推有效计算量而不是纯靠公式拍脑袋。1.3 为什么是幂律冗余容量与高维拟合的直觉损失随规模下降呈现幂律也就是在对数坐标下近似一条直线这件事一开始让我很意外。直觉上规模翻倍损失应该线性下降才对为什么是幂律一个比较能被工程直觉接受的解释是模型要拟合的目标可以看成大量难度不同的子模式的集合。容量增加时模型先覆盖容易的模式再覆盖难的模式。每增加一单位容量能新覆盖的模式数量在减少但不会突然归零于是边际收益递减形成幂律而不是指数衰减。另一个角度是冗余。大模型并不是每一个参数都在干有用的活相当一部分容量被用来做冗余表示、特征组合和误差平滑。规模越大冗余带来的平滑效应越明显损失下降越稳定。这也解释了一个现象在小模型上做架构微调效果波动很大到了大模型上同样的微调可能被淹没在冗余里收益变得不明显。幂律描述的是这种统计意义上的平均行为它对单个模型、单次训练的预测能力有限对一类模型、一个规模区间的趋势预测才有意义。所以我在做 Scaling Law 解析时会反复提醒自己不要拿它预测某一次训练的精确 loss而是拿它判断“往哪个方向加资源更划算”。这两件事的精度要求完全不同。前者要求你的拟合误差控制在几个百分点以内后者只需要你知道指数大概是多少、哪个自变量更值得加。搞清楚这个定位后面很多争论其实可以避免。2. 规模定律的两次关键修正与选型逻辑2.1 早期版本参数优先的代价最早一批规模定律研究给出的结论大致是参数量的指数明显大于数据量的指数。翻译成工程语言就是在固定算力下应该把更多预算砸给参数数据可以少一点。这个结论在当时有其合理性因为早期模型的训练数据确实有限很多团队的数据量还没有成为瓶颈。但把它当成通用配方就会出问题。参数优先的直接代价是模型欠训练。你有一个很大的参数容器但只灌了很少的数据模型没有充分见过足够的语言现象验证损失降不到它应有的水平。更麻烦的是这种欠训练在训练曲线上不一定明显因为训练损失还在降团队容易误以为“再训久一点就好了”。实际上你需要的是更多数据而不是更多步数。另一个代价是推理成本。参数越大单次前向的计算和显存占用越高上线之后的持续成本会吃掉训练阶段省下来的钱。我见过一个团队按早期配比训了一个参数偏大的模型训练阶段确实省了数据清洗的功夫但上线后推理成本比预期高了近一倍最后不得不重新蒸馏一个小模型来兜底。下面这张表是我自己整理的一个粗略对照用来提醒自己早期配比和修正配比的差异。表中的指数是示意值不是精确结论实际项目必须用自己的数据重新拟合。对比项早期参数优先配比修正后的均衡配比参数量随算力增长指数约 0.7 量级约 0.5 量级数据量随算力增长指数约 0.3 量级约 0.5 量级典型 token 参数比明显偏低约 20 比 1 起步主要风险欠训练、推理贵数据质量要求高适用场景数据极度受限数据可扩充的常规预训练这张表的价值不在于数字本身而在于提醒你配比不是固定真理它随数据可得性变化。如果你手里的高质量数据非常有限适当偏向参数并不是错如果你能持续产出高质量 token均衡配比通常更划算。2.2 修正版本参数与数据要同步放大后续的修正研究做了一个更系统的扫参在更大的规模范围内用统一的学习率调度和数据管线重新拟合参数和数据各自的指数。结论是在计算最优的约束下参数量和数据量应该大致等比例增长也就是两者随算力的增长指数都在 0.5 附近。工程上最常被引用的经验值是每个参数配大约 20 个训练 token。这个数字不是魔法它是在特定数据分布、特定模型结构下拟合出来的一个平衡点但它作为一个起点非常好用。为什么早期会偏我自己的理解是三个原因叠加。第一早期研究的规模点跨度不够大外推时指数容易被小规模段的局部行为带偏。第二学习率调度没有随规模做充分匹配小模型在固定步数下更容易收敛大模型反而欠训练导致拟合出来的参数收益被高估。第三数据质量差异没有被单独控制不同规模用了不同质量的数据指数自然失真。这三点在后来都被逐项修正所以修正版的结论更可信但也更依赖你把实验条件控制干净。我在项目里的做法是先用 20 比 1 作为初始配比做一轮小规模验证然后在这个配比附近做两三个点的扰动比如 15 比 1 和 30 比 1看验证损失对配比的敏感度。如果曲线在 20 比 1 附近很平说明你的数据质量和模型结构对这个配比不敏感可以放心放大如果曲线很陡说明你的场景有特殊性必须重新拟合。这个扰动实验的成本很低但能避免你在放大阶段犯大错。2.3 计算最优边界怎么算给定算力下的配比推导把上面的关系落成可计算的公式其实不复杂。假设总计算量 C 约等于 6ND再假设最优配比满足 D 等于 k 倍的 N那么 C 约等于 6k 乘以 N 的平方。给定 C 和 k就能反解出 N 和 D。这个过程我在预算会上用过很多次比拍脑袋靠谱得多。举几个具体数字。取 k 等于 20也就是每个参数配 20 个 token那么 C 约等于 120 乘以 N 的平方。当 C 等于 1e21 时N 约等于 2.9e9D 约等于 5.8e10当 C 等于 1e22 时N 约等于 9.1e9D 约等于 1.8e11当 C 等于 1e23 时N 约等于 2.9e10D 约等于 5.8e11。把这些数放进表里你能直观看到算力每涨一个数量级参数和数据各自涨约 3.16 倍也就是根号十。总计算量 CFLOPs估算参数量 N估算训练 token 数 D备注1e21约 2.9e9约 5.8e10中等规模预训练1e22约 9.1e9约 1.8e11需要稳定数据管线1e23约 2.9e10约 5.8e11通信与存储压力明显这张表只解决了“理论配比”没有解决“实际能不能跑完”。真实项目里你还要把训练吞吐、集群利用率、故障恢复开销算进去。我的经验是理论算力打七折到八折作为实际可用预算比较稳妥尤其是规模上去之后通信和重试的损耗不可忽略。另外k 值不是永远取 20如果你的数据质量很高、去重很彻底可以适当调高如果数据重复率高、质量参差调高 k 反而会放大噪声这时候更应该先修数据而不是继续加 token。3. 手把手做一次规模定律拟合3.1 网格设计小模型扫参怎么扫才不白扫拟合的第一步不是写代码是设计扫参网格。我的基本原则是规模点至少五个跨度至少两个数量级每个规模点上至少两个不同的 token 参数比。跨度太小指数拟合会非常不稳定点太少异常点会把整条曲线带偏。举个例子参数量可以从几百万到几亿取 1M、3M、10M、30M、100M 五个点每个点跑 20 比 1 和 50 比 1 两个配比这样你既有跨规模的趋势也有配比方向的敏感度。控制变量比堆点更重要。所有规模点必须用同一套数据、同一个 tokenizer、同一套模型结构、同一套优化器配置。学习率可以随规模调整但调整规则要固定比如按参数量的平方根反比缩放或者每个规模单独做一个小范围学习率扫描后取最优。如果你让小模型用调好的学习率、大模型用默认学习率拟合出来的指数基本没有参考价值。我踩过这个坑一轮扫参里大模型忘了改 warmup 比例结果大模型的损失异常高拟合出来的参数指数偏小差点得出“参数不重要”的错误结论。成本控制方面小模型扫参不需要跑满完整训练。你可以用较短的序列长度、较小的批量、较少的步数只要保证每个规模点都训练到损失曲线明显变平。判断“变平”的方法是看最近若干步的验证损失滑动平均变化小于某个阈值就停。这个阈值要提前定好不能看到结果再调。我的习惯是验证损失在最后百分之十的步数内下降不超过千分之五就算收敛。这个标准不严格但足够支撑趋势判断。3.2 损失曲线清洗不可约损失剥离与异常点处理原始损失曲线不能直接拿来拟合必须先清洗。第一件事是区分训练损失和验证损失。训练损失会被记忆效应污染尤其是小模型在少量数据上反复训练时训练损失可以降得很低但验证损失早就平了。拟合一律用验证损失而且要确保验证集和训练集没有重叠、没有同源污染。第二件事是处理异常点。训练过程中出现损失尖峰、发散后恢复、学习率重启这些都会在曲线上留下毛刺。我的做法是对最后一段做滑动平均取中位数而不是均值避免尖峰拉高。如果某个规模点整体发散不要试图修补直接重跑因为发散往往意味着超参不匹配修补后的数据会污染拟合。第三件事是确定收敛值。学习率没有衰减到接近零时损失还没有完全收敛直接取最后一个点会高估损失。我通常让学习率衰减到峰值的百分之一以下再取最后若干步的中位数作为该点的收敛损失。如果算力不够至少要让余弦衰减走完大部分周期。这一点在小模型上尤其重要因为小模型收敛快学习率调度没走完就停损失会明显偏高导致你低估小模型的效率进而高估大模型的相对收益。不可约损失的处理有两种方式。一种是把不可约损失作为拟合参数和数据项、参数项一起拟合另一种是用一个足够大的模型在足够多的数据上估计一个下限然后固定住。前者更省事但要求你的规模点跨度足够大否则不可约损失和参数项容易混淆后者更稳但需要额外的大规模实验。我在预算有限时通常用前者但会检查拟合出来的不可约损失是否落在合理区间如果它接近甚至超过最小规模点的损失说明数据有问题拟合不可信。3.3 拟合代码最小二乘与对数空间拟合本身不复杂核心是最小化预测损失和观测损失之间的相对误差。下面这段代码是我常用的模板用 Python 写依赖 numpy 和 scipy。它的做法是把不可约损失、参数项系数、参数项指数、数据项系数、数据项指数一起作为待拟合参数在对数空间里构造残差然后用鲁棒最小二乘求解。import numpy as np from scipy.optimize import least_squares # 观测数据参数量 N、token 数 D、验证损失 L N_obs np.array([1e6, 3e6, 1e7, 3e7, 1e8]) D_obs np.array([2e7, 6e7, 2e8, 6e8, 2e9]) L_obs np.array([3.42, 3.18, 2.95, 2.76, 2.58]) def predict(params, N, D): E, A, alpha, B, beta params return E A / np.power(N, alpha) B / np.power(D, beta) def residual(params, N, D, L): pred predict(params, N, D) # 用相对误差避免大损失点主导拟合 return (pred - L) / L # 初始猜测不可约损失取最小观测损失的八成指数从 0.3 起步 x0 np.array([2.0, 1.0, 0.3, 1.0, 0.3]) bounds ( [0.0, 0.0, 0.01, 0.0, 0.01], [np.min(L_obs), np.inf, 1.5, np.inf, 1.5] ) result least_squares( residual, x0, args(N_obs, D_obs, L_obs), boundsbounds, losssoft_l1, max_nfev20000 ) E, A, alpha, B, beta result.x print(f不可约损失 E {E:.4f}) print(f参数项 A {A:.4f}, 指数 alpha {alpha:.4f}) print(f数据项 B {B:.4f}, 指数 beta {beta:.4f}) # 留一验证用前四个点拟合预测第五个点 train_idx [0, 1, 2, 3] test_idx [4] res_train least_squares( residual, x0, args(N_obs[train_idx], D_obs[train_idx], L_obs[train_idx]), boundsbounds, losssoft_l1, max_nfev20000 ) pred_last predict(res_train.x, N_obs[test_idx], D_obs[test_idx]) print(f留一点预测损失 {pred_last[0]:.4f}, 实际 {L_obs[test_idx][0]:.4f})这段代码有几个细节值得说。第一用相对误差而不是绝对误差是因为大规模点的损失绝对值小绝对误差会让小规模点主导拟合指数被带偏。第二用 soft_l1 而不是默认的线性损失是为了降低异常点的权重一两个毛刺不至于把整条曲线拉歪。第三给指数加了上界 1.5防止拟合跑到不合理的区域比如指数大于一意味着规模翻倍损失腰斩这在实践中几乎不会出现。第四留一验证很重要它比拟合优度更能说明模型能不能外推。拟合结果怎么读先看不可约损失是否合理。它应该低于你最小规模点的损失但又不能低到离谱。再看两个指数。如果参数指数明显大于数据指数说明在你的实验条件下加参数比加数据划算反之则说明数据是瓶颈。最后看留一验证的误差如果预测值和实际值差在百分之五以内这条曲线可以用来做同分布的外推如果差得远不要硬用先检查实验条件是否一致。3.4 外推验证留一个最大点不参与拟合外推验证是整套流程里最容易被跳过、也最不该跳过的一步。我的做法是永远留一个最大规模点不参与拟合用它来检验曲线。这个点最好比参与拟合的最大点大一个数量级左右这样你能看出曲线在跨数量级时是否还站得住。如果留出点的预测误差在百分之五到百分之十以内我会认为这条曲线可以用于同架构、同数据分布的预算估算如果误差超过百分之十五我会把它标记为“仅供方向参考”不拿它做精确决策。外推误差的来源通常有三类。第一类是优化不充分最大规模点没有训到收敛实际损失偏高而曲线是按收敛趋势外推的自然对不上。第二类是数据重复大规模点用了更多 epoch有效数据量没有名义上那么多损失下降不及预期。第三类是架构或超参在大规模时发生了变化比如为了省显存换了激活重计算、为了稳定训练调了初始化这些都会让曲线断裂。排查时按这个顺序查基本能定位到原因。还有一个经验判断如果你只能用小于一个数量级的跨度做拟合外推结果的可信度会大幅下降。我一般要求参与拟合的规模跨度至少两个数量级留出点再跨一个数量级。达不到这个条件时我会明确告诉决策方“这是趋势估计不是预算承诺”。这句话听起来保守但能避免后面很多扯皮。毕竟 Scaling Law 解析的价值是帮你排序方案不是替你做最终决定。4. 实操中最容易踩的坑与排查表4.1 数据质量会直接改写指数同样叫一亿个 token去重前后、质量过滤前后有效信息量可能差出一大截。低质数据、模板化文本、重复段落会让模型把容量浪费在记忆上验证损失下降变慢拟合出来的数据指数偏低。你以为是“数据不重要”其实是“这批数据不值得学”。我在一个项目里做过对比同一套模型、同一个 token 数清洗后的数据让验证损失多降了将近百分之八拟合出来的数据指数从 0.22 变成了 0.31。这个差距足以改变配比决策。所以做扫参之前先把数据管线固定下来并且记录版本。扫参过程中不要换清洗规则、不要换去重阈值、不要中途补充新数据源。如果非要换所有规模点一起重跑否则你拟合的是数据差异不是规模差异。另一个细节是验证集的构造。验证集要从训练数据同分布里留出但不能和训练数据有重叠也不能用训练时过滤掉的低质数据充当验证集否则验证损失会虚低曲线整体下移指数反而看起来更漂亮这是典型的自欺欺人。4.2 学习率与批量带来的假 Scaling学习率是假 Scaling 的重灾区。小模型用偏大的学习率收敛快但最终损失偏高大模型用同样的学习率可能训练不稳定或者收敛不足。两种偏差方向相反叠在一起会让拟合指数失真。我的做法是给每个规模点单独做一个小范围学习率扫描取验证损失最低的那个然后记录下最优学习率和规模的关系。如果关系大致符合平方根反比说明你的扫描是自洽的如果关系乱七八糟说明还有别的变量没控制住。批量大小也一样。小模型在小批量下更新步数多收敛快大模型如果批量放大不够梯度噪声大损失曲线会更抖。反过来批量放得太大学习率没跟上训练会变慢。比较稳妥的做法是让批量随规模适度增长同时保证每个规模点的训练 token 总数和更新步数在合理范围。还有一个容易忽略的点是序列长度。小模型用短序列、大模型用长序列注意力开销占比不同实际计算量和你按 6ND 估算的值会偏离。扫参时尽量统一序列长度或者至少记录下实际吞吐用实测值校正计算量。4.3 下游任务与 loss 脱钩验证损失降了下游任务不涨这种事我遇到过不止一次。原因通常有三类。第一类是任务饱和你的评测集太简单模型早就到顶了loss 再降也反映不到准确率上。第二类是评测污染训练数据里混进了评测集的原题或近似改写loss 降的是记忆不是能力。第三类是格式不匹配模型学会了语言分布但没有学会你评测时要求的输出格式导致自动打分偏低。这三类的排查方法不同但共同点是不能只看 loss必须有一组自己构造的、训练时严格隔离的评测。我通常会留一组“金丝雀”评测规模不大但题目是手工构造的确保没有泄漏。每次扫参都跑一遍观察 loss 和评测分数的相关性。如果某个规模点上 loss 降了但金丝雀分数不动我会先怀疑数据或评测而不是急着下结论说“规模没用”。还有一种情况是能力跳变某个规模之后下游分数突然抬升这在文献里被讨论很多但在工程上要谨慎对待跳变可能是真实的也可能是评测阈值效应也就是模型刚好越过了某个打分边界。判断方法是换一组同难度但不同形式的题目再测如果跳变复现可信度就高很多。4.4 常见问题速查表下面这张表是我自己整理的排查清单按现象查原因能省不少时间。表中的“优先动作”是我个人的习惯顺序不一定适用于所有团队但方向大致通用。现象可能原因优先动作拟合出的参数指数异常大小模型欠训练、大模型超参不匹配检查每个规模点的收敛情况与学习率拟合出的数据指数异常小数据重复、质量差、验证集泄漏去重、质量过滤、重建验证集留出点预测误差超过百分之十五外推跨度不足、优化未收敛增加规模点、延长训练、检查数据 epochloss 降但下游不涨任务饱和、评测污染、格式不匹配换评测集、查泄漏、人工抽查输出曲线在小规模段很陡、大规模段变平不可约损失估计偏低、数据瓶颈放宽不可约损失边界、增加数据配比点不同批次实验结果抖动大数据顺序、初始化、硬件差异固定随机种子、记录数据顺序、多跑几次取中位数这张表不能替代具体分析但它能帮你快速排除低级错误。我的经验是八成以上的拟合异常都能在前三行里找到原因剩下的两成通常和工程环境有关比如不同规模跑在不同型号的机器上浮点精度或通信策略不一样导致数值行为有差异。遇到这种情况先把环境对齐再谈拟合。5. 从训练到推理规模定律的延伸用法5.1 推理成本 scaling什么规模值得上线训练成本是一次性的推理成本是持续的。参数量翻倍单次前向的计算量大致翻倍显存占用也翻倍但请求量大的时候推理成本会迅速超过训练成本。所以做规模决策时不能只看“这个规模 loss 更低”还要看“这个 loss 优势值不值推理溢价”。我的做法是算一个简单的盈亏平衡给定日均请求量和单 token 推理成本算出大模型相对小模型每年多花的推理费用再对比它在业务指标上带来的提升。如果提升带来的收益覆盖不了溢价就应该选小模型或者用蒸馏、量化把大模型的能力压到小模型里。这里有个容易混淆的点总参数量和激活参数量不是一回事。稀疏结构的总参数可以很大但每次前向只激活一部分推理成本按激活参数算。做预算时一定要区分这两个数否则你会把推理成本高估好几倍。另外长上下文会显著推高推理成本因为注意力计算随序列长度增长。如果你的业务输入很长参数量的边际影响会被摊薄这时候更值得优化的是上下文压缩和缓存策略而不是继续抠参数规模。5.2 数据重复与多 epoch 的收益衰减扫参时经常遇到数据不够只能重复训练。重复数据不是完全没用但有效数据量要打折。我的经验是前几个 epoch 的收益接近新数据之后衰减很快超过一定次数后基本只剩记忆效应。具体折扣系数因数据而异去重彻底、多样性高的数据折扣来得慢一些模板化严重的数据第二个 epoch 就开始明显衰减。拟合时如果忽略这一点你会把“重复带来的 loss 下降”误判成“规模带来的收益”外推到大模型上就会高估。处理方法有两种。一种是在拟合时把名义 token 数换成有效 token 数有效 token 数等于唯一 token 数加上重复部分的折扣另一种是干脆在扫参阶段控制每个规模点的 epoch 数一致避免重复度差异污染指数。我倾向于后者因为它更干净代价是需要准备足够多的唯一数据。如果实在做不到至少要在记录里标明每个点的 epoch 数外推时手动打折。这个细节不起眼但在预算紧张、数据有限的团队里它经常是拟合失真的主因。5.3 外推边界与定律失效的信号Scaling Law 不是万能钥匙它在某些条件下会明显失效。我总结了几类信号出现任意一类就不要直接套旧系数。第一类是架构大改比如从稠密换成稀疏、引入新的注意力机制、改变归一化位置这些会改变参数效率和数据效率旧指数不再适用。第二类是数据分布大改比如从通用文本切到垂直领域、从单语切到多语不可约损失和指数都会变。第三类是训练精度或优化器大改混合精度策略、优化器状态、梯度裁剪阈值的变动都会影响收敛行为。第四类是序列长度跨数量级长上下文带来的计算结构变化会让 6ND 近似偏离。遇到这些情况我的做法是重新做一轮小规模校准哪怕只跑三四个点也比直接套旧系数强。校准的目的不是追求精确而是确认指数没有发生方向性变化。如果新拟合的指数和旧系数差得不多可以继续用旧曲线做粗略估算如果差得多就以新数据为准。还有一点不要拿别人的系数直接用哪怕架构相同。数据管线、tokenizer、训练框架的差异足以让指数偏移百分之十以上而这个偏移在预算决策里可能就是几倍的资源差异。Scaling Law 解析说到底是一种本地化知识你得用自己的实验把它养出来。 
长河君 · 2026/10/26 2:59:44 · 阅读 1.2k Scaling Law工程实战：算力预算、曲线拟合与外推验证
Scaling Law 这个词这两年在做模型训练的人嘴里出现频率极高但真正动手拟合过曲线的人并不多。我第一次把它当工程工具用是在一个中等规模预训练项目上手里只有一小块算力预算会上被问的不是“讲讲幂律”而是“参数翻一倍loss 能降多少这笔钱值不值”。那一刻我才明白Scaling Law 解析的核心不是背公式而是回答资源分配的边际收益问题。它本质上是一组描述模型损失随参数量、训练数据量、计算量变化的经验规律能帮你在动手之前估算投入产出适合做预训练规划、算力预算审批、模型选型也适合刚接触大模型训练、想搞明白“为什么大家都在堆规模”的工程师。下面我按自己踩过的顺序把这套东西拆开讲。1. 先把 Scaling Law 到底是什么说清楚1.1 它不是一个公式而是一组可检验的工程假设很多人把 Scaling Law 理解成一条“参数越大loss越低”的曲线这个理解不算错但太粗。更准确地说它是一组带参数的函数形式用来描述验证集损失如何随模型参数量、训练 token 数、计算量变化。最常见的写法是把损失拆成三块一块是不可约损失也就是在当前数据分布和任务定义下任何模型都降不下去的下限一块是参数不足带来的损失一块是数据不足带来的损失。三块叠加才构成你观测到的总损失。这个拆法很重要因为如果你只盯总损失很容易把数据不够导致的欠训练误判成参数不够。我习惯用一个做菜的类比来解释锅的大小相当于参数量食材总量相当于训练 token 数火候和时间相当于计算量。锅再大食材不够做出来的菜量还是上不去食材再多锅太小也装不下。不可约损失则像菜谱本身的上限你换再好的锅也突破不了菜谱定义的天花板。这个类比不严谨但它能帮你记住一件事三个自变量是耦合的不能单独看。还有一点必须强调Scaling Law 是经验规律不是物理定律。它的系数依赖数据分布、模型结构、优化器、学习率调度、序列长度甚至依赖你用什么 tokenizer。换一套数据管线指数可能就变了。所以我在项目里从来不直接套别人论文里的系数最多拿它当初始猜测然后用自己的小规模扫参重新校准。这一点后面会展开讲因为它是踩坑最多的地方。1.2 三个自变量和它们之间的耦合关系参数量 N、训练 token 数 D、计算量 C这三个量不是独立的。对于标准的稠密 Transformer 类结构一次前向传播的计算量大约是 2ND反向传播大约是 4ND合起来训练一个 token 大约需要 6ND 次浮点运算。这个 6 不是精确值它忽略了注意力机制里随序列长度增长的部分也忽略了激活重计算、通信开销等工程因素但在做预算估算时足够用。记住这个关系你才能在“给定算力”的条件下反推参数和数据的配比。耦合关系体现在两个方向。第一个方向是参数涨了、数据不涨模型会进入欠训练状态表现是训练损失还能降但验证损失提前抬头或者验证损失降得越来越慢。第二个方向是数据涨了、参数不涨模型容量不够多出来的数据只能被反复咀嚼收益迅速衰减。我见过一个项目数据量翻了四倍参数没动最后验证损失只降了不到百分之二团队一度以为是数据清洗出了问题其实是模型容量已经饱和。还有一个容易被忽略的耦合项是序列长度。同样叫“一个 token”在长上下文任务里注意力计算占比会显著上升6ND 这个近似会偏乐观。如果你的项目涉及长文档、代码仓库级别的输入做算力预算时要把这部分额外开销单独留出来否则你会发现自己算出来的训练步数根本跑不完。我的做法是在小规模扫参阶段就记录实际吞吐用实测的 tokens per second 反推有效计算量而不是纯靠公式拍脑袋。1.3 为什么是幂律冗余容量与高维拟合的直觉损失随规模下降呈现幂律也就是在对数坐标下近似一条直线这件事一开始让我很意外。直觉上规模翻倍损失应该线性下降才对为什么是幂律一个比较能被工程直觉接受的解释是模型要拟合的目标可以看成大量难度不同的子模式的集合。容量增加时模型先覆盖容易的模式再覆盖难的模式。每增加一单位容量能新覆盖的模式数量在减少但不会突然归零于是边际收益递减形成幂律而不是指数衰减。另一个角度是冗余。大模型并不是每一个参数都在干有用的活相当一部分容量被用来做冗余表示、特征组合和误差平滑。规模越大冗余带来的平滑效应越明显损失下降越稳定。这也解释了一个现象在小模型上做架构微调效果波动很大到了大模型上同样的微调可能被淹没在冗余里收益变得不明显。幂律描述的是这种统计意义上的平均行为它对单个模型、单次训练的预测能力有限对一类模型、一个规模区间的趋势预测才有意义。所以我在做 Scaling Law 解析时会反复提醒自己不要拿它预测某一次训练的精确 loss而是拿它判断“往哪个方向加资源更划算”。这两件事的精度要求完全不同。前者要求你的拟合误差控制在几个百分点以内后者只需要你知道指数大概是多少、哪个自变量更值得加。搞清楚这个定位后面很多争论其实可以避免。2. 规模定律的两次关键修正与选型逻辑2.1 早期版本参数优先的代价最早一批规模定律研究给出的结论大致是参数量的指数明显大于数据量的指数。翻译成工程语言就是在固定算力下应该把更多预算砸给参数数据可以少一点。这个结论在当时有其合理性因为早期模型的训练数据确实有限很多团队的数据量还没有成为瓶颈。但把它当成通用配方就会出问题。参数优先的直接代价是模型欠训练。你有一个很大的参数容器但只灌了很少的数据模型没有充分见过足够的语言现象验证损失降不到它应有的水平。更麻烦的是这种欠训练在训练曲线上不一定明显因为训练损失还在降团队容易误以为“再训久一点就好了”。实际上你需要的是更多数据而不是更多步数。另一个代价是推理成本。参数越大单次前向的计算和显存占用越高上线之后的持续成本会吃掉训练阶段省下来的钱。我见过一个团队按早期配比训了一个参数偏大的模型训练阶段确实省了数据清洗的功夫但上线后推理成本比预期高了近一倍最后不得不重新蒸馏一个小模型来兜底。下面这张表是我自己整理的一个粗略对照用来提醒自己早期配比和修正配比的差异。表中的指数是示意值不是精确结论实际项目必须用自己的数据重新拟合。对比项早期参数优先配比修正后的均衡配比参数量随算力增长指数约 0.7 量级约 0.5 量级数据量随算力增长指数约 0.3 量级约 0.5 量级典型 token 参数比明显偏低约 20 比 1 起步主要风险欠训练、推理贵数据质量要求高适用场景数据极度受限数据可扩充的常规预训练这张表的价值不在于数字本身而在于提醒你配比不是固定真理它随数据可得性变化。如果你手里的高质量数据非常有限适当偏向参数并不是错如果你能持续产出高质量 token均衡配比通常更划算。2.2 修正版本参数与数据要同步放大后续的修正研究做了一个更系统的扫参在更大的规模范围内用统一的学习率调度和数据管线重新拟合参数和数据各自的指数。结论是在计算最优的约束下参数量和数据量应该大致等比例增长也就是两者随算力的增长指数都在 0.5 附近。工程上最常被引用的经验值是每个参数配大约 20 个训练 token。这个数字不是魔法它是在特定数据分布、特定模型结构下拟合出来的一个平衡点但它作为一个起点非常好用。为什么早期会偏我自己的理解是三个原因叠加。第一早期研究的规模点跨度不够大外推时指数容易被小规模段的局部行为带偏。第二学习率调度没有随规模做充分匹配小模型在固定步数下更容易收敛大模型反而欠训练导致拟合出来的参数收益被高估。第三数据质量差异没有被单独控制不同规模用了不同质量的数据指数自然失真。这三点在后来都被逐项修正所以修正版的结论更可信但也更依赖你把实验条件控制干净。我在项目里的做法是先用 20 比 1 作为初始配比做一轮小规模验证然后在这个配比附近做两三个点的扰动比如 15 比 1 和 30 比 1看验证损失对配比的敏感度。如果曲线在 20 比 1 附近很平说明你的数据质量和模型结构对这个配比不敏感可以放心放大如果曲线很陡说明你的场景有特殊性必须重新拟合。这个扰动实验的成本很低但能避免你在放大阶段犯大错。2.3 计算最优边界怎么算给定算力下的配比推导把上面的关系落成可计算的公式其实不复杂。假设总计算量 C 约等于 6ND再假设最优配比满足 D 等于 k 倍的 N那么 C 约等于 6k 乘以 N 的平方。给定 C 和 k就能反解出 N 和 D。这个过程我在预算会上用过很多次比拍脑袋靠谱得多。举几个具体数字。取 k 等于 20也就是每个参数配 20 个 token那么 C 约等于 120 乘以 N 的平方。当 C 等于 1e21 时N 约等于 2.9e9D 约等于 5.8e10当 C 等于 1e22 时N 约等于 9.1e9D 约等于 1.8e11当 C 等于 1e23 时N 约等于 2.9e10D 约等于 5.8e11。把这些数放进表里你能直观看到算力每涨一个数量级参数和数据各自涨约 3.16 倍也就是根号十。总计算量 CFLOPs估算参数量 N估算训练 token 数 D备注1e21约 2.9e9约 5.8e10中等规模预训练1e22约 9.1e9约 1.8e11需要稳定数据管线1e23约 2.9e10约 5.8e11通信与存储压力明显这张表只解决了“理论配比”没有解决“实际能不能跑完”。真实项目里你还要把训练吞吐、集群利用率、故障恢复开销算进去。我的经验是理论算力打七折到八折作为实际可用预算比较稳妥尤其是规模上去之后通信和重试的损耗不可忽略。另外k 值不是永远取 20如果你的数据质量很高、去重很彻底可以适当调高如果数据重复率高、质量参差调高 k 反而会放大噪声这时候更应该先修数据而不是继续加 token。3. 手把手做一次规模定律拟合3.1 网格设计小模型扫参怎么扫才不白扫拟合的第一步不是写代码是设计扫参网格。我的基本原则是规模点至少五个跨度至少两个数量级每个规模点上至少两个不同的 token 参数比。跨度太小指数拟合会非常不稳定点太少异常点会把整条曲线带偏。举个例子参数量可以从几百万到几亿取 1M、3M、10M、30M、100M 五个点每个点跑 20 比 1 和 50 比 1 两个配比这样你既有跨规模的趋势也有配比方向的敏感度。控制变量比堆点更重要。所有规模点必须用同一套数据、同一个 tokenizer、同一套模型结构、同一套优化器配置。学习率可以随规模调整但调整规则要固定比如按参数量的平方根反比缩放或者每个规模单独做一个小范围学习率扫描后取最优。如果你让小模型用调好的学习率、大模型用默认学习率拟合出来的指数基本没有参考价值。我踩过这个坑一轮扫参里大模型忘了改 warmup 比例结果大模型的损失异常高拟合出来的参数指数偏小差点得出“参数不重要”的错误结论。成本控制方面小模型扫参不需要跑满完整训练。你可以用较短的序列长度、较小的批量、较少的步数只要保证每个规模点都训练到损失曲线明显变平。判断“变平”的方法是看最近若干步的验证损失滑动平均变化小于某个阈值就停。这个阈值要提前定好不能看到结果再调。我的习惯是验证损失在最后百分之十的步数内下降不超过千分之五就算收敛。这个标准不严格但足够支撑趋势判断。3.2 损失曲线清洗不可约损失剥离与异常点处理原始损失曲线不能直接拿来拟合必须先清洗。第一件事是区分训练损失和验证损失。训练损失会被记忆效应污染尤其是小模型在少量数据上反复训练时训练损失可以降得很低但验证损失早就平了。拟合一律用验证损失而且要确保验证集和训练集没有重叠、没有同源污染。第二件事是处理异常点。训练过程中出现损失尖峰、发散后恢复、学习率重启这些都会在曲线上留下毛刺。我的做法是对最后一段做滑动平均取中位数而不是均值避免尖峰拉高。如果某个规模点整体发散不要试图修补直接重跑因为发散往往意味着超参不匹配修补后的数据会污染拟合。第三件事是确定收敛值。学习率没有衰减到接近零时损失还没有完全收敛直接取最后一个点会高估损失。我通常让学习率衰减到峰值的百分之一以下再取最后若干步的中位数作为该点的收敛损失。如果算力不够至少要让余弦衰减走完大部分周期。这一点在小模型上尤其重要因为小模型收敛快学习率调度没走完就停损失会明显偏高导致你低估小模型的效率进而高估大模型的相对收益。不可约损失的处理有两种方式。一种是把不可约损失作为拟合参数和数据项、参数项一起拟合另一种是用一个足够大的模型在足够多的数据上估计一个下限然后固定住。前者更省事但要求你的规模点跨度足够大否则不可约损失和参数项容易混淆后者更稳但需要额外的大规模实验。我在预算有限时通常用前者但会检查拟合出来的不可约损失是否落在合理区间如果它接近甚至超过最小规模点的损失说明数据有问题拟合不可信。3.3 拟合代码最小二乘与对数空间拟合本身不复杂核心是最小化预测损失和观测损失之间的相对误差。下面这段代码是我常用的模板用 Python 写依赖 numpy 和 scipy。它的做法是把不可约损失、参数项系数、参数项指数、数据项系数、数据项指数一起作为待拟合参数在对数空间里构造残差然后用鲁棒最小二乘求解。import numpy as np from scipy.optimize import least_squares # 观测数据参数量 N、token 数 D、验证损失 L N_obs np.array([1e6, 3e6, 1e7, 3e7, 1e8]) D_obs np.array([2e7, 6e7, 2e8, 6e8, 2e9]) L_obs np.array([3.42, 3.18, 2.95, 2.76, 2.58]) def predict(params, N, D): E, A, alpha, B, beta params return E A / np.power(N, alpha) B / np.power(D, beta) def residual(params, N, D, L): pred predict(params, N, D) # 用相对误差避免大损失点主导拟合 return (pred - L) / L # 初始猜测不可约损失取最小观测损失的八成指数从 0.3 起步 x0 np.array([2.0, 1.0, 0.3, 1.0, 0.3]) bounds ( [0.0, 0.0, 0.01, 0.0, 0.01], [np.min(L_obs), np.inf, 1.5, np.inf, 1.5] ) result least_squares( residual, x0, args(N_obs, D_obs, L_obs), boundsbounds, losssoft_l1, max_nfev20000 ) E, A, alpha, B, beta result.x print(f不可约损失 E {E:.4f}) print(f参数项 A {A:.4f}, 指数 alpha {alpha:.4f}) print(f数据项 B {B:.4f}, 指数 beta {beta:.4f}) # 留一验证用前四个点拟合预测第五个点 train_idx [0, 1, 2, 3] test_idx [4] res_train least_squares( residual, x0, args(N_obs[train_idx], D_obs[train_idx], L_obs[train_idx]), boundsbounds, losssoft_l1, max_nfev20000 ) pred_last predict(res_train.x, N_obs[test_idx], D_obs[test_idx]) print(f留一点预测损失 {pred_last[0]:.4f}, 实际 {L_obs[test_idx][0]:.4f})这段代码有几个细节值得说。第一用相对误差而不是绝对误差是因为大规模点的损失绝对值小绝对误差会让小规模点主导拟合指数被带偏。第二用 soft_l1 而不是默认的线性损失是为了降低异常点的权重一两个毛刺不至于把整条曲线拉歪。第三给指数加了上界 1.5防止拟合跑到不合理的区域比如指数大于一意味着规模翻倍损失腰斩这在实践中几乎不会出现。第四留一验证很重要它比拟合优度更能说明模型能不能外推。拟合结果怎么读先看不可约损失是否合理。它应该低于你最小规模点的损失但又不能低到离谱。再看两个指数。如果参数指数明显大于数据指数说明在你的实验条件下加参数比加数据划算反之则说明数据是瓶颈。最后看留一验证的误差如果预测值和实际值差在百分之五以内这条曲线可以用来做同分布的外推如果差得远不要硬用先检查实验条件是否一致。3.4 外推验证留一个最大点不参与拟合外推验证是整套流程里最容易被跳过、也最不该跳过的一步。我的做法是永远留一个最大规模点不参与拟合用它来检验曲线。这个点最好比参与拟合的最大点大一个数量级左右这样你能看出曲线在跨数量级时是否还站得住。如果留出点的预测误差在百分之五到百分之十以内我会认为这条曲线可以用于同架构、同数据分布的预算估算如果误差超过百分之十五我会把它标记为“仅供方向参考”不拿它做精确决策。外推误差的来源通常有三类。第一类是优化不充分最大规模点没有训到收敛实际损失偏高而曲线是按收敛趋势外推的自然对不上。第二类是数据重复大规模点用了更多 epoch有效数据量没有名义上那么多损失下降不及预期。第三类是架构或超参在大规模时发生了变化比如为了省显存换了激活重计算、为了稳定训练调了初始化这些都会让曲线断裂。排查时按这个顺序查基本能定位到原因。还有一个经验判断如果你只能用小于一个数量级的跨度做拟合外推结果的可信度会大幅下降。我一般要求参与拟合的规模跨度至少两个数量级留出点再跨一个数量级。达不到这个条件时我会明确告诉决策方“这是趋势估计不是预算承诺”。这句话听起来保守但能避免后面很多扯皮。毕竟 Scaling Law 解析的价值是帮你排序方案不是替你做最终决定。4. 实操中最容易踩的坑与排查表4.1 数据质量会直接改写指数同样叫一亿个 token去重前后、质量过滤前后有效信息量可能差出一大截。低质数据、模板化文本、重复段落会让模型把容量浪费在记忆上验证损失下降变慢拟合出来的数据指数偏低。你以为是“数据不重要”其实是“这批数据不值得学”。我在一个项目里做过对比同一套模型、同一个 token 数清洗后的数据让验证损失多降了将近百分之八拟合出来的数据指数从 0.22 变成了 0.31。这个差距足以改变配比决策。所以做扫参之前先把数据管线固定下来并且记录版本。扫参过程中不要换清洗规则、不要换去重阈值、不要中途补充新数据源。如果非要换所有规模点一起重跑否则你拟合的是数据差异不是规模差异。另一个细节是验证集的构造。验证集要从训练数据同分布里留出但不能和训练数据有重叠也不能用训练时过滤掉的低质数据充当验证集否则验证损失会虚低曲线整体下移指数反而看起来更漂亮这是典型的自欺欺人。4.2 学习率与批量带来的假 Scaling学习率是假 Scaling 的重灾区。小模型用偏大的学习率收敛快但最终损失偏高大模型用同样的学习率可能训练不稳定或者收敛不足。两种偏差方向相反叠在一起会让拟合指数失真。我的做法是给每个规模点单独做一个小范围学习率扫描取验证损失最低的那个然后记录下最优学习率和规模的关系。如果关系大致符合平方根反比说明你的扫描是自洽的如果关系乱七八糟说明还有别的变量没控制住。批量大小也一样。小模型在小批量下更新步数多收敛快大模型如果批量放大不够梯度噪声大损失曲线会更抖。反过来批量放得太大学习率没跟上训练会变慢。比较稳妥的做法是让批量随规模适度增长同时保证每个规模点的训练 token 总数和更新步数在合理范围。还有一个容易忽略的点是序列长度。小模型用短序列、大模型用长序列注意力开销占比不同实际计算量和你按 6ND 估算的值会偏离。扫参时尽量统一序列长度或者至少记录下实际吞吐用实测值校正计算量。4.3 下游任务与 loss 脱钩验证损失降了下游任务不涨这种事我遇到过不止一次。原因通常有三类。第一类是任务饱和你的评测集太简单模型早就到顶了loss 再降也反映不到准确率上。第二类是评测污染训练数据里混进了评测集的原题或近似改写loss 降的是记忆不是能力。第三类是格式不匹配模型学会了语言分布但没有学会你评测时要求的输出格式导致自动打分偏低。这三类的排查方法不同但共同点是不能只看 loss必须有一组自己构造的、训练时严格隔离的评测。我通常会留一组“金丝雀”评测规模不大但题目是手工构造的确保没有泄漏。每次扫参都跑一遍观察 loss 和评测分数的相关性。如果某个规模点上 loss 降了但金丝雀分数不动我会先怀疑数据或评测而不是急着下结论说“规模没用”。还有一种情况是能力跳变某个规模之后下游分数突然抬升这在文献里被讨论很多但在工程上要谨慎对待跳变可能是真实的也可能是评测阈值效应也就是模型刚好越过了某个打分边界。判断方法是换一组同难度但不同形式的题目再测如果跳变复现可信度就高很多。4.4 常见问题速查表下面这张表是我自己整理的排查清单按现象查原因能省不少时间。表中的“优先动作”是我个人的习惯顺序不一定适用于所有团队但方向大致通用。现象可能原因优先动作拟合出的参数指数异常大小模型欠训练、大模型超参不匹配检查每个规模点的收敛情况与学习率拟合出的数据指数异常小数据重复、质量差、验证集泄漏去重、质量过滤、重建验证集留出点预测误差超过百分之十五外推跨度不足、优化未收敛增加规模点、延长训练、检查数据 epochloss 降但下游不涨任务饱和、评测污染、格式不匹配换评测集、查泄漏、人工抽查输出曲线在小规模段很陡、大规模段变平不可约损失估计偏低、数据瓶颈放宽不可约损失边界、增加数据配比点不同批次实验结果抖动大数据顺序、初始化、硬件差异固定随机种子、记录数据顺序、多跑几次取中位数这张表不能替代具体分析但它能帮你快速排除低级错误。我的经验是八成以上的拟合异常都能在前三行里找到原因剩下的两成通常和工程环境有关比如不同规模跑在不同型号的机器上浮点精度或通信策略不一样导致数值行为有差异。遇到这种情况先把环境对齐再谈拟合。5. 从训练到推理规模定律的延伸用法5.1 推理成本 scaling什么规模值得上线训练成本是一次性的推理成本是持续的。参数量翻倍单次前向的计算量大致翻倍显存占用也翻倍但请求量大的时候推理成本会迅速超过训练成本。所以做规模决策时不能只看“这个规模 loss 更低”还要看“这个 loss 优势值不值推理溢价”。我的做法是算一个简单的盈亏平衡给定日均请求量和单 token 推理成本算出大模型相对小模型每年多花的推理费用再对比它在业务指标上带来的提升。如果提升带来的收益覆盖不了溢价就应该选小模型或者用蒸馏、量化把大模型的能力压到小模型里。这里有个容易混淆的点总参数量和激活参数量不是一回事。稀疏结构的总参数可以很大但每次前向只激活一部分推理成本按激活参数算。做预算时一定要区分这两个数否则你会把推理成本高估好几倍。另外长上下文会显著推高推理成本因为注意力计算随序列长度增长。如果你的业务输入很长参数量的边际影响会被摊薄这时候更值得优化的是上下文压缩和缓存策略而不是继续抠参数规模。5.2 数据重复与多 epoch 的收益衰减扫参时经常遇到数据不够只能重复训练。重复数据不是完全没用但有效数据量要打折。我的经验是前几个 epoch 的收益接近新数据之后衰减很快超过一定次数后基本只剩记忆效应。具体折扣系数因数据而异去重彻底、多样性高的数据折扣来得慢一些模板化严重的数据第二个 epoch 就开始明显衰减。拟合时如果忽略这一点你会把“重复带来的 loss 下降”误判成“规模带来的收益”外推到大模型上就会高估。处理方法有两种。一种是在拟合时把名义 token 数换成有效 token 数有效 token 数等于唯一 token 数加上重复部分的折扣另一种是干脆在扫参阶段控制每个规模点的 epoch 数一致避免重复度差异污染指数。我倾向于后者因为它更干净代价是需要准备足够多的唯一数据。如果实在做不到至少要在记录里标明每个点的 epoch 数外推时手动打折。这个细节不起眼但在预算紧张、数据有限的团队里它经常是拟合失真的主因。5.3 外推边界与定律失效的信号Scaling Law 不是万能钥匙它在某些条件下会明显失效。我总结了几类信号出现任意一类就不要直接套旧系数。第一类是架构大改比如从稠密换成稀疏、引入新的注意力机制、改变归一化位置这些会改变参数效率和数据效率旧指数不再适用。第二类是数据分布大改比如从通用文本切到垂直领域、从单语切到多语不可约损失和指数都会变。第三类是训练精度或优化器大改混合精度策略、优化器状态、梯度裁剪阈值的变动都会影响收敛行为。第四类是序列长度跨数量级长上下文带来的计算结构变化会让 6ND 近似偏离。遇到这些情况我的做法是重新做一轮小规模校准哪怕只跑三四个点也比直接套旧系数强。校准的目的不是追求精确而是确认指数没有发生方向性变化。如果新拟合的指数和旧系数差得不多可以继续用旧曲线做粗略估算如果差得多就以新数据为准。还有一点不要拿别人的系数直接用哪怕架构相同。数据管线、tokenizer、训练框架的差异足以让指数偏移百分之十以上而这个偏移在预算决策里可能就是几倍的资源差异。Scaling Law 解析说到底是一种本地化知识你得用自己的实验把它养出来。