Skywork Open Reasoner 1 Technical Report

Paper: arXiv:2505.22312 Code: SkyworkAI/Skywork-OR1 Code reference: main @ 64e96af (2025-06-06)

1. Motivation (研究动机)

这篇技术报告要解决的不是“如何再做一个推理模型榜单”，而是一个更具体的问题：在 DeepSeek-R1-Distill 这类已经具备很长 CoT 输出习惯的 SFT/蒸馏模型上，如何用在线 RL 继续提高数学与代码推理，同时避免长输出带来的训练成本、无效样本、以及策略熵过早塌缩。作者的出发点是，DeepSeek-R1 已经证明了基于规则奖励的在线 RL 可以显著提升推理能力，但多数复现工作把重点放在 base model 或较短 CoT 场景；当基础模型本身平均会生成上万 token 的推理链时，朴素套用 GRPO/PPO 会遇到三个现实瓶颈：rollout 占用绝大部分训练时间，固定上下文长度会截断样本并引入 noisy reward，策略很容易在少数轨迹上过早收敛，导致后续训练“看起来还在跑、但测试性能不再增长”。

作者把这些瓶颈统一到一个工程化 RL pipeline 中处理。Skywork-OR1 的目标是训练开放的数学与代码推理模型系列，包括 Skywork-OR1-Math-7B、Skywork-OR1-7B 和 Skywork-OR1-32B，并公开模型权重、RL 数据与训练代码。论文特别强调，它不是只报告最终分数，而是把训练 recipe、消融实验和 entropy collapse 诊断放在同等重要的位置：哪些数据该保留，context length 如何分阶段扩大，截断响应要不要 mask，温度与 group size 如何影响学习信号，KL loss 是否真的有益，off-policy update 为什么会伤害泛化，以及在资源更多时应把计算投到 rollout budget 还是更多 SGD step。

Figure 1 解读：这张曲线展示 32B 模型在 RL 训练中 AIME 2024/2025 的性能随步骤变化，并用红星标出最终 checkpoint。它说明 Skywork-OR1 的收益不是单点调参，而是来自多阶段训练过程中持续增加 context、保持探索能力并选择合适 checkpoint 的组合。对读者来说，关键不是曲线最高点，而是“RL 后期仍然可继续提高”这一现象，因为后文所有 entropy-control 与资源分配实验都围绕如何保持这种后期可塑性展开。

Figure 2 解读：32B 模型的主要结果把 Skywork-OR1-32B 与 DeepSeek-R1、Qwen3-32B 等强基线放在同一组数学与代码任务上比较。图中最重要的信息是数学 benchmark 上的优势：AIME24 和 AIME25 均超过当时强基线；LiveCodeBench 上虽然略低于 DeepSeek-R1/Qwen3-32B，但仍达到同一量级。它支撑了论文的核心 claim：使用公开 recipe 训练 DeepSeek-R1-Distill-Qwen-32B 仍可获得显著 RL 增益。

Figure 3 解读：7B 结果说明同一 recipe 不只适用于 32B 规模。Skywork-OR1-7B 相比 DeepSeek-R1-Distill-Qwen-7B 在 AIME24、AIME25 和 LiveCodeBench 都有明显提升，且 Skywork-OR1-Math-7B 虽只偏向数学训练，也保持了较强数学能力。这为后续大量基于 7B 的消融实验提供了合理性：作者用较小模型研究机制，再把结论迁移到最终 7B/32B 发布模型。

这项工作的研究价值在于，它把“RL for reasoning”从结果导向推向可复现的系统诊断。若只关心最终模型分数，读者无法知道性能来自数据、更长上下文、更多采样、还是某个 loss trick；而 Skywork-OR1 的实验明确区分了 sample efficiency、token efficiency、entropy dynamics、off-policy bias 和计算资源分配。对于后续想训练开放推理模型的人，这比单个 checkpoint 更有价值，因为它提供了可迁移的训练守则：长 CoT 模型的 RL 首先是 rollout 与探索管理问题，其次才是扩大模型或堆更多训练步数。

2. Idea (核心思想)

Skywork-OR1 的核心 insight 是：长 CoT 模型的在线 RL 成败主要取决于能否在“有效奖励信号”和“策略熵不塌缩”之间维持平衡。作者提出的 MAGIC（Multi-stage Adaptive entropy scheduling for GRPO In Convergence）不是一个单独的新损失，而是一套围绕 GRPO 的训练 recipe：用高质量、可验证且难度适中的样本产生非零组内优势；用多阶段 context length 控制早期成本与截断比例；用高温 rollout 保持组内多样性；用 adaptive entropy control 动态调节熵项；并移除会把 actor 拉回 reference policy 的 KL loss。

与 DeepScaleR、DAPO、VAPO 这类同时期工作相比，Skywork-OR1 的差异在于实验问题更聚焦于长 CoT 的训练动力学。DeepScaleR 已经使用多阶段 context 扩展来降低成本，DAPO/VAPO 强调 PPO/GRPO 的稳定化 trick；而 Skywork-OR1 把这些选择放到同一个因果链中解释：多阶段训练让早期 rollout 更短，截断负样本反而有助于 token efficiency；高温采样和 on-policy update 延缓熵塌缩；过多 SGD step 虽然节省 wall-clock 但会引入 off-policy 数据并损害泛化；资源增加时，与其减少 rollout latency，不如增大 rollout batch 或 group size 以得到更好的梯度估计。

