Ai大模型训练全流程拆解：数据、算力、训练、对齐、评测与上线

本篇是《Ai大模型训练教程：从入门到实战落地的系统课程》系列中的“全流程拆解”篇。目标不是泛泛而谈，而是把从数据→算力→训练→对齐→评测→上线这条链路逐段拆开，给出可执行的步骤、常见坑位与建议配置。你可以把它当成一份“训练项目作战清单”：每一段都能落到任务、产物与验收标准。

适用范围：以 Transformer 语言模型为主（通用 LLM 或垂直领域 LLM），同时覆盖“从零预训练”和“基座模型上做继续预训练 + 指令微调”的主流落地路径。

一、目标与路线：先决定“训练什么”，再决定“怎么训练”

训练流程的第一步不是找数据，而是定义目标模型形态和验收口径，否则后面每个环节都在漂。

1.1 明确三类目标（决定数据与训练方式）

• A：从零预训练（Pretrain from scratch）：追求通用能力或完全自有底座。成本最高，要求大量通用语料与长时间训练。
• B：继续预训练（Continual Pretraining / Domain-adaptive Pretraining）：在开源基座上用领域数据再“喂一遍”，提升领域词表覆盖与知识密度。成本中等，性价比高。
• C：指令微调/对齐（SFT + RLHF/DPO）：让模型“会用、听话、可控”。对工程落地最关键。

实际企业落地通常是 B + C：先用领域数据继续预训练补知识，再用指令数据与偏好对齐提升可用性。

1.2 确定验收指标（贯穿评测与上线）

至少要有三类指标：

1) 能力指标：如领域问答准确率、抽取/分类 F1、SQL 生成执行正确率、代码单测通过率。
2) 安全与合规指标：有害内容触发率、敏感信息泄露率、越权指令成功率。
3) 成本与体验指标：首 token 延迟、吞吐、单次调用成本、长文本稳定性。

产物建议：写一个《模型验收说明》文档，列出每项指标的阈值、数据集来源、跑分脚本与版本号。

二、数据：从“能用”到“可训练”的工程化流水线

数据决定上限，工程决定下限。大模型数据处理的关键在于：可追溯、可复现、可迭代。

2.1 数据类型拆解（对应不同训练阶段）

• 通用预训练数据：网页、书籍、论文、代码等，强调广覆盖与规模。
• 领域继续预训练数据：内部文档、行业标准、产品手册、FAQ、工单、知识库等，强调准确与专业术语。
• 指令数据（SFT）：指令/输入/输出 三元组或多轮对话，强调任务覆盖与格式稳定。
• 偏好数据（DPO/RLHF）：同一 prompt 下的 chosen/rejected，强调“更符合人类偏好/业务偏好”。
• 评测集数据：必须“冻结”，严禁混入训练；最好覆盖线上真实分布。

2.2 数据获取与合规：先做“白名单”，再做采集

建议建立数据白名单来源：

• 内部：已授权的知识库、公开发布的文档、脱敏后的工单/对话
• 外部：开源协议明确的数据集、公开网站（注意版权与 robots/条款）

关键动作：

1) 授权记录：数据来源、授权范围、用途、保留期限。
2) 脱敏策略：手机号/邮箱/身份证/地址/订单号等规则脱敏 + 模型/NER 检测脱敏。
3) 黑名单过滤：涉政暴恐、色情、个人隐私、公司机密关键字与正则。

产物建议：形成《数据合规清单》《脱敏规则表》《过滤策略版本记录》。

2.3 清洗与去重：降低“噪声训练”与“重复记忆”

大模型训练中常见问题：

• 重复数据导致过拟合、记忆化与评测泄漏
• 乱码、模板页、导航页导致无效 token 浪费
• 低质量文本拉低生成质量

可执行步骤（推荐流水线）：

1) 格式统一：统一为 JSONL，字段至少包含：id, source, text, lang, license, timestamp。
2) 语言检测：按语种分桶；不需要的语种直接剔除。
3) 文本规则清洗：

• 过短/过长截断：例如小于 50 字符丢弃；超长按段落切分
• 去除脚本、样式、导航、重复标点

4) 去重：

• 精确去重：hash（对规范化后的文本）
• 近似去重：MinHash/SimHash 或 embedding 近邻
• 文档级与段落级都要做

5) 质量打分：用启发式 + 轻量模型打分（如困惑度阈值、脏词比例、链接密度、标点异常）。

经验建议：去重不要追求“绝对干净”，而是把高重复的模板/镜像站数据砍掉，通常 token 利用率会显著提升。

2.4 切分与打包：训练友好的 token 分布

• 长文切分：按标题/段落/句子切分，避免把“目录 + 正文 + 页脚”揉在一起。
• 上下文窗口策略：如果计划训练 8k/32k，上游就要准备长样本，否则长上下文能力只能靠推理技巧补。
• packing（样本拼接）：把多个短样本拼到一个序列以提升 GPU 利用率（注意不同样本的 attention mask 与 loss mask）。

