预训练大模型通用训练流程包含什么

想系统搞懂大模型原理的人，多半卡在同一个地方：能说出「预训练、微调、对齐」这几个词，但说不清预训练内部到底跑了哪几步、每步之间怎么衔接。这篇按流程顺序把数据准备、分词处理、架构定型、分布式训练、评测选点、权重交付这几段拆开讲，每段给可核对的清单，并指出哪些环节是公开资料里能看到、哪些只能靠站内实测数据反推。

想系统搞懂大模型原理的人，多半卡在同一个地方：能顺口说出「预训练、微调、对齐」这几个词，但说不清预训练内部到底跑了哪几步、每一步的输入和输出分别是什么、上一步的产物怎么交给下一步。结果就是看论文和博客时每段都认识，连起来不知道卡在哪一环。

这篇不讲玄学，按流程顺序把预训练拆成数据准备、分词处理、架构定型、分布式训练、评测选点、权重交付这几段，每段给一份可以照着核对的清单。哪些环节在公开资料里能看到，哪些只能靠站内实测数据反推，也会标出来，省得你在不公开的细节上白耗时间。

先明确预训练到底在做什么

预训练的目标可以压成一句话：用海量无标注文本，让模型学会「给定前文，下一个 token 最可能是什么」。跑完之后你拿到的是基座权重加一份结构配置，它没有对话格式、不听指令，更像一个超级自动补全器，而不是能直接交给用户的产品。

这条边界很重要：预训练阶段决定的是能力上限，后训练阶段决定的是表达方式和服从度。两者用的数据形态完全不同，前者是无标注原始文本，后者是成对的指令与回答。混在一起讨论，判断一定会走偏。

• 预训练只管「接下一个词」，产出基座权重；微调和校准才让它变成能对话的形态
• 预训练定能力天花板，后训练定顺从度和输出风格，改不了前者
• 只想做应用开发的人，把精力放在后训练和评测上更划算，基座怎么练出来对选型影响有限
• 自己读到多深算够用：能解释「为什么基座不能直接当客服上线」就基本到位
• 术语口径不一致时，先到 /ai-dict/category/tech 把基线概念对齐，再往下读

数据采集与清洗：整条流程里最耗人力的部分

预训练流程里真正吃掉人力的往往不是训练本身，而是数据。语料大致分四类：网页抓取、书籍与论文、代码仓库、多语种语料。每一类的清洗规则、去重力度、比例搭配都不一样，最后会汇成一份「可训练的干净语料」。

去重和去噪不是可选项。重复样本会让模型倾向于背答案，长尾噪声会让收敛变慢甚至跑偏。质量过滤通常两条腿走：先用启发式规则粗筛，再用分类器打分细筛。具体阈值各家不公开，你只能从成品模型的表现反推，别指望找到一份标准答案。

版权与合规这一层，务必在数据准备阶段就定下来。等训练跑起来再补授权，代价极高，基本等于重来。相关术语和边界口径，可以先到 /ai-dict/category/safety 看一眼，避免后面在法务环节被卡住。

分词与数据格式：决定了后面算力和上下文的账怎么算

分词器在预训练开始前就要固定下来，而且它是流程里少数不可逆的决定之一。中途换分词器等于把已训好的权重作废，因为 token 和权重是绑死的。这一步想错，后面全部重来。

语料不会一句一句喂进去，而是被打包成定长序列再进训练循环。所以「我攒了多少 TB 文本」和「实际训了多少 token」是两回事，中间要过一遍分词器做换算。序列长度、是否跨文档拼接、padding 策略，都会改变每步的实际计算量，也就直接影响显存和吞吐。

1. 先定分词器确定词表规模与切分规则，跑一遍小样本可视化，确认中文、代码、多语种不会切得太碎。
2. 做过一遍 token 换算拿一批真实语料样本跑分词，量出「字」和「token」的大致比例，再去估总量。
3. 确认打包策略决定序列长度、是否跨文档拼接、padding 怎么处理，并明确这些选择对显存的影响。
4. 留出验证集从同一分布里切一小份干净语料作为验证集，后面看困惑度趋势要用它，不能和训练集混淆。

想自己估算规模，可以先用 /tools 里的换算类工具把 token 数、显存、卡数对齐，再去看训练成本相关的页面，避免一上来就按错误的量级做预算。

