从零训练7B底座模型：数据清洗、并行策略与调参避坑全记录

如果有人问我，从零开始训一个底座模型到底难在哪里，我大概率不会先说算力，也不先说算法。真正让一个训练团队感到无力的，是整条链路里那些无法从教科书里直接查到的工程问题。过去大半年，我们团队一直在和一条从头训练的模型管线较劲，从语料清洗到超参回滚，从loss尖峰排查到checkpoint逐文件校验。这篇文章就是想把这套大模型训练流程完整摊开，讲清楚每个阶段的核心任务、技术选型背后的原因，以及那些文档不会告诉你的坑。无论你是刚入门想了解全貌，还是正在规划自己的训练任务，都应该能从里面找到一些用得上的东西。

1. 先看全景：一份训练任务背后藏着多少条并行流水线

1.1 从数据到模型权重：一个完整训练周期的真实时间账

很多人以为大模型训练就是把语料喂进GPU，跑几个月出个模型。实际接触之后你会发现，纯GPU计算时间只占整个项目周期的一半都不到。拿我们团队这次7B底座模型、约1T有效token的训练任务举例，完整时间账大概是这样的：

注意，这里列的是7B这个体量的任务。如果换成几十B甚至百B以上的底座，预训练时间会从几周拉长到两三个月，而数据工程的时间反而相对固定。所以业内经常说，数据组永远是先开工、后收工的那批人。这也导致很多团队会并行安排：数据组还在洗第五轮语料时，预训练组已经用小批量数据做缩放率实验了。

训练成本本身也有一个非常实用的估算公式。Transformer架构下，训练一个N参数、D token的模型，需要的浮点运算量大约是6ND。假设一个7B模型配1T token，那就是6 × 7e9 × 1e12 ≈ 4.2e22 FLOPs。一块主流加速卡跑约100TFLOP/s的可用算力，理想情况下一张卡要跑120天，一千张卡大概需要3天多一点。真实环境里因为通信开销、故障恢复、负载不均，利用率往往只有理论峰值的百分之二三十，所以实际耗时通常落在几周这个量级。很多人不理解为什么团队先用小模型试跑，看到这个公式应该就明白了：参数量和数据量都是线性放大成本的，架构上省下来的每一点计算都会被放大到整个训练周期里。

1.2 为什么说算力预算决定架构选型，而不是反过来

新人最容易犯的错，是先定一个“看起来很厉害”的模型规模，再回头看自己的算力够不够。我见过不止一个团队，一开始信誓旦旦要做几十B的底座，最后发现训练一次要跑两三个月，中间连一次完整的对比实验都做不起。

顺序应该反过来。先算清楚你有多少卡、能跑多久、能承受几次失败重来，再倒推模型参数量和训练数据规模。我们当时的约束是千卡集群，可用周期大约两个月，于是果断把目标定在7B级别，数据规模控制在1T token左右。这个体量让我们能做到每天至少看一次关键评测，每周做一次完整回归。

架构选型还会被推理部署绑住。如果你训完模型是要放在有限显存环境里服务的，那在线层数、隐层维度、注意力头数这些参数都必须在预训练之前就和后端同事对齐。否则训出一个效果很好但部署不下的模型，整个项目就白做了一半。

2. 数据才是真正的护城河：清洗、配比与序列构造

2.1 原始语料到训练样本：tokenization和去重比想象中更费时

预训练语料的来源通常非常杂：爬取网页、电子书、论文、代码仓库、论坛帖子、多语言文本，每种来源的噪声都不一样。我们的清洗管线做了三轮。

第一轮是规则过滤，把乱码、全角半角混杂、纯广告内容、重复模板段落、超长无标点文本先筛掉。这一轮最容易写，但往往能砍掉30%以上的垃圾。第二轮是去重，这里用的是MinHash近似去重，分别按整文档和n-gram两个粒度做。单纯按文档去重不够，因为很多低质内容会把同一个段落套在不同模板里，整篇看起来不重，但实际信息冗余非常严重。按n-gram去重能把这部分再压掉不少。

第三轮是质量分类。规则过滤解决不了“看着通顺但毫无信息量”的文本，所以我们需要训练一个轻量级质量打分模型。具体做法是抽一批候选样本让人工标注质量档次，然后用这些标注数据训练一个小分类器，最后拿它对全量语料打分，低于阈值的直接剔除。这一步经常被低估，但实际效果非常明显，它直接决定了模型后续的知识密度。

