企业官网建设流程全解析

大模型训练这件事，网上说的人多，真正从数据到评估完整跑通的人少。大多数人看到的是各家机构发布的模型卡和论文，真正实践时面对的却是数据清洗、loss异常、显存爆炸、对齐效果不稳定这些具体问题。这篇内容我按真实训练流程来写，从数据准备、预训练、SFT、DPO/RLHF到评估，每个环节都给出可落地的方案和参数参考，也包括踩坑记录。无论你是想从零训练一个百亿级模型，还是只想系统理解大模型训练全链路，都可以按这条路径走一遍。

1. 先搞清楚一件事：你到底要不要从零训

1.1 从零训练不是炫技，而是需求驱动的决策

在这个开源模型遍地都是的时代，从零训练一个大模型并不是默认选项，它只适用于几类特定场景。我在决定启动这个项目前，花了整整两周做前期论证，核心就一个问题：现有的开源模型能不能满足需求？

先说结论：如果你的任务是中文长文本理解、垂直领域知识密集型问答、特定格式生成，微调一个开源基座就足够了，从零训练反而会拖垮预算和迭代周期。但如果你的场景同时满足以下条件，从零训练才值得考虑：

第一，领域数据在通用语料中占比极低，比如特定古籍整理、特殊行业文档结构化、某种专业符号体系的翻译，这些内容在开源模型的预训练语料里几乎不存在，单纯靠微调是“无中生有”，模型很难学会。

第二，你对模型架构和训练流程有改造需求，比如要改注意力机制、要接入特殊编码器、要控制词表大小以适应某些边缘设备，从已有模型改架构的难度往往大于从头训一个。

第三，你有长期迭代的计划，模型底座要持续升级，从零训练能让你完整掌握数据配比、训练节奏、对齐策略这些环节，后面每次迭代都是可控的。

我这次训练的模型定位是“中文百科全书式问答助手”，语料以中文高质量文本为主，参数量定在3B级别。选这个规模的原因很实际：单机8卡A100（80G）就能完成预训练，总成本可控，迭代速度快，且在推理侧部署成本低。很多人一上来就奔着几十B甚至上百B去，结果卡在显存和电力预算上，项目就烂尾了。如果你的资源有限，建议从1B到3B起步，把全链路跑通，再考虑放大。

1.2 路线图与真实成本估算

整个训练链路我拆成了五个阶段，每个阶段的耗时和成本完全不一样。预训练占大头，大概占整体预算的70%以上；SFT和对齐阶段虽然数据量小得多，但需要反复调参实验，迭代次数反而很多；评估看似简单，但真正的有效评估需要大量人力投入标注，这块往往被低估。

用3B模型、中文语料1万亿token来算一笔账：在8卡A100上，每卡每秒约处理3000-5000 token（取决于上下文长度和优化器配置），理论吞吐量大约是每秒3万-4万 token。每小时能处理1.1亿-1.4亿 token，1万亿token需要约710-900小时，即30-40天连续训练。按A100租用市场行情算，这个阶段的成本约15万-25万元人民币。如果数据量减到5000亿token，成本和周期都能减半。

SFT阶段的数据量通常在100万-500万条指令对，训练3-5个epoch，8卡并行下一天内就能完成。DPO或RLHF阶段的数据量在10万-50万条偏好对，训练也不超过一天。但这两个阶段由于要反复实验不同参数，实际消耗的时间可能是训练本身的好几倍。

我强烈建议在项目启动前就明确“每个阶段的可接受最低效果指标”。比如预训练阶段，验证集loss下降到某个值才进入SFT；SFT后人工抽测回答质量达标率多少；对齐后安全评测通过率多少。没有这些量化指标，你会陷入无休止的调参循环。

2. 数据工程：决定模型上限的第一道工序

2.1 数据从哪来：混合多源语料的配比思路

大模型的能力上限，很大程度上在数据阶段就锁定了。模型架构和训练技巧只是把数据里蕴含的知识和模式提取出来，数据里没有的东西，模型不可能凭空学会。所以数据工程这部分，值得你投入最大的精力。

