1. 动手前先泼三盆冷水硬件、数据与预期管理我记得自己第一次动“从头训一个大模型”这个念头是在看到一篇开源中文基座模型的报告之后。当时心里想的是别人能做我为什么不能做。结果真正动手之前先做了个预算表格差点把自己劝退。这里先分享几个关键结论省得后来者走弯路。1.1 一张卡能训动什么规模先算清楚显存账很多人会把“训练大模型”和“跑推理”混在一起来算显存。跑一个7B模型的推理一张24GB显卡就勉强够但训练它完全是另一回事。全参数训练时显存里要同时装下模型权重、梯度、优化器状态Adam一般有主权重、一阶动量、二阶动量三份副本以及前向激活值。粗略估算每1B参数在bf16精度下全参数训练大约需要16到20GB显存这还没算上激活值。所以我个人建议模型规模全参数训练最低显存实际可参考配置用什么能跑起来100M-500M8-12GB单张消费级显卡全参数训练无压力1B-2B24-40GB单张A100/H100或双卡3090全参数勉强可行7B左右80-120GB以上4卡A100起步必须配合DeepSpeed ZeRO或FSDP13B以上200GB多机多卡不建议个人坑里跳所以如果你手里只有一块消费级显卡别一上来就想着从零训练7B先拿1B以下把全流程跑通这个投入产出比最高。等代码、数据和流程都熟了再考虑换机器上规模踩坑成本完全不一样。1.2 数据规模的最低线Chinchilla法则的实用修正训练大模型有一个绕不开的经典参考Chinchilla法则。它的核心结论是在固定算力预算下模型参数量与训练token数大致存在一个最优比例大约是每1B参数对应20B token。但这里我想说点实际经验——个人做从零训练最好不要把这个比例当成铁律。原因很简单个人或小团队的数据量和算力都有限。按照20:1要训好一个1B模型需要不下20B高质量token光是清洗、过滤、去重就能让人怀疑人生。实操中大家更常用的是“压缩版”方案1B模型配4到8B token先让模型有基本语言能力反正后面还有SFT阶段兜底。数据少一点模型会欠拟合一点但整个训练周期从“几周”缩短到“几天”对前期迭代太重要了。Chinchilla法则给出的是最优算力分配不是最低可行方案。1.3 从零训练的真实收益什么场景值得这么做接下来是最容易被忽略的一步想清楚自己到底要不要“从零”训练。因为很多人口中的“从零训练”其实用继续预训练Continue Pretraining就能解决。我在实际帮团队做技术选型时一般用这几个问题来判断目标领域有没有大量独特数据比如垂直行业日志、专有的代码仓库、特殊符号语料这些通用模型没见过。是否需要完全控制数据配比和词表比如中文、代码、数学混合比例极高不如自己训一个词表更贴合。版权和合规有没有硬性要求部分场景不允许把数据喂给外部API这时候自己训一个基座反而更安心。有没有足够的工程人力来维护训练链路如果答案是“只有我一个人业余时间”那更务实的路线是拿开源基座做SFT而不是重头训练。我自己经历下来最大的体会是从零训练的价值不在“复刻一个GPT”而在于把数据处理、模型结构、训练稳定性、评估体系这一条链路彻底跑通。哪怕最终模型只有几百M过程中积累的经验在后面任何一次微调或部署中都能直接变现。2. 数据管线的完整闭环采集、清洗、去重与配比预训练是“穷人才自己动手”的阶段因为它的全部成本几乎都压在数据上。很多教程会把这一章飞快带过然后大讲Transformer结构。但我敢说数据环节做的糙后面预训练损失曲线一定很难看。这个阶段没有捷径只能一条条地把管线搭扎实。2.1 数据从哪来公开语料与领域数据的取舍预训练数据源大类上无非三类通用网页文本、书籍/论文类长文本、结构化语料代码、数学公式、百科。常见的公开语料有Common Crawl、维基百科、各类开源中文语料如WuDaoCorpora、CLUECorpus等。如果你的目标是通用能力直接拿这些公开语料起步最快。如果你的目标是垂直领域比如法律、金融、医疗那就必须加入大量领域内原始文档。我的做法是按“源类型”分别建目录保持元信息完整比如来源域名、抓取时间、文档级别哈希。这样在后面做数据配比时可以随时追溯“这条数据到底来自哪、长什么样”排查问题会顺手很多。不要小看这一步等训练完想分析某个bad case时元信息是你唯一的救命稻草。2.2 清洗与去重质量过滤的优先级排序清洗的优先级我建议按这个顺序来编码层过滤乱码、非UTF-8、控制字符直接丢。语言识别过滤用fastText或语种检测库筛掉目标语言之外的内容。中文场景特别要注意繁体、简体和“伪中文”外文机翻的区分。质量启发式过滤统计句均长度、符号占比、重复字符占比、标点密度。对于中文语料一个简单但有效的规则是全文平均句长低于某个阈值或者高频n-gram重复率过高基本可以判定为低质内容。精确去重与近似去重精确去重用内容哈希近似去重普通做法是MinHash LSH按Jaccard相似度做去重。这里特别提醒很多人只做文档级去重忽略了段落级去重。实际上网页模板、导航栏、重复的免责声明在文档级去重里完全逃得掉却会污染训练数据让模型学会大量无意义重复文本。我在实操中还会加一道“累积重复率”检测对文本按句子切分后看后50%的句子中有多少与前50%重复。如果相邻两三段都在重复同一句话这种数据比简单低质文本更可怕它会让模型在生成时陷入复读机状态。2.3 tokenizer训练词表大小与合并规则很多人会把tokenizer训练拖到最后甚至直接拿现成词表用。如果你是从零训练我还是建议自己做一次词表训练核心原因是中文场景下现成词表不一定适配你的数据领域。词表大小我一般给两个选项通用场景32K-50K垂直领域代码中文英语混合50K-100K。词表越大模型能表示的空间更灵活但embedding矩阵参数会暴增训练和推理都会变慢词表太小长文本会被切成很多碎片训练效率反而不高。tokenizer训练一般用SentencePiece或Tokenizer库。重点要看它对空格、标点、数字的处理方式。中文场景我习惯把空格前缀处理开启数字按位数进行拆分。词表训练完之后一定要做一个覆盖率统计在你自己的专属语料里随机采样百万个文本统计有多少字/词被词表覆盖。覆盖率如果低于98%要么扩词表要么查一下是不是语料里有大量特殊符号。这一步检查只要几分钟能避免后面训了一两个epoch才发现词表有问题的惨剧。2.4 配比策略多语言、代码、数学与通用文本的调和数据配比是这个阶段最“玄学”也最见功力的一步。公开可查的很多模型报告配比都是“商业机密”级别。通用经验是通用文本占大头代码和数学等推理型数据要刻意提高比例。比如一个面向通用代码能力的1B模型可以参考这样的配比数据类别配比建议说明通用网页/百科50%-60%保证语言底座、常识覆盖代码20%-30%提升逻辑与结构化文本能力数学/科学5%-10%帮助模型掌握精确推理格式多语言其他5%-10%避免单语过拟合这不是精确参数而是给新手一个大概的锚点。配比之后还需要把每个类别的数据按“清晰度、去重率、质量分”再做一次全局排序保证sampler在取数时不会连续抽到同一类别的低质数据。我在实现时通常把不同类别做成独立的数据集文件再用按权重采样的DataLoader做混和这样后续想调整任何一个类别的比例都不用重写管线。3. 预训练阶段学习率、损失曲线与中途止损数据准备好预训练就是一场“开着车过隧道”的体验你不知道前面到底是直路还是急弯只能时刻盯着仪表盘。这个阶段最核心的仪表盘就是损失值和梯度范数。3.1 模型初始化与优化器设定如果你基于Transformer架构自己搭模型初始化策略很关键。常见做法是用标准差0.02左右的正态分布初始化同时对embedding层做较小初始化。还有一点容易被忽略如果你把深层数开得很大要考虑残差分支的初始化缩放比如把每层输出前的残差分支scale到1/sqrt(2 * num_layers)左右。这些看起来很微小的差异在深网络里会直接决定早期训练是稳定收敛还是一路NaN。优化器我默认用AdamWweight decay取0.1附近。beta参数一般沿用(0.9, 0.95)。在初始化阶段梯度范数如果突然超过固定阈值不要急着调学习率先检查是不是数据里出现了极端异常样本。很多时候一个包含超长重复字符的坏样本就能把训练节奏带崩。3.2 全局批大小与学习率调度预训练里全局批大小和学习率是成对调参的不能只看其中一个。经验公式是当全局batch size翻倍学习率大体上可以跟着放大sqrt(2)倍但这只在合理范围内成立。个人实测下来1B左右模型用全局batch size 512峰值学习率在3e-4到5e-4之间比较稳。如果你显存只够用256学习率就降到2e-4左右。学习率调度我推荐warmup cosine decay。warmup步数不要拍脑袋一般占总训练步数的2%到5%。总步数长的warmup可以适当放短一点比例总步数短的warmup比例要拉高否则模型在最开始震荡期还没站稳就进入高学习率容易把embedding搞坏。cosine把学习率一路降到峰值的1/10以下最后几十步如果损失还降得动可以再加一个超低学习率的“稳底”阶段。3.3 损失曲线的判读PPL在说什么预训练阶段的评估指标最常用的是perplexity困惑度。它的直觉含义是“模型对下一个token的惊讶程度”PPL越低说明模型对语料的预测越自信。但这里有个大坑——PPL降得好不代表下游任务一定做得好。PPL其实衡量的是“语言建模能力”翻译到人身上就是“这个模型词汇量大不大、语句通顺不通顺”跟“逻辑能力强不强、知识准不准”是两回事。我见过不少从零训练的模型PPL降到6以下表面看很漂亮但拿去回答数学题还是一塌糊涂。所以PPL只适合做训练过程的早期信号用于判断训练有没有在正常推进、学习率是不是太大、数据有没有出问题。更靠谱的下游能力还是要靠后续的基准测试来确认。3.4 日志、检查点与稳定性预防预训练长跑中最怕的就是训练到一半出现NaN或者损失激增。我的应对方案有三条每步都记录梯度范数、学习率、loss做成可搜索的日志。不要只看最后聚合值要看每一步的走势。检查点保存要有足够密度。早期我按“每500步”保存后来发现太浪费磁盘改成“按时间按步数”双策略每1小时保存一个重要步数点再额外存一个。从零训练这种长任务宁可多存废文件不能赌上一个检查点能救回来。对损失突刺保持冷静。损失突然飙升一步可能是样本里的异常值不用立刻停如果连续几百步都不回落那才需要回滚到前一个稳定检查点而不是继续硬熬。这些经验都是拿训练成本换来的。有一次我在40G显存的机器上训练忘了做梯度累积的clipping更惨的是检查点保存间隔太长一片NaN直接丢失了快20小时的进度。从那以后我再也不敢偷懒了。4. SFT阶段指令格式、数据质量与过拟合控制预训练结束模型就像一本“什么都知道但不怎么会聊天的书”。SFT阶段的本质是把书里的知识翻译成符合人类对话习惯的表达。这个阶段数据量不需要很大但对数据质量的要求极其苛刻。4.1 指令模板为什么这么重要很多人SFT踩坑的第一步就是指令模板不统一。今天用ChatML格式明天用User/Assistant格式训练时模型根本没机会真正学会“应该怎么区分指令和回复”。我这里强烈建议固定使用一套模板最稳妥的是ChatML|im_start|system 你是一个人工智能助手。|im_end| |im_start|user 你好请介绍一下自己。|im_end| |im_start|assistant 你好我是一个人工智能助手……|im_end|训练里所有文本都必须拼好模板后再tokenize。你可能觉得这是小事但我亲眼见过有人直接拿纯文本“问题答案”训练结果推理时模型根本理解不了“哪一段是用户说的”。模板是模型学习“角色边界”的教具不能省。另外一个细节对answer部分的token做mask处理loss只计算assistant回复的部分。否则模型会学着预测“用户隔几分钟会说什么”这对对话能力完全是干扰。虽然很多框架有现成实现但真要自己写训练循环的话务必记得这个。4.2 数据集的选择与构造质量优先还是数量优先SFT数据质量远比数量重要。个人观点5000条高质量、多样化的人工整理数据效果往往好过从网上抓来的10万条粗劣对话。现在常见的公开SFT数据源包括Alpaca、ShareGPT、UltraChat、OpenAssistant等。但这些数据都有各自的“风格偏向”直接混合之前需要做采样比例控制和抽样质量检查。我建议在构造SFT数据时至少覆盖这几类通用问答知识型问题、开放型讨论指令执行类改写、翻译、摘要、格式转换推理类数学题、逻辑题、代码实现题多轮对话至少包含几轮上下文的数据让模型学会承接话题。数据整理阶段要特别注意“问题与答案是否匹配”“答案中是否有事实错误”。这一步最好人工抽样检查哪怕只抽200条也比完全信任自动清洗要稳。SFT阶段数据量小人工检查成本完全可控。4.3 训练参数与过拟合SFT不是预训练SFT最容易犯的错误是“用预训练的思路训SFT”。预训练动辄几十亿token要训练好几个epochSFT数据量少通常1到3个epoch就足够了多了必然过拟合。我跑1B模型SFT时常用设置是学习率1e-5到2e-5batch size 16到32warmup占SFT总步数的5%到10%epoch不超过3。过拟合在SFT阶段的表现不是loss升高而是模型把训练数据中的固定句式背下来了。典型症状问它一个训练里没出现过的问题它给出的答案开头永远都是“首先我们需要了解……”这种万能废话。如果发现模型生成越来越“背课文”第一件事就是减少epoch和调低学习率而不是去加数据增强。4.4 用验证集确认“变得更像人了”SFT训练完别roll进垃圾桶就完事一定要留一小部分数据做验证集。取个最有用的验证维度看模型生成的句子是否自然、是否遵循了指令、有没有在多个问题上稳定产出而非复读。我的习惯是准备20到50个验证题涵盖训练时完全没见过的指令。然后用同一个模板让模型逐条回答自己一条条看重点看三种问题答非所问、话痨空转、结构性错误。这种人工抽检虽然原始但比任何自动指标都真实。当然如果你有时间还可以看一下生成样本里的重复率、平均回复长度、连续多轮是否仍然保持角色一致性。这套验证结果不要等到最后再去看SFT中途每隔几百步就抽查一次能提前发现很多潜在问题。5. DPO与RLHF阶段偏好优化走向实用对齐阶段往往是“网上讨论最多、教程最少、坑最深”的一节。标题里写的是DPO/RLHF我自己亲测下来DPO的性价比高太多所以这一章重点讲DPO的落地细节顺带说明RLHF为什么劝退。5.1 为什么RLHF对多数团队来说是坑传统RLHF至少要准备三套东西奖励模型RM、策略模型actor、参考模型reference然后用PPO去迭代。PPO训练本身非常不稳定要调的系数一堆KL系数、clip ratio、gae lambda显存占用也大因为我们同时要在内存里维护四个模型的状态。我不否认PPO在某些场景的最终效果上限更高但说句实话中小团队很少有能力把这一套跑稳。相比之下DPO的思路是绕开显式的奖励模型直接用偏好数据来优化策略。这样训练时只有两个模型正在训练的actor和冻结的reference。显存压力小一个量级训练稳定性也高很多。这也是现在很多开源项目默认选DPO的主要原因。5.2 DPO的数学直觉与实现要点DPO的数学推导一句话概括假设存在一个隐式的奖励函数通过Bradley-Terry模型建模偏好然后把它代入RLHF的目标函数最后能化简成一个简单的交叉熵损失。实现上核心逻辑是对每一对(chosen, rejected)样本分别计算当前策略和reference在两条回复上的log概率然后通过一个log(sigmoid(beta * (log_p_chosen - log_ref_chosen - log_p_rejected log_ref_rejected)))来更新。这里的beta是KL约束系数控制模型偏离reference的尺度。实操中最大的坑是“reference和actor没分清楚”。如果你用同一份模型同时当actor和reference又没有冻结reference的梯度那训练就变成了模型追着自己跑更新方向直接乱掉。所以代码里务必先复制一份一模一样的reference模型置为eval()全程不要更新它。5.3 偏好数据构造chosen和rejected怎么来的偏好数据质量直接决定DPO效果。最基础的要求是同样的prompt对应的chosen回复必须明显优于rejected回复。如果两条回复水平差不多DPO的梯度信号会非常弱甚至会让模型产生随机漂移。我的建议是数据构造时遵循三条原则同一个prompt至少让两个不同模型生成多条候选再人工或规则选择最好和最差的各一条。拒绝“弱差样本”比如chosen是长篇详细的rejected是“我不知道”这种敷衍回答模型会很快学会直接拒绝这不是真正的偏好对齐。混合“编辑型偏好”对有些回答本身还可以但存在小错误的样本与其选一条全错的做rejected不如让人类把正确答案改出来这样信号更精细。此外偏好数据也要覆盖多样化的场景不只是“答得好不好”还包括“风格受不受欢迎”“语气是否礼貌”“是否简洁”。模型对齐的其实是“你觉得什么更好”所以数据要体现你的价值观。5.4 beta取值与训练步数DPO也要防过拟合DPO训练里我最常被问到的就是beta取多少。这个值没有唯一答案但有一个合理的参考区间大多数开源实现里beta在0.1到0.5之间。beta越大模型越偏离reference对齐力度越强但也更容易产生奖励欺骗hacking或多样性崩塌。我一般从0.1开始试观察模型在验证集上的人工偏好率如果一段时间没提升再逐步加大到0.3附近。训练步数同样不能多。DPO的过拟合来得非常快经常一个epoch甚至半个epoch就让模型的生成风格产生剧烈变化。我的习惯是保存多个checkpoint每训练几十步就在验证集上看一批生成结果找到“偏好提升但语言自然度没有缩放”的那个临界点然后用那个检查点做后续部署。不要迷信“训练完的最后一个权重”DPO场景里中途的权重可能更好用。6. 评估贯穿全程别把最后一天留给评估很多人的评估习惯是“训练完了跑几个benchmark发个报告”。但从零训练大模型评估必须贯穿整个生命周期的每个阶段因为不同阶段回答的问题根本不一样。6.1 预训练阶段的PPL评估与它的局限预训练阶段PPL是最直观的早期信号适用范围是“训练是否正常、模型是否在拟合数据”。但PPL有两个明显的毛病一是它对文本中的重复片段不敏感模型哪怕只会复读PPL也能压得很低二是PPL测试集如果和训练集数据来源太接近评估结果会虚高。所以PPL用的测试集需要单独留出一批干净、不参与训练的语料而且最好覆盖多个领域比如新闻、百科、代码、技术文档分开算这样能看到模型在各领域的拟合程度。我习惯在每个checkpoint上跑一个小测试集大概300M到500M token不求多只求快。关键是看不同领域的PPL是不是一起在降。如果某个领域的PPL明显高大概率是数据配比偏低后面可以考虑给对应类别加权重。6.2 SFT阶段的任务级评估比PPL更接近真实使用SFT之后PPL的作用明显下降因为模型已经会按照指令输出这时候更需要任务级评估。标准做法是选择一个开放的评估框架跑一批公开benchmark。常见的比如MMLU知识推理、GSM8K数学、HumanEval代码、C-Eval中文综合。这里要说一个非常容易被忽略的点不要为了“好看的数字”去反复跑同一个benchmark。因为你一旦在同一个测试集上调过prompt、改过few-shot示例就是在变相过拟合这个测试集。正确做法是固定一套评估配置包括prompt模板、few-shot数量在整个训练周期里保持不变所有的对比才有意义。我一般还会把评测时用的生成参数也固定下来比如temperature、top_p否则结果根本没法复现。6.3 对齐阶段的人工偏好评估数字再漂亮不如人眼把关对齐阶段的评估光看自动指标会失真。DPO的loss降低只说明模型和reference的距离在拉大并不能证明“人类更喜欢它了”。所以在这个阶段一定要引入人工评估。最便宜的做法是“A/B盲测”让评估者在两个模型的回答中选更喜欢的一个同时不知道哪条来自哪个模型。无论是一个人自己选还是团队里几个人一起选都比只看正则化指标可靠得多。我实际操作中会构建一个小题库每次评估都用同一批题。评价维度不是简单的“对错”而是“是否遵循指令”“回答是否自然”“信息是否准确”“是否有过度重复”。每个维度按1到5打分。跑完后看平均分和胜率重点看负面的bad case它们能精确告诉你DPO又在哪个风格上跑偏了。6.4 部署后的效果回测评估的最后一公里很多人把评估止步于benchmark但其实最贴近真实价值的评估是部署后的效果回测。你在训练时设计的问题和线上真实用户问的问题通常分布差异很大。所以我的建议是模型上线前先拿一批真实的、脱敏后的用户问题做回放测试。在这一步里用vllm部署一个推理服务把离线积累的真实query灌进去逐个跑生成结果。然后重点看三类问题安全承诺是否被绕过、生成是否崩坏、延迟是否符合交互要求。如果你还接入了RAG之类的检索增强框架最好再配上RAG专用的评估工具比如ragas把检索质量、生成忠实度、答案相关性都量化出来。到这里从零训练一个大模型的完整闭环就齐了数据预处理、预训练、SFT、偏好对齐、评估回测。我最后再分享一个小经验别把“训练完”当终点把评估日志都保留下来下次训练新版本时对照着看你会惊喜地发现大模型训练最大的提速工具不是更好的卡而是你之前踩过的每一个坑。 从零训练大模型：数据、预训练、SFT与DPO全流程实战解析
1. 动手前先泼三盆冷水硬件、数据与预期管理我记得自己第一次动“从头训一个大模型”这个念头是在看到一篇开源中文基座模型的报告之后。当时心里想的是别人能做我为什么不能做。结果真正动手之前先做了个预算表格差点把自己劝退。这里先分享几个关键结论省得后来者走弯路。1.1 一张卡能训动什么规模先算清楚显存账很多人会把“训练大模型”和“跑推理”混在一起来算显存。跑一个7B模型的推理一张24GB显卡就勉强够但训练它完全是另一回事。全参数训练时显存里要同时装下模型权重、梯度、优化器状态Adam一般有主权重、一阶动量、二阶动量三份副本以及前向激活值。粗略估算每1B参数在bf16精度下全参数训练大约需要16到20GB显存这还没算上激活值。所以我个人建议模型规模全参数训练最低显存实际可参考配置用什么能跑起来100M-500M8-12GB单张消费级显卡全参数训练无压力1B-2B24-40GB单张A100/H100或双卡3090全参数勉强可行7B左右80-120GB以上4卡A100起步必须配合DeepSpeed ZeRO或FSDP13B以上200GB多机多卡不建议个人坑里跳所以如果你手里只有一块消费级显卡别一上来就想着从零训练7B先拿1B以下把全流程跑通这个投入产出比最高。等代码、数据和流程都熟了再考虑换机器上规模踩坑成本完全不一样。1.2 数据规模的最低线Chinchilla法则的实用修正训练大模型有一个绕不开的经典参考Chinchilla法则。它的核心结论是在固定算力预算下模型参数量与训练token数大致存在一个最优比例大约是每1B参数对应20B token。但这里我想说点实际经验——个人做从零训练最好不要把这个比例当成铁律。原因很简单个人或小团队的数据量和算力都有限。按照20:1要训好一个1B模型需要不下20B高质量token光是清洗、过滤、去重就能让人怀疑人生。实操中大家更常用的是“压缩版”方案1B模型配4到8B token先让模型有基本语言能力反正后面还有SFT阶段兜底。数据少一点模型会欠拟合一点但整个训练周期从“几周”缩短到“几天”对前期迭代太重要了。Chinchilla法则给出的是最优算力分配不是最低可行方案。1.3 从零训练的真实收益什么场景值得这么做接下来是最容易被忽略的一步想清楚自己到底要不要“从零”训练。因为很多人口中的“从零训练”其实用继续预训练Continue Pretraining就能解决。我在实际帮团队做技术选型时一般用这几个问题来判断目标领域有没有大量独特数据比如垂直行业日志、专有的代码仓库、特殊符号语料这些通用模型没见过。是否需要完全控制数据配比和词表比如中文、代码、数学混合比例极高不如自己训一个词表更贴合。版权和合规有没有硬性要求部分场景不允许把数据喂给外部API这时候自己训一个基座反而更安心。有没有足够的工程人力来维护训练链路如果答案是“只有我一个人业余时间”那更务实的路线是拿开源基座做SFT而不是重头训练。我自己经历下来最大的体会是从零训练的价值不在“复刻一个GPT”而在于把数据处理、模型结构、训练稳定性、评估体系这一条链路彻底跑通。哪怕最终模型只有几百M过程中积累的经验在后面任何一次微调或部署中都能直接变现。2. 数据管线的完整闭环采集、清洗、去重与配比预训练是“穷人才自己动手”的阶段因为它的全部成本几乎都压在数据上。很多教程会把这一章飞快带过然后大讲Transformer结构。但我敢说数据环节做的糙后面预训练损失曲线一定很难看。这个阶段没有捷径只能一条条地把管线搭扎实。2.1 数据从哪来公开语料与领域数据的取舍预训练数据源大类上无非三类通用网页文本、书籍/论文类长文本、结构化语料代码、数学公式、百科。常见的公开语料有Common Crawl、维基百科、各类开源中文语料如WuDaoCorpora、CLUECorpus等。如果你的目标是通用能力直接拿这些公开语料起步最快。如果你的目标是垂直领域比如法律、金融、医疗那就必须加入大量领域内原始文档。我的做法是按“源类型”分别建目录保持元信息完整比如来源域名、抓取时间、文档级别哈希。这样在后面做数据配比时可以随时追溯“这条数据到底来自哪、长什么样”排查问题会顺手很多。不要小看这一步等训练完想分析某个bad case时元信息是你唯一的救命稻草。2.2 清洗与去重质量过滤的优先级排序清洗的优先级我建议按这个顺序来编码层过滤乱码、非UTF-8、控制字符直接丢。语言识别过滤用fastText或语种检测库筛掉目标语言之外的内容。中文场景特别要注意繁体、简体和“伪中文”外文机翻的区分。质量启发式过滤统计句均长度、符号占比、重复字符占比、标点密度。对于中文语料一个简单但有效的规则是全文平均句长低于某个阈值或者高频n-gram重复率过高基本可以判定为低质内容。精确去重与近似去重精确去重用内容哈希近似去重普通做法是MinHash LSH按Jaccard相似度做去重。这里特别提醒很多人只做文档级去重忽略了段落级去重。实际上网页模板、导航栏、重复的免责声明在文档级去重里完全逃得掉却会污染训练数据让模型学会大量无意义重复文本。我在实操中还会加一道“累积重复率”检测对文本按句子切分后看后50%的句子中有多少与前50%重复。如果相邻两三段都在重复同一句话这种数据比简单低质文本更可怕它会让模型在生成时陷入复读机状态。2.3 tokenizer训练词表大小与合并规则很多人会把tokenizer训练拖到最后甚至直接拿现成词表用。如果你是从零训练我还是建议自己做一次词表训练核心原因是中文场景下现成词表不一定适配你的数据领域。词表大小我一般给两个选项通用场景32K-50K垂直领域代码中文英语混合50K-100K。词表越大模型能表示的空间更灵活但embedding矩阵参数会暴增训练和推理都会变慢词表太小长文本会被切成很多碎片训练效率反而不高。tokenizer训练一般用SentencePiece或Tokenizer库。重点要看它对空格、标点、数字的处理方式。中文场景我习惯把空格前缀处理开启数字按位数进行拆分。词表训练完之后一定要做一个覆盖率统计在你自己的专属语料里随机采样百万个文本统计有多少字/词被词表覆盖。覆盖率如果低于98%要么扩词表要么查一下是不是语料里有大量特殊符号。这一步检查只要几分钟能避免后面训了一两个epoch才发现词表有问题的惨剧。2.4 配比策略多语言、代码、数学与通用文本的调和数据配比是这个阶段最“玄学”也最见功力的一步。公开可查的很多模型报告配比都是“商业机密”级别。通用经验是通用文本占大头代码和数学等推理型数据要刻意提高比例。比如一个面向通用代码能力的1B模型可以参考这样的配比数据类别配比建议说明通用网页/百科50%-60%保证语言底座、常识覆盖代码20%-30%提升逻辑与结构化文本能力数学/科学5%-10%帮助模型掌握精确推理格式多语言其他5%-10%避免单语过拟合这不是精确参数而是给新手一个大概的锚点。配比之后还需要把每个类别的数据按“清晰度、去重率、质量分”再做一次全局排序保证sampler在取数时不会连续抽到同一类别的低质数据。我在实现时通常把不同类别做成独立的数据集文件再用按权重采样的DataLoader做混和这样后续想调整任何一个类别的比例都不用重写管线。3. 预训练阶段学习率、损失曲线与中途止损数据准备好预训练就是一场“开着车过隧道”的体验你不知道前面到底是直路还是急弯只能时刻盯着仪表盘。这个阶段最核心的仪表盘就是损失值和梯度范数。3.1 模型初始化与优化器设定如果你基于Transformer架构自己搭模型初始化策略很关键。常见做法是用标准差0.02左右的正态分布初始化同时对embedding层做较小初始化。还有一点容易被忽略如果你把深层数开得很大要考虑残差分支的初始化缩放比如把每层输出前的残差分支scale到1/sqrt(2 * num_layers)左右。这些看起来很微小的差异在深网络里会直接决定早期训练是稳定收敛还是一路NaN。优化器我默认用AdamWweight decay取0.1附近。beta参数一般沿用(0.9, 0.95)。在初始化阶段梯度范数如果突然超过固定阈值不要急着调学习率先检查是不是数据里出现了极端异常样本。很多时候一个包含超长重复字符的坏样本就能把训练节奏带崩。3.2 全局批大小与学习率调度预训练里全局批大小和学习率是成对调参的不能只看其中一个。经验公式是当全局batch size翻倍学习率大体上可以跟着放大sqrt(2)倍但这只在合理范围内成立。个人实测下来1B左右模型用全局batch size 512峰值学习率在3e-4到5e-4之间比较稳。如果你显存只够用256学习率就降到2e-4左右。学习率调度我推荐warmup cosine decay。warmup步数不要拍脑袋一般占总训练步数的2%到5%。总步数长的warmup可以适当放短一点比例总步数短的warmup比例要拉高否则模型在最开始震荡期还没站稳就进入高学习率容易把embedding搞坏。cosine把学习率一路降到峰值的1/10以下最后几十步如果损失还降得动可以再加一个超低学习率的“稳底”阶段。3.3 损失曲线的判读PPL在说什么预训练阶段的评估指标最常用的是perplexity困惑度。它的直觉含义是“模型对下一个token的惊讶程度”PPL越低说明模型对语料的预测越自信。但这里有个大坑——PPL降得好不代表下游任务一定做得好。PPL其实衡量的是“语言建模能力”翻译到人身上就是“这个模型词汇量大不大、语句通顺不通顺”跟“逻辑能力强不强、知识准不准”是两回事。我见过不少从零训练的模型PPL降到6以下表面看很漂亮但拿去回答数学题还是一塌糊涂。所以PPL只适合做训练过程的早期信号用于判断训练有没有在正常推进、学习率是不是太大、数据有没有出问题。更靠谱的下游能力还是要靠后续的基准测试来确认。3.4 日志、检查点与稳定性预防预训练长跑中最怕的就是训练到一半出现NaN或者损失激增。我的应对方案有三条每步都记录梯度范数、学习率、loss做成可搜索的日志。不要只看最后聚合值要看每一步的走势。检查点保存要有足够密度。早期我按“每500步”保存后来发现太浪费磁盘改成“按时间按步数”双策略每1小时保存一个重要步数点再额外存一个。从零训练这种长任务宁可多存废文件不能赌上一个检查点能救回来。对损失突刺保持冷静。损失突然飙升一步可能是样本里的异常值不用立刻停如果连续几百步都不回落那才需要回滚到前一个稳定检查点而不是继续硬熬。这些经验都是拿训练成本换来的。有一次我在40G显存的机器上训练忘了做梯度累积的clipping更惨的是检查点保存间隔太长一片NaN直接丢失了快20小时的进度。从那以后我再也不敢偷懒了。4. SFT阶段指令格式、数据质量与过拟合控制预训练结束模型就像一本“什么都知道但不怎么会聊天的书”。SFT阶段的本质是把书里的知识翻译成符合人类对话习惯的表达。这个阶段数据量不需要很大但对数据质量的要求极其苛刻。4.1 指令模板为什么这么重要很多人SFT踩坑的第一步就是指令模板不统一。今天用ChatML格式明天用User/Assistant格式训练时模型根本没机会真正学会“应该怎么区分指令和回复”。我这里强烈建议固定使用一套模板最稳妥的是ChatML|im_start|system 你是一个人工智能助手。|im_end| |im_start|user 你好请介绍一下自己。|im_end| |im_start|assistant 你好我是一个人工智能助手……|im_end|训练里所有文本都必须拼好模板后再tokenize。你可能觉得这是小事但我亲眼见过有人直接拿纯文本“问题答案”训练结果推理时模型根本理解不了“哪一段是用户说的”。模板是模型学习“角色边界”的教具不能省。另外一个细节对answer部分的token做mask处理loss只计算assistant回复的部分。否则模型会学着预测“用户隔几分钟会说什么”这对对话能力完全是干扰。虽然很多框架有现成实现但真要自己写训练循环的话务必记得这个。4.2 数据集的选择与构造质量优先还是数量优先SFT数据质量远比数量重要。个人观点5000条高质量、多样化的人工整理数据效果往往好过从网上抓来的10万条粗劣对话。现在常见的公开SFT数据源包括Alpaca、ShareGPT、UltraChat、OpenAssistant等。但这些数据都有各自的“风格偏向”直接混合之前需要做采样比例控制和抽样质量检查。我建议在构造SFT数据时至少覆盖这几类通用问答知识型问题、开放型讨论指令执行类改写、翻译、摘要、格式转换推理类数学题、逻辑题、代码实现题多轮对话至少包含几轮上下文的数据让模型学会承接话题。数据整理阶段要特别注意“问题与答案是否匹配”“答案中是否有事实错误”。这一步最好人工抽样检查哪怕只抽200条也比完全信任自动清洗要稳。SFT阶段数据量小人工检查成本完全可控。4.3 训练参数与过拟合SFT不是预训练SFT最容易犯的错误是“用预训练的思路训SFT”。预训练动辄几十亿token要训练好几个epochSFT数据量少通常1到3个epoch就足够了多了必然过拟合。我跑1B模型SFT时常用设置是学习率1e-5到2e-5batch size 16到32warmup占SFT总步数的5%到10%epoch不超过3。过拟合在SFT阶段的表现不是loss升高而是模型把训练数据中的固定句式背下来了。典型症状问它一个训练里没出现过的问题它给出的答案开头永远都是“首先我们需要了解……”这种万能废话。如果发现模型生成越来越“背课文”第一件事就是减少epoch和调低学习率而不是去加数据增强。4.4 用验证集确认“变得更像人了”SFT训练完别roll进垃圾桶就完事一定要留一小部分数据做验证集。取个最有用的验证维度看模型生成的句子是否自然、是否遵循了指令、有没有在多个问题上稳定产出而非复读。我的习惯是准备20到50个验证题涵盖训练时完全没见过的指令。然后用同一个模板让模型逐条回答自己一条条看重点看三种问题答非所问、话痨空转、结构性错误。这种人工抽检虽然原始但比任何自动指标都真实。当然如果你有时间还可以看一下生成样本里的重复率、平均回复长度、连续多轮是否仍然保持角色一致性。这套验证结果不要等到最后再去看SFT中途每隔几百步就抽查一次能提前发现很多潜在问题。5. DPO与RLHF阶段偏好优化走向实用对齐阶段往往是“网上讨论最多、教程最少、坑最深”的一节。标题里写的是DPO/RLHF我自己亲测下来DPO的性价比高太多所以这一章重点讲DPO的落地细节顺带说明RLHF为什么劝退。5.1 为什么RLHF对多数团队来说是坑传统RLHF至少要准备三套东西奖励模型RM、策略模型actor、参考模型reference然后用PPO去迭代。PPO训练本身非常不稳定要调的系数一堆KL系数、clip ratio、gae lambda显存占用也大因为我们同时要在内存里维护四个模型的状态。我不否认PPO在某些场景的最终效果上限更高但说句实话中小团队很少有能力把这一套跑稳。相比之下DPO的思路是绕开显式的奖励模型直接用偏好数据来优化策略。这样训练时只有两个模型正在训练的actor和冻结的reference。显存压力小一个量级训练稳定性也高很多。这也是现在很多开源项目默认选DPO的主要原因。5.2 DPO的数学直觉与实现要点DPO的数学推导一句话概括假设存在一个隐式的奖励函数通过Bradley-Terry模型建模偏好然后把它代入RLHF的目标函数最后能化简成一个简单的交叉熵损失。实现上核心逻辑是对每一对(chosen, rejected)样本分别计算当前策略和reference在两条回复上的log概率然后通过一个log(sigmoid(beta * (log_p_chosen - log_ref_chosen - log_p_rejected log_ref_rejected)))来更新。这里的beta是KL约束系数控制模型偏离reference的尺度。实操中最大的坑是“reference和actor没分清楚”。如果你用同一份模型同时当actor和reference又没有冻结reference的梯度那训练就变成了模型追着自己跑更新方向直接乱掉。所以代码里务必先复制一份一模一样的reference模型置为eval()全程不要更新它。5.3 偏好数据构造chosen和rejected怎么来的偏好数据质量直接决定DPO效果。最基础的要求是同样的prompt对应的chosen回复必须明显优于rejected回复。如果两条回复水平差不多DPO的梯度信号会非常弱甚至会让模型产生随机漂移。我的建议是数据构造时遵循三条原则同一个prompt至少让两个不同模型生成多条候选再人工或规则选择最好和最差的各一条。拒绝“弱差样本”比如chosen是长篇详细的rejected是“我不知道”这种敷衍回答模型会很快学会直接拒绝这不是真正的偏好对齐。混合“编辑型偏好”对有些回答本身还可以但存在小错误的样本与其选一条全错的做rejected不如让人类把正确答案改出来这样信号更精细。此外偏好数据也要覆盖多样化的场景不只是“答得好不好”还包括“风格受不受欢迎”“语气是否礼貌”“是否简洁”。模型对齐的其实是“你觉得什么更好”所以数据要体现你的价值观。5.4 beta取值与训练步数DPO也要防过拟合DPO训练里我最常被问到的就是beta取多少。这个值没有唯一答案但有一个合理的参考区间大多数开源实现里beta在0.1到0.5之间。beta越大模型越偏离reference对齐力度越强但也更容易产生奖励欺骗hacking或多样性崩塌。我一般从0.1开始试观察模型在验证集上的人工偏好率如果一段时间没提升再逐步加大到0.3附近。训练步数同样不能多。DPO的过拟合来得非常快经常一个epoch甚至半个epoch就让模型的生成风格产生剧烈变化。我的习惯是保存多个checkpoint每训练几十步就在验证集上看一批生成结果找到“偏好提升但语言自然度没有缩放”的那个临界点然后用那个检查点做后续部署。不要迷信“训练完的最后一个权重”DPO场景里中途的权重可能更好用。6. 评估贯穿全程别把最后一天留给评估很多人的评估习惯是“训练完了跑几个benchmark发个报告”。但从零训练大模型评估必须贯穿整个生命周期的每个阶段因为不同阶段回答的问题根本不一样。6.1 预训练阶段的PPL评估与它的局限预训练阶段PPL是最直观的早期信号适用范围是“训练是否正常、模型是否在拟合数据”。但PPL有两个明显的毛病一是它对文本中的重复片段不敏感模型哪怕只会复读PPL也能压得很低二是PPL测试集如果和训练集数据来源太接近评估结果会虚高。所以PPL用的测试集需要单独留出一批干净、不参与训练的语料而且最好覆盖多个领域比如新闻、百科、代码、技术文档分开算这样能看到模型在各领域的拟合程度。我习惯在每个checkpoint上跑一个小测试集大概300M到500M token不求多只求快。关键是看不同领域的PPL是不是一起在降。如果某个领域的PPL明显高大概率是数据配比偏低后面可以考虑给对应类别加权重。6.2 SFT阶段的任务级评估比PPL更接近真实使用SFT之后PPL的作用明显下降因为模型已经会按照指令输出这时候更需要任务级评估。标准做法是选择一个开放的评估框架跑一批公开benchmark。常见的比如MMLU知识推理、GSM8K数学、HumanEval代码、C-Eval中文综合。这里要说一个非常容易被忽略的点不要为了“好看的数字”去反复跑同一个benchmark。因为你一旦在同一个测试集上调过prompt、改过few-shot示例就是在变相过拟合这个测试集。正确做法是固定一套评估配置包括prompt模板、few-shot数量在整个训练周期里保持不变所有的对比才有意义。我一般还会把评测时用的生成参数也固定下来比如temperature、top_p否则结果根本没法复现。6.3 对齐阶段的人工偏好评估数字再漂亮不如人眼把关对齐阶段的评估光看自动指标会失真。DPO的loss降低只说明模型和reference的距离在拉大并不能证明“人类更喜欢它了”。所以在这个阶段一定要引入人工评估。最便宜的做法是“A/B盲测”让评估者在两个模型的回答中选更喜欢的一个同时不知道哪条来自哪个模型。无论是一个人自己选还是团队里几个人一起选都比只看正则化指标可靠得多。我实际操作中会构建一个小题库每次评估都用同一批题。评价维度不是简单的“对错”而是“是否遵循指令”“回答是否自然”“信息是否准确”“是否有过度重复”。每个维度按1到5打分。跑完后看平均分和胜率重点看负面的bad case它们能精确告诉你DPO又在哪个风格上跑偏了。6.4 部署后的效果回测评估的最后一公里很多人把评估止步于benchmark但其实最贴近真实价值的评估是部署后的效果回测。你在训练时设计的问题和线上真实用户问的问题通常分布差异很大。所以我的建议是模型上线前先拿一批真实的、脱敏后的用户问题做回放测试。在这一步里用vllm部署一个推理服务把离线积累的真实query灌进去逐个跑生成结果。然后重点看三类问题安全承诺是否被绕过、生成是否崩坏、延迟是否符合交互要求。如果你还接入了RAG之类的检索增强框架最好再配上RAG专用的评估工具比如ragas把检索质量、生成忠实度、答案相关性都量化出来。到这里从零训练一个大模型的完整闭环就齐了数据预处理、预训练、SFT、偏好对齐、评估回测。我最后再分享一个小经验别把“训练完”当终点把评估日志都保留下来下次训练新版本时对照着看你会惊喜地发现大模型训练最大的提速工具不是更好的卡而是你之前踩过的每一个坑。