1. 为什么大家都在聊 MiMo V2.6 的后训练配方
最近开源圈子里讨论最多的模型，除了各种小尺寸“卷王”，就是小米开源的 MiMo V2.6 了。我留意到一个很有意思的现象：很多人拿到权重文件后，第一反应是赶紧跑一下推理、测测中文能力，但真正让这个模型有价值的，其实是它随模型一起放出来的后训练 recipe——也就是从基础模型锻炼成最终可用模型的那整套“训练菜谱”。
说白了，模型开源这件事，权重只是结果，recipe 才是过程。MiMo V2.6 的开源后训练配方里包含了数据配比、训练阶段划分、超参设置、评估策略这些关键信息。如果你只是拿它来跑推理，那相当于只看到了成品菜；如果你仔细研究 recipe，等于拿到了后厨的完整操作手册，可以复现、可以借鉴、甚至可以按自己的数据改造它。
这篇文章我想以一个做过几年模型训练、踩过不少坑的从业者视角，把 MiMo V2.6 开源后训练 recipe 里那些值得琢磨的细节拆开来讲。适合谁看？打算自己微调大模型的算法工程师、做 LLM 训练的 Researcher、还有对开源模型“知其然也想知其所以然”的技术爱好者。我会尽量不堆术语，把背后的逻辑讲清楚。
2. MiMo V2.6 后训练 recipe 的整体设计思路
2.1 从基础模型到可用模型，中间隔着一整套后训练
预训练得到的基础模型，本质上只是一个“语言统计引擎”，它知道词怎么接下去最通顺，但不一定知道怎么听指令、怎么拒绝有害请求、怎么用工具。要让基础模型变成真正可用的对话助手，靠的就是后训练（post-training）阶段。
MiMo V2.6 的 recipe 把后训练分成几个清晰的阶段：继续预训练（CPT）、监督微调（SFT）、偏好对齐（DPO/SimPO 类算法）、以及安全与能力评估。这个划分并不稀奇，但有意思的是它每个阶段的具体做法——数据怎么配、样本怎么组织、超参怎么选，这些细节才是 recipe 的含金量所在。
2.2 一个很务实的取舍：通用与垂直能力兼顾
看 MiMo V2.6 的 recipe，我最大的感受是它非常“务实”。它不是那种堆了超大训练数据、烧了几百万卡时的大厂炫耀型方案，更像是在有限算力下做了很多精细设计的工程方案。它兼顾了通用能力和中文场景下的特定能力（比如代码、数学、推理），同时没有放弃长上下文和工具调用这些现代模型必备的能力。
这种取舍不是随便定的。我自己的经验是，在训练预算固定的前提下，什么数据都想要的结果往往是什么都做不好。MiMo V2.6 的策略是分阶段、分主题地让模型逐项掌握能力，而不是一口气把所有数据混在一起“大乱炖”。
2.3 开源 recipe 对社区的价值远超权重本身
我之前复现过一些只给权重不给 recipe 的开源模型，那个过程非常痛苦。你只能靠猜：它用了什么对话模板？数据是什么格式？学习率是多少？这些信息缺失，你想在此基础上做领域微调，就得自己从头试，成本很高。
MiMo V2.6 把 recipe 完整开放，等于给了社区一条“从零到一”的路径。你可以拿它的 recipe 做三件事：
- 完整复现：照着跑一遍，理解每个阶段的目的和效果。
- 改造适配：换掉部分数据，保留训练框架，适配自己的垂直场景。
- 学习借鉴：哪怕你不训练 MiMo，也可以把它的数据配比、阶段设计思路迁移到其他模型上。
这个价值，比权重文件本身大得多。
3. 核心细节拆解：数据、阶段与超参
3.1 数据配比：一份好的训练食谱，关键在于“比例”
看一个后训练 recipe，我第一个关注的点永远是数据配比。MiMo V2.6 的数据构成大致包含这几类：通用指令数据、代码数据、数学推理数据、长文本数据、以及安全对齐数据。
每个类别不是平均分配的。从 recipe 中能看出，代码和数学推理数据占了相当大的比重，这说明模型的重点能力方向就是推理密集型任务。通用对话数据保证基础交互能力，但占比反而相对克制。这个思路我认为是对的——在模型容量有限的情况下，与其让它在“今天天气怎么样”这种问题上过度优化，不如多花数据在真正有门槛的任务上。
我建议你在设计自己的数据配比时，别直接照抄 MiMo 的比例，而是根据你的目标场景调整。比如你要做一个法律问答助手，那你的法律领域数据占比就应该远高于通用代码数据。但可以参考它的“分层设计”思路：先保证通用能力兜底，再重点强化目标能力。
3.2 训练阶段划分：CPT、SFT 与对齐的顺序逻辑
MiMo V2.6 的后训练流程里，几个阶段的顺序很有意思。它没有一上来就做对齐，而是先做了继续预训练（CPT），用一部分高质量数据让模型在特定领域“再多读点书”，然后才进入有监督微调，让模型学会对话的格式和指令跟随能力，最后做偏好对齐，让模型的回答更符合人类的偏好。
这个顺序背后的逻辑是：先让模型学会知识，再让模型学会对话，最后让模型学会取舍。如果顺序反了，先对齐再补知识，对齐阶段学到的东西很可能在补知识的时候被破坏掉。我自己在训练过程中碰过这个问题，补完领域知识后模型突然不爱遵守指令了，后来才意识到就是对齐和知识注入的顺序没安排好。
3.3 关键超参笔记：学习率、批量大小与训练轮数
recipe 里超参部分也是干货很多的地方。根据我自己复现类似规模模型的经验，MiMo V2.6 使用的学习率应该是比较保守的——后训练阶段如果学习率设置太高，模型会在微调过程中“遗忘”预训练阶段学到的通用知识，这也就是所谓的灾难性遗忘。一般后训练的学习率会设置在预训练阶段的十分之一甚至更低。
批量大小方面，后训练阶段通常不太追求超大 batch，而是更在意梯度更新的稳定性。训练轮数（epoch）通常不会太多，一般 1 到 3 轮，多了容易过拟合到指令数据上。MiMo V2.6 的做法是典型的“少而精”——数据质量高，所以不需要反复看太多遍。
我给一个我自己常用的排查思路：如果微调完模型在通用能力上掉点明显，先看是不是学习率太高、训练轮数太多；如果模型该学的没学会，再看是不是数据量不够、数据格式有问题。
3.4 长上下文与工具调用能力的训练技巧
MiMo V2.6 在长上下文和工具调用这两个能力上花了不小的功夫。长上下文问题在于，模型在预训练阶段见过的序列长度有限，后训练突然让它处理几千甚至上万 token 的内容，很容易“晕”。recipe 里的做法一般是：用渐进式序列长度训练，从短到长逐步增加，而不是直接一步到位。
工具调用能力则依赖高质量的数据。模型需要学会“什么时候该调用工具、怎么把参数格式化传出去、拿到工具返回结果之后怎么整合进回答”。这类数据如果纯人工编写，成本极高；MiMo 的 recipe 大概率使用了一定的合成数据和规则化生成手段。我自己做工具调用的经验是，格式一致性极其重要。如果训练数据里工具调用的格式五花八门，模型学出来的结果就是时灵时不灵。
4. 实操过程：从拿到 recipe 到完整复现
4.1 环境准备与基础配置
如果你想把 MiMo V2.6 的 recipe 完整跑一遍，第一步肯定是准备环境。我假设你用的是比较标准的 PyTorch 生态，搭配 DeepSpeed 或 FSDP 做分布式训练。显存方面，说实话，跑这种规模的模型，没有 8 卡 A100 级别的资源会比较吃力，毕竟模型本身是稠密 MoE 架构里的“大家伙”。
环境配置上，我建议先确认以下组件版本匹配：
- CUDA 版本与 GPU 驱动匹配。
- PyTorch 版本与其分布式组件匹配。
- Transformers 或 Megatron 类训练框架版本与模型代码兼容。
- 数据加载与预处理流程与 tokenizer 版本一致。
一个我踩过的坑是 tokenizer 版本不一致导致数据预处理结果不同。哪怕是同一个模型，tokenizer 换了版本，结果也可能对不上。复现之前一定要锁定 tokenizer 版本。
4.2 数据准备与格式化
Recipe 里给出的数据格式通常已经被预处理成统一的对话格式，比如用 Chat Template 组织成的多轮对话 JSON。你需要做的第一步是把原始数据清洗、过滤、去重，然后转成模型训练代码能直接读取的格式。
我自己的做法是写一套数据预处理管道，包含几个关键步骤：
- 清洗 HTML 标签、乱码、异常字符。
- 过滤低质量样本（比如长度过短、重复度过高、包含大量无意义符号）。
- 去重，尤其是代码数据里重复率很高的问题。
- 按 recipe 要求的对话模板重新组织样本。
- 统计 token 长度分布，确定合理的 max length 设置。
数据质量我始终认为是后训练效果的第一决定因素。模型效果不好，很多人第一反应是调超参，但我见过太多问题其实是数据没弄干净。同一个数据，清洗前后效果可能天差地别。
4.3 分阶段训练的执行要点
执行完整后训练流程时，我建议严格按 recipe 的阶段顺序来。每个阶段之间要保留检查点，方便回溯。比如发现 SFT 之后模型效果反而变差了，至少你能回到 CPT 结束的状态重新调整。
一次完整训练下来可能要跑很久。我的经验是，不要全程“放养”，而是设置多个中间评估点。每训练一定步数就在验证集上跑一次评估，看 loss 曲线和具体能力指标。如果发现异常，及时止损，别等跑完了才知道崩了。
4.4 评估：训练过程中的“仪表盘”
Recipe 里通常还会包含评估方案，这是很多人忽略的部分。训练过程中必须有一套能够快速反馈的评测集，不需要太大，但要能代表目标能力方向。比如代码能力、数学能力、指令跟随能力，各准备一组小样本，训练过程中定期跑。
需要注意的是，训练集里的数据有时候会“漏进”评测集，导致评估结果虚高。我在实际工作中踩过大坑，后来专门写了一套查重逻辑，确保训练数据和评测数据之间没有重叠。这一步虽然麻烦，但非常必要。
5. 常见问题与排查技巧实录
5.1 数据泄漏问题：评估结果虚高的“隐形杀手”
数据泄漏在后训练里比预训练更隐蔽。因为后训练数据很多来自公开数据集，这些数据集里的样本可能已经在各种评测集里出现过。模型见过答案再去考试，成绩自然好看，但这没有任何实际意义。
我的排查经验是：在构建训练集之前，先跑一遍与常用评测集的哈希对比，或者用 embedding 做相似度筛选。至少要做到和评测集的精确匹配去重。更进一步，还可以检查训练数据里有没有和评测题目“语义等价”的样本——这个难度高一些，但对评估可信度的提升很明显。
5.2 训练不收敛：先查数据，再查超参
如果训练过程中 loss 不降、指标不动，我的第一反应不是调学习率，而是检查数据。最常见的问题无非几种：标签错位、数据格式不一致、样本顺序被意外打乱、或者是数据预处理时 token 数量超过模型上限导致截断异常。
我自己遇到过一个非常隐蔽的问题：多轮对话数据中，某个角色的 token 被意外重复插入，导致整个对话上下文语义被污染。这种问题从单条样本看很难发现，但累积起来对训练影响很大。建议写几个数据抽样可视化工具，随机抽几条样本直接打印出来看。
如果数据检查完没问题，再考虑调整超参。优先动学习率和 warmup 步数。
5.3 灾难性遗忘：如何让模型“学了新知识不忘旧能力”
后训练过程中最常见的问题就是灾难性遗忘——模型在垂直领域变强了，但通用对话能力变弱了。这是因为后训练数据分布与预训练数据分布差异太大，模型在优化新目标时把旧知识覆盖掉了。
recipe 里应对遗忘的手段一般是两类：一是把一部分通用数据混入后训练数据，让模型在学新知识的同时“复习”旧知识；二是控制学习率和训练轮数，避免过度优化。如果你发现遗忘严重，我建议先检查是不是学习率太高。我自己常用的做法是把通用数据按一定比例混进来，这个比例视场景而定，一般 10% 到 30% 之间。
5.4 工具调用格式混乱：从数据侧根治
工具调用微调后出现格式不稳，十有八九是训练数据格式不一致。模型对“调用工具”这件事的本质理解，其实是纯粹的序列生成模式匹配。训练时格式百花齐放，模型就只能学到一个模糊的模式，自然做不好。
我的经验是：训练数据里工具调用的格式必须严格统一。比如函数名怎么表示、参数怎么传、JSON 里 key 的顺序是否固定、返回结果怎么包裹，这些都要有明确的模板。只有格式一致，模型才能稳定地学会“什么时候该调工具”和“怎么调工具”这两件事。
5.5 一个容易忽略的坑：评估指标与训练目标错位
还有一次我做微调，训练时用的是一个指标，评估模型好不好用却用了另一个指标。结果训练过程显示 loss 一直在降，但人工体验下来完全不对味。后来复盘发现，训练目标优化的方向和评估指标衡量的重点不一致，导致模型在“错误的方向上精益求精”。
这个教训让我养成了一个习惯：先定义清楚“什么表现算好”，再设计训练方案。训练目标和评估指标应该是闭环的——你最终想达到什么效果，训练过程中就围绕什么效果去优化。
6. 个人实操体会与扩展建议
把 MiMo V2.6 的 recipe 完整吃透之后，我最大的体会是：开源模型的价值不仅在于你“用什么”，更在于你“怎么学”。很多人在社区里讨论的是它的跑分、它的推理速度，但对真正想自己做模型的人来说，更值得研究的是它为什么要这样设计数据配比、为什么这么多阶段按这个顺序走、为什么超参取这些值。
复现一个开源 recipe，比自己从零设计训练方案要省力得多，但前提是你要能看懂每一步背后的意图。否则一不小心就变成了“照着做但不知道为什么这么做”，遇到问题时无从下手。
最后再说一个扩展思路。如果你不打算完整训练 MiMo V2.6，只想借用它的 recipe 做小规模实验，可以先裁剪模型尺寸或者缩短训练序列长度，在小算力环境下跑通流程，验证数据管道、训练代码、评估流程都没问题之后，再上全量资源跑正式训练。这样能省不少时间和钱，也能避免拿着大资源直接跑结果发现数据问题，白白烧了一堆卡时。
模型训练这件事，踩坑在所难免。但有了像 MiMo V2.6 这样把 recipe 完整敞开的项目，至少我们能少走很多弯路。