我从五个来源收集语料，每个来源的配比经过了多轮实验调整：

• 通用网页文本：来自Common Crawl的中文子集、中文维基百科、百度百科等，占比约60%。这部分提供基础语言能力和世界知识，但噪声很大，必须严格清洗。
• 高质量书籍与论文：各类公开的中文书籍、arXiv论文、期刊资源，占比约15%。这部分语言质量高、逻辑性强，对模型的长文理解和推理能力帮助很大，但数量有限，需要反复清洗和去重。
• 结构化知识库：包括百科类结构化数据、领域知识图谱、医学/法律/工程等专项数据库，占比约10%。这部分决定了后续微调阶段的上限，如果这里的领域数据质量不行，后面花再多精力对齐也补不回来。
• 对话与社区语料：知乎、豆瓣、百度贴吧等平台的公开数据，占比约10%。这部分语料口语化强，对模型后续“像人一样说话”很有帮助，但涉及隐私和安全的内容必须过滤掉。
• 代码数据：GitHub公开代码库的中文注释、技术文档，占比约5%。代码语料能显著增强模型对逻辑和结构化信息的理解能力，即使你的任务不涉及写代码，也建议保留少量代码数据。

这个配比不是一次到位的。我第一版训练用了纯网页文本，结果模型生成的内容虽然通顺，但事实性极差，一句话里三个事实错两个。后来逐步加入书籍和结构化和知识库，事实性才明显提升。建议你每次改配比之后，都做一次小规模（比如10亿token）的试训练，对比效果再决定下一步，不要一次投入全部数据。

2.2 清洗、去重、质量过滤，一个都不能少

数据清洗的流程我按“规则清洗→质量过滤→语义去重→安全检查”四步来做，每一步都不省。

规则清洗解决的是明显垃圾：HTML标签、控制字符、只包含数字或符号的无效行、乱码文本、广告和营销内容。我用了一套基于规则的正则表达式，加上布隆过滤器做URL去重。公开爬取语料里总有大量低质内容，清洗后往往能减掉20%-30%的原始文本。

质量过滤这一步很关键。我用了两个维度：文本长度和困惑度。单条样本少于200个字符的直接丢弃，因为短文本很难提供完整的语义信息；困惑度过高的文本通常是乱码或极端口语化内容，也直接过滤。困惑度的阈值我在实验中选择的分数是“PPL>500则丢弃”，结合语言模型打分，这一步能把剩余噪声再压掉一半。实际操作时，你不需要自己训一个打分模型，用现成的小型bert或xlm-roberta即可，速度也够快。

语义去重不能只靠字符串匹配。我用MinHash加LSH方案，先对文本做jaccard相似度计算并分组，再做簇内过滤。相似度超过0.85的文本只保留一条，优先保留来自更高质量源的那条。这个步骤的重要性被很多人低估——重复数据会直接导致模型过拟合，在评估集上表现为泛化能力差，生成内容严重的复读倾向。

安全检查这步不容含糊。大模型训练语料里如果混入大量违法违规内容，模型会在生成阶段直接复现。我用关键词黑名单加分类模型双重过滤，黑名单覆盖色情、暴力、赌博等类别。这一步必须做，不只是合规问题，也是模型质量的基本保障。

2.3 tokenization与数据配比的主要参数

tokenization是大模型训练里容易被忽略但实际影响很大的环节。中文的tokenize方式和英文不同，如果直接用BPE切中文，会产生大量碎片化的token，降低训练效率。我用的方案是：基于sentencepiece训练一个词表为5万的中文spm模型，采用byte-level BPE方法，把中文字符、常用词、英文单词、代码符号都纳入词表中。

词表大小需要把握一个平衡：太小会导致单字被拆多次，训练效率低；太大会让embedding矩阵过大，增加训练参数量。5万对3B模型是个稳妥的选择，embedding和输出层的参数量大约占模型总参数的30%，这个占比是可控的。如果你准备训练更大规模的模型，词表可以适当放大到8万到10万，但要提前算好显存。

