大模型多轮训练实战：从SFT到强化学习的迭代优化方法

最近这个本地大模型算法项目走到了一个比较关键的节点：整体进度大约 90%。项目内部最核心的手段不是继续堆参数、刷榜单，而是用多轮训练把模型能力一层一层拉起来。如果你正在做 SFT、偏好对齐、强化学习微调，或者准备把一套只能跑 demo 的模型推到接近可用状态，这篇文章建议直接收藏。

先说结论：多轮训练不是简单地把同一批数据反复训练几遍，而是每一轮都要带着上一轮暴露出来的错误样本、失败案例和评测缺口重新构造数据、调整训练目标、再评估、再补数据。这个循环走到后期，提升的往往不是单点指标，而是模型的指令遵循、拒答边界、格式稳定性和长上下文一致性。项目后面 10% 的工作，主要是把这些能力固化、写清评测规则、做数据隔离和上线前的回归验证。

这篇文章会围绕多轮训练拆开讲：为什么它能提升模型能力、项目到 90% 时应该已经完成哪些事、关键算法怎么选、训练流水线怎么设计、用什么方式验证模型是真的变强了、最容易踩的坑有哪些。重点放在可落地的流程和排查方法，不是讲理论推导。

1. 多轮训练核心能力速览

在展开细节之前，先用一张表把多轮训练的关键信息列出来。这个项目的训练对象是对话式大模型，任务类型是能力增强与对齐微调，所以下面这张表也主要面向这个方向。

需要说明的是，多轮训练的显存占用和训练时长没有统一答案，取决于模型参数量、训练方式、批次大小和硬件条件。更稳妥的判断方式是先在小模型上跑通全流程，再迁移到大模型上。

2. 多轮训练为什么能提升模型能力

单轮 SFT 能很快让模型学会对话格式，但面对复杂指令、拒绝回答、严格格式输出、长上下文多步推理这些场景时，往往表现不稳定。原因不一定是模型容量不够，而是训练数据里的“困难样本”不够，或者模型在某一类错误上形成了错误惯性。

多轮训练的核心价值，是给训练过程加了一个“反馈闭环”。

第一轮训练完成后，用固定评测集去测模型，找出错误集中出现的类型。比如模型总是把用户输入的 Markdown 格式原样返回、面对不合适请求时没有拒答、或者多轮对话里忘记之前问过什么。针对这些错误，构造新的数据样本，或从已有数据中筛选出难例，混合进下一轮训练。这样模型在后续迭代中不是重新学习全部知识，而是专门去修正薄弱点。

项目走到 90% 时，多轮训练的优势会体现得很明显：基础功能全都能跑通，但最后的指标提升全靠“错题本”反复打磨。这个阶段如果还靠加大训练数据量，收益很低；要找的是高质量错误样本和边界情况。

值得注意的一点是，多轮训练不能无限制循环。每一轮之后模型可能出现“旧能力回退”的现象，也就是常说的灾难性遗忘。所以在项目的后期，每轮训练结束后都要跑一次全量回归测试，不只看新能力有没有提升，还要看旧能力有没有下降。

3. 大模型算法项目进度 90% 时的收尾检查清单

项目进度到 90%，意味着主流程已经全部跑通，剩余工作集中在稳定性、回归验证和发布准备上。这里给出一份适合多轮训练项目的收尾检查清单。

这个清单的核心思路是：多轮训练越到后期，越要依赖“可复现”和“可对比”。否则当你发现模型某一轮效果变差时，很难判断到底是数据问题、超参数问题还是评测集改动导致的。

项目进度 90% 时，还有一个容易被忽略的点：训练日志和评估记录要按轮次归档。不只是记录 loss 曲线，还要记录每一轮训练用到的数据量、数据来源、评测集版本、模型 checkpoints 编号。这样后续无论是继续训练还是回滚，都有据可查。

4. 多轮训练的关键算法选择与对比

多轮训练涉及的算法不是单一的，常见的组合是“SFT 打底 + 偏好对齐 + 强化学习调优”。下面按训练阶段拆开说。