架构与规模定型：参数、层数、注意力方案怎么定

这一阶段的产出是一份结构配置：层数、隐藏维度、注意力头数、上下文长度上限、是否用专家混合这类稀疏方案。配置一旦定下来，训练中途基本不改，改了通常要重训，所以它和分词器一样属于不可逆项。

稠密和稀疏的选择不只是效果问题，它直接改变算力与显存的账。缩放规律给的是方向而不是答案：同样的预算下，「更大更浅」还是「更小更深」，要看你的任务类型和推理侧成本。公开资料里能看到的是架构家族的共性，具体某家的配置细节一般不公开，别硬找，也找不到。

结构配置

层数、维度、头数、上下文长度上限等参数的集合，定死后沿用整轮训练。

稠密与稀疏

前者每次激活全部参数，后者按需激活一部分，账算方式完全不同。

缩放规律

描述参数、数据量、算力之间大致关系的经验方向，不是可直接套用的配方。

分布式训练：并行策略与稳定性处理

到这一步才算真正开跑。主流做法是数据并行、张量并行、流水线并行组合使用，选哪种取决于卡数和单卡显存，不是越复杂越好。并行策略配错，要么跑不满卡，要么直接报显存不足。

训练途中最常见的事故是损失尖刺和梯度异常。标准处理是回滚到最近一个检查点，跳过高损失批次再继续。这部分流程公开资料里讲得最少，但恰恰是工程团队日常花时间最多的地方。

• 检查点要定期存，并且要验证过能断点续训，否则一次中断就是从头再跑
• 回滚方案要在开跑前就写好，别等尖刺出现了才临时决定跳哪批数据
• 并行策略先看单卡显存，再算通信开销，通信瓶颈比显存不足更难排查
• 训练日志要能定位到具体批次和步数，不然事后复盘只能靠猜

想看这一步对算力的实际消耗，去 /compute/training-cost 对一遍口径。别人的案例数字换个模型规模就失效，别直接套自己项目。

评测与选点：训练不是跑完就结束

预训练阶段的评测用的是困惑度加一批能力探针，不是最终产品榜单。困惑度看的是「预测下一个词有多准」，探针看的是某一类能力有没有出现。这两类指标都不能直接当成用户能感知的效果。

要分清「中途评测」和「发布评测」：中途评测只用来判断趋势，决定要不要继续投入算力；发布评测才对读者和选型有意义。把中途的数字当结论，是常见的误读。

选点，也就是拿哪个检查点交付，往往比多训几天更影响最终效果。很多团队在这步偷懒，默认用最后一个检查点，结果交出去的是已经开始过拟合的版本。

榜单怎么读才不被带偏，可以到 /benchmarks 和 /benchmarks/registry 看解题思路，注意题目饱和和自评分这两类常见干扰。

权重交付与往下游走

预训练结束时，你拿到的是基座权重加一份配置，外加一份许可证说明。能不能商用、能不能改、能不能蒸馏，全看许可证，别默认「开源就等于随便用」。这一步要在选型前就确认清楚。

接下来才轮到监督微调、偏好对齐、安全对齐这些后训练环节。它们需要的数据量比预训练小几个量级，但决定了模型能不能听懂人话、能不能守住边界。基座能力不够的时候，后训练是补不回来的，这是很多项目后期返工的根本原因。

• 先确认许可证允许的用途范围，再决定要不要在这套权重上投入
• 评估基座能力时用你自己的业务样本，别只看通用榜单
• 5 人小团队做垂直场景，通常在后训练和检索侧投入回报更高，不必碰预训练
• 算力从哪来、买还是租，见 /compute/platforms，本分区其他文章有单独讲

一份可以照着对的流程清单

把上面几节收成一张能逐条打勾的清单。顺序有讲究：先问目标，再锁不可逆项，最后才算账和留退路。照着走一遍，基本不会漏环节。

1. 问清目标先确定要的是基座还是能用的模型。只要后者，预训练细节读个大概就够。
2. 锁定不可逆项分词器、架构配置、许可证这三样先定死，再谈其他，改一次就是重训。
3. 算账把 token 数、卡数、天数、租用或自建成本对应起来，数字口径到站内页面核对。
4. 留退路检查点策略和回滚方案在开跑前写好，别等事故出现再补。
5. 分开读评测预训练、微调、对齐的评测口径分开看，混着读一定误判。