tokenization之后要做数据配比与混洗。我采用的是“先按配比混合，再全局随机打乱”的方式。注意这里的细节：如果不同来源的数据本身是分文件存储的，一定要在按比例融合后再做全量随机shuffle，否则模型会在训练早期集中学习某一种分布的数据，出现阶段性的loss异常波动。

另外提醒一点：数据管道的数据加载和预处理必须以离线完成的中间格式进行。把原始文本直接在训练循环里做tokenize，速度会慢到难以接受。我通常先把全部数据离线tokenize为二进制格式（如arrow或mmap），训练时直接读token序列，既省CPU，也方便做断点续训。

3. 预训练：最关键也最枯燥的一环

3.1 基础配置与关键参数

预训练阶段的核心配置，我直接给出一份经过验证的参数组合，3B模型、中文语料场景下可以直接参考：

# 模型结构（3B级别） hidden_size: 2560 num_hidden_layers: 32 num_attention_heads: 32 intermediate_size: 10240 max_position_embeddings: 8192 vocab_size: 50000 # 训练配置 batch_size: 512 (按序列长度8192计算) learning_rate: 1.5e-4 warmup_steps: 2000 lr_scheduler: cosine weight_decay: 0.1 optimizer: adamw

3B级别建议用bf16混合精度训练。A100对bf16的支持很好，训练速度约是fp32的2-3倍，显存还省一半。梯度累积步数设为8，每批次有效样本数为1024。序列长度从4096开始，预训练到一半再切换为8192，这种动态长度策略能降低前期训练成本，同时让模型更平滑地适应长文本。

学习率是最敏感的超参数。我在实验中对比了1e-4到3e-4几个档位，1.5e-4表现最稳。如果你发现训练中期loss出现明显震荡，可以适当降低学习率；但如果前期就不收敛，问题往往不在学习率，而在数据或embedding初始化。warmup步数大概占整个训练步数的1%-2%即可，太少会导致大学习率冲击底层embedding，太多则浪费训练时间。

优化器选择AdamW基本是业界的通用做法，没有需要特殊折腾的地方。但有两个细节值得注意：权重衰减不要加在LayerNorm层和bias上，否则会影响训练稳定性；梯度裁剪设置为1.0，防止个别样本产生超大梯度导致loss尖峰。

3.2 Loss曲线怎么看，什么情况该停了

预训练阶段，每天做得最多的事情就是看loss曲线。很多人只看整体loss下降，觉得在降就行，其实几种异常模式需要特别警惕。

第一种：loss降到一定程度后长期平台，怎么调学习率都在原地波动。这种情况通常是数据问题，常见的是清洗后保留的文本过于同质化，或者有效token占比过低。我用神州数码的一次经历举个例子：某次训练loss卡在2.3附近一周没动，我把验证集loss按数据来源拆分来看，发现其中代码语料占比最高的子集loss一直在涨，说明是代码数据分布和训练数据不一致导致的。换掉了一批格式异常的代码文件后，loss才继续下降。

第二种：loss周期性尖峰。每个几千步就冒出一个高峰再回落，这通常是某个batch里有污染数据（比如清洗漏掉的乱码文本）。我的做法是定位到引起尖峰的batch，把样本拿出来人工检查，确认是异常数据就把它从训练集中剔除。不处理的话，尖峰会导致模型学习到噪声模式。

第三种：验证集loss和训练集loss差距越来越大，也就是过拟合信号。预训练阶段通常不会明显过拟合，但如果你数据量很小又训练过多个epoch，就会出现这种情况。这时候不要单纯加数据，先检查是不是训练集和验证集之间混入了重复数据。

“什么时候停”这个问题，我建议不要只看loss绝对值，还要看具体能力指标。比如我在训练中每5000步保存一个checkpoint，同时跑一次小规模评测（包括通用问答、知识问答、代码生成三个维度），观察这些任务的表现和loss下降之间的对应关系。通常loss下降的前期，任务效果提升明显；到了后期，loss还在降，但任务效果增长趋于平缓，这时候就可以评估是否值得继续烧钱。

3.3 检查点管理、恢复训练与显存优化

