INTELLECT-3: 在强 base 上做大规模 agentic RL

1 · 动机:为什么是 agentic RL × strong base × 106B

I-3 看上去只是"又一个 RL post-training paper",但放在 Prime Intellect 自家系列里看,它每个选择都意味深长。这一节拆三个维度。

1.1 历史脉络:RL 后训练的爆点已经从 reasoning 漂移到 agentic

2024 末到 2025 上半年,开源 RL 后训练的"剧本"是:在一个 dense base 上跑 GRPO/DAPO,优化数学推理 chain-of-thought。DeepSeek-R1、Qwen3-Thinking、INTELLECT-2 都属于这一波。这一波的特征是:

• 单 turn,prompt → long CoT → final answer
• verifier 是规则(math-verify、test cases pass/fail)
• rollout 长度 8k–32k token,但拓扑简单

到 2025 下半年,前沿模型(o3、Grok 4、GLM-4.5、Kimi K2.5)已经把竞争点漂到了agentic + tool-use + 长 horizon:模型一次任务里要 search → click → 读网页 → 写代码 → 跑 sandbox → 看 stderr → 改代码 → 提交。开源框架(verl、OpenRLHF、TRL、NeMo-RL)对这种 multi-turn rollout 的支持往往是外挂而不是 first-class。

I-3 的论证非常直白:"从 SFT 到大规模 RL,我们整条 stack 都是为这个新爆点设计的"——prime-rl 的 orchestrator、verifiers 的环境 hub、Prime Sandboxes 的 4000+ 并发执行,全是为了 agentic episode 服务。

1.2 别的方案为什么不够

1.3 为什么这事不平凡

读 I-3 容易觉得"啊不就是 SFT + GRPO 嘛,怎么没新算法?"——但把 Prime Intellect 系列看成一条曲线,I-3 的非平凡性来自三个看似背离 I-1/I-2 叙事的取舍:

• 放弃 from-scratch 预训练。I-1 的招牌是"我们能去中心化预训一个 10B 模型"。I-3 直接从 GLM-4.5-Air-Base 起步,不再"自己造轮子"。这等于公开承认:在开源世界里,"造一个有竞争力的 base"不是 Prime Intellect 的比较优势——挑一个好 base,把 RL 做到极致才是。
• 放弃跨地理分布式 RL。I-2 的卖点是 "decentralized RL across the internet"。I-3 把 60 个节点(512 H200)塞在一个 InfiniBand fabric 里,160 GB/s AllReduce、Slurm + cgroup v2、Lustre + NVMe NFS——一个标准的 frontier lab 集群。Decentralized 这个词在 I-3 全文几乎不出现。
• 把 Environment 当一等公民管理。verifiers 库 + Environments Hub 把"环境"做成 PyPI-like 的可版本化、可分发模块。这是工程上最有 lasting impact 的事。

所以 I-3 真正的"非平凡"不在某个 ML trick 上,而在一组 infra 优先级重排 上。系统层面的硬骨头(in-flight weight update、grouped-MM MoE、context parallelism、distributed Muon、千并发 sandbox、Headless Service + nsenter 注入命令)远多于算法新意。

2 · 背景速查

对读者(已熟悉 I-1/I-2)的最小补丁:把 prime-rl 想成 PipelineRL/AReal 思想 + verifiers env 接入层 + 自家 vLLM 改造;最关键的工程差异是"orchestrator 是个 CPU 进程,trainer/inference 真物理 disaggregated"。

3 · 系列演化:I-1 → I-2 → I-3

这一节是给老读者看的 differential。如果只读一节,读这节。

3.1 每一代解决了什么、留下了什么

个人 take:I-1/I-2 是"在错的题上做对的事";I-3 是"切到对的题,再做正确的事"。从一个长期 thesis 来说，这个调整很健康——开源生态最缺的不是分布式预训框架，是可复现的 RL 后训练 cookbook + 环境治理。

4 · prime-rl 架构: 三件套 + async off-policy

4.1 三件套

prime-rl 把 RL 训练拆成三个物理 disaggregated 的角色:

• Trainer: FSDP2 + torchtitan 风格,吃 packed batches,产出新 weights θ_n
• Inference: 多个独立 vLLM 服务,带自定义 /update_weights 与 /reload_weights 端点
• Orchestrator: 一个 CPU 进程,既往 inference 推送新 weights、又从 inference 收 rollout、组 batch、给 trainer

4.2 Async one-step off-policy

同步 on-policy 的痛点:inference 生成完 (x_0, y_0),它必须等 trainer 算出 θ_1 才能继续。Async 下,inference 可以在 trainer 还在算 g_0 的时候,继续用 θ_0 生成 (x_1, y_1)——下一步训练就是用了"老一步"的 policy 产生的 rollout,通过 IS 校正。

