DeepSeek 大模型训练流程分 6 个阶段，每个阶段产出什么

大模型训练分 6 个阶段：数据准备、预训练、监督微调、偏好对齐、评测、量化部署。DeepSeek 公开的技术报告里写明，V3 基座采用 MoE 结构，总参数 671B，每个 token 激活 37B，预训练喂了 14.8 万亿 token。整条线走完按团队规模分 3 到 9 个月。

我们做过 1 次 7B 规模的小模型复现，从清洗数据到上线推理，4 个人花了 11 周。算力是租的，8 卡机器 2 台，最大的坑不在训练脚本，而在第 6 周发现评测集里有 300 多条样本跟训练集重复，分数虚高了 6 个点。

一、谁能做：4 个硬条件

训练不是装个框架就能跑。下面 4 条缺任意 1 条，流程会在中途停住。

1. 有可用的语料。预训练至少要 TB 级去重文本，微调阶段要 1 万条以上人工标注的指令数据。语料来源、授权、脱敏记录要能追溯。
2. 有稳定算力。7B 模型全参预训练按百卡天计，MoE 结构再往上翻。租卡要预留排队时间，集群网络带宽不足会让多机训练效率掉到 30% 以下。
3. 有工程人手。至少 1 个懂分布式训练的工程师，负责并行策略、检查点、故障恢复。卡在 loss 尖刺上排查 2 天是常态。
4. 有评测与合规通道。上线前要过内容安全评测，涉及个人信息的数据要过合规审查，这部分工作量常被低估。

二、要准备什么

开工前把下表 6 项凑齐，缺项在对应阶段会直接卡住。表格里第 4 项是最容易被跳过的一项。

第 4 项由独立于训练组的人来做，这条在复现时救过我们 1 次。写评测集的人和调模型的人是同一批，出题时会不自觉绕开模型答不好的地方，最后分数很好看，上线一问就露。

三、怎么办：6 个阶段

阶段 1 到 2：把原料做成基座

1. 数据准备。抓取、解析、去重、质量过滤、按语种与领域配比。去重常用 MinHash 做近似重复检测，阈值设在 0.8 附近。用时占整个项目的 30% 到 40%，产出是若干份 tokenized 数据分片。
2. 预训练。目标是下一个 token 预测，损失函数用交叉熵。DeepSeek-V3 的报告里写了 14.8 万亿 token 的预训练量，MoE 结构下每个 token 只走 37B 参数，算力花在路由选中的专家上。产出是一个只会续写、还不会听话的基座模型。

这两步的产出决定了能力上限。基座没见过的知识，后面几步补不回来；基座见过的，微调用几百条样本就能调出来。判断基座好坏看 3 个指标：验证集困惑度、少样本问答准确率、长文本续写的连贯长度。

阶段 3 到 4：教会它听话

3. 监督微调。用指令数据做全参或 LoRA 微调，学习率比预训练小 1 到 2 个数量级。这一步把续写模型变成对话模型，产出是能按指令答题的版本。
4. 偏好对齐。人工排序数据训练奖励模型，再用强化学习调策略。DeepSeek-R1 用的是 GRPO，一组采样内部比较优劣，省掉独立的价值网络。产出是语气、拒答边界、格式都更稳的版本。

阶段 5 到 6：验收与落地

5. 评测。跑通用能力、专业能力、安全三类评测集，逐项和上一版比。同一套题跑 3 次取均值，单次分数波动 2 个点以内算稳定。产出是 1 份对比表，标出退化的项目。
6. 量化与部署。把权重压到 int8 或 int4，用推理引擎做批处理与 KV 缓存复用。压完再跑一遍评测，准确率掉 3 个点以内可接受。

第 6 步常被当成纯工程活，实际它会回头影响训练。int4 量化后某些长尾任务的准确率掉得比平均值多，遇到这种情况要回到第 3 步补对应数据，再重新走一遍量化。

6 个阶段的时间怎么分

按 11 周的项目记录：数据准备 4 周，预训练 3 周半，微调与对齐 2 周，评测 1 周，量化部署 1 周半。占比最容易被压错的是第 2 项，很多团队把预算全押在预训练，结果微调数据只有 2000 条，模型答得通顺但不听指令，返工又花 2 周。

四、卡在哪：7 个常见卡点

1. loss 突然尖刺。现象是训练 2 万步后 loss 跳到 3 倍以上。原因是某个 batch 的学习率过高或数据异常。解法是回滚到上一个检查点，把学习率降 30%，跳过那批数据。
2. 显存溢出。现象是加大 batch 就 OOM。原因是激活值占满显存。解法是开梯度检查点、切分序列长度，或换 ZeRO 第三阶段。
3. 多机效率掉底。现象是 8 卡跑 1 天，64 卡跑 3 天。原因是机间带宽不足、通信占比过高。解法是调并行切分比例，把流水并行段数降下来。
4. 评测集泄漏。现象是评测分数比上线实测高 10 个点以上。原因是评测题与训练语料重复。解法是做 13-gram 重叠检测，重叠样本一律剔出评测集。
5. 奖励作弊。现象是强化学习后回答变长、变套话，人工看反而更差。原因是奖励模型学到了长度偏好。解法是在奖励里加长度惩罚，并用人工抽样复核 200 条。
6. 对齐过头。现象是模型对正常问题也拒答。原因是安全数据配比过高。解法是把安全样本占比压到 5% 以内，保留 1 份只做微调的对照版本。
7. 推理成本压不下来。现象是上线后单次请求耗时 4 秒以上。原因是模型规模与并发不匹配。解法是做蒸馏，用大模型生成数据训一个小模型。

7 个卡点里，前 3 个属于工程问题，按日志能查到根因；后 4 个与数据、评测口径有关，排查靠对照实验。我的习惯是每次只改 1 个变量，跑 5000 步看 loss 与验证集分数，两条曲线不一起动就说明方向改错了。

五、怎么核验：3 个可查的动作

1. 看训练日志的 loss 曲线与学习率曲线，两张图叠在一起，检查每次学习率变化后 loss 是否跟着回落。日志要留存到项目结束，中间断档就无法复盘。
2. 跑固定题单的回归测试。挑 200 道有标准答案的题，每版必跑，答对率与上一版对比。这一项能拦住 80% 的隐性退化。
3. 做人工盲测。把新旧两版的回答打乱顺序，让 5 个人各评 30 条，只看偏好不看来源。评分一致性低于 60% 说明题单设计有问题。

阶段 2 的检查点策略也要提前定。每 2000 步存 1 次，只留最近 3 个与最好 1 个，存储占用能压到 1/5；不留最好那份，loss 尖刺后回滚就没有可用的锚点。

6 个阶段里，花时间最多的是第 1 步，最容易出错的是第 4 步，最容易被砍的是第 5 步。真按流程走，砍掉评测省下的 1 周，往往在上线后花 3 周补回来。

本文信息核对时间：2026-11