分词器也要单独训练。BPE这类算法在代码数据上有一个细节：空格处理会影响代码的压缩率和建模质量。词表大小也讲究，7B模型我们用32K的词表，再大收益不明显，反而会增加embedding参数占比和推理延迟。

如果你刚起步，我建议把“高质量数据”理解为“七成靠清洗、三成靠去重”，不要急着堆来源数量，先把每一类来源的噪声洗干净，再谈配比。我们统计过，最后真正进入训练管线的token，大约只有原始语料的40%出头。

2.2 数据配比不是玄学：如何用采样权重控制模型的知识结构

数据来源大致分成网页、百科、书籍、论文、代码、数学题、多语言文本这几类。它们不能等量混合，配比直接决定模型最终的能力偏向。代码数据比例高的模型，思维链和推理能力通常更强，但文本风格会偏“工具化”；数学数据能提升逻辑推理，但来源有限；多语言数据太少会导致非英语能力退化，太多又会挤占主要语种的容量。

我们当时的配比大致是网页50%、代码20%、书籍和论文约10%、数学数据5%、多语言文本15%。这不是拍脑袋定出来的，背后有一套小实验支撑。我们先用一个1B左右的模型，对几种候选配比各自跑约100B token，观察它们在代码、数学、通用问答几个小评测集上的变化趋势，才选定最终配比。这类“配比消融”实验成本不高，但非常值得做，因为它把玄学变成了可量化的比较。

这里还有一个很多人不知道的坑：数据重复epoch的问题。如果某类数据来源特别少，比如高质量数学题，你可能为了凑配比反复采样，导致它被模型反复看过好几遍。短期看评测分数上涨了，长期看模型对这类数据会过拟合，泛化反而变差。我们的做法是给每条数据加一个采样上限，同一份数据最多出现固定次数，超过就不再进采样池。

2.3 序列打包与注意力掩码的工程细节

真实语料里绝大多数文档远短于训练序列长度。如果我们坚持“一篇文档作为一条样本”，大量短的文档都会浪费序列空间。所以训练样本构造阶段要把多个短文档拼接到固定长度，这个操作叫packing。

Packging本身不难，难点在于注意力掩码和损失计算必须跟着改。拼接后的序列里，第3篇文档的token不应该看到第2篇文档的内容。正确做法是给每个文档一个内部的注意力范围，形成块对角掩码，文档之间全部置零。同时，损失函数只计算有效文本token，不计算padding位置。

这个环节的bug非常隐蔽。我们有一次训练了几个星期，loss曲线非常漂亮，但下游评测发现模型生成内容里频繁出现跨段落的人称混乱和逻辑跳跃。查到最后才发现，某个并行配置下掩码变量被广播成全部可见，模型在训练时偷偷“看到”了其他文档的内容。loss低是因为它学到的是一种作弊的解码路径，而不是真正理解了语义。这类问题只有靠完整的评测回归才能暴露，所以每次改数据管线之后，哪怕改动很小，我都强烈建议跑一轮小规模训练做对照，别直接拿大任务当实验品。

3. 预训练主战场：Loss曲线背后是并行策略和超参数的博弈

3.1 数据并行、张量并行、流水线并行到底怎么分工

预训练阶段最核心的工程问题，是怎么让几百上千张卡协同工作还不被通信拖死。我碰过很多人把三种并行混为一谈，其实它们的分工完全不同。

数据并行是每张卡都持有一份完整模型副本，各吃各的微批次数据，算完梯度后做全局同步。它的优点是实现简单、卡数扩展性好，缺点是每张卡都要存完整模型，显存限制很大。张量并行是把一个层内的权重按维度切到多张卡上，前向计算时每算一步都要做卡间通信。它能把单层显存摊薄，但通信量很大，通常只在同一节点内、有高速卡间互联的场景使用。流水线并行则是按层切分，把网络不同层放在不同卡上，数据像流水线一样逐层流过。它能大幅减少单卡显存压力，但会有流水线气泡问题，需要把微批次切得更细来填满气泡。

