后训练释放万亿参数大模型潜力的完整教程

一、教程目标

本教程要帮你完成三件事：

1. 能力定位：搞清楚一个已经预训练完成的超大规模基座模型，能力短板到底在哪一层（知识、推理、代码、长上下文、视觉、工具调用），从而决定后训练该投什么数据、投多少。
2. 后训练落地：按”数据工程 → 监督微调 → 偏好对齐 → 可验证奖励强化学习 → 长上下文/多模态扩展 → Agent 与工具调用训练”的顺序，把基座模型改造成可交付的生产级模型。
3. 交付与验收：建立离线评测 + 人工评审 + 线上监控的三层验收体系，并在能力不变的前提下，交付一个输出吞吐更高的轻量版本。

一句话概括教程主线：预训练决定模型的上限，后训练决定这个上限能被释放出多少。

二、适用读者与场景

• 算法工程师：需要一套完整的后训练流水线设计与调参依据，而不是零散脚本。
• 平台/运维工程师：负责训练集群调度、显存与吞吐调优、模型服务化上线。
• 技术负责人：需要评估”继续堆预训练”与”加强后训练”的投入产出比，以及排期与风险。
• 企业应用开发者：要把大模型能力接进自己的代码助手、文档分析、三维建模、业务流程 Agent 等系统。

典型适用场景包括：通用对话模型的能力升级、代码与 Agent 能力专项强化、金融/法律等专业文档问答、百万级长文档处理、多模态文档理解，以及为线上服务构建低延迟高吞吐版本。

三、先厘清几个关键概念

后训练（Post-training） 指基座预训练收敛之后的所有训练阶段，目标是让模型从”会续写文本”变成”会按要求完成任务”。常见阶段：

阶段	目标	数据形态
监督微调（SFT）	教会模型指令跟随、格式规范、领域表达	指令-回答对
偏好对齐	让输出更符合人类偏好（有用、无害、诚实）	同一问题的多候选 + 偏好标注
可验证奖励强化学习（RLVR）	用可自动判定的正确性信号提升推理与代码能力	任务 + 校验器（单测、编译器、数值答案）
长上下文扩展	在有限算力下把有效上下文推到百万 Token 级	长文档、长仓库、多轮长对话
多模态对齐	让视觉输入进入统一表征，具备原生理解能力	图文交错、文档截图与结构化标注
蒸馏与推理优化	在能力基本不降的前提下换吞吐与延迟	强模型轨迹、业务流量分布

为什么后训练值得重投：预训练的算力成本随参数规模超线性增长，而在一个已经具备广泛世界知识的基座上，通过高质量任务数据与强化学习”唤醒”特定能力，单位成本要低得多。前述三万亿参数级模型在终端编程类基准上做到 60% 以上通过率、与头部模型差距收窄到 1 个百分点以内，在金融文档分析类评测上取得同项最优，靠的正是这一路径。

四、前置准备

4.1 资源与环境

• 算力：万亿参数级全参数微调对显存与互联带宽要求极高，通常需要多机多卡高速互联；若算力受限，优先采用参数高效微调（低秩适配类方法）冻结主干、只训练少量新增参数。
• 存储：训练语料、检查点、评测日志量级很大，建议使用云上对象存储保存数据集与检查点，文件存储承载高频读写的训练数据，日志服务统一收集训练与服务日志。
• 编排：用容器平台做分布式训练任务编排与弹性伸缩；用监控告警跟踪 GPU 利用率、显存、吞吐、loss 曲线与线上延迟。
• 账号与权限：准备训练集群访问权限、数据集读写权限、模型仓库读写权限、服务发布权限，遵循最小权限原则。

4.2 数据与评测

• 业务语料：至少覆盖目标场景的输入分布（终端命令、报错栈、金融报表、三维建模脚本等）。
• 可验证校验器：单元测试、编译/静态检查、数值答案比对、几何体素或拓扑校验脚本。这是强化学习阶段的地基。
• 评测集：从真实业务中采样，与训练集严格去重，并保留一份永不参与训练的”密封集”用于最终验收。

4.3 前置知识

熟悉 Transformer 基本结构、分布式并行（数据并行/张量并行/流水并行/序列并行）、指令微调数据格式，以及强化学习中策略梯度、优势函数、KL 约束等基本概念。

