小米把 RL 训练"直播"了——从 MiMo-V2.6 训练仪表盘读出的一切
强化学习（RL）阶段一直是各家大模型最黑盒的一环：你只知道它训完了，不知道它训了多久、烧了多少钱、中间炸过几次。 小米这次把一个正在跑的 RL 训练过程做成了公开仪表盘（https://mimo.xiaomi.com/rl/），step 数、累计 token、美元成本、pass rate、梯度范数、KL 散度全部实时挂在网上。 我把它扒了一遍，聊聊能从这些数字里读出什么——以及哪些数字容易被误读。
数据口径（先说清楚，免得后面扯皮）
- 数据来源：小米 MiMo 官方 RL 训练仪表盘 https://mimo.xiaomi.com/rl/ ，快照时间 2026-09-20 11:10 前后（北京时间）。仪表盘是实时的，你隔几小时再刷新，下面几乎所有数字都会变。
- 事实 vs 推算：凡表格里直接列出来的都是页面上原样抓取的；凡是"约""推算""粗算"标注的，都是我从这些数字算出来的推导，不是官方口径。
- 不确定的地方我会直说：比如仪表盘标题栏写 flash 停在 step 30，但 feed 区最后一条记录是 step 31——这类不一致我按原样保留，不做脑补合并。
先说结论
- ✅ MiMo-V2.6-Flash 已停止训练（2026-09-19 停止，跑了 30 步、3 天 11 小时、81.4B token、75.3 万条样本，累计花掉 85.4 万美元）。
- ✅ MiMo-V2.6-Pro 仍在训练（截至快照跑到 step 27 完成 / step 28 进行中，4 天 16 小时、65.1B token，已经烧掉 231.5 万美元——相当于 flash 全程的 2.7 倍，而它还没跑完）。
- ⚠️ PRO 在评测上并不是全面领先：代码类两项 pro 领先（DeepSWE +5.24、内部编码榜 +1.57），但 AutomationBench v1.0.6 上 flash 反而高 1.70 分（52.70 vs 51.00）。别默认"越大越强"。
- ⚠️ 别拿 avg@n 横向比较两个 run：pro 0.603 看着比 flash 0.644 低，但两者起点不同（pro 起点约 0.565、flash 约 0.514），而且 pro 刚做了一次"剔除过易任务"，会主动把 pass rate 压下去。涨幅 flash +0.130、pro +0.038 说明的是训练增益，不是绝对强弱。
- Pro 中途炸过一次：官方 notice 明说 step 17 时因专家负载不均导致 GPU OOM 而重启，随后调整了训练并行策略。这是 MoE + RL 场景的经典坑，小米把它公开写在页面上，很实在。
- 一次 RL 训练的真实价签：flash 全程 85.4 万美元；pro 已 231.5 万美元且还在涨。折合单 token 成本 flash 约 10.5 美元/百万 token、pro 约 35.6 美元/百万 token（约 3.4 倍）——这是"大模型后训练到底多贵"最直观的一组公开数字。
一、仪表盘里到底有什么
页面上并行挂着两个 run，核心数字如下（原样抓取）：
| 项目 | mimo-v2.6-flash | mimo-v2.6-pro |
|---|---|---|
| 状态 | stopped（已停止） | in progress（训练中） |
| 起始时间 | 2026-09-15 15:16 UTC （北京 09-15 23:16） |
2026-09-15 10:32 UTC （北京 09-15 18:32） |
| 结束 | 2026-09-19（北京约 10:21） | — |
| 已运行时长 | 3d 11:05:40 | 4d 16:37:45（截至快照） |
| 步数 | step 30（feed 末条为 step 31） | step 27 完成，step 28 进行中（已 2h42m） |
| 累计 token | 81.4B | 65.1B |
| 最近一步 token | 3.7B（step 30） | 3.15B（step 27） |
| samples trained | 753k | 677k |
| batch 配置 | 1,568 × 16 seqs | 1,568 × 16 seqs |
| 累计成本 | $854,044 | $2,315,205 |
| dynsam/avg@n（Δ vs step 1） | 0.644（▲0.130） | 0.603（▲0.038） |
评测分数（avg@3）
| 基准 | mimo-v2.6-pro | mimo-v2.6-flash | 差值 |
|---|---|---|---|
| DeepSWE v1.1（mini-swe-agent） | 70.92 | 65.68 | pro +5.24 |
| In-house Coding Bench（内部编码榜） | 64.44 | 62.87 | pro +1.57 |
| AutomationBench v1.0.6 | 51.00 | 52.70 | flash +1.70 |
训练中的实时指标（最新一步）
| 指标 | pro | flash（末步） |
|---|---|---|
| dynsam/avg@n | 0.603 ▼0.019 | 0.644 ▼0.019 |
| critic/rewards/mean | 0.587 ▼0.00979 | 0.601 ▲0.00269 |
| actor/entropy_loss | 0.457 ▲0.00111 | 0.471 ▲0.00254 |
| actor/pg_loss | 0.00823 ▲0.00384 | 0.026 ▲0.014 |
| actor/grad_norm | 0.00482 ▲0.00014 | 0.00628 ▼0.00152 |
| train_infer_diff/new_infer/kl | 0.0074 ▲0.00296 | 0.011 ▲0.00452 |
二、五个能从数字里读出来的门道
1. 每一步的"配方"是固定的：1,568 × 16 = 25,088
两个 run 的 batch 配置都写着 1,568 × 16 seqs——即每个 step 取 1,568 个 prompt，每个 prompt 采样 16 条序列，合计 25,088 条序列/步。
这个数字能对上"samples trained"：
- flash：25,088 × 30 步 = 752,640 ≈ 页面上的 753k
- pro：25,088 × 27 步 = 677,376 ≈ 页面上的 677k
对得严丝合缝。也就是说，"samples trained" 基本等于 step 数 × 25,088，它衡量的是"喂进去多少条轨迹"，不是"用了多少道题"。
avg@n 里的 n 就是这里的 16——每个 prompt 采 16 次，取平均通过率。这是 agentic RL 里判断"这道题难不难"的标准做法：同一题跑 16 遍，全过说明太简单（该剔除），全挂说明太难（也该剔除）。仪表盘里还有 dynsam/passrate/zero 和 dynsam/passrate/one 两个指标，正好对应这两类。
2. Token 是随 step 膨胀的，不是匀速的
- flash 全程 81.4B token / 30 步 ≈ 平均 2.71B/步，而最后一步（step 30）是 3.7B
- pro 全程 65.1B / 27 步 ≈ 平均 2.41B/步，而 step 27 是 3.15B
越到后面，单步消耗的 token 越多。这不是巧合——agentic RL 里，模型变强后会写出更长的推理链、调更多轮工具、产生更长的轨迹。同样的 batch 配方，实际 token 量在涨。
推论：按初始 step 的成本去估算整轮 RL 预算，一定会低估。这个坑在自己做 agentic RL 预算时尤其要防。
3. 钱：flash 85 万，pro 231 万（还在烧）
这是整页最刺眼的两个数字。折合一下：
| 口径 | flash | pro |
|---|---|---|
| 累计成本 | $854,044 | $2,315,205 |
| 单 token 成本（推算） | 约 $10.5 / 百万 token | 约 $35.6 / 百万 token |
| 单步成本（推算） | 约 $2.85 万/步 | 约 $8.57 万/步 |
| 单步耗时（推算） | 约 2.77 小时/步 | 约 4.17 小时/步 |
pro 的单步成本约 flash 的 3 倍、单步耗时约 1.5 倍。粗算的话，pro 若按 flash 的 30 步收尾，还要约 3 步 ≈ 12~13 小时，累计成本大概落在 250 万美元量级（纯推算，仅供参考）。
一句话感受：一次前沿 RL 后训练，就是"百万美元级、三五天、几十步"这个量级。以后再看到"某某模型 RL 阶段训了 N 天"的说法，拿这组数字当锚点。
4. 动态采样（dynsam）：为什么 avg@n 不能横向比
页面顶部两个 run 的 avg@n 分别是 pro 0.603、flash 0.644。如果直接比，会得出"flash 比 pro 还强"的错误结论。三个原因让它不可比：
- 起点不同：各自 Δ 是相对自己 step 1 的。反推起点——flash 约 0.514（0.644−0.130），pro 约 0.565（0.603−0.038）。pro 起步就更高。
- 题库在动态变化：动态采样会不断剔除过易/过难的题目，剩下的题难度分布一直在变。
- pro 刚刚主动加难：官方 notice 明说"我们过滤掉了当前 pro 模型觉得相对容易的任务"。过滤容易题，pass rate 必然被压低——所以 pro 最新一步 avg@n 是 ▼0.019 的下降，不代表训崩了。
顺带看一眼采样器的实时快照，能看出 agentic RL 的"流水线"长什么样：
| pro（step 28） | flash（step 31，末条） | |
|---|---|---|
| accepted / target | 1,944 / 1,568 | 2,704 / 1,568 |
| judged | 1,865 | 2,559 |
| pass rate | 0.614（n=3,164） | 0.547（n=13,430） |
| remaining（待判） | 663 + 931 partial + 280 rewarding | 107 + 1,001 partial + 390 rewarding |
| prewarm | 512 | 297 |
accepted 数明显超过 1,568 的目标（pro 124%、flash 172%），说明采样器会超量收货再筛选/留作后续候选，而不是凑够就停。
5. 一次 OOM 事故：专家负载不均 → 改并行策略
页面 notices 区两条公告，信息量很大：
1d 23h ago — the pro run restarted at step 17 due to a GPU OOM issue caused by expert load imbalance. we have adjusted the training parallelism strategy.
16h 55m ago — we filtered out tasks that are relatively easy for the current pro model.
第二条前面讲过了。第一条值得单独说：MoE 模型在 RL 训练中因专家负载不均（expert load imbalance）导致 OOM。
MoE 的路由是动态的，某些专家会被打到爆、某些闲着，显存占用随路由分布剧烈波动；RL 又比 SFT 更容易把分布推歪（策略在变，路由也在变）。一旦某个 rank 上的专家被灌爆，就是 OOM。解法是调整训练并行策略（换 EP/TP 切分或加负载均衡约束）。
小米在这个方向上有对口论文——2025-10 的《Stabilizing MoE Reinforcement Learning by Aligning Training and Inference Routers》。仪表盘里那个 train_infer_diff/new_infer/kl 指标（pro 0.0074、flash 0.011）盯的就是训练与推理之间的分布/路由差异。（论文题目与指标名的对应关系是我按语义推断的，官方未明示。）
这种"训练炸了、写明原因、公开在页面上"的做法，在行业里相当罕见。多数实验室只会给你一个漂亮的最终分数。
三、这不是一次纯代码 RL：看 batch 的题目构成
仪表盘还公开了每一步训练样本的类别构成。以 pro 的 step 27 为例：
| 类别 | 数据源数 | prompts | 占比 | Δ 占比 |
|---|---|---|---|---|
| code | 11 | 1,061 | 67.7% | ▲0.7 pt |
| visual | 6 | 270 | 17.2% | ▼0.7 pt |
| general | 4 | 190 | 12.1% | ▲0.5 pt |
| chat | 3 | 47 | 3.0% | ▼0.5 pt |
| cyber | 1 | 0 | 0.0% | — |
| 合计 | 25 | 1,568 | 100% |
三点观察：
- 代码是主战场（67.7%），但远不是全部。视觉占了 17.2%，还有 general、chat、cyber——这是一次多模态 + 多任务的混合 agentic RL，不是单点的代码 RL。
- 25 个数据源同时供题，且占比在缓慢漂移（code ▲0.7pt、visual ▼0.7pt），说明配比是动态调整的，不是写死的。
- cyber 在这一步挂 0——但在 flash 的 feed 里出现过
cyber/dataset-9aui。某些类别在某些 step 上缺货，是采样器的正常波动，不是故障。
四、PRO 不是全面领先：AutomationBench 的反超
这点值得单独拎出来，因为它打破了"PRO 一定更强"的默认假设。
| 基准（avg@3） | pro | flash | 谁赢 |
|---|---|---|---|
| DeepSWE v1.1 | 70.92 | 65.68 | pro，+5.24 |
| In-house Coding Bench | 64.44 | 62.87 | pro，+1.57 |
| AutomationBench v1.0.6 | 51.00 | 52.70 | flash，+1.70 |
解读（含不确定性，请注意）：
- pro 的分数是"中间 checkpoint"，它还在 step 28 上跑，这三行数字随时会变。flash 是终局分数、pro 是过程分数，严格来说不可直接 PK。
- 代码类差距最大（+5.24），这也符合 batch 构成——67.7% 的训练预算压在代码上。
- AutomationBench 上 flash 反超，可能意味着这类"自动化流程/办公操作"任务对模型规模不那么敏感，延迟和成本反而是更关键的约束。如果你关心的是这类场景，别急着等 PRO。
结合小米的产品线（MiMo-V2-Flash: Blazing speed meets frontier performance 的定位一直存在），flash 版本的定位本来就不是"弱化版"，而是速度/成本优先的并行版本。
五、这套公开仪表盘，对做 RL 的人有什么可抄的？
如果你自己也在做后训练或 agentic RL，这个页面相当于一份免费的工程 checklist：
| 做法 | 为什么值得抄 |
|---|---|
| 公开 step 级成本 | 让"这一步值不值"变成可讨论的问题，而不是黑盒 |
| 公开 Δ vs step 1 | 只看绝对分数会误导，看增益才有意义 |
| 动态采样：剔除过易/过难 | 省算力，把预算压在"有梯度信号"的题上 |
| 公开 batch 类别构成 | 配比漂移是 RL 崩坏的主要诱因之一，盯着看比事后复盘强 |
| 盯 train_infer_diff KL | 训练/推理不一致是 RL 训练不稳的头号嫌疑 |
| 出事故写明根因 | "OOM 因专家负载不均"这种信息，同行能直接避雷 |
反过来说，如果你只是用模型的人，这份仪表盘给你的是另一件事：判断一个模型的 RL 阶段到底投了多少。30 步 vs 27 步、81.4B vs 65.1B token、85 万 vs 231 万美元——这些数字比任何宣传语都更能说明厂商在 RL 上的投入强度。
六、想追更的话，盯这几个数
PRO 还在跑，仪表盘实时更新。想跟进度，重点看：
- step 数：flash 停在 30，pro 现在 27/28。看 pro 最终停在哪一步——这可能是判断"是否收敛"的间接信号。
- cost so far：目前 $2,315,205。每步约 $8.57 万，看它最终停在哪。
- avg@n 的 Δ：现在 ▲0.038。如果连续几步 Δ 走平甚至转负，说明增益见顶。
- AutomationBench 的反转：pro 现在落后 flash 1.70 分。看它训练结束时能不能翻过来——这是"PRO 到底强在哪"最直接的证据。
- notices 区：还有没有新的事故公告。
附：数据口径与免责说明
- 本文所有事实性数字均来自小米官方仪表盘 https://mimo.xiaomi.com/rl/ 在 2026-09-20 11:10（北京时间）前后的快照，未使用模型记忆补写。
- 标注"推算""粗算""约"的数字为我根据页面数据自行计算，非官方口径，仅供参考。
- 仪表盘为实时页面，你阅读本文时数字很可能已经变化，请以页面当前值为准。
- 文中对指标名与小米已发表论文之间关联的推断（如
train_infer_diff与 MoE 路由对齐论文的对应）属于语义层面的推测，官方未明示。 - 论文列表（MOPD、ARL-Tangram、HySparse、MiMo-V2-Flash Technical Report、Stabilizing MoE RL by Aligning Training and Inference Routers 等）来自小米 MiMo 官网 https://mimo.xiaomi.com/ 的公开列表。
posted on 2026-09-20 11:24 fox_charon 阅读(131) 评论(0) 收藏 举报
浙公网安备 33010602011771号