预训练动辄几十天，检查点管理决定你的容错能力。我每1000步保存一个检查点，保留最近5个，每5000步保存一个里程碑检查点，永久保留。这样即使中途崩溃，最多丢失1000步的训练进度，折合时间约1-2小时。保存时用异步方式，把写入磁盘和训练并行处理，避免保存过程阻塞训练。

断点恢复训练是最必须掌握的操作。很多框架如Megatron-LM、DeepSpeed都支持从指定checkpoint恢复，关键是要保证随机种子、数据加载位置、学习率调度器的状态都和保存时一致。我踩过最大的坑是忘记恢复数据加载位置，导致断点后重复读了一段已训练过的数据，相当于重启了一个小型的过拟合实验。恢复后我会空跑100步对比loss曲线是否与原训练曲线平滑衔接，有问题就立即停止排查。

显存优化方面，如果8卡A100不够用，可以逐一添加以下手段：开启activation checkpointing，用计算换显存；梯度累积，用小batch多次累积到目标batch；ZeRO-3将优化器状态在数据并行组间分片，这部分能显著降低显存。我在1024batch_size、8192序列长度下，单卡峰值显存稳定在76G左右，预留了约5%的余量，跑得很稳。

训练吞吐方面有一个恒等式：有效吞吐等于“global_batch_size乘以每秒迭代数”。如果你发现吞吐率远低于理论值，优先排查数据加载瓶颈。我的数据管道用了异步预取和预缓存，把tokenize后的数据直接缓存在内存中，训练过程完全不出现GPU等待的情况。

4. 从"会接话"到"会干活"：SFT阶段

4.1 指令数据的构建与格式

预训练完成后的模型能续写文本，但不具备“听懂指令”的能力。你要让模型从“填空式生成”变成“任务执行式生成”，这一步靠的正是SFT。SFT数据决定了模型的“性格”和基本行为模式，质量压倒数量。

我搭建SFT数据集时，定义了超过30种任务类型，从最基础的问答、摘要、翻译，到更复杂的代码生成、推理分析、结构化抽取。每个任务类型都设计了对应的指令模板，同一个任务至少写10种不同的表达方式，避免模型对措辞过拟合。

指令格式方面我用的chat式模板，三部分结构：system（角色设定，可选）、user（用户指令或问题）、assistant（期望输出）。模板必须全程统一，这直接关系到后续RLHF阶段和推理阶段的数据格式，SFT阶段格式不一致，后面所有工作都会乱套。

一条高质量的SFT数据长这样：

{ "instruction": "请分析下列文本的主旨，并用不超过三句话概括。", "input": "近日，某研究团队发布了一项关于深海热液区微生物群落的研究成果，研究显示这些极端环境中的微生物具有独特的代谢途径...", "output": "该研究聚焦深海热液区的微生物群落，揭示了极端环境下微生物的特殊代谢机制，对了解生命适应极限具有重要意义。" }

每条数据必须经过人工质量抽检。我按1%的比例抽检，抽检不合格率超过3%就返工重写。因为一个坏数据对模型的影响不是一两个样本的问题，而是会在模型内部形成错误映射，后面很难纠正。

4.2 SFT训练技巧与loss解析

SFT阶段的训练配置和预训练差异很大，我认为这是全链路里最需要“控制住手”的阶段。

学习率主要策略是要降低到预训练的十分之一到五十分之一，通常在1e-5到5e-5之间。过大的学习率会破坏预训练已经学到的知识。我观察到一个具体现象：学习率用到2e-4时，SFT训练出来模型的通用知识问答能力明显下降，而用2e-5时则几乎无影响。这就是“灾难性遗忘”在SFT阶段的典型表现。

训练轮次（epoch）不宜过大。我的SFT数据约200万条，训练3个epoch基本收敛，再多就有过拟合风险。判断依据：验证集loss在第二个epoch后持续上升，而训练集loss继续下降，说明模型开始死记硬背指令数据而不是学会泛化。如果你用的数据量较小（比如只有10万条），1-2个epoch就足够了。

SFT阶段loss的绝对数值参考价值有限，我更看重loss下降后的分布情况。具体做法是：训练结束后，用一组从未见过的指令让模型生成，对比输出的多样性、信息度和格式正确性。如果模型输出千篇一律，那么即使loss再低，这个SFT也是失败的。