I-3 默认 max_off_policy_steps = 8。也就是同一条 rollout 跨越的 policy 跨度若超过 8 个版本,就丢掉。这给 IcePop 校正留了一个"安全围栏"。

5 · Continuous batching + in-flight weight updates

这部分是 prime-rl 相对 verl/OpenRLHF 最具体的工程改进。问题场景:reasoning model 在 agentic 环境里,rollout 长度方差极大(短的 5k,长的 60k);如果 batch 必须等最慢的那条结束才能投到 trainer,那 batch 末期 inference 池的大部分槽位是 idle 的。

5.1 Continuous batching: rollout 池"永远满"

orchestrator 维护一个固定大小 N 的 in-flight rollout 池。任何一条 rollout 完成后,立刻在池子里替换成一个新的 prompt。这与 vLLM 自身的 token-level continuous batching 是两层不同抽象:vLLM 管的是"同一个 batch 里 token 步进的对齐";orchestrator 管的是"prompt 级的池子保持饱和"。

5.2 In-flight weight update: 同一条 rollout 跨多 policy

当 trainer 产出 θ_n+1,orchestrator 通知 inference 池,vLLM 服务暂停 generation 几百毫秒,接收新权重,然后从中断处继续 decode。也就是说,同一条 rollout 的前 5k token 可能由 θ_n 产生,后 35k token 由 θ_n+1 产生。这是 IcePop 这种 token-level 而非 sequence-level 的 IS 必须支持的原因——sequence-level IS 在这种场景下分母都不知道写什么。

5.3 Multi-Client Orchestrator: 为什么不用 vLLM 自带 DP

这是个有趣的小细节。I-3 试过 vLLM 多节点 data-parallel,发现 inference throughput 不能 linearly scale,加节点出现 plateau。原因是 vLLM 多节点 DP 内部有协调开销。他们的解决方案非常朴素:每个 inference 节点跑一个独立 vLLM server,orchestrator 维护 N 个 client,简单 round-robin 派发 prompt group,完全去掉 inter-node 同步。结果:throughput 与节点数线性 scale。

(个人 take: 这种"放弃框架内置的 DP,自己在外层做 sharding"的做法在大集群里非常常见,是个很好的工程教训。)

6 · Verifiers + Environments Hub: 把环境当 PyPI 包来管

这是 I-3 最有 lasting 价值的设计——比模型本身重要。

6.1 一个环境是什么

environments/primeintellect/i3-code/      # 一个 pip-installable 模块
├── pyproject.toml        # 锁依赖
├── env.py
│   ├── load_environment()       # 工厂方法
│   ├── class CodeEnv(SandboxEnv):
│   │     dataset: 8.6K Python 题
│   │     async def rollout(client, prompt, info):
│   │         # 多轮交互,直到 termination
│   │     class Rubric:
│   │         reward_funcs = [test_pass_rate, format_check]

类继承层级:Environment → MultiTurnEnv → ToolEnv → StatefulToolEnv → SandboxEnv → CodeEnv。每一层加一个能力:多轮 / OpenAI 工具调用格式 / 工具参数依赖 rollout 状态(如 sandbox ID)/ 沙箱执行 / 测试用例打分。

6.2 EnvGroup: 多环境同时训练

I-3 训练时同时在 math + code + science + logic + deepdive + deepswe 等多个环境上跑。EnvGroup 是 verifiers 提供的"把多个环境拼成一个"的容器,数据集 concat 后注入一列 task_id,rollout/score 时按 task_id 路由到对应子环境。

6.3 Hub vs 把环境塞 trainer 仓库里

实际效果:报告说截至发布时已有 500+ 环境。这是个生态飞轮——别人加的环境 prime-rl 直接能用,反过来 prime-rl 的训练成果验证了环境质量。

7 · Prime Sandboxes: 千并发代码执行

"在 RL 训练里跑用户代码"是 agentic RL 的最大基础设施开销之一。I-3 单单 i3-code 一个环境就需要 4000+ 并发 sandbox。直接用 K8s 的 kubectl exec 死路一条——他们实测每条命令延迟可达 2.5s,瓶颈在 etcd 的 write lock。

7.1 三层旁路 K8s 控制面

三个关键 trick:

• Headless Service + 自建 CoreDNS: Gateway 通过 DNS A 记录直接拿到 pod IP,跳过 kube-proxy load balancing
• nsenter sidecar: 不用 kubectl exec(那会过 API server + websocket upgrade),sidecar 直接进 target namespace 起进程
• Push-based readiness: pod 启动完主动 webhook 通知训练后端,不让训练池子 poll K8s

结果:< 10s 冷启,瞬时 4000+ 并发,256 sandboxes/node 的密度。