五、实施步骤

步骤 1：基座能力体检，定位后训练靶点

不要一上手就微调。先用分层评测把基座的”能力地图”画出来：

1. 知识层：多学科选择题、事实问答，判断是否存在明显知识空洞。
2. 指令层：格式遵循、长度约束、多轮一致性。
3. 推理层：数学、逻辑、代码生成的 pass@1 与 pass@k。
4. Agent 层：多步任务完成率、工具调用正确率、平均步数、失败恢复率。
5. 长上下文层：不同上下文长度（8K/32K/128K/1M）下的检索式问答与全局长文摘要，观察”中段丢失”现象。
6. 多模态层：文档版式理解、图表读数、界面截图操作。

作用：后训练的资源必须投到”基座已有潜力但未被激发”的方向。知识空洞往往要靠数据补齐，而推理与 Agent 能力的差距，通常靠强化学习更能见效。

步骤 2：训练数据工程（决定成败的一步）

按”采集 → 清洗 → 去重 → 难度分层 → 配比 → 校验”六步走：

• 采集：优先使用真实业务日志与人工标注；合成数据要保留来源可追溯。
• 清洗：去掉答案错误、格式混乱、含敏感信息、含评测集泄漏的样本。
• 去重：精确去重 + 近似去重（如 MinHash 类方法），防止重复样本导致过拟合与记忆化。
• 难度分层：按校验器通过率把任务分为简单/中等/困难，为后续课程式训练做准备。
• 配比：通用指令数据、代码数据、领域专业数据、多轮对话数据按经验比例混合，一般领域数据不超过总量的一半，以避免通用能力退化。
• 校验：每条样本都要能自动判定”回答是否正确/格式是否合法”，否则不进入训练集。

注意：数据质量提升带来的收益通常大于同等工作量的调参收益。宁可少而干净。

步骤 3：监督微调（SFT）

• 做什么：用清洗后的指令-回答对训练模型，重点是格式规范、工具调用协议、专业表达。
• 为什么：SFT 是后续对齐与强化学习的初始化点，初始化不好会让后续训练发散。
• 注意：
  • 全参数微调与参数高效微调的选择取决于算力预算；
  • 学习率通常比预训练低 1—2 个数量级，过大极易造成灾难性遗忘；
  • 对 loss 只在回答部分计算（mask 掉 prompt），这是常见错误点；
  • 保留 5%—10% 的通用数据做”回放”，抑制能力回退。

步骤 4：偏好对齐

• 做什么：对同一问题采样多个回答，人工或规则标注偏好，训练奖励模型或直接做偏好优化。
• 为什么：把”正确”进一步推向”用户真正满意”，显著改善有用性与安全性。
• 注意：偏好标注一致性（标注者间一致率）低时，训练收益会被噪声吃掉；上线前先做一次标注质量抽检。

步骤 5：可验证奖励强化学习

这是提升代码、数学、Agent 能力最有效的一步。

• 奖励设计：以可自动验证的信号为主，例如单元测试通过率、编译成功、答案数值匹配；辅以格式奖励与长度惩罚，抑制无意义长篇输出。
• 流程：对同一任务采样多条轨迹 → 用校验器打分 → 计算组内相对优势 → 带 KL 约束更新策略（PPO 类或 GRPO 类去价值网络的组内相对优势方法均可）。
• 注意：
  • 奖励黑客是最大风险：模型可能学会写死测试、跳过断言。对策是保留隐藏测试、随机化输入、增加人工抽检。
  • 组内采样数（group size）太小会让优势估计方差过大，训练不稳。
  • KL 系数过小会跑偏基座分布，过大会学不动。

步骤 6：长上下文与多模态能力扩展

• 长上下文：不要只靠”堆长度”训练。建议做位置编码外推/插值适配、长样本分桶（避免长短样本混合导致 padding 浪费），并专门构造”跨段落检索””全局一致性总结”类任务，缓解中段信息丢失。
• 原生视觉理解：将视觉编码器与语言主干做对齐训练，数据以图文交错、文档截图配结构化标注为主；重点覆盖表格、图表、界面元素与版面顺序。
• 注意：长上下文与多模态都会显著抬高显存占用与推理成本，需在训练阶段就评估线上可承受的单请求成本。

agent-">步骤 7：工具调用与 Agent 轨迹训练

