大模型算法项目推进到90%进度时很多人会发现一个奇怪的现象功能 demo 能跑训练脚本也能跑完评估指标还涨了几个点但一旦把模型丢到真实场景里它就开始不稳定。答非所问、格式错乱、对同一句话给出完全不同的结果。这个时候最值得做的不是继续堆算力也不是换更大模型而是把多轮训练重新梳理一遍。多轮训练提升模型能力的关键不在于多跑几轮而在于每一轮之间是否形成了数据、训练、评估、错误样本回捞的闭环。这篇文章写给正在做大模型微调、模型训练或算法项目交付的人会拆开讲多轮训练每一轮到底改什么、怎么判断提升、以及从90%到可交付还需要处理哪些事。1. 先搞清楚多轮训练到底解决什么问题别把重复跑当迭代1.1 90%进度真正缺的不是代码是模型边界一个算法规格项目到90%通常意味着训练流程已经完整数据能加载、模型能启动、loss 能下降、checkpoint 能保存、推理也能出结果。但离“可交付”还差一步因为模型还处于能力边界不清晰的状态。你很难回答三个问题它在什么输入上表现稳定它在什么输入上会明显崩掉如果输入在某几个维度变化输出会不会跟着错乱这些问题不是靠“再训练久一点”能解决的。90%阶段缺的不是训练步数而是对模型边界足够细的认知。多轮训练存在的意义就是通过一轮一轮的“优化、验证、找问题、补数据”把边界从模糊压到清晰。我见过不少项目团队把 epoch 从 3 加到 10loss 确实继续下降但线上表现反而更差。因为训练轮次增加只解决了拟合问题没有解决数据分布问题。多轮训练如果只是把同一批数据重复喂进去那就是重复跑不是迭代。1.2 多轮训练的核心数据、训练、评估的闭环多轮训练的正确工作流不是“train.py 多执行几次”而是一个闭环用当前模型在验证集和真实样本上做推理。找出错误样本、低质量输出、格式不稳定的案例。对错误样本做归因是数据覆盖不够、标注错误还是指令表达有歧义。构造新一批数据混合旧数据后重新训练。用同一套评估集做对比确认能力提升且不倒退。进入下一轮。每一轮的核心产物不是新权重而是“这一轮到底修正了哪一类错误”。如果一轮训练结束你只能说“指标涨了 0.3”但说不清是哪些 bad case 被解决了这轮训练的信息量就很低。所以多轮训练的第一个习惯是每次启动训练前先写清楚本轮目标。比如“解决长文本场景下答非所问的问题”“修正输出格式不稳定”“提升同义问法的召回率”。目标越具体后续的数据构造和评估就越容易。1.3 什么时候需要多轮什么时候不需要不是所有大模型项目都必须多轮训练。如果任务很简单比如只做固定模板的分类或者输入输出格式非常封闭单轮微调可能已经够了。多轮训练更适合下面这些情况用户输入变化大同一个意思有几十种说法。负样本或反例很少模型容易“什么都说好”。业务指标不仅要求正确还要求格式稳定、可解析。需要控制幻觉比如抽取任务不允许输出原文没有的内容。模型要同时处理多种指令但互相之间会产生干扰。反过来如果第一轮训练已经达到目标指标bad case 数量很少就不要为了“多轮”而多轮。多轮训练也有成本数据标注成本、GPU训练成本、评估成本。该收就收。2. 多轮训练落地的环境准备和样本策略2.1 环境准备从“能跑通”开始做多轮训练前先确认环境不是“理论够用”而是“实际跑过一轮”。很多项目卡住不是模型代码问题而是环境细节没有准备好。至少需要确认这几项GPU 显存够不够放模型加梯度。如果用的是 7B 或 13B 规模模型先按实际参数查一下显存占用不要凭感觉。内存和磁盘是否够用。数据切分、checkpoint 保存、日志写入都会占磁盘如果磁盘快满了训练会莫名中断。依赖版本是否一致。transformers、peft、deepseed 这类库的版本差异会影响训练行为最好固定一个 requirements.txt。训练脚本和推理脚本是否共用同一套 tokenizer。这个坑很隐蔽训练时没问题推理时经常因为 tokenizer 不一致导致输出异常。我一般会把配置拆成三个文件环境配置、训练参数、评估参数。这样每一轮只改该改的部分不会误动其他逻辑。2.2 第一轮从最小样例开始多轮训练的第一轮建议不要直接全量数据。先用一个小样本集跑通全流程比如 200 到 500 条数据确认三件事数据能正确加载字段映射没有错。loss 能降下来不会出现 NaN。训练后的模型能保存、能加载、能推理。这个过程通常很枯燥但很值得。因为后续每一轮都要依赖这套流程如果流程里有隐藏问题越到后面越难查。我见过有人第一轮就直接用几千条数据训练训练到一半发现数据里混入了 JSON 解析失败的行导致某一段学习不到有效信号。如果先用小样本跑通这个问题几分钟内就能发现。最小样例跑通后再逐步放大到全量数据。放大时要留意 batch size 是否要跟着调显存是否够用。如果显存不够可以降低 batch size但要注意同步调整学习率或梯度累积步数。2.3 每轮样本怎么构造错误样本回填和困难样本挖掘多轮训练每轮的数据增量应该优先来自“当前模型犯错的样本”而不是随便扩充数据。这是整个流程里最关键的一点。具体做法有三类错误样本回填把上一轮评估中模型输出错误的样本收集起来人工修正后加入下一轮训练。这是最直接、效果最明显的方式。困难样本挖掘根据预测置信度、输出与标准答案的差异从大量未标注数据里挑出模型容易混淆的样本优先标注。指令覆盖扩展把同一件事改成不同问法、不同表达习惯、不同长度增强模型的泛化能力。数据量不是越多越好。增加 500 条高质量错误样本可能比增加 5000 条相似样本更有用。因为多轮训练优化的是决策边界不是记忆量。另外每一轮的新增数据要和控制旧数据之间保持平衡。不要让新数据过多导致模型对新数据过拟合忘记之前学到的能力。通常会把历史数据做采样混合或者按一定比例保留上一轮的重复样本。2.4 数据加工从原始库到模型能读懂的格式很多算法工程师会忽略一个问题原始数据库里的字段和模型训练需要的 prompt、response 格式并不是一回事。比如关系数据库里的字段是结构化的而大模型训练通常需要“指令输入输出”这种文本结构。在数据进入训练脚本前至少要完成这几步字段清洗去掉空值、异常值、重复数据。格式统一中文标点、换行、空格是否需要统一处理。标签校验检查标注样本是否和业务规则一致有没有错标、漏标。泄漏检查确认模型输入里没有包含答案本身否则训练时 loss 降得很快上线后效果完全不一样。这一步建议写一个独立的数据预处理脚本并且保留中间输出文件。这样每一轮数据变更时可以对比前后差异避免“上一轮数据状态已经记不清”的问题。3. 训练参数和评估指标怎么定才能看出每一轮有没有提升3.1 核心训练参数怎么调多轮训练不是每一轮都用同一套参数。常见的做法是第一轮用常规参数第二轮开始根据上一轮表现做针对性调整。以下几个参数最值得关注学习率第一轮可以从 1e-5 到 5e-5 之间尝试。第二轮开始如果基于上一轮模型继续训练学习率通常要降比如降到原来的 1/3 或 1/5避免破坏已经学到的能力。batch size影响训练稳定性和显存占用。batch size 较小时模型收敛不稳定较大时训练更稳但显存占用高。如果显存不够用梯度累积模拟大 batch。epoch多轮训练中每轮 epoch 不宜过大通常 1 到 3 个 epoch 就够。重点是数据变化而不是重复咀嚼同一批数据。max length要根据任务输入的最长长度设定。设太短会截断关键信息设太长会浪费显存。warmup大规模训练时建议保留让学习率从一个小值缓慢升到目标值减少前期 loss 震荡。这里给的信息是常见实践不是标准答案。实际项目要以自己的模型规模、数据量和显存情况为准。每一次改参数都要记录在实验表里。3.2 评估指标不能只看 lossloss 是训练过程中的重要信号但不是最终交付标准。很多模型训练后 loss 很低一上线就表现很差原因是 loss 衡量的是训练样本拟合程度而不是真实业务质量。每轮训练后至少看四类指标业务指标准确率、召回率、F1或者你们任务对应的核心指标。格式指标输出是否可解析、JSON 是否合法、字段是否完整。bad case 数量固定一个 bad case 池每轮跑一遍看数量是否下降。稳定性同一个输入跑多次输出是否一致。如果模型每次生成结果都不同影响很大。更简单的做法是准备一个“影子测试集”从真实业务请求里抽 200 到 500 条样本训练前和训练后都跑一遍人工或脚本判断结果好坏。这个测试集不要参与训练只用来做每轮对比。3.3 checkpoint、日志和实验记录多轮训练必须保存好每一次的 checkpoint不要用同一个文件名覆盖。最好按“时间轮次数据量”命名例如 ckpt_r2_1500_v1。同时记录训练数据量、新增样本数量、数据来源。学习率、batch size、epoch 等关键参数。训练前和训练后的评估指标。这一轮主要修复了哪些 bad case新增了哪些问题。这些记录不需要很复杂一个 Markdown 表或 Excel 表就行。但一定不能漏。因为项目到后面最贵的成本不是训练而是“想不起上一轮为什么这么改”。3.4 进阶手段模型融合、蒸馏和多轮对齐多轮训练稳定后再考虑进阶手段。比如模型融合可以把多个训练分支的最好 checkpoint 做加权融合有时比单独选一个模型效果更稳。但模型融合并不是所有场景都有效需要先确认各分支差异足够大。模型蒸馏则适合想把大模型能力迁移到小模型的场景。先用多轮训练把大模型调好再用大模型的输出作为小模型的训练目标。这样小模型在保持低延迟的同时能学到一部分大模型的能力。这些手段都属于多轮训练之后的可选优化不要一开始就扎进去。先把基础闭环跑稳再谈进阶。4. 多轮训练中常见的坑和排查顺序4.1 越训越差过拟合、灾难性遗忘和随机性多轮训练最常见的问题是这一轮修好了一个问题另一轮又把旧问题带回来了或者整体能力反而下降。原因主要有三个过拟合新数据太少或者学习率太大模型记住了数据里的噪声。灾难性遗忘新增数据过度改变了模型权重导致旧数据上的能力下降。随机性训练和推理本身有随机性如果只看一两个样本的结果很容易误判。我一般会给模型同时跑“回归集”和“增量集”。回归集是历史的稳定样本增量集是新一轮重点想解决的 bad case。如果增量集提升但回归集下降很多就要减小学习率或增加回归集比例。4.2 数据泄漏、标签噪声和分布漂移数据泄漏是多轮训练里最隐蔽的问题。比如一个抽取任务训练数据的“输入”里已经包含了标准答案模型学到的只是复制答案而不是抽取逻辑。这样的模型在真实输入上没有泛化能力。判断方法很简单检查训练输入和输出之间是否存在明显的“答案提示”。如果有就要把提示字段从输入里剥离或者重新构造数据。标签噪声则是标注错误。可能来自自动标注脚本的规则遗漏也可能来自人工标注时口径不一致。多轮训练到后面错误样本往往会集中在这些噪声标签上。建议定期抽检一部分训练数据看看标签是不是真的正确。分布漂移则意味着线上真实请求和训练数据来自不同分布。如果上线后发现模型表现不如训练时优先怀疑数据分布不一致而不是模型代码。4.3 一套能用的排查顺序遇到多轮训练效果不及预期时我建议按下面的顺序排查先看训练日志loss 是否正常下降有没有 NaN有没有训练中断。再看评估集下降的是哪个指标是整体下降还是某个子类下降。然后看数据新增样本是否有效标签是否正确输入输出是否泄漏。接着看参数学习率是否过大epoch 是否过多batch size 是否明显变化。最后看环境依赖版本、随机种子、GPU 状态是否和上一轮一致。这个顺序能覆盖大部分问题。不要一上来就怀疑模型结构多轮训练阶段模型结构通常不是瓶颈。4.4 为什么“多轮训练后能力反而下降”多轮训练后能力下降最常见的原因是评估集太窄。比如这轮为了提升某个特殊场景构造了大量特殊样本训练后自然在这个子类上表现更好但整体平均指标可能没变甚至下降。这不一定是坏事关键看业务是否更关注这个子类。另一个常见原因是没有固定随机种子。训练时如果不固定随机种子每轮结果会有波动。这会让“提升”和“下降”难以判断。建议在训练脚本里固定随机种子同时保留一个稳定回归集。5. 从90%到可交付部署、接口和应用侧还有哪些事5.1 导出和量化别让模型只能用显卡跑模型训练完不等于项目交付完成。训练阶段的模型格式往往是框架内部格式推理阶段还要考虑推理速度、显存占用、部署环境。多轮训练结束后第一件事是把模型导出成适合推理的格式并做必要的量化。比如把权重从 fp32 转成 fp16 或 bf16能明显降低显存占用。如果条件允许再尝试量化为 int8 或 int4。但量化不是无损的。量化后模型能力可能下降尤其是多轮训练里比较精细的任务。所以量化和导出之后一定要在这个新格式上重新跑一遍影子测试集确认关键 bad case 没有变差。5.2 本地部署还是 API部署方式要看实际场景。如果是内部小流量系统本地部署是常态如果需要给 C 端产品调用API 化更合适。本地部署的重点是显存、时延和并发。你要先明确单卡还是多卡单次请求最长等待多久最大并发多少这些决定了你能否直接用原始模型还是必须量化、裁剪甚至换小模型。如果是通过 API 调用就要考虑请求认证、限流、超时、重试和计费。不要只想着训练能力部署侧的稳定性同样重要。上线前最好做一个最简单的压测用固定并发连续调用看时延和错误率。5.3 接口调用和失败重试大模型接口的调用和普通后端接口不太一样因为模型推理可能比较慢也更容易超时。调用方需要特别注意请求超时时间的设置。我给一个非常基础的调用思路示例具体接口以你的实际部署为准import requests import json import time url http://your-model-service/v1/chat payload {messages: [{role: user, content: 请解释多轮训练的含义}], temperature: 0.2} headers {Content-Type: application/json} for attempt in range(3): try: resp requests.post(url, jsonpayload, headersheaders, timeout30) if resp.status_code 200: data resp.json() print(data[choices][0][message][content]) break except requests.exceptions.Timeout: print(timeout, retry, attempt 1) time.sleep(1)这个例子只做演示。真实场景里还要考虑接口版本、鉴权方式、返回字段兼容性、错误码处理。多轮训练期间如果已经有推理服务最好从第一轮就把接口调通而不是训练结束才开始。5.4 上线后的 bad case 回流和版本回滚项目上线不是终点。多轮训练最有价值的地方是它能持续利用线上反馈优化模型。所以上线后一定要做 bad case 回流。最简单的做法是把线上输入和模型输出存成日志每天抽一批自动判断异常再人工确认。每周把新 bad case 加入下一轮训练数据。这样模型会随着时间推移越来越贴合真实分布。同时要保留上一版本模型需要回滚时能快速切回去。回滚能力和部署能力一样重要。6. 最后的10%为什么最难我建议怎么推进6.1 先列出当前能力边界如果你已经做到 90%最后 10% 的工作不应该从“继续加数据”开始而应该从“列边界”开始。把当前模型能稳定处理的任务、不能处理的任务、表现不稳定的任务分别写出来。再针对不稳定部分找 20 到 50 个真实样例逐条看失败原因。很多项目卡在最后 10%不是因为模型不够强而是因为不清楚到底要解决什么问题。我习惯在项目看板上列一张“能力边界表”每个边界后面注明数据来源、失败样例、预计改进方式。这样每一步都有据可依。6.2 下一轮迭代的优先级数据 参数 结构到 90% 阶段后改进优先级通常是数据质量 参数调整 模型结构改进。多轮训练每一轮都应该优先考虑数据侧的问题比如错误样本有没有真正修正、负样本够不够、指令覆盖是否充分。只有当数据侧已经稳定才去调学习率这类参数。模型结构改动的影响最大风险也最高通常放在最后甚至不轻易动。如果项目时间紧不要同时改数据、改参数、改模型结构。一次只改一个变量否则出了问题很难定位。6.3 给新手的落地路径如果你刚开始接触大模型训练我的建议很简单先跑通单轮训练再做多轮训练先小样本再全量先把流程固定下来再优化效果。多轮训练听起来高大上但真正拉开差距的往往是基本功数据清洗、评估集固定、日志记录、checkpoint 管理。这些工作看起来不酷但项目最后 10% 的稳定性就是靠这些细节撑起来的。踩过几次坑之后我发现很多问题不是模型能力不够而是前置环境和输入材料没有处理干净。把多轮训练的闭环跑顺项目交付的确定性会高很多。