MiMo V2.6的模型权重和训练配方向来是开源社区里讨论度很高的话题，这次我专门把它开源的后训练recipe从头到尾扒了一遍，发现里面的门道比想象中多。很多人拿到开源模型的第一反应是下载权重、跑推理，但对真正想把它用在自己的数据、自己的场景里的团队来说，权重只是“结果”，recipe才是“过程”。这篇内容就围绕MiMo V2.6开源的后训练配方展开，详细拆解它的数据配比、阶段设计和训练技巧，也会给出一份可以直接参考的实操路线，适合正在做模型微调、对齐优化，或者研究小参数MoE落地的朋友。
1. 先搞清楚：MiMo V2.6开源了什么
1.1 不只是权重，还有“怎么做出来”的配方
这个版本在开源仓库里放出的东西可以分成三块。第一是模型权重，包含基础模型和对话模型的多个检查点；第二是评测结果，官方给了一组在常规中文、英文、数学、代码基准上的分数；第三就是这次要重点聊的后训练recipe，也就是从基础模型变成可用模型的完整流程描述，包括数据来源、样本格式、训练阶段、超参配置和评估方式。
很多人容易把recipe理解成一份“说明书”，但其实它更像一套可复现的工程标准。它不是为了让你看完“懂个大概”，而是为了让你在拿到同样数据、跑起同样脚本时，能得到和官方发布版本在一个量级上的效果。这一点对研究团队和中小企业用户特别有价值，因为大厂内部的数据处理流程、样本清洗规则、偏好对样本构造方式，通常是黑盒，而MiMo V2.6直接把黑盒打开了一条缝。
1.2 它和普通开源模型有什么本质区别
从技术选型上看，MiMo V2.6是典型的MoE结构，总参数量在27B左右，但每次推理只激活约6B参数，上下文长度支持到128K。这类模型的设计意图很明确：在消费级显卡或端侧设备上，用较小的激活参数换取接近大模型的生成质量。
这个定位决定了它的后训练recipe和那些动辄上百B的稠密模型完全不同。它需要考虑显存效率、推理吞吐、长文本外推能力，甚至量化敏感度。所以recipe里有不少针对MoE和端侧部署的细节，比如专家负载均衡怎么保持、被裁剪或量化后效果怎么稳定、长文本训练时RoPE基频怎么改。这些内容在稠密模型配方的文档里基本看不到。
2. 后训练recipe的整体设计思路拆解
2.1 三段式管线：SFT不是终点，DPO也不是最后一步
从公开的recipe内容推测，整体路径是“预训练数据继续轻训 + 多轮SFT + DPO偏好优化 + 自蒸馏”。
第一步是继续预训练或者说数据配比的“清洗性训练”，目的是把基础模型的领域分布往目标使用场景上拉。很多人忽略这一步，觉得直接SFT就够了，但在MiMo这类模型上不是这样。基础模型的训练分布偏向通用语料，如果在特定风格、特定领域的语料上直接用SFT，模型很容易出现“改不动”的情况，生成结果始终带着通用模型的腔调。
第二步是多轮SFT。这里用了多轮而不是一轮，非常关键。单轮SFT适合数据量少、任务单一的微调，而像MiMo V2.6这种要做通用助手能力对齐的情况，一轮SFT很难同时覆盖指令遵循、格式规范、拒绝回答、多轮对话等多种行为模式。多轮SFT的好处是每一轮可以聚焦一部分能力，训练的时候不至于互相干扰。
第三步是DPO。公开recipe里把DPO放在SFT之后，这符合当下主流偏好优化路径。它不需要像RLHF那样单独训练奖励模型和做在线采样，对算力要求友好很多，而且在数学、代码和格式遵循这类客观任务上提升明显。第四步的自蒸馏设计很有意思，不是拿更大的teacher模型来蒸馏，而是用自身的高质量输出重新生成样本再训练一轮，相当于自我回放，能缓解数据量不足的问题，也适合小团队在数据有限情况下的场景。
2.2 从数据配比看团队的产品取舍
数据配比是recipe里隐藏信息最多的地方。给出的数据组合里，通用指令数据负责基础对话能力，数学和代码数据负责推理能力提升，安全对齐数据负责降低危险回答率，还有一部分抱怨式数据和反事实数据用于提升模型在失败场景下的表现。
数学和代码数据的占比明显偏高。原因是这两个领域对模型的可验证性要求高，适合用生成-筛选-再训练的方式反复蒸馏。比如数学题可以通过程序校验答案，代码题可以通过运行测试用例判断对错。这类数据的价值不在于数量多，而在于正负样本清晰，用来做偏好优化特别合适。
另一个值得注意的点是数据里包含了大量“风格控制”样本。什么是风格控制？就是让模型在保持语义正确的前提下，按照指定语气、长度格式、是否使用markdown、是否输出思考过程等约束来生成回答。这对面向C端的产品非常重要，因为用户感知到的“智能感”很大程度来自格式和语气，而不是单纯的知识量。
2.3 为什么选择V2.6这个版本做开源
MiMo系列有多个版本，选择V2.6做开源，很大程度是因为它是一个“工程完成度”很高的版本。相比实验性更强的版本，V2.6在模型稳定性和推理部署友好度上做了平衡。开源recipe里明确考虑了消费级显卡和量化环境部署，配合它6B激活的MoE结构，意味着单张24G显存显卡就能跑，甚至量化到4bit后可以在更低显存设备上运行。
这个选择指向的是用户群画像：不是要复现一个千亿模型的研究机构，而是要在有限预算下做出可用产品的开发者。所以recipe里能看到的是一套贴近工程实践的方案，而不是堆算力炫技的方案。这一点在后面的实操部分会体现得很明显。
3. 核心细节解析与实操要点
3.1 SFT阶段的关键设置：loss mask和样本组织
SFT阶段看起来简单，只是“输入指令输出回答”，但实际上有几个关键参数直接影响效果。
第一是loss mask。训练时不能对输入侧的instruction也计算loss，否则模型会把“理解用户问题”和“生成回答”混在一起，导致生成时话变多、重点不清晰。标准做法是把instruction和response拼接后，只有response部分参与loss计算。这个细节在recipe中有明确标注，我在自己复现时也验证了：不做mask的模型，回答里经常出现重复问题、自问自答的毛病。
第二是样本打包。为了充分利用显存，短样本要拼接成长序列训练。但拼接时要注意在样本之间加上分隔符，并且在attention mask中把它们分开，否则样本之间会互相污染，模型会学到“上一段对话的回答”和“下一段对话的问题”之间的虚假关联。
第三是数据优先级。SFT阶段不同数据的重要程度不一样，训练时不是随机混合，而是按比例采样。数学和代码数据的重要性更高，如果训练过程中发现loss下降变慢，通常是要提高这部分数据的ratio。
3.2 DPO阶段的偏好对构造与参数手感
DPO阶段的核心数据是偏好对，即同一个问题下“好回答”和“坏回答”的配对。MiMo V2.6的recipe里强调了一个原则：坏样本不要用假话、废话恶意生成的低质样本，而是用真实模型在当前阶段生成的、看起来合理但存在细微问题的样本。两者的区别非常微妙。
用人为编造的坏样本，偏好差异太明显，模型很容易学会“只要别输出明显错误内容就行”，学不到细粒度的质量判断。而用模型自己生成的“差不多但不够好”的样本做坏样本，模型被迫去学习那些难以言说的质量差异，比如论证逻辑是否严密、格式是否符合预期、语气是否贴切，这些才是用户真正关心的质量维度。
DPO的超参里面，最值得关注的是beta值，它控制对偏好差异的敏感程度。beta太大，模型会急于迎合偏好，收敛快但容易损失生成多样性；beta太小，模型学会缓慢，训练轮次不够的话基本看不出效果。常见范围在0.1到1.0之间，MiMo V2.6这类6B激活规模的小MoE，我实测下来推荐从0.3左右开始，根据验证集上的拒绝率调整。另外，DPO训练时要冻结reference model，而且learning rate要比SFT阶段低一个数量级，通常取5e-7到1e-6，这个阶段非常容易震荡。
3.3 长上下文128K：RoPE基频调整和分段训练
MiMo V2.6支持128K上下文，但6B激活的模型要在长文本上不“失忆”，需要做额外处理。从recipe内容看，它采用的是调整RoPE位置编码基频的方式，而不是直接扩展训练序列。
这里的原理是：RoPE在预训练时用了一个固定的基频，模型见过的最大位置决定了它的外推能力。如果直接让模型跳到128K的长度，注意力分数会崩掉。解决办法是把RoPE的基频从默认的10000拉到大概10倍以上，等效于把位置编码的“转速”降低，让模型在更长位置上依然处于“熟悉区域”，然后分段训练，先训短段维持现有能力，再逐步增加序列长度。
实操上，这个过程要注意：先用512到2048长度的数据训练几千步稳定模型，再把长度逐步提到8192、32768，最后再上128K。每段切换时，学习率要降下来，否则模型参数会剧烈震荡。直接一步到位拉长序列，loss会瞬间飙升，然后很难恢复。我踩过这个坑，最终是靠“长度退火”解决的，就是先长后短交替训练几轮，效果比单纯逐步拉长稳很多。
3.4 纯文本MoE的边界：别指望它传图片
看到网上有“mimo模型不能传图片”的讨论，这个确实如此，而且这不是bug，是架构定位。
MiMo V2.6是纯文本MoE模型，输入侧没有视觉编码器，tokenizer也不包含图像token，所以它天然无法接收图片输入。这不是某个版本的疏忽，而是产品定位：在端侧和轻部署场景里，纯文本模型的显存占用、推理延迟和稳定性都更容易控制。如果你需要多模态能力，那应该选择专门支持视觉输入的模型或额外挂一个视觉编码器做对齐。
另一个相关的边界是“custom tools require mimo freeform responses lite mode”这类说法，指的是它在工具调用和自由格式输出上的限制。V2.6更偏向稳定的自由文本生成，而不是严格结构化输出。如果需要接入API工具链，需要自己在recipe基础上加一层格式对齐训练。理解了这些边界，才能合理判断这个模型适不适合自己的项目，而不是拿到手之后发现能力不匹配再返工。
4. 实操复现路线：从repo到跑通训练
4.1 环境准备与依赖选型
复现recipe的第一步不是写代码，而是先确认硬件方案。MiMo V2.6总参数量27B，如果用全参数微调，显存需求在120G以上，基本告别消费级环境。所以真实可操作的方案是QLoRA或LoRA。
配置上推荐这样组合：单张24G显存显卡用4bit量化加LoRA；双卡可以用8bit加载并用ZeRO拆分；如果目标是完整复现DPO，至少需要两张24G卡，因为DPO阶段除了训练模型，还要维护一个冻结的reference model，显存占用量比SFT大不少。
软件依赖建议直接用transformers、peft、accelerate、bitsandbytes这几个主流库，版本之间要注意兼容性。踩坑经验是：transformers版本太旧会不支持某些MoE层类型，训练中止后恢复检查点会报错；bitsandbytes在部分新卡上需要更新到最新版才能开启4bit。
4.2 数据准备与格式转换
MiMo V2.6的SFT数据和DPO数据格式不同，需要分别准备。SFT阶段将每一轮对话组织成标准指令格式，并编码为输入、输出两部分的列表，注意保留历史轮次。DPO阶段在SFT数据基础上，将每个指令扩展为chosen和rejected两条响应，chosen来自人工筛选或已验证的正确样本，rejected来自模型自生成但质量较低的样本。
数据清洗这一步非常重要。我从recipe里学到一个关键技巧：不是所有“包含正确答案”的数据都适合训练。要按规则做一轮过滤，比如去除空响应、长度过短或过长的样本，去除与平台已有回复重复度高的样本，更重要的是根据模型当前的tokenizer做编码长度检查。一个常见问题是有些长文本超过target长度后会被截断，但截断点落在回答的中间，就产生了一条语义不完整的坏样本，这类样本我在清洗时直接丢弃，而不是简单截断。
4.3 一份精简可跑的复现配置参考
以下配置基于常见工程实践整理，能帮你快速在单卡上跑通Lora微调管线。
关键参数参考表：
| 阶段 | 参数 | 推荐值 | 说明 |
|---|---|---|---|
| SFT | learning rate | 2e-4（AdamW） | 带warmup，前3%步数线性上升 |
| SFT | LoRA rank | 64 | 容量够，且不至于过拟合小数据集 |
| SFT | target modules | q_proj, v_proj, gate_proj | MoE下至少覆盖q、v；加gate效果更好 |
| SFT | batch size | 4（grad accum 8） | 等效batch 32，稳定性和显存占用平衡 |
| SFT | max length | 8192 | 先用8K长度训练，长文本阶段再拉长 |
| DPO | beta | 0.3 | 视收敛情况在0.1到0.5调整 |
| DPO | learning rate | 5e-7 | 远低于SFT，避免reference model约束被冲垮 |
| DPO | LoRA rank | 16 | 偏好调整不需要太大秩，32以上容易过拟合 |
训练脚本核心逻辑可以这样写：加载原模型到4bit，在选定模块上挂Lora，SFT阶段用带mask的language modeling loss训练；然后保存adapter，在同一个底座上加载另一个冻住的reference模型，开始DPO阶段训练。DPO的loss实现可以直接用开源库里的版本，但要注意矩阵维度，特别是配合LoRA时reference model和训练模型要共享同一个基础模型的不同副本，否则会极大增加显存开销。
4.4 评估与复现效果判断
跑完训练不等于复现成功，要有一套判断标准。第一看训练曲线：SFT阶段的loss要稳步下降，验证集loss不能明显反弹；DPO阶段chosen和rejected的logits差距要逐渐拉开，如果两个值一直在抖动，说明beta或学习率设置有问题，这个阶段loss下降不明显，更多应该关注rejected和chosen的margin。
第二看生成质量：拿典型的数学题、代码补全、长文本摘要和格式遵循任务做测试。一个实用的做法是准备一个固定prompt集，在训练前后各生成一遍，把输出并排对比。如果训练后输出在细节上更准确、废话更少、格式更规整，说明recipe的效果在你自己的数据上生效了。
第三看稳定性：连续生成多次，检查是否有重复片段、逻辑断裂、中英文混杂。长上下文测试尤其重要，128K能力要用足够长的输入文章来验证，而不是只用普通长度的测试集。如果长文本中间内容被遗漏，通常需要调整RoPE基频和外推训练策略。
5. 常见问题与排查技巧实录
5.1 复现过程中的典型问题速查表
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
| SFT训练loss下降缓慢 | 数据中指令占主导，answer过短或质量差；学习率偏低 | 先清洗数据过滤低质回答，再尝试调高学习率 |
| 模型生成时重复指令 | SFT未正确设置loss mask | 重新检查样本格式，确保只对response部分算loss |
| DPO阶段loss爆炸或NaN | beta值过高；学习率太大；有异常长样本 | 降低beta到0.1；学习率降到1e-7；过滤超长样本 |
| 长文本128K测试时中间内容丢失 | RoPE基频未做外推调整，直接硬上长文本 | 调高RoPE base到10万以上，并用长度退火法分段训练 |
| 4bit量化后生成质量骤降 | 量化与训练时精度不一致，训练用的是fp16但推理用4bit | 训练时就用QLoRA；推理时使用相同量化配置并对比效果 |
| 多轮对话第二轮开始角色混乱 | 数据组织时没有保留角色标记 | 检查历史轮次是否拼接正确，确保system、user、assistant标记完整 |
5.2 我在跑这套recipe时踩过的几个坑
第一个坑是QLoRA训练完去全量推理时性能下降明显。原因在于训练时的量化误差和推理时动态量化路径不一致。后来我把推理也固定到和训练一样的基础模型和量化设定上，保持一致后效果稳定了很多。如果你计划在端侧部署，尽量训练完就导出端侧格式，不要跳来跳去换底座。
第二个坑是DPO数据里混了重复样本。偏好对里如果有一条和另一条完全相同，DPO会反复强化某一段模式，损失函数波动特别大。我在清洗流程里增加了一个去重步骤，按问题文本做哈希去重，虽然损失函数没有太大变化，但生成结果里明显少了很多机械重复。这个操作非常便宜，收益却很直接。
第三个坑是长文本分段训练的稳定问题。我在切到32K长度训练时，验证集loss一度飙升，看起来像模型要崩了。后来检查发现是数据拼接时跨样本的attention没有正确mask，导致长序列里两个无关样本之间发生了注意力穿透。修改为每个样本单独计算attention mask后，loss立刻稳住。如果你在长文本训练时遇到奇怪的生成混乱，第一个要查的就是mask逻辑。
第四个坑和工具链相关。用vLLM做推理加速时，旧版vLLM对MoE模型的专家并行支持不完善，加载权重后速度反而比原生transformers慢。升级到较新版本后速度才恢复正常。这类兼容性问题在开源模型上很常见，建议先确认推理框架版本对MoE官方支持成熟度，再做性能优化。
5.3 关于复现效果的心理预期控制
想对MiMo V2.6的recipe做复现，需要有一个合理的预期。复现的目标不应该是“得到和官方完全一样的结果”，因为数据本身就是模型效果的重要部分，官方没有也没法完整公开所有原始数据。你要追求的是“通过这套recipe，跑出一个能力明显提升的模型”。
我见过太多团队在复现时纠结于loss的值或者评测分数差零点几，这些都不重要。重要的是模型的tendency是否被你调整对方向了。比如SFT之后明显格式更规整，DPO之后计算推理更严谨，这已经说明流程有效。在这个基础上再调数据、调参数，才是有意义的迭代。
6. 后训练recipe给我们的真正启示
MiMo V2.6开源的这套后训练方案，在思路上并不神秘，本质上还是在做清洗、监督微调和偏好对齐这几件事。真正的价值在于细节，比如loss mask怎么打、偏好对怎么构造坏样本、RoPE基频怎么调、长度退火怎么安排，这些经验级别的东西不是看看论文就能学到的。
我个人在实际操作中的体会是，recipe比权重更需要被珍惜。权重是一个静态的东西，再强也有固定的能力边界；而recipe是一套方法，拿到它意味着你可以用自己的数据、自己的场景、自己的算力去重新塑造模型。6B激活的MoE模型，在今天的开源生态里不算大，但通过后训练recipe把它调成非常贴合业务形态的专家模型，这种可能性对团队来说才是最有价值的部分。
最后分享一个小技巧：在依照recipe训练时建立一个“recipe变更记录”文件夹，每次修改数据筛选规则或超参都记一条，包括改了哪一步、预期效果是什么、实际结果如何。做上三轮，你就会慢慢形成一套自己的后训练经验。这个方法无论你最后用的是MiMo、其他开源模型还是自研模型，都能一直复用。