4.1 SFT 指令微调

SFT 是所有微调工作的基础阶段。它的目标是把预训练模型改造成能听指令、能按格式回答的对话助手。这个阶段的数据通常是system / user / assistant三段式结构，模型学会的是对话交互方式和基础任务执行能力。

SFT 训练相对稳定，但要注意数据质量远大于数据数量。一份格式混乱、答案错误率高、多轮上下文不一致的数据集，即使量很大，也会让后续偏好对齐和强化学习的效果大打折扣。

4.2 Reward Model 与偏好对齐

偏好对齐阶段需要给模型学习“什么样的回答更好”。常用的数据是同一问题下的人类偏好排序。Reward Model 训练完成后，可以给模型生成的回答打一个分数，为后续强化学习提供奖励信号。

训练 Reward Model 时要特别注意过拟合。如果偏好数据集中存在大量相似样本，Reward Model 容易找到“捷径”，比如单纯因为回答更长就给更高分，而不是真正理解内容质量。

4.3 PPO / DPO / GRPO 的选择

强化学习阶段有几种主流方案。

• PPO 是最经典的方法，训练稳定，但实现复杂度高，需要同时维护 Actor、Critic、Reward Model 和 Reference Model，显存占用较大。
• DPO 直接使用偏好数据完成对齐，不需要单独训练 Reward Model，训练流程更简单。缺点是它对偏好数据质量要求非常高，而且可控性不如 PPO。
• GRPO 这类变体主要优化了采样和基线估计方式，在部分场景下能减少显存压力，值得在小规模实验里对比。

从项目可控性来看，如果训练资源有限或更看重实现速度，可以先从 DPO 开始跑通全流程；如果最后发现模型在拒答和风格控制上不稳定，再引入 PPO 类方法做精细调优。

5. 多轮训练环境准备与分布式训练配置

多轮训练不是单个脚本跑一次，而是整个训练、评测、数据分析循环反复执行。所以环境准备阶段要尽量把依赖和流程固定下来。

5.1 基础环境

建议使用 Python 3.10 以上的环境，配合 PyTorch 和 Transformer 生态。如果是 GPU 训练，还需要确认 CUDA 驱动版本和 PyTorch 版本匹配。

# 创建虚拟环境 conda create -n llm_train python=3.10 conda activate llm_train # 安装核心依赖 pip install torch deepspeed accelerate transformers datasets peft

具体版本号需要以当前官方发布为准。安装完成后，先检查 PyTorch 是否能正确识别 GPU：

python -c "import torch; print(torch.cuda.is_available(), torch.cuda.device_count())"

输出True和可用的显卡数量，说明环境基础正常。

5.2 训练数据格式

多轮训练的数据格式建议从最开始就统一，避免后期切换。最常用的是messages列表结构：

{ "id": "round1_0001", "messages": [ {"role": "system", "content": "你是一个有用的助手。"}, {"role": "user", "content": "帮我总结这段会议记录的关键信息。"}, {"role": "assistant", "content": "会议记录的关键信息如下：第一，项目进度为90%；第二，剩余工作集中在回归测试和发布准备。"} ], "metadata": { "source": "manual_label", "round": 1 } }

如果是偏好数据，建议设计成如下结构：

{ "prompt": "用户问题：如何排查训练 loss 不下降？", "chosen": "先检查数据质量、学习率和模型初始化状态……", "rejected": "把学习率调大一点再试试。" }

统一格式以后，每一轮迭代都可以直接复用数据加载和预处理脚本，不需要反复改代码。

5.3 分布式训练配置

模型规模超过单卡显存容量时，需要引入分布式训练。DeepSpeed 是常用的方案之一。这里给出一份基于accelerate启动训练的参考命令，实际参数需要根据模型规模和硬件调整。

accelerate config

配置完成后，训练命令类似：

accelerate launch \ --num_processes 4 \ --mixed_precision bf16 \ train_sft.py \ --model_name_or_path /model/base \ --train_data_dir /data/round1 \ --output_dir /checkpoints/round1 \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 8 \ --num_train_epochs 2 \ --learning_rate 2e-5 \ --logging_steps 10

