企业官网建设流程全解析

开源模型这两年见得多了，多数项目都是权重一放、README一写就完事，权重文件倒是齐全，可你怎么把模型训练成这个水准的，过程基本是黑盒。MiMo V2.6这次把后训练recipe整整齐齐地开放出来，对我来说算是少见的高价值动作。所谓recipe，在LLM圈子里可以直白地翻译成“训练菜谱”——数据怎么组织、超参怎么设、SFT做几轮、偏好对齐用什么方法、评测集怎么选，每一步都落到文件和配置上。对于想复现这套模型的人，或者想拿MiMo做底座做二次开发的企业团队，这份recipe的价值可能比权重本身还大。这篇文章我不打算替谁吹产品，只说我自己蹲在repo里啃了几天之后的理解：这套后训练配方到底拆成了哪几块，每一块在解决什么问题，以及真正动手复现时你会踩到哪些坑。

1. 先看懂recipe的门面：一个后训练项目到底开放了什么

拿到一个开源后训练recipe，第一反应千万别是去找训练命令一行行跑，那是把宝当草用了。你要做的是先盘一遍目录结构，搞清楚这个仓库把“训练过程”拆成了哪几个模块。以MiMo V2.6的recipe为例，它表面上是一堆脚本和配置文件，背后其实是把一套完整的后训练工程方法论摊开在你们面前。

1.1 一份能跑通的后训练配方，至少要包含五样东西

我盘过不少开源后训练项目，一个真正能复现的recipe，目录里通常要塞进五类内容。

第一类是数据组织脚本。原始语料跟模型能直接吃的数据格式之间，差着一整个pipeline：清洗、去重、按模板拼装成instruction和response。repo里如果只有整理好的JSON而没有转换脚本，你换了数据源就等于从头再来。

第二类是训练入口与启动命令。常见的是shell脚本包着一层train.py，里面写清楚了大模型训练框架（比如Megatron-LM或DeepSpeed）怎么启动，分布式参数怎么传。这层东西最容易被忽略，但恰恰是你复现时能不能在自家集群上跑起来的关键。

第三类是超参数配置文件。SFT阶段和偏好对齐阶段通常是两套YAML，学习率、warmup、batch size、序列长度、ZeRO级别全在里面。这部分我后面会专门拆开讲。

第四类是评估脚本和评测集。没有固定版本的评测集，你拿什么证明“复现成功”？很多repo随便丢几个eval脚本，但评测集版本不锁死，今天跑MMLU和下周跑MMLU用的题目可能都不是同一年代的，分数对比没有意义。

第五类是结果日志和示例输出。一个诚实的recipe应该附上训练过程中的loss曲线截图、中间checkpoint的表现、以及模型在典型case上的输入输出。MiMo V2.6的repo里如果放了这部分，建议你务必先看——它相当于告诉你“跑成什么样算正常”，省得你自己对着loss曲线瞎猜。

这五样缺了哪一样，recipe的可复现性都会打折扣。别小看“缺失部分”，实践中很多项目就是因为少了数据组装脚本，同一个batch size下喂进模型的token分布都不一样，导致你复现出来的效果跟官方报告差了十万八千里。

1.2 为什么“开源权重”远远比不上“开源recipe”实用

权重是成品，recipe是工艺。成品只能让你拿回去推理，工艺才能让你理解这模型是怎么长成这样的。

我见过太多团队拿开源权重做二次开发，发现能力边界不对，想微调一下，结果手里连原始训练数据格式都不知道，只能自己猜着构造，最后模型跑偏了还找不到原因。有了recipe之后，整个链路是闭环的：你把它跑通一次，模型的“性格”是怎么来的，数据在哪个环节起了作用，你心里全有数。这个价值对于做研究和做落地的团队是截然不同的——研究团队可以拿recipe做消融实验，比如把某个数据模块去掉看看能力掉多少；落地团队则能直接换自己的场景数据，沿用整套工程框架，省下的时间少说也是几个月。

2. 后训练三件套拆解：SFT、偏好对齐与评估兜底

任何开源大模型的后训练，拆到最后都是三个阶段的主线：先做指令微调（SFT），再做偏好对齐，最后拿评测集验收。MiMo V2.6这份recipe的主线也没有跳出这个框架，但它把每个阶段做得很“工程化”。我们一个一个看。

2.1 SFT阶段：先把格式和知识长在模型里

SFT的目标是让预训练模型学会“人话交互”，核心是把对话模板和指令跟随能力教给模型。这一步的数据组织细节，recipe里通常体现为一条一条的对话样本，字段大致是instruction、input、output，有些还会带system字段。