产物建议：数据最终形成“训练包”，例如：

• pretrain_corpus_v3.jsonl（通用/领域）
• sft_instructions_v5.jsonl（指令）
• pref_pairs_v2.jsonl（偏好）
• eval_holdout_v1.jsonl（冻结评测）

三、算力与训练栈：把预算换成可控的吞吐

算力规划不是“越多越好”，而是：在目标时间内完成 token 训练，并保证稳定性。

3.1 关键概念：你需要关心的不是 GPU 数量，而是 token/s

评估训练资源时，建议用以下口径：

• 训练总 token 数：例如继续预训练 100B tokens
• 有效吞吐：每秒处理的 tokens（tokens/s）
• 目标训练时长：例如 7 天完成

粗略估算：

• 需要的 tokens/s ≈ 总 tokens / 总秒数
• 总秒数 = 天数 × 24 × 3600

这样你就能反推需要多少卡、是否要启用更激进的并行与优化。

3.2 并行策略选择：DP/TP/PP/ZeRO

• 数据并行（DP）：最常见，简单有效；卡越多吞吐越高。
• 张量并行（TP）：单卡放不下模型时用；通信开销更大。
• 流水并行（PP）：按层切分；适合超大模型，调参更复杂。
• ZeRO（1/2/3）：切分优化器状态/梯度/参数，解决显存瓶颈。

落地建议：

• 7B/14B：优先 DP + ZeRO-2/3
• 30B+：常见组合 TP + PP + ZeRO（需要成熟训练栈）

3.3 训练稳定性清单（很“土”，但救命）

1) 统一 CUDA/驱动/NCCL 版本；固定镜像与依赖。
2) 设置 checkpoint 间隔与自动恢复；故障重启不丢进度。
3) 监控 GPU 利用率、显存、通信占比、loss 曲线、梯度范数。
4) 训练前先用 1% 数据跑通端到端（数据→训练→保存→加载→推理）。

四、训练：预训练/继续预训练/SFT 的可执行配方

4.1 预训练与继续预训练：核心是“数据配比 + 学习率策略”

继续预训练常见目标：

• 学会领域术语与表达
• 提升领域知识覆盖
• 不明显损伤通用能力

实操建议（可作为起点）：

1) 数据混合：领域数据 : 通用数据 = 3:7 或 5:5（视领域强度而定）。
2) 学习率：比从零预训练更小；并设置 warmup + cosine/linear decay。
3) 训练步数：不追求“越久越好”，先用小步数验证收益，再加码。
4) 灾难性遗忘监控：在通用评测集上定期跑分，发现掉点及时调整混合比例。

4.2 指令微调（SFT）：把“会”变成“会用”

SFT 关键在于任务覆盖与格式规范。

指令样本结构示例

• 单轮：

  • instruction: “根据用户问题，从知识库中抽取答案并给出引用段落”
  • input: “问题：……\n知识：……”
  • output: “答案：……\n引用：……”
• 多轮：保存为 messages 数组（system/user/assistant），并明确系统提示词策略。

SFT 工程建议

1) 模板统一：同一任务保持固定输出结构，便于评测与后处理。
2) 难例优先：把容易出错的边界样本（否定、冲突、缺信息）占比拉高。
3) 拒答与澄清：专门构造“信息不足”样本，让模型学会追问或拒答。
4) loss mask：只对 assistant 输出计算 loss，避免把 instruction 当作要生成的目标。

4.3 训练超参：给一个“能跑起来”的默认起点

不同框架差异较大，这里给通用起点（需按模型规模与显存调整）：

• batch：用 global batch 思维（micro batch × gradient accumulation × GPU 数）
• max seq len：按业务需要（4k/8k/16k/32k）
• optimizer：AdamW
• fp16/bf16：优先 bf16（若硬件支持）
• gradient checkpointing：显存紧张时开启
• weight decay：小值即可（如 0.1/0.01 级别，视任务）
• 训练过程：每 N steps 评测、保存 checkpoint、记录可复现配置

五、对齐：让模型“更像你要的样子”而不只是更会说

SFT 解决“会按格式做事”，但不一定解决“选择更好的回答”。对齐阶段通常引入偏好信号。

5.1 DPO vs RLHF：怎么选

• DPO（Direct Preference Optimization）：工程更简单，不需要训练 reward model；对多数企业场景足够。
• RLHF（PPO 等）：更强但更复杂，训练不稳、成本高；适合对安全/风格极端敏感的产品。

建议默认从 DPO 起步：先把偏好数据体系搭起来，再考虑 RLHF。

5.2 偏好数据怎么做：从线上真实对话中来

构建偏好对的三种常见来源：

