小米的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仓库的顶层结构，通常会有这么几块：

打开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 80G，per_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里用了DPO（Direct Preference Optimization）作为核心偏好优化算法，这一点我比较认可。相比于传统的RLHF（基于强化学习的从人类反馈优化），DPO不需要单独训练奖励模型，也不需要在线采样和后置策略更新，实现简单、训练稳定。

DPO的核心是让模型在偏好数据上拉开差距：给定同一个prompt，有一条被偏好的回答（chosen）和一条不被偏好的回答（rejected），训练目标就是增大chosen的概率、减小rejected的概率，同时用KL散度约束不要让模型偏离参考模型太远。这里有两个关键超参数：beta（KL约束强度）和参考模型（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和DPO，MiMo 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 环境准备清单

先列出我复现时的环境，给大家一个参考：

依赖安装这块，我的经验是不要直接用最新的版本。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方法配合batched=True，在加载数据的同时完成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模板和采样参数。同一个模型，temperature=0.1和temperature=0.7的成绩会差很多，few-shot还是zero-shot也会显著影响结果。MiMo的repo里评测脚本是固定的，直接跑就好，不要自己乱加prompt工程。

但我要强调一点：基准分数只是一个参考维度。实际对话体验、对特殊指令的遵循度、回答风格的一致性，这些也需要人工评估。我在复现时常常挂一个简单的脚本，随机抽100条问题，用同一服务端跑模型并保存日志，快速浏览模型在开放式问答上的表现。这样能发现基准测试覆盖不到的“歪”现象，比如模型总喜欢用“好的，我来帮你分析一下”这样的开场白——基准分看不出来，但用户反馈一定很难受。

5. 实操中的常见问题与排查技巧

5.1 训练过程中loss突然冲高

这大概是所有复现工程中最高频的问题。我的排查顺序如下：

1. 检查数据格式。有没有样本只包含assistant回答，但没有对应的user输入？有没有response内容为空？这些异常样本会直接把loss拉高。
2. 检查学习率。如果warmup结束后的初始学习率偏高（比如超过3e-5），可能在训练前期就出现loss上涨，这时把learning rate调低重新跑。
3. 检查attention mask。如果packing时没有做正确的mask，模型会看到下一个样本的内容，loss平均值也会受影响。
4. 检查梯度累积步数。累积步数大时，loss display的频率设置不好，你看到的loss其实是好几个step的平均，波动看起来会比实际更夸张。

5.2 评测分数跟官方对不上

这种问题几乎人人都遇到过。我总结几个最容易出偏差的地方：

另外，有些评测集本身对模型输出格式非常敏感。MiMo的模型如果开了“思维链”选项，评测模板里可能要做相应处理，否则分数就会偏低。这些问题都能靠“直接用官方评测脚本+官方采样参数”规避。

5.3 模型“变笨”了：丢掉通用能力怎么办

复现recipe之后，我发现模型在目标数据上确实变强，但在一些通用能力上（比如常识问答、开放生成）有退化。这不一定是你的训练出了问题，而是后训练的通病——模型把自己的“注意力”放在训练分布上，对分布外的内容回应变差。

缓解方法有这么几个：一是加大通用数据的配比，二是保留一部分“原始数据”做遗忘补偿（比如在DPO数据里混入原始SFT样本），三是降低学习率和epoch数。我从MiMo V2.6的recipe里看到，它的数据配比表里特别标注了“通用能力保持数据”的占比，这个设计思路挺值得学习。它就是在SFT数据里专门留出一部分任务无关的语料（新闻、百科、博客），用来抵消其他任务数据带来的分布偏移。

5.4 训练资源不够：能用单卡复现吗

前面说过，MiMo V2.6的7B模型用单卡跑是可能的，但需要接受几个妥协。我给的参考配置是：RTX 4090 24G，per_device_train_batch_size=1，gradient_accumulation_steps=64，这样有效batch size也能到64左右。配合4bit量化（QLoRA）之后，显存占用可以压到15G以内，但量化训练和bf16训练的数值行为有差异，效果可能略有折损。

另一个省资源的技巧是用LoRA（低秩适配）。在recipe的config里，模型用LoRA训练时只需额外保存几MB适配器权重，合回base模型即可。MiMo的repo里对LoRA的rank和target_modules有预设配置（一般是rank=128，覆盖全部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，别急着直接上全量数据。我自己的习惯是：先拿几百条数据跑通整个流程，确认环境和代码没问题，再逐步放开数据规模和训练时长。这个过程听上去慢，但实际省时间多了——至少不会在训练了十几个小时后才发现数据处理阶段就埋了雷。希望这篇解读能帮你节省一些摸索时间。