关键点在于loss mask。训练时只有assistant回复部分参与loss计算，用户指令部分要掩膜掉。这个设定很多人不理解，我打个比方：模型要学的不是背题目，而是对题目给出正确回答。如果用户输入也算loss，模型就会学着“预测用户下一句说什么”，这跟指令跟随的目标是违背的。排查loss无法下降的故障时，第一个就应该检查loss mask有没有写对。

SFT阶段的数据量，主流开源项目从几十万条到几百万条不等。MiMo这类规模的项目一般不会走极端，几十万量级的高质量指令数据已经足够重塑模型的行为模式。数据量不是越大越好，量大但重复度高，等于让模型在大海里反复捞同一根针，浪费时间还容易过拟合。

2.2 偏好对齐：DPO与RLHF怎么选

SFT之后模型已经能对话了，但它可能会一本正经地胡说八道，也会在需要拒绝的场景里硬凹答案。偏好对齐阶段解决的就是“让模型输出符合人的偏好”。

偏好对齐里两大流派是RLHF和DPO。RLHF要靠训练一个奖励模型，再用PPO算法让策略模型跟奖励模型对齐，工程复杂度和算力成本都很高。DPO就聪明很多，它不需要单独的奖励模型，直接拿“好回答 vs 差回答”的偏好对构造损失函数，迫使模型往好回答方向挪。MiMo V2.6的recipe如果按常见开源项目的惯例走，偏好阶段大概率是DPO路线，原因也很实在：DPO训练稳定、显存开销可控、不需要维护一整套PPO的推理集群。

DPO里有一个关键超参数叫beta，它控制模型偏离reference model（微调前的SFT模型）的惩罚强度。beta调大了，模型不敢偏离参考策略，学得慢；beta调小了，模型容易学过头，输出崩坏。业界常见范围是0.1到0.5，新手起步用0.3，然后在验证集上观察是否出现重复或胡言乱语，再往两个方向微调。

2.3 评估体系：不能只有一个榜单分数

后训练做完没有评测，相当于考试不公布成绩。一份靠谱的recipe一定会把评估脚本和评测集固化下来，而且评估维度不会单一。

通用知识走MMLU，数学推理走GSM8K和MATH，代码生成走HumanEval和MBPP，中文能力走CMMLU或C-Eval，对话能力还要单独看IFEval这类指令跟随指标。MiMo这种中文友好模型，中文维度评测尤其不能漏，不然你只看英文榜单一味调优，很容易把中文语感练退化了。

评测集版本锁定很重要。建议先把评测集的哈希值记录到repo里，再用固定seed跑。不然今天升级了评测集、明天换了采样参数，分数波动会让你误判模型好坏，做出南辕北辙的调参决策。

3. 关键超参数逐项解读：照着填也要知道为什么

超参数是recipe里最“照妖镜”的存在。同一个模型、同一份数据，超参数不同，结果天差地别。我建议你不要只把YAML当作“别人填好的作业去抄”，而是要理解每一组数字背后的权衡逻辑，这样换环境、换数据时才不会翻车。

3.1 学习率、warmup和batch size的搭配逻辑

学习率图样里，SFT阶段和偏好对齐阶段通常是两个世界。SFT阶段模型要从“只会续写”切换到“会对话”，需要学的模式变化较大，学习率可以给到1e-5到2e-5。DPO这类偏好优化阶段，模型已经在SFT基础上很接近目标了，只需要小幅调整分布，学习率要压到5e-7到1e-6量级。给偏好阶段用SFT的大学习率，我见过最坏的结果是模型开始疯狂重复同一个句子，loss降到谷底但生成彻底崩坏。

warmup参数通常设3%到5%。预训练状态下模型和训练数据的分布差异较大，一上来就全速更新参数，前期loss可能直接冲出图表。warmup让学习率从0附近缓慢爬升，相当于跑步前先热身，让优化器逐步适应数据分布。

batch size的调整思路是看global batch size而不是单卡batch size。比如单卡per_device_train_batch_size=2，梯度累积16步，4张卡，那global batch size就是2×16×4=128。为什么关注全局值？因为它决定模型每次更新参数时看到的样本量，直接影响收敛稳定性和最终效果。SFT阶段128到256是常见区间，DPO阶段可以稍小一些。

3.2 max_length、精度与并行策略

max_length这个参数直接决定模型的上下文能力。你用8192的序列长度训练出来的模型，在使用中很难稳定处理8192以上的长文；如果你按2048训练却希望它写长篇报告，它就是会“忘掉开头”。MiMo这类现代开源模型一般会支持至少4K到8K的上下文，所以recipe里的max_length也会往这个区间走。代价是显存暴涨，序列长度翻倍，激活内存基本也是接近翻倍。