实际训练几乎没有只用一种并行的情况。7B模型在千卡规模下的典型组合是数据并行 + ZeRO显存优化，或者在小规模卡组里用张量并行 + 流水线并行。选型逻辑很简单：先看单卡显存能不能装下模型权重加上优化器状态，再看卡间通信带宽撑不撑得住。同一节点内的NVLink互联可以用张量并行，跨节点只有普通网络时就必须优先考虑数据并行和梯度压缩。

3.2 学习率调度与batch size：warmup不是可有可无

预训练的学习率调度看起来是小事，但影响比想象中大得多。主流做法是线性warmup到峰值，再用余弦退火降到终值。峰值学习率通常落在1e-4到3e-4之间，warmup步数占总步数的0.5%到2%，终值一般是峰值的十分之一左右。

warmup为什么必不可少？Adam优化器会维护梯度的一阶矩和二阶矩估计，训练初期这两个估计值噪声非常大，如果一上来就用很高的学习率，模型参数会被一步推到一个很偏的位置，后面很难拉回来。先让学习率从小变大，相当于给优化器一个“热身期”，让动量统计量稳定下来再发力。我们见过不止一次，有人把warmup去掉后loss前几百步剧烈震荡，最后不得不回滚重跑。

学习率和batch size也不是各自独立的。经验上，batch size翻倍时，学习率往往也要跟着调大，但并非线性关系。更稳妥的做法是固定一个相对保守的峰值学习率，优先把batch size调到卡间同步效率最高的值，然后再小范围扫学习率。别小看这个顺序，很多人把学习率调到模型发散，又反过来怀疑数据有问题，来回浪费了好几周。

3.3 检查点保存的代价：多频繁才算合理

故障恢复是所有大训练任务逃不开的话题。千卡规模下，单卡故障几乎必然发生，如果checkpoint存得不够及时，一次故障可能让你回退几天的训练进度。

这里的关键是优化器状态和RNG状态必须和模型权重一起保存。很多人只存权重，恢复训练后loss曲线倒是正常，但生成质量和之前不连续，就是因为训练随机状态被重置了。我们这次训练7B模型，bf16权重约14GB，Adam优化器状态大约是权重的两到三倍，再算上RNG状态和加载器偏移，单个checkpoint的完整大小轻轻松松超过50GB。

保存频率取决于存储系统的写入带宽。我们按训练步数每2000步存一次，折合时间约6小时。试过更频繁的每500步存一次，结果存储IO反而拖慢了整体吞吐。恢复训练还有一个细节：要校验数据加载器从正确的偏移量继续读取。我们有一次恢复后loss明显跳升，查了很久才发现数据加载器的index被重置到了epoch开头，等于把已经学过的数据又喂了一遍。从那以后，我们的恢复脚本会同时打印数据偏移、checkpoint步数和RNG校验值，三层对不上就不允许继续训练。

4. 从基座模型到对话模型：对齐阶段的技术选型与数据构造

4.1 SFT数据：数量和质量哪个更关键

预训练结束后的底座模型本质是一个“文本补全器”，它不是在跟你对话，而是在接续文本。让它变成能听懂指令、按格式回答的对话模型，靠的是监督微调，也就是SFT。

很多人以为SFT需要几十万甚至上百万条数据，实际不是这样。高质量的一两万条指令样本，已经足够让7B模型学会对话的基本行为模式。数据覆盖面的重要性远大于总数。你可以想象成教一个博学的朋友学习社交礼仪，不需要给他讲一万遍“你好”，而是需要让他见过足够多不同类型的问题和回答方式。

我们构建SFT数据时主要走三条路：第一是收集真实用户问题，尤其是那些模型在预训练评测里表现不好的方向；第二是让人工写标准答案，尽量模拟目标用户期待的回复风格；第三是让模型自己生成候选回答，再由人工筛选修改。整个过程里最花时间的不是生成回答，而是格式校验。任何一个answer字段缺失、换行符错乱、系统提示词缺失，都会在训练时产生噪声，把模型往错误的方向带一点。

4.2 RLHF还是DPO：稳定性和成本之间的取舍

SFT之后的模型已经“会说话”了，但它的回答风格还不够符合人类偏好，这时候就需要偏好优化。主流的两个流派是RLHF和DPO。

