Mach-Mind-4-Flash：3B 激活参数，如何靠后训练追上 100B 级模型

一个 3B 激活参数的模型，在 AIME’26 上拿到 92.70，在 IFBench 上拿到 82.82，在 Behavioral-SafetyBench 上拿到 80.74，在 BFCL-v4 上拿到 75.80，在 BrowseComp-zh 上拿到 72.31，在 ClawBench 上拿到 84.20。

这组数字真正刺眼的地方，不是“又一个模型刷榜”。刺眼的是参数量的错位：Mach-Mind-4-Flash 是一个 35B 参数的 MoE，但每个 token 只激活 3B 参数。论文把它放到 Qwen3.5-122B-A10B、Nemotron-3-120B-A12B、MiMo-V2-Flash-309B-A15B、Kimi-K2.5-1T-A32B 这些模型旁边比较，它在若干维度上不是“勉强接近”，而是直接领先。

如果只看摘要，我们很容易把结论简化成一句话：小 MoE 也能很强。但这篇技术报告真正值得读的地方，不在这个口号，而在它试图回答一个更难的问题：当预训练规模不再继续往上堆，后训练到底能不能变成一条可扩展的工程路线？

先把三个概念放在桌面上

第一个概念是 MoE 的“激活参数”。一个稠密模型像一整家公司所有部门同时开会；MoE 更像按任务叫人，模型总参数很多，但每次推理只激活其中一小部分专家。Mach-Mind-4-Flash 总规模是 35B，激活只有 3B，所以它的戏剧性不在“模型很小”，而在“每次真正参与计算的部分很小”。

第二个概念是 post-training，也就是后训练。预训练像把学生送进图书馆读万卷书；后训练像考前集训、专题训练、模拟实战、纠错复盘。过去几年大家习惯把能力提升和预训练算力绑定在一起，但这篇论文押注的是另一件事：如果底座已经不错，能不能靠一套更强的后训练流水线，把它推到大模型能力带里？

第三个概念是“能力跷跷板”。我们想要一个模型既会数学、代码，又会指令遵循、安全、工具调用、网页搜索、长程 agent。直觉上，把所有奖励混在一起做 RL 不就行了吗？问题正出在这里：不同任务的奖励密度、反馈延迟、输出形式、优化目标都不一样。一个奖励把模型往长推理方向拉，另一个奖励又要求它短、稳、守约束；一个任务鼓励探索工具，另一个任务惩罚不必要动作。最后常见结果是，某个能力涨了，另一个能力掉了。这就是论文反复强调的 see-saw degradation。

为什么“把奖励混起来”不够用？

我们先从最朴素的方案想起。假设你已经有数学题、代码题、安全题、工具题、网页搜索题，每个任务都有自己的 reward。那就把这些任务混成一个大 batch，让模型统一做 GRPO 或 PPO，奖励加权求和。听上去既简单又端到端。

但这里有两个隐藏问题。

第一个是奖励本身不在同一把尺子上。数学和代码可以靠最终答案、测试用例给强验证信号；写作和指令遵循需要规则引擎或 judge；agent 任务的好坏常常到几十轮工具调用之后才知道；安全还要区分“拒绝得对”和“拒绝过度”。这些信号被压成一个混合 reward 后，梯度并不会自动理解“每个领域该保留什么”。它只是在当前 batch 上追逐最容易拿到的分数。

第二个是训练顺序会制造依赖链。你可以先训数学专家，再训安全，再训工具；但后一阶段会改写前一阶段学到的行为。你也可以所有领域一起训；但那意味着每一步都要服务一整套异质 reward stack，工程成本和稳定性都变差。论文的说法很直接：无论 staged 还是 jointly mixed，都会出现 pronounced see-saw effect。

Mach-Mind-4-Flash 的路线是反过来的：不要一开始就逼一个模型在所有 reward 之间妥协，而是先让不同能力各自长到足够强。论文把专家分成三条 RL 轨道：Reasoning 负责 Math、Code、STEM；General 负责 Instruction Following、Writing、Safety；Agent 负责 Tool-Use、DeepSearch、Code Agent、Claw Agent。每条轨道用适合自己领域的数据合成、验证器和训练策略。

