MiMo V2.6后训练recipe全解读：从数据配比到实操复现

小米的MiMo系列开源模型在社区里已经不算陌生了从7B级别的dense模型到MoE版本再到VLM多模态分支迭代节奏一直挺快。这次V2.6版本把后训练post-training的完整recipe直接摊开放在仓库里对于想搞清楚“一个大模型是怎么从预训练权重变成能好好聊天的助手”的人来说是非常难得的实操教材。我花了不少时间把这份recipe从数据配置到超参数、从训练脚本到评测流程从头到尾过了一遍这篇文章想分享我从这份recipe里读出来的关键信息以及自己实际动手时踩过的坑。如果你正准备复现或者参考MiMo V2.6做自己的模型对齐又或者只是好奇开源模型的后训练到底长什么样这篇解读应该都能帮上忙。我会按“整体思路—配置解读—关键技术—实操复现—问题排查”这个顺序来拆尽量把每个环节背后的“为什么”也讲清楚。1. 先搞清楚MiMo V2.6的recipe到底是个什么东西1.1 从MiMo系列说起MiMo是小米在2024到2025年间陆续放出来的开源模型系列主打的是“中尺寸高性能”。7B这个量级在推理成本上比几百B的大模型友好太多同时通过MoE混合专家结构把激活参数控制在很低的范围单卡甚至就能跑起来。V2.6是这系列里的一次重要迭代重点优化的方向包括指令跟随的稳定性、长文本场景下的表现以及推理效率的提升。后训练recipe在开源模型仓库里通常不显眼因为大家第一眼都去看模型权重和推理demo。但V2.6把这一块认真地开源出来等于把“从基座模型到可用助手”的那条生产线也公开了。这条生产线包含数据配比、训练策略、超参数、评测脚本甚至还有训练过程中的一些trick。这不是简单的train.py一个文件而是一整套可复现的配置。1.2 为什么后训练recipe值得单独解读预训练把“语言能力”灌进模型但预训练模型直接拿来对话效果是很灾难的——它不会遵循指令不知道什么时候该停止也不会用人类喜欢的语气回答问题。从预训练模型到Chat式模型的转变靠的就是后训练。后训练的核心任务可以拆成几个台阶先是让模型学会“听话”指令跟随再让模型的回答符合人类偏好有用的、无害的、格式正确的最后还要考虑效率和可靠性。MiMo V2.6的recipe把这些台阶都串起来了里面的每一个设计决策都值得仔细琢磨。我自己看了很多开源模型的训练文档很多项目只给结论不给过程像MiMo这样把细节写到这个程度的并不多见。这里还要提一个很多人容易忽略的点开源模型的两类资源里权重是“鱼”recipe是“渔”。权重让你能跑起来recipe让你能在它的基础上改出适合自己的模型。尤其是企业做私有化部署的时候往往需要针对业务数据做二次微调这个时候一份清晰的后训练recipe的参考价值就出来了。2. 打开recipe仓库目录结构和配置文件怎么读2.1 一个典型的后训练recipe包含哪些文件我整理了一下MiMo V2.6 recipe仓库的顶层结构通常会有这么几块目录/文件作用我的解读建议configs/训练超参数配置YAML或JSON格式优先看这个最快了解训练规模data/数据配比清单和数据处理脚本这是recipe的灵魂值得逐行读scripts/训练、评测、转换格式的脚本看启动命令和参数传递方式model/模型结构定义和加载逻辑如果复现要确认和权重版本匹配evaluation/评测基准和prompt模板看评测条件后面对比成绩要用打开config文件后你可能看到一堆参数learning_rate、per_device_train_batch_size、gradient_accumulation_steps、num_train_epochs、warmup_ratio、lr_scheduler_type、bf16等等。关键是不要孤立地看每个数字要结合起来判断训练的压力和成本。2.2 核心超参数背后的逻辑首先说学习率。后训练阶段的学习率通常比预训练低一到两个数量级。预训练阶段常见的学习率在1e-4到3e-4左右后训练SFT阶段则普遍在1e-5到2e-5这个区间。MiMo V2.6的recipe里用的学习率在这个范围内配合warmup逐步提升避免训练早期对模型权重产生过大冲击。之所以要这么低是因为后训练阶段模型已经具有较强语言能力我们只需要“微调方向”不需要“大改能力”学习率过大会导致已有能力被破坏这就是所谓的灾难性遗忘。再来看训练轮数。SFT阶段一般跑1到3个epoch不是越多越好。数据量大的时候1个epoch就够数据量小的时候跑2到3个epoch来充分吸收。如果数据量很大还跑多个epoch模型就开始对训练数据过拟合表现为回答变得刻板、泛化能力下降。batch size的设定则受显存约束。MiMo V2.6是7B级别的模型MoE版本激活参数更少如果用8卡A100 80Gper_device_train_batch_size通常可以开到8到16配合梯度累积达到一个较大的有效batch size。有效batch size的计算方式是per_device_train_batch_size × 梯度累积步数 × 设备数量。这个有效batch size决定了训练的稳定性一般建议SFT阶段控制在128到512之间DPO阶段可以更小一些。序列长度方面V2.6支持长上下文recipe里的max_length通常会设置为8192或16384。序列长度直接决定显存占用因为它和注意力机制的计算量是平方关系。如果显存不够优先降低batch size而不是贸然缩短序列长度因为短序列会让模型丢失长文本能力。2.3 数据配置才是recipe的灵魂看一份recipe我最先翻的永远是数据部分。MiMo V2.6的recipe里对数据格式做了明确的约定每一条训练样本都按照messages的结构组织包含system、user、assistant三部分。system prompt用来设定模型身份和行为边界user是用户输入assistant是理想回答。在tokenize阶段prompt部分会被mask掉也就是说模型只在assistant输出上计算损失。这个设计很多人一开始不理解——如果prompt部分也计算损失模型会被迫去“记住”用户的问题这既浪费容量又容易造成过拟合。数据配比是另一个重头戏。recipe里通常会把数据分成几类通用指令数据训练基础对话能力、数学推理数据训练逐步思考、代码数据训练程序生成、多轮对话数据训练上下文连贯性。配比原则要结合模型定位看MiMo强调通用助手能力所以通用指令数据的占比最高数学和代码居中再配合一定比例的纯文本数据来抑制遗忘。我注意到recipe里还包含少量中文数据这对国内使用场景非常重要——很多国际开源模型的recipe在中文数据配比上几乎为零。数据处理阶段还有几个容易忽略的细节全词掩码whole word masking处理避免token被切碎去重逻辑防止数据重复导致过拟合质量过滤通过规则或小模型打分筛掉低质量样本。这些在recipe的脚本里都有体现复现的时候建议先跑通数据处理流水线再启动训练。3. 后训练recipe中的关键技术与原理拆解3.1 SFT阶段别小看“简单的指令微调”SFT监督微调是整个后训练流程中最基础的一步。虽然现在很多项目直接跳过SFT去做偏好优化但以我的经验SFT仍然是最能稳定提升模型指令跟随能力的阶段。MiMo V2.6的SFT数据涵盖了单轮、多轮、检索增强、工具调用等多种形态这个设计很符合当前大模型应用的实际情况——大家不只是拿模型聊天还希望它能调用工具、查资料、操作API。SFT损失函数只计算去掩码后response部分的交叉熵。这里有个常见误区有人认为既然是交叉熵那只要把数据切好就能训练。实际上response格式的一致性对训练效果影响非常大。如果一部分数据用Markdown格式另一部分用纯文本模型就会在这两种风格之间摇摆。MiMo的recipe特别强调格式统一甚至给了一个数据格式校验的脚本跑一遍能过滤掉不符合格式要求的样本。我在自己项目中复刻了这个做法效果立竿见影训练后模型输出格式的稳定性明显提升。SFT阶段还要注意数据长度分布。如果数据大多是短问题短回答模型在长文本场景下就会“懒得写”。MiMo解法是在数据配比中混入一部分长文档摘要、长对话生成的数据让模型见过“长输出”长什么样。这个思路很朴素但确实管用。3.2 偏好优化阶段DPO与更进阶的配方SFT之后模型能“好好说话”了但离“说得让人满意”还有距离。偏好优化解决的是这个问题——让模型知道什么样的回答是用户更喜欢的。MiMo V2.6的recipe里用了DPODirect Preference Optimization作为核心偏好优化算法这一点我比较认可。相比于传统的RLHF基于强化学习的从人类反馈优化DPO不需要单独训练奖励模型也不需要在线采样和后置策略更新实现简单、训练稳定。DPO的核心是让模型在偏好数据上拉开差距给定同一个prompt有一条被偏好的回答chosen和一条不被偏好的回答rejected训练目标就是增大chosen的概率、减小rejected的概率同时用KL散度约束不要让模型偏离参考模型太远。这里有两个关键超参数betaKL约束强度和参考模型reference model。beta一般设置在0.1到0.5之间。beta越大对参考模型的约束越强模型的变化越小beta越小模型越激进地靠近偏好数据但也容易产生“过度优化”现象——模型会故意使用华丽的辞藻和冗长的句式来讨好偏好打分器反而让真实用户体验变差。我在复现时把beta调低到0.1以下试过模型回答确实变得花哨但事实准确性明显下降所以最后还是回到了recipe推荐的0.2左右。参考模型通常是SFT阶段的模型副本。DPO训练时参考模型负责计算当前模型偏离的“锚点”但参考模型本身不参与梯度更新。这里有个显卡优化技巧可以冻结参考模型并共享同一块显存通过peft的prepare_model_for_kbit_training把模型量化到4bit或8bit参考模型保持bf16这样两块模型的计算都压到单卡也能跑。MiMo的recipe里对这部分有详细的内存配置说明实践下来收益很大。3.3 蒸馏与后训练融合除了SFT和DPOMiMo V2.6的recipe里还增加了基于蒸馏的数据增强环节。蒸馏的基本思路是让一个小模型学习一个大模型的输出。这里的具体做法是用更大的教师模型比如更大参数量的通用模型生成高质回答然后把这些回答作为SFT数据训练MiMo。这样做的好处是可以低成本地把大模型的风格和推理模式迁移到小模型上。蒸馏数据处理有两个关键点第一温度设置。生成教师模型回答时采样温度通常控制在0.7左右太低会让回答缺乏多样性太高会引入大量噪声。第二过滤逻辑。不是所有教师输出都值得学recipe里会加一个规则判断如果教师模型回答的长度过短或包含“我不确定”“我不知道”等表达就丢弃该样本。这个过滤逻辑我建议原样保留因为垃圾样本对蒸馏的伤害远大于它们带来的数据量贡献。V2.6的recipe还有一个亮点是“短答案蒸馏”专门针对数学和代码任务。用教师模型生成的问题会附带一个简短的思维链CoT在训练时把思维链作为response的一部分。这样模型在推理时就会自己“打草稿”但不会把草稿暴露给用户而是直接用最终答案回答。这种数据组织方式让我印象很深它其实是用数据工程技巧同时解决了“推理能力”和“输出简洁度”这两个目标。3.4 长上下文与模型合并策略长上下文已经成为这个阶段模型的标配能力。V2.6的recipe里在后训练阶段加入了一部分长上下文数据长度从16K到32K不等用来维持和强化模型的长文能力。这种做法背后的原理是RoPE旋转位置编码对超出预训练长度的位置无法直接外推需要通过在长文本数据上做少量继续训练来“激活”外推能力。如果你要复现这个部分建议准备好32K以上长度的真实语料并监控模型在长文本基准上的表现变化。另外recipe里还提到了模型合并。我在多家开源项目里见过这种做法训练完一个SFT模型和一个DPO模型之后不直接使用DPO版本而是把两个模型的权重做比值合并如SLERP插值或Layer-wise合并。这样可以在保留SFT模型的稳定性和指令能力的同时吸收DPO模型的偏好优化成果。V2.6的recipe把合并后的模型也做了评测并显示在部分基准上有微弱提升。这个trick不需要额外训练成本适合所有做模型微调的人尝试。3.5 训练中的小技巧梯度累积、指数移动平均与低精度优化提到这些小技巧不是因为它们“高级”而是因为它们对训练稳定性影响非常大。梯度累积在显存受限时几乎是必选项。注意梯度累积不是简单地把batch大小变大它还影响BatchNorm统计但LLM里通常没有BN影响小和warmup步数的计算。如果gradient_accumulation_steps设得很大比如8以上那么整个训练的有效步骤数就会变小warmup_ratio需要相应提高否则学习率还没“热”起来就进入主阶段了。指数移动平均EMA在图像生成模型里用得多现在LLM后训练里也开始流行。recipe里给EMA的衰减系数是0.9999每隔一定步数把当前权重和EMA权重做插值。这样做的好处是让模型参数更平滑评测时往往比直接用最后checkpoint的效果更稳定。代价是显存和算力都要额外付出所以如果训练资源紧这个部分可以先跳过。低精度优化方面MiMo V2.6的recipe默认用bf16混合精度Loss Scaling策略依赖bf16原生动态范围就够了不需要像fp16那样手动调scale。如果你用的是消费级显卡如RTX 4090可以开8bit优化器如AdamW8bit来省显存但要注意量化后的数值精度变化对训练结果可能产生微妙影响建议先跑小规模实验验证。4. 实操复现照着recipe跑一遍全流程4.1 环境准备清单先列出我复现时的环境给大家一个参考项目配置建议备注GPU8×A100 80G 或 8×H100单卡也可以跑但要调小batch size内存512GB数据预处理阶段很吃内存存储2TB NVMe SSD模型checkpoint 数据集至少1TBCUDA12.1及以上保证FlashAttention能跑起来框架PyTorch 2.1transformersacceleratepeftflash-attn版本严格对齐recipe的requirements依赖安装这块我的经验是不要直接用最新的版本。transformers的接口变动很频繁小版本差异可能导致AutoModelForCausalLM.from_pretrained加载出来的模型结构对不上。MiMo V2.6的repo里如果有requirements.txt就按里面的版本装不要自己挑“最新版”装。另一个建议是先用一个1080/4090级别的卡跑通一次小规模的训练脚本比如把数据裁到1000条训练1个step验证环境没问题再上全量。4.2 数据准备与tokenize数据准备的第一步是把原始数据转换成训练样本。MiMo的recipe里用的是对话格式每行一个JSON对象包含messages字段。如果你有自己的数据需要按照这个格式组织特别要注意system prompt的书写方式。第二步是tokenize和打包。这里我要提醒一个对新手很友好的技巧不要直接用tokenizer()来做全量数据预处理那样会产生一个巨大的中间文件。更高效的做法是流式处理用datasets库的map方法配合batchedTrue在加载数据的同时完成tokenize并缓存到磁盘的arrow文件。这样即使数据集很大也不会一次性占满内存。打包packing是一个提升训练效率的关键操作。把多个短样本拼接成一个长的训练序列可以减少padding浪费提升GPU利用率。但打包也带来一个问题序列边界处的attention容易“串扰”。MiMo recipe里给出的处理是把不同样本用eos分隔并在position_ids上做连续编号保证每个样本内部的token相对位置正确。这个实现细节很值得看一下因为不少开源的packing实现只做了拼接没有处理position_ids训练效果会打折扣。4.3 训练执行与监控准备好数据和环境之后就可以启动训练了。启动命令通常是类似这样的bash scripts/train_sft.sh脚本内部会调用accelerate或deepspeed启动分布式训练。第一次跑建议用accelerate launch --config_file configs/zero2.yaml这种模式显存和速度比较平衡。如果数据量大到几十亿token再考虑zero3但zero3会引入额外的通信开销。训练过程中我最关心的几个指标分别是loss曲线、梯度范数、学习率变化。loss曲线正常应当平滑下降如果出现突然的“spike”尖峰多半是数据里混进了异常样本比如超长文本、格式坏掉的输入这时候先暂停训练定位到具体数据批次再重启。梯度范数如果飙升到正常值的好几倍也是数据异常的征兆可以配合grad clip一般设1.0来兜底但根本解决办法还是清理数据。checkpoint保存策略建议每隔500到1000步保存一次。显存大的设备可以保存全部优化器状态显存小的就只保存模型权重重启时从头开始warmup。保存的checkpoint不一定都要保留因为后训练阶段通常只需要最后几个checkpoint中间版本的价值不大。4.4 评估不要只看单次得分线下评测是复现recipe的最后一步也是很多人最容易做“塌”的地方。评测的时候首先要对齐prompt模板和采样参数。同一个模型temperature0.1和temperature0.7的成绩会差很多few-shot还是zero-shot也会显著影响结果。MiMo的repo里评测脚本是固定的直接跑就好不要自己乱加prompt工程。但我要强调一点基准分数只是一个参考维度。实际对话体验、对特殊指令的遵循度、回答风格的一致性这些也需要人工评估。我在复现时常常挂一个简单的脚本随机抽100条问题用同一服务端跑模型并保存日志快速浏览模型在开放式问答上的表现。这样能发现基准测试覆盖不到的“歪”现象比如模型总喜欢用“好的我来帮你分析一下”这样的开场白——基准分看不出来但用户反馈一定很难受。5. 实操中的常见问题与排查技巧5.1 训练过程中loss突然冲高这大概是所有复现工程中最高频的问题。我的排查顺序如下检查数据格式。有没有样本只包含assistant回答但没有对应的user输入有没有response内容为空这些异常样本会直接把loss拉高。检查学习率。如果warmup结束后的初始学习率偏高比如超过3e-5可能在训练前期就出现loss上涨这时把learning rate调低重新跑。检查attention mask。如果packing时没有做正确的mask模型会看到下一个样本的内容loss平均值也会受影响。检查梯度累积步数。累积步数大时loss display的频率设置不好你看到的loss其实是好几个step的平均波动看起来会比实际更夸张。5.2 评测分数跟官方对不上这种问题几乎人人都遇到过。我总结几个最容易出偏差的地方原因具体表现对策评测温度不一致分数偏低按recipe里的采样参数来跑prompt模板不一致分数偏差大用repo里自带的评测脚本生成长度限制太短数学题做不完默认设512或更长少样本示例不同GSM8K分数波动很大明确few-shot的示例来源并行评测的数值误差微小浮动但整体一致多跑几次取平均另外有些评测集本身对模型输出格式非常敏感。MiMo的模型如果开了“思维链”选项评测模板里可能要做相应处理否则分数就会偏低。这些问题都能靠“直接用官方评测脚本官方采样参数”规避。5.3 模型“变笨”了丢掉通用能力怎么办复现recipe之后我发现模型在目标数据上确实变强但在一些通用能力上比如常识问答、开放生成有退化。这不一定是你的训练出了问题而是后训练的通病——模型把自己的“注意力”放在训练分布上对分布外的内容回应变差。缓解方法有这么几个一是加大通用数据的配比二是保留一部分“原始数据”做遗忘补偿比如在DPO数据里混入原始SFT样本三是降低学习率和epoch数。我从MiMo V2.6的recipe里看到它的数据配比表里特别标注了“通用能力保持数据”的占比这个设计思路挺值得学习。它就是在SFT数据里专门留出一部分任务无关的语料新闻、百科、博客用来抵消其他任务数据带来的分布偏移。5.4 训练资源不够能用单卡复现吗前面说过MiMo V2.6的7B模型用单卡跑是可能的但需要接受几个妥协。我给的参考配置是RTX 4090 24Gper_device_train_batch_size1gradient_accumulation_steps64这样有效batch size也能到64左右。配合4bit量化QLoRA之后显存占用可以压到15G以内但量化训练和bf16训练的数值行为有差异效果可能略有折损。另一个省资源的技巧是用LoRA低秩适配。在recipe的config里模型用LoRA训练时只需额外保存几MB适配器权重合回base模型即可。MiMo的repo里对LoRA的rank和target_modules有预设配置一般是rank128覆盖全部attention层这个我直接用了训练速度比全参快很多最终在评测集上的分数和全参版本差距在可接受范围内。如果你要做快速验证LoRA是首选方案。5.5 关于recipe依赖项的一个坑复现代码时最容易翻车的地方反而是框架版本。有时候transformers版本不匹配加载模型时会出现key不匹配的警告有时候flash-attn编译失败模型训练直接跑不起来。我的建议是用docker镜像固定整个环境而不是只依赖pip。把官方推荐的tag拉下来再在里面装自己的依赖这样能省去很多排查环境问题的时间。6. 最后聊几点我的实际体会把MiMo V2.6的recipe完整解读和复现之后我最大的感受是开源后训练recipe的价值不在于提供一个“exact copy”而在于提供一套经过验证的决策框架。你拿到一份recipe不应该只想着“照抄跑一遍”而是要试着去改改看。比如把数据配比里中文数据比例调高会不会更适合国内业务把DPO的beta调到0.15模型的风格会有多大变化序列长度从8192改成16384显存压力翻了多少这些问题的答案在官方repo里找不到只有自己动手实验才能得到。还有一点想特别提醒任何recipe都是一个快照它反映的是那个时间点上团队对数据、算法、算力三者关系的理解。后训练这个领域还在快速演进今天的最优配置可能半年后就过时了。所以比起记住某个具体超参数更重要的是理解这个recipe里每一个决策背后的动机和取舍逻辑。这份能力才是真正能迁移到下一个模型、下一个项目上的资产。如果你也准备动手复现MiMo V2.6别急着直接上全量数据。我自己的习惯是先拿几百条数据跑通整个流程确认环境和代码没问题再逐步放开数据规模和训练时长。这个过程听上去慢但实际省时间多了——至少不会在训练了十几个小时后才发现数据处理阶段就埋了雷。希望这篇解读能帮你节省一些摸索时间。