企业官网建设流程全解析

翻开一个开源模型的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.72，CMMLU是79.42，BMC_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和近两年几个开源后训练方案放在一起对比，会看得更清楚：

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量级模型后训练的经验，一套相对稳的起步配置会是这样：

这套配置基本对应市面上主流开源项目在“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最值得学习的地方，不是某个具体技巧，而是它面对“小参数、中文、长文本、端侧部署”这些约束时所做出的系统性取舍。把约束列清楚，把取舍看懂，剩下的训练工程其实都是常规工作。