大模型预训练这几年被讨论得越来越多但真正上手跑过一版端到端流程之后你会发现Scaling 这件事远不是“堆算力”三个字就能概括的。它牵扯到模型参数体量与数据配比怎么定、卡与卡之间怎么切分分工、通信拓扑怎么排布这些安排在开跑之前就已经决定了你后续几个月的成本曲线和产出的模型质量。参数配比和并行策略正是预训练里最核心的两个抓手。这篇文章写给正在规划真实预训练项目、或者准备从单卡迁移到多卡训练的团队我会按自己实际踩过的坑把从参数设计到并行落地的完整链路拆开讲。1. 预训练前的设计哲学目标、数据与算力的三角均衡1.1 先别急着把模型变大先定义“大”的方向不少团队启动预训练项目时的第一反应是“我们也要训练一个几百亿参数的模型”但这个目标如果脱离数据和算力直接拍板后面基本都会被卡住。大模型规模的定义不只是一个参数总量而是三件事的组合模型容量参数量、训练数据规模Token 总量、可承受的算力开销GPU 卡数和时间。业界的可扩展性规律研究给出过一个粗粒度参考在算力预算固定的前提下模型参数量和训练 Token 数量存在一个性价比最高的配比点。注意这个配比不是固定值而是一个区间。稠密语言模型实测下来当 Token 数与参数量比值维持在 15:1 到 30:1 之间损失的下降效率通常比较理想。明显低于这个比值模型容易欠拟合数据反复过量套用会导致收益递减明显高于这个比值参数体量又撑不起那么多数据的知识容量训练后期 loss 会提早进入平台期。实际操作中很多团队手里的有效数据远没有想象中充足。我见过一个项目规划 7B 模型按 20:1 需要 1400 亿 Token但清洗后可用高质量中文语料只有 600 亿。这时候就不是硬凑 1400 亿而是反过来调小模型规格或者接受模型本身的容量上限把目标定成领域模型。这个决策要在项目第一周就完成否则后面所有并行策略都是白设计。1.2 数据配比与采样策略的全局观参数配比中数据配比经常被忽略。预训练数据的领域构成直接影响模型的行为能力。实际训练中建议先把数据按领域进行占比拆分比如通用文本、代码、数学、多语言各占多少。这个占比不是拍脑袋定的要结合模型的最终使用场景。比较稳妥的做法是先用小规模的实验网做一次数据配比的消融。比如用 10 亿参数级别模型在 50 亿 Token 的规模上分别验证代码占比 5% 和 15% 时下游代码任务与通用能力的变化。这种对比要花一周时间但它能避免正式训练走完全程之后才发现模型偏科。我在实际项目中还踩过另一个坑数据批次内数据的熵过低。如果某一轮数据抽样里某个领域的文本特别多当轮 loss 会异常下降后续恢复正常配比时 loss 又回升形成锯齿状波动。曲线抖动加大之后学习率调度会很难做降低的时候可能刚好撞上尖峰导致模型在局部最优里出不来。所以公用的采样器最好带一个全局的领域配额控制而不是简单地每个 batch 独立随机。2. 参数配比的核心拆解从公式到实际显存账本2.1 用一条近似公式做初始设计Transformer 类稠密模型的参数量业界经常用一条近似公式来估算参数量 ≈ 12 × 层数 × 隐藏维度²假设一个 24 层的模型隐藏维度 4096那么 12 × 24 × 4096² ≈ 48.2 亿参数。这个估算包含了 Attention 的 QKV 矩阵、输出矩阵和 MLP 的上下投影矩阵。Embedding 层通常单独算一般考察词表大小乘以隐藏维度。如果词表是 5 万隐藏维度 4096那么 Embedding 参数就有约 2.05 亿。这里有一个很重要的设计选择输出层的 Embedding 是否与输入层共享。共享的话能省下不少显存但会限制模型在输出端的表征能力。在中小规模模型1B 到 10B上共享是常见操作因为词表占据的比例不小到了 30B 以上很多团队会考虑解绑因为容量够大可以承受一点参数占用换取表达能力。MLP 的中间维度也值得注意。经典的配置是中间维度等于隐藏维度的 4 倍即 FFN 部分占比高这也是为什么总参数公式里 12 这个系数的来源Attention 占 4 份MLP 占 8 份合计 12 份。有些模型为了提高 MoE 扩展性把 MLP 中间维度略微压到接近 8/3 倍隐藏维度这时 12 系数的公式就不再准确需要分模块单独核算。如果照搬公式后面估算显存和算力开销时会出现偏差。2.2 参数量与激活显存的实际账本参数配比不只是“模型文件多大”的问题预训练过程中真正吃显存的大户除了参数本身还有前向传播时保存的激活值。每张卡上的激活显存近似正比于序列长度 × 每层激活字节数 × 微批大小。我这边习惯用三部分来估算单卡显存占用模型参数与梯度每个参数在 FP16 下占 2 字节梯度又占 2 字节Adam 优化器状态一阶动量 4 字节FP32二阶动量 4 字节FP32加总共 8 字节每参数激活值这个最容易被忽略实际测试里长序列8K 甚至以上场景下激活显存会超过参数显存。举例来说一个 7B 参数的模型如果单卡要放下完整的模型参数、梯度和优化器状态至少要(2244) × 7B 84GB的显存这已经超过了单张 80GB 卡的容量。所以必须配套切分策略或者选择性 offload而不是指望一张卡能装下所有状态。这也是为什么并行策略不该在参数配比之后才考虑两者必须同步设计。先估好参数量与激活量再确定每卡需要多少显存然后才能定并行维度怎么切。2.3 超参数中的隐藏调节阀学习率、批次大小与序列长度参数配比还包含一部分软性设计即学习率、批次大小、序列长度之间的联动。批次大小Global Batch Size与学习率存在一个经验性的缩放关系批尺寸增大到参考值 K 倍时学习率通常需要按大约 sqrt(K) 的比例上调但超过某个阈值很多场景是 4096 条样本以上后再上调学习率容易造成训练不稳业界常见的处理是改用学习率预热Warmup加余弦退火。这个节奏直接影响 loss 曲线的平滑程度预训练中建议把 Warmup 步数设成总步数的 1% 到 2%而不是固定几百步。序列长度方面当前主流做法是先短后长。比如先用 2048 的序列长度跑前面 80% 的进度后续阶段逐渐拉升到 4096 甚至 8192。这么做的好处一是加速前期迭代二是让模型先在短上下文内学会基础语义再进长上下文的注意力交互。需要留意的点是切换序列长度时学习率调度不能简单继续走否则注意力机制的分布突变会带来 loss 尖峰。我在实际项目里一般会把最后 10% 的步数留给加长为长上下文后的稳定训练同时把学习率再降一个数量级。3. 并行策略深度实战数据、张量、流水线怎么取舍3.1 数据并行与 ZeRO 的边界数据并行Data ParallelismDP是最容易理解的并行方式每张卡都有一份完整模型各自处理不同的微批数据反向传播完成后做梯度同步。它的优点是实现简单扩展性几乎和卡数线性挂钩不考虑通信开销的情况下。但前面提到的显存账本已经表明当模型增大到一定程度单卡连完整状态都放不下时纯 DP 就没有立足之地了。DeepSpeed 的 ZeRO 优化器就是为了解决这个问题产生的。ZeRO-1 把优化器状态切分到多卡ZeRO-2 额外切分了梯度ZeRO-3 把参数也做了分片。开 ZeRO-3 之后每张卡只保存模型参数的一部分配合通信收集前向所需的完整参数更新单卡显存压力大幅下降。但 ZeRO 不是没有代价。它在每个 Transformer 层的前向和反向过程中都会插入额外的 AllGather 通信如果所用节点内的 NVLink 带宽不够或者跨机走的是低带宽网络很容易产生通信瓶颈。实际使用 ZeRO-3 时我通常会结合梯度累积和通信重叠配置确保计算和通信不是串行等待否则训练吞吐率会比预期低 30% 以上。数据并行与 ZeRO 适用边界的判断标准不复杂如果模型单卡能完整放下且还有富余空间优先用纯 DP 加 ZeRO-1因为它通信开销最小如果模型大到单卡放不下完整参数才考虑 ZeRO-2 或 ZeRO-3。注意 ZeRO-3 切分不难难的是遇到通信热点时要在模型层内手动做通信与算子重排。3.2 张量并行让单卡装不下矩阵变成装得下张量并行Tensor ParallelismTP是解决“单个权重矩阵太大一张卡放不下”的方案。做法是把某一层权重按行或按列切分成多份每张卡持有矩阵的一个切片计算时通过 AllReduce 汇总部分结果。举个例子一个隐藏维度 4096 的 Attention 输出投影矩阵形状是[4096, 4096]如果 TP4则每卡只保存[1024, 4096]的切片前向计算出局部结果后通信聚合。这个切分减少了单卡参数占用但带来了额外的通信量。TP 的通信频率非常高基本每个 Attention 层和 MLP 层都要做两次 AllReduce因此它通常只适合在同一节点内使用依赖 NVLink 这类高带宽低时延的互联。TP 维度要多大的问题实际经验是单卡显存只要放下了权重切片就不要继续加大 TP因为通信代价增长很快。以 8 卡 A 节点为例TP8 是极限配置但通常 TP4 时计算通信比更优。TP 调大的另一个坏处是如果某个 GPU 发生故障整个张量并行组都会受影响可用性下降。在实际框架中TP 还要考虑ColumnParallelLinear与RowParallelLinear的配对关系。列并行从输入侧切行并行从输出侧合两者必须配对才能保证整体语义不变。理解和验证这一点通常是在刚做完切分时用一个固定输入对比切分前后的 logits 是否一致。3.3 流水线并行微批次调度让气泡没那么可怕流水线并行Pipeline ParallelismPP按照层对模型进行切分每个 stage 放在一组设备上。第 1 层到第 N 层在设备 1 计算完再把中间结果传给设备 2 算后续层。这个方案最大的问题是流水线气泡前半段设备在等待后级设备空闲后半段前级设备又已经空闲。业界常用的解决办法是切分出多个微批micro-batch把这些微批在流水线中交错执行。经典的 1F1B 调度会在前向和反向之间交替排布让设备和通信尽量满负荷运转。另一个改进是交错式调度把每个设备上划分多个 stage 小段减少气泡占比但代价是通信次数增加。实际使用 PP 时还有两个经验点。第一各 stage 的计算量要尽量均衡。比如 24 层模型切给 4 个 stage每个 stage 6 层这是理想情况。但如果是 Embedding 和输出层占比较大、层数又无法均分时会出现一个 stage 比其他 stage 慢很多拖慢整个流水线。这种情况要考虑把 Embedding 层并入第一个 stage、输出层并入最后一个 stage甚至用虚拟流水线来细化切分粒度。第二PP 组内部不要在非常慢的节点间跨机通信。流水线阶段间的通信是逐层传递的中间激活单次数据传输量可能很大网络带宽不够时流水线后半段几乎处于停滞状态。节点间用更高速网络互连节点内用 NVLink是 PP 排布的基本前提。3.4 混合并行DP、TP、PP 如何排列组合实际预训练中很少只用一种并行方式。常见的混合策略是先用 TP 和 PP 把单台机器内的显存打散到合理水平再用 DP 增加整体并行度。比如 64 卡集群上常见配置是DP4, TP4, PP4翻译过来就是 4 个数据并行副本每个副本内部 4 张卡做张量并行再 4 个流水线 stage。选择这三个维度时要按顺序思考先看单机卡数和卡间带宽确定 TP 大小的上限。单机 8 卡 NVLink 下TP 建议 4 或 8再看模型层数是否适合切 PP stage。每段若能分到 4~8 层 transformer是比较健康的区间最后用 DP 把总卡数补齐。如果多出来的卡数不足以组成完整的 DP 副本就要回头调 TP 或 PP。还有一种并行维度是上下文并行Context ParallelismCP主要针对长序列场景把序列维切到多卡上分别处理注意力。如果预训练目标就是超长上下文CP 值得引入但它通常和 TP 有通信叠加不是简单地替换关系。我的建议是只有当序列长度超过 16K 且单卡激活显存已经爆炸时再上 CP别为了追求“并行维度全都要”而牺牲实现复杂度。4. 实操步骤与关键节点从配置到稳定训练4.1 一份可直接参考的预训练启动清单以下是我在正式预训练前必做的启动清单按顺序执行能省掉不少后期排查成本确定模型配置层数、隐藏维度、头数、FFN 中间维度、词表大小并用近似公式核算总参数量确定训练 Token 总量校验参数 Token 比是否落在 15:1 到 30:1 区间否则回看模型配置是否要调整核算单卡显存账本模型参数 梯度 优化器 激活值判断是否需要 ZeRO、TP 或 PP在真实集群上运行一次通信测试确认卡间带宽符合预期记录每个节点的实际拓扑用 1 到 2 次小配置的预训练验证数据配比、学习率预热与调度策略确认 loss 曲线在预期范围内启动正式训练前 500 步内密切观察 loss、吞吐量、通信占比与显存稳定度确认各项指标达标后再进入长稳阶段。这份清单看上去基础但很多项目正式训练翻车恰恰是因为前面的一两步没有做扎实。我见过最典型的情况是模型配置直接照搬论文里的参数却忽略了自家数据量远小于论文章节训练占用结果训练到了 30% 进度loss 就已经没有明显下降进退两难。4.2 选择的基准配置示例这里给一个 13B 稠密模型的参考配置方便理解参数配比到并行策略的推算过程。隐藏维度 5120层数 40词表大小 5 万输入输出共享MLP 中间维度 13696约为隐藏维度的 2.7 倍平衡部分参数开销全局批次大小 1024序列长度 4096激活参数约 13B加上 Embedding 共享后内存折算相对减少。按近似公式粗算40 层 × 5120² × 12 约 12.58B嵌入层参数约 2.56 亿总计接近 13B。训练 Token 规划 2600 亿参数 Token 比为 20:1落在合理区间。显存估算上每个参数需要 FP16 权重镜像 2 字节、梯度 2 字节、Adam 状态 8 字节每参数总占用约 12 字节。13B 参数全状态就是 156GB。因此单卡 80GB 不可能放下完整状态。结合 64 卡集群我选了TP4, PP4, DP4的混合并行配合 ZeRO-1 做优化器状态分片让单卡实际承载约 3.3B 参数的状态量显存余量足够支撑 4096 序列下的激活缓存。这个配置启动后我实测到的卡间通信占比在 25%~35% 之间吞吐约 38% 到 45% 的算力利用率MFU属于正常范围。如果 MFU 低于 25%就要怀疑是不是并行维度配比失衡或者数据加载耗时过长。4.3 训练过程中的监控与动态调整预训练过程不是设定完参数就等结果的尤其初期要盯紧三类指标。第一类是 loss 曲线形态。正常情况下 loss 会持续下降但斜率逐渐变缓。如果在某个阶段出现不下降或者上升第一个排查方向不是并行策略而是数据配比和梯度更新是否正常。查看模型每一层的梯度范数有无异常爆炸是快速定位问题的最佳切入口。第二类是吞吐量指标包括每秒处理的 Token 数与单卡 MFU。记录一个基线值如果后续迭代吞吐急剧下降多半是通信热点或数据加载的 IO 瓶颈问题。这时用性能剖析器分别统计通信耗时、算子耗时和数据加载耗时定位比重异常的部分再处理。第三类是显存水位曲线。如果显存使用量随时间持续上涨要优先怀疑框架内部的缓存泄漏或动态 shape 导致的显存碎片化而不是简单调低批次大小。预训练过程中显存要尽量保持平稳频繁显存分配和释放会拖慢性能严重时导致 OOM。动态调整方面最常见的两个操作是模型进度超过一半时重新评估全局批次大小与学习率序列长度切换后重新跑一次基准测试确认长序列下激活显存仍在安全水位。5. 常见问题与排查技巧实录5.1 显存溢出OOM的排查顺序预训练里 OOM 太常见了而且未必是模型参数过大造成的。建议按下面的顺序排查先看批次大小是否过大。全局批次大小除以数据并行度和流水线微批数之后才是单卡实际批次大小很多人忘了换算导致 OOM再看激活显存。长序列场景下把序列长度调小一点或者打开梯度检查点激活重计算能显著减少激活占用然后检查优化器状态分片是否生效。如果预期开启 ZeRO 却没生效单卡显存很容易在整机上 80GB 直接打爆最后检查是否启用了不必要的动态图操作比如在训练循环里使用 Python 控制流导致显存峰值积累。OOM 发生后训练中断的恢复策略也要提前准备。比较稳妥的做法是周期性保存模型权重和优化器状态恢复后从最近的检查点继续并跳过部分数据批次避免同样的数据被前序后续各训练一遍。5.2 吞吐率上不去通信瓶颈还是算子瓶颈吞吐率下降时先分清楚瓶颈在哪。一个简单的判断方法是把数据加载耗时、通信耗时、算子计算耗时分别打点记录如果通信耗时占比超过 30%说明通信瓶颈如果算子计算耗时占比偏高说明算力本身没有发挥出应有水平。通信瓶颈的常见表现是跨机通信带宽不够。TP 维度跨机时每次 Attention 和 MLP 后的 AllReduce 都要过机间网络带宽一旦受限整体吞吐直接塌。解决方案是把 TP 限制在单机内并用 PP 承担跨机切分。算子瓶颈的常见原因是小算子过多。比如模型实现里频繁调用单独的矩阵乘法和逐元素操作而不把它们融合起来导致 GPU 的空闲等待时间变长。用融合算子Fused Kernel实现 QKV 投影合并、MLP 上下投影合并是常见的性能修复手段。5.3 Loss 不收敛和锯齿状曲线的排查Loss 不收敛的原因通常不在并行策略上而在优化器、学习率和数据配置上。我建议按以下路径检查检查学习率是否过大或过小。过大时 loss 会在早期震荡甚至发散过小时 loss 下降速度令人绝望检查梯度是否出现异常值。用梯度范数日志观察如果某步梯度过大考虑启用梯度裁剪检查数据是否存在泄漏或噪声。某些语料中混入了大量乱码和重复文本会让 loss 长期徘徊在某个高位检查混合精度配置。如果使用 FP16 而不是 BF16在某些场景下可能会遇到数值溢出问题切换到 BF16 后训练稳定性会明显改善。锯齿状曲线的处理我之前提过关键在于全局数据采样配额。每轮数据批次中的领域比例要相对稳定尤其是代码和数学这类高方差数据要按全局比例进行采样而不是让它在某个窗口内集中出现。5.4 并行配置失效和通信拓扑不一致多机训练中还有一个隐蔽问题并行配置看起来正确实际通信拓扑却不是想要的。比如配置 TP4、PP2但框架实际将 TP 组跨到了不同节点的卡上导致每次张量并行通信都走跨机带宽性能骤降。排查这类问题时一般要看设备分配映射表确认每个 TP 组内的设备是否在同一台机器上。这个检查必须在训练启动初期做一次不要等到后续性能下降再回头。启动日志里通常会打印各进程的全局 rank 与本地 rank 映射关系对照检查即可。另外多机网络的拓扑感知如交换机层级对大规模训练的影响也不小。如果两层交换机之间的上联带宽不足跨设备通信会受很大限制。有条件的话尽量让一个 DP 副本的程序跑在同一交换域内避免跨层级网络的大量流量。6. 一些实际操作中的体会做了几轮预训练之后我最大的感受是Scaling 不是一个单点问题而是一连串决策相互嵌套的系统工程。参数配比影响显存账本显存账本反过来又限制并行维度并行策略又决定了通信拓扑通信拓扑最后又决定你选的框架配置能否发挥出真实算力。任何一个环节拍脑袋后面都会在昂贵的一次次实验里付出代价。还有一点想提醒的是别迷信“更大一定更好”。如果一个团队的算力只够撑起 10B 模型的 Token 量那强行上 30B 模型只会得到半个训练好的模型这个失败成本可能好几个月都缓不过来。务实一点先做能完成的事情让每一个参数都吃到应有的数据再谈下一步扩展。最后分享一个实用小技巧在正式启动大规模训练之前在相同并行配置下用一个 3 到 5 分钟的小实验比如几千步跑一次完整的参数初始化、前向反向、优化器更新和周期性检查点保存。这个小实验能暴露出绝大部分配置问题远比直接跑长时间训练再中断排查要便宜太多。