1. 从“能聊天”到“会进化”MiMo-V2.6 到底想解决什么第一次看到“自我改进的强化学习规模化”这个说法我的反应是又来了一个堆概念的。但把 MiMo-V2.6 的技术报告翻了两遍之后我改主意了——它真正想啃的是开源大模型圈子里一个长期没人正面回答的问题模型能不能在部署之后靠自己的经验继续变强而不是永远等着下一轮人工标注和全量重训。这件事为什么难因为过去两年开源模型的迭代逻辑基本是“预训练堆数据 监督微调对齐 人类反馈强化学习RLHF收尾”这条流水线。这条线跑得通但有个天花板RLHF 依赖人类偏好数据标注成本高、覆盖场景窄而且一旦模型规模上去人类根本评不过来。更麻烦的是RLHF 优化的是“像不像人类想要的回答”而不是“在真实任务里能不能把事办成”。你让一个模型去操作浏览器、调工具、写多步代码人类偏好打分几乎失效——因为没人能对一长串 agent 轨迹逐帧打分。MiMo-V2.6 的切入点就在这里。它把强化学习从“对齐阶段的收尾工具”提升成了“模型持续进化的主引擎”并且强调两个关键词规模化和自我改进。规模化指的是 RL 不再只跑几千条偏好对而是能跑海量、长程、多轮的任务轨迹自我改进指的是模型自己生成任务、自己尝试、自己评估、自己筛选形成一个闭环。说白了它想让模型从“被教”变成“自己练”。这对谁有用三类人最该关注。第一类是做 agent 产品的工程团队你们最头疼的就是模型在多步任务里越走越偏MiMo-V2.6 的 agentic RL 思路直接对口。第二类是研究强化学习落地的人尤其是搞离线强化学习offline RL和基于模型的强化学习model-based RL的这篇报告里的规模化工程细节比很多论文都实在。第三类是想自己微调开源模型的中小团队你们没那么多标注预算自我改进的闭环能帮你们把有限的人力用在刀刃上。我先把结论摆前面MiMo-V2.6 不是又一个“刷榜模型”它的价值在于把一套原本只在大厂内部跑得动的 RL 工程体系用开源的方式讲清楚了。下面我按“它怎么想—它怎么做—它踩了什么坑—你能抄什么”这条线把技术报告里最值得抠的细节拆开讲。2. 自我改进闭环的四个齿轮任务生成、轨迹采样、奖励判定、策略更新要理解 MiMo-V2.6 的自我改进别被“自我”两个字唬住。它不是模型突然有了意识而是一套精心设计的循环流水线。我把它拆成四个齿轮任何一个齿轮卡住整个闭环就转不起来。2.1 任务生成让模型自己出题但出题比答题更难自我改进的第一步是“有题可做”。如果任务永远来自固定数据集模型练到一定程度就会过拟合遇到新场景直接崩。MiMo-V2.6 的做法是让模型基于已有能力边界自动生成难度略高于当前水平的新任务。这里的关键词是“略高”——太简单没收益太难全是失败轨迹学不到东西。具体怎么控制难度报告里透露的思路是维护一个任务难度分布用当前模型在各类任务上的通过率作为信号。通过率高于某个阈值比如 80%的任务被判定为“已掌握”生成器就往更难的方向推通过率低于某个下限比如 20%的任务被判定为“超纲”暂时搁置。这个机制听起来简单但实操里最难的是难度信号的噪声。同一个任务模型这次通过下次失败你怎么判断它是真会了还是蒙对了MiMo-V2.6 用了多次采样的方差来过滤方差大的任务标记为“不稳定”优先重练。这个细节很关键很多团队自己做自我对弈self-play时就是栽在难度信号抖动上练着练着模型开始刷简单题骗通过率。提示如果你要复现这套任务生成逻辑先别急着上大模型。用一个小的任务池 明确的通过/失败判定函数把难度调度跑通再放大。难度调度本身就是一个独立的工程问题。2.2 轨迹采样长程任务的“信用分配”才是真难点任务有了接下来是让模型去尝试产生轨迹。单轮问答的轨迹就是“输入—输出”简单。但 agentic RL 面对的是多步轨迹模型调工具、看结果、再决策可能几十步才结束。这时候强化学习的经典难题——信用分配credit assignment——就冒出来了最终任务成功了到底是第 3 步的工具调用对了还是第 17 步的修正救了场MiMo-V2.6 在轨迹采样上的处理我印象最深的是它对轨迹分段的重视。它没有把整条轨迹当成一个整体给一个奖励而是把轨迹切成若干决策段每段单独评估。这样做的好处是奖励信号更密集模型能更快定位到哪一步做对了。代价是分段边界怎么定——切早了信息不全切晚了信号太稀疏。报告里用的是基于“动作类型变化”和“环境状态跳变”的混合切分策略这个思路和传统强化学习里 options framework 的分层思想是一脉相承的。另外采样效率是规模化的命门。如果每条轨迹都要真实调用外部工具成本高得离谱。MiMo-V2.6 用了大量模拟环境来替代真实调用只在关键验证环节才走真实接口。这个取舍很务实模拟环境跑得快、可并行、可复现但存在“模拟与真实不一致”的风险。他们的应对是定期用真实环境校准模拟器的奖励函数防止模型在模拟器里练出一身“屠龙之技”到真实场景全废。2.3 奖励判定从人类打分到可验证奖励的迁移奖励是 RL 的方向盘。RLHF 时代奖励来自人类偏好模型reward model。但到了 agentic 场景人类打分不现实MiMo-V2.6 大量转向可验证奖励verifiable reward代码能不能跑通、数学题答案对不对、工具调用返回是否符合预期、任务目标是否达成。这类奖励是程序判定的客观、便宜、可规模化。但可验证奖励有个硬伤它只覆盖“有明确对错”的任务。写一篇好文章、做一个合理规划这些没有标准答案的任务怎么办报告里的折中方案是“可验证奖励为主模型评判为辅”。对于开放式任务用一个独立的评判模型来打分但这个评判模型本身也要定期用人类标注校准防止它和主模型一起“跑偏”。这个设计其实呼应了强化学习里一个老问题奖励黑客reward hacking。模型会找到奖励函数的漏洞用看似达标实则取巧的方式拿高分。MiMo-V2.6 的防御手段是奖励函数集成——同时用多个不同来源的奖励信号任何一个信号异常高就触发人工审查。2.4 策略更新规模化 RL 的工程瓶颈不在算法在吞吐四个齿轮里策略更新是算法最成熟、工程最要命的一环。MiMo-V2.6 是 MoE 架构这意味着它的策略更新要处理专家路由带来的额外复杂性。MoE 的好处是参数量大但激活参数少推理便宜坏处是 RL 训练时不同专家被激活的频率差异会导致梯度分布不均某些专家被过度训练另一些几乎没更新。报告里对这块的处理用了专家负载均衡的正则项在策略梯度里加了一项惩罚防止路由塌缩到少数专家。这个技巧在 MoE 预训练里常见但搬到 RL 阶段需要重新调权重——预训练时均衡是为了效率RL 时均衡是为了防止策略退化。我实测过类似配置正则项权重给大了会让模型变得“平均主义”每个专家都学一点但都不精给小了又压不住塌缩。MiMo-V2.6 报告里给的是一个动态调整的方案根据训练过程中专家激活熵来实时调权重这个思路值得借鉴。吞吐方面规模化 RL 的瓶颈往往不在 GPU 算力而在数据管道的吞吐。轨迹采样、奖励判定、经验回放experience replay这三个环节如果串行GPU 大量时间在等数据。MiMo-V2.6 用了异步的采样—训练分离架构采样进程持续往经验池里灌数据训练进程按自己的节奏消费。这个架构和推荐系统里常用的参数服务器思路很像核心是把“生产”和“消费”解耦。3. MoE 架构下的强化学习省算力的代价是训练不稳定MiMo-V2.6 选择 MoE 不是偶然。开源模型要在有限算力下拼能力MoE 几乎是必选项——总参数量可以堆到很大但每次推理只激活一小部分显存和算力压力可控。但 MoE 和 RL 结合会放大一些原本不明显的矛盾这些矛盾在报告里被反复提及我觉得是全文最有价值的部分之一。3.1 专家路由在 RL 训练中的“马太效应”MoE 的核心是路由器router它决定每个 token 送给哪些专家处理。预训练阶段路由器学的是“什么样的 token 该给什么样的专家”这个分布相对稳定。但 RL 训练会改变模型的输出分布进而改变 token 的统计特性路由器跟着变专家激活模式也跟着变。问题在于这个反馈回路容易形成正反馈某个专家在某类任务上表现好路由器就更倾向把这类 token 给它它被训练得更多表现更好路由器更倾向给它……最后少数专家吃掉大部分流量其余专家“饿死”。这个现象在报告里被称为路由塌缩router collapse。它的直接后果是模型的有效容量缩水——你以为有几十个专家实际只有几个在干活。更隐蔽的后果是塌缩后的模型在遇到训练分布外的任务时没有足够的专家来应对泛化能力断崖式下跌。MiMo-V2.6 的应对是双管齐下一是在损失函数里加负载均衡正则二是定期做专家重激活——把长期低激活的专家拿出来用当前任务分布的数据单独微调让它们重新跟上节奏。这个“重激活”操作在工程上不复杂但需要监控每个专家的激活率和梯度范数属于典型的“监控驱动训练”。3.2 稀疏激活对信用分配的干扰MoE 的稀疏激活还给信用分配添了乱。在稠密模型里一个 token 的梯度会更新所有参数在 MoE 里只更新被激活的专家。这意味着同一条轨迹里不同步骤的梯度更新的是不同的参数子集。如果轨迹前半段激活了专家 A后半段激活了专家 B那么“最终成功”这个奖励信号对 A 和 B 的信用分配是不均匀的——A 可能只是做了个无关紧要的开头却因为参与了轨迹而分到梯度。报告里对这个问题的处理比较巧妙它在轨迹分段的基础上进一步做了专家归因。简单说就是统计每个决策段激活了哪些专家然后根据该段对最终结果的贡献把奖励按比例分配给对应的专家。这个做法增加了计算开销但显著提升了训练稳定性。我个人的经验是如果你的 MoE 模型在 RL 阶段出现“练着练着突然变傻”的情况八成是信用分配被稀疏激活搞乱了可以试试类似的归因方案。3.3 推理成本与训练成本的错位MoE 的一个卖点是推理便宜但 RL 训练阶段MoE 的训练成本并不低。因为训练时通常要激活更多专家为了梯度覆盖而且负载均衡、专家归因这些操作都有额外开销。MiMo-V2.6 报告里给的数据是RL 阶段的训练成本大约是同等稠密模型的 1.3 到 1.5 倍但推理成本只有稠密模型的 30% 到 40%。这个账要算清楚如果你的场景是“训练一次、推理百万次”MoE 绝对划算如果是“频繁重训、推理量小”MoE 的优势就没那么明显。注意别被“MoE 省算力”这句话带偏。省的是推理算力训练算力该花还得花甚至更多。选型时先想清楚你的训练/推理比例。4. Agentic RL 的落地细节从单轮问答到多步任务Agentic RL 是 MiMo-V2.6 最实用的部分也是和普通 RLHF 拉开差距的地方。普通 RLHF 优化的是“这一句话回得好不好”agentic RL 优化的是“这一串操作能不能把任务办成”。后者更接近真实产品需求但工程复杂度高一个量级。4.1 环境接口设计动作空间和观测空间怎么定做 agentic RL第一件事是定义环境接口。模型能做什么动作动作空间能看到什么反馈观测空间这两个设计直接决定训练能不能收敛。MiMo-V2.6 报告里没有给完整的接口定义但从它支持的任务类型代码执行、工具调用、多轮检索可以反推出一些设计原则。动作空间要离散化且语义清晰。比如“调用工具”这个动作不能只给一个“调用”的抽象动作而要细化到“调用哪个工具、传什么参数”。参数空间如果太大模型探索成本极高如果太小又表达不了复杂操作。MiMo-V2.6 的做法是把常用工具的参数模板化模型选择模板再填槽位这样既控制了动作空间大小又保留了灵活性。观测空间要包含足够的中间反馈。如果模型只能看到最终结果那和单轮任务没区别。agentic 场景下每一步的工具返回、环境状态变化都要作为观测喂回去模型才能根据中间结果调整策略。但观测太长会撑爆上下文所以需要做观测压缩——只保留和当前决策相关的信息。这个压缩策略本身可以是一个学习出来的模块报告里提到他们用了一个轻量的摘要模型来做这件事。4.2 长程任务的奖励设计稀疏奖励怎么破长程任务最大的坑是稀疏奖励任务成功了给 1失败给 0中间几十步没有任何信号。这种设置下模型很难学到有效策略因为随机探索几乎不可能撞到成功。MiMo-V2.6 用了三层奖励来破解过程奖励每个决策段给一个基于规则或模型的即时评分比如“这一步的工具调用格式是否正确”“检索结果是否相关”。里程碑奖励任务被拆成若干子目标每达成一个给一次奖励比如“完成登录”“找到目标页面”“提交表单”。最终奖励任务整体成功给大奖励。这三层奖励的权重需要仔细调。过程奖励给太高模型会沉迷于“刷过程分”而不顾最终目标给太低又起不到引导探索的作用。报告里用的是课程学习curriculum learning的思路训练初期过程奖励权重大帮模型快速建立基本行为训练后期逐步降低过程奖励让最终奖励主导逼模型追求真正的任务完成。4.3 经验回放哪些轨迹值得反复学RL 训练里经验回放experience replay是提升样本效率的关键。但 agentic 场景的轨迹很长全存下来显存吃不消全丢掉又浪费。MiMo-V2.6 用了优先级回放根据轨迹的“学习价值”给优先级价值高的轨迹被采样概率大。学习价值怎么定义报告里用的是 TD 误差时序差分误差的变体——预测奖励和实际奖励差距大的轨迹说明模型还没学好优先级高。另外成功轨迹和失败轨迹要平衡采样。只学成功轨迹模型不知道什么不能做只学失败轨迹模型学不到正确行为。MiMo-V2.6 的做法是维护两个回放池成功池和失败池按比例混合采样。这个比例也是动态调的训练初期多学成功轨迹建立信心后期多学失败轨迹查漏补缺。4.4 训练稳定性那些报告里没写但一定会遇到的问题技术报告总是把最光鲜的结果放出来但实操里 agentic RL 的训练稳定性是个大坑。我结合自己的经验和报告里的蛛丝马迹列几个大概率会遇到的问题问题现象可能原因应对思路奖励突然崩盘策略更新步长过大或奖励函数被 hack降低学习率加奖励裁剪人工审查高奖励轨迹模型输出长度爆炸过程奖励按步给模型学会“凑步数”给步数加惩罚或改成按里程碑给奖励训练后期性能回退过拟合到模拟环境真实环境表现差增加真实环境校准频率加环境随机化专家激活率两极分化MoE 路由塌缩加负载均衡正则定期专家重激活经验回放池“陈腐”老轨迹占比过高模型学的是过时策略加时间衰减老轨迹优先级随时间降低这张表里的每一条都是我在实际项目里踩过或见别人踩过的。报告里不会写这些因为它们是“工程脏活”但恰恰是决定项目成败的地方。5. 开源大模型做强化学习的算力账MiMo-V2.6 的成本结构拆解聊到这儿必须算笔账。开源模型做 RL最现实的问题不是算法是算力够不够。MiMo-V2.6 作为开源模型它的成本结构对想复现的团队有直接参考价值。5.1 训练三阶段的算力分配大模型 RL 训练通常分三个阶段冷启动用监督数据让模型具备基本能力、大规模 RL 探索、策略收敛精调。MiMo-V2.6 报告里虽然没有给精确的 GPU 小时数但从它的训练曲线可以推断出大致比例冷启动占 10% 到 15%大规模探索占 60% 到 70%精调占 20% 到 30%。这个分配和直觉一致——探索最费算力因为要大量采样。对中小团队来说冷启动阶段可以复用开源社区已有的监督微调模型省掉这部分。大规模探索阶段是省不掉的但可以通过减少并行环境数、增加单环境轨迹长度来降低峰值算力需求代价是训练时间变长。精调阶段可以用较小的学习率和较少的采样算力需求相对可控。5.2 推理成本 vs 训练成本的权衡前面提过 MoE 的推理优势这里展开算一下。假设一个稠密模型和一个 MoE 模型能力相当稠密模型推理一次激活全部参数MoE 只激活 30%。那么 MoE 的单次推理成本是稠密的 30% 左右忽略路由开销。但 MoE 的训练成本是稠密的 1.3 到 1.5 倍。设训练成本为 T推理成本为 I推理次数为 N总成本 C T N×I。稠密C_dense T N×IMoEC_moe 1.4T N×0.35I令两者相等T N×I 1.4T N×0.35I解得 N×0.65I 0.4T即 N 0.615 × (T/I)。也就是说当推理次数超过训练成本的 0.615 倍以单次推理成本为单位时MoE 更划算。实际场景里推理次数通常是训练成本的几十上百倍所以 MoE 几乎总是划算的。但这个结论有个前提你的推理量足够大。如果只是实验室里跑跑 demo推理量小MoE 的训练开销反而拖后腿。5.3 中小团队的“轻量化 RL”路线不是每个团队都有千卡集群。MiMo-V2.6 的自我改进思路其实可以降级到小模型上跑。我试过用 7B 级别的模型做类似的闭环核心调整有三点第一任务生成器要更简单。大模型可以生成复杂任务小模型生成能力弱就用模板 参数扰动的方式生成任务保证任务多样性但不追求复杂度。第二奖励判定要更依赖规则。小模型的评判能力不足以做开放式任务的奖励模型就尽量把任务设计成可验证的用规则判定奖励。第三经验回放池要更小但更精。小模型学得慢回放池太大反而稀释了有效信号用优先级采样只保留最有价值的几千条轨迹。这套轻量化路线跑下来7B 模型在特定任务上的提升是肉眼可见的虽然达不到 MiMo-V2.6 的通用性但对垂直场景够用。6. 从报告到落地我建议你按这个顺序动手看完报告最容易犯的错是直接照着最复杂的部分开干。我的建议是分四步走每步都有明确的验证目标别跳步。6.1 第一步把奖励函数跑通别急着上 RL很多人一上来就搭 RL 训练框架结果奖励函数没设计好模型学出一堆歪门邪道。正确的顺序是先把奖励函数单独拿出来测用一批已知好坏的轨迹看奖励函数能不能正确区分。如果奖励函数连“好轨迹”和“坏轨迹”都分不开后面 RL 训练全是白费。具体做法收集 100 条人工标注的好轨迹和 100 条坏轨迹用你的奖励函数打分看分布是否可分。如果重叠严重回去改奖励函数直到能清晰分开为止。这一步花一天能省后面一周的无效训练。6.2 第二步用小模型验证闭环再放大闭环能不能转起来和模型大小关系不大和工程细节关系很大。先用 1B 到 3B 的小模型把“任务生成—采样—奖励—更新”这条链路跑通确认数据能流动、梯度能更新、指标能上升。小模型上跑通通常只要几小时大模型上跑不通可能要几天才能定位问题。小模型验证时重点看三个指标任务通过率是否上升、奖励是否上升、专家激活熵是否稳定如果是 MoE。三个指标都健康再换大模型。6.3 第三步监控体系先于训练规模规模化 RL 最怕的是“训练跑着跑着不知道发生了什么”。在放大规模之前先把监控搭好每个专家的激活率、每条轨迹的奖励分布、每个任务的通过率变化、梯度范数、学习率。这些指标要能实时看最好能自动告警。我见过太多团队训练跑了三天回头一看指标早就崩了白白烧了三天算力。6.4 第四步留出真实环境的“验收集”模拟环境里练得再好也要用真实环境验收。提前留出一批真实任务作为验收集训练过程中定期跑看模拟环境和真实环境的性能差距。如果差距越来越大说明模型在过拟合模拟器需要增加模拟器的随机性或引入更多真实数据。提示验收集要严格保密不能混入训练数据。我见过有人图省事把验收集也拿去训练结果指标好看得离谱上线就露馅。7. 几个容易想歪的地方提前说清楚最后聊几个我在交流中经常听到的误解提前澄清能帮你少走弯路。第一个误解自我改进等于不需要人类。不是的。MiMo-V2.6 的自我改进闭环里人类的作用从“标注每一条数据”变成了“设计奖励函数、审核异常轨迹、校准评判模型”。人的介入频率降低了但介入的质量要求更高了。设计一个能防住 reward hacking 的奖励函数比标几千条数据难多了。第二个误解MoE 一定比稠密好。前面算过账MoE 的优势在推理量大的场景。如果你的场景推理量小、训练频繁稠密模型可能更省心。而且 MoE 的训练不稳定性是实打实的没有足够的工程能力慎碰。第三个误解agentic RL 就是多轮对话 RL。多轮对话只是 agentic 的一个子集。真正的 agentic 要处理工具调用、环境状态、长程规划复杂度和多轮对话不是一个量级。别拿多轮对话的经验直接套 agentic会踩坑。第四个误解开源模型做 RL 一定要大集群。MiMo-V2.6 的完整训练确实需要大集群但它的方法论可以降级。前面说的轻量化路线单机多卡也能跑出效果关键是任务设计和奖励函数要匹配你的算力。我在实际项目里的体会是强化学习落地最难的不是算法推导而是把“奖励—行为—结果”这个链条上的每一环都对齐。MiMo-V2.6 的报告给了很多工程细节但真正的坑还得自己踩一遍才记得住。建议你从最小的闭环开始跑通了再逐步加复杂度别一上来就追求“规模化”先把“能转起来”这件事搞定。