一句话概括：本文的创新不是“又一个 GRPO 变体”，而是把长 CoT 推理模型 RL 训练中最容易被混淆的工程变量拆开，并给出一套面向可复现开放模型的 MAGIC recipe。其根本贡献是把 entropy collapse 从事后现象提升为训练设计的主线指标：当策略熵过快趋近 0 时，模型会失去探索多样推理路径的能力，测试性能也难以继续提升；反过来，适度维持熵下界能让 RL 在后期仍有学习空间。

3. Method (方法)

3.1 预备：从 GRPO 到 MAGIC 的训练目标

论文以 GRPO 为基础。对 prompt $x$ 和 response $y$，规则 verifier 给出二值奖励 $r(x,y)\in \{0,1\}$，目标是最大化 $J(\pi )={\mathbb{E}}_{x\sim D,y\sim \pi (\cdot |x)}[r(x,y)]$。在每个训练步 $k$，模型对每个 prompt 采样 $M$ 个 response，使用组内 reward 的均值与标准差估计 token-level advantage： $A_t^{ij}=racr(x_i,y_{ij})-\mathrm{mean}(r(x_i,y_{i1}),\dots ,r(x_i,y_{iM}))\mathrm{std}(r(x_i,y_{i1}),\dots ,r(x_i,y_{iM})).$ MAGIC 对 vanilla GRPO 做了三类改造。第一，数据层面只保留可验证、正确且对当前模型有难度的问题，并在训练中 reject 掉组内全对或全错的 prompt 组，因为它们的 GRPO advantage 为零，不能提供有效 policy-gradient 信号。第二，训练策略层面使用 multi-stage context length、rollout temperature $au=1.0$、默认不对截断 response 做 advantage mask，并倾向 on-policy update。第三，loss 层面移除 response-length normalization，用 token-level 平均 policy loss，并加入 adaptive entropy term： $L_{\text{MAGIC}}(\theta )=-\frac{1}{T_k}{\sum }_{i\in {\tilde{T}}_k}{\sum }_{j=1}^M{\sum }_{t=0}^{|y_{ij}|-1}\left[\min ({\rho }_t^{ij}(\theta )A_t^{ij},\mathrm{clip}({\rho }_t^{ij}(\theta ),1-ϵ,1+ϵ)A_t^{ij})+{\alpha }_k{H}_t^{ij}(\theta )\right].$ 直观上，移除长度归一化会避免短回答在 loss 中被过度放大，使训练更像“每个 token 都承担相同平均权重”；保留 PPO-style clip 则避免一次更新把策略推得太远。熵项的作用不是让模型永远随机，而是在模型过快收敛时提供一个可调的探索下界，使后续数据仍然能改变策略。

3.2 数据收集与 rejection sampling

数据部分有两个层级。离线层面，数学数据来自 NuminaMath-1.5、DeepScaleR、STILL-3-Preview-RL-Data、Omni-MATH 和 2024 年以前 AIME 等来源；代码数据主要来自 LeetCode 与 TACO。作者先做去重、答案提取一致性检查、AIME24/25 去污染、格式/URL/图像过滤，再用模型感知难度估计筛掉“当前模型全错或全对”的题。论文报告最终约保留 105K 数学问题和 13.7K 代码问题，其中代码问题约 2.7K 来自 LeetCode、11K 来自 TACO。对当前模型的离线难度估计中，7B 模型在数学/代码上分别丢弃 21.4%/28% 全错、32.4%/24% 全对，保留 46.2%/48%；32B 模型保留比例为 37.3%/37.6%。

代码中，or1_scripts/data_preprocess/download_and_filter_data_7b.py 与 download_and_filter_data_32b.py 从 Skywork/Skywork-OR1-RL-Data 加载数据，读取 extra_info.model_difficulty 中对应 base model 的难度值，只保留 difficulty 在 1 到 15 之间的样本，再按 ability == math/code 拆成训练 pkl。这个实现与论文的“去掉 0/N 与 N/N”一致：对 group size 16 的数学场景，difficulty 1–15 正好表示至少有一个正确且至少有一个错误 rollout。

Figure 4 解读：左图比较 Skywork-OR1 自定义数学 mixture 与 DeepScaleR mixture；右图比较默认 mixture 与加入较低验证标准额外数据的 mixture。关键结论有两个：一是 DeepScaleR 的数据对更小模型有效，但在作者早期 32B 数学实验中训练约 300 步后性能回落；二是少量带潜在答案噪声的额外难题主要减慢早期学习，而没有立即破坏最终趋势。这解释了为什么最终 recipe 强调“难且可验证”，但也承认 RL 对少量 ground-truth 噪声有一定鲁棒性。

在线层面，verl/trainer/ppo/ray_trainer.py 在计算 rule-based reward 后按 uid 聚合同一 prompt 的 group rewards。如果某个 uid 下所有 reward 都是 0 或所有 reward 都是 1，就把这组样本标成 invalid；当 trainer.rejection_sample=True 时，只保留有非零组内 advantage 的组，并把 batch size 截断到 world size 的整数倍。这正对应论文中的 $ilde{T}_k$：只让存在非零 advantage 的 prompt group 进入 policy update。这样做的意义不是提高表面 reward，而是防止 zero-advantage 组在 policy loss 中无贡献，却继续通过熵项或 KL 项改变训练比例。

3.3 Multi-stage context length：先省 token，再恢复 scaling

