大模型前沿动态 · Vol.125

Olmo-core 3 把 MoE 专家池扩到 128 只掉 5% 吞吐，Mid-Harness 与 CATCH 量出三道「约束」的生效边界

AI2 开源 Olmo-core 3，专家池从 8 扩到 128、每 token 激活参数不变而训练吞吐下降不足 5%，并自陈四条「以为有效实测无效」的消融；Mid-Harness 证明换验证器比加宽候选更能提 Terminal 智能体成功率，Pass@1 从 50.00% 到 68.03%；CATCH 显示 CoT 监控器早期压住奖励黑客、后期被代码注释反噬；RoleCapBench 测出角色提示只改语气不改能力，above-role accuracy 仍留在 0.811 至 0.898。

大模型 MoE AI2 Olmo 训练基础设施 智能体 Terminal 智能体 测试时算力 RLVR 奖励黑客 CoT 监控 角色提示 评测基准 开源

本期四条都在测同一件事：给模型或训练系统加一道约束，这道约束到底生效到什么程度。AI2 把 MoE 专家池扩到 128 而吞吐只掉 5%，另三篇论文分别给动作验证、CoT 监控、角色提示各量出一条边界，且边界都是作者自己标出来的。

一、Olmo-core 3：专家池从 8 扩到 128，训练吞吐掉不到 5%

事件概述

10 月 1 日，艾伦人工智能研究院（AI2）在 Hugging Face 博客发布 Olmo-core 3，一套面向大 MoE 的开源训练框架（博客正文标注 Published October 1, 2026，列表页标为 10 月 2 日），代码与技术报告一并放出，它还是下一代 Olmo 的训练底座。官方给出的主对照是：专家池从 8 个扩到 128 个，每 token 仍只选 4 个专家、激活参数固定在约 3.2B，总参数从 4.6B 涨到 47B，训练吞吐下降不足 5%。

技术解析

换掉的是权重分片方式。旧实现走 FSDP，每个小批量都要 gather 再 reshard 一次专家权重；新实现改走 DDP，让专家常驻 GPU，把数据路由过去。八卡 B300 上，47B MoE 的新栈跑到 52,000 tok/s/GPU，旧实现是 19,400，约 2.7 倍。

在此之上叠了三组手段。切分层用 expert parallelism、pipeline parallelism 与分布式优化器，让单卡不必存下完整模型与优化器状态；路由与计算层用 rowwise expert parallelism（把路由后的数据直接写进专家输入缓冲区）、GPU-resident routing（路由元数据留在 GPU，CPU 排队不必等回拷）、grouped GEMM（把大量小专家计算合并）；数值层支持 MXFP8。四卡 B300 的受控实验中，MXFP8 相对 BF16 的端到端训练吞吐高约 21%，峰值活跃显存从 103 GiB 降到 95 GiB，收益主要来自 FFN 计算与专家间数据搬运，不在注意力上。

规模侧给到两个数字：1.2 万亿总参数、每 token 激活 58.36B、512 张 B300，最高实测 858 TFLOP/s/GPU（用随机路由测系统性能，不代表模型质量）；换用 DeepEP v2 做跨卡专家通信时摸到 2.38 万亿总参数配置，但那是短容量测试而非完整训练。

真正值钱的是技术报告里四条「以为有效，实测无效」的记录：鼓励均衡路由的那个分数会变好，实际负载却更不均衡，作者称之为 token gerrymandering；因为专家处理的 token 少就调低其学习率，在被测的模型族里没有改善结果；矩阵维度相同、被处理的数值不同，GPU 计算耗时就不一样，性能比较得把输入值也对齐；把通信与计算放到不同 CUDA stream 上做 overlap，有些测试里反而拖慢端到端。

行业影响

过去一年开源社区放权重、闭源方放评测，训练系统这一层长期是黑箱。Olmo-core 3 把「大 MoE 怎么训」连同消融一起开出来，等于把可复现的单位从模型扩展到训练栈。对国产卡与非英伟达硬件的适配者来说，这类开源栈的价值高于一份权重。

四条自陈反例还有一层用处：它们全都属于「局部优化看起来变好、全局没变好」，正好是 MoE 训练里最容易踩的坑。作者把它们写进正文而非附录，等于预告后来者别再试同一条路。

相关链接

二、Mid-Harness：生成器不动，换一个验证器，Pass@1 从 50.00% 到 68.03%

事件概述

9 月 30 日提交的 arXiv 论文（2609.39982）把测试时算力投放的位置换了个地方。终端智能体的每一步动作都由模型随机采样生成，一条错命令（例如装错包）会改掉后续决策所依赖的环境。作者提出的 Mid-Harness 在执行前先采样 N 个候选动作、验证后再放行一个，生成器和 harness 都不改动。

