训练一个模型的门槛，这些年被各种开源项目拉低了不少。很多人以为只要有几张显卡、准备一份数据集，就可以把训练跑起来。但实际上，当你真正去翻大模型的训练日志，看到loss曲线在几千步里纹丝不动，或者因为一个学习率设置不当导致loss爆炸，才会意识到“训练”这两个字背后藏着的是一整套系统工程。
这篇文章我想把自己在训练大模型过程中的经验做个梳理——包括数据怎么处理、超参数怎么定、并行策略怎么选、训练出问题怎么排查。内容面向的是准备开始训练自己模型、或者正在带团队做训练的开发者。搞清楚一个模型从零到能用的完整链路，比单纯跑通一个demo重要得多。
1. 训练这件事，真正在干什么
1.1 训练的起点不是代码，是目标定义
训练大模型的第一个问题不是“用什么架构”，而是“这个模型拿来干什么”。同一个架构，做对话和做代码补全，数据配比、训练阶段、评估方式完全不同。
我在带一个项目的时候，曾经直接把对话模型的训练流程搬到了一个做代码生成的模型上，结果生成质量始终不理想。当时没有意识到：代码数据对格式的敏感性远高于自然语言，一个缩进错误就会让整个函数不可用。后来单独增加了代码数据的比重，并且在训练阶段加入了“格式化完整性”的专门评估项，效果立刻不一样。
所以在动工之前，建议先明确三件事：
- 模型的输入输出形态是什么，是短文本对话、长文档生成，还是结构化内容输出
- 最看重的指标是什么——答案准确性、格式规范性，还是风格一致性
- 数据来源有哪些，数量和清洗成本大概是什么量级
很多训练项目没有定义清楚这些问题就直接进了数据整理环节，结果后面反复返工。我在实际项目中体会最深的一点是：训练前多花一周做目标定义和数据分析，能省下后面一个月的调参时间。
1.2 算力、数据、模型三者的不匹配是最大的隐性成本
训练大模型，最常被低估的事情是算力、数据和模型规模三者之间的匹配关系。见过一些团队在算力有限的情况下强行训练十几B的模型，结果一个迭代周期要跑三周，每个参数实验的代价高到无法接受。其实同一个任务，用更小的模型配合更高质量的数据，效果未必差，但迭代速度快得多——小模型跑实验、验证思路，大模型做最终的训练和微调，这个节奏才是稳妥的方案。
数据规模也一样。模型参数越多，越需要海量数据来支撑。如果数据量不够，大模型反而比小模型更容易过拟合，训练中后期loss曲线开始分离，而验证集效果并不提升。这时候优先做的不是加算力，而是回头检查手里的数据量到底够不够。
2. 数据：比模型更值得花时间的部分
2.1 数据来源与筛选
大模型的数据来源现在大致有几类：一是开源数据集，二是爬取的网页数据，三是领域业务数据。开源数据集清洗成本低，但同质化严重；爬取数据覆盖面广，但噪声大；业务数据质量高，但往往体量小。
数据筛选的经验做法是分两层走。第一层做粗筛，用规则和启发式方法过滤掉明显无用的内容——重复网页、乱码文本、超短碎片、纯广告词。第二层做细筛，用质量评分模型给文本打分，把低质量数据剔除出去。我自己在处理爬取数据时常用一个“三连法则”：连续出现三行以上无效符号、连续重复的字符比例超过百分之五、一句话里超过两个HTML标签残留，都会直接剔除。这套规则虽然简单，但能清理掉相当一部分脏数据。
粗筛过滤掉明显无意义的噪声，细筛保障最终数据的质量曲线。很多模型训练出来效果不理想，追根溯源是第二步没做好，数据里面混了太多低质量文本。
2.2 清洗与去重
清洗是数据环节里最枯燥但又最重要的一步。文本里残留的HTML标签、异常空格、不可见字符、编码错误，都会在tokenize阶段产生大量无效token，白白消耗模型容量。我处理文本时通常会过一遍统一管线：先转码统一为UTF-8，再做标签剥离和空白归一化，最后用规则表达式处理异常字符。
去重是另一个常被忽视的环节。互联网上大量内容都是转载和改写，不去重的话，模型会反复“背诵”同一批内容。我之前用MinHash做去重，把文本归一化后计算特征指纹，通过计算两两之间的相似度来控制重复度，效果非常明显。去重后再配合一个“保留多样性”的策略，确保同一主题的语料在数据集里不会过于集中。
2.3 数据配比与采样策略
数据配比决定了模型的“性格”。如果你希望模型既懂通用对话又懂代码，就不能简单地把代码数据直接混进去，需要按比例采样。举例来说，常见配比是通用语料占大头、代码和数学数据做加权。多领域数据混在一起时，如果某一个领域的数据量过大，模型在这个领域的loss会降得很快，但其他领域的loss可能会抬高，出现“偏科”现象。
我常用的做法是根据token数量而不是样本数量来配比。因为不同数据集的单条平均长度差距可能很大——代码数据一条可能几百个token，论文数据一条可能几千个token。按token数来算比例，才能在训练中保持平衡。配比确定后，还可以给不同领域设置采样权重，在训练过程中做微调。如果训练到一半发现某一类任务的效果偏弱，可以把这类数据的采样权重调高，再做几轮增量训练。
3. 模型结构与初始化
3.1 架构选型
模型架构很大程度上决定了训练的上限。当前主流的选择基本集中在Transformer的decoder-only结构上。这不是说其他架构不行，而是这个架构在生成任务上的表现经过了大量验证，工程实现的成熟度也最高。
架构选型的核心看三点——上下文长度、参数规模和部署限制。上下文长度直接影响训练时的序列长度设置；参数规模受限于推理成本和训练显存；部署限制则决定了你能否用得上量化、蒸馏等手段。对一个从零训练的团队来说，我建议先选一个公开的成熟结构，不要上来就魔改。等整个链路跑通了，再根据实际效果做针对性优化。
3.2 参数初始化
参数初始化虽然看起来不如架构和数据那么显眼，但它对训练稳定性的影响非常大。初始化不当，训练一开始梯度就可能爆炸或者消失，尤其是深层模型。常见的初始化方式包括Xavier和Kaiming初始化，它们在各自的设计里考虑了前向传播和反向传播的方差保持。对于Transformer结构，还需要对残差分支的初始化做特殊处理——通常会把最后一块残差层的权重乘一个缩小的系数，保证早期训练时残差连接不会主导整个信号。
我踩过的坑是：有一版模型初始化时用了过大的标准方差，前几百步loss就飞到了几十万，调回来之后重新训练，前面的算力全白费。初始化这个环节，宁可保守，不要冒进。
3.3 词表与Tokenizer
很多人在数据准备阶段忽略词表设计，直接沿用开源分词器，结果训练时遇到大量未登录词。未登录词多，意味着这些token永远不会被模型很好地表示，模型被迫用“未知”标记硬扛，生成质量会受影响。
如果用的是已有的开源tokenizer，做一次词表覆盖分析是值得的——统计你自己的训练语料里有多少内容被切成了未知token。如果比例偏高，可以考虑扩展词表或者在现成词表基础上做增量训练。从零训练一个BPE分词器也不难，关键是用尽量接近最终训练分布的数据来训练分词器，保证词表更贴合你的语料。
4. 训练流程四步走
4.1 预训练阶段：让模型学会“说人话”
大模型训练的起点是预训练，目的是让模型通过海量文本学习语言的基本规律——词怎么搭配、句子怎么组织、知识怎么表达。预训练使用的目标函数很简单，就是让模型最大化看到文本的概率。给定前面的词，预测下一个词的概率越高，说明模型对语言的建模能力越强。
预训练的特点是数据量大、训练步数多、计算代价极高。这个阶段一般不会刻意做任务层面的训练，而是依赖模型在自监督学习过程中自然获得的能力。你可以把预训练理解成“打基础”——地基不牢，后面做什么都很难弥补。很多人一上来就关心微调怎么做，但预训练阶段没有做扎实，微调的效果会非常有限。
4.2 学习率与超参数：手册里不会写的那些细节
训练大模型常用的优化器是AdamW，配合一个带预热和衰减的学习率策略。学习率初始值通常在1e-4到3e-4之间，但具体数值需要根据模型规模、数据量、batch size一同调整。以7B级别的模型为例，一个我实际用过的经验起点是：学习率3e-4，预热2000步，cosine衰减到最终学习率的十分之一。
这里有个关键点：学习率和batch size之间存在对应关系。batch size翻倍时，学习率通常也应当相应调整，但直接翻倍会破坏训练的稳定性，一般需要有控制地增加。我见过团队在换用更大batch size之后没有调整学习率，结果loss曲线震荡幅度明显变大，收敛速度反而下降了。
超参数的参考起点大概可以这样设定：
| 参数 | 常用取值范围 | 备注 |
|---|---|---|
| 学习率 | 1e-4 ~ 3e-4 | 大模型通常比小模型用更小的学习率 |
| 预热步数 | 1000 ~ 5000 | 与总训练步数相关，一般占1%-5% |
| batch size | 512 ~ 4096 | 按token数计算，越大越考验学习率配合 |
| 权重衰减 | 0.01 ~ 0.1 | 太大容易欠拟合 |
| 梯度裁剪 | 1.0 ~ 2.0 | 防止梯度爆炸，对早期训练稳定性有帮助 |
这些参数不是一组“标准答案”，但作为起点足够让你把训练跑起来，再根据loss曲线的实际表现做调整。
4.3 混合精度与优化器
训练大模型时显存是最稀缺的资源，而混合精度训练是节省显存最直接的手段。当前用得最多的是BF16，因为它比FP16拥有更大的动态范围，在小数值上不容易溢出，梯度更新时更稳定。我自己在实际训练中基本不会用FP16做主力精度，BF16在损失精度可控的前提下，把显存占用压到了接近一半。训练过程的梯度更新一般仍然用FP32来维护权重，避免累加误差。
优化器带来的显存开销也不可小觑——AdamW不仅存储一份权重副本，还需要存储对应的动量项和方差项。这也是3D并行和ZeRO系列优化器存在的意义，后面我会单独讲。
4.4 对齐与微调：从“会说话”到“懂指令”
预训练结束之后，模型已经具备了语言生成能力，但它还不太“听话”。让它回答问题时，它可能写出一段还算流畅但完全不符合指令要求的内容。这时候就需要对齐和微调阶段上场了。
对齐的核心是让模型学会遵循指令，通常通过指令微调数据来实现。指令数据由“指令-输入-期望输出”组成，让模型从普通文本续写切换到“被要求做什么就做什么”的互动模式。对齐阶段训练量远小于预训练，但数据质量要求极高。几条低质量的对齐数据足以让模型生成风格明显退化，所以对这个阶段的数据，整理工作要极度精细。
对齐阶段常见的做法包括全量微调、LoRA和QLoRA、以及基于人类反馈的强化学习。有的项目还会把三个步骤串起来：先在通用指令数据上微调，再在特定领域数据上继续精调，最后用偏好优化打磨风格和安全表现。
5. 基础设施：一只模型背后的“血汗工厂”
5.1 集群拓扑与通信
单卡训练一个大模型在绝大多数情况下是不现实的，这涉及的不是显存能不能装下参数，更关键的是训练的绝对时长。一万张卡跑一天和一张卡跑一万天，结果在数学上等价，但后者根本不可能出现在实际项目里。
集群训练最核心的瓶颈是GPU之间的通信。训练过程中频繁同步梯度，如果卡间网络是普通以太网，通信开销会大到让GPU长期处于等待状态。综合看，训练场景下最好使用NVLink和InfiniBand这类高速互联方案，普通以太网可以作为调试环境，但规模化训练时通信瓶颈会极其明显。有过一次不愉快的经历，为了节省成本只用万兆以太网组了个集群，训练吞吐量比理论值低了将近一半，那些“剩下的预算”最终都变成了等待时间。
5.2 并行策略：DP、TP、PP、ZeRO
大模型训练的并行策略有几种基本手段，实际工程里往往组合使用。
| 策略 | 核心思路 | 适用场景 |
|---|---|---|
| 数据并行（DP） | 每个GPU存一份完整模型，各处理不同batch | 模型能装进单卡时首选 |
| 张量并行（TP） | 把模型的层内矩阵切分到多卡 | 单卡装不下超大模型时 |
| 流水线并行（PP） | 把不同层放到不同设备上，按段流水执行 | 配合数据并行做跨节点扩展 |
| ZeRO | 把优化器状态、梯度、模型参数分片存储 | 大幅降低单卡显存 |
实际工程里，一个常见组合是“数据并行+张量并行+流水线并行+ZeRO”混用，通常由框架统一调度。框架选型上，DeepSpeed和Megatron是两条主流路线，其中DeepSpeed的ZeRO系列对现有训练代码侵入性小，出效果快；Megatron对超大模型的切分控制更细。此外PyTorch自带的FSDP在中小规模集群上也能提供不错的开发体验。
一个非常实际的经验：并行策略的选择要基于实测，不要照着别人论文里的配置照抄。不同模型在不同的集群拓扑下，最佳并行维度差异很大。我习惯用一个小规模的profiling run先跑几分钟，记录各种并行配置下的吞吐量和显存占用，再做决定。这比反复试错整轮训练省时省力得多。
5.3 断点续训与故障恢复
大模型训练动辄数周，训练过程中随时可能出现节点故障、网络抖动、显存异常等意外。断点续训不是可选项，而是必选项。每次保存的checkpoint里应包含模型权重、优化器状态、随机数生成器状态、学习率调度器的位置和已完成的步数。
我见过由于checkpoint没有保存随机数状态导致的问题：断点之后恢复训练，虽然权重和优化器都正确加载了，但数据顺序和增强方式变了，前后两段训练的loss曲线出现明显断裂。从那次以后，我整理的checkpoint规范里，随机数状态固定占据一个位置。
保存频率也需要权衡。模型参数每隔一个固定步数保存一次；优化器状态等重数据则可以放宽保存频率，减少I/O带来的停顿。我用过“里程碑+滚动”的保存模式——每个固定步数保存一个里程碑版本，同时只保留最近两个普通版本，在恢复能力和存储成本之间找到平衡。
6. 训练中的观察与调参
6.1 Loss曲线：模型的“体温计”
训练过程中最常盯的指标就是loss。理论上，随着步数增加，loss应该平稳下降。如果能观察到这一点，说明模型在学习；但实际训练里，loss曲线会呈现各种形态——陡降、平台期、锯齿震荡、发散上翘，每种形态都对应不同的问题。
我一般会按三个维度去看loss：
- 训练集loss和验证集loss是否同步变化，如果训练loss还在降、验证loss已经回升，说明模型开始过拟合
- 梯度范数是否稳定，梯度范数突然飙升，通常预示着学习率太高或者数据里有异常样本
- 各阶段的loss表现是否均衡，例如代码数据的loss降得比通用语料慢，可能需要调整数据配比
6.2 训练稳定性的处理
训练大模型时最让人紧张的问题是训练发散，通常表现为loss突然飙升甚至变成NaN。遇到过这些情况的处理经验如下：
- 梯度裁剪要尽量提前设置到合理范围。把梯度范数裁剪到1.0附近是常见的起点
- loss出现单点尖峰时，别急着停训练，可以适当调低学习率并继续观察
- 如果是NaN而不是普通尖峰，优先检查混合精度设置，以及是否存在脏数据导致数值溢出
6.3 用评估集和checkpoint做过程管理
训练过程中不能只看loss，还要周期性地在评估集上跑一些任务指标，判断模型的实际能力变化。如果发现某个能力维度在退步，需要及时分析是数据配比的问题还是超参数的问题。
中间checkpoint本身就是重要的产出物。大模型的训练过程并不总是越到后面越好——某些中间版本的模型在某类任务上可能表现意外地好。我习惯每隔一定步数保存一次，训练完成后做一次批量评估，再决定哪一版值得做后续对齐。与训练过程相比，评估和筛选虽然不起眼，却经常决定了最终产品效果的上限。
7. 踩坑实录：常见问题与排查
7.1 Loss不降或降得太慢
Loss长期不降，优先排查的顺序：先看数据是否存在大量重复或标签错误，再看学习率是否过低或过高，最后检查模型架构有没有数值稳定性问题。还有一个容易被忽略的原因——数据顺序的shuffle做得不好。如果数据按领域堆在一起，模型每段时间只见到一个领域的文本，loss会波动得很厉害。
7.2 显存OOM
显存不够用有几个层面的解决方向。第一优先开启混合精度，第二开启梯度检查点，用计算换显存；效果更明显的是调整并行策略，比如让ZeRO把优化器状态分片；在数据流层面也可以控制batch size和序列长度。训练吞吐和显存占用之间存在一对矛盾，需要根据实际显存余量动态调整。
7.3 训练效率低
训练效率低经常表现为GPU利用率上不去。排查时先看数据加载线程是否成为瓶颈，再看通信比例是否过高。有时候问题出在非常不起眼的地方：数据预处理没做缓存，每次迭代都在重复tokenize，GPU大部分时间都在等待CPU。把数据提前预处理并缓存成二进制格式，往往是提升吞吐量性价比最高的一步。
7.4 常见问题速查表
| 现象 | 可能原因 | 排查建议 |
|---|---|---|
| loss出现NaN | 数值溢出、脏数据 | 检查混合精度与梯度裁剪，定位异常样本 |
| 训练loss降、验证loss升 | 过拟合 | 增加数据多样性，引入更强正则 |
| GPU利用率低于预期 | 数据加载慢、通信瓶颈 | 预处理缓存、调整并行维度 |
| 梯度爆炸 | 学习率过大 | 降低学习率，开启梯度裁剪 |
| 多个loss不均衡 | 数据配比不当 | 重新设计采样权重 |
这些都是训练过程中高频出现的问题类型，把排查逻辑理清楚，比遇到问题到处求助要高效得多。
8. 关于训练节奏的几句真话
在我数次训练模型的经验里，踩过的坑多到可以写满好几页。启动训练第一天，经历过持续多个小时loss完全不动；调试过多机分布式通信到深夜，最终发现只是某个环境变量没配对。训练大模型这个事，很多时间其实不是在写训练代码，而是在处理数据、配置环境和排查问题。
如果让我给一个最实际的建议，那就是：正式大规模训练之前，一定先用小模型、小数据、小规模集群把整个流程的每个环节都打通。用1B模型、几十G数据、一两张卡跑通全链路，包括训练、checkpoint保存、断点恢复、评估、对齐，再上真正的规模。很多新手犯的错误是在小规模验证还没通过时就直接开了大规模任务，结果浪费巨大的算力才发现流程有硬伤。
还有一点我想多说一句：训练过程中要保留完整日志、完整代码版本和完整的数据版本记录。大模型训练项目的成功经验无法复现，绝大多数情况是日志和配置版本没有留全。等遇到效果回退时，手里有完整的“案发现场”，排查起来才真正有的放矢。
这些是我在实际项目中积累下来的习惯，分享出来，希望后来者能少走我走过的弯路。