长 CoT 模型的早期 rollout 往往非常长，直接用 16K 或 32K context 会让训练成本被 generation 主导。Skywork-OR1 采用 multi-stage training：先用较短 context 限制响应长度和计算成本，等性能趋于稳定后再提升 context length。论文的消融从 8K→16K 与从头 16K 对比，发现两者最终 AIME24 accuracy 都可收敛到约 60，但 multi-stage 在前 1000 步约节省 100 训练小时，并把 Stage I 平均响应长度从约 12.5K 降到约 5.4K，同时不阻断后续 Stage II/III 的响应长度与准确率增长。

Figure 5 解读：左侧把 response length、AIME24 avg@8 与累计训练小时放在一起，说明 multi-stage 的收益来自早期更短输出带来的 rollout 成本下降；右侧比较 AIME24 avg@32 与响应长度，说明 Stage I checkpoint 已能以更短响应达到接近 DeepSeek-R1-Distill-Qwen-7B 的性能，后续 stage 再用更长 context 恢复 scaling。这个图是 MAGIC 中“效率”和“能力”可以兼得的关键证据。

需要注意，发布代码的 or1_scripts/train/*.sh 是按 context length 分开的脚本，而不是一个自动切换 stage 的 orchestrator。论文 Table 10–12 给出最终发布模型的 stage schedule；但代码里 7b_16k.sh、7b_32k.sh、32b_16k.sh、32b_32k.sh 等脚本只暴露固定的 RES_LENGTH，用户需要按阶段手动运行或覆盖参数。因此训练配置在笔记中分开记录“论文报告的最终 stage schedule”和“released scripts 的可执行默认值”。

3.4 截断 response：为什么最终不做 advantage mask

短 context 下 response 超过 $T$ 会被截断，因为没有最终答案，accuracy reward 被置为 0。这可能把本来“如果继续生成会正确”的样本当成负样本。作者因此尝试三种策略：No-Adv-Mask、Adv-Mask-Before、Adv-Mask-After。理论分解中，训练准确率 $J(\pi )$ 可写成非截断概率 $p_{\pi }^{extnon-trunc}(x)$ 与非截断条件准确率 ${\bar{r}}_{\pi }^{extnon-trunc}(x)$ 的乘积；提高训练 reward 可以来自让回答更短以避免截断，也可以来自真正提高非截断回答质量。

Figure 6 解读：Stage I 初期约 40% response 被截断。训练前 100 步整体 accuracy 上升主要来自 clip ratio 快速下降，而非非截断样本质量立即提高；随后非截断 accuracy 才逐渐恢复。这说明短 context 的 early improvement 很大部分是 token-efficiency 学习：模型学会在上下文限制内给出答案。

Figure 7 解读：Adv-Mask-Before 确实让非截断 accuracy 上升，但 clip ratio 也持续增加，整体 training accuracy 下降；No-Adv-Mask 与 Adv-Mask-After 更能降低截断比例。作者把 Adv-Mask-Before 视为一种 reward-hacking 倾向：模型没有真正提高大 context 下的 test-time scaling，而是在短 context 下逃避被截断信号。

Figure 8 解读：当测试 context 放大到 32K 时，不同 advantage mask 策略的 AIME24 avg@32 最终没有显著差异；No-Adv-Mask 在 Stage I 学到的短回答习惯没有阻碍 Stage II 的进一步增长。这是最终 pipeline 不使用 truncation advantage mask 的直接依据。更一般地，它提醒我们：短 context 训练中的“截断负信号”不一定是噪声，也可能是驱动 token efficiency 的有效约束。

3.5 高温采样与 adaptive entropy control

GRPO 的学习信号依赖同一 prompt 下 $M$ 个 response 的组内差异。如果 temperature 太低，group 内样本相似，可能全对、全错，或者只在少数 token 上出现差异，优势信号会变窄。Skywork-OR1 将 rollout temperature 设为 $au=1.0$，而不是常见的 0.6。论文的温度消融显示，$au=0.6$ 的训练初始 entropy 低，约 100 步内快速塌缩到接近 0，学习变慢且趋于停滞；$au=1.0$ 早期 entropy 更高，虽然初期测试分数可能低，但保留了后续提升潜力。

Figure 9 解读：左侧 AIME25 avg@8 曲线显示高温采样在后期更有优势；右侧 entropy 曲线显示低温训练一开始就处于更低熵状态。这里的温度不是推理时“让模型更随机”的简单开关，而是训练时扩大组内 response diversity 的机制。对 GRPO 来说，diversity 本身就是 reward contrast 的来源。

Adaptive entropy control 则解决固定熵系数难调的问题。论文定义目标熵 tgt-ent 和步长 $\Delta$。令 $e_k$ 为当前 rollout buffer 估计的 actor entropy，若 $e_k<tgt\text{-}ent$，增大熵系数 $c_k$；若 $e_k>tgt\text{-}ent$，减小系数，并且只有当 $e_k\le tgt\text{-}ent$ 时才启用熵项： ${\alpha }_k=c_k\cdot 1\{e_k\le tgt\text{-}ent\},c_{k+1}=\{\begin{array}{ll}{c}_k+\Delta ,& e_k<tgt\text{-}ent\\ c_k-\Delta ,& e_k>tgt\text{-}ent\end{array},c_0=0.$ 代码中 verl/trainer/ppo/core_algos.py::EntController 实现了同一逻辑：current_ent < target_ent 时 value += delta_ent_coef，否则 value -= delta_ent_coef，随后 clip 到 [min_ent_coef, max_ent_coef]，并用 entropy_loss_enabled = int(current_ent < target_ent) 控制是否实际生效。verl/workers/actor/dp_actor.py 在 actor update 中计算 entropy_term = entropy_loss * entropy_coeff * entropy_loss_enabled，最终 policy_loss = pg_loss - entropy_term；如果 use_kl_loss 打开，才额外加 kl_term。

Figure 10 解读：Skywork-OR1-Math-7B 全阶段训练中，作者使用 tgt-ent=0.2 和 $\Delta =0.005$；entropy 大体被维持在目标附近，AIME24 avg@8 继续增长。这个图说明 adaptive entropy control 的作用不是让 entropy 越大越好，而是在模型即将过早收敛时提供下界，使训练保持可塑性。

3.6 No KL loss：不要把 actor 拉回 reference

传统 PPO/RLHF 中 KL loss 常用于约束 actor 不偏离 reference policy。但在这篇论文的 long CoT reasoning 场景中，作者发现 KL loss 会明显妨碍后期提升。Stage II 消融中，$\beta =10^{-3}$ 的 KL 项会快速把 actor 拉回 reference，使 KL divergence 接近 0，AIME24 性能增长停滞；移除 KL 后性能继续改善。因此最终发布模型所有训练阶段都设 $\beta =0$。

Figure 11 解读：左图显示加入 KL loss 后 actor-reference KL 快速下降，说明 policy 被强行约束回初始模型；右图显示这会限制 AIME24 avg@8 的继续增长。对 reasoning RL 来说，reference model 不是一个永远安全的锚点：如果目标是发现更强的长推理策略，过强 KL 约束会直接压制探索。

代码层面，or1_scripts/train/*.sh 并没有启用 actor_rollout_ref.actor.use_kl_loss；dp_actor.py 中 KL 分支只有在 self.config.use_kl_loss 为真时才计算 kl_penalty 并加到 policy_loss。这与论文最终 recipe 一致。论文公式与 released code 实现差异：论文 Table 10–12 报告最终模型 stage 中部分 batch/group 配置为 160/32 等；而公开训练脚本默认值主要是 ROLLOUT_BATCH_SIZE=256、GROUP_SIZE=16，且没有把论文 step schedule 写成单个自动流程。复现实验时应以论文表格理解最终训练配置，以脚本理解仓库默认可执行入口。

3.7 Entropy collapse 诊断：为什么 on-policy 更稳

总体结论与变量地图

论文第 4 节把 entropy collapse 单独作为研究对象。作者先给出经验结论：更快的 entropy collapse 通常对应更差的测试表现；增大 rollout batch size 或 group size 对 entropy dynamics 影响较小，但提高 sampling temperature 对初始 entropy 影响明显；增加每个 training step 中的 SGD 次数会引入 off-policy 数据，显著加速 entropy collapse 并降低泛化；固定熵系数高度依赖数据与系数，adaptive entropy control 或合适的 clip-higher 可以稳定 entropy。

Figure 12 解读

这张 overview 把“探索能力”拆成 rollout diversity 与 policy update 两条路径。黄色变量包括 temperature、rollout batch size、group size、SGD step 数、entropy loss 和 clip-higher。它是论文最重要的实验地图：后续实验不是零散调参，而是在检验哪些变量真正影响 entropy collapse。

基线设置与可复现配置

基线消融使用 DeepSeek-R1-Distill-Qwen-7B，设置 $D_R=64$、$D_T=64$、$N_{reuse}=1$、group size 16、context 16K、temperature 1.0、learning rate $10^{-6}$，无 entropy control、无 KL loss。该基线 2700 步后在 32 张 H800 GPU 上达到 AIME24 69.2、AIME25 53.3、LiveCodeBench 50.5，接近最终 7B 版本，因此适合作为机制研究平台。

Figure 13 解读

固定 entropy loss 系数的初步实验显示，较高的 ${\alpha }_k=5\times 10^{-3}$ 比 $10^{-3}$ 更能缓解熵塌缩，并带来更好测试性能。这证明“entropy collapse 可被干预”，但也引出后文问题：固定系数对数据和数值非常敏感，不能作为稳健 recipe。

Figure 14 解读

on-policy 条件下改变 rollout batch size $D_R\in \{16,32,64\}$ 或 group size $gs\in \{4,8,16\}$，entropy dynamics 差异不大，且都没有明显 collapse。这说明“只增加 rollout 多样性”并不是防止熵塌缩的充分解释；真正危险的是 policy update 中引入 off-policy 数据。

Figure 15 解读

on-policy update 在整个 rollout buffer 上做一次 SGD；off-policy update 则把 rollout buffer 切成 $D_R/D_T$ 个 mini-batch 并可复用 $N_{reuse}$ 次，因此 $N_{SGD}=D_R/D_T\cdot N_{reuse}$。这个公式把“更多 SGD step”与“同一 rollout 数据被更久地用于更新”联系起来，是后续性能下降的关键机制。

Figure 16 解读

当 $N_{SGD}$ 从 1 增加到 2 或 4，无论是减小 $D_T$ 还是增大 $N_{reuse}$，entropy 都会在很少训练步内快速下降，测试性能也不再稳定提升。它反驳了一个常见工程直觉：在 rollout 很慢时，多做几步 SGD 看似“更充分利用样本”，但在 on-policy RL 中会把数据变成 off-policy，从而伤害泛化。

Figure 17 解读

作者进一步控制 $D_T$，比较相同 SGD data size 下的 on-policy 与 off-policy。结果表明，较小 $D_T$ 的 on-policy 仍能稳定提升且不发生 premature collapse，而对应 off-policy 更差。因此性能下降主要不是 mini-batch 小导致的梯度噪声，而是 off-policy 数据本身造成的策略收敛过快。

Figure 18 解读

即使把 off-policy 配置的 rollout batch size 从 64 增大到 256，只要 $N_{SGD}=4$，仍不能阻止 entropy collapse，甚至可能更快。这说明“更多 rollout diversity”无法抵消多步 off-policy 更新的负面影响。

Figure 19 解读

固定 entropy coefficient 的敏感性非常强。${\alpha }_k=5\times 10^{-4}$ 到 $10^{-2}$ 会导致 entropy 最终上升过猛并造成模型 collapse；$10^{-4}$ 又无法阻止 entropy 继续下滑。该图支持 adaptive coefficient 的必要性：目标不是选一个全局最优常数，而是根据当前 entropy 自动调节。

Figure 20 解读

相同 ${\alpha }_k=10^{-3}$、相同配置，仅替换数学训练数据，就会产生完全不同的 entropy 演化：一个持续下降，另一个持续上升。这说明 entropy loss 的最优强度依赖数据分布，固定经验值很难迁移。

Figure 21 解读

在原本会快速塌缩的 off-policy 配置 $(N_{SGD},D_R,D_T,N_{reuse})=(4,64,16,1)$ 上开启 target entropy 0.2，可以阻止 entropy collapse 并提高测试性能。但作者也提醒，大 $N_{SGD}$ 下 adaptive entropy 仍可能不稳定，因为熵项在整个词表上计算，可能提高很多非预期 token 的概率。因此最终建议是优先保持 on-policy，再用 adaptive entropy control 作为辅助。

Figure 22 解读

clip-higher trick 也能影响 entropy。把 higher-clip 从 0.20 增到 0.25 或 0.265 可以减慢收敛并改善性能，但 0.28 会让 entropy 上升过快且性能不佳。结论是 clip-higher 的最佳值任务相关，不能机械照搬；Skywork-OR1 更强调先理解 entropy dynamics，再决定是否使用特定 trick。

3.8 资源分配：rollout 是瓶颈，更多资源应买更多样本

长 CoT RL 的总训练时间可拆成 rollout 时间 $t_R$、policy update 时间 $t_T$ 和其他开销 $t_O$：

$$t_{total}=t_R+t_T+t_O.$$

论文测得 Skywork-OR1-32B 训练 1000 步中，总耗时 309 小时，其中 rollout 223 小时，占 72.1%；policy update 仅 27 小时，占 8.7%。这解释了为什么工程师会想增加 $N_{SGD}$：如果 rollout 最贵，多做几步 update 看似几乎不增加总耗时。但第 4 节已经证明，这会通过 off-policy update 损害 entropy 与泛化。因此论文建议，固定资源下不要单纯增加 SGD step；资源增加时，也不要只指望 rollout latency 线性下降，因为最长 response 会限制并行收益。

Figure 23 解读：固定计算资源时，提升效率的候选路径包括减少 rollout 成本或增加 policy update 利用率。论文最终否定了“盲目增加 $N_{SGD}$”这一路径，因为它虽然时间成本小，却会牺牲泛化。该图把成本模型与训练质量联系起来，避免把吞吐优化误当成模型优化。

Figure 24 解读：当有更多 H800 资源时，作者建议把资源用于增加 rollout budget，而不是仅仅把同样 1024 个 response 分到更多 GPU 上。原因是 rollout time 随 GPU 数增加存在边际收益递减：生成 1024 个 response 时，32/64/128/256 H800 的 rollout time 分别约 375/270/225/205 秒，后期改善越来越小。

Figure 25 解读：在更多资源下增大 rollout batch size $D_R$ 可以在相近训练时间内带来更好测试性能。更大的 $D_R$ 提供更多 prompt 级别的梯度估计，而不必通过重复利用旧 rollout 来增加 update 次数，因此不会引入同等程度的 off-policy 风险。

Figure 26 解读：增大 group size 也能提升性能，因为同一 prompt 下更多 response 会给 GRPO 提供更可靠的组内相对优势估计。与增大 $D_R$ 不同，增大 group size 更直接改善 reward contrast；但二者共同点都是用更多 rollout budget 购买更好的 on-policy 信号。

3.9 Verifier：规则奖励的质量决定 RL 信号上限

数学 verifier 部分，作者比较了 verl 版 MATH verifier、PRIME verifier、Qwen2.5 verifier、DeepScaleR verifier 与 Math-Verify。Qwen2.5 verifier 会在解析中丢失信息，PRIME verifier 可能 stall，因此被排除；最终实现中先提取 reasoning 后的答案，用 Math-Verify parser 解析，如果解析出的字符串直接匹配 gold answer 则返回 True，否则把 gold answer 包进 \boxed{} 后调用 semantic verify。代码对应 verl/workers/reward_manager/hf_math_verify.py::math_verify_reward_function，并设置 parse timeout 与 verify timeout 以避免 verifier 本身拖垮训练。

代码 verifier 部分基于 LiveCodeBench 的实现，支持 stdin/stdout、solution function unit test 和 assert-based test。verl/utils/reward_score/livecodebench/compute_score.py 会从最后一个 Python code block 提取 solution，先用 ast.parse 做语法检查，再运行测试；compute_code_generation_metrics.py::check_correctness 使用 multiprocessing.Process 包装执行，默认 max_memory_gb=50，并用 psutil 监控主进程及子进程 RSS，超过阈值或超时则 kill。这个实现对应论文中的 syntax validation、memory monitoring 和 multiprocessing stability optimization。

Figure 27 解读：不同数学 verifier 会显著改变“某题有几个 rollout 正确”的分布，而这正是 GRPO 难度过滤和 advantage 估计的基础。如果 verifier 假阳性/假阴性较多，样本可能被错误保留或丢弃，训练 reward 也会偏移。因此 Skywork-OR1 把 verifier 选择作为训练 pipeline 的一等组件，而不是实验附录细节。

3.10 代码映射与伪代码

Paper Concept	Source File	Key Class/Function
训练入口与可执行超参	or1_scripts/train/7b_16k.sh, 7b_32k.sh, 32b_16k.sh, 32b_32k.sh, 32b_8k.sh	Hydra overrides: algorithm.adv_estimator=grpo, data.max_response_length, actor_rollout_ref.rollout.n, adaptive_entropy.*
GRPO 组内 advantage	verl/trainer/ppo/core_algos.py; verl/trainer/ppo/ray_trainer.py	compute_grpo_outcome_advantage; compute_advantage
Rejection sampling 去掉零 advantage 组	verl/trainer/ppo/ray_trainer.py	train loop around reward grouping by uid
PPO-style clipped policy loss	verl/trainer/ppo/core_algos.py; verl/workers/actor/dp_actor.py	compute_policy_loss; actor update_policy
Adaptive entropy control	verl/trainer/ppo/core_algos.py; verl/trainer/ppo/ray_trainer.py; verl/workers/actor/dp_actor.py	EntController; self.ent_ctrl.update; entropy_term
No-KL final recipe	verl/workers/actor/dp_actor.py; train scripts	if self.config.use_kl_loss; scripts omit KL activation
数据难度过滤	or1_scripts/data_preprocess/download_and_filter_data_7b.py, download_and_filter_data_32b.py	filter_fn over extra_info.model_difficulty
数学 verifier	verl/workers/reward_manager/hf_math_verify.py	math_verify_reward_function, MathVerifyRewardManager
代码 verifier / sandbox	verl/utils/reward_score/livecodebench/compute_score.py; .../compute_code_generation_metrics.py	ast.parse, check_correctness, multiprocessing memory monitor
评测脚本	or1_scripts/eval/eval_7b.sh, eval_32b.sh	AIME24/25 and LiveCodeBench rollout settings

MAGIC 训练步可按 released code 概括如下：

for prompt_batch in dataloader:
    responses = rollout_actor(prompt_batch, n=GROUP_SIZE, temperature=TRAIN_TEMPERATURE,
                              max_response_length=RES_LENGTH)
    reward_tensor = rule_based_reward(responses, math_verify_or_livecodebench)
 
    if adv_estimator == "grpo":
        # ray_trainer.py: group by uid, remove all-zero/all-one reward groups
        valid_groups = [uid for uid in groups if not all_rewards_same(uid)]
        batch = keep_only(valid_groups)
 
    advantages = compute_grpo_outcome_advantage(reward_tensor, uid, response_mask)
    old_log_prob = actor.compute_log_prob(batch)
 
    # dp_actor.py update
    log_prob, entropy = actor.forward(batch)
    pg_loss = clipped_ppo_loss(old_log_prob, log_prob, advantages, cliprange)
    entropy_term = mean(entropy, response_mask) * ent_controller.value * ent_controller.enabled
    policy_loss = pg_loss - entropy_term
    if use_kl_loss:
        policy_loss += kl_penalty(log_prob, ref_log_prob) * kl_coef
    optimizer.step(policy_loss)
 
    ent_controller.update(metrics["actor/entropy_loss"])

Adaptive entropy control 的 released code 逻辑非常短，但含义很关键：

if current_entropy < target_entropy:
    ent_coef += delta_ent_coef
else:
    ent_coef -= delta_ent_coef
ent_coef = clip(ent_coef, min_ent_coef, max_ent_coef)
entropy_loss_enabled = int(current_entropy < target_entropy)

代码搜索记录：已通过论文首页、Hugging Face paper page 与 GitHub 搜索确认公开代码为 SkyworkAI/Skywork-OR1；本地 clone 的版本为 main@64e96af，commit date 2025-06-06。源码审查覆盖了训练脚本、GRPO advantage、actor loss、entropy controller、数据过滤、数学 verifier、LiveCodeBench sandbox 和评测脚本。论文公式与 released code 实现差异：除了训练 stage schedule 未在脚本中自动串联外，论文第 8.1 节称评测生成 temperature 为 1、top-p 为 1；但 or1_scripts/eval/eval_7b.sh 中 AIME/LiveCodeBench 的 rollout.temperature=0.6，eval_32b.sh 则为 1.0。因此复现实验时应明确记录所用 eval script，而不能只按论文文字假设所有模型同温度评测。

4. Experimental Setup (实验设置)

4.1 发布模型训练配置

所有 Skywork-OR1 发布模型都基于 DeepSeek-R1-Distill 系列：7B 和 32B 分别基于 DeepSeek-R1-Distill-Qwen-7B 与 DeepSeek-R1-Distill-Qwen-32B。训练统一使用 MAGIC policy loss，常数学习率 $10^{-6}$、clip ratio 0.2、target entropy 0.2、sampling temperature 1.0、rejection sampling，并且不使用 KL loss。论文报告的最终 checkpoint 分别来自 Skywork-OR1-Math-7B step 2160、Skywork-OR1-7B step 1320、Skywork-OR1-32B step 1000。

Skywork-OR1-Math-7B 的论文 stage schedule：Stage 1 为 0–740 步、8K context、batch 256、mini-batch 128、group size 16；Stage 2 为 740–1740 步、16K context、batch 256、mini-batch 128、group size 16；Stage 3 为 1740–2080 步、32K context、batch 256、mini-batch 128、group size 16；Stage 3.5 为 2080–2160 步、32K context、batch 128、mini-batch 64、group size 64。

Skywork-OR1-7B 的论文 stage schedule：Stage 1 为 0–660 步、16K context、batch 256、mini-batch 256、group size 16；Stage 2 为 660–1320 步、32K context、batch 160、mini-batch 160、group size 32。Skywork-OR1-32B 的论文 stage schedule：Stage 1 为 0–760 步、16K context、batch 256、mini-batch 256、group size 16；Stage 2 为 760–1130 步、24K context、batch 160、mini-batch 160、group size 32。

released scripts 的默认配置略有不同，且更像复现入口模板：or1_scripts/train/7b_16k.sh 与 7b_32k.sh 设置 ENTROPY_COEFF=0.0、USE_ADAPTIVE_ENT=True、TGT_ENTROPY=0.2、MAX_ENT_COEF=0.005、MIN_ENT_COEF=0、DELTA_ENT_COEF=0.0001，ROLLOUT_BATCH_SIZE=256、PPO_MINI_BATCH=256、GROUP_SIZE=16、TRAIN_TEMPERATURE=1.0，并通过 data.max_response_length 切换 16K/32K。32B 脚本同样默认 batch 256、group 16，但 TP/SP 随 16K/32K 改变。这些数字来自实际 launch scripts，而非基础配置默认值。

4.2 消融实验配置

MAGIC component 的消融包括数据 mixture、多阶段训练、截断 advantage mask、采样温度、adaptive entropy 和 KL loss。重要共享配置包括：Table 1 的 Ablation Experiments 1 使用 batch 64、mini-batch 32、group size 16、target-entropy 0.2、无 KL；Table 2 的 advantage mask 消融使用 batch 256、mini-batch 128、group size 16、Stage I 8K、target-entropy 0.2、无 KL；Table 3 的温度消融使用 batch 64、mini-batch 32、group size 16、Stage I 16K、target entropy 0.2、KL 0；Table 4 的 KL 消融使用 batch 256、mini-batch 128、group size 16、Stage II 16K、target entropy 0.2。

Entropy collapse 主实验基线在 Section 4.1：$D_R=64$、$D_T=64$、$N_{reuse}=1$、group size 16、context 16K、temperature 1.0、learning rate $10^{-6}$、无 entropy control、无 KL。作者用 AIME24、AIME25 和 LiveCodeBench 2024-08 至 2025-02 作为消融评测集合，消融中的综合 test performance 是 AIME24/25 avg@8 与 LiveCodeBench pass@1 的经验均值。该基线使用 32 张 H800 GPU 训练 2700 步，达到 AIME24 69.2、AIME25 53.3、LiveCodeBench 50.5。

资源分配实验记录了长 CoT 训练耗时结构。Skywork-OR1-32B 1000 步耗时中，$t_{total}=309$ 小时，$t_R=223$ 小时，$t_T=27$ 小时，$t_O=59$ 小时，rollout 占 72.1%。在同样 32 H800 的 1000 步实验中，$(N_{SGD},D_R,D_T,N_{reuse})=(1,64,64,1)$、$(2,64,32,1)$、$(4,64,16,1)$ 的总耗时分别为 116、114、118 小时，说明增加 SGD step 对 wall-clock 影响确实小，但第 4 节显示它会带来熵塌缩和泛化下降。

4.3 评测设置

最终 benchmark 包括 AIME 2024、AIME 2025 和 LiveCodeBench 2024-08 至 2025-02。论文第 8.1 节报告：所有模型最大生成长度 32,768 tokens；AIME24/25 报告 avg@32；LiveCodeBench 报告 avg@4；生成 temperature 与 top-p 均为 1。avg@n 定义为 $n$ 次响应正确性的平均值。代码中 or1_scripts/eval/eval_32b.sh 与论文一致使用 temperature 1.0、top-p 1.0、response length 32768；or1_scripts/eval/eval_7b.sh 则把 temperature 设为 0.6。因此，评测复现应以具体脚本为准，并在报告中注明模型规模对应的温度差异。

5. Experimental Results (实验结果)

5.1 最终模型结果

Table 13 是论文最核心的结果。7B 组中，DeepSeek-R1-Distill-Qwen-7B 为 AIME24 55.5、AIME25 39.2、LiveCodeBench 37.6；Skywork-OR1-Math-7B 达到 69.8、52.3、43.6；Skywork-OR1-7B 达到 70.2、54.6、47.6。也就是说，在同一 7B distilled base 上，完整数学+代码 pipeline 把三项平均能力明显推高，其中 AIME24 增长 14.7、AIME25 增长 15.4、LiveCodeBench 增长 10.0。

≥32B 组中，DeepSeek-R1-Distill-Qwen-32B 为 72.9、59.0、57.2；Qwen3-32B 为 81.4、72.9、65.7；DeepSeek-R1 为 79.8、70.0、65.9；Skywork-OR1-32B 为 82.2、73.3、63.0。Skywork-OR1-32B 在 AIME24 与 AIME25 上超过 DeepSeek-R1 和 Qwen3-32B，在 LiveCodeBench 上略低于 DeepSeek-R1/Qwen3-32B 但仍显著超过其 distilled base。摘要中报告，32B 模型在 AIME24、AIME25 和 LiveCodeBench 的平均准确率从 57.8% 提升到 72.8%，增加 15.0%；7B 模型从 43.6% 提升到 57.5%，增加 13.9%。

Model	AIME24 avg@32	AIME25 avg@32	LiveCodeBench avg@4
DeepSeek-R1-Distill-Qwen-7B	55.5	39.2	37.6
Light-R1-7B-DS	59.1	44.3	39.5
AReaL-boba-RL-7B	61.9	48.3	-
AceReason-Nemotron-7B	69.0	53.6	51.8
Skywork-OR1-Math-7B	69.8	52.3	43.6
Skywork-OR1-7B	70.2	54.6	47.6
DeepSeek-R1-Distill-Qwen-32B	72.9	59.0	57.2
TinyR1-32B-Preview	78.1	65.3	61.6
Light-R1-32B	76.6	64.6	-
QwQ-32B	79.5	65.3	61.6
Qwen3-32B	81.4	72.9	65.7
DeepSeek-R1	79.8	70.0	65.9
Skywork-OR1-32B	82.2	73.3	63.0

这些结果的含义要和方法部分一起读。Skywork-OR1-32B 的数学提升并不只来自更长输出：作者在 token efficiency 图中已经显示 Stage I 可用更短响应达到接近 base 的性能；后期提升来自恢复更长 context、增加 rollout budget、维持 entropy，以及更高质量 verifier/data。LiveCodeBench 的相对弱项也提示，数学和代码的 reward/verifier 质量与数据难度分布不同；同一 MAGIC recipe 可以提升代码，但代码 benchmark 的上限仍受 sandbox、unit test 覆盖和数据难度影响。

5.2 Component ablation 的主要结论

数据 mixture 消融说明，高质量难题比简单扩大数据更重要。DeepScaleR mixture 在较小模型上已有强表现，但在作者早期 32B 数学实验中后期性能回落；Skywork mixture 加入 NuminaMath-1.5 等更广来源，并经过难度过滤和质量控制，训练更稳定。加入较低验证标准的额外数据不会立即毁掉训练，但会减慢早期学习，因此最终选择更干净的默认 mixture。

Multi-stage 消融说明，短 context 不是只为省钱，而是在早期塑造更高 token efficiency。8K Stage I 让响应明显缩短，节省约 100 小时/1000 步；切到 16K 后，性能在约 500 个 Stage II 步内追上从头 16K。更重要的是，短 context 训练没有破坏大 context scaling；反而为后续 Stage II/III 提供了更高效的起点。

Advantage mask 消融说明，对截断 response 的负优势不一定是坏信号。Adv-Mask-Before 会提高非截断 response 的局部质量，但模型可能通过继续生成更长响应来逃避短 context 约束，clip ratio 上升，整体 training accuracy 下降；测试到 32K 时也没有优势。因此最终不 mask truncated response，用负 reward 推动模型在有限 context 内更快给出答案。

Temperature 与 entropy control 消融说明，保持探索是长 CoT RL 的核心。$au=1.0$ 虽然增加随机性，但能提供更高初始 entropy 和组内多样性；固定 entropy coefficient 难以泛化，太小无效、太大 collapse，且对数据敏感；adaptive target entropy 0.2 能在多个阶段中提供更稳的下界。KL 消融则说明 reference policy 约束不总是安全，特别是在目标是超越 SFT distilled base 的 reasoning RL 中，KL 会直接阻碍后期性能上升。

5.3 Entropy collapse 与资源分配的综合启示

最重要的负结果是：更多 SGD step 不是免费午餐。由于 rollout 占 70% 以上耗时，工程上很自然想通过 $N_{SGD}>1$ 来提高样本利用率；但实验显示，只要引入 off-policy update，entropy 会更快塌缩，测试性能更差。即使把 $D_R$ 增到 256，只要 $N_{SGD}=4$，也不能阻止 collapse。这说明 long CoT RL 的瓶颈不是“每批样本没训练够”，而是“策略更新必须紧跟当前 rollout 分布”。

更合理的资源策略是：如果资源固定，优先降低 rollout 成本和改善 token efficiency，不要用 off-policy 多步更新硬换吞吐；如果资源更多，优先增加 rollout batch size 或 group size，让 on-policy 信号更丰富。Table 9 显示，生成同样 1024 个 response 时，H800 从 32 增到 256 的 rollout time 只从 375 秒降到 205 秒，边际收益递减；把资源用来增加 rollout budget 更能改善梯度估计和测试表现。

5.4 局限与可迁移经验

论文的局限之一是，许多结论来自 DeepSeek-R1-Distill-Qwen 系列与数学/代码 reward 组合，未必直接迁移到开放问答、工具调用或多模态 reasoning。尤其是 adaptive entropy control 的 target 0.2、clip-higher 的最佳值、temperature 1.0 等都依赖模型与数据；作者自己也展示固定 entropy coefficient 对数据高度敏感。第二个局限是 released scripts 与论文最终 stage schedule 不完全一键对齐，复现者需要手动组织阶段、checkpoint 与参数覆盖。第三，代码 sandbox 不处理多合法输出的非确定性题，这会限制部分真实编程题的 reward 准确性。

可迁移经验则非常清晰：第一，训练 reasoning model 时要先保证 verifier 和数据难度能产生非零组内优势，否则 RL 只是消耗 rollout；第二，长 CoT 的多阶段 context 是效率工具，也是行为塑形工具；第三，把 entropy 作为训练健康指标比只看 reward 更可靠，因为 reward 可能因回答变短或数据变易而上升，但 entropy collapse 往往预示泛化停止；第四，on-policy 性质对 reasoning RL 尤其重要，吞吐优化不能以旧 rollout 多步复用为代价；第五，最终报告必须同时记录论文配置和 released code 配置，避免把 paper recipe、GitHub script default 和本地复现实验三者混为一谈。