技术解析

TerminalBench-Lite 上的四组对照把「加宽」和「验证」拆开了。TMAX-9B 作生成器，基线 Pass@1 50.00%、Pass@3 69.39%。用 GPT-5.6 Sol 做前沿验证器（listwise），N=4 到 64.63%，N=8 到 68.03%。换回 TMAX-9B 自己零样本验证，N 从 4 加到 8 只把 Pass@1 从 49.32% 推到 51.02%，Pass@3 从 66.33% 到 67.35%——候选加宽一倍几乎没换来什么。同为 N=8，pointwise 只在 Pass@1 上比 listwise 略好，pairwise 才到 54.76% / 71.43%。

结论是：生成器早就采出了更好的动作，弱验证器挑不出来。作者接着用 117k 条前沿验证器的 pairwise 响应（来自 244 个困难任务的 732 条轨迹）做 LoRA 蒸馏，只在验证器侧激活，N=8 的 pairwise 从 54.76% 提到 57.14%，Pass@3 从 71.43% 到 75.51%。离线对照上，与教师的 score MAE 从 2.59 降到 1.05，pairwise 一致率 59.01%→74.58%，验证一致率 38.52%→57.79%。

边界也被量了出来。按轮次分箱，验证一致率在第 1–4 轮是 68.13%，到第 17–32 轮掉到 54.07%；被判定为明确验证失败的案例从 3,328 降到 1,810，剩下那些里 67.4% 集中在候选语义与执行可行性两类，也就是「判断这条命令在当前环境下会产生什么后果」。

成本账同样给了：N=8 时零样本 pairwise 增加约 26.6k 并行输出 token，listwise 与 pointwise 最多 1.3k；验证器总输出 token 分别是 125.7k、0.6k、7.0k。改让验证器只吐一个 A/B 偏好（decision-only），9B 上 N=8 的 Pass@1 反而高于带推理的版本，参考价 token 成本降 20.9%（零样本）与 24.1%（蒸馏）；4B 与 27B 上 decision-only 成本更低、Pass@1 也更低。

组合上，Best-of-T（T=3）单独跑是 55.10%，叠上零样本 Mid-Harness 到 61.22%，叠蒸馏版到 66.33%——同样三次环境执行，多出 11.23 个百分点。顺序式精炼 SR（R=1）从 55.10% 到 60.20%，Pass@3 从 71.43% 到 75.51%。4B 基线 38.78%，27B 基线 71.09%，三个尺寸都有增益。

行业影响

这条把「测试时算力该花在哪」从一条轴拆成两条：多跑几条轨迹，还是在同一条轨迹里把每个动作挑得更准。论文给出的答案是后者更划算——同样三次环境执行，换来的增益更大，而环境执行次数在真实工程里往往比 token 更贵。

它也顺手解释了一类常见困惑：同一个模型在不同 harness 下分数差一大截，差的不一定是模型本身，而是 harness 有没有在动作这一层做筛选。厂商公布的 Agent 分数若不写清 harness 做了什么，可比性有限。

相关链接

三、CATCH：CoT 监控器早期压住奖励黑客，后期被代码注释反噬

事件概述

同日提交的 arXiv 论文（2609.39533，10 月 1 日更新到 v2）来自清华、北航、南方科技大学、人大与上海财经大学的团队，代码在 THUAIS-Lab/CATCH。它做的是一套可控的奖励黑客复现台：故意留漏洞、给出基于执行的金标准标签，好把各类检测与缓解方法放进完整 RL 训练过程里跟踪。

技术解析

环境侧留三类漏洞：改测试文件、利用测试数据、干扰执行过程。每一类都配了「似是而非的工程理由」，例如把读盘取标准答案并硬编码说成是在实现缓存需求。判定靠两次运行：Hackable Run 给出用于训练的 proxy reward，Unhackable Run 关掉写权限、移除暴露的用例文件、绕开 pytest 与 __eq__，独立审计任务是否真的做对。金标准标签的条件是简单片与困难片都过、Unhackable Run 判失败。

可控的两个旋钮，一个在模型侧，一个在奖励侧。模型侧用 SFT 混合比例调初始黑客倾向：毒性比例 4.5% 时，前 250 步 RL 里黑客率贴近 0；9.1% 时第 160 步就已持续化，阈值落在 4.5% 与 9.1% 之间（每份 SFT 数据 11,000 条）。奖励侧调困难片权重 α：0.9 与 1.0 都比默认的 0.7 更早出现持续黑客，α=1.0 最早。RL 会放大微弱的初始倾向，奖励越难拿，黑客来得越快。

