小米 MiMo-V2.6 深度实测:逐张量核对 1.02T 参数,六天 RL 直播日志全量对账

小米 MiMo-V2.6 深度实测:逐张量核对 1.02T 参数,六天 RL 直播日志全量对账

今天凌晨,小米发布并开源了 MiMo-V2.6 系列:Pro(1.02T 总参数 / 42B 激活)、Flash(310B / 15B),外加一个蒸馏到 Qwen3.5-9B 上的 9B 版本,三个仓库都是 MIT 许可。中文圈三个小时内就铺满了,「46 分」「开源第一」「万亿参数」的说法到处转。

参数有多大、榜单第几名,这些转述就够了。我更关心三件能自己动手验证的事:那个 1.02T 是不是真的;把成本、失败、重启都摊在面板上的六天直播,日志里究竟写了什么;以及「开源」这两个字,这次到底覆盖了多少东西。

于是我把三个仓库共 199 个权重分片各取了前几百 KB 的 safetensors 头部(只取头部,没下那 573 GB 权重),把每张张量的 dtype 与 shape 拉下来,逐个数参数;训练面板的接口是公开的,我把两次 RL 每一步的指标全量拉了下来对账;再把 GitHub 上那三个「训练资源」仓库逐一看了一遍。

结论先放前面:参数量没吹,训练日志甚至比技术报告更细,但确实有三处对不上——其中一处是 Pro 这一轮 RL 里没有网络安全数据集。

这次发布的三个模型与它们的骨架

Pro 与 Flash 都是稀疏 MoE 的全模态模型,文本、图像、视频、音频进同一套序列,1M 上下文;第三个 MiMo-V2.6-Distill-Qwen-9B 是把 MiMo 的 agentic 能力蒸馏进 Qwen3.5-9B 的监督微调版,官方定位是「给社区当 agentic RL 的起点」。

骨架上有三个值得记的决策。一是混合注意力:Pro 的 70 层里 60 层是滑动窗口注意力(窗口只有 128),10 层是全局注意力,第 0 层用全局注意力加稠密 FFN 兜住早期表征。二是 MoE 的规模:384 个路由专家、每 token 激活 8 个、没有共享专家,第 0 层之后每层都是 MoE。三是投机解码:随包附了一个 5 层的 DFlash 草稿模型(2.77B 参数,块扩散,一次前向并行猜多个 token),外加 3 层 MTP。

编码器也没含糊:视觉塔 28 层(24 层 SWA 加 4 层全局),音频分词器编码器 308M 参数,音频 patch 编码器把 25Hz 压到 6.25Hz。

RL 侧才是这次真正的新东西。异步 GRPO,每步 1,568 个提示、每个出 16 条轨迹,即每步 25,088 条;训练 30 步。优化器用的是 Muown(Muon 与 Adam 合体),学习率 3e-6,没有 warmup,梯度裁剪 1.0。为了防止专家负载塌陷,RL 期间路由器被整个冻结——报告里给了对照实验:不冻结时第 9 层的专家负载变异系数从 0.78 涨到 2.0、峰值负载从 6 倍涨到 16 倍、冷门专家占比从 0.5% 升到 22%;冻结后三条曲线全部走平。

证据一:把 1.02T 参数一个个数出来

先说方法。HF 上每个分片都是标准 safetensors:文件头 8 个字节是头长度,后面跟一段 JSON,列出该文件里每张张量的 dtype、shape 和数据偏移。所以我只要对每个分片发一个 Range 请求,取前几百 KB 就够了——Pro 130 个分片、Flash 65 个、蒸馏版 4 个,加起来只下了几十 MB,却把三个仓库索引里的 23 万条张量记录全部清点了一遍。

结果是这样的:

项目 官方口径 我从权重里数出来的 差异
Pro 总参数 1.02T 1,024,216,603,392(1.0242T) +0.4%
Pro 每 token 激活 42B 41.89B −0.3%
Flash 总参数 310B(报告)/ 309B(模型卡) 310.76B +0.2%
Flash 每 token 激活 15B 15.45B +3%
视觉塔 681M 681.4M 一致
音频 patch 编码器 127M 126.9M 一致
音频分词器编码器 308M 302.3M(编码器层)加卷积与量化器 一致
蒸馏版 9B 9.41B 一致