这一步看似只是“分而治之”，但它改变了后面融合问题的性质。我们不再问：一个模型如何同时听懂所有奖励？而是问：一个学生如何从多个已经稳定的老师那里，把对应能力搬到自己身上？

MOPD：让样本自己找到老师

这就是论文的核心方法 Multi-Teacher On-Policy Distillation，简称 MOPD。

先不要被名字吓住。MOPD 做的事情可以用一个课堂比喻理解：同一个学生在做不同作业时，数学题交给数学老师看，写作题交给写作老师看，工具题交给工具老师看。老师不再参与更新，都是冻结的专家；学生自己先写答案，也就是 on-policy rollout；然后对应老师在学生已经写出的每个 token 位置上给软监督。

关键是“对应”。每个训练样本带一个 teacher_route，训练框架根据这个路由 key 把样本送到相应的 frozen specialist。这样，一个数学样本不会被安全老师监督，一个工具样本也不会被代码老师误导。论文把目标写成 routed mixture of token-level reverse-KL：学生分布 πθ 在自己生成的前缀上，去贴近该领域老师 πTk 的 token 分布。

为什么是 reverse-KL，而且是 on-policy？这里有一个细节很重要。传统离线蒸馏常常让学生模仿老师生成的数据；但部署时学生会走到自己的状态空间里，犯自己的错，遇到自己的前缀。MOPD 让学生先按当前策略生成 rollout，再让老师在这些真实前缀上提供目标。这等于把监督放到学生实际会走的路上，而不是老师理想路径上。

reverse-KL 的直觉也很贴合这个目的。它不是鼓励学生覆盖老师所有可能说法，而是让学生在自己已经选择的 token 路径上，减少和老师的分布差距。论文为了可训练性，用 Schulman 的 k1 单样本估计器：每个 token 只需要学生和老师对该 token 的 log probability 差，不需要传全词表分布。这个工程选择很实际，因为多教师蒸馏如果每步都搬运 full-vocabulary logits，很快会被通信成本淹没。

还有一个容易忽略的工程点：rollout 由 vLLM 推理引擎异步产生，而训练引擎的参数可能已经前进了，所以样本到梯度步时严格说有 off-policy drift。论文在 Appendix B 里给了 clipped policy-gradient surrogate，用 PPO 式 importance ratio 和 0.2 clip 来抑制高漂移领域早期的 loss spike。换句话说，MOPD 不是简单“多个老师 logits 加权平均”，而是一套适配异步大规模训练的路由蒸馏机制。

它解决跷跷板的方式，也就清楚了：混合奖励 RL 是让多个领域在同一个 reward 空间里抢梯度；MOPD 是把每个领域已经学好的策略先固定下来，再按样本路由给学生密集、同质的 token-level 信号。奖励不再直接打架，老师也不会在训练中相互漂移。

论文给的融合结果很有说服力。SFT base 的 IFBench 是 72.79，General expert 到 82.65，MOPD final 到 82.92，不但保住还略高；IFEval 从 92.42 到 expert 94.64，再到 MOPD 94.84；LexInstructEval 从 72.21 到 75.47，再到 75.63。Reasoning 侧，LiveCodeBench-V6 从 SFT 79.39 到 expert 80.23，MOPD final 80.12，基本持平。Agent 侧更复杂：SWE-bench Verified expert 是 73.80，MOPD 后是 71.10，有 2.7 分缺口；但 ClawBench 从 expert 80.30 到 MOPD 83.20，ClawEval 从 67.23 到 70.35，出现正迁移。

这组数字比“平均涨分”更有信息量。它告诉我们 MOPD 不是魔法：高度 scaffold-specific 的长程 SWE 行为仍然会在融合中被磨平一点；但在指令、安全、开放 agent 任务上，多领域能力可以互相补强。

Appendix C 还有一个有趣的消融：在 tool-use + IF + safety 的 MOPD 配置上加入 code teacher，其他不变。结果不仅 LiveCodeBench-V6 +3.81，AIME’25 +2.30、AIME’26 +0.83；连 Behavioral-SafetyBench 也 +4.06，IFEval +2.14，IFBench +0.55，BFCL 基本不变（+0.09）。这说明代码专家不是一个窄能力模块，而像一种“结构化推理和约束执行”的底层能力，会外溢到数学、指令甚至安全。