RLHF是训练一个奖励模型，再用强化学习算法（比如PPO）来优化策略模型。理论上限最高，但也最“娇气”：需要维护奖励模型、策略模型、参考模型和值函数模型，显存占用高，超参敏感，训练稳定性差，动不动就出现reward hacking——模型找到一条让奖励虚高的输出路径，而不是真正变好。它对数据也有要求，必须线上采样新回复再打分，工程链路很长。

DPO直接从偏好数据对里做损失优化，不需要单独训奖励模型，也不需要线上采样。它的优点是稳定、快、显存占用小，小团队几乎都是先跑通DPO再考虑要不要上RLHF。我们这次的路线是DPO为主，主要原因是迭代速度快，一条偏好数据改动几个小时就能看到效果，而RLHF一次完整实验往往要等好几天。

两种方案需要的数据形态也不同。DPO需要的是同一prompt下两个回答的对比偏好，我们人工标注了约几万对高质量对比样本，覆盖问答、代码、写作、拒绝回答等场景。RLHF则还需要额外的奖励模型标注数据，成本又高一个量级。预算有限的情况下，我的建议是不要一上来就追RLHF，DPO的性价比要实在得多。

4.3 对齐阶段容易忽略的过拟合问题

对齐数据比预训练数据少了好几个数量级，所以这个阶段最大的风险是把原有能力覆盖掉。我们最担心的是训完对话能力之后，模型在数学推理、事实准确率上出现明显退化，因为几万条对齐数据里不可能覆盖所有预训练学到的知识。

对策有三招。第一，在对齐数据里混入一定比例的原始预训练数据，通常5%到10%就行，让模型在学对话行为的同时不至于把旧知识忘光。第二，对齐阶段的学习率要比预训练低一个量级，我们用0.5e-6左右，跑得慢一点但稳。第三，每个中间checkpoint都同时跑通用能力评测和对齐专项评测，两边都观察，任何一边掉了就停。

对齐训练出现loss下降、通用评测分数却掉的局面，往往不是数据本身脏，而是学习率太高或混合比例太小。先检查这两项，比盲目清洗数据更有效。

5. 训练中真正让人崩溃的瞬间：Loss尖峰、梯度爆炸与静默失败

5.1 一次loss spikes追查路径

预训练最刺激的瞬间，是某天早上看到loss曲线突然拉出一个大尖峰。尖峰不可怕，可怕的是你不知道它为什么出现。我们整理过一套排查顺序，按这条路径走基本能定位到根因。

第一步，锁定尖峰发生的具体step，直接把它对应的数据批次单独提取出来。第二步，检查这批样本里有没有异常文本，比如某个网页模板在清洗时漏掉了，整篇都是重复字符串；或者一条样本里包含了非UTF编码字符，切分后变成了大量无意义token。第三步，查看尖峰前后的梯度范数，如果梯度范数在尖峰前就明显增大，问题多半出在学习率或数据本身；如果是突然跳高，还要再看一眼混合精度是否有异常。第四步，如果尖峰发生在断点恢复之后，优先怀疑checkpoint恢复流程，而不是数据。

我们实际遇到过一次很典型的尖峰，恢复训练后loss先正常了一两百步，然后突然拔高，又慢慢降回。逐层排查后发现问题出在数据加载器被重置到了epoch开头，模型在重复学习一批已经被学过的样本。这类问题不会导致训练崩溃，但会让loss曲线看起来“莫名其妙地波动”，而且污染整个训练过程。

5.2 混合精度训练中的数值溢出

大模型基本都靠混合精度来省显存、提速度。你需要在fp16和bf16之间做选择。fp16的动态范围小，容易出现数值溢出，所以需要一套动态loss scaling机制来保护梯度；bf16的动态范围和fp32基本一致，不容易溢出，但精度更低。

我们最终选了bf16，理由很简单：稳定。fp16在7B模型这种规模上，每一步都要小心翼翼地维护loss scale，哪怕某个参数的梯度极端值没有预料到，整个训练就可能出现NaN。而bf16虽然你的梯度精度低一点，但正常预训练场景根本感知不到差别。

数值溢出有一个常见症状：某个样本的loss骤然变成NaN，然后整条loss曲线开始震荡，因为后续step的梯度都是基于脏数值计算的。我们的处理方式是训练脚本里加一个保护逻辑，只要检测到/step/loss为None或者NaN，就跳过该样本并记录编号，同时打印该样本的前几百个token，方便数据组定位。别笑，这个保护逻辑后来不止一次帮我们抢救了整轮训练。

