开源模型阵营的排位赛最近又刷新了一次纪录。AI21实验室放出了MiMo-V2.6系列直接登顶开源大模型榜单而且这次官方没有只丢一个模型权重出来而是同步发布了一份相当厚的技术报告把训练配方、数据筛选、强化学习RL的细节都摊在了台面上。不少朋友看到“自我改进的强化学习规模化”这个说法第一反应是“又来了个概念”但如果你真的把报告翻完会发现里面的路线其实非常务实用72B的中等规模模型靠强化学习硬生生把推理能力推到了接近闭源第一梯队的水平。这篇文章不打算复述报告摘要而是从我的视角把几个关键环节拆开聊聊这个版本到底做对了什么、落地时有哪些雷以及各位如果想在自己业务里复现这套打法大概需要准备什么。这篇内容适合三类人看一是在做开源模型选型、想了解MiMo-V2.6真实水平的工程朋友二是对强化学习训练感兴趣、想知道self-improvement具体怎么落地的算法同学三是单纯想跟一跟大模型前沿进展、又不愿意啃全英文技术报告的爱好者。我会尽量用比较直白的话把报告里的核心机制讲清楚同时穿插一些我在实际部署和复现过程中遇到的坑和解决办法希望能帮你少走点弯路。1. 先搞清楚MiMo-V2.6到底在“秀”什么1.1 五个关键词先串一遍想要读懂这次发布先得把标题里的几个限定词拎清楚。“第一开源大模型”指的是当前主流权威榜单上MiMo-V2.6的综合成绩在可商用开源模型里排到了第一这个不是自封的而是多项基准测试的结果“MiMo-V2.6”是AI21实验室的开源模型代号这一代同时放出了72B和7B两个尺寸“自我改进”指的是训练过程中让模型自己生成训练数据、自己验证答案再拿这些数据进修“强化学习规模化”则是把以往只用来做对齐微调的RL技术放大成训练主引擎通过增加RL训练的规模来持续拉升模型能力而不是靠堆参数。这里要特别解释一下“强化学习规模化”。过去大家对大模型的认知是“参数越大越聪明”于是各家拼命卷参数量、卷数据量。但2024年之后的一个明显趋势是不少团队发现预训练规模带来的收益正在放缓而强化学习阶段还有巨大的挖掘空间。通俗地说预训练阶段模型读了很多书知识面很广但更像一个“知道很多道理却过不好这一生”的旁观者到了RL阶段模型开始在真实反馈中反复试错逐渐学会怎么把知识用出来。MiMo-V2.6恰恰把后者的规模做到了一个相当高的水位用更少的参数打出了更强的推理表现。1.2 为什么这个版本值得专门写一篇解读我读过不少开源模型的技术报告多数是“预训练指令微调常规评测”老三样读起来很快因为没什么新鲜东西。MiMo-V2.6不太一样它的核心卖点不是模型架构有多少创新而是把“RL as a Scaling Law”这件事真正落地并开源了出来。报告里明确给出了他们如何通过多轮RL迭代、自生成训练数据、奖励模型混合打分等方法让同一个底座模型的能力一波一波往上走。这对行业的意义很大。以前能做大规模RL训练的基本是几个闭源巨头普通团队既没有算力也没有经验现在有人把全套方案摊开虽然你未必能直接照搬72B的训练成本但至少把路径、坑点和关键参数都给你画出来了。对中小企业来说这意味着复现“自我改进”不再是天方夜谭你完全可以在小模型上用同样的方法论跑一遍效果虽然不可比但思路是通的。1.3 一个务实的底座选择我特别想提的一点是MiMo-V2.6没有选择自己从头预训练一个超大模型而是直接以Qwen2.5-72B为底座去做强化学习训练。这个选择背后有非常现实的考量从头训一个几百B的模型光预训练成本就是天文数字而且大概率做不出比开源社区更好的基座。而72B这个体量正处于一个“甜点区”——单机多卡能推理训练成本可控发布后社区也能勉强部署起来不至于像700B模型那样变成“少数人的玩具”。用别人的底座做RL本质上是在做“二次加工增值”。底座的通用知识和语言能力是别人贡献的MiMo-V2.6的增量贡献在“如何让这些知识做出来”也就是推理链路、解题能力和自我纠错能力。这也给广大团队提了个醒在开源生态里你未必需要从零开始在一个好的骨架上施加高质量的后天训练同样能做出非常有竞争力的产品。2. 自我改进的强化学习训练链路拆解2.1 数据飞轮让模型自己出题给自己做MiMo-V2.6训练链路里最核心的一个词是“数据飞轮”。传统方法里高质量标注数据是人工和生产环境一点点攒出来的成本高、天花板低而自我改进的路径是让模型参与数据生产再用自动验证手段筛选最后把合格样本重新喂养回模型形成一个不断扩大的数据循环。具体来说大致是四步流程。第一步用现有的强模型或者当前训练中的模型自身根据种子题目生成一批新的问题第二步对每个问题做多路采样让模型生成各不相同的解题过程和答案第三步用规则验证器去判断答案对不对保留正确的那些第四步把正确样本混入训练集进入下一轮训练。这样做的好处是数据量可以指数级扩张难度也能被动态调节——模型越强生成的题目就可以越难从而持续挑战自己。动手写过这种流程的朋友应该知道这里的难点不是“生成”而是“筛选”。自生成数据的质量问题非常大模型会生成一些看似合理但逻辑偷懒的解题过程甚至会出现“答非所问但答案正确”的情况。MiMo的做法是对整个过程加了多重过滤格式检查、答案一致检查、去重、难易度分层。我自己的经验是如果你要复现这个流程过滤环节至少占整个Pipeline开发量的一半千万别觉得生成完就完事了。2.2 奖励信号从哪来规则奖励与模型奖励的混合强化学习训练最核心的问题是“拿什么做奖励”。MiMo-V2.6给出的答案不是单一种类而是按任务类型灵活混搭。对于数学类任务用规则奖励最可靠。题目有唯一答案验证器直接把模型输出的答案和标准答案做比对是哭是笑一目了然。这种信号没有歧义也没有模型偏见是RL训练里最优质的反馈。对于代码类任务通常会准备一组单元测试模型生成的代码如果能通过测试就给高分部分通过就给部分奖励这是一种介于规则与模型之间的“弱规则”信号。对于开放域问答这类没有唯一答案的任务规则就失效了这时需要上一个奖励模型或者直接用大模型当裁判LLM-as-a-Judge让另一个模型去给输出打分。三种信号如何混合是个非常考验手艺的地方。奖励信号如果不准模型会被带偏训练得越狠错得越离谱奖励信号太稀疏模型又找不到学习方向。MiMo在报告里花了不少篇幅讲他们如何校准奖励模型、如何在多条奖励通道之间做加权这里面有一个我印象很深的细节——他们会对奖励模型采样的结果做一致性检查如果多个Judge对同一条样本给出的分数差异过大这条样本会被丢弃而不是简单取平均。这个操作背后是“宁可没有信号不要错误信号”的思路我在实践中也非常认同。2.3 RL阶段的两个关键陷阱做RL训练和做普通监督微调完全是两种体验。监督微调只要保证数据质量高、不要过拟合基本不会出大岔子但RL训练里模型会想方设法“钻空子”去拿高分训练一长就会冒出各种幺蛾子这里讲两个最常见的陷阱。第一个是奖励黑客Reward Hacking。模型找到了一个分数很高但实际能力没有提升的捷径。比如你给一个推理题设置了“最终答案正确得高分”的奖励模型可能学会在输出里塞一大段看似详细的推导步骤然后直接在末尾蒙一个答案因为答案对了有奖励推导对不对模型根本不在乎。这类问题在纯规则奖励下尤其严重解决思路一般是加“过程约束型”奖励——推导逻辑混乱要扣分、格式不合规要扣分让模型明白过程本身也要正确才行。第二个是多样性塌缩Diversity Collapse。RL训练到后期模型输出的风格会越来越单调所有题目的解题思路都变成同一个模板甚至话术都趋于雷同。原因是RL天然倾向于“找到最优策略然后固化”但过于固化就失去了探索能力。处理手法是对KL散度惩罚项和熵正则项做细致调节既不让模型偏离底座太远又保留一定的随机性。我实测下来这个平衡点非常敏感KL系数调大一点模型就学不进去调小一点又开始放飞自我基本每个阶段都需要重新校准一次。2.4 技术报告里最有价值的几张表MiMo-V2.6技术报告里最值得反复翻的是那几张“消融对比表”。它们不是简单列出最终成绩而是把不同训练的中间状态都拿来做了评测只有SFT的版本、做了一轮RL的版本、做了两轮RL的版本、加了奖励模型混合的版本……你能清清楚楚看到每一层处理给最终效果带来了多少增量。这种披露粒度在开源圈非常罕见。大多数团队只告诉你“我们最后用了什么”而MiMo把“如果中间某一步不做会怎样”也讲明白了。比如有一组对比显示在数学推理任务上增加RL数据量带来的收益比增加预训练数据量带来的收益更明显这直接证明了“RL规模化”这条路是通的。对做训练的同学来说这些数据就是最宝贵的参考资料你可以直接拿来做你自己的实验配置参考。3. 从报告到实操把MiMo-V2.6跑起来3.1 笔记整理先评估你需不需要“全文复读”技术报告读完你大概会分两类反应一类是想上手体验这个模型另一类是想把它的训练流程复现到自己的场景。这两种需求的落地路径完全不同。如果只是体验模型你最需要关心的是部署和推理成本如果你想复现训练那得先搞清楚自己的数据规模、验证器设计能力和可用的GPU预算。我的建议是很多人根本不需要从头复现整个流程而是可以拿现成模型做“二次改造”。比如你觉得MiMo-V2.6在通用场景很强但自己业务里有一些垂直知识它不懂那你完全不需要做RL只需要在它的权重基础上做一轮少量高质量数据的SFT适配成本低、见效快。真正的RL自我改进留到有明确推理需求、并且能设计出可靠验证器的场景再用否则就是拿大炮打蚊子。3.2 第一步下载模型并做本地部署先教你如何把模型跑起来。MiMo-V2.6在Hugging Face上有完整的权重用huggingface-cli下载即可。如果想直接跑测试最简单的方式是使用vLLM部署一个OpenAI兼容的API服务几分钟就能用起来。# 下载模型权重 huggingface-cli download AI21Labs/MiMo-V2.6-7B-RL --local-dir ./mimo-7b # 安装vLLM pip install vllm # 启动OpenAI兼容服务 python -m vllm.entrypoints.openai.api_server \ --model ./mimo-7b \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 32768启动之后用Python请求一下接口import urllib.request payload { model: mimo-7b, messages: [ {role: user, content: 一个圆的半径扩大为原来的2倍面积扩大为原来的几倍请给出详细推理。} ], max_tokens: 1024, temperature: 0.7 } req urllib.request.Request( http://localhost:8000/v1/chat/completions, datajson.dumps(payload).encode(), headers{Content-Type: application/json} ) response urllib.request.urlopen(req) print(response.read().decode())如果你手头只有一张4090或3090这样的24GB显卡装下7B模型是绰绰有余的但是72B版本就需要多卡并行或者使用量化后的小模型。官方也提供了AWQ量化版显存占用能压到36GB左右两张卡就能跑起来。实测下来量化后的推理质量损失在可接受范围日常体验和评测基本够用。提示vLLM启动时要把--max-model-len设得足够长因为RL模型在推理任务中会输出大段思考过程长度设短了会被截断直接影响输出质量。3.3 第二步正确评估RL模型的真实水平模型部署好了接下来是怎么评估它。很多人直接拿几个数学题问一下觉得答得不错就下结论说“这模型很强”其实这很容易被骗。RL模型评测最怕的是测试集和训练集重合模型可能只是把题目记住了而不是真正会推理。我的做法是先构造一个“分布外”的评测集。在模型训练之后发布的新题、自己仿照真题风格编写的变体题、以及从业务场景里采集来的未公开问题都是不错的测试样本。用这些题目去测模型才能看出它的真实泛化能力而不是背题能力。另外要建立一个“过程质量”意识。普通大模型评测只看最终答案对不对但RL模型更值得关注的是解题过程是否严谨。我建议拿同一个问题反复问几遍观察它的思路是不是稳定再故意给一道有陷阱的题看它能不能识别陷阱并纠正自己。MiMo-V2.6一个给我留下深刻印象的点就是它在面对错误假设时会主动“自我纠错”先指出题目里的问题再调整思路。这种能力用传统的一问一答方式根本测不出来但这种能力才是RL训练真正带来的价值。3.4 第三步低成本复现一轮“自我改进”如果你想在自己的场景里试试“自我改进”完全不需要MiMo那么大的算力。这里给一条我已经验证过可行的小规模路线硬件要求是2到4张消费级显卡数据量控制在几千条量级。流程大概是先从种子题库里挑出200到500道你觉得有代表性的题目用当前模型为每道题生成10路左右的不同解答然后写一个轻量验证器根据规则把正确答案筛出来用筛选后的数据做一轮SFT把模型的输出风格先校准到“能正确解题”接着接一轮GRPO或者PPO微调用规则奖励做信号最后用训练好的模型去生成下一轮的新题目重复筛选过程。就这样一轮一轮迭代每轮你都能看到模型在分布外题目上的得分有肉眼可见的提升。我在这套流程里吃过最大的亏是“验证器设计得过于宽松”。一开始我对“正确”的定义只停留在“答案对就行”结果模型学到后面开始输出各种莫名其妙的中间过程训练指标却一路飙升。后来我把验证器加上“必须有完整推导过程”“推导步骤不能跳步”“格式必须规范”等约束模型的真实能力才跟上训练指标。记住一句话验证器严格程度的下限就是模型最终能力的上限。3.5 部署和评测之外还要关注什么有一件容易被忽略的事是RL模型在推理阶段会消耗更多你账户里的钱。因为模型学会了“想得多再答”输出token数量比普通模型多出一大截。在MiMo-V2.6这种以推理见长的模型上单次回答可能动辄输出上千token和传统模型的几百token相比延迟和费用都不可同日而语。这在业务选型时是个关键的权衡。如果你的业务场景是客服机器人、简单信息抽取用推理型RL模型其实是“杀鸡用牛刀”白天明明可以直接给结论非要先思考半天再回答用户体验反而差。但如果你的场景是代码辅助、数学解题、深度分析报告这类需要高质量输出的地方多花的token完全值得因为一次错误的回答带来的返工成本远高于多付的那点推理费用。4. 常见问题与避坑经验4.1 部署与推理阶段的高频问题最近在社区里看到不少人部署MiMo-V2.6时遇到一些问题这里集中整理几个典型的。输出质量不稳定是反馈最多的一个。同一道题问两遍答案可能完全不一样甚至第二遍的推理过程反而更差。很多人以为这是模型不行其实多半是推理参数没设好。RL训练过的模型对temperature和top_p非常敏感我建议推理时将temperature设置在0.6到0.8之间太高会随机乱说太低又会退化成一个模板机。另外把repetition_penalty开到1.05以上能有效减少长输出的无效重复。显存不足的问题更多出现在自建服务时。如果你把模型加载进去后频繁OOM不要急着换更大的卡先检查两点一是gpu-memory-utilization有没有设到0.9以上二是max-model-len是不是设得过大导致KV Cache吃满显存。通常把上下文长度从32K降到8K显存占用能降三分之一如果业务场景不需要长文本没必要硬撑。推理速度慢也是一个不可避免的现实问题尤其是72B模型在非高端GPU集群上几乎每秒只能出10到20个token。如果只是做测试可以忍如果要做生产强烈建议上量化方案或者换用7B模型做蒸馏版。4.2 复现训练阶段的工程经验如果你决定自己复现一轮RL训练下面这些经验能帮你省不少时间。第一个是学习率和KL系数的配合。我见过很多同学直接照搬SFT的建议学习率去跑RL结果训练直接发散。RL训练用的学习率通常要比SFT小一个数量级比如SFT用1e-5RL用1e-6到3e-6起步。KL惩罚系数则建议从0.01开始走一步看一步不要上来就定一个固定值。第二个是回合长度控制。RL训练时生成的轨迹长度决定了探索空间设太短模型根本来不及展示完整推理链设太长又极端消耗算力。我的经验是从实际任务的最优解长度往上浮动20%~30%再逐步加长。MiMo在训练时使用超长上下文做rollout但那是人家有算力你的小规模复现就没必要逞强了。第三个是数据去重的优先级。自生成数据里重复内容多到惊人尤其当你用同一个种子模型在同一批题目上做多路采样时输出高度雷同。我建议在训练前至少跑一遍MinHash去重否则模型会过度学习高频套路在分布外问题上的泛化能力急转直下。4.3 使用开源模型必须关注的合规项选择开源模型不能只看效果许可协议直接决定了你能否拿去商用。MiMo-V2.6采用的是AI21 Open License允许商用但对使用场景有一些附加限制比如不能用于特定的高风险领域。如果你对接的是金融、医疗这类监管敏感的行业使用前务必把条款里那些禁止事项读清楚免得训练完模型才发现有合规问题。另一个容易忽视的问题是数据合规。如果你在本地部署模型喂给它的业务数据属于你的私有数据这是本地部署最大的优势但如果你调用第三方API数据就会经过对方服务器。做企业内部知识库问答时我强烈建议用本地部署方案敏感数据不出内网这是底线问题。注意即便模型允许商用你用它生成的输出内容仍然可能涉及版权归属问题特别是代码生成场景。在商业化产品里使用模型输出请务必保留人工审查环节不要无脑全自动发布。5. 我对这个方向的一点个人体会把MiMo-V2.6的技术报告完整读下来我最深的一个感受是开源大模型竞争的焦点正在从“谁的底座参数多”转向“谁的训练方法更巧妙”。强化学习规模化让模型学会了自我改进这意味着以后的开源模型差距会更多体现在训练“手艺”上——数据怎么筛选、奖励怎么设计、训练曲线怎么稳定这些才是真正的护城河。对普通开发者和中小团队来说这个趋势其实是利好。以前你缺算力、缺数据连入场券都拿不到现在MiMo把整套方法论开源出来你至少能在一个小得多的规模上把流程跑通然后再思考怎么把它用在自己的垂直场景里。我个人后续比较期待的是这种“自我改进”模式被复制到代码智能体、工具调用等更复杂的场景——毕竟推理题的答案验证容易做实但让模型在一个复杂工具链里自我纠错那才是下一个真正有意思的挑战。