精度策略我强烈推荐bf16而不是fp16。fp16的表示范围窄，loss一大就容易溢出变成nan；bf16动态范围跟fp32接近，虽然小数精度低一些，但训练稳定性好得多。现在主流的训练框架和GPU都原生支持bf16，没必要为了算力兼容硬用fp16。

并行策略上，小规模复现用DeepSpeed ZeRO Stage 2就够，模型规模上到几十B再考虑ZeRO Stage 3，甚至配合CPU offload。ZeRO Stage 3会把参数切到所有卡上，通信开销变大，如果带宽有限，训练效率可能反而不如Stage 2。别盲目追求Stage 3，要根据集群实际情况来。

3.3 一个参考的YAML配置长什么样

以常见的开源训练框架配置为例，SFT阶段的配置大概长这样：

model: base: "MiMo-V2.6-Base" dtype: bf16 data: train_file: "data/sft_train.jsonl" max_length: 8192 training: per_device_train_batch_size: 2 gradient_accumulation_steps: 16 learning_rate: 1.5e-5 lr_scheduler: cosine warmup_ratio: 0.04 num_train_epochs: 2 optimizer: adamw weight_decay: 0.1 parallel: zero_stage: 2 offload: false

偏好阶段则把学习率改成5e-7到1e-6，换一个偏好数据文件，再把DPO的beta: 0.3加上去。整体框架不用动，动的就是这几个关键值。你可以看到，超参数之间的联动很紧密，改学习率就得检查warmup，改batch size就得看显存和global batch，一轮全链路梳理下来，你对这份recipe的掌控感会完全不一样。

4. 数据配比与质量控制：最容易拉开复现差距的地方

超参数可以抄，但数据是抄不走的。这是recipe里“玄学”含量最高的部分。MiMo V2.6把数据组织脚本和配比公开出来是一回事，你拿到自己数据能不能做出同等效果又是另一回事。这里面的差距主要来自三件事：数据来源、清洗去重、配比设计。

4.1 数据来源与清洗流程

公开数据集是主粮，比如各类开源指令集、问答社区数据；自采数据是特色，用来扣住目标场景的语感；合成数据是现代LLM后训练里越来越重要的增量，让模型自己生成问题、互相评价质量，但合成数据需要严格过滤，不然模型会学到一套“正确的废话”。

清洗流程里最重要的两件事是去重和质量过滤。精确去重很简单，算哈希，完全一样的文本删掉。近似去重一般用MinHash，把长文本打成n-gram的集合，用Jaccard相似度判断重叠。我建议把阈值调到0.7以上，否则一些只改了几个字的相似回答也会在数据集里反复出现，模型会对着某个句式产生严重的偏好。

质量过滤方面，可以用规则和模型打分两路并进。规则负责祛除乱码、超长无标点段落、HTML残留；模型打分则让一个成熟模型对指令和回答的相关性打分，低于阈值的直接扔掉。这一环节很吃算力，但对最终效果的影响巨大。

4.2 数据泄漏检查：eval集被污染是最大翻车点

这是很多人会忽略的深坑。训练数据里如果混入了评测集的相似内容，评测分数会虚高，模型看起来很聪明，上线就露馅。

基本做法是用n-gram重叠检测，把训练语料和评测样本逐条比对。比如将评测集的每个问题拆成8-gram序列，在训练语料里搜索，一旦出现连续8个词完全重叠，就要把对应的训练样本标记出来人工审查。

还有一类隐蔽泄漏是时间戳泄漏。比如评测数据里的知识截止到2025年3月，而训练数据里混入了2025年6月的新闻，模型在评测时“答出了不该知道的事”，看起来是好事，其实是数据穿越，部署后没有任何意义。固定评测集版本，并且跟训练数据做隔离审查，是recipe里必须有的安全程序。

4.3 配比失衡会带来遗忘

配比设计你可以理解成给模型划重点。一个常见配比方可以是：通识指令35%、数学推理20%、代码生成20%、多轮对话15%、中文场景语料10%。这不是标准答案，但它体现了思路——通用能力打底、专项能力强化、中文场景兜住。

配比失衡的典型症状叫灾难性遗忘：代码数据加太多了，通用的MMLU分数掉三五个点，模型写诗都开始带注释风格。排查遗忘问题，你需要在训练多个stage之间保留旧任务的评测集，每次SFT或DPO完成后跑一遍，把分数趋势绘出来，一旦发现某类能力掉得离谱，就得压缩对应数据的权重或者干脆把它加回数据集里。

5. 复现实践中常见的五个翻车点与排查清单