面向”复杂 3D 建模、游戏场景开发、长时间多步骤软件工程”这类任务：

1. 定义工具协议：统一函数签名、参数 schema、错误返回格式，让模型学会”失败可读、可重试”。
2. 采集轨迹：把真实多步执行过程录成”观察-思考-动作”三元组序列，成功与失败轨迹都要保留。
3. 负样本利用：对失败轨迹做过程奖励标注（哪一步走错），比只学成功轨迹更省数据。
4. 训练目标：既学”选对工具”，也学”何时停下来问用户”，避免无限循环调用。

步骤 8：评测与验收

评测必须覆盖四个维度，且离线评测与线上抽样并行：

• 任务维度：终端编程类任务、真实代码仓库级修改、金融等专业文档分析、三维建模脚本生成。
• 效率维度：任务完成率、平均步数、单任务 Token 消耗、端到端耗时。
• 安全维度：越狱抵抗、敏感信息泄露、危险操作拦截。
• 一致性维度：多次采样结果方差，判断能力是否稳定而非偶然。

验收门槛建议写成明确数字（例如”终端编程类基准 pass@1 不低于基座 +X 个百分点，且通用评测回退不超过 1 个百分点”），避免”感觉变好了”式验收。

步骤 9：交付高吞吐版本

同能力高吞吐版本（输出速度提升约 2—3 倍）的常见做法：

• 知识蒸馏：以强版本为教师，让学生模型在业务流量分布上学习，优先保住高频任务的能力。
• 推理系统优化：分页式 KV 缓存、连续批处理、前缀缓存复用、投机解码、结构化输出约束。
• 量化与并行策略：在质量损失可接受范围内做权重量化，配合张量并行降低单卡压力。
• 必做动作：高吞吐版本必须与标准版本跑同一套评测集，逐项对比，任何单项明显回退都要阻断发布。

步骤 10：接入与灰度上线

• 通过统一的模型服务 API 网关对外提供能力，网页端、移动端、IDE 插件、企业内部系统共用同一入口。
• 灰度顺序：内部账号 → 小流量白名单 → 按百分比放量 → 全量。每阶段观察错误率、P99 延迟、人工反馈。
• 完整权重如需对外发布，走版本化模型仓库与校验和核对流程，避免”线上跑的”与”发布出去的”不一致。

六、关键配置说明

配置项	含义	常见取值逻辑	风险
序列长度	单样本最大 Token 数	覆盖 P95 业务样本长度，长上下文任务单独分组	过大导致显存溢出与算力浪费
并行策略	数据/张量/流水/序列并行的组合	按模型规模与互联带宽权衡，通信密集层用张量并行	配置不当使 GPU 利用率长期偏低
学习率	参数更新步长	后训练显著低于预训练，配合 warmup 与余弦衰减	过大引发灾难性遗忘
批次构成	全局 batch 与梯度累积	长样本多时用梯度累积凑够有效 batch	长短混批导致 padding 浪费
KL 系数	策略与参考模型的偏离约束	从较小值起调，观察 reward 与 KL 的同步曲线	过小跑偏，过大不收敛
采样温度 / top-p	生成多样性	训练采样适当提温探索，线上按需降温求稳	提温过高增加格式错误率
并发与限流	服务端最大并发与排队策略	由压测得出安全水位，留出突发余量	限流缺失导致雪崩

通用原则：一次只改一个变量，每次实验都记录数据版本、配置快照与随机种子，否则结果不可复现、无法归因。

七、示例（通用伪代码）

1) 训练数据统一格式（JSONL）

{"id":"task-001","messages":[{"role":"user","content":"修复该仓库单测失败的原因并给出补丁"},{"role":"assistant","content":"..."}],"meta":{"domain":"code","difficulty":"hard","verifier":"unit_test"}}

2) 可验证奖励函数

def reward(sample, model_output):
    score = 0.0
    if compiles(model_output.patch):
        score += 0.3
    passed, total = run_hidden_tests(model_output.patch)
    score += 0.6 * (passed / total)
    if format_ok(model_output):
        score += 0.1
    if too_long(model_output):
        score -= 0.05
    return max(0.0, min(1.0, score))

3) 强化学习单步流程