HMPO：让模型别把会做的题写成论文

MOPD 融合完，模型强了，但另一个问题出现了：强推理模型容易 overthinking。

我们现在已经很熟悉这种现象。模型明明能三步做完，却写出二十步；明明答案已经确定，还要自我检查好几轮。对 benchmark 来说这可能无伤大雅，对线上服务却很贵：更长输出意味着更高延迟、更高 token 成本、更大的 KV cache 压力。

直觉上，我们可以给长度加惩罚。但这会立刻引出 reward hacking：模型为了短，可能直接猜答案；或者把关键推理省掉，准确率下滑。真正难的是同时表达两个优先级：第一必须正确，第二才是短。

HMPO，也就是 Hybrid Median-length Policy Optimization，正是为这个优先级设计的。它从每个 query 的一组 rollout 开始，只看其中正确的那些，取它们长度的中位数作为预算 b。这个选择很聪明：预算不是人工写死的，而是由题目难度自适应产生。简单题的正确 rollout 自然短，预算就紧；难题的正确 rollout 自然长，预算就松。随着策略变好，正确样本变短，预算也会自动收紧。

然后它给 token reward 做一个平滑的 cosine decay：正确且长度小于 b 的轨迹能拿到长度奖励，越接近预算奖励越低；错误或者超预算的轨迹拿 0。最后的总奖励不是相加，而是相乘：R_final = R_acc × R_token。

这个乘法是整件事的安全阀。只要答案错，R_acc 为 0，短也没用；只要超过预算，R_token 为 0，正确但啰嗦也不给效率梯度。这样 HMPO 把“正确优先，长度第二”写进了奖励结构，而不是靠调权重碰运气。

论文报告 HMPO 只用大约 6.5K 高质量数学题训练，group size 为 10，reward offset λ=0.8。更关键的是，训练只在数学上做，但长度控制迁移到了代码、科学问答、指令遵循。摘要中的压缩幅度是 19–46%，准确率损失不超过 0.7 个百分点。Figure 14 还把 AIME’26 的准确率和平均 token 数放在一起：Mach-Mind-4-Flash 在约 13K–14K token 区间进入 92% 以上，而 Kimi-K2.5 约 16.6K token、93.30；Nemotron-3-120B-A12B 是 89.90、约 13.4K。这里真正重要的是 Pareto frontier 的移动：不是单纯更准，也不是单纯更短，而是在更少 token 下仍保住顶级数学表现。

基础设施：论文里最不性感、但最决定成败的部分

如果 MOPD 和 HMPO 是方法名，基础设施就是它们能不能规模化落地的条件。

论文第 3 节先搭了一个统一 RL/OPD 框架。它把损失写成 L = α·L_OPD + β·L_RL。α=0、β>0 时是纯 RL；α>0、β=0 时是纯 OPD；两个都大于 0 时是联合训练。这个设计的价值不是公式复杂，而是把强化学习、在线采样、reward evaluation、policy optimization、distillation supervision 放进同一套分布式调度系统里。

动态多教师架构则解决扩展问题。每个 teacher 是配置树里的独立节点；rollout 结束后，样本按 routing identifier 异步分发给对应 teacher；teacher 返回目标 logits 或 log-prob 后统一聚合算 distillation loss。新增领域老师不需要改训练核心，只要注册配置、加路由列、分配节点。这对一个不断增加业务能力的 agent 模型非常关键：后训练系统不能每加一个任务就重写一次。

算子层面，论文集成 SonicMoE indexed Grouped GEMM，针对 Hopper GPU 的 TMA copy engine、warp specialization、多阶段 producer-consumer pipeline 做优化，减少 token permutation 和全局内存访问；共享专家则通过 AllGather、Expert Computation、ReduceScatter 的分段融合，与普通专家的 Dispatch、Expert Computation、Combine 交错，尽量把通信藏进计算。Appendix A 给了具体速度：tp=8、ep=8 时 656s/step 到 642s/step，约 2%；tp=4、ep=8 时 542 到 531，也是约 2%；tp=8、ep=4 时 681 到 580，达到 17%。摘要里说的 17% end-to-end speedup，就是来自这个配置。