5.3 三种静默失败：数据重复、掩码错位、梯度同步中断

比loss尖峰更麻烦的，是那些不报错、loss还正常下降、但模型质量明显不对的问题。这类静默失败我至少踩过三种。

第一种是数据重复。训练任务重启后，数据加载器没有从正确偏移量恢复，导致一段大小为几十B token的数据被反复重复加载。但因为loss在下降，整个训练没有报警，直到下游评测发现模型在某些主题上输出模式固化，才查出问题。第二种是掩码错位，前面已经详细说过，loss虚低但生成质量崩坏。第三种是梯度同步中断。某张卡通信超时后，训练框架可能进入降级模式，没有主动退出，导致部分卡上的梯度没有参与全局聚合，模型实际等于在一个“缩水”的batch上训练。这个问题最难发现，因为loss还是降的，只是没有达到预期水平。

对付静默失败，最好的办法是预防。我们在训练循环里给数据批次加hash校验，在梯度聚合阶段加卡间校验信息，每个checkpoint保存时做一次小batch对照评估，如果当前GPU上的loss和保存时的数值明显对不上，就强制告警。

6. 评估实验、checkpoint管理与继续训练的思路

6.1 评测集怎么搭才不会被“刷榜”

训练流程的最后一步，是评估与上线，但这步做不好前面全白搭。公开benchmark数据很容易在网络上被泄露，如果用它们作为唯一标尺，模型很可能在预训练阶段就已经“见过”过这些题目，分数高得没有意义。

我们的做法是搭一套自己的内测集：一部分来自真实业务场景中的问题，一部分由领域专家编写，还有一部分是故意构造的对抗样本，比如要求模型拒绝不合理请求、处理低质量输入。评测维度和训练侧要完全隔离，这些数据集不会进入任何训练阶段。每隔固定步数做一次采样评测，每隔较大间隔做一次全量回归。

6.2 多轮checkpoint怎么选版本上线

loss曲线的值只能反映训练是否正常，不能直接决定哪个checkpoint更值得上线。我们遇到过几次loss最低的checkpoint在通用评测上表现反而一般，因为模型在训练后期趋于保守，部分能力出现轻微回落。

选择checkpoint的标准是综合多项指标。自动化指标跑一遍之后，会做一轮人工盲评，把候选checkpoint生成同一组prompt的输出，让评估人员在不被告知具体版本的情况下对比排序，最后综合自动化分数和人工偏好选出最终版本。这个过程耗时，但非常必要，尤其对对话场景，人的主观感受才是上线质量的第一标准。

6.3 阶段训练：增量数据与继续预训练的策略

底座模型上线之后，知识是需要更新的，不可能每次都从头训练。继续预训练成了常态：在已有权重的基础上，加入采集到的新语料、旧语料按一定比例混合，继续跑预训练，让模型学到新知识。

继续训练和从零训练有一个重要区别：优化器状态不能简单重置，学习率需要重新warmup。如果不保留旧优化器状态，模型的知识结构会在前几步出现剧烈扰动。同时因为新数据量远小于原始训练数据，过拟合风险很高，旧语料比例不能降太多。我们的经验是新旧比例大概在1比3到1比5之间，具体数值可以通过一组小规模对照确定。

继续训练的另一个坑是要做能力回归。很多团队只顾着验证新知识有没有进去，却忽略模型在旧任务上的表现。一份安全评测、一份基础能力评测、一份新知识评测，三者一个都不能少，否则你很可能用新数据的收益换走了旧数据的稳定。

最后说一点真实的个人体会。每次完整走完一个训练流程，我都会重新确认一件事：大模型训练的门槛，不是某一个算法难到无解，而是整条链路上所有细节同时不出错。数据配比、掩码拼接、并行策略、学习率调度、checkpoint恢复……任何一环的疏漏，最后都会以某种形式体现在模型的行为里。你可能在第一步数据清洗时觉得“差不多就行了”，结果训练中期所有问题都从这里爆发。不要怕慢，宁可多花时间把每个环节的校验做扎实，也不要抱着侥幸心理堆算力。这份耐心，会从loss曲线和最终评测分数里一五一十地还给你。