大模型圈子这两年被Scaling Law刷屏但多数人把它当成一种“信仰”或者“趋势判断”很少有人把它当成一套能指导日常训练的工程工具来用。我自己在几个规模不小的预训练项目里摸爬滚打之后越来越觉得Scaling Law的真正价值不在于告诉你“大就是好”而在于帮你回答几个非常实际的问题预算有限时该涨参数量还是涨数据量训练到一半loss走平是欠拟合还是数据出了问题下一个版本迭代投入算力到底能换回多少个点的收益。这篇文章把我自己的理解和实操经验整理出来目标读者是那些真正要动手训模型、做容量规划、或者评估“加机器到底值不值”的人。1. 先拆开看Scaling Law到底在说哪几条曲线1.1 三条幂律曲线各管一摊Scaling Law的核心发现不复杂模型在预训练中的交叉熵损失也就是我们常说的loss会随着某个资源维度的增加而按幂律下降。这个“某个维度”可以是模型参数量N也可以是训练数据量D还可以是累计计算量C。2020年左右那批经典实验得出的主要结论是固定数据量只增大模型参数量时loss随N的增大按幂律下降固定模型规模只增加训练数据量时loss随D的增大按幂律下降同时增大N和D、让计算量C也随之增加时loss整体继续下降但下降速度同样服从幂律。这三条曲线的指数并不完全一样在经典实验结果里单独增大N带来的收益比单独增大D的收益更明显一些。这也解释了为什么前几年大家一窝蜂去堆参数因为同样的算力投入短期内看起来涨参数的效果更“响亮”。但这个结论有一个非常重要的前提数据量不能成为瓶颈。如果在固定数据量下无限涨参数模型迟早会把数据里的信息“榨干”之后继续加参数只是在死记硬背loss曲线会走平甚至因为过拟合而反弹。这个现象我真实遇到过训练某个十亿级模型时数据反复过了三四十个epochloss低是低了但下游任务表现反而变差这就是典型的参数和数据不匹配。1.2 为什么是幂律而不是线性很多刚接触的人会问为什么参数翻倍、数据翻倍loss不是按线性比例下降而是先快后慢这里有一个直观的理解方式神经网络本质上是在有限维度的参数空间里去逼近一个极其高维的目标函数。一开始参数“稀疏”地分布在目标函数的各个关键区域随便加点参数都能覆盖到新的解释范围但到了后期绝大多数新增参数只是在填补已有解释的“细微褶皱”边际收益自然会越来越低。用生活里的例子类比就像擦一张桌子第一遍抹布一擦肉眼可见的灰尘立刻没了第二遍、第三遍你再仔细擦虽然桌面更光洁了但你很难再看到明显的变化。幂律曲线就是这种“收益递减”的数学描述它不是玄学而是一个极端高维拟合问题在资源有限下的必然表现。1.3 关于“loss不可再降”的极限幂律曲线往下走最终会逼近一个“不可约损失”的下限。这个下限由什么决定数据本身的噪声、任务固有难度、完全确定的信息内容等。如果训练集本身就存在噪声标注哪怕模型完美拟合了正确规律这部分噪声对应的loss也是消除不掉的。所以在做规模化规划的时候我习惯先做一个“天花板测试”拿一批高质量数据反复训练一个稍大的模型观察loss最终停在哪里这个值可以作为后续所有外推曲线的基准线。如果未来换了更大模型、更多数据后loss已经接近这个基线那就说明当前数据集的“有效信息量”已经被吃完了继续堆算力大概率是浪费。这个判断比单纯看曲线形状更靠谱。2. 参数与数据怎么配比才不浪费算力2.1 经典结论已经点过名2022年那篇著名的Chinchilla工作核心是想解决一个效率问题在固定算力预算C下模型参数量N和训练数据量D应该按什么比例分配才能让最终loss最小。结论是计算量最优时模型参数量和训练token数的比例约为1比20。换句话说一个70亿参数规模的模型训练数据量应该大致在1400亿token左右一个700亿参数的模型数据量应该在1.4万亿token左右而不是此前很多人习惯的“有多少数据就硬练多少轮”。这个结论对实操最大的冲击是过去我们默认“把数据多过几轮总没坏处”Chinchilla明确告诉我们在算力预算固定的前提下过度重复数据等于白白燃烧计算资源不如拿那些算力去增大模型的参数量。2.2 数据配比的经验式设计在实际项目中我一般不会机械照搬1比20而是先做一个“缩比例”的粗测试。比如拿总数据的1%、模型参数的1%先跑一个极短run看loss曲线下降的形状再外推到全量规模。这个做法的成本很低但能提前暴露数据配比是否合理。这里给出一个可参考的规划流程确定总算力预算C单位为PFLOPS或等效GPU小时根据C倒推出可训练的参数量N和数据量D的可行组合用“C ≈ 6ND”的估算公式快速验证组合是否匹配这个公式把前向和反向一次完整更新所需的浮点运算量近似为6倍参数量×数据量在缩小版配置上对比“多数据少参数”和“少数据多参数”两种方案的loss走势选择最终配比并在中期检查点观察loss离开预期曲线的时点及时调整。2.3 如果数据确实不够现实中经常出现的情况是公司手里的数据量有限又不可能快速买到新数据。这时候有一类值得推荐的做法——适度重复数据但用“温度”或者“重采样权重”来控制重复程度。我倾向于训练集里的高价值样本可以多重复几次低价值样本、噪声样本尽量少重复而不是无脑把整个数据集均匀重复N遍。另一个思路是进行数据降噪。很多时候数据量看着大实际里面有大段重复模板、低质量OCR乱码、或者语义上等价但是表达完全相同的文本。把这些冗余样本做hash去重、做minhash近似去重往往能让有效信息密度提升30%甚至更多等于变相“增加”了训练数据。这类工程投入的性价比很多时候甚至高过单纯增加一批新数据。3. 实操一次从零开始的规模化训练决策3.1 先用公式框定可行域举一个真实的模拟场景。假设我们有一批算力资源相当于1000张高性能加速卡连续跑30天。每张卡每天大概能完成约1e18次浮点运算这是目前主流加速卡的常规水平那么总计算量C就是1000卡 × 30天 × 1e18 FLOPS/天 3e22 FLOPS用C ≈ 6ND做倒推如果选择N 13B约130亿参数那么可训练的数据量D大约为D C / (6 × N) 3e22 / (6 × 1.3e10) ≈ 3.8e11 token也就是3800亿token左右这个量级的数据如果公司内部有那就可以放心按13B参数3800亿token去组织训练如果实际只有1000亿token那要么降低参数量到3B-5B级别让配比不至于严重失衡要么优先去扩充数据。3.2 训练中途怎么判断“是否还在线上”规模化训练不是启动之后就不管了。我会在训练过程中定期记录“实际loss”和“外推预期loss”的差值。具体做法是在训练集的一个固定子集上永远用同一个batch计算loss这个子集不参与任何数据增强或采样权重调整。这样就能保证数值是横跨整个训练过程可比的。如果实际loss一直在预期曲线下方说明数据配比相对充足模型还有收敛空间如果实际loss开始高于预期曲线并且差距越来越大优先怀疑两个问题一是模型容量已经逼近该数据量的信息上限二是数据采样过程中混入了过多重复样本导致有效信息密度下降。另外我强烈建议保留一份“按来源分组的评估集”。训练loss是全局的如果某个数据源质量特别差它会把损失拉高但其他数据源的loss正常全局曲线看起来并不异常。只有拆开看才能精准发现是哪个来源在拖后腿。这个习惯帮我们排查过多次“莫名升高的loss”最后定位到是某个自动爬取管道一段时间内注入了大量噪声页面。3.3 超参选择要不要跟模型规模联动模型规模变大后最优学习率、batch size都会变化。一个粗略的经验是模型每增大一个数量级最佳batch size往往需要一个量级左右的增长学习率则需要适当下降。这个调整不是玄学而是因为大模型梯度噪声相对更平稳可以用更大的batch去压低方差但由于参数维度更多过大的学习率容易在训练中后期造成不稳定。我的做法是在短跑阶段同时尝试2-3组“模型规模-学习率-batch size”的组合每组只训练几千步然后比较loss曲线的下降速度和波动情况。短跑阶段选出最优组合后再启动长跑。中途不要频繁大改超参尤其是学习率尽量维持warmup后平稳衰减把不确定性降到最低。4. 别让Scaling Law耽误了你常见误区和边界4.1 误区一拿单次训练结果硬套论文曲线最常见的翻车现场是读者看到一个论文里画的loss曲线发现自己训练到某个步数时loss高于曲线立刻断定“Scaling Law失效了”。但论文里的曲线往往来自对大量模型、多次训练的平均拟合单个模型一次训练结果落在线下或线上都是正常波动。而且不同tokenizer、不同batch size、不同数据混合比例都会对loss绝对值产生很大影响。tokenizer的词表大小尤其致命如果词表太小每个token包含的信息量就少同样的数据量折算下来的“有效信息量”就偏低模型必须学更多step才能达到同样的loss。我踩过一次坑某版本实验里换了一个压缩率较弱的tokenizer同样的模型和数据loss整体高了0.15当时一度以为是模型结构出了问题。所以做对比时一定要先固定tokenizer和数据预处理。4.2 误区二觉得“越大越好”而忽略下游任务Scaling Law衡量的核心指标是预训练loss但很多实际业务关心的是下游benchmark。两者有关系却不是严格单调对应。部分能力比如复杂推理、代码生成、长文本理解要到模型规模超过某个阈值、loss降到某个临界点之后才会“涌现”出来。换句话说loss曲线看着还在平滑下降但下游某一项能力可能在某个点突然起飞也可能在另一个点完全没动静。所以我建议在规模化训练规划期就挑出5-10个跟业务强相关的下游任务做成轻量级评测集每隔一定步数跑一次。不要只盯loss也不要在模型完全收敛后才看下游任务。我自己见过一个模型loss表现很好但在数学推理类任务上一塌糊涂最后排查发现是数据配比中缺乏推理链样本loss低并不能暴露这个问题只有任务评测才能。4.3 边界跨模态、跨任务类型的迁移预测要谨慎经典Scaling Law主要适用于“同分布、同任务类型下的资源-性能”外推。一旦换成跨模态场景比如从纯文本换成图文混合数据或者从语言模型换成多模态生成模型幂律的指数甚至形状都可能发生改变千万不能机械套用。多模态场景里视觉token和文本token的信息密度差异很大简单把所有token混在一起算“总量”是不合理的。跨任务类型时比如从预训练迁移到指令微调两者的关系也不是简单的“预训练做得越好微调后一定更强”。我实践中的经验是跨域前先用小规模验证单独做一组“模态/任务配比测试”而不是直接沿用上一轮的最优配置。4.4 数据质量恶化时Scaling Law会失真Scaling Law有个隐含假设新增数据在质量上是稳定的、同质的。如果数据管道出问题比如爬虫抓到了大量重复页面、OCR工具批量产生乱码模型的loss曲线可能不降反升。这不是Scaling Law失效而是“数据质量”这一项在模型中未被显式建模但它能完全破坏规律。所以规模化规划里我坚持把数据质量监控也当作“一等公民”训练过程中不仅记录loss还记录训练样本的token多样性指标、重复率、字符级熵等。一旦发现多样性大幅下降立即暂停数据管道排查而不是傻等曲线恢复。5. 关于扩展律我的几点个人体会落到最后说一下我自己心态上的变化。早期我总觉得Scaling Law是“实验室里的规律”跟我做业务模型没多大关系。经历了几次规模化训练后我反而觉得它更像一本“工程预算手册”——它不告诉你什么该做但能告诉你“做这件事大概要花多少算力、能换回多少收益、值不值得做”。这份预算感在跟资源管理部门撕算力配额的时候特别有用有数据支撑的请求比“我觉得需要更大模型”这种主观说法好沟通得多。实际使用中最让我受益的一件事是学会了用“相对斜率”代替“绝对loss值”来做监控。绝对loss值受tokenizer、评估集、温度等一堆因素影响不同环境之间不可比但相邻checkpoint之间的loss下降速度如果突然偏离了平滑趋势往往意味着采样分布变化、数据污染或优化器状态异常。这三个字“看斜率”几乎成了团队里的口头禅。还有一个长期习惯我会把每个规模训练实验的关键指标loss、斜率、下游弱项、配比超参记录成一张带备注的表。规模训练跑的周期长时间久了很容易忘记当初某个配置为什么要这么调。有这张表在手下一轮设计就能少走很多弯路。这大概也算是我自己的“小规模扩展律”吧。 
长河君 · 2026/10/20 9:40:56 · 阅读 1.2k Scaling Law工程化：参数、数据与算力的最优配比实战
大模型圈子这两年被Scaling Law刷屏但多数人把它当成一种“信仰”或者“趋势判断”很少有人把它当成一套能指导日常训练的工程工具来用。我自己在几个规模不小的预训练项目里摸爬滚打之后越来越觉得Scaling Law的真正价值不在于告诉你“大就是好”而在于帮你回答几个非常实际的问题预算有限时该涨参数量还是涨数据量训练到一半loss走平是欠拟合还是数据出了问题下一个版本迭代投入算力到底能换回多少个点的收益。这篇文章把我自己的理解和实操经验整理出来目标读者是那些真正要动手训模型、做容量规划、或者评估“加机器到底值不值”的人。1. 先拆开看Scaling Law到底在说哪几条曲线1.1 三条幂律曲线各管一摊Scaling Law的核心发现不复杂模型在预训练中的交叉熵损失也就是我们常说的loss会随着某个资源维度的增加而按幂律下降。这个“某个维度”可以是模型参数量N也可以是训练数据量D还可以是累计计算量C。2020年左右那批经典实验得出的主要结论是固定数据量只增大模型参数量时loss随N的增大按幂律下降固定模型规模只增加训练数据量时loss随D的增大按幂律下降同时增大N和D、让计算量C也随之增加时loss整体继续下降但下降速度同样服从幂律。这三条曲线的指数并不完全一样在经典实验结果里单独增大N带来的收益比单独增大D的收益更明显一些。这也解释了为什么前几年大家一窝蜂去堆参数因为同样的算力投入短期内看起来涨参数的效果更“响亮”。但这个结论有一个非常重要的前提数据量不能成为瓶颈。如果在固定数据量下无限涨参数模型迟早会把数据里的信息“榨干”之后继续加参数只是在死记硬背loss曲线会走平甚至因为过拟合而反弹。这个现象我真实遇到过训练某个十亿级模型时数据反复过了三四十个epochloss低是低了但下游任务表现反而变差这就是典型的参数和数据不匹配。1.2 为什么是幂律而不是线性很多刚接触的人会问为什么参数翻倍、数据翻倍loss不是按线性比例下降而是先快后慢这里有一个直观的理解方式神经网络本质上是在有限维度的参数空间里去逼近一个极其高维的目标函数。一开始参数“稀疏”地分布在目标函数的各个关键区域随便加点参数都能覆盖到新的解释范围但到了后期绝大多数新增参数只是在填补已有解释的“细微褶皱”边际收益自然会越来越低。用生活里的例子类比就像擦一张桌子第一遍抹布一擦肉眼可见的灰尘立刻没了第二遍、第三遍你再仔细擦虽然桌面更光洁了但你很难再看到明显的变化。幂律曲线就是这种“收益递减”的数学描述它不是玄学而是一个极端高维拟合问题在资源有限下的必然表现。1.3 关于“loss不可再降”的极限幂律曲线往下走最终会逼近一个“不可约损失”的下限。这个下限由什么决定数据本身的噪声、任务固有难度、完全确定的信息内容等。如果训练集本身就存在噪声标注哪怕模型完美拟合了正确规律这部分噪声对应的loss也是消除不掉的。所以在做规模化规划的时候我习惯先做一个“天花板测试”拿一批高质量数据反复训练一个稍大的模型观察loss最终停在哪里这个值可以作为后续所有外推曲线的基准线。如果未来换了更大模型、更多数据后loss已经接近这个基线那就说明当前数据集的“有效信息量”已经被吃完了继续堆算力大概率是浪费。这个判断比单纯看曲线形状更靠谱。2. 参数与数据怎么配比才不浪费算力2.1 经典结论已经点过名2022年那篇著名的Chinchilla工作核心是想解决一个效率问题在固定算力预算C下模型参数量N和训练数据量D应该按什么比例分配才能让最终loss最小。结论是计算量最优时模型参数量和训练token数的比例约为1比20。换句话说一个70亿参数规模的模型训练数据量应该大致在1400亿token左右一个700亿参数的模型数据量应该在1.4万亿token左右而不是此前很多人习惯的“有多少数据就硬练多少轮”。这个结论对实操最大的冲击是过去我们默认“把数据多过几轮总没坏处”Chinchilla明确告诉我们在算力预算固定的前提下过度重复数据等于白白燃烧计算资源不如拿那些算力去增大模型的参数量。2.2 数据配比的经验式设计在实际项目中我一般不会机械照搬1比20而是先做一个“缩比例”的粗测试。比如拿总数据的1%、模型参数的1%先跑一个极短run看loss曲线下降的形状再外推到全量规模。这个做法的成本很低但能提前暴露数据配比是否合理。这里给出一个可参考的规划流程确定总算力预算C单位为PFLOPS或等效GPU小时根据C倒推出可训练的参数量N和数据量D的可行组合用“C ≈ 6ND”的估算公式快速验证组合是否匹配这个公式把前向和反向一次完整更新所需的浮点运算量近似为6倍参数量×数据量在缩小版配置上对比“多数据少参数”和“少数据多参数”两种方案的loss走势选择最终配比并在中期检查点观察loss离开预期曲线的时点及时调整。2.3 如果数据确实不够现实中经常出现的情况是公司手里的数据量有限又不可能快速买到新数据。这时候有一类值得推荐的做法——适度重复数据但用“温度”或者“重采样权重”来控制重复程度。我倾向于训练集里的高价值样本可以多重复几次低价值样本、噪声样本尽量少重复而不是无脑把整个数据集均匀重复N遍。另一个思路是进行数据降噪。很多时候数据量看着大实际里面有大段重复模板、低质量OCR乱码、或者语义上等价但是表达完全相同的文本。把这些冗余样本做hash去重、做minhash近似去重往往能让有效信息密度提升30%甚至更多等于变相“增加”了训练数据。这类工程投入的性价比很多时候甚至高过单纯增加一批新数据。3. 实操一次从零开始的规模化训练决策3.1 先用公式框定可行域举一个真实的模拟场景。假设我们有一批算力资源相当于1000张高性能加速卡连续跑30天。每张卡每天大概能完成约1e18次浮点运算这是目前主流加速卡的常规水平那么总计算量C就是1000卡 × 30天 × 1e18 FLOPS/天 3e22 FLOPS用C ≈ 6ND做倒推如果选择N 13B约130亿参数那么可训练的数据量D大约为D C / (6 × N) 3e22 / (6 × 1.3e10) ≈ 3.8e11 token也就是3800亿token左右这个量级的数据如果公司内部有那就可以放心按13B参数3800亿token去组织训练如果实际只有1000亿token那要么降低参数量到3B-5B级别让配比不至于严重失衡要么优先去扩充数据。3.2 训练中途怎么判断“是否还在线上”规模化训练不是启动之后就不管了。我会在训练过程中定期记录“实际loss”和“外推预期loss”的差值。具体做法是在训练集的一个固定子集上永远用同一个batch计算loss这个子集不参与任何数据增强或采样权重调整。这样就能保证数值是横跨整个训练过程可比的。如果实际loss一直在预期曲线下方说明数据配比相对充足模型还有收敛空间如果实际loss开始高于预期曲线并且差距越来越大优先怀疑两个问题一是模型容量已经逼近该数据量的信息上限二是数据采样过程中混入了过多重复样本导致有效信息密度下降。另外我强烈建议保留一份“按来源分组的评估集”。训练loss是全局的如果某个数据源质量特别差它会把损失拉高但其他数据源的loss正常全局曲线看起来并不异常。只有拆开看才能精准发现是哪个来源在拖后腿。这个习惯帮我们排查过多次“莫名升高的loss”最后定位到是某个自动爬取管道一段时间内注入了大量噪声页面。3.3 超参选择要不要跟模型规模联动模型规模变大后最优学习率、batch size都会变化。一个粗略的经验是模型每增大一个数量级最佳batch size往往需要一个量级左右的增长学习率则需要适当下降。这个调整不是玄学而是因为大模型梯度噪声相对更平稳可以用更大的batch去压低方差但由于参数维度更多过大的学习率容易在训练中后期造成不稳定。我的做法是在短跑阶段同时尝试2-3组“模型规模-学习率-batch size”的组合每组只训练几千步然后比较loss曲线的下降速度和波动情况。短跑阶段选出最优组合后再启动长跑。中途不要频繁大改超参尤其是学习率尽量维持warmup后平稳衰减把不确定性降到最低。4. 别让Scaling Law耽误了你常见误区和边界4.1 误区一拿单次训练结果硬套论文曲线最常见的翻车现场是读者看到一个论文里画的loss曲线发现自己训练到某个步数时loss高于曲线立刻断定“Scaling Law失效了”。但论文里的曲线往往来自对大量模型、多次训练的平均拟合单个模型一次训练结果落在线下或线上都是正常波动。而且不同tokenizer、不同batch size、不同数据混合比例都会对loss绝对值产生很大影响。tokenizer的词表大小尤其致命如果词表太小每个token包含的信息量就少同样的数据量折算下来的“有效信息量”就偏低模型必须学更多step才能达到同样的loss。我踩过一次坑某版本实验里换了一个压缩率较弱的tokenizer同样的模型和数据loss整体高了0.15当时一度以为是模型结构出了问题。所以做对比时一定要先固定tokenizer和数据预处理。4.2 误区二觉得“越大越好”而忽略下游任务Scaling Law衡量的核心指标是预训练loss但很多实际业务关心的是下游benchmark。两者有关系却不是严格单调对应。部分能力比如复杂推理、代码生成、长文本理解要到模型规模超过某个阈值、loss降到某个临界点之后才会“涌现”出来。换句话说loss曲线看着还在平滑下降但下游某一项能力可能在某个点突然起飞也可能在另一个点完全没动静。所以我建议在规模化训练规划期就挑出5-10个跟业务强相关的下游任务做成轻量级评测集每隔一定步数跑一次。不要只盯loss也不要在模型完全收敛后才看下游任务。我自己见过一个模型loss表现很好但在数学推理类任务上一塌糊涂最后排查发现是数据配比中缺乏推理链样本loss低并不能暴露这个问题只有任务评测才能。4.3 边界跨模态、跨任务类型的迁移预测要谨慎经典Scaling Law主要适用于“同分布、同任务类型下的资源-性能”外推。一旦换成跨模态场景比如从纯文本换成图文混合数据或者从语言模型换成多模态生成模型幂律的指数甚至形状都可能发生改变千万不能机械套用。多模态场景里视觉token和文本token的信息密度差异很大简单把所有token混在一起算“总量”是不合理的。跨任务类型时比如从预训练迁移到指令微调两者的关系也不是简单的“预训练做得越好微调后一定更强”。我实践中的经验是跨域前先用小规模验证单独做一组“模态/任务配比测试”而不是直接沿用上一轮的最优配置。4.4 数据质量恶化时Scaling Law会失真Scaling Law有个隐含假设新增数据在质量上是稳定的、同质的。如果数据管道出问题比如爬虫抓到了大量重复页面、OCR工具批量产生乱码模型的loss曲线可能不降反升。这不是Scaling Law失效而是“数据质量”这一项在模型中未被显式建模但它能完全破坏规律。所以规模化规划里我坚持把数据质量监控也当作“一等公民”训练过程中不仅记录loss还记录训练样本的token多样性指标、重复率、字符级熵等。一旦发现多样性大幅下降立即暂停数据管道排查而不是傻等曲线恢复。5. 关于扩展律我的几点个人体会落到最后说一下我自己心态上的变化。早期我总觉得Scaling Law是“实验室里的规律”跟我做业务模型没多大关系。经历了几次规模化训练后我反而觉得它更像一本“工程预算手册”——它不告诉你什么该做但能告诉你“做这件事大概要花多少算力、能换回多少收益、值不值得做”。这份预算感在跟资源管理部门撕算力配额的时候特别有用有数据支撑的请求比“我觉得需要更大模型”这种主观说法好沟通得多。实际使用中最让我受益的一件事是学会了用“相对斜率”代替“绝对loss值”来做监控。绝对loss值受tokenizer、评估集、温度等一堆因素影响不同环境之间不可比但相邻checkpoint之间的loss下降速度如果突然偏离了平滑趋势往往意味着采样分布变化、数据污染或优化器状态异常。这三个字“看斜率”几乎成了团队里的口头禅。还有一个长期习惯我会把每个规模训练实验的关键指标loss、斜率、下游弱项、配比超参记录成一张带备注的表。规模训练跑的周期长时间久了很容易忘记当初某个配置为什么要这么调。有这张表在手下一轮设计就能少走很多弯路。这大概也算是我自己的“小规模扩展律”吧。