训练参数的设定策略是：先在小规模数据上做一次短运行，确认显存和训练速度，再根据日志调整per_device_train_batch_size和gradient_accumulation_steps。

6. 多轮训练流水线设计与迭代流程

多轮训练的核心是流水线设计。每一轮都包含数据构建、训练、评估、错误收集和下一轮数据策略调整。下面给一个标准化流程。

6.1 流水线整体结构

多轮训练的层级结构可以概括为以下几个环节：

• 准备工作：构建初始 SFT 数据集，确定评测集。
• 第 1 轮：SFT 训练，完成基础指令跟随能力。
• 第 2 轮：偏好对齐，引入 chosen / rejected 数据，提升回答质量。
• 第 3 轮：针对评测错误样本补充数据，继续微调。
• 第 4 轮：回归验证，对比所有历史评测结果。

每一轮之后都需要产生一份“错误样本清单”。这份清单是下一轮训练数据最重要的来源。

6.2 训练循环伪代码

下面的伪代码展示了一个典型的多轮训练循环控制逻辑：

import glob def evaluate_model(model, eval_dataset): """返回评测分数和错误样本列表""" score = run_eval(model, eval_dataset) bad_cases = collect_fail_cases(model, eval_dataset) return score, bad_cases def build_data_by_round(round_idx, history_bad_cases, base_data): """把历史错误样本混入下一轮训练数据""" if round_idx == 1: return base_data return base_data + history_bad_cases[round_idx - 1] for round_idx in range(1, total_rounds + 1): train_data = build_data_by_round(round_idx, bad_cases_history, base_train_data) model = train_sft(model, train_data, round_idx) model, reward_model = train_reward_and_align(model, preference_train_data, round_idx) current_score, new_bad_cases = evaluate_model(model, eval_dataset) bad_cases_history[round_idx] = deduplicate(new_bad_cases) print(f"round {round_idx} eval score: {current_score}")

在实际项目中，伪代码会替换成具体的训练脚本和评测脚本。注意要在每轮训练结束后把模型 checkpoints 保存到独立目录，避免覆盖上一轮结果。

6.3 数据补全策略

多轮训练过程中，错误样本通常不会很多，尤其是项目到后期，模型能犯的“低级错误”越来越少。这时数据补全策略要升级：

• 从高风险场景中人工构造对抗样本。
• 从真实用户日志中筛选失败对话，但必须做隐私脱敏。
• 把模型的成功样本和失败样本做对照，提取边界特征。
• 对已有数据做改写，增加相似但不同的表述。

重点不是加大数据量，而是让模型遇到之前没见过但很可能出现的边界情况。

7. 模型能力验证与多轮评测指标

多轮训练提升不能靠感觉，要用固定评测集和可靠的指标来判断。

7.1 常用评测指标

7.2 离线评测示例

评测脚本可以直接读取评测集，循环调用模型推理接口，并记录结构化输出：

import json import requests eval_cases = json.load(open("eval_round3.json")) results = [] for case in eval_cases: response = requests.post( "http://127.0.0.1:8000/v1/chat/completions", json={ "messages": case["messages"], "temperature": 0.2 }, timeout=60 ) answer = response.json()["choices"][0]["message"]["content"] results.append({ "case_id": case["id"], "label": case["expected"], "answer": answer, "pass": judge(case["expected"], answer) }) pass_rate = sum([r["pass"] for r in results]) / len(results) print(f"eval pass rate: {pass_rate:.2%}")

评测过程中需要注意：温度要固定，建议使用接近实际生产环境的参数；评测集不能混进训练数据；每次评测使用完全相同的评测集和判定规则，否则指标对比没有意义。

7.3 部署接口验证

多轮训练完成后，最终产物通常以 API 服务形式提供。可以使用 vLLM 或类似推理框架启动服务，再用 curl 验证。

curl -X POST http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "messages": [ {"role": "user", "content": "在一个无法访问外部网络的环境中部署模型，需要注意什么？"} ], "temperature": 0.2 }'