8 · MoE × 长序列 × Muon 的工程取舍

8.1 为什么没启用 Expert Parallelism

106B / 12B-active MoE 一般会想到用 EP 切 experts。但 I-3 经实测关掉 EP 比开 EP 快。论文里 Figure 5 给了一个直观图:torch._grouped_mm 在 hidden=4096, MoE_dim=1408 下,当每张 GPU 上的 token 数足够大时(seq=32k–64k),即使专家数 128 也已经把 grouped GEMM kernel 喂饱了。这时再切 EP,只会引入 scatter/gather 通信开销,而不能再降低 grouped GEMM 时间。

这里的隐含教训:EP 不是 MoE 训练的银弹,要看 per-GPU token 数能不能 saturate kernel。

8.2 长序列:CP 不行,activation offload 凑合

Activation memory 估算 (46 层, hidden 4096, FA3 + full activation checkpointing):

到 48k seq + FSDP=32 还能扛;到 64k+ 必须再做点什么。两条路:

Agentic SFT 阶段(98k 上下文)他们才上 CP。这是个非常实用的"先 offload 撑住,再 CP 顶天"的级联策略。

8.3 Distributed Muon

Muon 操作的是整个矩阵(Newton-Schulz 迭代),与 FSDP 把权重 shard 在不同 rank 上天然冲突。两个方案:

• Round-robin gather: 每个 rank gather 自己负责的那部分参数的全梯度 → 算 NS → scatter 回去。能并行,但许多并发 gather 在 IB 上撞车。
• All-to-all reshuffle (Dion 实现): 一次 all-to-all 把 shard 重排,每个 rank 拿到完整某些矩阵。少 collective、能避堵塞,生产用这个。

MoE 的 state dict 还要在广播给 vLLM 时动态变换:trainer 用 torchtitan grouped-MM layout,inference 用 HF 标准 MoE layout,在 push 权重的 hot path 上做 layout 转换。

9 · RL 算法: Masked token-level IS (IcePop)

I-3 的 RL loss 没有创新,直接用了 IcePop [Zhao et al. 2025]。我们写出公式然后做物理直觉。

9.1 公式

9.2 物理直觉

• 每个 token 算一个 IS ratio = 当前训练 policy / 产生 rollout 时 policy。
• 如果 ratio 在 [0.5, 5] 之间,正常用;超出就整个 token 的梯度置 0(masking,而不是 clipping)。
• 另外有个 lower threshold 1e-5,如果整条 rollout 里某 token 的 ratio 太小(意味着 trainer 已经几乎不会产出这个 token),整条 rollout 屏蔽。
• Advantage 是 group-relative(GRPO 风格,每 prompt 16 个 rollout),归一化只减均值。

9.3 反向论证: 为什么 mask 而不是 clip

常见做法是 PPO clip:min(r, clip(r, 1-ε, 1+ε)) · A。但当 r 极大时 clip 后还是有梯度——只是被截断到边界。在 high off-policy + reasoning rollout 这种 long-tail 场景里,这种"边界值"的梯度本身是噪声(因为 r 很大说明这是个 trainer 不太会产出的 token,信号其实不可信)。Mask 干脆不算这个 token 的梯度。

9.4 训练不稳定性: GSPO 崩盘

论文有一张 ablation 图(Figure 10):同一个 async-8 setup,用 GSPO 出现 reward 直接塌方;CISPO/IcePop 稳定。这跟 [Khatri et al. 2025] 与 [Qi et al. 2025] 的发现一致——sequence-level IS 在 high off-policy 下天然不稳。

9.5 一个具体数字示例

10 · 训练配方与一个具体 agentic episode 走查

10.1 配方一览

10.2 一个具体 episode: deepswe 跑通一个 GitHub issue

设想 task: "Project requests/requests 中 Cookie 在 redirect 时被 leak 给三方域,issue #1234"。环境是 deepswe (基于 mini-swe-agent-plus 改的 scaffold)。

关键预算估算: 一条 rollout 上限 200 turns × 平均 200 token/turn ≈ 40k token,而 RL ctx 是 65k,所以一条难题真的会撞天花板。这也是为什么 future work 里专门提到"long horizon agents 要让模型自己管理 context"——65k 不够用了。

10.3 Reward 与 mask 的细节

• 多 reward 加权: Rubric 抽象支持 (test_pass, format_check, length_penalty) 等多个函数加权;deepswe 主要用 test_pass。
• per-turn 还是 per-episode credit: I-3 直接 episode-level reward,通过 Â_{i,t} = S_i − mean 把 sparse reward 平摊到所有 assistant token(类 GRPO 风格)。没有显式的 turn-level credit assignment——他们押注 advantage normalization + IS 足够。
• tool 输出处理: tool message 的 token 在 loss 里 mask=0;reasoning + tool_call 的 token mask=1。
• sandbox 失败: 自动 mask 整条 completion 并取消 generation,避免无效 reward 干扰。