for batch in dataloader:
    group = [policy.sample(batch.task) for _ in range(G)]      # 同任务采样多条轨迹
    rewards = [reward(batch.task, y) for y in group]           # 校验器打分
    adv = group_relative_advantage(rewards)                    # 组内相对优势
    loss = policy_loss(logprobs, adv) + beta * kl_to_reference(policy)
    loss.backward(); optimizer.step()
    if eval_every_n_steps: run_regression_suite();             # 防止通用能力回退

4) 服务端配置示意

serving:
  max_context_tokens: 1048576
  max_concurrency: 128
  kv_cache: paged
  prefix_cache: enabled
  request_timeout_seconds: 120
  stream_output: true
  guardrails: {sensitive_data_filter: true, tool_call_whitelist: true}

八、结果验证：怎么判断真的成了

1. 离线指标：目标能力评测集相对基座的提升幅度达到预设门槛；通用能力评测回退在阈值内。
2. 回归测试：把历史失败案例固化为回归集，确认老 bug 不复发。
3. 人工评审：抽样 100—300 条真实请求做盲评，比较标准版本与候选版本的胜率。
4. 效率验收：同能力高吞吐版本在相同硬件与并发下的输出速度、P99 延迟是否达标。
5. 压测与稳定性：长时间高并发运行观察显存是否泄漏、是否出现请求堆积。
6. 线上监控：上线后持续跟踪成功率、工具调用成功率、平均步数、人工接管率与用户反馈，指标异动要能定位到具体版本与配置。

九、常见问题与排查

• loss 下降但业务效果不变：多为数据分布与业务分布不匹配，或 loss 只在错误位置计算。核对 mask 与数据采样分布。
• 通用能力明显退化（灾难性遗忘）：学习率过大、领域数据占比过高。降低学习率、加入通用数据回放、缩小可训练参数范围。
• 长上下文”中间丢失”：训练时缺少中段信息依赖型任务。补充跨段落检索与全局一致性任务，并检查位置编码外推方式。
• 奖励黑客（写死测试、空补丁骗分）：增加隐藏测试集、输入随机化、过程奖励与人工抽检。
• Agent 死循环调用工具：缺少步数上限与终止条件。设置最大步数、重复动作检测与”请求澄清”分支。
• 工具调用参数幻觉：schema 描述不清、示例不足。强化参数校验与错误重试轨迹训练，服务端强制 schema 校验。
• 显存 OOM：序列长度、批次、并行度三者失衡。优先降长样本批次，再调并行策略，最后考虑量化或重计算。
• 输出变慢：检查前缀缓存是否命中、批处理是否被长请求拖住、是否被限流排队。

十、优化建议

• 性能：把评测集与高频前缀做缓存复用；对长文档场景做检索式上下文裁剪，只把必要片段送进上下文，降低单请求成本。
• 安全：输入侧做提示注入检测，输出侧做敏感信息过滤，工具侧做白名单与权限最小化；危险操作（删除、发布、外发）必须显式确认。
• 稳定性：训练任务设置检查点与自动重调度；线上服务设置超时、重试、熔断与降级到小模型的兜底路径。
• 可维护性：数据、配置、评测集、模型版本四者全部版本化，任一线上效果都能追溯到具体数据与配置组合。
• 成本控制：用小模型做前置路由，只对复杂请求走大参数模型；把高吞吐版本用于交互式场景，标准版本用于高价值离线任务；训练侧优先参数高效微调，避免每次都全参数重训。

十一、总结

后训练是把大基座”能力上限”转化为”实际生产力”的关键工程。完整链路可以概括为：体检定位靶点 → 高质量数据工程 → 监督微调 → 偏好对齐 → 可验证奖励强化学习 → 长上下文与多模态扩展 → Agent 与工具调用训练 → 多维评测验收 → 高吞吐版本交付 → 灰度上线与持续监控。

三个最容易被忽视但收益最高的动作：一是把”可自动验证的校验器”当成核心资产来建设；二是评测集与训练集严格隔离，并维护密封集；三是每次实验只改一个变量、全程可复现。

后续可继续深入的方向包括：过程级奖励与推理轨迹优化、跨模态统一表征训练、Agent 长任务的记忆与规划机制、以及在百度智能云等云平台上通过对象存储、容器平台、监控告警等通用能力把这套流程工程化、自动化，让后训练从”手工实验”变成”可持续迭代的流水线”。