一个额外技巧：在SFT数据集里混入10%-20%的纯预训练数据（原始语料，不含指令格式），能显著抑制灾难性遗忘。这个做法称为数据混合，实测下来能让模型在保持指令遵循能力的同时，尽量维持预训练阶段获取的通用知识。

4.3 合成数据与人工标注的取舍

指令数据的来源不能只靠人工写。维护一支标注团队的成本极大，我采用的是“人工标注 + 合成数据”混合方式。

合成数据是用已有的大模型（GPT系列、Claude或者开源模型）生成的指令对。但直接生成的脏数据不能用，必须经过过滤和重写。我的流程是：先让一个较强的模型生成候选指令对，再用规则加人工抽检做过滤，最后将过滤后的数据交给标注人员重写增强。合成数据大约占SFT总数据的60%，人工数据占40%。

这里其实有一个容易被忽略的“天花板问题”：学生模型的水平超不过老师模型时，合成数据越多，模型上限越受限于教师模型。所以合成数据绝不是越多越好。我在试验中发现，当合成数据占比超过70%，模型输出的风格和内容开始明显趋近于教师模型的风格，原创性和多样性反而下降。此外，你还要警惕数据污染——如果合成数据里有教师模型的错误知识，学生模型会把错误“巩固”下来。

人工标准数据的价值是给模型提供高质量“示范点”，弥补合成数据分布不均匀的问题。建议人工标注优先覆盖：复杂推理题、专业领域知识点、多伦对话、安全边界场景。这些场景合成数据往往质量不稳定，但人工可控性最强。

5. 对齐阶段：DPO与RLHF怎么选

5.1 偏好数据从哪来

SFT让模型学会了“怎么回答”，而对齐让模型学会“什么回答更好”。无论选DPO还是RLHF，第一步都是要构造偏好数据。

偏好数据的来源主要有三种：人工标注、模型自动对比、线上反馈。人工标注最贵但质量最高，适合做核心偏好集；模型自动对比可以用一个强模型（比如GPT-4）来比较不同回答的质量，速度快但会有Bias；线上反馈适合产品已上线的场景，用真实用户的点赞/踩来构造偏好对。

我采用的比例是人工标注60%、模型对比40%，总计50万条偏好对。每条数据包含一个prompt、两个候选回答（chosen和rejected）、以及选择的依据说明。chosen和rejected的结构必须保持，选择的依据要写清楚，目的不是为了让人看懂，而是为了后续数据审核时可以追溯，方便找出标注错误和矛盾标注。

偏好数据的一致性检查相当重要，相同prompt下两条数据不能出现互相矛盾的偏好标注。这是一项繁琐的体力活，但如果不做，后续DPO或RLHF训练时模型学到的是混乱的奖励信号，效果很可能不升反降。

5.2 RLHF完整链路与实现细节

如果你听信一些博主说的“RLHF就是PPO套上去就行”，那你大概率会走进一个漫长的烧钱期。任何一个做过RLHF的人都会告诉你，这条链路最大的复杂度在于四个组件：Actor模型、Reward模型、Critic模型、Reference模型。

训练流程分三步走。第一步训练Reward模型，用偏好数据训练一个给回答打分的模型，这个模型通常和Actor模型同规模或略小。第二步冻结Reference模型（就是SFT后的模型），它作为KL散度的约束基准，防止Actor在训练中跑偏太远。第三步用PPO算法循环迭代：Actor生成回答，Reward模型打分，Critic模型估计优势函数，然后根据优势函数更新策略。

PPO阶段的关键参数我给出一个稳定的组合：

kl_coef: 0.05 clip_epsilon: 0.2 entropy_beta: 0.01 # 熵正则强度 reward_model_batch_size: 128 ppo_epochs_per_batch: 4