每一个数字都能对得上,连「681M 视觉塔」这种边角都对得上——报告的小字写着「编码器参数含输入嵌入、不含投影层」,我按这个口径算,视觉塔的 28 个 block 正好 681.4M,投影层另算 57.7M。

第一个坑:mxfp4 是打包存储的,按字节估算参数会错一半。专家权重在文件里的 dtype 是 U8,一张 down_proj 的 shape 是 [6144, 1024]——但它的逻辑维度是 [6144, 2048],也就是一个字节里塞了两个 4-bit 数。我第一版脚本按元素数直接累加,得到 5240 亿参数,正好是 1.02T 的一半。发现之后按「U8 元素数乘二」重算,才落回 1.0242T。想从下载体积或文件大小反推参数量的人,会被这个坑绊住。

第二个坑:三种精度说法并存。权重索引里的元数据写着 save_format: mxfp4,HF 的标签写着 8-bit 和 fp8,而实际情况是混合的——专家权重是 mxfp4(每 32 个一组带块缩放),多数线性层是 FP8 E4M3,而配置里那份 ignored_layers 名单把全部 70 层的输出投影排除在量化之外、保持 BF16,嵌入与归一化也是 BF16。也就是说,官方文档里的 mxfp4 只描述了专家那一部分(占总参数 97.7%),标签里的 8-bit 说的是另一部分。

顺带得到一个结构上的观察:Pro 每 token 激活的 41.89B 里,专家占 49.7%(20.84B),注意力占 44.7%(18.72B)——两者几乎一样重。原因是 head_dim 192 配上 128 个查询头,qkv 投影一层就是 2.7 万维。MoE 把 97.7% 的参数堆在库里,但每 token 真正动用的计算,有一半还留在注意力上。

证据二:六天直播的日志,对上了什么

训练面板的接口没有鉴权,/api/status/api/series/api/benchmarks/api/notices 都能直接读。我把两次 run 的全部指标拉了下来:

项目 Pro Flash
训练步数 30 30
轨迹总数 752,640 752,640
累计 token 75.0B 81.4B
每步 token(首→末) 1.80B → 3.43B 1.79B → 3.70B
成本 $2,620,671 $854,045
时长 127.5 小时 83.1 小时
重启次数 14 5
基础设施错误率(峰值) 0.98% 3.04%
DeepSWE v1.1(首步→末步) 58.41 → 72.57 48.67 → 65.68

对上的部分很硬:技术报告说 Pro 花了 2.6M 美元、Flash 0.9M,面板上是 2,620,671 与 854,045;报告图 3 说 DeepSWE 从 58.4 涨到 72.6、Flash 从 48.7 涨到 65.7,面板上逐步曲线正好是 58.41 到 72.57、48.67 到 65.68;1,568 乘 16 等于 25,088,乘以 30 步等于 752,640,也都是逐字对得上。合计 347 万美元、每小时 3.08 万美元——媒体算的「约 3.1 万美元每小时」就是这个数。

对不上的地方在「每步 token」。官方发布页写「每次训练步的 token 数达到 3.5~3.7B」,技术报告写 2.7B~3.7B。我把每一步的数值拉出来:Pro 从 1.73B 涨到 3.43B,30 步均值 2.50B,全程没有一步到过 3.5B;Flash 从 1.79B 涨到 3.70B,均值 2.71B。也就是说,发布页那个区间是末期单步的峰值,不是训练的实际水位——报告里的 2.7B 起点同样偏高。

面板上还挂着六条人工通知,我认为这才是「直播」最值钱的部分:

时间 官方在日志里写的话(摘要)
9/17 01:58 更新了 Flash 第 12 步与 Pro 第 8 步的 DeepSWE 离线评测结果
9/17 04:08 一个节点显存出问题,Pro 重启
9/17 10:27 Flash 从第 15 步重跑:某数据集的一类基础设施错误在过去约 3 小时里没被正确检出
9/17 20:20 Pro 集群与评分器之间网络中断,已重启;同时把 cyber 数据集从接下来的 Pro 训练里移除了,因为 rollout 日志里出现了坏 pattern
9/18 11:49 Pro 在第 17 步因专家负载不均导致的 GPU OOM 重启,已调整并行策略
9/19 18:14 我们过滤掉了对当前 Pro 模型来说相对简单的题