11 · 实验关键结果

11.1 主表(节选)

读法:

• I-3 同尺寸下(对 GLM-4.5-Air post-train)全面胜出,尤其 LCB +7.8、AIME25 +6.0、MMLU-Pro +8.0。这是论文最干净的卖点。
• 对 3× 大的 GLM-4.5,在 AIME24/25 与 LCB 实际更高或相当;但 GPQA 与 MMLU-Pro 输了 — 大模型的"知识广度"还是吃尺寸。
• 对自家上游 GLM-4.6 (它本身已经是更强的版本),I-3 整体仍输——这说明 RL post-train ≠ 取代继续 pretrain。
• 对 DSR1-0528(6×参数)在 reasoning 上能压住,但 GPQA/HLE 知识题输 — 同一个模式。

11.2 训练曲线

论文给出在 AIME24/25, LCB, HLE, GPQA 上每 15 步的 online eval 曲线。训练到 ~600 步时曲线仍在向上,未饱和。这是 I-3 在 conclusion 里反复强调"如果再多训会更好"的依据。

11.3 训练效率

• step time ~1500s,seq 65k,16+44 节点
• 关掉 in-flight weight update → step time 增加 > 2× (inference 利用率塌方)
• 没有报告具体 MFU 数字。Activation offload(同步版)只降 0.1% MFU,几乎免费。

12 · 与同类工作对比

另请参见同期 sibling notes: 07_INTELLECT2_2505.07291.html(INTELLECT-2 详解,本目录下)与 01_INTELLECT1_2412.01152.html(INTELLECT-1 详解)。

13 · 局限 / 个人 take / 待验证问题

13.1 局限

• 没有报告 MFU。这种规模的训练 MFU 是核心 KPI,缺失让"高效"有点空泛;只能从"step time 1500s, 60 节点 65k seq"反推。
• RL 仅用了 Hub 中很小一部分环境(math/code/science/logic/deepdive/deepswe)。Hub 上 500+ 环境的多样性收益没在 I-3 里得到验证。
• 对 GLM-4.6 整体输。说明在一个相对老 base 上做 RL 的天花板低于"上游持续 pretrain + post-train"。
• Long-horizon 受限。RL ctx 65k,deepswe 上限 200 turns × 200 token = 40k;真正的"自动 AI research"任务还放不下。论文自己点了 context rot。
• 没有 turn-level credit assignment。现在的 advantage 是 episode-level 平摊,长 episode 信号稀疏的问题没正面解。
• Decentralized 叙事彻底淡出。从一个长期使命角度看,这意味着 Prime Intellect 把"分布式训练"作为商业卖点的可能性降低了——更像是要做"开源 RL infra 的 Anyscale"。

13.2 个人 take

• I-3 真正的护城河不是模型,是 verifiers + Environments Hub。这个抽象+注册中心是开源 agentic RL 的"PyPI 时刻"。如果这套用起来,prime-rl 就有了类似 vLLM 之于 inference 的位置。
• "放弃 EP" + "Multi-Client Orchestrator" + "Headless Service + nsenter" 这三件事是反框架思维:不要相信框架内置的东西总是最优——尤其在大集群上,简单的 round-robin / 自管 DNS / 旁路 K8s 经常更稳。
• IcePop (mask not clip) 这种"long-tail r 干脆不学"的策略,与本届 RL 训练社区(R1 / Qwen3 / MiniMax)的总体方向一致 — sequence-level IS 在 high off-policy 下基本被淘汰。

13.3 待验证问题

1. Hub 的环境质量分布是什么?500+ 环境里多少能直接拿来训生产模型?多少其实是 toy?
2. 如果对 GLM-4.6-Base(更新更强 base)做同样的 prime-rl pipeline,能不能压过 GLM-4.6 official post-train?
3. EnvGroup 的 mix ratio 是怎么调的?有没有自动 curriculum(类似 GSM-PLUS 的难度自适应)?
4. max_off_policy_steps=8 怎么选的?是用 IS variance 监控 + 早期 ablation,还是经验值?
5. tool 输出非常长(如网页 markdown)时,KV cache 会膨胀,vLLM 怎么调度 / 是否做 KV eviction?
6. 在 60 节点规模下,fault-tolerance 故事是什么?Slurm 重启?checkpoint 频率?这个规模 1500s/step 跨"两个月",工程必然踩过坑但论文没展开。
7. 没有 DeepSpeed ZeRO,坚持 FSDP2 + torchtitan 的取舍依据 — 是性能还是社区一致性?

14 · 记忆点