视野（rollout）里最需要盯的指标是kl散度。如果kl散度在训练开始后快速增大，说明模型在偏离参考策略，生成内容可能开始飘，这时需要提高kl_coef值或者降低学习率。另一个需要监视的是模型的输出长度：PPO训练中模型会在奖励驱动下产生回答越来越长的趋势，因为长回答往往能得到更高分数，这种长度退化需要靠约束输出长度来抑制。

RLHF的成本是SFT的5-10倍，这是是正常的节奏。每次PPO迭代中要反复让Actor生成和评分，消耗大量算力。训练相对稳定的情况下，大约2-3天可以完成一个收敛周期。

5.3 DPO的实现与稳定性问题

DPO全称是Direct Preference Optimization，它的核心思路是不用训练一个独立的Reward模型，而是直接把偏好目标转成策略模型的训练信号。相比RLHF，DPO实现简单得多，训练稳定性也好得多，我用DPO做主线对齐，然后用RLHF做精细微调。

DPO的损失函数核心是：让chosen的回答相对于rejected的回答有更高的概率。具体实现时，需要同时计算Actor模型在chosen和rejected上的log概率，还要计算Reference模型在同样数据上的log概率。关键的系数beta（遗传正则强度）控制模型偏离参考策略的幅度。

我给的参考参数：

beta: 0.1 # 这个值越小越激进，越大越保守 learning_rate: 5e-6 # DPO阶段学习率必须很小 batch_size: 32 max_length: 2048

DPO的坑我觉得有两个。第一个是额外要拿到chosen和rejected的完整输出，不能只存文本，还要存logprob。第二个是DPO训练过程中容易发生“奖励黑客”，也就是模型找到了某种提升chosen概率的捷径，比如改变输出格式而不是内容质量。判断的方法是写一个格式占比统计器，观察chosen和rejected在长度、标点、特殊标记等维度的分布，如果训练后这些差距显著拉大，就说明模型在用格式作弊。

DPO之后的模型一般比RLHF更“锐利”，但也会更容易出现安全边界被突破的情况，原因就在于DPO没有奖励模型的软约束。所以DPO之后通常建议用一轮轻度RLHF做安全对齐，或者至少在偏好数据里加大安全边界场景的比例。

6. 评估：别只看Loss，要看真实能力

6.1 基准测试的选择与局限

训练完的模型效果如何，不能凭感觉判断。但基准测试本身就是一门博弈，你需要知道每个基准到底在测什么。

我评估3B模型时用了这样一个组合：

公开基准有个致命问题：数据污染。如果基准题出现在预训练或SFT数据里（无论是原始语料还是合成数据），模型就相当于“考前看过答案”。判断污染的办法是用一个训练前的模型跑同样基准，对比分数差异，如果从随机水平直接跳到高水平，大概率就是数据污染了。

我建议每个项目都必须搭建自己的业务测试集，至少覆盖你的核心使用场景，比如1000条真实用户问题，由人工标注标准答案。这个测试集在整个训练过程中保持冻结，每个关键节点都跑一遍，以此作为“真值”。

6.2 人工评估的流程设计

自动化基准能测出模型的基础能力，但真实交互体验还得靠人工评估。我设计了一套双项人工评估流程：能力维度评估和偏好评估。

能力维度评估把输出质量拆成四个维度打分：信息准确性（关键事实有没有错）、逻辑连贯性（前后是否自洽）、指令遵循度（有没有按格式和长度要求来）、有帮助性（整体上有没有解决问题）。每个样本两到三个人标注，取平均分。

偏好评估是更简单直接的标签：“A还是B”，就是让标注者同时看两个模型的回答，选出更优的那个。这个流程虽然粗糙，但最能反映真实用户感受，而且还能作为后续DPO偏好数据的补充来源。我建议在人工评估中定期加入“盲测对照”，不告诉标注者哪个是哪个模型，避免因先入为主的品牌印象而产生系统性偏差。

6.3 安全性与幻觉检测

对齐之后模型变得“听话”了，但安全性和幻觉问题仍然需要专项检测。

安全性检测方面，我构建了约500条对抗性样本，覆盖诱导泄露、违法信息请求、恶意代码生成、侮辱性内容生成等类别。检测结果中最理想的全通过率应为95%以上，如果低于这个标准，唯一的补救办法是回到对齐阶段，补充对应的偏好数据，重新训练一轮。