技术报告里能对上最后两条:5.5 节写着训练期的失败主要是 GPU 显存双比特错误,以及一次微批次内 MoE 不均衡造成的 OOM——「某一层上,一个专家并行 rank 收到了超过均值 30 倍的 token 负载」。直播里的通知,就是事后复盘时被写进正式报告的那部分;没写进报告的部分,才需要读者自己去对。

把这段通知和面板上的数据集清单对起来看,就出现了第三处对不上。面板给每次 run 列了当前批次里的数据集构成:Pro 是 24 个——11 个 code、4 个 general、3 个 chat、6 个 visual,没有 cyber;Flash 是 25 个,多出 cyber/dataset-9aui。而技术报告第 5.1 节的训练设置写着任务混合包含 4% 的网络安全。

也就是说,从面板能看到的构成里,Pro 这一轮 RL 没有 cyber 数据(再加上 9/17 那条通知,后半程基本可以确认没有),可发布时 Pro 报的是 CyberGym 94.0、内部 Cyber Bench 80.2 这样的网络安全分数。这些分数只能来自 RL 之前的阶段,或者报告那句 4% 描述的是混合计划、不是 Pro 这一轮的实际构成——小米没有解释,公开日志里也查不到补回来的记录。这不是造假,但训练直播最大的价值恰恰是这种能被外部抓出来的口径差:说 30 步、说 1,568 个提示、说 347 万美元都能对上,唯独「训了什么」有一块对不上。

还有一个可以算的账:Pro 这 75.0B token 花了 262 万美元,折合每百万 token 的 RL 成本 34.94 美元。而 MiMo-V2.6-Pro 的 API 输出价是每百万 token 0.87 美元。训练期每 token 的成本,是它自己卖出去的价格的 40 倍——这个比例解释了为什么前沿模型不可能靠 API 收入覆盖训练开支。

证据三:开源开了什么,以及首日的三个可复现问题

三个仓库的权重都能直接下,MIT。Pro 的完整下载量是 573.5 GB:专家分片 563.6 GB、DFlash 草稿 5.5 GB、MTP 2.5 GB、音频分词器 1.9 GB。Flash 178 GB,蒸馏版 19 GB。

训练资源则是另一种形态:GitHub 上那三个仓库——verl(RL 训练框架)、uni-agent(长程 agent 训练)、mimoagent(agentic rollout)——都是别人家仓库的 fork,各自开了一条叫 mimo-oss 的分支,装的是 multi-harness gateway、agentic RL recipes(arvo、code、design、general 四个目录)、rollout 与环境适配器。分支上的提交数是 125(uni-agent)、565(mimoagent)和 2,848(verl,含上游历史),星标 3 到 4 个,issue 0 个。这是研究级的代码投放,不是长期维护的开源项目,别期待有人回你的 issue。

然后是首日就能复现的问题,三个都是我自己跑出来的:

第一,Flash 仓库里的 DFlash 配置不是合法 JSON。dflash/config.json 最后多了一个逗号,json.load 直接抛错,任何按标准流程加载这个草稿模型的脚本都会在这里断掉。Pro 的同名文件没有这个问题。HF 上已经有人提了 PR(第 2 号),截至我写作时仍是 open 状态。

第二,同一份配置里的超参和主配置不一致。Flash 的主 config 里 attention_value_scale 是 0.707,它的 DFlash 配置里却是 0.612——而 Pro 两份都是 0.612。看起来是从 Pro 复制过去之后忘了改。

第三,模型卡把 MTP 和 DFlash 草稿说成了一个东西。Pro 与 Flash 的模型卡都写「MTP:5 层投机解码器」,报告表 1 的「投机解码器」一栏也写 5 层。但权重里那个 MTP 模块只有 3 层(Flash 的 config 也老实写着 num_nextn_predict_layers: 3);5 层的是另一个独立文件,就是前面说的 DFlash 草稿。顺带一提,Pro 的 config 里干脆没有 num_nextn_predict_layers 这个字段,而随包发布的 transformers 建模代码里也一次都没引用它——这两个模块的权重更像是给 SGLang、vLLM 那套推理栈准备的。