这部分容易被读者跳过，但它其实解释了为什么这篇报告不是一个单点算法 paper。MOPD 要同时服务十多个 frozen specialists；Agent RL 要和环境异步交互；DeepSearch 要在线搜索；Code Agent 要跑容器和测试；HMPO 要做多 rollout 长度预算。如果底层没有统一调度和吞吐优化，方法再漂亮也会卡在 GPU 小时和工程复杂度上。

结果：强在哪里，边界又在哪里

总体评测覆盖八个能力轴。几个最值得记的数字是：AIME’26 92.70，AIME’25 92.08，LiveCodeBench-V6 80.91，GPQA-Diamond 83.08；指令遵循里 IFEval 94.64、IFBench 82.82、LexInstructEval 74.63；安全里 Content-SafetyBench 98.20、Behavioral-SafetyBench 80.74；工具和 agent 里 BFCL-v4 75.80、τ²-bench 80.04、SWE-bench Verified 70.60；搜索里 BrowseComp-zh 72.31；OpenClaw 里 ClawBench pass@3 84.20。

最有戏剧性的不是每个榜单都第一，而是它在哪些榜单上领先谁。IFBench 82.82 明显高于 Qwen3.5-35B 的 70.20、Qwen3.5-122B 的 76.10、Kimi-K2.5 的 67.43；Behavioral-SafetyBench 80.74 比第二名 Kimi-K2.5 的 67.75 高约 13 分，而很多 baseline 只有 20–35；BrowseComp-zh 72.31 高于 Qwen3.5-122B 的 70.30 和 Kimi-K2.5 的 71.28；BFCL-v4 75.80 接近 MiMo-V2-Flash 的 76.30，并超过 Qwen3.5-122B 的 72.20 和 Kimi-K2.5 的 74.50。

这说明 Mach-Mind-4-Flash 的强项不是单一数学推理，而是生产 agent 所需的混合能力：遵循复杂约束、保持行为安全、调用工具、搜索中文网页、完成开放任务。它的后训练路线正是围绕这些能力搭的。

但边界也要写清楚。第一，论文的底座是 Qwen3.5-35B-A3B，强初始化本身贡献很大；Mach-Mind-4-Flash 证明的是“在强底座上，后训练可以极大放大能力”，不是“任何 35B MoE 都能靠同样流程追上 100B”。第二，MOPD 在长程 SWE 上仍有小缺口，说明路由蒸馏会平滑掉部分高度专门化、和 scaffold 强绑定的行为。第三，HMPO 当前主要面向单轮推理链压缩；多轮 agent 轨迹里，模型要在几十轮工具调用之间分配思考预算，这比压缩单条 CoT 难得多。第四，DeepSearch 和长上下文状态保持仍然是紧绷的轴，论文自己也把 persistent multi-constraint web browsing 和 long-context comprehension 列为未来挑战。

这篇论文真正的信号

看完整篇报告，我觉得它的核心信号不是“李想汽车发布了一个强模型”，而是“后训练正在被工程化成一条新的 scaling path”。

过去我们谈 scaling，默认说的是更多参数、更多 token、更多预训练算力。Mach-Mind-4-Flash 展示的是另一种 scaling：更多可验证环境、更多领域专家、更稳定的专家融合、更便宜的 token 预算、更高吞吐的训练系统。它不否认预训练的重要性，但把战场从“底座有多大”转移到“底座之后怎么系统性塑形”。

MOPD 的意义在于，它把多能力融合从混合 reward 的争吵，改成按领域路由的教师监督。HMPO 的意义在于，它把“少想一点”从人工长度惩罚，改成正确性优先的自适应预算。基础设施的意义在于，它让这些方法不是实验室里的单卡技巧，而能承载十多个专家、长程 agent 环境和异步 rollout 的生产级流水线。

如果未来小激活 MoE 模型要真正进入低延迟、高并发的 agent 部署，问题不会只是“模型够不够聪明”。更具体的问题会是：能不能把数学、代码、工具、安全、搜索这些能力同时保住？能不能不要为了一个能力牺牲另一个能力？能不能少输出 40% token 还不掉分？能不能把每一次新增业务能力变成配置扩展，而不是重写训练系统？

Mach-Mind-4-Flash 给出的答案还不是终局，但它把问题问得非常具体，也给出了一套相当完整的工程解法。对今天的 LLM 训练来说，这可能比单个榜单第一更重要。