翻开一个开源模型的repo我第一件事通常不是跑benchmark而是翻它的后训练recipe。benchmark分数是结果recipe才是过程。分数只能告诉你这个模型“值不值得用”recipe才能告诉你它“为什么能到这个分数”以及这套方法你能不能搬到自己项目里。这次要拆的是小米最近放出来的MiMo V2.6重点放在它的开源后训练配方上结合中文长文本、移动端部署、6B小参数这些词一起看希望能帮你理清楚一个开源模型在能力上做取舍的时候训练链路到底是怎么设计的。如果你团队里正在做模型压缩、端侧部署或者想复现一套中文长文本后训练流程这篇内容应该比看官方release note更实在一些。我会尽量按工程复现视角来讲哪些地方直接能用哪些地方需要自己补也都会点出来。1. MiMo V2.6的recipe到底在解决什么1.1 先看定位这是一个“能塞进手机但还能答辩”的模型MiMo V2.6不是一个从头训练的模型这一点尤为重要。它是以Qwen系模型作为基座通过蒸馏和后训练得到的紧凑模型主打中文能力和长文本能力。几个型号里最让人注意的就是那个6B级别的版本——并不是原生7B而是从更大基座压下来的。这个“从大到小”的过程决定了它的后训练配方和从头训练或者常规微调是完全不同的路子。在长上下文方面V2.6支持超长输入官方放出的公开成绩里C-Eval得分达到80.72CMMLU是79.42BMC_GAOKAO是73.83在同类体量模型里算相当能打的。一个6B模型能拿到这个数字说明后训练阶段的配方起到了决定性作用——不是基座强就有这结果而是在压缩的过程中没有把知识和能力丢掉。我在测评它的时候感受比较深的一点是这个模型在“中文知识问答”和“长文档理解”这两个场景下表现接近不少13B甚至更大的模型。这在端侧小模型里并不常见。而这一切的基础恰恰是它选了一套适配“小模型 中文 长文本”的后训练方案而不是照搬大模型那套标准SFT DPO模板。1.2 开源后训练recipe里到底包含什么“Recipe”这个词在开源模型圈里用得很广但很多人理解得过于浪漫。我把它落成四个实际能拿到手的部分基座选择与蒸馏关系模型是从哪个基座压下来的压缩比是多少有没有保留原基座的任何层或embedding初始状态。数据配方训练语料的构成比例、来源类型、清洗和去重方式以及每个领域的数据占比。训练超参与调度学习率、batch size、序列长度、优化器参数、上下文窗口扩展策略。评估与调优闭环用什么数据集分级评测哪个阶段看哪几项指标评测结果怎么反馈回下一轮数据配比。但这里有个残酷的现实官方仓库通常只放出权重、推理代码以及一部分很少的训练配置信息真正决定效果的完整数据清洗细节、蒸馏时的混合比例、偏好数据构造规则往往在release note里看不到。MiMo V2.6这边的开源材料同样属于这种“给了结果和路径没给完整底稿”的状态。所以下面我讲的很多分析属于基于公开做法和工程经验的复现式推导我会明确标出哪些是推断、哪些是常见做法。如果你是要逐字节复现官方效果那大概率需要用自己的数据再做检索调优。2. 整体后训练路线图蒸馏、长文扩展、对齐三步走2.1 后训练主线不是“先SFT再DPO”这么简单我在复现过几家中英文开源项目之后慢慢形成了一种判断方式看后训练配方不是看它有没有用某一种技术而是看这些技术在整个训练链路里的顺序和比重。MiMo V2.6这条链路我把它拆成三个阶段来看第一阶段知识蒸馏和压缩。从大基座把能力迁移到6B甚至2B这样的小模型上。这阶段的核心目标是“保真”让小模型在知识类任务上的表现尽量贴近原基座。第二阶段长上下文扩展。将模型的上下文窗口从几K逐步扩展到长文本。这里会涉及位置编码的调整、长序列数据的逐步引入、训练效率和注意力的重平衡。第三阶段偏好对齐与指令跟随优化。让模型回答更符合人的偏好指令理解更稳定同时兼顾中文场景和移动端轻量交互的需求。这三步不是“一刀切”的先后关系。实际工程里第二阶段和第三阶段往往要穿插两到三轮因为长文本扩展后模型在超长输入下的指令行为会出现退化需要再补一轮偏好优化来拉回来。2.2 和DeepSeek/R1以及Qwen系配方比差异在哪把MiMo V2.6和近两年几个开源后训练方案放在一起对比会看得更清楚配方路线主要后训练手法适用场景成本重心DeepSeek R1类大规模强化学习RL冷启动SFT重视推理链强推理、数学、代码训练成本高、奖励模型设计难度大Qwen2.5类高质量大语料SFT DPO 长文本续训通用对话、多语言、工具调用数据质量管理成本高语料量需求大MiMo V2.6路线基座蒸馏 短到长序列扩展 轻量偏好优化端侧部署、中文长文本、资源受限场景蒸馏和序列调度设计成本高偏好数据相对轻量R1那条路非常烧钱因为大规模强化学习需要大量探索样本和比较稳定的奖励模型。对一个6B模型来说完全照搬R1的成本曲线是不理性的。MiMo V2.6没有选择在推理路径上硬堆RL而把更多力量放在“如何用小参数继承大模型的常识与长文本能力”这个取舍是符合端侧模型定位的。跟Qwen系比MiMo V2.6对中文数据明显有更强的倾斜。跑过C-Eval和CMMLU就会发现很多开源模型的中文能力靠的是“英文能力迁移”但MiMo这一版在中文本土知识、高考题目、中文阅读理解上的表现更扎实。这背后是后训练数据中中文比例和题型占比起了主要作用。2.3 设计意图是很多细节的上位解释很多人在复现开源模型时容易犯一个错只看技术名词不看设计意图。比如看到“没有用GRPO”就觉得它落后看到“没上多模态”就觉得它是功能缺失。但这类判断脱离了当时的约束条件——这个模型的目的是跑在移动端能源有限、内存有限、推理延迟敏感。带着这个约束再回看“为什么蒸馏而不是直接用原基座微调”答案就很清晰参数量直接决定了端侧推理的内存占用和速度。6B这个数字本身对端侧来说已经很临界了。如果后训练做不好它完全可能变成“分数好看手机跑不动”的摆设。还有一个有意思的细节这批模型都很关注1M级别的超长上下文。你会看到系列命名里带1M字样。但对移动端来说存下1M token的KV cache对内存来说是巨大的压力。所以配方里必然得考虑配合推理阶段的稀疏化或者量化方案单独把长文本训练做出来但没有推理侧承接产品上是不成立的。3. 数据配方后训练里真正的胜负手3.1 数据的构成比很多人想象的“更偏应试”如果你只看官方公布的benchmark会发现一个很明显的特征——它把中文知识类考试题拿捏得很到位。这说明它的后训练数据里中文题库类数据一定占了不小的分量。我基于工程经验做一个推断MIMO V2.6的数据混合比例大体上会落在这样一个区间内中文通用对话差不多35%到40%英文通用语料20%到25%代码与技术类语料15%到20%数学与推理链数据15%到20%特定领域知识如医学、法律5%左右这个比例不是为了拍脑袋定的。中文数据占比高才能解释C-Eval和CMMLU的涨幅代码和推理数据占比不能太低否则模型的逻辑能力会出现明显垮塌这在跑BMC_GAOKAO这类综合考试题时会直接暴露。5%左右的垂直领域知识则起到了“点亮”作用让模型在某些专业问答下有基本概念而不是一问三不知。如果你手头也在做中文模型的后训练我建议不要直接把通用模型的数据比例拿过来套用。先在中文benchmark上跑一个小规模的强化学试把“中文通用/英文/代码/推理”这四类的比例从40/20/20/20调成50/15/15/20看你的验证集收益是正还是负再决定要不要动全局配比。3.2 数据从哪来蒸馏不是从权重而是从数据MiMo V2.6“从大到小”的路线决定了它在数据构造上极大概率用了大模型蒸馏技术。这里的“蒸馏”要区分两个概念权重蒸馏直接把大模型的参数迁移到小模型里或者说用大模型作为老师直接监督小模型的logits。这种方案对训练框架要求高通信开销大。数据蒸馏不复制权重而是拿大模型生成大量高质量指令对和答案再用这些小模型能消化的规模去训练。这种方案更灵活也是现在开源社区里更主流的做法。我判断MiMo V2.6更可能采用的是数据蒸馏。原因是数据蒸馏在工程实现上更稳定并且天然适合训练多轮迭代——先把数据拿大模型生成一遍经过筛选和评分再用Student模型做SFT跑完评测后把失败case送回给大模型重新生成。这个闭环做两三轮效果提升会非常显著。蒸馏数据时有一个实操经验值得注意大模型生成的数据如果不做长度惩罚往往会拖出一堆冗长的“正确的废话”。在训练小模型时这类数据尤其致命因为小模型的容量有限它会把这些废话的语调也学进去。最终结果就是模型答非所问、喜欢绕弯子。所以数据蒸馏阶段一定要设计“长度约束 信息密度打分”两个过滤维度不能只看答案对不对。3.3 评测闭环是数据配方的“方向盘”后训练数据配方不是一次性定死的。我在自己项目里的经验节奏大致是“三天一轮”的闭环优化第一天用上一轮模型跑全部评测集按错误类型打标分类。第二天把错误类型回传给数据生产链路针对薄弱题型重新生成或采样数据。第三天做数据混合比例的微调启动小规模训练验证。MiMo V2.6能做到多个中文题库同时高分背后的评测闭环一定做得非常细。这也可以从最后的结果反推如果它只是在通用语料上做一次SFT不可能同时拿捏住高考题和代码题必须有多轮“补短板”式迭代。我做评测时还有一个习惯不只看平均分还会把每个子题库的分数打印成分位图。比如某个模型C-Eval平均分看起来不错但一到“法律常识”就掉到个位数那说明这部分知识几乎没训练到。反推数据比例时这种维度的分析比单一平均分有用得多。3.4 聊天模板和格式一致性看似小事实则大事聊到数据配方最后必须提一个绝大多数新手会踩的坑聊天模板不一致。在长文本后训练中如果训练数据的格式时而用ChatML、时而用纯文本拼接、时而带系统提示、时而不带模型会花大量无效容量去学习“格式切换规律”。这会直接挤压知识容量还会导致推理阶段出现灾难性的“乱加分隔符”现象。所以后训练recipe里对格式的统一要求重要性不亚于语料配比。如果你在复现时发现模型总是把instruction重复输出一遍先别怀疑模型回去检查训练数据的模板是否严格统一了。4. 训练超参数档位和稳定性经验4.1 我会首选的默认超参数档位训练后配方里最枯燥但最致命的是超参数。没有一套超参能通吃所有模型但有一个合理的默认档位可以先跑起来。基于我对6B量级模型后训练的经验一套相对稳的起步配置会是这样参数推荐值备注优化器AdamW后训练阶段不需要换花哨优化器学习率2e-5 至 1e-5先高后低的线性衰减或cosineWarmup步数占总量2%到3%太少容易前期震荡Batch size128到2048样本均可长文本时看有效token数而非条数最大序列长度从4096逐步扩到131072甚至更多不要一步到位梯度剪裁1.0长序列训练尤其重要权重衰减0.1后训练阶段保持稳定这套配置基本对应市面上主流开源项目在“SFT 长文本续训”阶段的常用做法。MiMo V2.6公开信息有限但如果你从零复现把上面这套作为首个实验跑大概率不会因为基础超参而翻车。4.2 长上下文扩展的序列调度短到长不能一步跨有一个细节我在很多开源recipe里都能看到但官方通常不会专门拿出来强调——长短序列的训练顺序。上下文窗口从短扩展到长的过程不是把训练序列长度参数直接改成目标值那么简单。原因是位置编码在预训练阶段只见过短序列的分布如果你直接把131072长度的数据灌进去RoPE在远端位置的外推会不稳定损失会突然飙升。正确做法是分阶段引入第一阶段短序列跑稳定比如最大4096跑若干步。第二阶段混入中等长度数据比如8192到16384训练数据按比例混合而不是全部切换。第三阶段逐步提高长序列占比比如8192以上占四分之一再提升到二分之一。每个阶段之间要做一次完整的中短长度评测确保模型在旧长度下的能力没有大幅度退化。如果你发现短文本分数掉得厉害那就不是在扩长而是在破坏已有能力。这个短到长的调度设计我认为是MiMo V2.6能达到超长上下文的关键之一。长文本能力不是“微调”出来的而是“铺路”出来的前期的数据比例和损失策略决定了这条路稳不稳。4.3 训练崩溃和损失尖峰长序列场景的真实折磨长序列训练最常见的崩溃点是OOM和NaN。OOM好理解序列长度翻倍激活内存几乎幂次增长能压缩的办法无非是gradient checkpoint、flash attention、序列打包以及降低batch size。最难排查的是NaN。我印象最深的一次长文本训练事故是用长序列数据直接续训一个模型跑了600步左右loss突然从2.1跳到4.8然后彻底发散。查了很久才定位到问题某个超长样本里混入了一个损坏的token id加上学习率调度在拐点处出现了异常倾斜两者一起触发了神经网络的数值不稳定。现在我的习惯是在长文本训练的配置里强制加三条保险梯度剪裁上限设为1.0宁可训练慢一点也不能让梯度爆炸。数据管线里额外做一步“token id合法性校验”把所有超出词表范围的非法id直接过滤掉。检查点保存频率要缩短长序列训练几千步可能就要重启热启动比从头再来要便宜得多。4.4 评测指标不要只盯loss跑后训练时盯训练loss是最容易产生“虚伪安全感”的。训练loss降低只能说明模型在拟合训练分布不等于它对用户更友好。我见过太多loss曲线很漂亮、实际回答乱七八糟的模型了。更合理的方式是建立“轻量评测流水线”每个checkpoint保存后自动跑一批多温度解码的答案覆盖通用问答、指令跟随、长文本提取等维度生成一份对比报告。整个过程控制在二十分钟内就能把训练过程中“能力上升还是下降”看清楚。从MiMo V2.6最终的能力图谱来看它一定是在训练过程中做了多轮checkpoint级评估的。因为如果你只盯着最后几块checkpoint打分中间出现能力塌陷是无法被发现的。只有形成持续评测的习惯才能及时调整训练方向。5. 长上下文、纯文本与真实部署边界5.1 超长上下文带来的拷问不是大就美MiMo V2.6系列以超长上下文作为卖点但我必须说一句可能不太顺耳的话长上下文的“账面长度”和“实际可用长度”是两回事。一个模型声称支持131072长度甚至更长这是它训练时的最大上下文。但在实际使用中随着输入变长记忆准确率会下滑。你可以做这样的测试在上下文中间埋一个指定事实然后在末尾提问看模型能不能准确回捞。短中长三种输入长度各测一轮很快就能找到模型真实可靠的上下文深度。很多号称长上下文的模型在超过八分之一窗口长度后准确率就开始明显下降。长文本能力本质上更像“检索可靠性”而不是“注意窗口长度”。对端侧模型来说这个问题更严重。因为KV cache随序列长度线性增长超长上下文会让内存用量突破手机能承受的范围。所以工程上必须配合降精度、稀疏注意力、推理侧滚动窗口等手段才能真正跑起来。5.2 为什么它不带图片输入能力和“不支持图片输入”这个点很有关系。很多用户一看到这个就抱怨“为什么不能用图”但从后训练设计的角度看这个“不”是主动选择不是技术缺失。把图像支持放进模型意味着在输入侧增加视觉编码器训练时加入大量图文交错数据推理时图像token会占据超长文本的空间。对本来就以压缩和长文本为目标的移动端小模型来说图像能力是一笔不划算的开销。没有图片输入换来的是更快的处理速度、更少的内存占用和更强的文本理解专注度。如果你一定要让这种模型处理图片工程上有替代方案单独跑一个离线OCR或者图像描述模型把图片转成文字再把文字送给主模型。这招在办公文档、截图、表格识别场景下非常稳甚至比端到端视觉语言模型更可控。我自己在处理长文档时用的也是这条链路效果很好。所以别把“不能传图片”当成缺陷。大多数真实场景比如客服知识库、文档问答、会议纪要本质还是文本理解和检索纯文本模型反而更干净。5.3 推理阶段的高效策略别浪费后训练的功夫一个模型的“可用性”不光由训练决定还由推理框架决定。MiMo V2.6这类移动端模型推理时最需要注意的是三点第一采用KV cache量化。把缓存从FP16压到INT8内存大约能省一半精度损失在长文本场景下通常可控。如果模型本身后训练时做过量化感知训练收益会更明显。第二启用增量推理。每次请求只计算新增token而不是重新跑全量序列这对长对话的效果是质变级别的。第三尽量用与训练一致的系统提示词格式。推理时如果你自由发挥改了几句话术可能没有明显影响但如果改动了分隔符或者提示词的层级结构长文本召回效果可能会突然变差。这就是第3小节里强调的“模板一致性”在推理侧的回声。6. 从MiMo V2.6的recipe里能带走什么6.1 最值得直接照搬的五个设计我觉得这套开源后训练配方里有这么几件事是可以直接迁移到自己项目里的小模型继承大模型能力时优先用数据蒸馏不要死磕权重蒸馏。数据蒸馏工程成熟效果稳定且天然能配合多轮闭环。长上下文扩展要按“短到长”分阶段调度绝不能一次性拉满。序列长度的逐步引入是保护已有能力的关键。数据配比中中文、代码、推理三个维度的比例要根据目标benchmark做差异化设置。泛泛的“通用比例”在小模型上效果很平庸。后训练阶段要建立checkpoint级评测循环不能只盯loss。每次出检查点都要尽快看到能力曲线而不是等训练全部结束才验收。评估和数据处理必须考虑模板一致性。聊天格式的统一性是小模型后训练里优先级被严重低估的要素。6.2 复现这套配置需要多少预算按6B模型加长文本后训练来算一个相对现实的估算取决于你是否从预训练基座开始。如果只是做后训练也就是拿到一个现成的基座加上蒸馏数据构建、SFT、长文本扩展和偏好优化我参考同类开源项目的常见规模给一个区间纯训练算力上8卡到32卡一到两周时间可以跑完一个中等质量的后训练全流程。当然如果你的目标是超越官方release note上的高分那数据侧的成本会远超训练侧。data acquisition和质量筛选永远是这类项目里最大的隐性投入。如果你预算有限我的建议是砍训练步数不要砍数据质量。少跑几千步模型可能只是分数低一点数据不干净模型可能直接学歪连低分数都保不住。6.3 真正搬不走的部分我必须诚实地补一刀这套recipe里有一块东西是搬不走的那就是“用户真实反馈”。MiMo的表现之所以扎实除公开技术路线外小米在真实中文用户场景下的使用反馈数据是一大隐性资源。这些数据决定了偏好对齐的上限。你可以在开源社区里收集到公开指令对也可以用自建数据蒸馏但都比不上海量的真实用户评价数据来得有效。所以如果你自己也想做一个类似的中文小模型最合理的路径未必是等公开数据复现MiMo的全部而是建一条自己的数据闭环用小模型跑真实业务积累一批用户反馈再针对薄弱点生成补充数据不断回灌训练。这个闭环转起来之后哪怕模型参数量只有6B也能在你的垂直场景里跑出不输通用大模型的表现。这类后训练recipe最值得学习的地方不是某个具体技巧而是它面对“小参数、中文、长文本、端侧部署”这些约束时所做出的系统性取舍。把约束列清楚把取舍看懂剩下的训练工程其实都是常规工作。