理论看完就得动手了。这一章整理的是我真刀真枪复现类似开源recipe时踩过的坑，以及排查思路，全部写出来供你对照。

5.1 用显存小卡复现时怎么降资源

不是所有人都有同款算力。想把recipe跑起来，最常见的手段是砍序列长度、调小batch、开offload。

先砍max_length。如果显存不够，把8192降到4096甚至2048，代价是你复现的模型长文本能力可能不及官方，但对于先跑通流程这个目标来说完全够用。再调per_device_train_batch_size，从1做起，配梯度累积去补global batch。注意调小单卡batch时，如果同时开着ZeRO Stage 3，通信会变频繁，训练会变慢。此时可以试试Stage 2配合CPU offload，把优化器状态放到内存里，对显存助益很大。

如果使用的是4090这类消费级显卡，建议把offload开关打开，同时把gradient_checkpointing: true加上。它用重计算换显存，会让前向多算一遍，但能换回可观的显存余量。

5.2 loss不收敛、reward炸掉、中文退化怎么排查

复现过程中最让人头疼的几种异常现象，我整理成了一张速查表：

一条基本的修行准则：只改一个变量，观察一段日志，再动下一步。许多人一上来就是lr、batch、数据同时改，出了差异根本定位不了元凶。

5.3 快速验证recipe的小规模试点

拿到recipe别一口气跑完整版，先做小规模试点。

试点思路是这样：把训练数据缩减到十分之一，max_length砍到2048，训练步数减半，用单机多卡跑通全流程。跑通的定义不只是loss在降，还包括检查日志里有没有显存溢出、checkpoint是否能正常加载、评测脚本能不能跑出合理分布。小规模试点相当于练兵，一次全流程演练下来，你会对这个recipe的运行逻辑有一个感性的时间感知，比如一步大概多少秒、数据吞吐是不是正常。

小规模跑通后再逐步放大，把数据恢复完整、序列长度恢复、步数拉长，这时候绝大多数工程坑已经踩平了。直接全量开跑一旦在第五千步炸掉，成本就不是几小时能弥补的了。

6. 一些可能别人不会说的实操体会

这一章不是从YAML里能读出来的东西，是我自己在类似开源recipe项目上反复折腾后的一些实感。有些话可能没人专门跟你讲，但确实能帮你少走弯路。

6.1 小团队拿到recipe后应该怎么落地

小团队的算力预算通常撑不起从头预训练，所以拿到这类recipe，最优路径是把它的后训练管线整体搬过来，套自己的场景数据，直接跑SFT和偏好对齐。这样既吃到了大厂验证过的工程框架，又不至于被基础模型的成本拖死。

具体落地上，我建议先把recipe仓库的依赖版本锁定成一个可运行的环境快照，再单独建一个分支替换数据源。数据格式是最容易出问题的地方，多花一天时间把自制数据映射到repo要求的schema上，比着急启动训练划算得多。

6.2 给模型定位匹配数据，而不是只堆通用数据

我见过太多项目在SFT阶段把各种公开指令集全部灌进去，最后模型四不像。MiMo V2.6这类开源的魅力在于可以领域化改造，但你不能指望一份通用recipe适配所有业务。如果你要做法律问答，那就得把判决书、法条解析、法律咨询这样的语料压到第一优先级，通用指令集反而应该降权。

还有一条关于能力边界的提醒：不要期待文本模型能够处理图片输入。这类问题不在后训练recipe的讨论范围内，如果业务有图像理解需求，需要的是多模态模型架构，靠调整文本训练数据改不出来。不少人在使用过程中抱怨“模型不能传图片”，这其实从定位上就没匹配对。

6.3 最后补一个小技巧

把评测集固化成一份独立的JSON文件，塞到repo的固定目录里，之后每次训练完直接用同一份文件、同一套脚本、同一个随机种子做评估。别小看这个习惯，它能让你在两周后翻出历史分数时，依然能自信地跟别人说“这两个checkpoint的差异完全来自训练过程本身”。我在实际项目中踩过评测集被悄悄更新的坑，那次对比结果出现异常，排查了半天才发现是评测集版本变了，白白浪费了一个下午。

这个开源recipe的思路，后续完全可以扩展成自己的SOP。比如在train脚本里加一个自动记录评测分数的逻辑，接到任意一款可视化面板上，长期监控模型的每次变化。跑多了你会发现，后训练的技术知识点其实不算多，真正拉开差距的往往是“流程纪律”——数据处理是否严格、评测是否稳定、变更是否可控。把这套纪律固化下来，任何开源recipe到你手里都会变形为可复用的内部资产。