幻觉检测是我觉得整个评估环节里最值得投入的部分。用无攻击性但事实性要求高的问题，比如“某某机构成立于哪一年”“某个专业术语的定义是什么”，然后人工逐条核对模型输出的每句话是否和权威来源一致。模型的幻觉来源通常有两个：一个是训练数据本身有错误知识，另一个是生成阶段为了“凑内容”编造事实。前者难以根治，只能靠数据清洗时提升来源可信度；后者可以通过调整采样参数、降低温度值来缓解。

7. 踩坑记录与实操心得

7.1 我遇到过的七个典型问题及解决方案

第一个坑：预训练Keyword里没有设置固定随机种子，结果断点恢复时种子不一致，导致重复数据训练。解决方案是把所有可能导致随机性的部分（数据shuffle、dropout）的seed都固定下来，并在checkpoint里保存。

第二个坑：SFT数据里混入了几条因为模板拼接错误产生的“空指令对”——就是system为空但user也为空的数据。模型学到后，碰到空输入会产出大量无意义内容。解决方式是数据上线前跑一次完整的数据校验，统计每段数据的长度分布，发现异常样本立即剔除。

第三个坑：DPO训练时Reference模型没有完全冻结。因为在代码里不小心把Reference模型也设为了可训练状态，导致reference的分布跟着变化，训练了一个小时后才察觉。这提醒我在Reference模型前必须显式设置requires_grad为False。

第四个坑：PPO训练时经验回收机制（timesteps累积）设置过低，导致reward信号被旧策略污染。简单说就是数据的时效性被拉低了，模型学到的奖励信号失真。用标准的per-episode回放，并在每次更新前清空旧的rollout数据就好。

第五个坑：动用了不合适的设备跑长文本序列。模型max_position_embeddings设置到8192，但某次升级代码时误把训练序列改成了16384。显存立即溢出，训练崩溃。建议每次改配置前都检查序列长度、batch_size、显存这三个变量。

第六个坑：tokenizer的vocab在预训练和SFT之间发生了更新，导致SFT阶段无法精确映射token。这个问题相当隐蔽，表现形式是模型输出质量下降但无法定位。我的解决办法是在项目开始就把tokenizer固化为一个不可变版本，任何修改都要重跑一遍全流程。

第七个坑：合成SFT数据中出现了“标签泄漏”——生成答案直接包含了输入数据中隐藏的正确答案。比如让模型根据文章写摘要时，摘要直接复制了文章最后一句。这会让模型学会“复制”而不是“概括”。需要针对“复制率过高”做专项检测，超过阈值就重写那批数据。

7.2 一些省钱省时的建议

大模型训练的项目管理，比技术本身更考验人的耐心和判断力。用“小规模试错”模式来替代“一步到位”的大规模训练，所有改动都要先跑一轮小的验证实验，比如用10亿token验证数据配比，用1万条指令验证SFT策略。等小规模实验通过，再放大到全量数据。这个模式看似多花了时间，实际上帮你省掉的是灾难性失败的成本。

数据版本管理是大模型训练里最容易被忽略的基础设施。我把每次数据清洗后的数据、每个阶段的训练数据都打了snapshot，用类似dvc的方案管理。没有这套管理机制，你会在一次次实验迭代中迷失方向，搞不清某个效果好的模型用的究竟是哪一版数据。

最后想说一个项目运行的小技巧：每轮训练结束之后，跑一套“回归测试”再继续下一阶段。具体操作是把已经通过的历史评测集拿出来重新跑一遍，确保新阶段的改动没有让老能力退化。表面上看是保守，实际上是在为长期迭代建一个安全网，每一次模型更新都心里有数。

我自己实际做完一遍全流程之后，最大的体会是：大模型的训练没有玄学，很多看似“灵光一现”的效果提升，大多来自数据质量和评估体系的可控改善。如果你在某个环节卡住了很久，通常不是训练技巧的问题，而是数据或评估的标准没有定好。把这两件事管住了，全流程的可操作性会超出你最初的预期。