另外,技术报告表 1 里 Pro 那一行,「激活参数」印成了 42T(同行的 Flash 是 15B)。这种笔误不影响任何结论,但它提醒你:模型卡和报告是宣传材料,不是规格书。

要自己部署的话,官方给的 SGLang 命令是 16 路张量并行、2 个节点、DeepEP 通信加 EAGLE 投机解码;vLLM 是 8 路。573 GB 是下载量,不是显存需求,但 1M 上下文的 KV cache 和 MoE 通信会把它抬到「要有集群才能聊」的级别。

判断:数字层面很扎实,但别把它读成别的东西

先说值得肯定的。这是我今年核过的国产开源发布里,可验证度最高的一次:参数、成本、每天的进步曲线、失败与重启,全都能从公开渠道复算,而且训练日志的颗粒度比论文更细——技术报告只给了三条曲线和一句「2.7~3.7B」,面板上有每一步 20 多条指标、六条人工通知和 14 次重启的完整记录。这种透明度本身就是发布内容的一部分。

但有三件事别读歪。

第一,「6 天」指的是最后一场 RL,不是模型研发周期。面板上 Pro 的 run 从 9 月 15 日 18:32 跑到 9 月 21 日凌晨 2:01,Flash 更早结束。官方发布页自己写了「这六天背后是半年的基础研究积累与工程试错」。347 万美元是这一场 RL 的账单,不是这个模型的开发成本。

第二,开源的是权重加部分训练资源,不是可复现的训练。预训练数据披露到来源类别为止,约七千个 RL 任务能在框架分支里看到 recipe,但没法把每一批实际任务和某个固定 commit 对上。9B 蒸馏版加那套 RL recipe 其实是这次对社区最有用的东西——比 1.02T 的权重更实用,因为大多数人根本跑不动后者。

第三,榜单数字要打两个折。一个是外部评测的口径:Artificial Analysis 的小米页上,MiMo-V2.6-Pro 的智能指数显示 46(上一代 V2.5-Pro 是 26),中文圈普遍引用的 46.32 是同一指数更精确的小数位。另一个是基准自身的质量:Epoch AI 对 DeepSWE v1.1 的审查认定 113 道题里至少 23 道存在假阴性问题(超过 20.3%),并把整个基准标为 flawed——我读了原文,问题出在验证器会覆盖模型改过的测试文件。面板上那条 58.41 到 72.57 的曲线是这个基准上的,看趋势可以,当绝对刻度不行。与闭源旗舰的差距也还在:ProgramBench 26.5 对 Claude Opus 5 的 37.0,ExploitBench 47.9 对 78.5,Terminal Bench 4.0 是 34.9 对 49.0,GDPval-AA 是 1673 对 1708。

那么谁该动手?做 agentic coding、长上下文、成本敏感场景的人,直接走 API 最省事:Pro 每百万 token 输入 3 元、输出 6 元,缓存命中 0.025 元;Flash 是 1 元与 2 元,批量推理半价。要注意两点:这次新增了一个 mimo-v2.6-pro-ultraspeed 档位,价格是 30 元与 60 元,十倍;另外 V2.5 系列将在 10 月 21 日下线,别把线上业务留在旧模型上。

想做研究者,从 9B 蒸馏版和那套 RL recipe 入手;想自建推理,先数清楚自己有没有 16 张卡和两个节点。至于「1M 上下文」,报告自己写的典型 RL 轨迹长度是 11 万到 15 万 token——容量是容量,有效使用是另一回事。

我核过的那三处对不上——每步 token 的区间、Pro 的 cyber 数据、MTP 的层数——都不改变「这是一次扎实的发布」这个判断。但它们说明一个更通用的道理:当一家公司把训练过程直播出来,它其实同时交出了两样东西:一份成绩单,和一份可以被外部逐条核对的账本。第二样比第一样稀罕得多。

相关阅读: