Step 3.5 Flash 技术报告全文
本文译自 StepFun 团队的 Step 3.5 Flash: Open Frontier-Level Intelligence with 11B Active Parameters1，2026 年 2 月 11 日提交 arXiv，2 月 23 日更新至 v2，署名 216 位作者。原文 67 页，这里是全文翻译，覆盖摘要、§1 引言、§2 架构、§3 基础设施、§4 预训练与中期训练、§5 后训练、§6 评测、§7 局限，以及附录 A（架构细节）、附录 B（局部激活爆炸的详细分析）、附录 C（Step 预训练数据基础）、附录 D（后训练细节）、附录 E（详细评测协议与 prompt）。附录里的贡献者名单按姓名排列，不逐条抄录。评测 prompt 模板按原文逐字保留在代码块里——它们是实际跑评测时喂给模型的字符串，译过去就不是原文用的东西了。
摘要
我们推出 Step 3.5 Flash，一个稀疏 Mixture-of-Experts（MoE）模型，弥合前沿级 agentic 智能与计算效率之间的落差。我们关注的是构建 agent 时最要紧的两件事：推理要锋利，执行要又快又可靠。围绕这两个优先级，Step 3.5 Flash 用 196B 参数的底座 承载高保真建模，用 11B 激活参数 保证推理效率，并以交错的 3:1 Sliding Window / Full Attention 和 Multi-Token Prediction（MTP-3）把多轮 agentic 交互的延迟和成本压到最低。为了逼近前沿级智能，我们设计了一套可 scale 的 RL 框架，把可验证信号与偏好反馈整合在一起，同时在大规模 off-policy 训练下保持稳定，从而在数学、代码和工具使用上持续自我提升。
Step 3.5 Flash 在 agent、编码和数学任务上展现出强劲的智能水平：IMO-AnswerBench 85.4%、LiveCodeBench-v6（2024.08–2025.05）86.4%、$\tau^2$-Bench 88.2%、BrowseComp（带上下文管理）69.0%、Terminal-Bench 2.0 51.0%——与 GPT-5.2 xHigh、Gemini 3.0 Pro 这类前沿模型处在同一水平。通过重新定义效率前沿，Step 3.5 Flash 为在真实工业环境中部署复杂 agent 提供了一个高密度的底座。
1 引言
开源大语言模型（LLM）234567 在可验证任务8910 上已经迅速缩小了与闭源前沿系统111213 的差距，但随着 agentic 系统日益重要，新的挑战也随之出现。具体来说，开源模型在复杂推理上仍然落后于闭源前沿；更要紧的是，关键的效率瓶颈阻碍了它们在长上下文 agentic 任务141516171819202122 上的应用，更别说部署到边缘或资源受限的场景里。
在设计 Step 3.5 Flash 的架构时，我们盯住两个核心方面：效率和容量。我们采用稀疏 MoE2324252627 架构（MoE），总参数 196B、每 token 只激活 11B，配合 3:1 的 sliding-window attention（SWA）滑动窗口注意力28（Sliding Window Attention）与 full attention 比例，以及 multi-token prediction（MTP-3）多 token 预测2930314（MTP）来降低长上下文延迟。为了在混合注意力下以最小的开销提升容量，我们把 SWA 层的 query head 数从 64 增加到 96，并采用 head-wise gated attention32。这套设计支撑了大规模在线部署：上线 OpenRouter33 的第一周，模型在 Hopper GPU 上稳定跑到约 170 token/s。
在预训练一侧，我们把稳定性当作一等要求，通过一个轻量的异步 metrics server 配合 micro-batch 级的连续日志，搭起了一整套可观测性与诊断栈。这套基础设施让我们能系统性地识别并缓解大规模 MoE 的失败模式（例如 Muon 相关的精度敏感性、专家坍缩34，以及激活爆炸635）。结合一个改进版的 Muon 优化器36——它给出更准确、更稳定的更新——我们在 17.2T 高质量、多样化的 token 上完成了稳定训练，全程只出现一次瞬时 loss spike。在这个稳定的训练机制下，Step 3.5 Flash Base 在数学、编码和知识 benchmark 上对上体量更大的同类模型（如 DeepSeek-V3.2-Exp Base2 和 Kimi-K2-Base6）也具备竞争力。值得注意的是，它在 SimpleQA37 上拿到 31.6%，超过了 DeepSeek-V3.2-Exp Base，而参数量只有后者的三分之一。
译注：这里的 17.2T 与 §4.2 训练课程给出的口径对不上——那里写「预训练约 17.6T token、mid-training 750B token」，而两个预训练阶段是 14.6T + 3T = 17.6T。原文两处并存，本译文照抄未改。
朝着前沿级智能走，当前的后训练系统面临两个紧密耦合的挑战：用于自蒸馏的领域专精专家模型迭代效率低2345，以及强化学习（RL）在 MoE 模型的长程推理上难以 scale。训练单个通才去直接覆盖各种领域，往往会牺牲领域专长；而维护一组独立的专家模型则导致碎片化，持续多模型迭代的成本难以为继。同时，当模型被推向更深的推理轨迹时，off-policy rollout 里哪怕很小的 token 级差异，也会累积成高方差的梯度。这个效应在 MoE 模型上格外严重——专家级的 routing 会引入更大的分布漂移，在前沿性能区间破坏优化的稳定性3839402。
为了解决这些问题，我们提出一套构建在共享 SFT 基础之上的、面向大规模 RL 的统一后训练配方。这个框架在领域专精和全局综合之间交替，既能高效迭代专家，又始终维持单一的高性能通才模型。一个专门的 mid-training 阶段把上下文窗口扩到 128k，并通过合成数据强化核心的 agentic 与推理能力，为下游后训练提供强初始化。为了在这个统一框架内支撑稳定且可 scale 的 RL，我们引入 Metropolis Independence Sampling-Filtered Policy Optimization（MIS-PO）4142，用 token 级和轨迹级的离散分布过滤取代连续的 importance weighting。通过把优化限制在一个稳定 trust region 内的样本上，MIS-PO 大幅降低了梯度方差，同时保留了有效的学习信号，使 RL 能够可靠地 scale 到长程推理和 agentic 行为。
尽管只有 11B 激活参数，Step 3.5 Flash 在广泛的推理和 agentic benchmark 上都达到了与领先前沿模型及系统相当的表现。在标准推理设置下，它在推理任务上给出强劲结果，包括 IMO-AnswerBench43 85.4% 和 LiveCodeBench-v6（2024.08–2025.05）10 86.4%；同时也展现出稳健的长程、工具增强能力：$\tau^2$-Bench16 88.2%、BrowseComp（带上下文管理）18 69.0%、Terminal-Bench 2.017 51.0%。配上 PaCoRe44 deep think 推理，Step 3.5 Flash 在那些需要延长思考和多轮综合的推理密集型 benchmark 上进一步提升。综合来看，这些结果说明 Step 3.5 Flash 在推理和 agentic 两个方向上都显著缩小了先进开源模型与前沿闭源系统之间的差距。
2 架构
2.1 设计理念
Step 3.5 Flash 的架构体现了模型—系统协同设计上的一次范式转变。除了智能和成本这两个传统目标，自主 agent 的时代把第三个关键约束提到了同等重要的位置：推理延迟。在交互式 agentic 工作流4546 里，把延迟压到最低直接换来任务完成的 wall-clock 时间下降；反过来看，也可以在固定时间预算内通过 test-time scaling47484944 换到更高的智能。
agentic 负载通常呈现出一个鲜明的画像：大量的上下文 prefill，随后是漫长的多轮交互式 decode。因此，我们围绕低 wall-clock 延迟沿三条互相耦合的轴来协同设计 Step 3.5 Flash：attention（加速长上下文处理，并且和 MTP 亲和性好）、稀疏 MoE（避免分布式部署中拖慢吞吐的 straggler），以及 multi-token prediction（MTP，通过 speculative decoding 加快生成）。
Attention。为了加速 prefill，我们采用混合注意力机制505135 来缓解长上下文处理的二次复杂度。对 decode，我们优先考虑与 speculative decoding52 的架构兼容性——在带宽受限的硬件上，验证效率是最主要的杠杆。这两点考虑推出了两个注意力设计决策：
-
Sliding-Window Attention（SWA）。我们选 SWA28 而不是 linear attention853 来最大化 decode 效率。虽然两者都是线性复杂度，但 linear attention 的状态更新机制会让 speculative decoding 所需的高效 draft tree 生成和并行 tree 验证变得复杂545556。相比之下，SWA 保留了标准 attention 的语义，天然适合通过 $KV$ masking 做并行验证。而且，在没有确凿实证表明 linear attention 能给 agentic 任务带来更好的长上下文建模的情况下，我们发现窗口大小 $W{=}512$ 的 SWA 在 kernel 效率与捕捉局部依赖之间取得了很好的平衡。
-
硬件对齐的 Grouped-Query Attention（GQA-8）。瞄准标准 8 卡服务器节点的部署，我们把模型配成 8 个 $KV$ head（GQA-8）57。这让 $KV$ cache 的分片（KV-Cache 基础）与 8 路张量并行对齐，改善内存访问模式。关键在于，GQA-8 虽然让 attention 更加受内存带宽约束，但它同时也腾出了计算余量，可以吸收 speculative 的起草和验证开销，从而在不付出等比例延迟代价的前提下做激进的多 token 投机。
稀疏 MoE。在前馈一侧，我们采用细粒度 MoE2324252627 来降低 FFN 的平均计算量，同时保持容量。我们用 expert parallelism（EP）26 实现可 scale 的部署。但在 EP 下，端到端延迟可能被 routing 不均衡引起的 straggler 主导：token 分配的偏斜把负载集中到少数专家及其所在的 GPU 上，在同步点处卡住整体吞吐。因此我们引入一种 EP-Group Balanced MoE Routing 策略。
Multi-Token Prediction（MTP）。为了进一步降低自回归延迟，我们把 MTP5830 作为 speculative decoding52 的互补杠杆纳入进来。为了让投机保持轻量，我们借助 SWA 和稠密 FFN4 来精简 MTP head。
我们进一步把模型规模限制在 200B 参数以内，使其能在高端工作站 128GB 的内存预算内做高性能推理。
2.2 混合注意力的稀疏 MoE 主干
如 Figure 2 所示，Step 3.5 Flash 采用 45 层的稀疏 MoE Transformer 主干（3 个稠密层加 42 个 MoE 层），搭配一套专门设计的混合注意力层布局。每个 MoE 层包含 288 个 routed expert 加 1 个 shared expert，top-$k$ router 每 token 激活 $k{=}8$ 个专家。这个配置既维持了庞大的知识容量（总参数 196B），又把每 token 的激活限制在 11B，确保推理延迟低到足以支撑高响应性的 agent 交互。Table 6 汇总了 Step 3.5 Flash 的关键架构超参数。
混合注意力层布局。为了在长上下文效率与稳健的长程连通性之间取得平衡，Step 3.5 Flash 采用 $3:1$（SWA : Full）比例的交错注意力布局，灵感来自 355159，记作 $S3F1$。这个配置重复一个四层的基本单元：三个 SWA 层（$W{=}512$）后接一个 full GQA-8 层。但在我们最初的实验里，朴素的交错策略在各种 benchmark 上都稳定地不如稠密注意力 baseline（Table 10）。为了在不引入实际开销的前提下弥合这个性能差距，我们借助两个互补的增强：（i）增加 SWA 的 query head 数，（ii）采用 head-wise gated attention32。
加大 SWA 的 query head 数。用更多的 query head（从 $64$ 增到 $96$）有效缓解了从统一的 full-attention 架构切到 $S3F1$ 布局时通常会看到的性能下降（Table 10）。我们认为这几乎是一顿「免费的午餐」。因为在长文本场景下，朴素 SWA 的开销本来就很小，即便我们的方案把它显著放大了也还是小。
Head-wise Gated Attention。朴素 SWA 的一个局限是，当输入窗口里没有有用信息时，它无法有效吸收用不掉的 attention 权重60616232。此前的工作354 引入可学习的、数据无关的 sink token 放进窗口来解决这个问题。我们则选择了另一条路：整合一个参数高效的 head-wise gating 机制633264，它可以被看作是引入了数据相关的 sink token。实现细节和进一步讨论见附录 A.1。head-wise gating 对理论 FLOPs 和实际延迟的影响都可以忽略。关于 gating 和加大 SWA head 数的更多性能分析与基准测试，见附录 A.2。
MoE 的专家并行负载均衡。我们用 loss-free load-balancing3065 来促使 token 在专家间达到全局均衡。但这个做法并不保证 micro-batch 级别上各 EP rank 之间的负载均衡，可能导致 straggler 和吞吐下降。因此我们引入一个 EP 级的均衡损失，显式地促进 rank 级利用率的均匀27。
EP 把专家集合 $\mathcal{E}$ 切成 $G$ 个互不相交的组 $\{\mathcal{E}_g\}_{g=1}^{G}$，分布在各 rank 上。对 token $t$，令 $S_t$ 表示 top-$K$ 专家（mask $s_{t,e}=\mathbf{1}[e\in S_t]$），$p_{t,\cdot}$ 表示 routing 概率。那么 EP 负载均衡损失 $\mathcal{L}_{EP}$ 为：
$$ \begin{aligned} p_e &= \frac{1}{T}\sum_{t=1}^{T} p_{t,e}, \qquad f_e = \frac{1}{TK}\sum_{t=1}^{T} s_{t,e}, \\ p_g &= \sum_{e\in\mathcal{E}_g} p_e, \qquad f_g = \sum_{e\in\mathcal{E}_g} f_e, \\ \mathcal{L}_{\mathrm{EP}} &= G\sum_{g=1}^{G} f_g\,p_g. \end{aligned} $$Multi-token Prediction（MTP）。为了在长上下文 agentic 负载上加速 speculative decoding，我们挂上三个轻量的 MTP head。每个 MTP head 由一个 SWA 和一个稠密 FFN 构成，只增加 0.81B 参数（约 $0.41\%$）。我们按 head 在标准 LM head 之外额外的预测偏移来给它们编号：对 $h\in\{1,2,3\}$，MTP-$h$ 基于位置 $t$ 处的主干 hidden state 预测 token $x_{t+1+h}$。为了控制训练开销，我们在大多数训练阶段只激活并优化 MTP-$1$。等主干训练得差不多了，我们用 MTP-$1$ 初始化 MTP-$2$ 和 MTP-$3$，在一个轻量的后训练阶段联合训练所有 MTP head。受 Fast-MTP66 启发，我们在 MTP head 的各预测偏移上采用位置相关的损失重加权，避免对远距离 token 的预测过度优化。
2.3 架构消融与结果
我们做了大量实验来验证 Step 3.5 Flash 的关键设计选择，聚焦于（i）注意力布局，包括 SWA 和 head 数的 scaling，以及（ii）head-wise gated attention 对比 sink token。为了确保效率优化不会拖累模型表现，我们采用两套互补的消融协议：一套评估覆盖预训练、32k 长上下文扩展和 64k 上下文监督微调（SFT）的完整端到端流水线，另一套把分析规模推到 100B 参数，研究这些设计选择随规模变化的行为。所有表格的详细架构与评测设置见附录 A.4。下面总结这些大规模实验的关键发现。
SWA 与长上下文的关系。我们把一个 30B-A3B 模型走完整流水线训练（1.4T token 预训练后接 SFT），来评估混合注意力对推理和长上下文表现的端到端影响。我们消融了四种注意力布局：全 full attention（$FFFF$）、SWA/full 交替（$S1F1$）、3:1 的 SWA-to-full 布局（$S3F1$），以及加大 SWA query head 数的 $S3F1$ 变体（S3F1+Head）。为了隔离出注意力结构本身的影响，我们把 SWA 窗口大小固定为 $W{=}512$ 并关闭 MTP（见附录 Table 9 和 Table 10）。
Table 1 显示各布局之间有清晰的成本—质量权衡。$S3F1$ 拿到最低的注意力侧 FLOPs（prefill 和 decode 分别各自归一到 1.00），而 $FFFF$ 的开销约为 $S3F1$ 的 $2.68\times$ / $2.90\times$；但 $S3F1$ 表现出一致的质量退化（例如 LongCtx 从 28.8 掉到 27.5）。
加大 SWA query head 数在很大程度上补回了这个损失。值得注意的是，S3F1+Head 在预训练阶段就已经超过 $FFFF$（55.7 对 54.1），后训练之后仍保持竞争力：LongCtx 从 27.5 提到 28.2，Sci 从 42.4 提到 44.0，以几乎可以忽略的额外注意力开销补上了与 $FFFF$ baseline 的大部分差距。剩下的劣势有限且局部（例如 Code 小幅掉到 18.3），而整体质量趋势是偏向 S3F1+Head 的。
有意思的是，交替的 $S1F1$ 布局给出最好的整体 SFT 质量和最强的 LongCtx 分（29.6），但需要显著更高的注意力侧 prefill/decode FLOPs（约 $1.58$ / $1.65$），相对 S3F1+Head 大约贵 60%。因此我们把 S3F1+Head 定为长上下文 agentic 负载的默认配置，优先要它低得多的 prefill/decode 成本，同时长上下文表现强且稳定。
| 布局 | SWA head 数 | 相对 FLOPs（Decode / Prefill） | 预训练均值 | Reasoning | Math | Code | Sci | General | LongCtx | 均值 |
|---|---|---|---|---|---|---|---|---|---|---|
| $FFFF$ | 32 | ~2.68 / 2.90 | 54.1 | 40.8 | 40.9 | 19.6 | 42.7 | 26.5 | 28.8 | 33.2 |
| $S1F1$ | 32 | ~1.58 / 1.65 | 54.6 | 42.1 | 42.3 | 19.3 | 44.5 | 26.8 | 29.6 | 34.1 |
| $S3F1$ | 32 | 1.00 / 1.00 | 53.6 | 40.2 | 40.4 | 18.9 | 42.4 | 25.4 | 27.5 | 32.5 |
S3F1+Head |
48 | ~1.01 / 1.02 | 55.7 | 40.6 | 40.3 | 18.3 | 44.0 | 26.0 | 28.2 | 32.9 |
Table 1：30B-A3B 上的下游结果。$F$ 表示 full attention，$S$ 表示 SWA。$S3F1$ 指混合布局里三个 $S$ 层后接一个 $F$ 层。相对 FLOPs 归一到 $S3F1$ 配置，并在 64k/256k 上下文上取平均（Table 8）。预训练均值汇总了通用、数学和代码 benchmark 的结果（Table 10）。
| 方法 | BBH | MMLU | GPQA | MBPP | C-EVAL | CMMLU | 均值 |
|---|---|---|---|---|---|---|---|
| Sink Token | 70.6 | 65.1 | 27.2 | 61.2 | 76.2 | 74.6 | 62.5 |
| Head-wise Gate | 73.7 | 67.0 | 28.1 | 62.6 | 77.9 | 77.1 | 64.4 |
Table 2：$S3F1$ 布局下 100B-A10B 模型的仅预训练评测。head-wise gating 在各 benchmark 上都稳定超过固定的 sink token，整体均值也是如此。
Head-wise Gated Attention 对比 Sink Token。我们在一个 100B-A10B 的 MoE 上做了放大规模的受控预训练实验，在贴近真实的 scaling 条件下研究注意力侧的机制。具体来说，我们在把注意力布局固定为同一套 $S3F1$ 配置、窗口大小 $W{=}512$ 的前提下，对比 sink token 和 head-wise gated attention。如 Table 2 所示，head-wise gating 稳定地改善质量，把平均表现从 62.46 提到 64.43（+1.97）。因此我们在后续研究中把 head-wise gated attention 定为默认机制。
3 基础设施
3.1 计算集群
Step 3.5 Flash 在一个 4,096 张 NVIDIA H800 GPU 的大规模集群上训练。每个节点含 8 张 GPU，通过 NVLink 和 NVSwitch 互连，提供高带宽的节点内通信。节点间连接方面，集群依赖 8×200 Gbps 的 RoCE 链路，在大规模下维持高效的同步和数据交换。
3.2 训练框架
Step 3.5 Flash 的训练由我们内部的 Steptron 框架驱动，它是一个构建在 PyTorch67 和 Megatron-LM68 之上的轻量高性能系统。Steptron 把完整的模型开发流水线统一起来，在同一套工程栈下支撑大规模预训练、后训练和强化学习（RL）负载。
Step 3.5 Flash 采用混合并行策略，包括 8 路流水线并行（PP）69 配虚拟流水线阶段（VPP）、8 路专家并行（EP）26，以及 ZeRO-1 数据并行（DP）70。为了让 Step 3.5 Flash 训得高效，我们用了下面这些工程手段。
解耦的并行策略。参照 Megatron-Core71，我们实现了一套解耦的并行方案，允许 attention 和 MoE 模块使用不同的并行策略。我们给它们分配独立的并行组，并在各模块对应的数据并行组内做梯度 reduction 和 scaling。
通信优化。解耦后的 attention 和 MoE 各自的 DP 通信流会同时打满 RoCE 链路，由于拥塞导致 DP 开销显著上升。为此我们提出两个互补的通信优化，合起来把迭代时间最多缩短 5%。第一，fabric 感知的通信调度 把 DP 流量切分成节点内 NVLink 和节点间 RoCE 两个阶段，并把它们流水起来，把两套 fabric 都吃满。第二，通信感知的 rank 摆放 用作业级的通信画像来在各交换机之间安排 rank，减少跳数，把重流量从交换机间的热点上引开。
Muon 的 ZeRO-1 重分片。Muon36 做 Newton–Schulz 正交化需要完整（未分片）的逐参数梯度，这与 ZeRO-170 的 reduce-scatter 相冲突——后者把一个参数的梯度切分到各 DP rank 上。Megatron-LM 当前的实现是在 Muon 更新前朴素地 all-reduce FP32 梯度来重建完整梯度，但通信量几乎翻倍。我们的做法是把整个参数分配给某个 DP rank，并把梯度缓冲区重排成 rank-major 的布局，这样一次 reduce-scatter 就能把每个参数的完整梯度送到它的属主手里。由于按最「胖」的 rank 做 padding 带来的开销会随数据并行规模增长，我们只对专家参数用这个方案，非专家参数仍走 DP all-reduce。相比朴素的 all-reduce baseline，这套混合策略把端到端迭代时间减少约 5%，额外显存不到 4 GB。
GPU kernel 优化。我们也在 kernel 层面做优化来提升训练效率。attention 里，我们把 QK normalization 与 RoPE 融合。MoE 里，我们把多个小算子融合以减少 kernel launch 开销和内存流量，并实现了一个带 grouped GEMM 的融合 MoE gather/scatter，做法类似 SonicMoE72。
细粒度选择性 checkpointing。我们的训练框架支持逐层、子模块级开关的细粒度激活重计算（例如 attention、FFN、normalization、SiLU 和 MoE permutation），使我们能只对最吃显存的组件做选择性重计算，以极小的开销降低峰值显存。
3.3 高吞吐轻量监控
我们采集了一整套指标（例如每个 micro-batch 内的专家分布、梯度范数）来做训练的细粒度监控。但遥测的规模非常大：一个 4,096 卡的负载每次迭代会产生近 600 万条消息。在主循环里做同步的全局 reduction 会引入好几秒的显著开销，等于把迭代时间翻倍，这对高性能训练显然不可接受。为了缓解这一点，我们开发了一个轻量 Metrics Server，把遥测处理从训练路径上解耦出来。每个 rank 使用 StepRPC——我们自研的异步通信框架——把本地指标异步卸载到远端服务器。这个做法把遥测开销降到每次迭代约 100 ms。
Metrics Server 缓冲收到的指标，只在收到所有参与 rank 的 end-of-iteration 信号之后才触发 reduction 和数据库持久化，消除了主循环里的同步。为了以低延迟摄取并处理数百万条消息，服务器实现为一个高并发的多进程系统，含两个解耦的模块：（i）为高吞吐摄取优化的 Message Receiver，（ii）负责聚合与持久化的 Reduction Processor。通过在这两个模块内部以及模块之间挖掘多核并行，服务器能跟上遥测流，确保指标管理永远不落后于训练。
4 预训练与中期训练
概述。本节总结我们的预训练和 mid-training 过程，重点是大规模稀疏 MoE 训练在实践中的稳定性约束。我们先讲训练稳定性的诊断与缓解（§4.1），然后详述预训练和 mid-training 用的课程，包括数据配比、时间表和关键超参数（§4.2）。
4.1 训练稳定性
训练稳定性是大规模稀疏 MoE 预训练的一等要求。为了让稳定性变得可操作，我们基于一个轻量的异步 metrics server 加 micro-batch 级的连续日志（§3.3）建了一整套可观测性与诊断栈。这套基础设施对优化器级和专家级的信号都提供了细粒度的可见性，使我们能系统性地缓解大规模 MoE 训练中反复出现的失败模式。
实践中，我们发现三种主要的不稳定，指标栈能帮我们及早暴露、精确定位：（i）瞬时 loss spike 以及偶发的随机数值爆炸，由 Muon36 在降精度下数值敏感的极分解迭代引起；（ii）专家侧坍缩（「死专家」），即使 router 的 dispatch 统计看起来仍然健康也可能发生；（iii）局限在少数专家上的局部激活爆炸。
在这些诊断指引的缓解措施之下，预训练 loss 全程保持平滑，只出现一次 loss spike。Figure 3 展示了学习率 cooldown 之前的完整曲线。
4.1.1 Muon 的数值敏感性
Muon 通过 Newton–Schulz（NS）迭代73 来近似一个半正交的更新方向。在早期实验里，我们发现换用收敛更快的正交化近似能带来温和但一致的 loss 下降。因此我们采用 Polar Express74 迭代，固定跑 $T{=}6$ 步，在优化质量和吞吐之间取平衡。
不过，即便用了推荐的安全 scaling74，我们仍偶尔观察到陡峭且不可恢复的 loss spike。这些 spike 是非确定性的（从附近的 checkpoint 重启往往就避开了），提示这是数值层面的病态。模拟表明，bfloat16 的 Polar Express 在某些更新统计量下，会因为加法的累积误差而在极少数情况下产生极端的中间 outlier。于是我们只把 Polar Express 迭代（状态和中间量）转成 float16，训练的其余部分仍保持混合精度。改完之后 spike 不再复现。
4.1.2 超出 routing 坍缩的专家坍缩
我们此前的工作 Step-334 报告过，MoE 训练可能出现「死专家」，通常描述为某些专家长期只收到极少的 token dispatch，因而拿不到有效的梯度信号。在我们之前的调查中，我们发现即使 router dispatch 保持稳定，专家坍缩也能以一种专家侧的病态表现出来，即专家激活消失、专家参数范数停滞或衰减。
我们观察到两个因素影响特别大：（i）routed expert 的聚合需要显式的 scaling。在引入 shared expert 时，必须引入一个显式的缩放因子来校准 shared expert 与 routed expert 之间的相对贡献。较小的模型或许能隐式学到这种平衡，但更大的模型在自我校准上不那么可靠。一旦失配，即使 routing 频率看起来健康，routed expert 的有效贡献也会被压制。（ii）在细粒度稀疏下，micro-batch 均衡可能过于严苛。对稀疏、细粒度的 MoE 设计，micro-batch 级的负载均衡约束（如 Switch 风格 routing23 里常见的实现）可能变得过于严格。正如 75 所分析的，micro-batch LBL 可能引入过度的跨专家竞争，妨碍有效的专精化。
因此我们更倾向于更宽范围的均衡（例如全局 batch 统计）7576，或基于观测到的负载做 loss-free 的 bias 调整6530。实践中，router dispatch 统计通常是稳定的，并不是专家坍缩的敏感指标。我们建议监控专家侧的信号，包括逐专家的激活范数（例如 MoE FFN 中间层的 RMS / 平均范数）和参数范数（例如专家投影矩阵的 Frobenius 范数）。当一部分专家的激活/更新趋近于零而中位数仍然稳定时（例如 min-to-median 比值在下降），这就是专家「死亡」的一个早期预警。
4.1.3 MoE 层里的局部激活爆炸
随着主训练阶段专家专精化逐渐成熟，我们在更深的 MoE 层里观察到一种局部的稳定性病态。具体来说，少数专家（往往每层只有一两个）的激活范数迅速增长，而同一层里的大多数专家仍然表现正常。这种反差造成一个重尾的激活分布：激活范数的中位数保持稳定，但最大值爆炸，大幅增加数值溢出和下游不稳定的风险。
Figure 4 展示了这个失败模式。值得注意的是，这个内部的不稳定被训练 loss 完全掩盖了——尽管 Panel (a) 里的范数在爆炸，loss 却几乎没有变化。我们通过监控逐专家 FFN 输出范数的离散程度来追踪这个现象。如 Panel (b) 和 (c) 所示，中间层（例如第 38 层）的分布保持稳定，而最后几层（即第 45 层）的最大值（实线）与中位数（虚线）之间的差距在迅速拉大。这说明激活能量正在危险地集中到深层网络中少数「流氓」专家身上。为了缓解，我们评估了两种不同的干预手段：
- 对专家投影做权重 clipping：我们约束 MoE FFN 专家投影矩阵的范数。对每个专家投影矩阵 $W$，如果它的最大激活范数 $\max_x\lVert Wx \rVert$ 超过阈值 $\tau$，就按 $W \leftarrow W \cdot \frac{\tau}{\max_x\lVert Wx \rVert}$ 重新缩放。这类似于 attention 里的 MuonClip6，但我们是在 checkpoint 上离线做 clipping，而不是训练中实时做。
- 在专家内部做激活 clipping：我们在输出投影之前，直接对 MoE FFN 的中间激活做逐元素 clipping，做法同 35。
尽管在 Figure 4 (a) 里不同缓解策略的训练 loss 看起来难以区分，max-to-median 比值可靠地把底层的不稳定揭示了出来。如 Panel (b) 和 (c) 所示，激活 clipping 保证了内部范数的稳定轨迹，而单靠权重 clipping 无法阻止 outlier 专家再次出现。因此，我们把逐专家激活范数的 max-to-median 比值确立为监控训练稳定性的一个稳健且必要的指标。
激活爆炸由若干因素驱动。我们观察到高频的 bi-gram 会触发专家专精化。在使用 pre-norm7778 时，单个专家可以无界地放大自己的输出并主导最终的输出范数，导致近乎确定性的预测行为。SwiGLU79 会加剧这个风险——gate 分支与 up-projection 分支之间的强对齐会产出幅值极端的稀疏激活。Muon 则通过放大持续存在的低秩更新进一步加速了这种坍缩。详细分析见附录 B。
4.2 训练课程
训练从广泛的开放域覆盖出发，逐步走向越来越 agentic、越来越长上下文的专精化。我们首先在 4k 上下文、用一个广泛的开放域混合做预训练来建立通用能力，然后把混合 anneal 到更高质量的知识和更多的软件开发数据（代码、PR、issue、commit），同时把上下文窗口扩到 32k。接着，一个专门的 mid-training 阶段把上下文窗口从 32k 扩到 128k，以强化长程推理，并为下游后训练和 agentic 负载提供更好的初始化。整体上，我们预训练约 17.6T token，mid-training 750B token。
4.2.1 数据配比
我们的语料把通用开放域数据和面向 agentic 的数据结合起来。下面总结主要来源，更多细节见附录 C。
通用知识数据。为支撑广泛的世界知识，我们构建了 StepCrawl（附录 C.1.1），一套超越标准 Common Crawl80 的自研爬取与筛选基础设施，从网页（HTML）以及书籍/文档类来源（ePub/PDF）大规模收割数万亿高质量 token。所有内容都经过多阶段质量过滤、站点/类目打标、去重和清洗。
代码数据。强代码能力是 agentic 模型的基础。我们的代码语料用一个改造过的 OpenCoder81 流水线来筛选和精炼。我们把过滤从零容忍策略放宽到允许每篇文档有 0–6 个启发式违规（附录 C.2.1），在质量与多样性之间取平衡，并在 annealing 和 mid-training 阶段上采样以代码为中心的数据，以强化 agent 相关的编程能力。
PR/Issue/Commit 数据。为了更好地匹配真实软件工程工作流，我们从 star 数 10+ 的 GitHub 仓库筛出一个全面的 PR/Issue/Commit 数据集（附录 C.2.2）。它包含：（1）Base Data，用 git diff 验证过（并与 benchmark8215 做了去重）；（2）PR-Dialogue Data，用 Agentless 风格的模板83 从 PR 线程和 commit 中导出，用于文件定位和代码修复；（3）用于 mid-training 和后训练的派生软件工程语料。
工具使用与推理数据。为了提升工具使用的稳健性和多步推理能力，我们加入了跨数学/代码/科学/通用知识的合成与半合成数据，以及针对搜索 agent、SWE agent 和工具执行的领域特定样本。在 mid-training 阶段，我们进一步引入长上下文样本（自然长文档和长篇合成任务），以强化在超长上下文上的规划与推理。
4.2.2 时间表
预训练时间表。预训练分两个阶段：
- 预训练阶段 1：开放域预训练（14.6T token，4k 上下文）。广泛的开放域训练，最大化覆盖面和基础能力。
- 预训练阶段 2：annealing + 长上下文初始化（3T token，4k 到 32k 上下文）。我们把数据混合 anneal 到以代码和 PR/Issue/Commit 为中心的来源上，同时提高高质量知识和推理密集样本的比例。这个阶段先用 2T token 在 4k 上下文上跑，然后在同样的 annealed 混合下转到 1T token 的 32k 上下文，为长上下文训练做初始化。
Mid-training 时间表。mid-training 也分两个阶段：
- Mid-training 阶段 1：32k 上的专精化（386B token，32k 上下文）。我们回放 81B token（21%）的预训练数据来缓解分布漂移、稳定专精化，同时侧重软件工程和工具使用为中心的混合。
- Mid-training 阶段 2：长上下文专精化（364B token，128k 上下文）。我们保留 10.5B 回放 token，并用合成长程推理与自然长文档（从预训练数据里挑长度 $>32$k 的）的混合，加上代码 agent、搜索 agent 和工具使用的领域数据，进一步专精长上下文能力。
4.2.3 超参数
预训练超参数。整个预训练使用 Muon 优化器36，weight decay 设为 0.1，梯度裁剪设为 1.0。学习率在最初 2,000 步内从 0 线性 warmup 到 $2.5\times10^{-4}$，然后在预训练阶段 1 内按 cosine 衰减到 $5\times10^{-5}$。在预训练阶段 2，我们在 4k 部分（2T token）上做第二次 cosine 衰减，从 $5\times10^{-5}$ 降到 $2\times10^{-5}$，并在 32k 部分（1T token）把学习率固定在 $2\times10^{-5}$。全局 batch size 在最初 400B token 内从 4096 逐步增到 16384，其余训练保持 16384，annealing 的 32k 部分设为 2k。MTP 损失权重在预训练阶段 1 设为 0.3、预训练阶段 2 设为 0.1，遵循 30。loss-free load balancing 的 bias 更新率在前 14.6T token 为 0.001，在 annealing 期间衰减到 0.0；EP-group 均衡损失的系数为 0.001，整个预训练都施加。RoPE84 方面，4k 训练时 full attention 和 sliding window attention（SWA）都用 $\theta=10{,}000$；annealing 的 32k 部分只把 full attention 设为 $\theta_{\mathrm{Full}}=1{,}000{,}000$，SWA 保持 $\theta_{\mathrm{SWA}}=10{,}000$。
Mid-training 超参数。mid-training 继续用 Muon36。我们冻结 MoE router 权重、关闭 EP-group 均衡损失，两个 mid-training 阶段的 MTP 损失权重都固定为 0.1。学习率在最初 3% 的迭代内从 0 warmup 到 $2\times10^{-5}$，在 Mid-training 阶段 1 保持不变，在 Mid-training 阶段 2 衰减到 $7.3\times10^{-6}$。RoPE 的选择性 scaling 方面，我们在 32k（Mid-training 阶段 1）设 $\theta_{\mathrm{Full}}=1{,}000{,}000$，在 128k（Mid-training 阶段 2）提到 $\theta_{\mathrm{Full}}=5{,}000{,}000$，整个 mid-training 期间 $\theta_{\mathrm{SWA}}=10{,}000$ 保持不变85。
5 后训练
本节介绍一套面向大规模强化学习（RL）的统一后训练配方，它从一个统一的监督微调（SFT）模型出发。这个框架把可验证的奖励信号与人类偏好反馈结合起来，实现持续的自我提升，同时即便在 Mixture-of-Experts（MoE）模型的大规模 off-policy 训练下也保持稳定。整个流程采用与此前工作863 类似的两阶段做法。首先，我们通过在数学、代码、STEM、工具使用、长上下文理解、人类偏好和 agentic 推理这些领域上做领域特定 RL，把统一的 SFT baseline 增强成一批专家模型。然后用自蒸馏和可 scale 的 RL 把这些专精的专家蒸馏进一个通才模型，确保最终模型在各类任务上都能与专精的 baseline 相抗衡。通过系统性地在定向专精与广泛综合之间交替，我们在不牺牲专家级表现的前提下获得了稳健的泛化。
5.1 专家模型构建与自蒸馏
我们用一个两阶段的 SFT 流水线为后续 RL 打下稳固基础。第一阶段执行大规模多领域 SFT，覆盖数学、代码、STEM、逻辑、通用 QA、代码 agent、工具使用、搜索 agent 和长上下文理解。我们施加了难度感知的过滤和有策略的配比，以培养广泛的 agentic 行为。第二阶段通过注入分布外（OOD）信号8748 显式地最大化推理密度，这些信号包括约 3 万条专家级化学轨迹和合成的算术任务。这种对不同推理模式的定向暴露，只用三个 epoch 就解锁了模型内潜藏的能力，让模型具备了初始化后续领域特定 RL 阶段所需的复杂结构。
在领域特定 RL 之后，我们把分化的各专家能力合并进一个统一的学生模型，学生从 mid-train checkpoint 初始化。在这个阶段，专家模型用一个与第一阶段 SFT 语料共享的 prompt 分布来生成高质量轨迹，相比直接做 RL 整合，这提供了一条更稳定、更高效的路径。这个做法用 rejection sampling 剔除语言混杂、过度思考这类不良模式，把专家知识集中到单个学生模型里。通过打好这个高质量的底子，自蒸馏显著减轻了后续 RL 阶段的优化负担。
超参数。使用 Muon 优化器36，$3\%$ warmup，cosine 衰减从 $1.0 \times 10^{-5}$ 到 $5.0 \times 10^{-6}$。我们冻结 MoE router 权重、关闭 EP-group 均衡损失，与 mid-training 一致。SFT 训练的 MTP 损失权重为 0.1，全局 batch size 为 32，全局序列长度为 $128\text{k}$。Rotary Position Embeddings（RoPE）84 方面，我们保持 $\theta_{SWA}=10,000$，把 $\theta_{Full}$ 调到 $5,000,000$ 以适配 128k 上下文长度85。
5.2 可 scale 的 RL
在 LLM 的 RL 里，我们优化一个策略 $\pi_\theta$ 来最大化轨迹 $\tau = (s_0, a_0, \dots, s_T)$ 上的终端奖励，其中 $a_t$ 表示在状态 $s_t$ 生成的 token。但对推理任务，这个过程会因高梯度方差而严重不稳定，而极长的 horizon 和模型规模又进一步放大了这一点（Figure 5 (2)）。这个方差主要来自高吞吐推理引擎与训练框架之间的基础设施差异，以及迭代更新固有的 off-policy 失配（RL Scaling: Off-Policy vs On Policy）。在这种设定下，importance sampling 本身就不稳定——微小的 token 级概率偏移会累积成噪声梯度，阻碍收敛。
5.2.1 MIS-Filtered Policy Optimization（MIS-PO）
为了应对这些稳定性挑战，我们提出 MIS-PO，一个受 Metropolis Independence Sampling（MIS）4142 启发的方法。我们把推理策略当作 proposal 分布、训练策略当作 target，把更新限制在那些与 target 分布足够接近的样本上。不同于 importance sampling 用有界的比值去缩放梯度、并常常受高方差之苦，MIS-PO 用二值 mask 过滤掉偏离分布的样本，并把保留下来的轨迹视为实际上 on-policy 的，从而显著降低梯度方差、稳定优化。
形式化地，我们定义一个二值指示函数 $\mathbb{I}(x) = \mathbb{1}[\rho_{\min} \le x \le \rho_{\max}]$，并在两个不同粒度上施加它。在 token 级，该函数过滤概率比 $x_t = \pi_{\theta_{\text{old}}}(a_t|s_t) / \pi_{\theta_\text{vllm}}(a_t|s_t)$，以抑制训练策略与推理策略之间的局部失配39。在 轨迹级，我们把同一个指示函数施加到几何平均比值 $\bar{\rho}(\tau) = (\prod_t x_t)^{\frac 1T}$ 上，从而丢弃那些已经显著偏离 target 分布的整条轨迹。重构后的 actor loss 用这两级离散 mask 取代了连续的 importance weight：
$$ \mathcal{L}_{actor} = - \mathbb{E}_{\tau \sim \pi_{\theta_\text{vllm}}} \left[ \mathbb{I}(x_t) \cdot \mathbb{I}(\bar{\rho}(\tau)) \cdot \log \pi_\theta(a_t|s_t) \cdot \hat{A}_t \right]. $$通过把有效样本视为实际上 on-policy 的，这个目标在 trust-region 约束下大幅降低了长程推理任务的梯度方差。Figure 5 给出一个约 5,000 训练步的消融研究，其中 MIS-PO 的 actor gradient norm 噪声明显低于 PPO，说明可扩展性更好。更多消融见附录 D.2.3。
为了进一步稳定训练动态，我们还用了几项技术：Truncation-Aware Value Bootstrapping88 用来纠正上下文长度截断引入的奖励偏差，以及 Routing Confidence 监控用来预测 MoE 架构特有的不稳定。
Truncation-Aware Value Bootstrapping。给被上下文截断的轨迹判零奖励，等于把截断和任务失败混为一谈。这种含混会惩罚长链推理，因为它无法区分「没做完」和「做错了」。为此，我们用终态的 bootstrapped value 估计取代零奖励，实际上把截断当作 horizon 被打断、而不是终局失败。轨迹 $\tau_i$ 的修正奖励定义为：
$$ \hat{R_i} = \begin{cases} V_\phi(s_T) & \text{if the response is truncated,} \\ R_i & \text{otherwise}. \end{cases} $$实证上，这个 truncation-aware value bootstrapping 即使在截断率高达 20% 时也能稳住训练，避免了不完整轨迹通常会触发的奖励退化8990。消融研究确认，这个技术对竞赛级 benchmark 尤其有益——那里长程推理让截断效应最为普遍。
用 Routing Confidence 做稳定性代理。近期研究3840 把 RL 的稳定性与 MoE 的 routing 一致性联系起来。在此基础上，我们提出 Routing Confidence（$\Sigma_k$）作为稳定性的代理指标，它是被激活专家的平均概率质量。$\Sigma_k$ 低意味着 routing 不确定性高，这会放大训练—推理失配。通过初步实验，我们识别出一个明显的稳定性相变：routing confidence 低的模型很脆，需要极端的稳定化手段（例如 Router Replay38402、严格的 on-policy 更新91）；相反，routing confidence 高的模型保持稳健，能在不做复杂干预的情况下做 off-policy 训练。
RL 训练动态。为了给出方法的整体面貌，我们在 Figure 6 中展示 Step 3.5 Flash 的 RL with verifiable rewards（RLVR）训练动态和下游评测提升。训练 reward 稳步上升，说明学习过程稳定且有效。此外，Step 3.5 Flash 在各类评测 benchmark 上都取得一致的提升。具体来说，我们观察到 IMO-AnswerBench43 +3.2%、CF-Div2-Stepfun-cpp（附录 E.2.1 里我们自建的 CodeForces92 Div.2 Benchmark）+6.1%、ARC-AGI-193 +10.6%、$\text{HLE}_\text{text}$94 +3.4%。
5.2.2 奖励系统
我们把 RL 框架解耦成 RL with verifiable rewards（RLVR95）和 RL with non-verifiable rewards（例如 RLHF96）两部分，各自配一个契合其监督特性的奖励。
可验证奖励。对 RLVR，每个 prompt 都配一个任务特定的 verifier 来输出奖励。逻辑、指令遵循和代码用基于规则的 checker，STEM 任务用基于模型的 verifier。在我们内部模型上跑 450 个 RL 训练步的消融研究中，STEM 任务用基于模型的 verifier 比直接用朴素的 math-verify 平均高 2.0%；更多细节见附录 D.2.2。
不可验证奖励。对不可验证的任务，我们用一个成对的生成式奖励模型（GenRM97），把候选回复与一个固定参考做对比。GenRM 是一个推理模型，输出一个置信分表示该回复胜出的可能性。这个分数随后被换算成 Bradley–Terry 胜率98 作为奖励信号。长度控制被建模为 GenRM 内的一个置信分惩罚项，并传播到胜率奖励上，有效抑制了 RL 训练中回复长度的过度膨胀。我们还对带伪造引用、过度自信断言或语言不一致的回复判零奖励，以进一步保证稳健性。
Agent 奖励。搜索任务由一个 LLM 基于实体匹配分来评估。对报告生成，一个基于 rubric 的 LLM judge 评估研究问题、rubric 规格和候选报告，产出三值判定（满足、部分满足、不满足）99。由于中间那一档常常与专家偏好不对齐，我们把输出映射成非对称的二值奖励，得到更清晰的学习信号，也更快地收敛到与专家对齐的行为。
GenRM 训练与 MetaRM。我们通过用 RM 专用的 prompt 微调 SFT 模型来初始化 GenRM。RL 训练时，我们用筛选过的成对偏好数据，配一个类似标量奖励模型形式的 logsigmoid 损失。为了提升 GenRM 的稳健性，我们对表现出虚假推理（即从有缺陷的逻辑里得出了正确偏好）的回复施加惩罚，做法是整合 MetaRM——一个额外的 verifier，检测到这类模式时降低训练奖励。在我们内部模型上跑 200 个 RL 训练步的消融研究中，MetaRM 增强的 GenRM 在每个 benchmark 上都比朴素 GenRM 高 0.5%–3%。
5.2.3 超参数
rollout 方面，我们把采样温度和 top-$p$ 都设为 1.0，最大序列长度为 128k token。每次生成，推理任务采样 256 个不同的 prompt、每个 16 条回复；人类偏好任务采样 512 个 prompt、每个 8 条回复；工具使用任务采样 128 个 prompt、每个 8 条回复。rollout 之后，完成的样本被切成 mini-batch，训练一个 epoch，actor 用 4 个 mini-batch、critic 用 12 个。优化用 Muon 优化器，weight decay 为 0.1。actor 的学习率为 $2 \times 10^{-6}$、20 步 warmup，critic 的学习率为 $5 \times 10^{-6}$、50 步 warmup。参照 ORZ91，我们把 $\gamma$ 和 $\lambda$ 都设为 1。最后阶段我们还采用一个系数为 0.001 的无偏 KL 损失86。对上面的 MIS-PO actor loss 公式，token 级和轨迹级的 mask 边界分别设为 $[0.5, 2]$ 和 $[0.996, 1.001]$。
5.3 数据合成与筛选
我们通过聚合开源数据、合成生成和用户轨迹，构建了一个多样且难度均衡的 prompt 池。我们施加一套统一的合成与筛选流水线，把严格的全局过滤与领域特定的精炼结合起来，以最大化推理密度。数据质量由基于规则的启发式与基于模型的保真度检查混合把关。最终数据集含 871k 样本（7.23B token），详细统计见 Table 3。
| 领域 | 样本数 | Token 数 | 语料占比 |
|---|---|---|---|
| Math | 68055 | 0.98B | 11.19% |
| Code | 86421 | 1.23B | 21.10% |
| STEM | 120399 | 0.55B | 6.31% |
| Logic | 93323 | 0.81B | 13.87% |
| General | 314495 | 0.80B | 9.16% |
| Code Agent | 37240 | 0.90B | 17.70% |
| Tool-use | 114507 | 0.76B | 8.72% |
| Search Agent | 20256 | 0.50B | 8.75% |
| Long Context | 15565 | 0.70B | 4.00% |
| 合计 | 870687 | 7.23B | 100.00% |
Table 3：第一阶段 SFT 的数据统计。
5.3.1 通用与推理
我们的训练语料聚合了社区 prompt、专家回复和来自各类开源的合成数据，包括数学10010110210310410510690911074810887、编码109110111 以及科学与开放式 QA112113114115。为了最大化推理密度，我们采用一套统一流水线，把严格的全局过滤与领域特定的精炼耦合起来，用基于规则的启发式与基于模型的保真度检查混合来保障质量。具体来说，在数学上我们通过专家引导的 rejection sampling 和合成的大数算术来确保数值稳定性。在编程上，我们优先保证离线可执行性，挑选严格的算法题，同时严格清除与 RAG 相关的幻觉。特别地，我们抑制模型谎称自己能访问外部搜索引擎、或假装在网上检索到解法的倾向。此外，我们把科学数据限制在有唯一可确定解的明确问题上。
为了让能力泛化到各种实际场景，我们扩展了开源 checker116，并给样本增补了若干真实世界的约束。同时，我们从开源、合成和用户轨迹中收集通用 prompt，形成一个多样、难度均衡的池子。这个过程产出一个十亿 token 量级、含数百万样本的高保真数据集。
5.3.2 通用工具学习
我们提出一个执行驱动的数据生成框架，用于让智能 agent 学会可靠的工具使用行为，解决现有合成流水线的几个关键局限：数据不一致、缺乏可验证性和模型幻觉。不同于依赖随机探索117118 或基于模型的模拟6119，我们的方法把工具使用行为分解成原子意图，用有限状态机（FSM）来建模，显式地把抽象的工具调用逻辑与参数化的执行约束分开。数据通过一个带 rejection sampling 的「采样—执行—验证」循环生成，所有候选轨迹都在真实环境里执行、由确定性反馈验证，从而保证保真度、消除幻觉行为。通过把原子意图组合起来，这个框架支持可 scale 地生成复杂、可控的工具使用场景。用这套范式，我们构建了超过 10 万条高质量轨迹、总计数十亿 token，为基于工具的规划、推理和执行提供了精确的监督。
5.3.3 代码 Agent
代码 agent 可以通过可验证的环境构建与解法生成之间的闭环干预来自我提升，可执行的反馈持续精炼这两项能力。我们把环境构建当作与修 bug、实现功能同等重要的一等能力，在可验证奖励信号下合成它。为此，我们开发了一个专门的 agentic 流水线，由 SWE-factory120 框架演化而来，加入了一个跨任务的记忆池（检索历史上成功的构建作为 few-shot 示范）和一个环路检测机制（防止冗余探索）。这个流水线达到 40% 的环境构建成功率，通过构建轨迹（含 shell 命令和错误恢复）提供的稠密监督，形成模型自我演化的正反馈回路。为了进一步提升信号质量，我们对环境构建轨迹做归一化，把那些对最终解决没有贡献的瞬时失败和冗余执行模式抽象掉、mask 掉。
bootstrap 出来的环境充当动态测试床，利用执行反馈和单元测试来生成高质量的合成数据和奖励信号，用于持续对齐。实证上我们观察到双向迁移：构建方面的专长会加速编码表现，而在这些环境里编码又反过来提升构建准确率，这一点在 DockSmith121 中也有体现。借助这条演化流水线，我们筛出 5 万个经过验证的环境，横跨 1.5 万多个 GitHub 仓库和 20 多种编程语言。这个多样的集合捕捉了广泛的真实场景，为训练通用代码 agent 提供了稳固基础。此外，我们也纳入了若干知名的开源环境，包括 SWE-smith15、SWE-Gym122、R2E-Gym123、SWE-rebench124 和 SETA125。
5.3.4 搜索与研究 Agent
为了支撑高级的信息寻求能力，我们的流水线整合了基于图和多文档的合成来强制多跳推理。通过在知识图谱（例如 Wikidata5m126）上做拓扑扩展、模拟跨网站的浏览轨迹，我们生成的数据能反映真实研究的复杂度。关键在于，为了保证外部检索确有必要，我们用 DeepSeek-R1127 来校验生成的查询，系统性地排除那些这个强推理模型不用工具就能解决的实例。得到的轨迹再经过一个结构化的报告生成流水线99 精炼，该流水线强制严格的指令遵循和结构完整性。具体来说，我们强制严格遵守预设的研究计划，凡是偏离结构的轨迹一律丢弃。随后，有效输出通过基于模型的 judger 和启发式规则做迭代清洗，解决用词不正式、时间幻觉和中英混杂这类细粒度问题。这套端到端的方法在 ResearchRubrics22 benchmark 上取得了业界领先的表现。
5.4 Agent 基础设施
推理与工具使用的模板设计。要把推理和 agentic 能力有效地整合进单个基座模型，关键是为思考过程和工具使用确定合适的模板。推理模板方面，我们评估了三种管理策略。每轮都丢弃推理历史的做法127 虽然鼓励独立生成，但在长程任务上会导致任务失败（例如超过 100 轮的编码会话）。反过来，保留完整推理历史会带来难以承受的上下文消耗，很快就把模型容量吃满，阻塞后续的工具调用。为了解决这个问题，我们采用一种选择性保留策略：只为最近一条用户指令所触发的工具使用轨迹保留推理痕迹。这个设计在推理连贯性和上下文效率之间取得了最优权衡，也与近期前沿模型的做法一致7686。
工具使用模板方面，我们对比了流行的 JSON 和 XML 格式。JSON 的语法很刚硬，包含转义序列和分隔符，在小的、训练不足的模型上频繁引发解析错误。相比之下，XML 格式允许扁平的字符串输出，语法开销显著更低。因此我们选择 XML 格式，以保证在复杂的真实 agentic 编码场景下的稳健性。
可 scale 的代码 Agent 基础设施。我们的集成架构聚焦于可 scale 的会话管理和跨框架泛化，以支撑高吞吐的 agentic 编码。核心是一个自研的 Session-Router，它通过 Kubernetes 编排容器生命周期，并通过 Tmux 保证交互一致性。这套架构支持数千个并发环境、状态无缝持久化，免去了针对每个 scaffold 手工配 Docker 的麻烦。为了保证在各类 agentic 工作流上的高泛化，我们训练模型去适配范围广泛的交互框架，从学术标准（例如 OpenHands128、SWE-agent129、Terminus-217）到企业级协议（例如 Kilocode130、Roocode131、ClaudeCode132）。通过在训练中把模型暴露给这些多样的交互范式，我们有效防止了它过拟合到特定的流水线模式，确保无论底层执行环境如何它都保持稳健。
6 评测
6.1 预训练评测
| Benchmark | # Shots | Step 3.5 Flash Base | MiMo-V2 Flash Base | GLM-4.5 Base | DeepSeek V3.1 Base | DeepSeek V3.2 Exp Base | Kimi-K2 Base |
|---|---|---|---|---|---|---|---|
| 激活参数 | - | 11B | 15B | 32B | 37B | 37B | 32B |
| 总参数 | - | 196B | 309B | 355B | 671B | 671B | 1043B |
| General | |||||||
| BBH | 3-shot | 88.2 | 88.5 | 86.2 | 88.2† | 88.7† | 88.7 |
| MMLU | 5-shot | 85.8 | 86.7 | 86.1 | 87.4† | 87.8† | 87.8 |
| MMLU-Redux | 5-shot | 89.2 | 90.6 | - | 90.0† | 90.4† | 90.2 |
| MMLU-Pro | 5-shot | 62.3 | 73.2 | - | 58.8† | 62.1† | 69.2 |
| HellaSwag | 10-shot | 90.2 | 88.5 | 87.1 | 89.2† | 89.4† | 94.6 |
| WinoGrande | 5-shot | 79.1 | 83.8 | - | 85.9† | 85.6† | 85.3 |
| GPQA | 5-shot | 41.7 | 43.5* | 33.5* | 43.1* | 37.3* | 43.1* |
| SuperGPQA | 5-shot | 41.0 | 41.1 | - | 42.3† | 43.6† | 44.7 |
| SimpleQA | 5-shot | 31.6 | 20.6 | 30.0 | 26.3† | 27.0† | 35.3 |
| Mathematics | |||||||
| GSM8K | 8-shot | 88.2 | 92.3 | 87.6 | 91.4† | 91.1† | 92.1 |
| MATH | 4-shot | 66.8 | 71.0 | 62.6 | 62.6† | 62.5† | 70.2 |
| Code | |||||||
| HumanEval | 3-shot | 81.1 | 77.4* | 79.8* | 72.5* | 67.7* | 84.8* |
| MBPP | 3-shot | 79.4 | 81.0* | 81.6* | 74.6* | 75.6* | 89.0* |
| HumanEval+ | 0-shot | 72.0 | 70.7 | - | 64.6† | 67.7† | - |
| MBPP+ | 0-shot | 70.6 | 71.4 | - | 72.2† | 69.8† | - |
| MultiPL-E HumanEval | 0-shot | 67.7 | 59.5 | - | 45.9† | 45.7† | 60.5 |
| MultiPL-E MBPP | 0-shot | 58.0 | 56.7 | - | 52.5† | 50.6† | 58.8 |
| Chinese | |||||||
| C-EVAL | 5-shot | 89.6 | 87.9 | 86.9 | 90.0† | 91.0† | 92.5 |
| CMMLU | 5-shot | 88.9 | 87.4 | - | 88.8† | 88.9† | 90.9 |
| C-SimpleQA | 5-shot | 63.2 | 61.5 | 70.1 | 70.9† | 68.0† | 77.6 |
Table 4：预训练评测结果。星号（*）表示原始分数拿不到，我们在与 Step 3.5 Flash 相同的测试条件下重新评测以保证公平比较。剑号（†）表示 DeepSeek 的分数引自 MiMo-V2-Flash 报告31。
评测设置。我们在一系列 benchmark 上评测 Step 3.5 Flash，覆盖多种能力：（1）通用语言理解与推理，包括 BBH133、MMLU134、MMLU-Redux135、MMLU-Pro136、HellaSwag137、WinoGrande138、GPQA139、SuperGPQA140 和 SimpleQA141。（2）数学推理，包括 GSM8K142 和 MATH143。（3）编码，包括 HumanEval144、MBPP145、HumanEval+、MBPP+146 和 MultiPL-E147。（4）中文理解，包括 C-Eval148、CMMLU149 和 C-SimpleQA150。
评测结果。Table 4 汇总了 Step 3.5 Flash 在通用推理、数学、代码和中文 benchmark 上的预训练评测。尽管只激活 11B 参数（总参数 196B），Step 3.5 Flash 与体量显著更大的稀疏 baseline（激活 15–37B，总参数 309–1043B）相比整体上仍有竞争力，展现出很好的准确率—效率权衡。在核心的通用 benchmark 上，Step 3.5 Flash 拿到 BBH 88.2（与最好成绩差距在 0.5 以内）和 MMLU 85.8。值得注意的是，Step 3.5 Flash 在 SimpleQA 上达到 31.6，超过 DeepSeek-V3.2-Exp Base（27.0），而总参数只有 196B 对 671B（即约 $3.4\times$ 的总参数差），凸显了单位参数预算下更强的能力密度。Step 3.5 Flash 还展现出强劲的编码能力，包括 HumanEval 81.1、MultiPL-E HumanEval 67.7 和 MultiPL-E MBPP 58.0。总体上，这些结果说明 Step 3.5 Flash 在单位激活算力上交付了很强的表现，为下游的推理和 agentic 后训练提供了扎实的基础。
6.2 后训练评测
我们在若干代表性 benchmark 上评测 Step 3.5 Flash，包括偏推理的 HLE（文本子集）94、MMLU-Pro136、GPQA-Diamond139、AIME20258、HMMT9、IMO-AnswerBench43；与编码相关的 LiveCodeBench-v6（2024.08-2025.05）10、CF-Div2-Stepfun151、SWE-Bench Verified14 和 SWE-Bench Multilingual15；agent 系列的 $\tau^2$-Bench16、Terminal-Bench 2.017、GAIA20、BrowseComp18、xbench-DeepSearch21、BrowseComp-zh19 和 ResearchRubrics22；通用相关的 ArenaHard v2152、IFBench153 和 MultiChallenge154；以及长上下文相关的 LongBench v2155、MRCR156157、FRAMES158 和 RepoQA159。
我们还通过采用 Parallel Coordinated Reasoning（PaCoRe） 范式44，在推理、通用和长上下文 benchmark 上考察 Step 3.5 Flash 的 test-time scaling 性质。借助 Step 3.5 Flash 极高的推理效率，这个方法通过启动并行的推理轨迹、再经多轮协调把它们的洞见综合成更高保真的解，从而把推理容量与上下文限制解耦。具体来说，我们采用多轮 PaCoRe 轨迹配置 $\vec{K} = [4,4,4,4]$，在各 benchmark 上都取得显著提升。
我们把最大序列长度维持在 256k，使用默认解码配置，解码温度和 top-p 均为 1.0。我们在原有 128k 位置编码之上施加 scaling factor 为 2.0 的 YaRN160，且只限于 full-attention 层。我们对所有方法都报告 pass@1 准确率，基于每题多次独立生成的平均表现：AIME 2025、HMMT 2025 Feb. 和 HMMT 2025 Nov. 各 64 次；IMO-AnswerBench、LiveCodeBench、GPQA-Diamond 和 MultiChallenge 各 8 次；HLE 1 次；其余所有 benchmark 4 次。更多细节见附录 E.2。
评测结果。Table 5 给出 Step 3.5 Flash 与一批强 baseline 在推理、代码 agent、通用 agent、长上下文理解和通用能力 benchmark 上的全面对比。尽管只激活 11B 参数（总参数 196B），Step 3.5 Flash 在广泛的任务上都展现出强劲表现，在 AIME 2025、HMMT 2025 Feb.、HMMT 2025 Nov.、IMO-AnswerBench 和 LiveCodeBench-v6 这类推理密集型 benchmark 上尤为突出。它稳定地超过参数量更大的开源模型，并达到与 GPT-5.2 xHigh、Gemini 3.0 Pro 这类前沿模型相当的水平。值得注意的是，Step 3.5 Flash 在 agentic 评测上取得强劲结果，包括 SWE-Bench Verified、Terminal-Bench 2.0、BrowseComp（带 Context Manager）、GAIA 和 $\tau^2$-Bench，凸显了稳健的工具使用和长程决策能力。
| Benchmark | Step 3.5 Flash（Vanilla） | Step 3.5 Flash（PaCoRe） | MiniMax M2.1 | MiMo V2 Flash | GLM 4.7 | DeepSeek V3.2 | Kimi K2.5 | Gemini 3.0 Pro | Claude Opus 4.5 | GPT-5.2 xHigh |
|---|---|---|---|---|---|---|---|---|---|---|
| 激活参数 | 11B | 11B | 10B | 15B | 32B | 37B | 32B | - | - | - |
| 总参数 | 196B | 196B | 230B | 309B | 355B | 671B | 1T | - | - | - |
| Reasoning | ||||||||||
| AIME 2025 | 97.3 | 99.9 | 83.0 | 95.1* | 95.7 | 93.1 | 96.1 | 95.0 | 92.8 | 100.0 |
| HMMT 2025 Feb. | 98.4 | 100.0 | 71.0* | 95.4* | 97.1 | 92.5 | 95.4 | 97.5† | 92.9† | 99.4 |
| HMMT 2025 Nov. | 94.0 | 97.8 | 74.3* | 91.0* | 93.5 | 90.2 | 91.1 | 94.5† | 91.7* | 97.1* |
| IMO-AnswerBench | 85.4 | 88.8 | 60.4* | 80.9* | 82.0 | 78.3 | 81.8 | 83.3† | 84.0† | 86.3† |
| LiveCodeBench-v6 | 86.4 | 88.9 | 75.4* | 81.6* | 84.9 | 83.3 | 85.0 | 90.7† | 84.8† | 87.7† |
| CF-Div2-Stepfun-cpp | 86.1 | 93.3 | 59.0* | 46.9* | 74.1* | 81.6* | 73.6* | 83.5* | 72.2* | - |
| MMLU-Pro | 84.4 | 84.8 | 88.0 | 84.9 | 84.3 | 85.0 | 87.1 | 90.1† | 89.5† | 87.4† |
| GPQA-Diamond | 83.5 | 85.0 | 83.0 | 84.1* | 85.7 | 82.4 | 87.6 | 91.9 | 87.0 | 92.4 |
| $\text{HLE}_\text{text}$ | 23.1 | 27.9 | 22.2 | 22.1 | 24.8 | 25.1 | 31.5 | 37.7† | 30.8† | 35.5† |
| Code Agent | ||||||||||
| SWE Verified | 74.4 | - | 74.0 | 73.4 | 73.8 | 73.1 | 76.8 | 76.2 | 80.9 | 80.0 |
| SWE Multilingual | 67.4 | - | 72.5 | 71.7 | 66.7 | 70.2 | 73.0 | 65.0† | 77.5† | 72.0† |
| Terminal-Bench 2.0 | 51.0 | - | 47.9 | 38.5 | 41.0 | 46.4 | 50.8 | 56.9† | 59.3† | 54.0† |
| General Agent | ||||||||||
| BrowseComp | 51.6 | - | 47.4 | 45.4 | 52.0 | 51.4 | 60.6 | 37.8† | 37.0† | - |
| BrowseComp（带上下文管理） | 69.0 | - | 62.0 | 58.3 | 67.5 | 67.6 | 74.9 | 59.2† | 57.8† | 65.8 |
| BrowseComp-ZH | 66.9 | - | 47.8* | 51.2* | 66.6 | 65.0 | 62.3* | 66.8* | 62.4* | 76.1* |
| GAIA | 84.5 | - | 64.3* | 78.2* | 61.9* | 75.1* | 75.9* | 76.6* | 76.1* | 83.5* |
| xbench-DeepSearch-2505 | 83.7 | - | 68.7* | 69.3* | 72.0* | 78.0* | 76.7* | 78.3* | 77.0* | 83.0* |
| xbench-DeepSearch-2510 | 56.3 | - | 43.0* | 44.0* | 52.3* | 55.7* | 40.0† | 57.7* | 59.3* | 67.0* |
| ResearchRubrics | 65.3 | - | 60.2* | 54.3* | 62.0* | 55.8* | 59.5* | 50.1* | 61.6* | 57.8* |
| $\tau^2$-Bench | 88.2 | - | 86.6* | 84.1* | 87.4 | 85.2* | 85.4* | 90.7 | 92.5 | 85.5* |
| General | ||||||||||
| Arena-Hard-v2.0 | 74.0 | 93.1 | 63.1* | 68.2* | 73.1* | 66.0* | 85.8* | 81.7† | 76.7† | 80.6† |
| MultiChallenge | 55.7 | 60.8 | 50.5* | 44.3* | 67.8* | 57.1* | 73.6* | 71.8* | 65.8* | 71.9* |
| IFBench | 67.4 | 56.8 | 70.0 | 64.0† | 68.0† | 61.0† | 72.8* | 70.4† | 58.0† | 75.4† |
| Long Context | ||||||||||
| LongBench v2 | 57.5 | 62.0 | 53.9* | 60.6† | 59.1* | 58.4† | 61.0 | 70.0* | 67.8* | 62.4* |
| MRCR-8needle | 28.8 | 26.3 | 20.0† | 19.9† | 25.4† | 27.2† | 36.5* | 73.0† | 54.0* | 88.2* |
| FRAMES-Oracle | 76.5 | 77.2 | 76.5* | 78.0* | 75.1* | 80.1* | 77.4* | 79.7* | 85.8* | 87.3* |
| RepoQA | 88.5 | 88.7 | 88.2* | 91.2* | 89.5* | 91.9* | 89.8* | 91.5* | 95.7* | 93.8* |
Table 5：Step 3.5 Flash 与闭源/开源模型的对比。星号（*）表示原始分数拿不到、或劣于我们复现的结果，因此我们报告在与 Step 3.5 Flash 相同测试条件下评测的结果以保证公平比较。剑号（†）表示分数引自非官方来源，包括技术报告或独立评测平台。我们对 HLE 的评测只针对纯文本子集。BrowseComp（带上下文管理）表示在启用 Context Management 的情况下评测 BrowseComp。
7 局限
Token 效率。Step 3.5 Flash 达到了前沿级智能，但目前要达到相当的质量，它需要比 Gemini 3.0 Pro 更长的生成轨迹。下一步我们会在保持同样竞争力的前提下，裁剪和压缩思考过程以获得更好的效率。
高效的通用精通。我们希望把通才的多面性与深度的领域专长统一起来。为了高效达成这一点，我们正在推进 on-policy 蒸馏的若干变体，让模型以更高的样本效率内化专家行为。
开放世界 agentic 任务上的 RL。虽然 Step 3.5 Flash 在学术 agentic benchmark 上表现有竞争力，但 agentic AI 的下一个前沿要求把 RL 应用到专业工作、高级工程和科学研究中那些错综复杂的专家级任务上。解决这些挑战是部署具备真正自主性的 agent 的前提。
运行范围与约束。Step 3.5 Flash 是为编码和工作导向的任务量身定制的，但在分布漂移时稳定性可能下降。这通常发生在高度专业化的领域，或长程、多轮对话中，此时模型可能表现出重复推理、中英混杂输出，或在时间和身份意识上前后不一致。
附录 A 架构细节
Table 6 汇总了 Step 3.5 Flash 的关键架构超参数。
| 超参数 | 取值 |
|---|---|
| Backbone | |
| 词表大小（$V$） | 128,896 |
| 模型宽度（$d_{\text{model}}$） | 4096 |
| Transformer block 数 | 45（3 稠密 + 42 MoE） |
| MoE FFN | |
| 每个 MoE block 的专家数 | 288 + 1 shared |
| Routing | top-$k=8$ |
| 稠密 FFN 隐层大小 | 11,264 |
| MoE 专家隐层大小 | 1,280 |
| Attention | |
| 混合 block 结构 | 3 个 SWA block + 1 个 full attention block |
| SWA 窗口大小 | 512 |
| KV head 数（GQA） | 8 |
| Query head 数（full / SWA） | 64 / 96 |
| Gate 类型 | 输出上的 head-wise |
| Head 维度 | 128 |
| RoPE $\theta$ | 10,000 |
| RoPE 维度（full / SWA） | 64 / 128 |
| Multi-Token Prediction | |
| MTP block 数 | 3（稠密 SWA） |
| 参数量 | |
| 总参数（主干） | 196B |
| 每 token 激活参数（主干） | 11B |
| 总参数（含 MTP3） | 198B |
| 每 token 激活参数（含 MTP3） | 13B |
Table 6：Step 3.5 Flash 的关键架构超参数。「激活参数」按 token 计，且不含 embedding / 输出矩阵。
A.1 Head-wise Gated Attention
每个 attention head 都被分配一个轻量的、输入相关的标量 gate，使模型能以可忽略的计算开销在混合布局上动态调节信息流。
形式化地，对一个维度为 $d$ 的（单个）head，令 $\boldsymbol{q}_i,\boldsymbol{k}_j,\boldsymbol{v}_j\in\mathbb{R}^{d}$ 分别表示位置 $i$ 的 query 向量以及位置 $j$ 的 key、value 向量，那么 scaled dot-product 分数 $s$、对应的 attention 权重 $\alpha$ 和输出 $\boldsymbol{y}$ 按下式计算：
$$ s_{i,j} = \langle \boldsymbol{q}_i,\boldsymbol{k}_j\rangle/\sqrt{d}, \qquad Z_i = \sum_{j'} \exp(s_{i,j'}), \qquad \alpha_{i,j} = \exp(s_{i,j})/Z_i, \qquad \boldsymbol{y}_i = \sum_j \alpha_{i,j}\,\boldsymbol{v}_j . $$给定位置 $i$ 处的输入表示 $\boldsymbol{x}_i$，我们计算一个 head-wise gate $g_i$ 来调节该 head 的输出：
$$ g_i = \sigma(\boldsymbol{w}_{gate}^\top \boldsymbol{x}_i), \qquad o^{\mathrm{gate}}_{i} = g_i\,\boldsymbol{y}_i, $$其中 $\sigma(\cdot)$ 是 sigmoid 函数，$\boldsymbol{w}_{gate}$ 是一个可学习向量。
head-wise gated attention 可以被看作是在 attention 机制里引入了一个输入相关的 sink token35。把 $\sigma(g) = \frac{1}{1+\exp(-g)}$ 代入上面的 gate 公式，我们得到
$$ \boldsymbol{o}^{\mathrm{gate}}_i = \sum_j \frac{\exp(s_{i,j})}{Z_i + e^{-g_i} Z_i} \boldsymbol{v}_j, $$其中 $\exp(-g_i)Z_i$ 在 softmax 的归一化项里起到了输入相关的 sink mass 的作用。如 §2.3 所示，这种自适应的形式稳定地超过固定的（输入无关的）sink token。
A.2 注意力增强的速度基准
我们用 MTP-3 做模拟，在理想负载下评估这两项增强的延迟开销。Table 7 给出理论 FLOPs 和延迟的相对增量。增加 SWA 的 query head 数会略微抬高 FLOPs，但对延迟影响较小。这是因为 query-to-$kv$ 比值为 12，即使把 MTP-3 算进来也仍让 SWA 处在 IO-bound 区间。至于 head-wise gating，由于它足够轻量，FLOPs 和延迟都没有明显差异。
| Backbone | SWA head 数 | 设置 | Decode 64k（FLOPs / 延迟） | Decode 256k | Prefill 64k | Prefill 256k |
|---|---|---|---|---|---|---|
| Step 3.5 Flash（$S3F1$ 布局） | 64 | no gate | 1.00 / 1.00 | 1.00 / 1.00 | 1.00 / 1.00 | 1.00 / 1.00 |
| Step 3.5 Flash（$S3F1$ 布局） | 96 | no gate | 1.02 / 1.01 | 1.01 / 1.00 | 1.08 / 1.06 | 1.04 / 1.03 |
| Step 3.5 Flash（$S3F1$ 布局） | 64 | head-wise | 1.00 / 1.00 | 1.00 / 1.00 | 1.00 / 1.02 | 1.00 / 1.01 |
| Step 3.5 Flash（$S3F1$ 布局） | 96 | head-wise | 1.02 / 1.02 | 1.01 / 1.00 | 1.08 / 1.08 | 1.04 / 1.05 |
Table 7：不同 SWA head 数和 gating 策略下的相对增量。指标以 FLOPs / 延迟的形式给出。baseline 配置（第一行）归一为 1.0。
| Backbone | 布局 | SWA head 数 | Decode 64K | Decode 256K | Prefill 64K | Prefill 256K |
|---|---|---|---|---|---|---|
| Step 3.5 Flash | $S3F1$ | 64 | 1.00 | 1.00 | 1.00 | 1.00 |
| Step 3.5 Flash | S3F1+Head |
96 | 1.02 | 1.01 | 1.08 | 1.04 |
| Step 3.5 Flash | $S1F1$ | 64 | 1.18 | 1.47 | 1.38 | 1.71 |
| Step 3.5 Flash | $FFFF$ | 64 | 1.51 | 2.33 | 2.07 | 3.00 |
| 内部 30B-A3B | $S3F1$ | 32 | 1.00 | 1.00 | 1.00 | 1.00 |
| 内部 30B-A3B | S3F1+Head |
48 | 1.02 | 1.01 | 1.05 | 1.02 |
| 内部 30B-A3B | $S1F1$ | 32 | 1.42 | 1.74 | 1.50 | 1.80 |
| 内部 30B-A3B | $FFFF$ | 32 | 2.21 | 3.16 | 2.47 | 3.34 |
Table 8：不同 backbone 与注意力模式下的相对 FLOPs 成本。head 数指的是 SWA head。对每个 backbone，FLOPs 最小的配置（head 数减少的 $S3F1$）为 baseline（1.0）。
A.3 Meta Token
近期文献161162163 从理论和实证两方面表明，在预训练序列前面拼上结构化的元数据可以提升数据效率、加快收敛：通过暴露高层属性（例如模态、语言、领域），元数据提供了全局线索，降低了对后续内容的不确定性，从而让 next-token prediction 变得更容易。
受这个范式启发，我们给每个训练样本关联一个人类可读格式的元数据字符串 $\mathbf{M}$，包含内容类型（例如 Code、Book、Paper、Web）、语言（例如 EN、ZH）、领域和来源。然后我们把 $\mathbf{M}$ 拼在原始 token 序列 $\mathbf{x}$ 前面，构成单条训练序列 $\mathbf{s} = [\mathbf{M}; \mathbf{x}]$。预训练时，模型被训练去最大化 $\mathbf{s}$ 的似然：
$$ \mathcal{L}_{\text{full}}(\theta) = -\sum_{t=1}^{|\mathbf{s}|} \log P_\theta(s_t \mid \mathbf{s}_{A.4 预训练消融细节
我们做了受控的预训练消融，以隔离出（i）不同混合注意力布局和（ii）sink token 对比 head-wise gated attention 的影响。
混合注意力布局。我们采用 30B-A3B MoE 架构，在固定 token 预算下评估不同混合注意力布局的下游影响。训练遵循一条严格的多阶段流水线：30B token 的 warmup 阶段，接 1T token 的主预训练，再接 300B token 的 cooldown 阶段，以及额外 100B token 的长上下文专精化阶段——总计约 1.4T token。之后在一个 $0.1\times$ 下采样的数据集上做监督微调（SFT）。完整训练细节见 Table 9。
Gate 对比 sink（放大规模的设置）。我们预训练一个 100B-A10B MoE 模型约 250B token，在更大规模的机制下对比 sink token 和 head-wise gating。
| 超参数 | 100B-A10B | 30B-A3B |
|---|---|---|
| 总 token 数 | 250B | 1.4T |
| 优化器 | Muon36 | Muon36 |
| 峰值学习率 | $1.31\times10^{-4}$ | $1.1\times10^{-3}$ |
| Batch-size warmup | - | 前 30B token |
| 层数 | 43 | 48 |
| 维度 | 4096 | 2048 |
| 开头的稠密层数 | 1 | 1 |
| Routed expert 数 | 96 | 128 |
| 激活 expert 数 | 4 | 8 |
| Shared expert 数 | 1 | 1 |
| 负载均衡方法 | Loss Free65 | Loss Free65 |
| Attention 模块 | GQA8 | GQA8 |
| 序列长度 | 4096 | 4096 |
| 词表大小 | 129280 | 129280 |
| Batch size | 8192 | 16384 |
| Weight decay | 0.1 | 0.1 |
| Partial RoPE | 关闭 | 开启 |
| MTP | 开启 | 关闭 |
Table 9：100B-A10B 与 30B-A3B 架构消融套件的训练配置。
| 布局 | SWA head 数 | BBH | MMLU | MMLU-Redux | MMLU-Pro | SimpleQA | GSM8K | MATH | HumanEval | MBPP | C-EVAL | CMMLU | 均值 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| $FFFF$ | 32 | 66.0 | 64.5 | 69.7 | 35.7 | 7.2 | 70.0 | 39.2 | 48.8 | 53.4 | 69.7 | 70.5 | 54.1 |
| $S1F1$ | 32 | 64.1 | 64.7 | 69.8 | 37.7 | 7.5 | 70.1 | 43.9 | 47.0 | 56.2 | 69.8 | 69.8 | 54.6 |
| $S3F1$ | 32 | 61.7 | 64.2 | 69.4 | 33.7 | 8.0 | 67.4 | 41.5 | 47.6 | 56.0 | 69.5 | 70.9 | 53.6 |
S3F1+Head |
48 | 65.3 | 65.9 | 71.0 | 37.4 | 7.5 | 72.2 | 44.5 | 48.8 | 58.6 | 70.2 | 71.0 | 55.7 |
Table 10：30B-A3B 上混合注意力布局消融（$W{=}512$）的预训练评测结果。$F$ 表示 full attention，$S$ 表示 SWA；$S3F1$ 指混合布局里三个 $S$ 和一个 $F$。S3F1+Head 把 SWA head 数从 32 增到 48。
架构消融的预训练结果见 Table 2 和 Table 10。我们采用 §6.1 里详述的评测协议。具体来说，GPQA139 用 5-shot prompting 评测，HumanEval144 和 MBPP145 用 3-shot prompting。
Table 1 里的后训练结果按如下方式聚合：
- Reasoning：MMLU-Pro136、GPQA-Diamond139、LiveCodeBench v610 和 LiveBench164 的平均。
- Math：AIME 2024165、AIME 2025166、HMMT 2025 Feb.167 和 CNMO 2024168 的平均。
- Code：CF-Div2-Stepfun 和 LiveCodeBench v610 的平均。
- Sci：由 GPQA-Diamond139 代表。
- General：IFEval169、IFBench153、WildBench170、Arena-Hard152 和 MultiChallenge154 的平均。
- LongCtx：六个 benchmark 级平均值的平均：（i）RULER171 上 8k–128k 各上下文长度的平均分，（ii）LongBench v2155 的 Short 和 Medium 子集的平均分，（iii）HELMET172 上 8k–128k 各上下文长度的平均分，（iv）GSM-Infinite173，（v）FRAMES158 的总分，（vi）RepoQA159 的总分。
Table 1 和 Table 10 显示，朴素的 $S3F1$ 布局在通用预训练 benchmark 上不如 full-attention baseline，也稳定地拉低 SFT 质量（例如 BBH：$-4.3$；SFT 均值：$-0.7$）。增加 SWA query head 数大幅缩小了这个差距（例如 MMLU-Pro：$+3.7$；SFT Reasoning：$+0.4$），只在 SFT Code 上有小幅回退（$-0.6$），而在若干指标上追平或超过了 full-attention baseline。Table 2 进一步表明，head-wise gated attention 相对 sink token 指标带来了从 62.5 到 64.4 的平均提升（$+1.9$）。
附录 B 局部激活爆炸的详细分析
为了探究局部激活爆炸的根本原因，我们分析了在所有层上触发最大专家激活的那些 token，识别出两种不同的大激活模式：（1）特定的词法项，例如 special token 和标点，通常会引起大但不夸张的激活，在较浅的层里尤为明显。我们不把这种模式认定为失败模式，因为它没有快速增长，而且它可能是语义建模的一种内部机制61174。另一种模式是（2）某些高频 bi-gram 在第一个 token 上触发极大的激活，这才是我们要调查的失败模式。这个模式由几个因素触发：
某个 bi-gram 出现的频率足够高，同时 MoE FFN 足够细粒度，使得一个专家可以专精于那个 bi-gram 而不被负载均衡机制约束住。这种专精化充当了一条捷径：一旦该专家被激活，输出就变成确定的，其他网络不再影响预测。虽然找捷径对最小化 loss 来说是个合理的做法，但在采用 pre-norm 架构7778 的 MoE 模型里，存在一条直白而病态的路径来实现这种确定性预测，如下所述。模型的最终表示是所有层输出之和，再过一个 RMSNorm。这可以表示为专家输出与 attention 层输出的组合：
$$ \boldsymbol{h}_{\text{final}} = \text{RMSNorm}(\underbrace{\text{expert}_{\text{outlier}}}_{\boldsymbol{h}_{\text{outlier}}} + \underbrace{\sum_{l=1}^L \text{attn}_l + \sum_{\substack{l,e\\(l,e)\text{ is not a outlier}}} \text{expert}_{l,e}}_{\boldsymbol{h}_{\text{others}}}), $$其中 attn、MoE、expert 表示各自模块输出的 hidden state，$L$ 和 $E$ 分别表示层数和专家数。那条直白的路径就是无界地放大 $\text{expert}_{\text{outlier}}$，于是
$$ \text{RMSNorm}(\boldsymbol{h}_{\text{final}}) = \lim_{c\rightarrow \infty}\text{RMSNorm}(c \cdot \hat{\boldsymbol{h}}_\text{outlier} + \boldsymbol{h}_{\text{others}}) = \text{RMSNorm}(\boldsymbol{h}_\text{outlier}), $$这里我们把 $\boldsymbol{h}_\text{outlier}$ 解耦成幅值 $c$ 和表示方向的单位向量 $\hat{\boldsymbol{h}}_\text{outlier}$。
SwiGLU79 是 Step 3.5 Flash 里专家的架构，它提供了一条即使 weight decay 有效压住了权重范数、也仍能产出大输出的路径。SwiGLU 定义如下：
$$ \text{SwiGLU}(\boldsymbol{x}) = \boldsymbol{W}_{\text{down}}\left(\text{SiLU}(\boldsymbol{W}_{\text{gate}}\boldsymbol{x})\cdot\boldsymbol{W}_{\text{up}}\boldsymbol{x}\right). $$我们分析了 $\boldsymbol{W}_{\text{gate}}\boldsymbol{x}$ 和 $\boldsymbol{W}_{\text{up}}\boldsymbol{x}$ 的激活范数，发现 outlier 专家与正常专家之间没有显著差异。然而，逐元素乘积产出了异常的输出，在 outlier 专家里满足
$$ \|\text{SiLU}(\boldsymbol{W}_{\text{gate}}\boldsymbol{x})\|\cdot\|\boldsymbol{W}_{\text{up}}\boldsymbol{x}\|\approx\|\text{SiLU}(\boldsymbol{W}_{\text{gate}}\boldsymbol{x})\cdot\boldsymbol{W}_{\text{up}}\boldsymbol{x}\|, $$这只有在 $\text{SiLU}(\boldsymbol{W}_{\text{gate}}\boldsymbol{x})$ 与 $\boldsymbol{W}_{\text{up}}\boldsymbol{x}$ 高度对齐、且集中在极少数维度上时才可能达成。因此，由于输入是稀疏的，$\boldsymbol{W}_{\text{up}}$ 只有很少的行被用到。这个观察让我们更倾向于激活 clipping 而不是权重 clipping——激活的数值性质直接促成了爆炸和稀疏性，而激活 clipping 能立刻处理这些问题。此外，激活 clipping 的负面影响可以忽略，因为表现正常的激活很少超过阈值。
在使用 Muon 优化器时，SwiGLU 这类门控线性单元容易出现 logit 爆炸。这个脆弱性来自与 6 报告的 attention 爆炸类似的机制。对一个专精于某个特定 bi-gram 的 outlier 专家，被 route 到它的 hidden state 预期会与它的 router embedding 高度对齐。我们通过把 router embedding 输入一个 outlier 专家、并直接基于该专家的输出做预测来验证这一点：预测出的分布与真实数据以及整个网络的表现是一致的。结合过于单一的训练目标（预测 bi-gram 里的第二个 token），我们认为，关于 outlier 专家参数 $\boldsymbol{W}_{\text{gate}}$、$\boldsymbol{W}_{\text{up}}$ 和 $\boldsymbol{W}_{\text{down}}$ 的梯度不仅秩异常地低（记为 $r$），而且持续指向一个强调幅值、没有旋转的方向，正如第一个因素里分析的那样。令参数矩阵 $\boldsymbol{W}\in\mathbb{R}^{N\times N}$ 的更新矩阵为
$$ \Delta \boldsymbol{W} = \sum_i \sigma_i \boldsymbol{u}_i\boldsymbol{v}_i^\top = \underbrace{\sum_{i=1}^r \sigma_i \boldsymbol{u}_i\boldsymbol{v}_i^\top}_{\text{low rank signal}} + \underbrace{\sum_{j=r+1}^{N} \sigma_j \boldsymbol{u}_j\boldsymbol{v}_j^\top}_{\text{noise}} $$在优化步上累积更新，会让低秩信号的奇异值迅速增大，导致权重参数爆炸。在 GLU 结构里，$\|\text{SiLU}(\boldsymbol{W}_{\text{gate}}\boldsymbol{x})\cdot\boldsymbol{W}_{\text{up}}\boldsymbol{x}\|$ 在我们这种强对齐的情形下会把谱范数平方，使这个过程更加陡峭。另外，Muon 完全消除了梯度幅值的影响。在爆炸过程中，RMSNorm 会缩小大输入的梯度；用 Adam 优化器时，它的 $\epsilon$ 在学习率自适应过程中充当阈值过滤掉小梯度，这可以阻碍这个过程。相比之下，Muon 持续且有效地对梯度做正交化，导致更激进的更新。
附录 C Step 预训练数据基础
C.1 知识数据构建
C.1.1 StepCrawl
在标准的 web 规模数据集（例如 CommonCrawl）之外，我们开发了 StepCrawl，一套自研的爬取与筛选系统，目标是大规模获取高质量且多样的 token。StepCrawl 既是高信号网页的主要数据来源，也是文档类内容（尤其是 PDF）的主要来源——后者往往包含长篇、高信息密度的材料。
StepCrawl 的一个关键组件是由 WebOrganizer 风格的模型175 驱动的站点与 URL 选择层。我们沿用 WebOrganizer 引入的能力，并进一步微调出一个适配我们流水线的版本。爬取过程中，每个抓到的网页都被这个模型分析，形成一个轻量的 LM-in-the-loop 反馈回路：（i）过滤掉 SEO 驱动和其他低效用的页面，（ii）通过平衡站点类目来引导爬取预算的分配（例如避免对工具类和电商类站点的爬取占比过高），以维持语料多样性、减少主题偏斜。实践中，在这套质量与多样性感知的调度策略下，StepCrawl 每天处理约 10 亿量级的页面。
所有爬取活动都严格遵守 robots.txt 和站点特定的访问策略。收集到的内容随后经过一个多阶段过滤流程（质量打分、去重和清洗），确保只有高效用且合规的数据被留下来训练。
C.1.2 质量精炼与分层
质量分层。受 Nemotron-CC176 风格的质量分桶启发，我们把内部 web 数据分成质量层级，优先从更高层级采样。我们用六个轻量打分器/分类器的集成来给每篇文档打标，并在各打分器之间对层级归属做集成。在最终配方里，我们保留 High/Medium-High/Medium，丢弃 Medium-Low/Low，这在消融中显著提升了 token 效率。对书籍和论文语料，我们施加同样的分层，但在 annealing 阶段只保留 High/Medium-High 两层以最大化多样性。除了共用的六打分器集成，我们还整合了针对 STEM 和知识密集内容的额外领域特定过滤器，并对占比过高的领域做下采样以保证均衡表示。
基于 embedding 的簇再平衡。我们把基于 embedding 的语料平衡当作进一步减少冗余、缓解分布偏斜的一条有原则的路径。具体来说，我们对大规模中英文 web 数据做 embedding，跑 k-means 聚类（10 万+ 个簇），并对质量占比过高的簇做下采样。在消融中，这种在 cooldown 阶段做的簇级再平衡改善了一批 benchmark。
知识密集挖掘与增强。我们用一个建立在上述共享 embedding 表示之上的轻量两阶段流水线，构建一个专门的知识子集。第一，用一份精心整理的高价值实体、概念和关系清单，在 embedding 空间里从全量语料中检索知识密集的文档和段落；这些候选再由一个知识密度模型和简单的覆盖度启发式来排序。第二，对检索到的一部分内容，我们施加有针对性的变换，例如受控的改写和 QA 合成，以提升可学习性。得到的样本被混回训练配比中，以提高有效的知识信号密度。我们在消融中观察到这条流水线带来一致的收益，而对其益处的详细因果分析留待未来工作。
C.2 代码数据
C.2.1 纯代码
我们用一个改造版的 OpenCoder 过滤规则81 来精炼内部编程数据集，并引入一个经过校准的放宽来平衡数据质量与多样性。在我们的流水线里，施加 OpenCoder 过滤器会为每篇文档产生一组「hit」，每个 hit 代表违反了一条启发式规则（提示存在潜在噪声）。我们按 hit 数给语料分类：hit0 表示干净文档（零违规），hit1 表示一个违规，以此类推。
我们的内部消融揭示出一个清晰的质量—多样性权衡：严格过滤（例如只留 hit0）会过度修剪语料，而完全不过滤又引入过多噪声。我们发现 hit0--6 配置（接受最多 6 个违规的文档）给出最好的整体 benchmark 表现，相比原始的严格约束保留了更多样的高信号代码。
C.2.2 PR/Issue/Commit 数据
为了增强软件工程能力，我们从 star 数超过 10 的 GitHub 仓库构建了一个全面的数据集，包含 PR、issue 和 commit。我们对仓库热度和内容质量施加严格过滤，并用 LLM 生成缺失的 issue 描述，得到一个 500 万样本的基础。在此之上，我们导出四个训练子集：
（1）Base PR/Issue/Commit 数据：我们通过 GHArchive 和 GitHub API 爬取数据，包括完整的 commit 历史。我们抽取变更，并把一小部分样本对着 git diff 的 ground truth 做验证，然后过滤到 20+ 种主流语言（例如 Python、Java、C++）。我们严格地与 SWE-Bench Verified14 和 SWE-Bench Multilingual15 做去重以防泄漏。
（2）拼接的 PR-Dialogue 数据（90B token）：我们通过施加两个受 Agentless 启发的模板83 生成了 90B token 的代码编辑训练数据：（1）文件定位：给定问题描述和仓库结构，识别目标文件路径；（2）代码修复：给定问题描述和文件内容，通过 SEARCH/REPLACE 块生成精确的修改。
我们把这 90B 代码编辑数据整合进两个训练阶段，各自用不同的 mask 策略。在预训练的 annealing 阶段，只 mask 模板脚手架；在 mid-training 阶段，数据被转成 chat 对话，user prompt 被 mask。内部消融显示，在 cooldown 阶段和 mid-training 阶段，这在 SWE-Bench Verified 和 SWE-Bench Multilingual 上都带来一致的收益。
（3）改写的推理导向数据（12B token）：从基础数据集的 Python 子集出发，我们通过 LLM 的变更类型标注导出修 bug 样本。我们施加两个简洁的改写策略：（1）推理重建：一个 LLM 重建 PR 作者的问题求解过程（问题分析、根因定位、方案设计和代码实现），注入到 PR-Dialogue 格式里。有幻觉/不一致的痕迹通过基于规则和 LLM 的验证过滤掉。（2）主动阅读笔记：把 PR/issue/commit 数据转成结构化的学习提纲（动机、根因、设计决策、洞见），再合成为连贯的技术笔记。这些改写数据集（约 12B token）在 mid-training 阶段被纳入，在 SWE-Bench Verified 上带来进一步收益。
（4）基于环境的种子数据。我们用附录 E.2.2 描述的环境构建流水线，从原始 PR、issue 和 commit 记录中筛选出可执行的环境。候选样本被严格过滤以确保包含 test patch，并通过严格的规则标准验证以保证环境可复现。此外，选中的 issue 会经过有针对性的改写以增强数据质量和覆盖度。得到的数据集包含数十万条种子样本，含问题描述、代码变更和测试函数，是增强 agentic 编码能力的基石，在下游 agent 任务上带来显著的性能提升。
C.3 数学与 STEM 数据
为了增强推理能力、从知识中激发智能，我们筛选出一个大规模的数学与 STEM 数据集。除了此前工作95177 用的标准 Common Crawl 数据，我们还利用自研的 StepCrawl 系统大规模收割额外的数学相关数据。具体来说，我们实现了一条受 MegaMath177 启发的过滤流水线，用一组内部分类器搭配 FineMath178。这让我们保留了数千亿个与 Common Crawl 不重叠的数学相关 token。我们还收集了一个多样的 1 亿样本教育数据集，涵盖习题、测验和教学内容。这个集合弥合了学术理论与专业应用之间的落差，覆盖从 K-12 数学/物理/化学和人文，到成人职业考试（CPA、法考）等领域。早期实验确认，这些问题求解数据对优化预训练的 token 效率至关重要。
C.4 数据基础设施
我们的数据构建与筛选流水线跑在一套高吞吐的自研数据基础设施系统上，它是为大规模去重、挖掘和模型推理过滤设计的。我们运行混合的 CPU/GPU 集群，配 Spark 和 Ray 这类分布式框架，既执行大体量处理（例如基于 minhash 的去重），也执行模型驱动的筛选负载（例如 embedding 生成和分类器/LM 推理）；底层存储层横跨对象存储（OSS）、HDFS 和 JuiceFS，以支撑原始语料和中间产物的高效读写。
C.5 数据消融设置
为了严格评估数据质量和筛选策略的影响，我们用 30B-A3B MoE 架构、配 Muon 优化器做了一套广泛的消融，设置与主线一致（Table 9）。遵循严格的 token 效率协议，我们为所有实验设定固定的训练预算。模型在 §6.1 列出的全面 benchmark 上评测，同时也在一系列精心设计的留出压缩（perplexity）测试集上评测。我们观察到压缩指标往往更直接地度量知识容量，提供了与主流 benchmark 互补的信号。
在 30B-A3B MoE 模型上的内部实验表明，相比更小的代理模型，它的表现和稳定性都更好。虽然更小的模型算力上更便宜，但它们往往抓不住复杂推理的细微之处，也缺乏记住长尾模式的容量，导致对数据重复产生人为的偏好。实证上，30B-A3B 这个尺寸提供了更强的稳定性，也更忠实地反映全尺寸的趋势。
附录 D 后训练细节
本节描述把 base 模型精炼成高性能 agentic 系统的后训练过程，涵盖配有严格数据处理与质量控制的 SFT，以及随后用来进一步提升推理、工具使用和泛化能力的大规模 RL。
D.1 SFT 细节
D.1.1 SFT 数据处理流水线
在所有领域上，我们施加一套统一的数据处理流水线，强调答案的可验证性、推理质量和执行的真实性。为了确保整体数据完整性，聚合后的数据集经过一个严格的两阶段过滤流程：
- 基于规则的过滤：我们剔除表现出退化模式的低质量数据，例如无限重复、有害内容和个人可识别信息。
- 基于模型的过滤：我们利用专门的模型来检测并过滤语言上不一致的数据。通过识别并移除带不自然语言混杂的样本，我们显著提升了数据集的语言纯净度和整体质量。
- 去污染：我们做全面的 benchmark 去污染以防测试集泄漏。这既包括精确匹配（配合数字 mask 以捕捉数值上的改动），也包括 $N$-gram 匹配。
这个流程产出一个最终精炼的数据集，含 871k 样本、总计 7.23B token。SFT 数据的详细分布见 Table 3。
译注：原文这里把「去污染」列为第 3 条，但前面的引言只说「两阶段过滤流程」。三条并存，本译文照抄未改。
D.2 RL 细节与消融
本节详述大规模 RL 后训练，涵盖数据筛选、异步搜索 agent 训练，以及在稠密和 MoE 模型上的消融。
D.2.1 数据筛选
我们通过聚合开源集合与竞赛档案来筛选 RL 训练数据集，覆盖竞技编程、STEM，以及用于通用 RLVR 训练的合成数据。为了防止数据污染，我们严格排除 2024–2026 年间举办的竞赛题目。数据集还用以下内容做了增补：（i）涉及 11–13 位整数的合成算术题；（ii）一个 generator–validator 流水线，为编码任务合成额外的测试用例；（iii）用于通用推理任务的合成环境，例如谜题和指令遵循。
我们施加一个两阶段过滤流程。第一，确定性的规则修剪移除含图片、外部链接，或没有唯一最终答案的开放式要求的 prompt。第二，一个基于准确率的过滤器排除过于简单或退化的题目。训练时，每个 batch 按预定义的采样概率从不同领域采样构成。
D.2.2 奖励系统
可验证奖励。对 STEM 任务，我们用 gpt-oss-120b35 作为 verifier 模型，用下面这个结构化 prompt（原文为中文）来严格评判最终答案的正确性。对编码任务，我们用沙箱来对着测试用例验证代码执行，配软奖励。
|
|
D.2.3 RL 消融细节
MIS-PO 对比 GSPO。
为了严格验证我们方法的有效性，我们在稠密和 MoE 两种架构上把 MIS-PO 与 GSPO38 做基准对比。我们选 GSPO 作为主要 baseline，因为它代表了一种降低 importance sampling 固有梯度方差的有竞争力的策略。在我们的实现里，我们把原始的 GSPO 估计量扩展到 actor-critic 设定下，把它的 Generalized Importance Sampling 机制整合进 actor loss。具体来说，我们用轨迹级比值的几何平均取代标准的 token 级 importance sampling 比值。得到的 actor loss 形式如下（$\gamma=\lambda=1$）：
$$ r_\tau(\theta) = \left(\prod_{t=0}^{T-1}\frac{\pi_\theta(a_t|s_t)}{\pi_{\theta_\text{old}}(a_t|s_t)}\right)^{\frac 1T} $$ $$ \hat{A}_t = \hat{R} - V_\phi(s_t) $$ $$ \mathcal{L}^{\text{GSPO}}_\text{actor} = -\mathbb{E}_{\tau \sim \pi_{\theta_\text{vllm}}} \left[ \mathbb{I}(x_t) \cdot \mathbb{I}(\bar{\rho}(\tau)) \cdot \min (r_\tau(\theta)\hat{A}_t, \text{clip}(r_\tau(\theta),1-\epsilon,1+\epsilon)\hat{A}_t) \right] $$为了保证公平比较，我们施加与 MIS-PO 相同的 token 级和样本级 mask 策略，排除训练—推理失配显著的数据。关于 clip 比例 $\epsilon$，我们在 $\{1,2,3,4\}\times10^{-4}$ 上做网格搜索。我们在所有实验里采用 $\epsilon = 10^{-4}$，主要因为它在 200 个 RL 训练步后取得最好的 benchmark 表现。此外，我们观察到这个设置给出约 15% 的 clip fraction，与原始 GSPO38 一致。
Figure 7 给出对比结果。实证上，MIS-PO 相比 GSPO 展现出更优的样本效率和可扩展性。关键在于，MIS-PO 有效地把训练—推理失配约束在一个稳定范围内。这种稳定性对 MoE 模型的大规模 RL 训练格外关键——那里 baseline GSPO 无法维持一致的收敛。
MoE 上的延长训练动态。为了进一步验证我们方法的可扩展性，我们在 MoE 模型上用一个有挑战性的数据集做了一次延长的 MIS-PO 训练。如 Figure 8 所示，模型的 reward 维持持续上升的趋势，actor gradient norm 稳定，entropy 水平也控制得当。这些结果实证地确认了 MIS-PO 对大规模 MoE off-policy RL 训练的可靠性。
D.2.4 搜索 Agent
在训练架构方面，早期的 client–server 单步 off-policy 框架被长尾延迟严重卡住：大约 5% 的样本占掉了约 80% 的生成成本。但我们的观察表明，策略对 staleness 有很强的稳健性，即使延迟约 20 步也能维持稳定表现。因此我们采用 FullyAsync 范式，把生成和更新解耦成一个完全异步的过程。此外，为了把多轮交互中的推理开销降到最低，我们实现了 sticky scheduling，把同一个会话始终派发到同一个节点上，以最大化 KV-cache 复用。整体上，这个配置在维持训练稳定的同时带来了约 $10\times$ 的效率提升。
整个训练过程中，FullyAsync 范式展现出稳健的稳定性，表现为 reward 持续上升，以及 Truncated Importance Sampling（TIS）的截断率维持在可控范围内，这说明异步引入的策略漂移是有限的。值得注意的是，我们观察到，与「RL from zero」在训练预算上可扩展性有限不同，在 mid-training 阶段注入任务相关的知识和工具使用先验，会在 RL 期间引出显著更高的性能收益，能力的涌现也更稳定。
| Model | BrowseComp | BrowseComp-ZH | GAIA | xbench DeepSearch-2505 | xbench DeepSearch-2510 | Avg Gain |
|---|---|---|---|---|---|---|
| Agent $\Delta$avg@3（指标：Pass Rate %） | ||||||
| Step 3.5 Flash* | 1.5 ▲50.1 | 25.0 ▲41.9 | 17.0 ▲67.5 | 26.0 ▲57.7 | 11.3 ▲42.7 | 52.0 |
| Kimi K2-Thinking* | 3.6 ▲37.9 | 23.8 ▲38.5 | 18.8 ▲36.6 | 28.7 ▲39.3 | 14.3 ▲27.0 | 35.9 |
| Kimi K2.5* | 7.4 ▲53.2 | 40.3 ▲22.0 | 26.7 ▲49.2 | 36.0 ▲40.3 | 19.7 ▲36.6 | 40.2 |
| DeepSeek V3.2 | 8.1 ▲43.3 | 41.2 ▲23.8 | 23.4 ▲51.7 | 35.7 ▲41.3 | 18.7 ▲30.6 | 38.1 |
| GLM-4.7 | 3.4 ▲48.6 | 30.2 ▲36.4 | 19.6 ▲26.5 | 29.7 ▲34.6 | 19.3 ▲23.4 | 33.9 |
| MiniMax M2.1 | 1.3 ▲46.1 | 10.1 ▲37.7 | 15.4 ▲30.9 | 18.7 ▲46.6 | 6.0 ▲36.3 | 39.5 |
| MiMo-V2 Flash | 0.9 ▲44.5 | 12.9 ▲38.3 | 12.9 ▲42.3 | 19.7 ▲49.6 | 6.3 ▲13.7 | 37.7 |
| Gemini 3.0 Pro | 25.2 ▲12.6 | - | 32.1 ▲44.5 | 45.0 ▲32.0 | - | 29.7 |
| Claude Sonnet 4.5 | 1.4 ▲22.7 | 21.2 ▲19.6 | 16.2 ▲54.7 | 24.7 ▲42.6 | 7.3 ▲37.7 | 35.5 |
Table 11：工具使用对 agent 表现的影响。每格先给出 baseline 分数（只用内部知识），后接启用搜索工具后取得的 ▲性能增益。最终分数是两者之和。Avg Gain 突出模型利用外部信息改善结果的能力。带星号（*）的模型表示工具结果是在 256K 设置下测得的；其他模型的设置未说明。
讨论。为了严格评估与参数化记忆无关的 agentic 能力，我们聚焦于工具使用增益，定义为：
$$ \Delta_{\text{tool}} = \text{Score}_{\text{with tools}} - \text{Score}_{\text{no tools}} $$这个指标把模型固有的知识与它动态利用外部工具的能力解耦开来。如 Table 11 所详述，Step 3.5 Flash 展现出最稳健的外部信息利用能力，取得最高的平均增益（$52.0$），并在 GAIA 和 xbench-DeepSearch 这类复杂 benchmark 上大幅领先。
这个区分很关键，因为在 BrowseComp 这类 benchmark 上的高绝对分数有时可能源自强的内化知识而非有效的搜索策略。一个高分模型的 $\Delta_{\text{tool}}$ 偏小，可能含混地意味着两种情况之一：高效率（模型本来就「知道」答案），或未能有效利用工具来改善结果。反过来，大的 $\Delta_{\text{tool}}$ 明确地表明模型善于通过检索来弥补知识缺口。因此我们主张，未来的优化不应只追逐更高的绝对分数（「刷榜」），而应该在长上下文、证据关键的场景里最大化这个 $\Delta_{\text{tool}}$。这才能确保 agent 真正掌握了信息检索与推理的过程，而不是过拟合到静态知识或 benchmark 的伪影上。
D.3 工具集成推理与并行推理
本节介绍 Step 3.5 Flash 中 test-time scaling 的两条主要方法：工具集成推理和并行推理。
工具集成推理。对复杂推理任务，我们把模型与一个 Python 解释器集成起来，以支持工具辅助的推理。在这个框架里，模型在沙箱内运行，迭代地思考并执行代码，用于计算、模拟和可视化。在我们的实验里，我们在 AIME 2025、HMMT 2025、IMO-AnswerBench、GPQA、HLE$_{\text{text}}$ 和 ARC-AGI-1 上评测，轮数上限为 100。如 Table 12 所示，工具集成推理在有挑战性的数学、STEM 和谜题 benchmark 上显著提升表现，凸显了 Step 3.5 Flash 先进的 agentic 推理能力。
| Benchmark | Step 3.5 Flash | Step 3.5 Flash + Python |
|---|---|---|
| AIME 2025 | 97.3 | 99.8（+2.5） |
| HMMT 2025 Feb. | 98.4 | 98.7（+0.3） |
| HMMT 2025 Nov. | 94.0 | 98.0（+4.0） |
| IMO-AnswerBench | 85.4 | 86.7（+1.3） |
| GPQA-Diamond | 83.5 | 84.4（+0.9） |
| HLE$_{\text{text}}$ | 23.1 | 26.5（+3.4） |
| ARC-AGI-1 | 54.8 | 56.5（+1.7） |
Table 12：Step 3.5 Flash 与 Step 3.5 Flash 配 Python 的对比。
工具集成的并行推理。我们呈现一个把 PaCoRe 扩展到多轮交互环境的初步探索。按设计，PaCoRe 保留了标准的 LLM message 接口。这种兼容性使它能无缝集成进那些使用多轮工具交互的现有 agentic 框架。为了把 PaCoRe 适配到这个设定，我们实现了一个状态感知的输入序列化协议，如 Table 14 所示。
我们在 GPQA 和 HLE$_{\text{text}}$ benchmark 上评测这个方法，用的是配了 Python 解释器的 Step 3.5 Flash。如 Table 13 所示，把并行推理扩展到这些 agentic 循环里，相比标准推理 baseline 带来显著的性能提升。这些发现表明 PaCoRe 能有效泛化到需要交互式反馈的环境，为 agentic 的 test-time scaling 指出了一条有希望的路径。
| Benchmark（配 Python） | Step 3.5 Flash | Step 3.5 Flash + PaCoRe |
|---|---|---|
| GPQA-Diamond | 84.4 | 85.7（+1.3） |
| HLE$_{\text{text}}$ | 26.5 | 28.2（+1.7） |
Table 13：Step 3.5 Flash 配 Python 与同一模型再加 PaCoRe test-time scaling 的对比。
|
|
|
|
Table 14：工具集成 PaCoRe 的输入序列化模板。我们引入两个不同的模板来处理最初的用户查询（Panel A）和后续的工具观察（Panel B）。注意，参考分支里的 tool_calls 被序列化成文本以供分析。
附录 E 详细评测协议与 Prompt
本节给出我们评测套件的实现细节。我们列出具体的 prompt 模板、few-shot 配置以及各 benchmark 上使用的 judge 模型。对于长上下文或推理任务里用到的复杂指标，我们还详述底层的计算逻辑和打分标准，以确保可复现性。在下面给出的模板里，{question} 表示文本问题描述的占位符，其他占位符（例如 {test}、{context}）表示任务特定的信息。
E.1 预训练模型的评测细节
E.1.1 通用语言理解与推理 benchmark
BBH。我们使用 BBH133 的官方 CoT prompt179，只把 “Q:” 和 “A:” 换成 “Problem:” 和 “Solution:"，如下：
|
|
MMLU。我们使用 MMLU134 的官方评测指标，5-shot。我们采用下面这个任务特定的 system prompt：
|
|
对应的 question prompt 结构如下：
|
|
MMLU-Redux。我们使用 MMLU-Redux135 的官方评测指标，5-shot，并采用下面这个 question prompt：
|
|
MMLU-Pro。我们遵循 MMLU-Pro136 的官方评测指标，5-shot。所有评测都使用下面这个 system prompt：
|
|
question prompt 结构如下，末尾的句号之后故意留一个空格：
|
|
值得注意的是，我们观察到原始 MMLU-Pro 数据集有一部分（12,102 道题中的 470 道）在 ground-truth 选项前有不一致的前导空格。我们显式移除这些空格，以缓解潜在的格式偏差、确保评测一致性。
HellaSwag。我们使用 HellaSwag137 的官方评测指标，10-shot。我们采用下面这个 question prompt：
|
|
WinoGrande。我们使用 WinoGrande138 的官方评测指标，5-shot。question prompt 的结构清晰地呈现二选一：
|
|
GPQA。我们使用 GPQA139 的官方评测指标，5-shot。question prompt 的结构清晰地呈现选项：
|
|
SuperGPQA。我们使用 SuperGPQA140 的官方评测指标，5-shot。question prompt 遵循 Chain-of-Thought（CoT）结构，每个 few-shot 示例都包含一步步推导直至最终答案：
|
|
SimpleQA。我们使用 SimpleQA37 的官方评测指标，5-shot。由于 SimpleQA 要求开放式的短答案，我们采用基于 LLM 的判定来评测，具体用 gpt-oss-120b35 作为 judge 模型。question prompt 格式为一句简洁的查询：
|
|
E.1.2 数学推理 benchmark
GSM8K。我们使用 GSM8K142 的官方评测指标，8-shot。question prompt 用下面这个模板来引出 CoT 推理：
|
|
MATH。我们使用 MATH143 的官方评测指标，4-shot。question prompt 用显式的 problem 和 solution 分隔符：
|
|
E.1.3 编码 benchmark
HumanEval。我们使用 HumanEval144 的官方评测指标，3-shot。question prompt 用三个 ground-truth 示例来为代码生成提供上下文引导：
|
|
MBPP。我们遵循 MBPP145 的官方评测指标，3-shot。
HumanEval+。我们遵循 HumanEval+146 的官方评测指标，3-shot。
MBPP+。我们使用 MBPP+146 的官方评测指标，zero-shot。我们采用一个结构化的指令 prompt，指明任务要求并包含一个用于对齐的示例测试用例：
|
|
MultiPL-E。我们使用 MultiPL-E147 的官方评测指标，zero-shot。我们遵循官方测试用例来判定生成的代码。
E.1.4 中文理解 benchmark
C-Eval。我们使用 C-Eval148 的官方评测指标，并加上 5-shot 设置。我们采用下面这个 system prompt：
|
|
对应的 question prompt 结构如下：
|
|
CMMLU。我们使用 CMMLU149 的官方评测指标，并加上 5-shot 设置。我们采用下面这个 system prompt：
|
|
对应的 question prompt 结构如下：
|
|
C-SimpleQA。我们使用 Chinese SimpleQA150 的官方评测指标和基于 LLM 的判定协议。我们加上 5-shot 设置，并用 gpt-oss-120b35 作为 judge 模型。我们采用下面这个 question prompt：
|
|
E.2 后训练模型的评测细节
本节详述用来在一系列多样的 agentic 任务上评估后训练模型的评测协议。我们的评测同时覆盖代码中心和通用 agent 两种设定，涵盖软件工程、终端交互、深度搜索、研究工作流和真实世界的工具使用。我们在精心控制的环境和推理预算下报告标准化指标，以确保跨 benchmark 的比较公平、稳定。
E.2.1 推理 benchmark
CF-Div2-Stepfun。近期研究和先进 benchmark 都强调，在新鲜的、竞赛级题目上评测模型至关重要180181。我们用一个自建的 CodeForces Div. 2 Benchmark151 来评测模型的竞技编程能力。这个 benchmark 由 53 道题组成，取自 2024 年 9 月至 2025 年 2 月间举办的官方 CodeForces Div.2 比赛。我们开发了一个离线评测框架，用本地判题机制替代实时在线提交。我们尽力构造与原始测试用例相近的测试用例。具体来说，我们先生成足量的小规模测试用例来覆盖正确性，然后加入随机化数据做大规模测试。最后，我们通过分析常见错误模式和真实用户的「hacked」提交，对边界用例做对抗式构造。部分边界用例也由压力测试技术自动生成——它不断生成大量测试用例，直到有一个能区分失败提交和正确提交。为了验证这个 benchmark 的可靠性，我们把原比赛里挑出的正确提交和有代表性的失败提交都跑了一遍。我们的评测器把 100% 的通过提交正确判为「Passed」，同时准确标出了 92.45% 的失败提交。
| Model | 准确率 avg@8 C++ | Python | Java | Codeforces C++ pass@8 Rating |
|---|---|---|---|---|
| Step 3.5 Flash | 86.1% | 81.5% | 77.1% | 2489 |
| Deepseek V3.2 | 81.6% | 66.5% | 80.7% | 2319 |
| GLM-4.7 | 74.1% | 63.0% | 70.5% | 2156 |
| Kimi K2-Thinking | 67.9% | 60.4% | 58.5% | 1976 |
| Minimax-M2.1 | 59.0% | 46.4% | 58.0% | 1869 |
| Mimo-V2 Flash | 46.9% | 43.6% | 39.6% | 1658 |
| Gemini 3.0 Pro | 83.5% | 74.1% | 81.6% | 2397 |
| Claude Opus 4.5 | 72.2% | 68.4% | 68.9% | 2100 |
Table 15：各模型在 CF-Div2-Stepfun 上的完整评测结果。
我们对每道题采样 8 个回答，报告平均准确率。这个过程使用的 user prompt 是：
|
|
C++、Python、Java 的编译与执行命令如下：
|
|
|
|
|
|
为了与竞技编程的惯例保持一致、避免 JIT「预热」期带来的不一致开销，我们使用标准 Python 解释器并给双倍时限，而不用 PyPy182。同样的双倍时限也适用于所有 Java 提交。
虽然 Table 15 报告的是原始准确率，我们意识到题目难度差异很大，因此 rating 分数是更稳健的指标。尽管 CodeELO183 这类框架可以计算竞技 rating，但当前顶级模型在 Division 2 比赛里表现太好，其 rating 可能成为统计上的离群点。此外，我们采用一种简化的 rating 计算，忽略提交时间罚分，假定所有解答都在比赛开始时提交。这个做法虽然偏离了真实的竞技场景、导致 rating 无法与人类选手直接对比，但它提供了一个标准化的、可用于一致跨模型比较的基准。
LiveCodeBench-v6。我们使用 LiveCodeBench10 的官方评测方法。我们采用下面这个 system prompt：
|
|
对应的 question prompt 结构如下：
|
|
AIME 2025。我们使用 AIME 2025166 的官方评测方法，repeat@64。我们采用下面这个 question prompt：
|
|
HMMT 2025 Feb./Nov.。我们使用 HMMT 20259 的官方评测方法，repeat@64。我们采用下面这个 question prompt：
|
|
IMO-AnswerBench。我们使用 IMO-AnswerBench43 的官方评测方法，repeat@64。我们采用下面这个 question prompt：
|
|
MMLU-Pro。我们使用 MMLU-Pro136 的官方评测方法。数据集的处理与我们预训练阶段的 MMLU-Pro 评测方法保持一致（细节见附录 E.1.1）。
|
|
GPQA-Diamond。我们使用 GPQA-Diamond139 的官方评测方法。我们采用下面这个 question prompt：
|
|
HLE$_{\text{text}}$。我们使用 HLE 的官方评测指标和基于 LLM 的判定协议。我们用 gpt-oss-120b35 作为 judge 模型。
E.2.2 代码 Agent benchmark
SWE-Bench。SWE-Bench Verified14 是原始 SWE-bench 数据集的一个高质量子集，包含 500 个软件工程任务，经人类专家开发者严格验证以确保评测可靠、准确。SWE-Bench Multilingual 把原始 benchmark 扩展到 9 种编程语言、共 300 个多样的真实软件工程任务。
我们用自研的 agent 基础设施（建立在前述 session-router 架构之上）在 SWE-Bench Verified 和 SWE-Bench Multilingual 上测试 Step 3.5 Flash 的软件工程 agent 能力。对每个评测实例，我们通过 Kubernetes 编排一个容器化 session。然后我们做 SWE-Bench 特定的环境初始化，包括移除未来的 commit 以防数据泄漏，以及配置网络代理和关键系统设置。至于 agent 脚手架，我们采用了研究社区里广泛使用的 OpenHands128 CodeAct Agent 框架。我们启用了默认的四件工具套装：execute_bash、str_replace_editor、finish 和 think。最大交互轮数设为 350。
考虑到编译型语言对资源的消耗，我们在 multilingual 设置下分配 12GB 内存，而 verified 实例限制在 4GB。评测中，工具执行超时设为 1200 秒，模型推理参数为 temperature=1、top-p=0.95。在上述设置下，Step 3.5 Flash 在 SWE-Bench Verified 上达到 74.4%、在 SWE-Bench Multilingual 上达到 67.4%（4 次重复运行的平均分）。我们还在其他流行的 agent 脚手架上交叉评测了 Step 3.5 Flash：SWE-Agent129 用原始 agent 流水线设置在 SWE-Bench Verified 上达到 74.2% 准确率；标准 Claude Code132 环境得分 72.0%，其中每个实例的时限延长到 4 小时、单次工具执行无时限。
Terminal-Bench 2.0。我们在远程的、任务间相互独立的容器里测试 Terminal-Bench benchmark17。我们把容器内存限制在 16GB。我们部署了一个内部 Artifactory 仓库，并更新了所有 Docker 容器的默认包源。在测试阶段的 session 创建和依赖安装过程中，一旦出错系统会重试多次。为了简化系统与 agent 的交互，我们修改了 Terminus 2 框架，使它自动中断超时命令、阻止同一轮里后续命令执行，并向 agent 返回一个超时警告。相应地，我们修改了原始 system prompt 里控制命令时长的那部分：
|
|
推理时，我们把模型的单轮输出上限设为 64k，所有交互的最大上下文窗口设为 256k。thinking 过程会保留在多轮历史里。如果模型输出超过 256k 上下文窗口限制，我们执行一种剪枝式上下文管理：保留问题陈述和历史的后 50%，然后重试。我们使用 top-p=0.95、temperature=1 的推理参数。交互协议主要用 XML 格式的结构化回复进行。agent 被限制在 200 轮交互内，一旦达到上限就直接进入测试阶段。交互与测试的总时限为 6 小时。
为了确保一致性，我们对照每个任务的问题陈述核验并改进了它的 checker184，这把整体准确率提升了约 1.5%。每个任务跑 8 次试验。值得注意的是，88.6% 的成功轨迹在 30 轮交互内完成。最终 pass@8 为 67/89，avg@8 为 50.98%。我们的 agent 在 89 个任务中的 23 个上取得了 8 次试验全部成功的 100% 成功率。在成功的轨迹中，9.41% 的运行触发了历史剪枝来管理上下文上限。
| 设置 | 最大输出 | 最大轮数 | 超时 | 上下文管理 | Avg@8 |
|---|---|---|---|---|---|
| Baseline | 64k | 200 | 6h | 有 | 50.98% |
| Limit 16k | 16k | 200 | 6h | 有 | 48.03% |
| Limit 16k w/o Pruning | 16k | 200 | 6h | 无 | 45.22% |
| Rounds 100 | 64k | 100 | 6h | 有 | 50.42% |
| Timeout 2h | 64k | 200 | 2h | 有 | 49.72% |
Table 16：Terminal-Bench 2.0 上推理约束的消融研究。
消融研究显示，Limit 16k 造成的性能下降最大，因为模型对复杂任务的长推理往往在还没输出终端命令之前就耗尽了 token 上限。在 16k 上限下再关掉上下文管理，进一步跌到 45.22%。同时 Rounds 100 影响很小，因为大多数任务都提前结束了。Timeout 2h 的下降说明某些涉及模型训练、重编译或复杂环境配置的任务需要更多时间才能完成。
E.2.3 通用 Agent benchmark
Deep Search。我们在多个 benchmark 上评测 agent 的深度搜索能力（例如 BrowseComp18、BrowseComp-ZH19、GAIA20、xbench-DeepSearch21）。Table 5 里报告的结果基于 avg@3 指标；GPT-5.2 xHigh 用 avg@1。agent 配备的核心工具集包括：
- search：并行执行多条搜索查询。
- visit：基于 LLM 分析网页内容以回答特定问题。
- google_scholar：搜索学术文章和技术文献。
- python_interpreter：运行 Python 代码做计算和数据分析。
- file：从直链下载并保存文件。
推理时，我们采用 256k token 的上下文窗口，最大生成长度不设限。推理参数为 top-p = 0.95、temperature = 1.0、presence penalty = 1.1，执行预算最多 400 步。
agent 和 LLM judge 的详细 system prompt 与 99 关联的 GitHub 仓库里提供的配置一致。
BrowseComp（配上下文管理）。Table 5 里报告的 BrowseComp（配上下文管理）69.0 这个结果，对应的是在完整 BrowseComp 数据集上评测的 discard-all 方法。这个做法与 DeepSeek V3.22 相同：当上下文长度超过预定义阈值时触发，此时 agent 丢弃它的整个上下文并重新初始化操作循环。在最多 1000 步的迭代约束下，这个策略对 BrowseComp 采用 72k token 的上下文长度阈值，对 BrowseComp-ZH 采用 41k token。
我们还在 BrowseComp 的 200 个实例子集上评测了各种上下文管理策略，包括 Summary、Keep-first&last$K$、Discard-all 和 Multi-agent 编排。如 Table 17 所示，我们的模型在这些不同范式下都展现出稳健的适应性。在单 agent 策略中，Discard-all 给出了有竞争力的 $66.0\%$ 准确率。我们推测 Discard-all 起到的是一种 test-time pass@$k$ 策略的作用，逼着模型从零重新推理，直到找到一条自我验证过的路径。性能呈现清晰的层级：Multi-agent 最高，因为它利用一个 master agent 来分解任务、派发专门 agent 做并行推理；其后依次是 Discard-all、Keep-first&last$K$ 和 Summary——这与真实步数的增长高度吻合。这种吻合反映出推理成本（步数）与准确率之间的直接权衡，说明密集的上下文管理能有效地把增加的算力转化为更优的性能。
| 方法 | 准确率（%） | 真实步数 |
|---|---|---|
| Step 3.5 Flash | 49.5 | 86 |
| + Summary | 57.0 | 131 |
| + Keep-first&lastK | 58.0 | 244 |
| + Discard-all | 66.0 | 302 |
| + Multi-Agent | 68.5 | 721 |
Table 17：上下文管理方法的评测结果。
ResearchRubrics。为了评测深度研究能力，我们使用 ResearchRubrics22 benchmark。这个数据集包含 101 个领域多样的研究任务，每个都配有 20–43 条专家撰写的细粒度打分标准，评估事实准确性、推理严谨性和清晰度。我们对照两类有代表性的系统族做基准测试：商业 agent 系统和 ReAct agent。
对商业 agent，我们在默认配置下通过它们的官方 web 界面收集报告（采集时间为 2025 年 12 月 2 日至 15 日）。如 Table 18 所示，领先的商业系统（Gemini DeepResearch）取得 63.69 的聚合分数。
| Agent 系统 | 分数 |
|---|---|
| Gemini DeepResearch | 63.69 |
| OpenAI DeepResearch | 60.67 |
| Kimi Researcher | 53.67 |
| MiniMax Agent Pro | 51.85 |
| Qwen DeepResearch | 49.24 |
Table 18：商业 Agent 系统在 ResearchRubrics benchmark 上的表现。
对 ReAct agent，详细的性能对比见 Table 5。我们的模型取得 65.3 分，超过了复杂的、闭源的商业 baseline。值得注意的是，当我们在自己的标准化 ReAct 框架里评测 Gemini 3.0 Pro 时，观察到的分数是 50.1。我们把这个性能落差归因于它在处理开放式研究问题时搜索深度不足：模型倾向于依赖内部参数化知识，而不去做广泛的外部检索。结果是生成的报告缺乏全面性，未能充分覆盖用户的隐含标准。
我们把 ReAct agent 的执行环境标准化为最多 30 轮推理、每轮输出上限 16k token。推理参数方面，其他基于 API 的模型使用它们的默认设置，我们的模型配置为 temperature 为 $1$、top-p 为 $0.95$。所有输出随后由一个 LLM judge 用三级评分逐条标准评定。为了支撑端到端的研究工作流，我们的 ReAct 框架提供以下工具套装：
- batch_web_surfer：用于并发网页搜索和多页浏览。
- file：用于稳健的文件操作，包括读、写和迭代编辑。
- file_parser：用于把文件转成 Markdown 格式。
- shell：用于交互式命令执行和环境交互。
- todo：用于动态的任务状态管理与追踪。
- tmux：用于模拟带持久 session 和回滚历史的多路终端环境。
$\tau^2$-Bench。$\tau^2$-Bench16 是一个 agentic benchmark，在航空、零售、电信三个客服领域评测通用工具使用能力。我们用原始代码库里的官方设置评测 Step 3.5 Flash。具体来说，我们使用默认的 LLM agent 框架，设 temperature 为 1.0、top-p 为 0.95、最大序列长度为 256K。user 模型设为 GPT-4.1、temperature 为 0.0，以确保评测期间交互稳定。对航空领域，由于它有错误的 ground truth 答案，我们使用来自 Claude Opus 4.5 的修正版本以确保评测可靠185。对零售和电信领域，我们同样跟随 Claude Opus 4.5，在 user prompt 里加上一段通用的补充说明，以避免 user 错误地结束交互这类失败模式186。我们报告 8 次运行的平均分以确保评测结果稳定。
E.2.4 通用 benchmark
Arena-Hard-v2.0。我们使用 Arena-Hard-v2.0152 的官方评测指标，并用 GPT-4.1187 作为 judge 模型。
MultiChallenge。我们使用 MultiChallenge154 的官方评测指标，以 o3-mini188 作为 judge 模型。这遵循 GPT-5189 发布时的发现：GPT-4o187 经常给复杂回答误评分，导致结果被低估。
IFBench。我们使用 IFBench153 的官方评测方法。
E.2.5 长上下文 benchmark
LongBench v2。我们使用 LongBench v2155 的官方评测方法。
MRCR-8needle。对 MRCR-8needle156 benchmark，我们报告 Area Under Curve（AUC）指标，遵循 ContextArena190 建立的协议。具体来说，我们使用 AUC@128k 指标，它用单个整体分数概括了直到 131,072 token 的各上下文长度上的表现。
AUC 的计算方式是：把每个上下文分桶（从 8k 到 128k）的平均检索准确率对该桶的最大上下文长度作图，在线性尺度上用梯形法则测量曲线下面积，再用总上下文宽度（128k 减去初始桶大小）归一化，得到 0% 到 100% 之间的百分比分数。这个指标能有效地惩罚随着上下文变长、难度上升而出现的性能退化。
FRAMES-Oracle。我们使用 FRAMES158 的官方评测指标。由于我们关注的是长上下文能力，我们专门报告 Oracle Prompt 子集的结果。在这个设定下，模型除了问题之外还会拿到人工标注时用过的所有 ground-truth 维基百科文章。这个配置作为模型表现的上界，模拟一个把所有相关上下文都交付给模型的完美检索系统。
RepoQA。我们使用 REPOQA159 的官方评测方法。
E.3 内部评测——benchmark 与方法论
E.3.1 数据分析 Benchmark
为了可靠地评估 Step 3.5 Flash 在 Claude Code 环境里执行实用数据分析任务的能力，我们开发了一个内部的数据分析 Benchmark，用于评测在真实业务约束下的端到端分析式问题求解。这个 benchmark 的构建方式是系统性地把资深从业者的隐性经验提炼成一套以 rubric 为基础的评测套件。这个做法既捕捉了真实世界分析工作中的歧义与上下文微妙之处，又通过标准化 rubric 和可验证的 ground-truth 产物保证了评测一致性。
benchmark 采用专家驱动、基于 rubric 的协议构建，以确保领域真实性和打分可靠性。来自中国主要互联网公司的十位资深数据分析负责人（每人 15 年以上经验）通过结构化访谈贡献了真实业务案例，访谈过程引出了核心分析模式和决策逻辑。这个过程产出了有代表性的任务，以及经专家认可的解题策略。
访谈材料被规范化为机器可消费的任务，每个任务包含一份问题陈述、一个 CSV 数据集、一份参考分析和一份带权重的 checklist 式打分 rubric。最终 benchmark 含 50 个条目，覆盖多样的分析意图，每个任务平均 26.9 条 rubric。质量通过迭代的专家评审来保证，对齐任务定义、数据、参考解答和评测标准，以提升有效性和可复现性。
我们还实现了一个统一的端到端评测框架，涵盖任务执行、自动打分和报告合成。这个框架在同一条流水线里支持基于代码的、研究导向的和纯文本的分析，使跨异构环境的评测既可扩展、可复现，集成开销又低。
评测方法。每个任务由一个基于模型的评测器对照专家定义的 rubric 给生成的输出打分，结果在 3 次相同运行上取平均，以降低随机方差、确保跨模型评测可靠可比。
| Model | Avg@3（%） |
|---|---|
| Claude Opus 4.5 | 45.0 |
| Step 3.5 Flash | 39.6 |
| GPT-5.2 | 39.3 |
| Gemini 3.0 Pro | 33.6 |
| Deepseek V3.2 | 27.9 |
Table 19：数据分析 Benchmark 上的评测结果。
评测结果。Table 19 给出数据分析 Benchmark 上的结果。Claude Opus 4.5 总体第一，而 Step 3.5 Flash 取得了强势的第二（39.58%），与 GPT-5.2（39.31%）非常接近。它有竞争力的表现可能部分与它对 Claude Code 环境的适配相对较好有关。此外，Step 3.5 Flash 展现出有利的速度—能力权衡：在保持扎实的分析质量的同时给出更快的响应。这些结果把 Step 3.5 Flash 定位为真实世界数据分析任务里一个高效且有竞争力的选择。
E.3.2 咨询与建议 Benchmark
为了严格评测 Step 3.5 Flash 在真实咨询场景下的表现，我们从 Reddit、Stack Exchange 和各类社区论坛等真实社交平台收集了 500 条多样查询，构成一个 benchmark。这些查询代表了日常生活、学术学习、娱乐和职场语境下的真实用户意图。
这里我们实现了一个「基于锚点」（Anchor-Based）的打分框架来评测候选模型。这个流程中，我们先用领先模型——包括 GPT-5.2、Claude Opus 4.5 和 DeepSeek V3.2——为每条查询独立生成回答。这些高水平输出随后由人类专家综合、精炼，形成作为 ground truth 的参考回答。这个参考作为高质量的「锚点」，被赋予标准化的性能值 88/100。
然后我们在四个关键维度上度量模型表现，施加严格的打分 rubric，包括 Usefulness、Logic、Instruction Following 和 Tone。Usefulness 评估模型是否给出了一个开箱可用的方案，能以专家级深度、可执行的步骤和可行的建议真正解决任务。Logic 评估事实准确性和结构合理性，检查是否有幻觉、错误引用、无效结论，或因果与时间上的不一致，以及整体连贯性和论证流畅度。Instruction Following 度量对显式约束（例如格式、长度和明确要求）以及用户查询里隐含的上下文期待的遵循程度。Tone 评估沟通质量，包括语言与语域的得体性、拆解复杂推理时的清晰度，以及有校准的表达——避免过度自信，同时在适当时清楚地表明不确定性。
我们采用一套混合的 LLM-as-a-Judge 系统。认识到不同前沿模型有各自的评判长处，我们按如下方式分配具体打分职责：Logic、Instruction Following 和 Usefulness 这三个维度由 GPT-5.2 评测，利用它在事实核查、约束检查和客观问题求解上的行业领先能力；Tone 这个维度由 Claude Opus 4.5 评测，利用它在语言风格、情感校准和「类人」共鸣上更优的细腻度。judge 的可靠性通过与人类专家的一致性研究来验证，AI 与人类给出的分数之间取得了高 Pearson 相关。最终分数按四个维度等权（各 25%）计算，确保评估均衡地同时反映技术正确性和沟通质量。
| Model | Average | Usefulness | Logic | Tone | Instruction-following |
|---|---|---|---|---|---|
| GPT-5.2 | 77.8% | 77.2% | 81.9% | 73.0% | 79.6% |
| Kimi K2.5 | 72.2% | 77.1% | 62.1% | 72.7% | 77.3% |
| Gemini 3.0 Pro | 70.6% | 73.9% | 61.7% | 72.3% | 74.4% |
| Step 3.5 Flash | 70.5% | 73.3% | 62.1% | 72.4% | 74.2% |
| Deepseek V3.2 | 70.3% | 72.5% | 64.4% | 71.2% | 72.9% |
| GLM-4.7 | 70.3% | 73.5% | 61.5% | 72.5% | 73.6% |
| Claude Opus 4.5 | 68.5% | 69.7% | 66.5% | 65.9% | 72.1% |
| Mimo-V2 Flash | 67.9% | 71.5% | 58.0% | 70.6% | 71.4% |
| Minimax M2.1 | 67.1% | 70.7% | 60.1% | 67.2% | 70.4% |
Table 20：咨询与建议 Benchmark 上的评测结果。
评测结果。Table 20 显示 Step 3.5 Flash 在咨询与建议 Benchmark 上取得 70.5% 的平均分，总体排名第四。Step 3.5 Flash 在所有维度上都与 Gemini 3.0 Pro 表现相当，取得可比的 Pro 级分数（70.5% 对 70.6%），同时推理成本和延迟都低得多。不同于许多用推理质量退化来换速度的快模型，Step 3.5 Flash 在 Logic 维度上超过了更大的模型，减少了幻觉和逻辑失败，使它非常适合那些事实完整性至关重要的自动化咨询工作流。
E.3.3 Step 3.5 Flash + Step-GUI
为了验证 Step 3.5 Flash 在真实 agentic 场景下的有效性，我们在 AndroidDaily Hard191 上评测——这是一个为中文移动应用环境设计的有挑战性的 benchmark。它包含横跨电商交易、多媒体交互和日常移动操作的组合式任务，为评估 GUI agent 在复杂多步工作流（代表生产部署场景）中的能力提供了一个自然的测试床。
我们实证考察两种架构实例：（1）Step-GUI191，一个轻量的端侧 agent（Edge Only），用本地算力自主执行任务；（2）Step 3.5 Flash + Step-GUI，一个端云协同框架，其中 Step 3.5 Flash 作为云端推理编排器，合成高层任务计划、通过 GUI-MCP 协议把它们分解成可执行的原语，并把低层控制委派给端侧的 Step-GUI agent。这个分层架构利用了云端规模推理与端侧效率的互补优势：Step 3.5 Flash 的 11B 激活参数支撑复杂的多步规划和上下文理解，而 Step-GUI 保证低延迟的动作执行和保护隐私的本地控制。
定量结果。端云协同范式在 AndroidDaily Hard 上取得 57.0% 的成功率，大幅超过只用端侧的 baseline（40.0%）。这个结果说明，把强的云侧推理与高效的端侧执行结合起来，是应对多轮 agent 交互中部署约束的一条有效策略。
架构上的泛化。关键在于，这种协同模式可以超越移动生态、扩展到包括桌面电脑和汽车信息娱乐系统在内的异构平台。通过把认知编排（云）与具身执行（端）解耦，这个框架为在资源受限的工业环境里部署复杂 agent 建立了一个可扩展的范式——这与 Step 3.5 Flash 为生产级 agentic 系统重新定义效率前沿的设计目标直接对齐。这些结果强调，有效的真实世界 agent 不仅需要先进的推理能力，还需要在各基础设施层级之间协调算力分布的架构。
-
Step 3.5 Flash: Open Frontier-Level Intelligence with 11B Active Parameters, https://arxiv.org/abs/2602.10604 ↩︎
-
DeepSeek-V3.2-Exp: Boosting Long-Context Efficiency with DeepSeek Sparse Attention, 2025 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
-
GLM-4.5: Agentic, Reasoning, and Coding (ARC) Foundation Models, https://arxiv.org/abs/2508.06471 ↩︎ ↩︎ ↩︎
-
LongCat-Flash Technical Report, https://arxiv.org/abs/2509.01322 ↩︎ ↩︎
-
Kimi K2: Open Agentic Intelligence, https://arxiv.org/abs/2507.20534 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
-
MiniMax-M2.1, 2025 ↩︎
-
Transformers Are RNNs: Fast Autoregressive Transformers with Linear Attention, ICML 2020（原文在「可验证任务」与 §6.2「AIME2025」两处也引用了此条目，与上下文不符，疑为 bib key 错配） ↩︎ ↩︎ ↩︎
-
LiveCodeBench: Holistic and Contamination Free Evaluation of Large Language Models for Code, https://arxiv.org/abs/2403.07974 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
-
GPT-5.2, 2025 ↩︎
-
Gemini 3 Pro Model Card, 2025 ↩︎
-
System Card: Claude Opus 4.5, 2025 ↩︎
-
Introducing SWE-bench Verified, https://openai.com/index/introducing-swe-bench-verified/ ↩︎ ↩︎ ↩︎ ↩︎
-
SWE-smith: Scaling Data for Software Engineering Agents, https://arxiv.org/abs/2504.21798 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
-
tau2-bench, https://github.com/sierra-research/tau2-bench ↩︎ ↩︎ ↩︎ ↩︎
-
Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces, https://arxiv.org/abs/2601.11868 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
-
BrowseComp: A Simple Yet Challenging Benchmark for Browsing Agents, 2025 ↩︎ ↩︎ ↩︎ ↩︎
-
BrowseComp-ZH: Benchmarking Web Browsing Ability of Large Language Models in Chinese, 2025 ↩︎ ↩︎ ↩︎
-
xbench: Tracking Agents Productivity Scaling with Profession-Aligned Real-World Evaluations, https://arxiv.org/abs/2506.13651 ↩︎ ↩︎ ↩︎
-
ResearchRubrics: A Benchmark of Prompts and Rubrics for Evaluating Deep Research Agents, https://arxiv.org/abs/2511.07685 ↩︎ ↩︎ ↩︎ ↩︎
-
Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity, https://arxiv.org/abs/2101.03961 ↩︎ ↩︎ ↩︎
-
ST-MoE: Designing Stable and Transferable Sparse Expert Models, 2022 ↩︎ ↩︎
-
GLaM: Efficient Scaling of Language Models with Mixture-of-Experts, ICML 2022 ↩︎ ↩︎
-
GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding, 2020 ↩︎ ↩︎ ↩︎ ↩︎
-
DeepSeekMoE: Towards Ultimate Expert Specialization in Mixture-of-Experts Language Models, 2024 ↩︎ ↩︎ ↩︎
-
Generating Long Sequences with Sparse Transformers, https://arxiv.org/abs/1904.10509 ↩︎ ↩︎
-
Better & Faster Large Language Models via Multi-Token Prediction, https://arxiv.org/abs/2404.19737 ↩︎
-
DeepSeek-V3 Technical Report, https://arxiv.org/abs/2412.19437 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
-
MiMo: Unlocking the Reasoning Potential of Language Model — From Pretraining to Posttraining, https://arxiv.org/abs/2505.07608 ↩︎ ↩︎
-
Gated Attention for Large Language Models: Non-Linearity, Sparsity, and Attention-Sink-Free, 2025 ↩︎ ↩︎ ↩︎ ↩︎
-
OpenRouter, https://openrouter.ai ↩︎
-
gpt-oss-120b & gpt-oss-20b Model Card, 2025 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
-
Muon: An Optimizer for Hidden Layers in Neural Networks, 2024 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
-
Measuring Short-Form Factuality in Large Language Models, https://arxiv.org/abs/2411.04368 ↩︎ ↩︎
-
Group Sequence Policy Optimization, https://arxiv.org/abs/2507.18071 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
-
Your Efficient RL Framework Secretly Brings You Off-Policy RL Training, 2025 ↩︎ ↩︎
-
Stabilizing MoE Reinforcement Learning by Aligning Training and Inference Routers, https://arxiv.org/abs/2510.11370 ↩︎ ↩︎ ↩︎
-
Equation of State Calculations by Fast Computing Machines, The Journal of Chemical Physics 21(6):1087–1092, 1953 ↩︎ ↩︎
-
Monte Carlo Sampling Methods Using Markov Chains and Their Applications, 1970 ↩︎ ↩︎
-
Towards Robust Mathematical Reasoning, EMNLP 2025 ↩︎ ↩︎ ↩︎ ↩︎
-
PaCoRe: Learning to Scale Test-Time Compute with Parallel Coordinated Reasoning, 2026 ↩︎ ↩︎ ↩︎
-
Building Effective Agents, https://www.anthropic.com/engineering/building-effective-agents ↩︎
-
Unrolling the Codex Agent Loop, https://openai.com/index/unrolling-the-codex-agent-loop/ ↩︎
-
Scaling LLM Test-Time Compute Optimally Can Be More Effective Than Scaling Parameters for Reasoning, ICLR 2025 ↩︎
-
s1: Simple Test-Time Scaling, https://arxiv.org/abs/2501.19393 ↩︎ ↩︎ ↩︎
-
Multiverse: Your Language Models Secretly Decide How to Parallelize and Merge Generation, NeurIPS 2025 ↩︎
-
Longformer: The Long-Document Transformer, https://arxiv.org/abs/2004.05150 ↩︎
-
Fast Inference from Transformers via Speculative Decoding, ICML 2023 ↩︎ ↩︎
-
Linear Transformers Are Secretly Fast Weight Programmers, ICML 2021 ↩︎
-
Opt-Tree: Speculative Decoding with Adaptive Draft Tree Structure, TACL 13:188–199, 2025 ↩︎
-
DySpec: Faster Speculative Decoding with Dynamic Token Tree Structure, World Wide Web 28(3):36, 2025 ↩︎
-
When Linear Attention Meets Autoregressive Decoding: Towards More Effective and Efficient Linearized Large Language Models, ICML 2024 ↩︎
-
GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints, EMNLP 2023 ↩︎
-
EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty, ICML 2024 ↩︎
-
Command A: An Enterprise-Ready Large Language Model, 2025 ↩︎
-
Efficient Streaming Language Models with Attention Sinks, ICLR 2024 ↩︎
-
Massive Activations in Large Language Models, COLM 2024 ↩︎ ↩︎
-
When Attention Sink Emerges in Language Models: An Empirical View, ICLR 2025 ↩︎
-
Highly Accurate Protein Structure Prediction with AlphaFold, Nature 596(7873):583–589, https://doi.org/10.1038/s41586-021-03819-2 ↩︎
-
Forgetting Transformer: Softmax Attention with a Forget Gate, ICLR 2025 ↩︎
-
Auxiliary-Loss-Free Load Balancing Strategy for Mixture-of-Experts, https://arxiv.org/abs/2408.15664 ↩︎ ↩︎ ↩︎ ↩︎
-
FastMTP: Accelerating LLM Inference with Enhanced Multi-Token Prediction, 2025 ↩︎
-
PyTorch 2: Faster Machine Learning Through Dynamic Python Bytecode Transformation and Graph Compilation, ASPLOS 2024 ↩︎
-
Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism, https://arxiv.org/abs/1909.08053 ↩︎
-
Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM, 2021 ↩︎
-
ZeRO: Memory Optimizations Toward Training Trillion Parameter Models, SC20 ↩︎ ↩︎
-
MoE Parallel Folding: Heterogeneous Parallelism Mappings for Efficient Large-Scale MoE Model Training with Megatron Core, 2025 ↩︎
-
SonicMoE: Accelerating MoE with IO and Tile-Aware Optimizations, 2025 ↩︎
-
Old Optimizer, New Norm: An Anthology, 2024 ↩︎
-
The Polar Express: Optimal Matrix Sign Methods and Their Application to the Muon Algorithm, 2025 ↩︎ ↩︎
-
Demons in the Detail: On Implementing Load Balancing Loss for Training Specialized Mixture-of-Expert Models, https://arxiv.org/abs/2501.11873 ↩︎ ↩︎
-
Qwen3 Technical Report, https://arxiv.org/abs/2505.09388 ↩︎ ↩︎
-
Language Models Are Unsupervised Multitask Learners, 2019 ↩︎ ↩︎
-
On Layer Normalization in the Transformer Architecture, ICML 2020 ↩︎ ↩︎
-
Common Crawl, https://commoncrawl.org ↩︎
-
OpenCoder: The Open Cookbook for Top-Tier Code Large Language Models, 2025 ↩︎ ↩︎
-
SWE-bench: Can Language Models Resolve Real-World GitHub Issues?, ICLR 2024 ↩︎
-
Agentless: Demystifying LLM-Based Software Engineering Agents, https://arxiv.org/abs/2407.01489 ↩︎ ↩︎
-
RoFormer: Enhanced Transformer with Rotary Position Embedding, 2024 ↩︎ ↩︎
-
Effective Long-Context Scaling of Foundation Models, 2024 ↩︎ ↩︎
-
DeepSeek-V3.2: Pushing the Frontier of Open Large Language Models, https://arxiv.org/abs/2512.02556 ↩︎ ↩︎ ↩︎
-
Time Limits in Reinforcement Learning, 2022 ↩︎
-
DeepScaleR: Surpassing O1-Preview with a 1.5B Model by Scaling RL, 2025 ↩︎
-
DAPO: An Open-Source LLM Reinforcement Learning System at Scale, https://arxiv.org/abs/2503.14476 ↩︎ ↩︎
-
Open-Reasoner-Zero: An Open Source Approach to Scaling Up Reinforcement Learning on the Base Model, https://arxiv.org/abs/2503.24290 ↩︎ ↩︎ ↩︎
-
CodeForces, https://codeforces.com/ ↩︎
-
On the Measure of Intelligence, https://arxiv.org/abs/1911.01547 ↩︎
-
DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models, 2024 ↩︎ ↩︎
-
Training Language Models to Follow Instructions with Human Feedback, 2022 ↩︎
-
Generative Verifiers: Reward Modeling as Next-Token Prediction, 2025 ↩︎
-
Rank Analysis of Incomplete Block Designs: I. The Method of Paired Comparisons, Biometrika 39(3/4):324–345, 1952 ↩︎
-
NuminaMath: The Largest Public Dataset in AI4Maths with 860k Pairs of Competition Math Problems and Solutions, 2024 ↩︎
-
Big-Math: A Large-Scale, High-Quality Math Dataset for Reinforcement Learning in Language Models, https://arxiv.org/abs/2502.17387 ↩︎
-
Orca-Math: Unlocking the Potential of SLMs in Grade School Math, https://arxiv.org/abs/2402.14830 ↩︎
-
Olympiads, https://huggingface.co/datasets/aslawliet/olympiads ↩︎
-
OpenR1-Math-220k, https://huggingface.co/datasets/open-r1/OpenR1-Math-220k ↩︎
-
DeepMath-103K: A Large-Scale, Challenging Math QA Benchmark, https://arxiv.org/abs/2504.11456 ↩︎
-
OpenThoughts: Data Recipes for Reasoning Models, https://arxiv.org/abs/2506.04178 ↩︎
-
AM-Thinking-v1: Advancing the Frontier of Reasoning at 32B Scale, 2025 ↩︎
-
TACO: Topics in Algorithmic Code Generation Dataset, 2023 ↩︎
-
DeepCoder: A Fully Open-Source 14B Coder at O3-Mini Level, https://www.together.ai/blog/deepcoder ↩︎
-
CodeContests+: High-Quality Test Case Generation for Competitive Programming, 2025 ↩︎
-
CAMEL: Communicative Agents for “Mind” Exploration of Large Scale Language Model Society, 2023 ↩︎
-
Llama-Nemotron: Efficient Reasoning Models, 2025 ↩︎
-
MegaScience: Pushing the Frontiers of Post-Training Datasets for Science Reasoning, https://arxiv.org/abs/2507.16812 ↩︎
-
WildChat: 1M ChatGPT Interaction Logs in the Wild, https://arxiv.org/abs/2405.01470 ↩︎
-
IFEvalG checkers, https://github.com/allenai/open-instruct/tree/main/open_instruct/IFEvalG ↩︎
-
WebExplorer: Explore and Evolve for Training Long-Horizon Web Agents, https://arxiv.org/abs/2509.06501 ↩︎
-
WebSailor: Navigating Super-Human Reasoning for Web Agent, https://arxiv.org/abs/2507.02592 ↩︎
-
Simulating Environments with Reasoning Models for Agent Training, https://arxiv.org/abs/2511.01824 ↩︎
-
SWE-Factory: Your Automated Factory for Issue Resolution Training Data and Evaluation Benchmarks, 2026 ↩︎
-
DockSmith: Scaling Reliable Coding Environments via an Agentic Docker Builder, 2026 ↩︎
-
Training Software Engineering Agents and Verifiers with SWE-Gym, https://arxiv.org/abs/2412.21139 ↩︎
-
R2E-Gym: Procedural Environments and Hybrid Verifiers for Scaling Open-Weights SWE Agents, https://arxiv.org/abs/2504.07164 ↩︎
-
SWE-rebench: An Automated Pipeline for Task Collection and Decontaminated Evaluation of Software Engineering Agents, https://arxiv.org/abs/2505.20411 ↩︎
-
SETA: Scaling Environments for Terminal Agents, 2026 ↩︎
-
KEPLER: A Unified Model for Knowledge Embedding and Pre-Trained Language Representation, TACL 9:176–194, 2021 ↩︎
-
DeepSeek-R1 Incentivizes Reasoning in LLMs Through Reinforcement Learning, Nature 645(8081):633–638, https://doi.org/10.1038/s41586-025-09422-z ↩︎ ↩︎
-
OpenHands: An Open Platform for AI Software Developers as Generalist Agents, https://arxiv.org/abs/2407.16741 ↩︎ ↩︎
-
SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering, NeurIPS 2024 ↩︎ ↩︎
-
Kilo Code, https://kilo.ai/ ↩︎
-
Roo Code, https://roocode.com/ ↩︎
-
Claude Code, https://claude.com/product/claude-code ↩︎ ↩︎
-
Challenging BIG-Bench Tasks and Whether Chain-of-Thought Can Solve Them, 2022 ↩︎ ↩︎
-
Measuring Massive Multitask Language Understanding, 2020 ↩︎ ↩︎
-
MMLU-Pro: A More Robust and Challenging Multi-Task Language Understanding Benchmark, https://arxiv.org/abs/2406.01574 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
-
HellaSwag: Can a Machine Really Finish Your Sentence?, 2019 ↩︎ ↩︎
-
WinoGrande: An Adversarial Winograd Schema Challenge at Scale, 2019 ↩︎ ↩︎
-
GPQA: A Graduate-Level Google-Proof Q&A Benchmark, 2023 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
-
SuperGPQA: Scaling LLM Evaluation Across 285 Graduate Disciplines, 2025 ↩︎ ↩︎
-
SimpleQA, https://github.com/openai/simple-evals ↩︎
-
Measuring Mathematical Problem Solving with the MATH Dataset, 2021 ↩︎ ↩︎
-
Evaluating Large Language Models Trained on Code, https://arxiv.org/abs/2107.03374 ↩︎ ↩︎ ↩︎
-
Program Synthesis with Large Language Models, https://arxiv.org/abs/2108.07732 ↩︎ ↩︎ ↩︎
-
Is Your Code Generated by ChatGPT Really Correct? Rigorous Evaluation of Large Language Models for Code Generation, 2023 ↩︎ ↩︎ ↩︎
-
MultiPL-E: A Scalable and Extensible Approach to Benchmarking Neural Code Generation, 2022 ↩︎ ↩︎
-
C-Eval: A Multi-Level Multi-Discipline Chinese Evaluation Suite for Foundation Models, 2023 ↩︎ ↩︎
-
CMMLU: Measuring Massive Multitask Language Understanding in Chinese, 2023 ↩︎ ↩︎
-
Chinese SimpleQA: A Chinese Factuality Evaluation for Large Language Models, https://arxiv.org/abs/2411.07140 ↩︎ ↩︎
-
CF-Div2-Stepfun, https://huggingface.co/datasets/stepfun-ai/CF-Div2-Stepfun ↩︎ ↩︎
-
From Live Data to High-Quality Benchmarks: The Arena-Hard Pipeline, 2024 ↩︎ ↩︎ ↩︎
-
Generalizing Verifiable Instruction Following, https://arxiv.org/abs/2507.02833 ↩︎ ↩︎ ↩︎
-
MultiChallenge: A Realistic Multi-Turn Conversation Evaluation Benchmark Challenging to Frontier LLMs, 2025 ↩︎ ↩︎ ↩︎
-
LongBench v2: Towards Deeper Understanding and Reasoning on Realistic Long-Context Multitasks, 2024 ↩︎ ↩︎ ↩︎
-
Michelangelo: Long Context Evaluations Beyond Haystacks via Latent Structure Queries, https://arxiv.org/abs/2409.12640 ↩︎ ↩︎
-
OpenAI MRCR 数据集, https://huggingface.co/datasets/openai/mrcr ↩︎
-
Fact, Fetch, and Reason: A Unified Evaluation of Retrieval-Augmented Generation, NAACL 2025 ↩︎ ↩︎ ↩︎
-
RepoQA: Evaluating Long Context Code Understanding, 2024 ↩︎ ↩︎ ↩︎
-
YaRN: Efficient Context Window Extension of Large Language Models, 2023 ↩︎
-
Metadata Conditioning Accelerates Language Model Pre-Training, ICML 2025 ↩︎
-
Physics of Language Models: Part 3.3, Knowledge Capacity Scaling Laws, https://arxiv.org/abs/2404.05405 ↩︎
-
Beyond URLs: Metadata Diversity and Position for Efficient LLM Pretraining, 2025 ↩︎
-
LiveBench: A Challenging, Contamination-Limited LLM Benchmark, 2025 ↩︎
-
American Invitational Mathematics Examination — AIME 2024 ↩︎
-
American Invitational Mathematics Examination — AIME 2025 ↩︎ ↩︎
-
MathArena: Evaluating LLMs on Uncontaminated Math Competitions, https://arxiv.org/abs/2505.23281 ↩︎
-
中国数学奥林匹克（CNMO）, https://www.cms.org.cn/Home/comp/comp/cid/12.html ↩︎
-
Instruction-Following Evaluation for Large Language Models, 2023 ↩︎
-
WildBench: Benchmarking LLMs with Challenging Tasks from Real Users in the Wild, 2024 ↩︎
-
RULER: What’s the Real Context Size of Your Long-Context Language Models?, 2024 ↩︎
-
HELMET: How to Evaluate Long-Context Language Models Effectively and Thoroughly, 2024 ↩︎
-
GSM-Infinite: How Do Your LLMs Behave over Infinitely Increasing Context Length and Reasoning Complexity?, 2025 ↩︎
-
Systematic Outliers in Large Language Models, ICLR 2025 ↩︎
-
Organize the Web: Constructing Domains Enhances Pre-Training Data Curation, 2025 ↩︎
-
Nemotron-CC: Transforming Common Crawl into a Refined Long-Horizon Pretraining Dataset, 2025 ↩︎
-
MegaMath: Pushing the Limits of Open Math Corpora, 2025 ↩︎ ↩︎
-
SmolLM2: When Smol Goes Big — Data-Centric Training of a Small Language Model, 2025 ↩︎
-
BIG-Bench-Hard CoT prompts, https://github.com/suzgunmirac/BIG-Bench-Hard/tree/main/cot-prompts ↩︎
-
LiveCodeBench Pro: How Do Olympiad Medalists Judge LLMs in Competitive Programming?, https://arxiv.org/abs/2506.11928 ↩︎
-
AutoCode: LLMs as Problem Setters for Competitive Programming, ICLR 2026 ↩︎
-
PyPy, https://pypy.org/ ↩︎
-
CodeELO: Benchmarking Competition-Level Code Generation of LLMs with Human-Comparable Elo Ratings, 2025 ↩︎
-
terminal-bench-2-verified, https://huggingface.co/datasets/zai-org/terminal-bench-2-verified ↩︎
-
tau2-bench airline ground-truth 修正, https://github.com/sierra-research/tau2-bench/pulls/chrisgorgo ↩︎
-
Claude Opus 4.5 tau2 model card, https://github.com/anthropics/model-cards/tree/main/claude-opus-4-5-20251101/tau2 ↩︎
-
OpenAI o3-mini, 2025 ↩︎
-
Introducing GPT-5, 2025 ↩︎
-
ContextArena, https://contextarena.ai/ ↩︎
-
Step-GUI Technical Report, https://arxiv.org/abs/2512.15431 ↩︎ ↩︎
Author houmin
Publish July 30, 2026
LastMod July 31, 2026
License 本作品采用 CC BY-NC-ND 4.0 许可协议进行许可，转载时请注明原文链接
如果你在浏览博客的过程中发现了任何问题，欢迎在对应文章下评论。如果你有其他事情想要咨询，可以通过邮件联系我。