最近几个月大模型圈子的节奏明显不一样了。技术群里高频出现的词从“预训练”慢慢变成了“中训练”和“后训练”LinkedIn上post-training相关的岗位需求翻了好几倍GitHub上DPO、GRPO、合成数据相关的repostar涨得飞快。最直观的感受是模型发布节奏以前是几个月憋一个大版本现在很多团队一周就能出一个新模型而且每次迭代的差异点往往不在base模型而在pre-training之后做的那些事。模型快速迭代本身也催生了一个很有意思的现象——越来越多团队开始用AI来辅助训练AI让模型生成训练数据、让模型当评测官、让智能体自动跑实验。“AI for AI”从一句口号变成了实打实的日常操作。这篇文章我把最近的观察和踩坑经验一起梳理一下聊聊中训练、后训练为什么持续升温以及为什么说它是AI for AI的最佳试炼场。1. 中训练不是新概念但它是被严重低估的一环先来把名词对齐。很多人习惯把训练阶段分成两段预训练pretraining和微调finetuning中训练mid-training夹在中间经常被忽略。但实际上现在大家口中说的“中训练”指的是预训练和指令微调之间那片广阔的过渡地带——包括持续预训练、领域自适应训练、语言适配、长上下文扩展、特定能力强化代码、数学、推理等等。它不是某个单一算法的名字而是一类训练目标的统称。1.1 预训练让模型学会“通识”预训练阶段模型在数万亿token上做next token prediction本质上是在学“这个世界大致是怎么组织的”。这个阶段决定了模型的知识上限和基础能力但代价极高。一个7B模型在高质量语料上完整预训练通常需要上千张GPU卡跑上一个月普通团队基本不碰。所以对大多数从业者来说预训练更多是“选哪个底座”的问题而不是“怎么训”的问题。1.2 中训练从“通识”到“专才”的过渡带中训练解决的核心问题是通用模型到细分任务之间的落差。比如你要做一个专利领域的模型base模型虽然懂语言但对专利文本的术语、结构、引用关系并不敏感。这时候直接在专利语料上继续预训练domain-adaptive pretraining让模型先“熟悉领域”再去做指令微调效果会比直接SFT好很多而且能大幅降低灾难性遗忘。中训练的常见形式有这么几类持续预训练CPT在原始预训练任务上继续训练语料换成领域文本这是最主流的形式。语言/格式适配让模型适配代码、结构化JSON、Markdown、特定模板等本质上也是“熟悉一种表达方式”。长上下文扩展通过调整位置编码和插值把上下文从4K扩展到128K以上解决的是“窗口不够用”的问题。特定能力强化在数学、代码、逻辑推理语料上继续训练提升模型的硬能力典型的如很多推理模型的底座训练。这里最关键的设计是数据配比。我之前做过一个代码领域的实验100%代码语料继续训练下游code指标涨了一些但通用对话能力掉得很明显后来把配比调成60%领域语料30%通用语料10%指令数据通用能力基本保住代码指标反而更高。原因是模型在领域语料上训太久分布坍缩了加入通用语料相当于给它一个“锚点”。注意中训练不是“把语料喂进去跑几步”就完事。领域语料的质量、去重程度、配比、学习率每一项都在影响最终结果。我见过太多人拿爬虫抓的原始网页直接训练结果模型学会了网页模板而不是领域知识。1.3 后训练把“会”变成“好用”后训练指预训练完成之后、模型上线之前的全部训练环节核心是指令微调SFT和偏好对齐RLHF、DPO、GRPO这一类。SFT让模型学会“按指令办事”偏好对齐让模型学会“办得漂亮”。后训练的重要性在过去一年被反复验证**同一个base模型用不同的后训练策略出来的模型能力差异可能比换一个更大的base还大。**这也是为什么现在很多团队愿意把资源往post-training倾斜。举个例子两个团队用同一个base模型一个只做了简单的SFT一个做了“SFT 偏好优化 推理时策略调优”最后在用户反馈上完全是两个产品。base模型决定了上限但后训练决定了你能摸到多高的上限。1.4 三者的配比正在改变模型迭代策略在算力预算有限的情况下预训练、中训练、后训练怎么分账我观察到的趋势是资源分配正从“90%预训练”转向“50%-60%预训练20%-30%中训练20%后训练”甚至后训练比例更高。原因很简单预训练一个7B模型的钱够你做几十轮中训练和后训练实验而对最终产品体验的影响后者往往更明显。很多中小团队的策略就是“直接拿开源base模型重仓中训练和后训练”用有限算力换最大产品收益。这里需要敲一下黑板中训练和后训练不是“能跑通就行”的事数据质量、配比、超参、评估这几个环节任何一个出问题迭代就变成空转。2. 迭代主战场为何从预训练迁向后训练2.1 预训练边际收益降低账单却在涨预训练领域最明显的变化是“赛道拥挤”。各家base模型在MMLU、HumanEval等通用基准上的差距越来越小动辄几千万美金的算力投入换来的是0.3%的提升。边际收益递减这是一个经济问题。大家开始意识到base模型“能用的下限”已经被几家头部团队拉高了真正决定产品口碑的是指令遵循、推理风格、稳定性这类后训练才能改的东西。我自己在选base模型时已经很少只盯着benchmark分数看更多是拿自己领域的样本去实测看它“好不好用”而不是“分高不高”。2.2 后训练是“小投入改行为”的杠杆后训练的杠杆效应体现在两个地方。一是参数层面LoRA这类高效微调方法只训练0.1%-1%的参数就能显著改变模型的输出风格与行为偏好二是数据层面几千条高质量指令数据就能让一个“看起来什么都懂但答非所问”的base模型变成可用的产品。这种投入产出比在预训练阶段是不存在的。预训练改一个行为可能需要重新跑几万亿token后训练改一个行为几百条样本加一块GPU跑几小时就够。2.3 快速迭代的真实形态模型序列与小步发布快速迭代不是“一个人偷偷训练”而是有组织地发布“模型序列”。最常见的是base模型和chat/instruct版本分开发布随后在几周内连续推出修订版一次修一个问题。这种小步快跑的模式对实验工程能力要求极高每个实验都要能快速复现、快速评估、快速回滚。如果你还在用“手动复制配置文件、跑完看loss、拍脑袋决定下一步”那迭代速度注定跟不上。我见过不少团队训一个模型两周评估加对齐拖一个月问题全出在流程上。2.4 智能体训练方法成为新突破口后训练阶段还出现了一个值得关注的新方向把智能体能力作为训练目标。DeepSeek曾经公开过一套智能体训练相关的新方法思路大致是让模型在模拟环境里执行多步任务用环境反馈当训练信号而不是只用人工标注的偏好对。这类方法把“AI学会用工具、学会规划”变成了一个可训练的目标是中训练和后训练结合的一个典型前沿案例。对做应用的团队来说这个方向意味着不要只盯着“让它说得好”更要关注“让它做得好”。3. AI for AI 到底在“试炼”什么“AI for AI”这个词听起来玄乎拆开看其实特别朴素**拿AI去把AI研发流程里的脏活、累活、重复活自动化。**为什么说它是“试炼场”因为AI研发本身是一个数字化、可量化、有清晰反馈闭环的行业AI工具在其中每走一步都能立刻看到效果这种环境最适合验证AI的能力边界。3.1 AI做数据生产者合成数据与数据清洗中训练和后训练最缺的不是模型是数据。合成数据是这两年最实用的突破口用强模型生成领域样本、用弱模型扩充长尾场景、用embedding模型去重、用语言模型做质量过滤。我以前整理代码训练语料时先用一个分类模型给每个文件打质量分再按分数分桶采样剩下要训的量直接少了60%训练效果反而更好。这就是AI for AI的价值不是玄学是减少无效计算。具体操作上我建议的顺序是先做粗粒度清洗去重、去广告、去低质量再做细粒度质量打分最后按任务类型做配比采样。其中embedding模型去重很容易被忽略但领域语料里重复率往往高得吓人重复样本会让模型在局部分布上过拟合。3.2 AI做评测官LLM-as-judge与自动回归快速迭代离不开快速评估。人工评测慢且贵LLM-as-judge让几个模型互相打分几分钟就能给几十个实验版本排出名次。我自己在迭代对话模型时固定了一个由50个典型问题组成的回归评测集每次训练完自动跑一遍用打分模型给结果排序哪个版本能合并、哪个版本要回滚一目了然。这个流程跑几个月后你会发现自己对模型变化的理解会变得非常敏锐。但评测官模型本身也有偏好所以要定期校准用一小撮人工标注样本校验打分结果发现偏差就及时修正打分模板。有一个细节是打分时最好让评测模型“先复述答案要点再打分”分数会比直接打更稳定。3.3 AI做训练协同者实验调度与失败分析再往前一步AI开始直接参与训练过程。智能体盯loss曲线、读日志、自动定位BN崩溃或者梯度爆炸然后给出超参调整建议实验平台根据历史数据预测哪些超参组合更可能有效直接排进队列。这也是DeepSeek那类智能体训练方法真正落地的场景——模型在环境反馈中学会调参和排错而不是靠人肉盯屏。3.4 为什么AI研发是最佳试炼场别的行业做AI落地常被数据孤岛和反馈延迟卡住AI研发自己呢目标函数就在屏幕上loss曲线是纯数字实验成败几小时就能见分晓。这种环境天然适合AI工具发挥。更重要的是AI研发的每一个环节——数据清洗、合成、评估、调参、部署——几乎都可以被拆解成“输入-处理-输出”的标准化流程这正是智能体最擅长处理的任务类型。所以我一直认为如果你想知道AI到底能多好用先看它在AI行业自己身上用得怎么样这就是“试炼场”三个字的含义。4. 一个人如何上手从模型选型到中后训练的最小闭环说了这么多趋势落到实操上一个人怎么开始做中训练/后训练我整理一套最小可行流程照做就能跑通。4.1 选模型与工具链别一上来就碰大模型如果你只在7B级别的小模型上做中训练/后训练单卡或双卡就能跑LoRA几小时出结果。大模型看起来更酷但迭代速度跟不上反而没法积累经验。建议的初始组合底座模型Qwen2.5-7B、Llama-3.1-8B这类开源模型或者DeepSeek-R1的蒸馏小模型。训练框架transformers peftLoRA trlSFTTrainer、DPOTrainer简单够用。推理与评测vLLM做服务化配合LLM-as-judge脚本做批量测评。实验记录权重和配置统一放在一个目录下命名规则建议带上“日期-数据版本-训练阶段-学习率”别小看这个习惯快速迭代时它能救你的命。4.2 中训练落地领域语料配比与抗遗忘设置第一步准备领域语料。我自己习惯的做法是收集原始文本→用规则做粗清洗去HTML、去空行、去重复段落→用embedding模型做去重→用一个轻量分类模型打质量分→按分数分桶采样。第二步设置数据配比。记住我之前说的60%领域30%通用10%指令数据这个基线然后根据你的任务调整。领域数据比例太高通用能力会掉太低中训练效果不明显。用LoRA训练学习率建议设在1e-4到3e-4之间比SFT低一个量级因为中训练的目标是“温和地迁移”。第三步监控遗忘。每轮训练结束除了看领域任务的指标一定跑一遍通用能力评测比如MMLU的子集发现通用能力掉得厉害就降低领域数据比例或提前停止。4.3 后训练落地指令微调与偏好优化的实操要点后训练的第一步是SFT。指令数据宁缺毋滥几百条高质量样本胜过几万条凑数的。以前我整理过一个用户真实提问的数据集发现一个规律用户问问题的语气和角度跟网上公开的指令模板差别很大。所以做SFT数据最有效的方式是从真实使用场景里捞对话而不是凭空编模板。第二步是偏好优化。如果预算有限优先试DPO而不是RLHF因为DPO不用单独训练奖励模型数据准备也简单——只需要一组偏好对chosen和rejected。偏好对的质量直接决定效果我踩过的坑是让模型自己生成rejected答案结果生成出来的答案太差模型很快就学会了“只要不答得离谱就行”的偷懒策略。后来改成人工挑错误答案里的典型错误模式效果才正常。4.4 快速迭代的工程基建评测集、实验记录与回归快速迭代的基础设施核心是三件事固定回归评测集、标准训练脚本、自动报告。回归评测集不用大50-100条能代表你核心场景的样本就够标准训练脚本要能一键跑完中训练/后训练的完整流程参数可配置自动报告每次训练完自动生成指标对比和示例输出直接发到群里。这套基建搭好之后模型迭代就变成了流水线数据更新→跑训练→跑评测→看报告→决定合并或回滚。这也是我前面说的“模型序列”小步发布的基础。4.5 不同模态与任务里的同类思路中训练/后训练不是大语言模型的专利。做视觉的同学在CLIP模型上微调本质上也是“预训练底座领域适配”做时序预测的用滑动窗口滤波模型或者LSTM/seq2seq模型同样有“先用通用数据预训练、再用领域数据中训练”的操作空间哪怕是用LightGBM做回归也经常是先在一个大样本上训练出基础模型再在新数据子集上继续训练调整权重。思路是共通的先学通用结构再迁移到特定领域最后用偏好或目标函数优化行为。5. 快速迭代期的典型翻车现场与排查经验模型迭代快了问题出现得也快。这里分享几个我在实际项目里碰到过的典型翻车场景和排查思路。5.1 训练中途BN崩溃YOLO与检测模型的经典问题做目标检测的同事应该都遇到过YOLO训练中BN崩溃的报错——训练到中途loss突然变成NaN或者剧烈震荡检查发现BatchNorm层的running_mean和running_var漂移到了离谱的值。这个问题在快速迭代中更容易出现因为你频繁改数据配比、改增强策略batch内的样本分布剧烈变化BN的统计量就跟不上了。排查链路先排硬件错误用确定性seed复跑再查学习率和warmup最后查BN。解决方案一般有三条一是固定BN层参数detect head之外的BN冻结二是调低BN的momentum让统计量更新更平滑三是检查是否用了过强的增强策略比如Mosaic和MixUp叠加会让单batch内分布过碎。BN崩溃不是偶发是训练配置和数据处理共同作用的结果复现后要一条条排查。5.2 切换模型后对话跳闪工程上的状态同步陷阱有朋友遇到过“CC switch切换模型后原对话不停跳闪”的问题表面看是前端bug实际是状态同步问题。切换模型时前端保留着原对话的历史消息但服务端新模型的上下文格式、system prompt、tokenizer版本可能都变了。模型ID一换历史上下文里旧的token序列在new tokenizer下解析错位返回结果异常前端反复重试导致跳闪。解法是切换模型时要么清空历史上下文重新开始要么将历史消息重新encode成新模型的输入。这件事给我们的通用教训是模型快速迭代时前后端的状态契约要比模型本身更稳定否则模型越新线上故障越诡异。5.3 自定义模型接入工作流失败Langflow与标准接口很多人在Langflow里配置自定义模型服务地址时失败报错千奇百怪。但绝大多数原因都指向同一个自定义模型服务没有暴露OpenAI兼容接口。Langflow这类工具默认用标准接口格式去调的你传一个裸的FastAPI接口给它它当然不认。解法是在你模型服务外面套一个兼容层把对话补全、鉴权、超时、流式输出都按OpenAI的格式对齐。这也算“AI for AI”的日常让工具链之间互相能对话本身就是一种集成工程。5.4 训练到部署的迁移断层IsaacLab到MuJoCo的教训仿真机器人领域有个高频问题“IsaacLab训练完成后如何导入到MuJoCo中”。之前在模仿学习和强化学习项目里遇到类似问题IsaacLab训好的策略导出成.pt或.onnx直接拿MuJoCo加载动作总是对不上。排查下来通常是三类原因动作空间定义不一致力矩 vs 位置增量、坐标系变换没对齐世界坐标系 vs 基座坐标系、时间步和控制频率不匹配。解决思路是先在两边各跑一个随机策略记录动作输出做对照逐项对齐实在对不齐就检查导出前是否做了动作缩放和clip。仿真迁移这事的本质是环境定义的一致性中训练和后训练里讲究数据格式一致仿真迁移里讲究环境接口一致底层逻辑一样。5.5 隐藏在数据里的风险模型中毒与评测污染快速迭代要特别小心两类数据风险。一是模型中毒攻击训练数据里被恶意塞入带trigger的样本模型平时表现正常一旦输入里出现trigger就输出攻击者想要的内容。随着中训练和后训练大量使用合成数据、爬虫数据供应链安全越来越重要。建议每一步数据都保留血缘记录定期用trigger样本做探测。二是评测集污染如果评测集被模型训练语料包含那一切指标都是自嗨。我见过有人拿MMLU的题目原文做后训练语料再拿MMLU做评测分数涨得飞起上线就露馅。数据血缘和评测隔离是模型快速迭代里绝对不能省的功夫。一点个人体会中训练和后训练升温本质是行业从“拼底座”转向“拼工程和拼数据”。快速迭代和AI for AI这两件事其实互为因果正因为迭代快才需要AI工具来帮忙管数据、跑评测、调实验正因为AI工具好用迭代才能更快。如果你打算入局我的建议很直接选一个小模型把中训练、后训练、评测回归这条链路完整跑通一遍再考虑怎么扩规模。这个过程里踩的坑大概率都是将来做更大模型时同样要面对的坑早踩早受益。