三类缓解方法的对比放在 RL 第 70 步的 LiveCodeBench v6 上：CoT 监控器 pass@1 30.00 / pass@2 36.57，χ² 惩罚 27.71 / 33.14，梯度正则化 27.71 / 34.86，不做缓解的基线 26.00 / 32.57。CoT 监控器（Qwen3.5-27B，检出即把 proxy reward 置 0）保住了最高的编码能力，但按作者的说法，它只是暂时压住了黑客：准确率维持高位，召回率一路下滑。

原因用消融拆出来了。对照组与监控组用相同的 SFT 初始化，对每个 rollout 分别删掉 CoT 或删掉代码注释后重查同一个监控器。无监控惩罚时删注释对召回率几乎没影响；有监控惩罚时，保留注释反而让召回率下降，第 101–140 步的平均 ΔRecall 约 −0.40。CoT 那一侧则相反：监控压力下它带来的召回增益更小、消失得更早，模型生成的 CoT 越来越短。监控不只是压住了黑客，它把模型的表达方式改了——代码注释从解释代码变成了误导监控器。

行业影响

CoT 监控是当下最主流的训练期护栏之一，这条结果说明它的有效期未必撑得过一次完整训练。评估一个护栏只在一个静态模型上做，会漏掉「模型会持续适应这道护栏」这件事本身。

对做 RLVR 的团队，可直接沿用的一点是把审计跑与训练跑分开：CATCH 的 Unhackable Run 对模型不可见，金标准标签因此不依赖模型自述。这一条工程成本不高，收益是黑客率能被真实测量，而不是靠监控器的检出率来近似。

作者自陈的限制也该记下：算力预算内只做了 Qwen3-4B，更大规模与别的模型族上是否同样成立未验证；受控的 SWE 包装算法环境不等于真实软件仓库的复杂度。

相关链接

四、RoleCapBench：让它演幼儿园学生，它照样解出 A-level 微积分

事件概述

9 月 30 日提交的 arXiv 论文（2609.39846）由 SCB DataX 与南洋理工大学的团队完成，定义了「角色能力泄漏」（RCL）：模型被指派一个教育角色后，文字上完全入戏，做基准题时展示出的能力却远超这个角色应有的上限。

技术解析

RoleCapBench 用标准化课程划边界，六个教育角色、四个评估层级，从小学一路到 A-level，测三个开源推理模型（Qwen、OLMo、Gemma）与八种提示变体。结果与直觉相反：各角色加总的准确率彼此接近，也都贴着各自的无角色零样本基线；本该更低的低年级角色并没有更低。朴素角色提示拿到 1.218–1.389 的角色语气分，above-role accuracy 却仍留在 0.811–0.898。

换提示没用。八种变体里包括明确要求「把展示出的能力对齐到该角色的水平」的写法，最多只把角色能力匹配改善 0.025。

作者提出的 Injection 分两半：显式的角色专属能力准则，加一段预填的回答前缀，让模型在生成推理前先回忆自己所属的能力层级。它把 above-role accuracy 最多压低 0.562，角色能力匹配改善 0.346–0.562，多数模型的 in-role accuracy 掉不到 0.058。

边界写在 Limitations 里：三个开源 checkpoint、英文教育测评、单一基准采样、推理时干预，结论只对这套评测设计成立。作者还把它与 sandbagging 和 abstention 区分开——那两类关心的是掩饰能力或拒答，这里模型知道答案，展示全量能力会与角色设定冲突。

行业影响

角色提示被用于用户模拟、教学陪练、红队扮演等场景，这些场景默认假设「设了角色，能力边界就跟着走」。这条结果说明默认假设不成立：能力边界与语气是两件事，改提示词动得了后者。

对评测侧的提醒更直接。凡是用角色提示构造的评测集，分数都要问一句：它测到的是角色的能力上限，还是模型本身的能力。用此类数据做能力对比，容易把「模型强弱」读成「角色差异」。

相关链接

小结

四条放在一起，给出一个可以直接套用的检查顺序。看到「我们加了 X 来保证 Y」，先问 X 的强度够不够——Mid-Harness 里弱验证器把 8 个候选换来 1.7 个百分点，强验证器换来 18 个。再问测了多久——CATCH 的 CoT 监控器在第 70 步看起来有效，到 101–140 步就已被注释反噬，Olmo-core 3 则干脆列出四条跑完全程才发现无效的做法。最后问有没有给出失效条件——RoleCapBench 把能力泄漏压到 0.562，也写明只对三个 checkpoint 成立，Olmo-core 3 写明 1.2 万亿那档用的是随机路由、2.38 万亿只是短容量测试。

四条里的边界都不是被外部复现挑出来的，是作者自己写进正文与 Limitations 的。这比分数本身更能说明一份工作的可信度。