“大模型训练”这四个字，放在项目计划书里是一句话，落到工程现场就是一整套体系：数据、架构、算法、分布式、稳定性，任何一个环节掉链子，整个训练都可能停摆。我见过不少项目把预训练想成“拼算力”，结果几千张卡跑了两周，模型不是loss不降就是中途崩掉，最后发现瓶颈根本不在卡的数量上。这篇内容我想用做项目的方式，把大模型训练的基础知识系统地串一遍：先讲训练链路的整体阶段，再拆数据工程、模型架构选型、分布式训练策略和稳定性调试，最后补一些可以直接照做的参数范围和排查清单。适合两类人：一类是刚接触大规模训练、需要建立全局认知的开发者，另一类是已经能跑通小规模微调，但想把预训练和规模化训练彻底搞明白的工程师。下面直接进入正题。
1. 先把大模型训练这张地图摊开：四阶段与路线选择
很多人一想到大模型训练，脑子里只有“把数据丢进GPU跑起来”。真实情况是，一条完整链路里至少包含四个阶段，每个阶段的学习目标、数据规模、计算成本完全不同。如果不做区分，后面一切的调参动作都会变得没有依据。
1.1 一条训练链路的四个阶段
一条典型的大模型训练链路，通常分为预训练、领域继续训练、指令微调、偏好对齐。前三段解决“能力”问题，最后一段解决“可交互性”和“安全性”问题，它们消耗的时间和算力也完全不在一个量级。
| 阶段 | 学习目标 | 典型数据规模 | 计算成本占比 |
|---|---|---|---|
| 预训练 | 语言能力、世界知识、推理基础 | 数百亿到数万亿token | 占比最高，通常超过80% |
| 领域继续训练 | 强化特定领域知识 | 数十亿到数百亿token | 中等 |
| 指令微调 | 学会按指令回答问题 | 数万到数十万条样本 | 低 |
| 偏好对齐 | 输出符合人类偏好与安全规范 | 数万到数十万条对比样本 | 低 |
预训练阶段读的是海量通用语料，用自回归的方式预测下一个token。这个阶段决定了模型“懂不懂语言”、掌握多少世界知识，也是计算资源消耗最集中的地方。领域继续训练则是在通用预训练基础上，用代码、医疗、法律这类专用语料继续训练，让模型在特定领域的能力更突出。指令微调的数据形态完全不同，是成对的“问题-回答”，量不需要多大，但质量要求极高，一条低质量样本就可能让模型学到错误的行为模式。偏好对齐阶段进一步用比较和排序反馈做优化，训练目标已经不是“预测下一个词”，而是“哪个输出更符合人的期望”。
理解这四个阶段的差异，最直接的好处是：你不会再用预训练的大学习率去做微调，也不会在指令微调阶段指望模型突然学到新知识。每个阶段的收敛判据、数据配比、学习率、评估方式都应该独立设计。
1.2 从零预训练还是基座微调：成本先算清楚
这是所有项目碰到的第一个岔路口。我建议先做一个粗糙的算力估算，再决定路线。
业界常用一个经验公式来估算训练所需的计算量：训练总计算量约等于6倍模型参数乘以训练token数。写成C约等于6ND，这里的N是模型参数量，D是训练数据量。
拿一个70B参数稠密模型、训练100B token来举例：总计算量大约为6乘以700亿再乘以1000亿，得到4.2乘以10的22次方FLOPs。假设单卡BF16峰值算力为300 TFLOPS，实际有效利用率做到50%，那么单卡大约需要2.8乘以10的8次方秒，换算下来约3240天。如果用512张卡并行，理论上约6天能跑完。注意这只是理论值，真实项目里通信开销、断点恢复、中间实验调整，至少还要再预留2到3倍时间。算完这笔账后，很多团队都冷静下来了。
所以我的建议是：除非你有海量且高度专有的数据，并且业务确实要求模型内部知识边界完全可控，否则优先选择已有基座模型加领域继续训练或指令微调。微调阶段通常只需要预训练成本的十分之一，甚至更低，时间上更能接受。判断依据可以看四条：
- 是否拥有足够大规模的高质量私有数据；如果只有几十万条样本，撑不起一次预训练。
- 业务目标是“变成某个领域的专家”，还是“复用已有能力”；前者可以在通用基座之上做继续训练。
- 算力预算是否支持数周级实验；预训练项目的周期通常按周甚至月计算。
- 团队是否具备数据管线、分布式训练、稳定性排查的全套工程能力；缺一环都可能半途而废。
1.3 训练前必须确认的四个检查项
我曾经看到过项目跑了一半，团队内部对“什么是成功”都还没有共识。训练开始前，至少要把四件事写下来：
- 任务形态：是开放式生成、分类、检索还是多轮对话，目标函数和评估指标完全不同。
- 数据预算：手里实际可用的有效token数量是多少，过少时需要降低模型规模，过多时则可以适当放大。
- 计算资源：卡数、单卡算力、卡间带宽、显存大小，这些直接决定并行方案的选择。
- 验收指标：用什么验证集、什么指标判断模型是否合格，没有可量化的指标，后面的一切优化都是盲调。
这四项不是在PPT上写写就完，是要落到训练日志里的。我自己每次起训练前都会先填一张实验卡，模型规模、数据规模、预期计算量、预估耗时、验收指标全部对齐，后续任何改动都在这张卡上留痕。别小看这个动作，它能帮你后期排查问题时节省大量时间。
2. 数据工程：训练质量的隐形地基
模型能力的天花板，很大程度上由数据质量决定。这不只是口号。同样的模型架构和算力，一个团队把数据做得干净、配比合理，训练效率和最终效果能比另一个团队高出一大截。很多训练中的“玄学问题”，最后都溯源到了数据管线。
2.1 原始语料到训练样本的七道工序
从互联网上抓下来的原始文本，不可能直接送进模型。一条语料从收集到成为训练样本，至少要经过七道工序：收集清洗、质量过滤、去重、安全与隐私过滤、分词、序列打包、分片与打乱。
收集清洗阶段做的是最糙的体力活：统一字符编码，去掉HTML标签、脚本、广告噪声、乱码，过滤过短或过长的无意义文本。质量过滤阶段会按规则或分类器给文档打分，过滤掉机器生成的低质量网页、SEO垃圾内容和无信息量的口水文。去重阶段处理的是重复和近重复数据，这一关尤其关键，后面单独展开。安全与隐私过滤则是在训练前把个人敏感信息、违法违规内容剔除，这条工序必须制度化地卡在训练之前，不能抱侥幸心理。
分词阶段涉及训练词表，常见做法是基于BPE或WordPiece算法在语料上统计出词表大小，一般会选几万到十几万个token。序列打包则是把清洗后的语料拼接成固定长度的序列，因为模型训练大部分时候是按固定长度进行的，单条文档可能太短，需要把多条拼在一起，同时标记文档边界，避免让模型跨文档乱学。最后分片与打乱，把样本写入多个分片文件，并做跨分片的全局打乱，目的是让每个训练批次的数据分布尽量均匀。
2.2 去重不是省算力，是保效果
重复数据对训练的破坏，远比你想象的大。如果数据集中有大量重复片段，模型会倾向于背诵而不是泛化，训练loss看似下降很好，但验证集上的表现并不同步提升。更隐蔽的问题是，如果验证集恰好和训练数据有重叠，指标会虚高，导致你在项目后期做了大量无效优化。
常见的去重分两个层面。第一层是URL级去重：数据如果带来源链接，直接按URL去重，简单高效。第二层是内容级去重，即使URL不同，内容也可能高度相似，比如各种转载。这时候常用MinHash近似去重。思路是这样的：先把文本切成5-gram，对每个n-gram做哈希，再取多个哈希函数下的最小值组成一个签名；然后用LSH把这些签名分桶，只有进了同一桶的文档才做精确比对，避免两两比对的计算灾难。相似度阈值通常可以设在0.8到0.9之间，按照实际项目需求调整。
一个经验是，做严格去重后数据集可能减少几个百分点，但最终下游评测通常会有小幅提升。有一次我在一个中等规模的项目里对语料做文档级去重，数据集缩了约3%，但模型在评测集上的表现反而提升了约1到3个百分点，去掉重复数据后loss曲线也明显平稳了。要注意，在代码类语料上去重要谨慎，注释和模板相似不代表代码行为相同，过度去重可能把有价值的代码变体删掉。
2.3 语料配比：不同领域的数据怎么混
语料配比是一次训练前最重要的决定之一。通用网页、百科、书籍、代码、数学、对话数据，各自有不同的信息密度和语言风格。纯自然语言数据占比太高，模型推理能力会比较弱；代码和数学数据填得太多，文风和对话体验又会变得奇怪。
常用的配比思路大致是这样的范围：通用网页和百科类语料占六到七成，代码类语料占一成半到两成半，数学和科学类语料占5%到10%，书籍和长文档占5%到10%。这个比例不是绝对的，需要根据目标业务调整。如果项目主导方向是代码生成，代码比例就要大幅上调。
采样层面还需要注意两点。第一，不同领域语料原始规模差距很大，需要用重采样把比例调到目标配比，也就是对稀缺领域的语料重复采样。第二，重复采样要控制次数，同一段语料被模型见过的次数越多，模型越容易把局部模式背下来。我的经验是，高质量、高信息密度的数据可以过3到5个epoch，但通用网页语料1到2轮就差不多了。如果整体数据量不足，宁可通过降低模型参数规模来匹配，也不要靠反复反复喂同几份数据来填训练量。
2.4 数据管线工程化：别让GPU空等数据
训练框架再快，如果数据加载跟不上，GPU利用率也会掉到惨不忍睹。很多团队在大模型训练上第一次碰到的性能瓶颈，根本不是计算，而是IO。实时解析HTML、边训练边做语料清洗，这些操作会让数据管线成为全局瓶颈。
正确做法是把能离线处理的工作全部前置。语料离线完成清洗、分词、token id转换和序列打包，直接以预处理后的二进制格式存放。训练时会话时用多个进程做数据预取，把下一批样本提前搬到内存或显存，让数据处理和计算重叠起来。数据要先落本地高速盘，避免每轮迭代都访问远端共享存储，原因是网络文件系统的IO延迟和吞吐都要比本地盘差很多。
还有一个容易踩的坑是shuffle范围。如果只在单个分片内打乱，模型每个epoch看到的顺序其实是高度相关的，会影响训练稳定性。要做跨分片的全局shuffle，并且每个epoch之间重新打乱。多个epoch训练时，第二个epoch的样本顺序要和第一个epoch错开，否则模型会学到样本顺序带来的虚假规律。
3. 模型架构与超参：把算力花在刀刃上
数据准备好了，接下来是模型本身。很多团队在架构选型和超参设置上依赖直觉，结果小规模能跑通的配置，放大到大规模后直接发散。这里需要建立一套可推算、可验证的参数选择逻辑。
3.1 架构规模怎么定：从稠密到MoE
Transformer已经成为主流底座，但同样叫“70B”，架构细节可能差别很大。参数量主要由层数、隐藏维度、前馈网络倍数、注意力头数和词表大小共同决定。前馈网络倍数通常设为隐藏维度的4倍左右，词表大小则直接影响嵌入层参数，因为嵌入矩阵的参数量等于词表大小乘隐藏维度。
规模缩放不是简单把层数翻倍。实际的工程经验是，同一个参数量下，稍微深一点、窄一点的模型往往比浅而宽的模型在复杂推理上表现更好，但训练也更容易不稳定。如果你要基于已有基座继续训练，最好保持原架构不变，因为数据并行和模型并行方案往往和层数、头数强相关，贸然改动意味着整个分布式配置都要重来。
如果算力预算固定，还想扩大模型容量，可以考虑混合专家架构MoE。它的核心思想是把前馈网络替换成多个专家子网络，每次只激活其中几路。同样的总参数量下，MoE的激活参数更少，计算成本更低，但引入了负载均衡和专家通信问题，工程复杂度明显更高。新手团队我不建议一开始就上MoE，先把稠密模型吃透更划算。
3.2 核心超参数：学习率、batch size、warmup、权重衰减
超参数的选择逻辑，比具体数值更重要。下面是两组我常用的经验范围，分别对应预训练和指令微调场景：
| 超参数 | 预训练常见范围 | 微调常见范围 |
|---|---|---|
| 学习率 | 1e-4到3e-4，随模型规模增大而降低 | 1e-5到2e-5 |
| 调度方式 | 余弦衰减，最终降到峰值10%左右 | 余弦或线性衰减 |
| warmup步数 | 总步数的0.5%到1% | 100到500步 |
| batch size | 按token算，每次迭代覆盖数百万token | 几十到几百条样本 |
| 权重衰减 | 0.1 | 0.01到0.1 |
| 梯度裁剪 | 1.0 | 1.0 |
| Adam优化器beta2 | 0.95 | 0.99 |
模型规模越大，对学习率越敏感，学习率设置过高通常表现为loss前期不降、中期震荡甚至直接发散。大batch训练时，步数减少但每一步更“稳”，为了对冲稳定性需要更长的warmup，让优化器状态先稳定下来再进入高学习率阶段。
关于loss的数值范围，可以提前算一个基线：如果词表大小是五万，均匀随机预测的交叉熵大约等于10.8。训练刚启动时loss接近或略高于这个值是正常的，如果启动后远低于这个值，反而要怀疑评估数据是不是和训练数据重叠了。有了这个参考，就不会被训练初期的“异常数值”吓到。
3.3 长上下文训练与注意力开销
现在很多场景需要长上下文能力，但序列长度增加，注意力机制的显存和计算开销都会快速上涨。直接训练超长序列，一张训练卡很快就会OOM。
常用的做法是课程式长度扩展：先拿较短序列比如2048训练稳定，再逐步拉长到8192、32768。这么做可以提升训练稳定性，也大幅节省前期算力。位置编码方面，旋转位置编码是主流方案，它天然具备一定的长度外推能力，但外推长度越长，效果衰减越大，所以不能完全依赖外推兜底。
长上下文场景还应该关注KV Cache。推理时缓存历史token的键值向量是必须的，缓存大小与层数、注意力头维度、序列长度成正比，长上下文下它是显存的主要占用者。训练时则可以通过稀疏注意力、滑动窗口、局部注意力等机制来降低计算和显存压力。这也是为什么很多大规模模型在长文本任务上会做分层设计，而不是简单地把上下文一步扩得非常大。
4. 分布式训练：把几千张卡组织成一个大脑
单卡显存放不下大模型，训练又要跑很久，所以分布式训练是绕不开的环节。这里最容易犯的错误是只盯着一两种并行方式看，忽略了它们之间的组合关系。我把并行方案摊开讲一下，帮你建立一个整体坐标。
4.1 四种并行方案的分工与配合
大模型训练里的并行，核心就四类：数据并行、张量并行、流水线并行、优化器状态分片。它们的切分对象完全不同。
| 方案 | 切分对象 | 适用规模 | 主要通信开销 |
|---|---|---|---|
| 数据并行 | 不同batch样本 | 大规模，千卡级别 | 每步all-reduce梯度 |
| 张量并行 | 每一层内部的矩阵参数 | 单机多卡，通常不超过8卡 | 每层前向反向多次all-reduce |
| 流水线并行 | 按层切分，不同设备负责不同层段 | 跨多节点 | 层间点对点通信、流水线气泡 |
| 优化器状态分片 | 优化器状态、梯度或参数分片到各卡 | 超大模型、长上下文 | all-gather参数、reduce-scatter梯度 |
数据并行最直观：每张卡都有完整模型副本，喂不同批次的数据，每步同步梯度求平均。问题在于模型太大时，单卡装不下。张量并行解决单卡装不下的问题，把一层的矩阵切分到多张卡上，相当于一个层由几块卡共同计算，但通信量很大，一般只在单机内部用，因为机内带宽远高于跨机。流水线并行则是把几十上百层模型切成几段，每张卡负责一段，数据像流水线一样流过各段，代价是模型和流水线气泡带来的闲置。
优化器状态分片是完全不同的思路。它不把模型层切开，而是把Adam优化器状态、梯度甚至参数分片到多张卡上。它和数据并行可以叠加使用：每个数据并行副本内部做参数分片，这样既能扩大batch，又能大幅降低单卡显存。
实际配合遵循一个原则：数据并行作为最大外层的扩展维度，内部用张量并行和流水线并行解决单卡装不下的问题，再配合优化器状态分片进一步压显存。举例来说，如果一张卡负责模型层的四分之一，那张量并行度就是4；又因为显存还是不够，优化器状态分片再加一档，单卡峰值显存就能明显降下来。
4.2 混合精度、梯度累积与显存账本
混合精度训练是主流做法。BF16格式和FP32的指数位一致，在大模型训练里数值稳定性比FP16好不少，不需要维护loss scaling，基本开箱即用。FP16则需要配合动态loss scaler，否则小梯度容易被截断成0。
显存需要从一开始就算清楚。以70B稠密模型、BF16精度为例，模型权重本身就占140GB。梯度跟参数同尺寸，又是140GB。Adam优化器通常要保存FP32主权重、一阶动量、二阶动量，综合下来权重、梯度、优化器状态三者加起来大概是参数量的5到6倍，也就是说70B模型训练状态最少需要350GB以上的显存，这还不算激活值和KV Cache。单张卡是绝对放不下的，必须靠分片和激活检查点来分担。
梯度累积解决的是batch size和显存解耦的问题。当显存放不下更大batch时，可以先把多批梯度累计起来，再统一更新一次参数。本质上它不是让优化器看到“更大batch”，而是让通信频率降低、数值更稳定。但要注意，梯度累积到一定程度后，步数变少，学习率调度和warmup步数都要按实际更新次数来算，不能照搬原始设置。
4.3 一个典型的分片训练配置长什么样
很多开源框架都提供一套配置接口，虽然名字不同，但底层逻辑一致。我下面给出一个典型的分片训练配置片段，字段含义按通用逻辑理解就行：
{ "sharding": { "stage": 2, "reduce_scatter": true, "overlap_comm": true, "contiguous_gradients": true }, "optimizer": { "type": "adamw", "params": { "learning_rate": 1e-4, "weight_decay": 0.1, "betas": [0.9, 0.95] } }, "gradient_clipping": 1.0, "activation_checkpointing": true }stage设置成2，代表把优化器状态分片到各卡，梯度仍然采用reduce-scatter方式先合并再分发。overlap_comm表示通信和计算重叠开启，能有效掩盖跨卡通信延迟。contiguous_gradients是把梯度放进连续内存，减少碎片化分配带来的开销。
activation_checkpointing是另一个关键开关。开启后，前向过程中不保存所有激活值，只在需要反向计算时重新计算一部分，能把激活显存下降一个量级，但代价是额外算力。所以开启前要实测吞吐影响，通常显存紧张时先开激活检查点，再考虑调整分片等级。
5. 训练监控、恢复与稳定化实战
模型能跑起来只是第一步，真正烧掉项目大量时间的，是训练过程中出现的各种问题。这里分享一套我长期使用的监控与排查动作。
5.1 看板指标：不是只有loss
训练看板上至少要同时看六个指标，而不是只盯loss。第一个是训练loss和验证loss，两者要分开展示，中间差距过大说明模型在背训练集。第二个是梯度范数，它应当整体稳定在某个量级，持续上升通常意味着训练状态开始不稳。第三是学习率曲线，确认warmup和衰减确实按预设走，很多时候loss异常其实是调度器配置失效。第四是吞吐量，一般用每秒处理的token数来衡量，除以卡数后才知道单卡效率。第五是MFU，即模型FLOPs利用率，指实际算力占理论峰值的比例，稠密模型做到40%到55%算正常，MoE通常低一些。第六是显存占用，一旦接近上限，后续随时可能OOM。
看loss曲线时，横坐标应该用“已经处理的token总数”，而不是训练步数。因为batch size不一致时，步数没有可比性，按token数画才能在模型规模不同的实验之间做对比。另外，loss曲线的横纵坐标都建议做平滑处理，否则原始曲线的抖动会把趋势掩盖掉。
5.2 检查点：不只是存模型权重
训练中断是最常见的事。检查点保存得对不对，直接决定恢复训练时是否前功尽弃。很多人只保存模型权重，恢复后warmup状态、学习率调度、数据顺序全部错乱，效果大打折扣。
一份完整的检查点至少应该包含：模型权重、优化器状态、学习率调度器状态、RNG随机数状态、数据加载索引和分片信息。优化器状态不保存，重启后等于优化器重新初始化，warmup白做；RNG状态不保存，shuffle顺序会变化，后续数据分布和断点前不连续；数据加载索引不保存，稍有不慎就重复或跳过了部分数据。
保存频率要按训练规模权衡。保存太频繁，IO开销拖慢训练；保存太少，一旦中断丢失太多进度。通常的做法是每几百步保存一个完整主检查点，每隔几十步保存一个临时轮询检查点。因为主检查点往往有几个GB甚至上百GB，写盘速度不能忽略。异步保存到独立存储路径，不要阻塞训练主循环。
恢复训练后，第一件事是打印恢复前后的loss曲线，确认曲线是连续下降而没有跳变。只要曲线出现明显的“断层”，基本就是某个状态没保存成功，要立即停下来检查保存逻辑。
5.3 高频问题与排查清单
训练过程中遇到问题，先看日志，不要盲目调参。我整理了一份高频排查速查表：
| 现象 | 可能原因 | 定位方式 | 处理建议 |
|---|---|---|---|
| loss不降或高位震荡 | 数据标签错、学习率过低、模型初始化异常 | 打印训练样本检查、缩小batch试跑 | 修数据、调lr、重新初始化 |
| loss定期尖峰 | 学习率过高、数据混入噪声、梯度异常 | 观察梯度范数是否同步飙升 | 降lr、加大warmup、加强梯度裁剪 |
| loss出现NaN | 数值溢出、数据异常、分片配置不一致 | 打开溢出检查日志 | 换BF16、降lr、核查数据管线 |
| 吞吐不足 | 通信阻塞、数据IO慢、有效batch太小 | 看通信占比和GPU利用率 | 增大batch、开通信重叠、数据本地化 |
| OOM | batch过大、激活占用过多、分片不足 | 打印显存分配信息 | 开激活检查点、降低序列长度、提高分片等级 |
排查有一个重要原则：一次只改一个变量。我见过好多次训练出问题后，团队同时改了学习率、batch size、数据配比、并行方案，结果问题还在，却完全不知道是哪一步改坏的。正确做法是先把问题最小化，比如batch降到8、序列长度压到512，确认基础路径正常，再逐步恢复原始配置。
6. 最后一点经验：先把小实验跑明白再上规模
前面写了这么多，最后想聊几句实际操作层面的话。以我参与过多个训练项目的体会看，最重要的事情排序是：数据质量大于数据规模，数据规模大于模型容量，模型容量大于调参技巧。纸面算力只是起点，真正烧时间的往往是数据管线的bug和训练状态的不稳定。
动手前一定先把“训练实验卡”写好，记录目标、数据规模、并行方案、超参、日志路径和验收指标。每次修改都有依据，而不是凭感觉。另一个我一直坚持的小技巧是：大规模训练正式启动前，先跑一个缩小版实验，用百分之一的数据量、十分之一的模型规模，让loss在几个小时内出现明显下降趋势。这一趟小实验能提前暴露大部分管线问题，帮你节省至少数周时间。项目后续如果要做长上下文扩展、领域继续训练或者偏好对齐，我建议方向上也保持一致：每一步都先用最小配置验证，再逐步放大。