验证重点是响应速度、输出格式和异常输入时的表现，不只是看回答内容是否合理。

8. 多轮训练中的资源占用与性能观察

多轮训练的资源消耗比单轮训练更值得关注，因为每一轮都要跑训练、推理和评测，整体时间成本会成倍增加。

8.1 训练过程显存监控

训练过程中要实时观察 GPU 占用情况。可以单独开一个终端持续监控：

watch -n 1 nvidia-smi

如果训练中途出现显存溢出，优先调低per_device_train_batch_size、减少序列长度，或者开启梯度累积。

8.2 性能优化思路

多轮训练中，不同阶段的瓶颈不同：

• SFT 阶段瓶颈主要在数据读取和计算资源。
• 偏好对齐阶段瓶颈在 Reward Model 的过拟合控制。
• 强化学习阶段瓶颈在采样效率和显存占用。

降低显存占用的常用方法包括：使用混合精度训练、开启梯度检查点、使用 DeepSpeed Stage 2/3、减少同时采样的 batch size。

但要注意，优化措施不能只为了显存降低而牺牲训练稳定性。每一步改动之后，都要重新跑一个短评测，确认效果没有下降。

8.3 多轮训练的评估记录

项目后期最重要的是趋势观察。建议把每一轮的评测结果汇总成一张表格，直观看到哪些指标在提升、哪些指标回退。

注意这里的数字只是示例，实际项目的指标受数据分布和模型规模影响很大，不能用固定标准去套。

9. 大模型多轮训练常见问题与排查方法

多轮训练容易踩的坑和单轮训练不太一样，很多问题要在多轮迭代后才会暴露出来。

多轮训练中最容易被忽视的问题是“评测集污染”。如果评测集里的题目在历史训练数据中出现过，从第二轮开始，指标就会虚高，无法反映真实能力提升。项目到后期，评测集的设计必须独立且固定，不能因为指标不好看就偷偷改题。

10. 多轮训练最佳实践与安全合规建议

多轮训练项目走到 90%，最后 10% 的工作决定了模型能不能真正上线使用。这里给出几条工程和合规建议：

• 第一次跑通全流程时，用小模型和中型数据集。先用最小配置验证数据格式、训练脚本和评测脚本，不要一上来就上大规模训练。
• 训练过程中保留所有 checkpoints 和评测记录。这样一旦发现某轮训练失败，可以快速回滚到上一轮。
• 每一轮训练前，确认评测集版本没有变化。评测集版本变化会导致前后指标不可比。
• 多轮训练的数据来源一定要做授权审查。如果使用真实用户数据，需要确保符合隐私保护和使用规范；涉及个人身份信息的内容必须脱敏处理。
• 模型的能力边界要在文档中写清楚。明确说明模型在哪些场景下可能产生错误回答，避免用户把模型输出当作权威结果。
• 发布前做人工抽检，不能只看自动化指标。真人评审可以发现在评测指标里看不出来的“答非所问”和“过度拒答”。

任何内容生成类模型，在涉及人物肖像、真实姓名、版权内容或敏感领域时，都必须确认授权和合规边界。多轮训练过程中构造的对抗样本，也要避免生成不当内容。

11. 总结与下一步

这个项目走到 90%，最值得总结的经验是：多轮训练不是重复训练，而是带着“上一轮的错误”继续训练。只有把失败样本、错误分析和数据补全做成一个固定流程，模型能力才能真正被一层层拉起来。

接下来最应该验证的是回归体系。把历次训练结果、评测指标、失败案例全部归档，确保任何一次改动都能被快速评估。后面的工作重心还有两个方向：一是把训练流程参数化，让新数据集可以自动接入下一轮训练；二是把训练产物部署成标准 API 服务，让下游业务可以直接调用。

项目最后 10% 通常比前面的 90% 更花时间。多轮训练的每一步调整都需要重新评测，这比训练本身更慢。建议先建立一套“最小回归集”，每次修改只跑核心用例，等确认没有回退后，再跑全量评测。这样既能控制时间，也能保证模型质量稳定。