1) 人工标注：同 prompt 下给 A/B 两个回答，让标注员选更好，并记录原因标签（事实性/完整性/语气/合规）。
2) 模型自生成 + 人工筛：让模型生成多个候选，人工选最好与最差，效率高。
3) 线上日志挖掘：用户点赞/采纳/继续追问等行为信号转成弱标注偏好。

落地建议：偏好数据字段最少包含：

• prompt
• chosen
• rejected
• preference_reason（可选但强烈建议）
• domain（可用于分桶训练与分析）

六、评测：建立“可对比”的基准，而不是跑几个榜单分数

6.1 评测体系分层：离线 + 半自动 + 在线

1) 离线自动评测（必须可复现）：

• 选择题/判别题：准确率
• 信息抽取：F1
• 代码：单测通过率
• 检索增强：引用命中率

2) 半自动评测：用 LLM-as-a-judge，但要有对照与抽检人工复核。

3) 在线 A/B：上线后用真实流量验证（满意度、转人工率、会话轮数、投诉率）。

6.2 防止评测“自嗨”的三条铁律

• 评测集冻结：版本化管理，训练集严禁混入。
• 覆盖真实分布：从线上真实问题抽样，包含长尾与脏输入。
• 指标可解释：掉点要能定位到任务类型、领域、样式，而不是一个总分。

6.3 常用评测集组织方式（建议）

把评测集按业务切成多个 bucket：

• 事实问答（含不可回答样本）
• 结构化输出（JSON/表格）
• 工具调用/函数调用
• 安全合规
• 长上下文理解

每个 bucket 给出：样本数、来源、指标、阈值、错误示例。

七、上线：从“能推理”到“能服务”的最后一公里

上线并不等于把权重扔进推理引擎。你需要的是完整的“模型服务化能力”。

7.1 推理优化：降成本与提体验的常见手段

1) 量化：INT8/INT4（需验证对领域指标的影响）。
2) KV Cache 与分页注意力：提升长文本吞吐。
3) 批处理与动态 batching：提高 QPS。
4) 多机推理并行：TP/PP 结合推理引擎能力。

建议上线前做一张表：不同量化/并行配置下的延迟、吞吐、成本、指标掉点。

7.2 结合 RAG/工具：用系统能力兜住“知识更新”

很多业务并不需要把全部知识“训练进模型”。更稳妥的架构是：

• 模型负责理解与生成
• 检索（RAG）负责提供最新事实
• 工具调用负责执行（查询、下单、检索、计算）

落地步骤：

1) 设计引用规范（回答必须带来源段落/链接/文档 ID）。
2) 对“必须查证”的问题强制走 RAG。
3) 评测时加入“引用正确性”指标。

7.3 安全与监控：上线后才是训练的开始

上线需要的监控与治理：

• 内容安全：敏感/有害检测，越权指令拦截
• 数据安全：提示词注入检测、输出脱敏
• 质量监控：低置信回答比例、拒答率、幻觉投诉
• 回流闭环：把线上失败案例进入“难例池”，定期做再训练（SFT/DPO）

建议每次版本迭代都输出：

• 训练数据变更（新增/删除比例）
• 关键超参与代码版本
• 离线评测对比
• 灰度结果与回滚预案

八、把全流程串成一个可落地的项目计划（示例）

下面给一个“4~8 周能交付”的典型节奏（以开源基座 + 领域增强为例）：

第 1-2 周：数据与评测基线

• 搭建数据流水线（清洗/去重/脱敏/版本化）
• 冻结评测集 v1（覆盖真实线上问题）
• 跑通推理服务与监控基线

第 3-4 周：继续预训练（领域增强）

• 领域数据 + 通用数据混合训练
• 每日离线评测，监控遗忘
• 产出领域增强基座 v1

第 5-6 周：SFT（可用性）

• 构造任务型指令数据（含拒答/澄清/结构化输出）
• 训练 SFT v1，修正格式与稳定性

第 7-8 周：DPO 对齐 + 灰度上线

• 构建偏好对数据（人工 + 线上弱标注）
• DPO 对齐，提升回答偏好一致性
• 灰度 A/B、监控与回流，形成难例池

结语：一张“验收清单”帮你避免返工

如果你只想记住本篇的核心：

• 数据要版本化、可追溯、可脱敏；去重与质量控制能直接省算力。
• 算力用 tokens/s 和训练时长倒推；先跑通再扩规模。
• 训练先继续预训练补领域知识，再 SFT 做可用性。
• 对齐优先 DPO，把偏好数据体系搭起来。
• 评测要冻结、贴近线上分布、可解释。
• 上线需要推理优化 + 安全监控 + 回流闭环。

下一篇如果继续沿系列推进，建议聚焦某一段做深做透（例如：领域数据流水线、SFT 数据设计、DPO 偏好数据生产、或评测体系搭建），这样你的《Ai大模型训练教程》才能真正从“教程”走向“可复用的工程方案”。