在很多人眼里大语言模型的可扩展性评估就是“把模型做大看看效果涨不涨”但真正动手做过一轮评估之后你就会发现这中间写满了坑。模型参数量翻倍损失曲线确实在降但训练成本翻了三倍下游任务指标又只涨了零点几个点同一个评估方案换一批数据、换一种并行策略得到的结果规律就完全变了。这篇文章我想从实际做评估的角度把大语言模型可扩展性评估这件事拆开来讲清楚它到底在衡量什么、关键指标怎么设计、实验怎么做完一轮能拿到可信的结论以及那些文档里不会写的排除故障经验。适合正在做预训练、模型选型或基础设施规划的团队参考也适合想系统理解大模型缩放规律的研究者快速建立框架。1. 可扩展性评估到底在评估什么1.1 一个规模问题引发的连锁反应先做一个思想实验你手上有一个1亿参数的小模型训练数据用了5GB效果不错。现在你想知道如果模型扩到10亿参数、数据扩到50GB效果能好多少训练要多久硬件要几卡。这些问题听起来简单但直接拿一个10亿模型去训练是不可行的因为你不能确定结果的提升是来自模型规模、数据规模还是优化器参数的运气。所以需要一种方法在真正烧钱之前先推算出规模变化的收益曲线。这就是可扩展性评估的用处。它本质上回答的是一个预测性问题给定模型结构、数据分布和计算资源当规模模型参数、数据token数、计算量FLOPs放大时模型性能损失、下游能力会以什么规律变化。如果变化规律是幂律那我们可以用几个小规模实验外推算出大规模训练的目标损失和资源预算。如果变化规律不是幂律那你就要小心了要么架构存在瓶颈要么数据分布有问题。这里有一个关键认知可扩展性评估不是事后统计而是事前的工程决策工具。所以评估的核心是“外推”和“可信度”而不是简单地记录几个点。1.2 可扩展性评估的三个核心维度我习惯把评估拆成三个维度分别是模型维度、数据维度和计算维度。三者互相耦合不能单独抽出来看。模型维度指的是参数量、层数、头数、宽度深度比例以及结构变体。最常见的是让模型尺寸按某种倍数递增比如从30M、60M、120M、240M一路涨到10B比较不同尺寸下的最终损失。这里必须保证所有尺寸用相同的训练步数或相同的计算预算否则比较失真。数据维度是训练数据的数量与质量。大语言模型的可扩展性研究里数据规模通常用token数衡量。很多团队在评估时只关注模型大小却忘了同时缩放数据量。经典结论是模型参数量与训练token数应该一起增长模型扩大10倍数据最好也扩大约10倍但现实中总是受数据收集能力和成本限制。评估时要明确定义数据是固定还是随模型缩放这是结论差异最大的一处。计算维度则是总FLOPs、训练时长、硬件配置和并行策略。计算预算决定了你能跑到多大尺度。可扩展性评估的一个常见目标是找到“最优分配”——在给定FLOPs预算下模型参数和数据分别应该是多少。这需要你在多个“模型尺寸-数据量”组合下做矩阵实验而不是一条线上的几个点。1.3 为什么不能只看损失曲线一个常见误区是拿训练loss曲线直接判断可扩展性。loss在变小听起来是好事但loss下降的速率和幅度受很多非规模因素影响学习率调度、batch size、梯度累积步数、优化器参数、数据顺序。如果你在改变模型尺寸的同时改了这些配置你看到的loss差异就混淆了因素。打个比方你测试一辆车的油耗和速度关系但每测一次都换不同的轮胎气压和空调档位最后得到的曲线自然无法真实反映排量与油耗的关系。可扩展性评估要严格控制变量只让目标规模维度变化其他超参要么固定要么按照已有规则进行补偿。比如batch size随模型尺寸同步放大时学习率也需要按比例调整否则小模型和大模型处于不同优化状态。所以我的建议是可扩展性评估至少需要三层输出。第一层是训练损失随计算量或参数量变化的曲线第二层是下游任务或评估集上的指标变化第三层是资源效率曲线比如每单位loss下降消耗的FLOPs和显存。只报告第一层的文章很多是被其蒙蔽的。2. 评估指标体系与实验设计2.1 关键指标训练侧与推理侧把大语言模型可扩展性评估落到具体执行上首先要定指标。训练侧最核心的是交叉熵损失cross-entropy loss和困惑度perplexity。这两者是模型对下一个词预测置信度的度量。loss越低模型对训练数据的拟合越好。但注意两者在数值上高度相关不必重复统计。更重要的指标是“loss vs. 计算量”曲线。我们可以把计算量定义为训练过程中消耗的总FLOPs这是一个标准化的横轴可以跨不同模型尺寸进行公平比较。因为从直觉上讲你花了多少算力才把loss降到某个水平才是可扩展性的真实含义。很多研究用“每token FLOPs × token数”做计算量如果要细算总FLOPs ≈ 6 × 参数量 × 训练token数仅前向反向的标准估算。这个公式是业界常用的近似值实际操作中还要考虑激活重计算和并行通信开销但作为评估基准足够稳定。推理侧指标也很重要。扩展模型后若表现变好却慢得没法上线这可不算成功。推理侧需要记录首token延迟、生成吞吐量tokens/s、显存峰值占用、批处理规模等。可扩展性评估经常被想做训练的人的预训练问题误导。实际上推理扩展性直接决定你这模型能不能用、成本能不能承受。尤其是当模型尺寸突破给定显存后可能需要张量并行、流水线并行或量化这些都会改变推理性能和显存曲线。评估要区分“裸模型推理性能”和“经过工程优化后的推理性能”否则不同团队结论无法对比。下游任务指标也不能省。损失下降不一定意味着能力均衡增长。有的模型损失降了但数学推理能力没涨反而在一些鲁棒性测试上退步。所以评估集合应该覆盖语言理解、生成、代码、推理、事实性等不同能力维度。每个任务选2到3个代表性指标即可不要追求跑几十个任务时间和算力成本太高。2.2 设计多尺度实验的基本法则设计一个可扩展性评估实验本质上就是确定一组从小到大、覆盖一个数量级的模型规模点。我常用的法则如下。首先确定最小基线和最大参考线。最小模型通常在20M到50M参数之间小到单卡几小时能跑完最大模型取决于你愿意为评估付出的预算一般比目标生产模型小一倍到一个数量级比如目标模型是10B评估的最大尺寸可以是1B或2B。过大的评估模型会拖慢迭代失去评估的意义。然后确定中间尺寸。中间尺寸建议按对数均匀分布比如30M、60M、120M、240M、480M、1B。这样在log-log坐标下点间距均匀后续拟合幂律曲线时更稳定。如果某个区间你的架构特性突变比如是否使用稀疏注意力、是否使用MoE那就要在那个突变点附近加密采样否则拟合出来的曲线会掩盖结构差异。训练步数或token数怎么定这是最容易出错的点。常见做法是固定总计算预算让大模型训练更多token小模型训练较少token这在可扩展性研究中叫作“compute-optimal”框架。但要研究“模型大小对性能的影响”则要固定token数让不同尺寸模型处理相同的数据量。两种做法回答的问题完全不同要看你评估的目标是什么。如果是为预训练方案做预算推荐用fixed compute如果是为了验证模型结构调整推荐用fixed data。还有一条容易被忽视每个尺寸至少要重复两次不同随机种子。小规模训练成本低可以多做几个seed去除噪声大规模训练跑不了太多seed但至少要有一次独立重复。否则你拟合出来的曲线可能只是噪声的趋势。2.3 数据与算力配置的归一化方法不同尺寸的模型使用的数据批次大小、序列长度、总token数都不同。如果直接拿loss对比相当于拿苹果和橘子比。必须做归一化。数据层面推荐以token为口径而不是以文本段落为口径。因为模型处理的是token序列段落长度差异会导致每batch的有效信息量不同。所有实验应当使用相同的tokenizer并统计处理过的token总数。这个总数决定了模型“看到”了多少数据。算力层面建议把所有成本折算成统一尺度。训练消耗的总FLOPs是最常用的归一化标准。可参考公式每token训练的计算成本约为6NN是参数量也就是训练一个token需要约6N次浮点运算。如果用了MoE结构实际计算量可能小于6N这时候要根据激活参数量计算。在评估报告中要显式写出计算公式和估算口径否则别人无法复现你的成本对比。很多团队喜欢用“GPU小时”做对比我建议把GPU小时拆成“单卡算力×时间”再统一换算。不同型号GPU的峰值算力不一样统一为FLOPs或Token-per-second才科学。还要考虑通信开销和IO瓶颈实测的FLOPs利用率可能只有理论值的40%到70%这个利用率在模型尺寸变化时通常也会变应该在记录中单独列出。3. 实操从零搭建一次可扩展性评估3.1 环境准备与基线选择在我看来新建可扩展性评估工程最好的起点不是找一堆代码仓库而是先把基线和约束写下来。建议准备一张白板或文档列清楚四件事模型架构定死比如标准decoder-only结构旋转位置编码GELU激活层归一化tokenizer定死固定词表大小和分词语法优化器与调度器定死AdamW配合余弦退火先设置一个较小warmup步数数据分布定死使用同一个预处理后的训练数据集不做增强或换顺序。只要是统一用同一个baseline你后续的实验才有对照意义。很多公开的大模型评估代码仓库把模型配置写在配置文件里这可以套用但注意要把数据路径、tokenizer路径也锁死避免隐性差异。硬件层面评测的最小模型单卡可跑最大模型要至少2卡以上。我推荐先在一张显卡上跑最小模型验证整个链路通顺包括数据加载、checkpoint保存、loss日志输出。先不要急着上并行训练因为你最少要在小模型上把全部评估流程跑通训练、评估loss、跑下游任务、记录指标、绘制曲线。这些步骤中的任何意外都应该在最小尺寸上暴露出来并修复。3.2 训练多个尺寸模型的调度策略当你有多个尺寸模型要训练时调度是有讲究的。最简单的是串行跑先跑完最小模型再依次跑更大的。这个策略缺点是如果中间发现配置错误你前面的时间全部浪费。更稳妥的方式是采用“先侦测后批量”策略先用最小模型跑一个缩短版比如只跑完整训练的20%步数确认loss下降趋势正常、吞吐指标符合预期然后再把所有尺寸排入队列按从小到大顺序批量执行。调度时还要注意一批实验的所有模型使用相同的训练步数规划。比如定下每个模型训练100B token那么小模型训练时长和大模型训练时长大为不同但计算总量随规模增长这就可以计算固定计算预算下的性能曲线。如果你决定固定token数那么所有模型都训练100B token总计算量随模型规模增长这时曲线的横轴应该是模型参数量。我建议同时记录两类数据一是每个模型在固定步数的loss快照比如每1000步记录一次二是训练结束后的最终指标。前者可以绘制全部训练曲线后者用于汇总最终可扩展性曲线。这两个数据分开存别混在一起。并行策略方面小模型尽量用单卡或数据并行大模型用张量并行。注意并行方式本身会影响训练效率因此记录日志时要额外记录“有效吞吐”即每秒实际训练的token数。不同并行策略下吞吐差异很大如果绘制的是FLOPs利用率会看到随机波动。3.3 记录数据、拟合缩放曲线训练结束后手里的数据是一组点每个模型有N、T总训练token、C总FLOPs、loss以及子任务指标。接下来要做的是拟合可扩展性曲线。主流做法是假设损失与计算量之间满足幂律关系loss(C) a * C^(-b) c其中b是缩放指数b越大代表效率越高c是可达到的最低损失受数据固有熵限制。做这个拟合不需要复杂的工具Python的scipy.curve_fit或直接对对数变换后的数据做线性回归都行。如果是对数变换公式变成log(loss - c) log(a) - b * log(C)。麻烦的地方在于c未知此时可以先用足够大尺度下观察到的loss下界估算c再迭代拟合。更有价值的做法是同时对多个幂律项进行联合拟合例如同时考虑N和D的独立贡献。业界经典公式为loss(N, D) A * N^(-alpha) B * D^(-beta) E这个公式把模型参数规模和数据规模对loss的影响分开。评估时可安排不同尺寸、不同token的组合。实际操作中需要用非线性最小二乘优化。拟合后你可以得到alpha和betaalpha通常大于beta说明一定范围内增加参数量比增加数据量更划算。我不建议新手一上来就拟合这个公式因为对数据点的数量和噪声容忍度要求较高还是先用单变量幂律热身。拟合时每个点最好带权重。大模型的loss更稳定应该有更高权重小模型点可能受随机种子影响大可稍微降权。至于怎么定权重可以直接用模型规模的倒数或者loss标准差的倒数没有绝对标准但要写进报告里。3.4 评估结果的可视化与解读等拟合完成后漂亮的可视化会帮助你看出很多趋势。最基础的图是log-log坐标下的loss-C曲线横轴是总FLOPs或训练token纵轴是loss每个点标不同尺寸模型。这条线如果呈较直的下降趋势说明可扩展性规律稳定如果曲线在大模型处开始变平说明模型扩展时数据不够或收益正在消失。第二个必须看的图是“loss vs 模型参数量”曲线固定token数绘制。若曲线下降趋势逐渐放缓说明模型从参数增加中获得的边际收益降低此时应该转而增加数据。第三个图是“下游任务指标 vs loss”的散点图用于验证“loss降了能力是否齐涨”。如果散点图呈现出某些任务在一个临界点后才开始上升说明模型能力和损失并不是理想的单调映射。做解读时不要只看拟合系数。b值大不等于模型好还要看绝对loss。小模型在极低计算预算下b值可能很大但绝对loss很高这种表现在scale up后很可能只是追赶小模型的起点。所以解读要结合“目标能力水平”反向推理你希望最终达到的loss是多少在拟合曲线上找到需要的FLOPs然后反推硬件资源。4. 常见问题与排查实录4.1 曲线抖动是随机噪声还是实现问题我在实际评估中第一个想分享的问题是曲线抖动。你训练三个尺寸的模型得到的loss-C点没有平滑排列甚至最小模型比中间模型效果还好。这种情况大概率不是随机噪声而是配置不一致。需要逐项排查tokenizer是否一致训练数据是否经过相同的预处理是否每个模型都执行了相同的检查点保存和评估代码有时候为了加速小模型用bfloat16混合精度而大模型用了FP8或int8这会影响数值精度从而改变loss。还有数据加载顺序不一致比如文件打乱时用了不同的随机种子会导致模型看到的数据分布略有不同尤其是如果数据本身存在领域偏差。我踩过一次最隐蔽的坑小模型训练时用了更大的batch size模拟大模型训练环境但学习率没有按batch size比例调整。结果是“大LR能吃下大batch”而小batch配上较小LR输出反而更高loss趋势完全混乱。后来我一律以“梯度更新步数”而不是“样本数”为基准设计对照。4.2 小模型数据量不合理导致拟合失真很多新手做评估时让所有尺寸模型训练同样长的步数但小模型由于单步计算量小总token数远低于大模型这本身没问题。但如果你在固定token数时让只有2000万参数的模型也读10亿token那它可能早就过拟合了loss不再下降最终点会在曲线中形成一个“高不可攀”的平台直接破坏幂律拟合。解决办法是先做一次小型过拟合探测对不同尺寸模型分别训练一定比例的token观察训练集loss和验证集loss的gap。如果gap持续扩大但验证loss不再下降说明数据量对该模型尺寸偏多。在正式评估时为每个尺寸设置一个合理的数据上限或干脆采用固定计算预算在低预算下损失主要是欠拟合而不是过拟合曲线更干净。4.3 吞吐与显存计算偏差可扩展性评估不只看loss还要看成本。很多人直接从框架日志里读“吞吐量”但不同框架的统计算法不同。例如有的统计的是端到端包含评估的吞吐有的只统计纯训练步骤。我建议自定义一个计数器只统计实际前向反向迭代的token数和时间并把数据加载、checkpoint、评估的时间单独计时。否则你有可能会把一个IO瓶颈误判为模型扩展性瓶颈。显存也需要按真实张量内存来分析。每个模型的峰值显存会随着batch size、序列长度和数据并行度变化。评估时如果要比较不同尺寸模型的内存扩展趋势必须固定batch per device和序列长度然后记录显存。同时梯度检查点、混合精度、优化器状态AdamW额外存m和v向量都会显著影响内存。统一配置后显存曲线应该大致随参数量线性增长如果你的曲线出现跳跃式上升多半是并行策略触发了通信缓冲区分配需要单独排查。4.4 跨集群实验的可复现性现实情况下一个评估项目常常要在不同显卡、不同集群上跑不同尺寸模型这会给可复现性带来很多麻烦。我遇到过同一份代码在不同集群上跑出不同loss的情况找了一圈原因发现是跨机器数据Shuffle的随机状态未对齐。由于dataset没有固定全局shuffle seed每台宿主机上的数据顺序不同导致模型见到的数据流不一致。解决办法是第一次把shuffle后的全局索引序列固化成一个文件所有模型都从相同索引序列中读取数据。还需要盯紧不同集群的通信带宽差异。小模型训练时通信占比小大模型并行度提升后通信时间可能占30%以上。如果你用总FLOPs除以端到端时间算有效算力会发现大模型的有效算力显著偏低。这个偏低本身不算bug但你要在评估报告中体现出来因为它会影响总成本预测。我的建议是记录“理论FLOPs利用率”和“端到端有效算力”两组值并分别绘制可扩展性曲线。前者反映算法缩放趋势后者反映工程可扩展性。写在最后我踩过几次坑之后的一些体会可扩展性评估做多了我会先画好一张三列表格一列是模型尺寸一列是数据总量一列是总FLOPs然后逼自己先写清楚每个配置背后的经济学理由。不要拿到模型就开跑先想清楚对比口径否则跑完一轮节奏不一定能快速收敛。实战中我最推崇“先小后大、多关注趋势、少在意绝对点”的心态。两个模型尺寸下的loss差异不如五个尺寸点下拟合出来的幂律指数重要。后者才是可扩展性的稳定指纹。另外一个小技巧也是我后期一直在用的每个实验跑完都要立即把配置和曲线导出成一份快照包括git commit号、数据版本、硬件信息、拟合参数、原始loss序列。因为可扩展性评估项目经常做到一半要加新的数据点如果你不保留完整快照几个月后你根本没法恢复当时的实验环境。我们团队现在要求每个评估任务结束后都生成一个标准化的JSON元数据文件后续所有分析都从这个文件取数大幅减少了沟通成本。最后我想说可扩展性评估的价值不在某个数据点多么漂亮而是能用几个小实验让你对大模型的边界更有数什么架构在数据充足时值得堆参数什么规模的投入开始边际递减你的硬件投入应该优先放在模型宽度还是数据清洗上。把这个评估做扎实后续每一分训练预算都会花得更踏实。