INTELLECT-2: A Reasoning Model Trained Through Globally Decentralized Reinforcement Learning

1 · 动机:从 INTELLECT-1 走到 INTELLECT-2 的鸿沟

1.1 历史脉络: 为什么 RL 比 pretraining 更适合 decentralized

INTELLECT-1 (2024-12) 已经证明: 用 DiLoCo + int8 ring all-reduce + ElasticDeviceMesh,可以把 10B-pretraining 在 5 大洲的 GPU 集群上跑到 ~83% 利用率。但即便如此,pretraining 在 decentralized setting 下仍然勉为其难:

• 每个 inner step 都要做一次跨节点通信(哪怕只是 8 比特量化的)
• worker 必须保持基本同步——一旦掉队太多,outer step 会被拖慢
• 所有节点都要装得下完整 model + optimizer states + activations

RL post-training 与之截然不同:

• 计算分布完全不同: 训练侧只占 ~20% FLOPs,推理 (rollout 生成) 占 ~80%。论文实测 train:infer FLOPs 比 = 1:4.5
• Inference 是 embarrassingly parallel: 一个 prompt 一条 trajectory,worker 之间不需要任何通信
• Inference worker 的内存压力小: 只需要装得下 frozen weights + KV cache,不需要 optimizer states / gradients
• 所以 inference 天然适合丢到消费级 GPU (3090, 4090, A6000) 上

论文里给出的核心洞察:communication 在 RL 里只剩一件事——把更新后的 policy 推给 inference worker。而这件事可以用 async 完全藏到 inference 计算时间后面。所以 RL = "decentralized 友好"。

1.2 别的方案为什么不够

"用现成的 RL 框架 + DDP 不行吗?"

所以 PRIME-RL 不是"又一个 RL 框架",而是第一次把 trustless 这个维度纳入设计目标的框架。

1.3 为什么这事不平凡: 三个新瓶颈

把 RL 搬到 permissionless swarm 上,有三个 INTELLECT-1 时代不存在的难题:

(a) Trust model 大变。Pretraining 时如果某节点提交错误梯度,DiLoCo outer step 的 averaging 会稀释影响,且最坏情况下 reward (loss) 自己会暴露异常。但 RL 里,一个恶意 inference worker 完全可以:

• 用一个更小的模型生成 token,然后只用大模型跑一次 prefill 来"伪造"hidden states
• 提前 EOS 截断长输出来省钱
• cherry-pick 简单题目反复刷
• 把别的 worker 提交过的 trajectory 抄一遍

这些都不会被 reward function (binary 0/1) 直接捕捉,但会污染训练分布。

(b) Async 在 RL 里有质变。Pretraining 的 DiLoCo 是"梯度 stale",RL 的 async 是"policy stale"。后者直接改变了 sampling 分布——rollout 用的是 πθ_{t-2},更新算的是 πθ_t 与 πθ_{t-2} 的 importance ratio。如果 lag 太大,ratio 会爆炸 → GRPO 的 clip 频繁触发 → 学习信号被截掉。

(c) Weight broadcast 在 RL 里成了新瓶颈。32B bf16 = 62 GB。要发给几十个全球 inference worker,如果用 naive 单点 server,带宽根本不够。论文实测一次 broadcast 平均 14 分钟 = 590 Mb/s——这已经是优化后的数据。

2 · 背景速查

2.1 术语

2.2 系统全貌 (Figure 1 抽象)

3 · PRIME-RL: 把 train / infer / verify 三相分离

PRIME-RL 与 verl/TRL/OpenRLHF 的根本区别:它把 trainer 和 inference worker 写成两个独立的可执行文件,彼此只通过 Parquet 文件 + HTTP step counter 通信。这一点对应 INTELLECT-1 里 ElasticDeviceMesh 的"动态 join/leave"诉求。

3.1 训练侧

• FSDP2 sharding (类 ZeRO-3): 32B 模型在 8×H100 上做参数 / 梯度 / optimizer state shard
• 不接收 inference 节点提交的 log_prob——而是在 trainer 端用当前 policy 自己重算一遍。原因: vLLM 报告的 log_prob 数值不稳定,而 GRPO 的 importance ratio 对此非常敏感
• 训练数据走 Parquet 远程 storage,trainer pull 而不是 worker push

3.2 推理侧

• vLLM bf16 跑 QwQ-32B
• 用一个确定性 seed = node_address · step + submission_count 决定每个 worker 拿哪条 prompt → 防止 cherry-pick
• 每生成 32 token,就 hash 一次 final hidden state,作为 TOPLOC proof 的一部分
• HTTP polling 一个 step counter endpoint,问"现在哪一步还缺 rollout?",这就是 worker join/leave 的对接点

3.3 一个完整的 RL step 走一遍 (worked example)

假设训练已跑到 step 100,trainer 刚 broadcast 了 weights_100。一个"3090×4"消费级 worker 加入:

1. 0:00 Worker 启动,联系 discovery service,被 orchestrator 邀请加入 pool
2. 0:30 Worker 从 SHARDCAST relay 下载 weights_100 的 shards,SHA-256 校验通过 → 装载到 vLLM
3. 0:31 Worker GET /step_counter,得到 "step 102 还差 800 个 rollout";seed = hash(addr) · 102 + 0 = 12345
4. 0:31 Worker 用 seed=12345 从 285K 题库里采样 16 道 (一个 GRPO group),开始生成
5. ~5:00 16 条 trajectories(平均 4-8K tokens)生成完毕,期间每 32 token 增量 hash 一次 hidden state
6. 5:01 Worker 计算 reward(数学: SymPy 比对答案;coding: 跑单元测试)
7. 5:02 把 (prompts, responses, rewards, advantages, TOPLOC proofs) 打包成 Parquet,signed-URL 上传到 step_102 文件夹
8. 5:03 触发链上事件,TOPLOC validator 看到新文件,启动验证 (~1 min)
9. 6:00 验证通过,parquet 添加 accepted=True flag,trainer 的 dataloader 能读到
10. ~22:00 step 102 收齐 4096 个有效样本,trainer 跑 8 个 GRPO optimizer steps
11. ~36:00 新 weights_102 写入 SHARDCAST,broadcast 14 min(下一步并行做)

4 · TOPLOC: 在不信任节点上验证 rollout

这是论文最有"技术新意"的部分。问题: 怎么在不可信 worker 上验证它真的用规定的 weights 跑了 inference?

4.1 设计目标的紧约束

朴素思路:让 validator 重跑一遍 inference 比对 token by token。不行,因为:

• GPU 非确定性: 不同 GPU 型号 / 不同 tensor parallel 配置下,同一 model + 同一 prompt 的 logits 数值有微小差异 → 重跑直接对比会 false-positive
• 验证不能比生成慢: 否则验证就成了新瓶颈

TOPLOC 的两个核心 trick:

1. 验证用 prefill 而不是 decode: 给定 prompt + 完整 response,validator 一次性 forward (parallel),只要算一遍而不是逐 token 自回归 → 可以做到 ~100× 比 decode 快
2. 对比的不是完整 hidden states,而是 top-k indices + polynomial commitment: 鲁棒处理 GPU 非确定性引起的微小数值差异

4.2 TOPLOC proof 的工作流

4.3 三类 check 一图汇总

4.4 一个具体的攻击场景及如何被检出

攻击: 一个 worker 想省钱——用 0.5B 小模型生成 token,但仍然报告自己用了 32B QwQ。它在 submit 之前用 32B 跑一次 prefill 得到看起来"对"的 hidden states。

检测: TOPLOC 的 sampling check 会注意到 token 概率分布。正常 32B sampling 后,该 token 在它自己的 distribution 上概率应当较高(typical mode 接近 1)。但用 0.5B sample 出的 token,在 32B 重算的 distribution 上,会有相当一部分落在 low-probability 区域 → distribution 出现 bimodal (一峰在 1,另一峰在 0)。validator 通过分析 prefill 时取得的 selected-token probability 直方图,发现双峰即拒绝。

反向论证: 如果 TOPLOC 不验证 sampling 形状,只验 hidden state hash 是否对得上呢?那么这个 hybrid 攻击就过得了—— prefill 是真用 32B 跑的,hidden states 自然对。所以 sampling check 不是冗余,而是"证 worker 真的用 32B 来 sample"的最后一道防线。

5 · SHARDCAST: tree-CDN 式权重广播

32B bf16 = 62 GB。要在 ~14 分钟内推给几十个全球 inference worker。Naive 方案的失败:

• "trainer 直接给每个 worker push": trainer 单点带宽极限,几十 worker 同时拉直接打死
• "P2P (BitTorrent style)": 需要暴露 worker 间的 IP,带来 DoS 风险;且 P2P 需要 trustless shard verification (每个 shard 自带签名),工程复杂

SHARDCAST 选了中间路线:3 层 tree CDN — origin (训练侧) → relay (中间层) → client (inference worker),每个 relay 像 nginx CDN 节点。

5.1 设计要点

• Sharded + pipelined: checkpoint 分片传输,worker 不必等完整文件就能开始下载,relay 也不必等完整文件就能开始服务
• EMA-based 多源采样: client 给每个 relay 维护 (success_rate, bandwidth) 的指数移动平均,按比例概率采样下一次从哪个 relay 拿 shard;一个 healing factor 强制周期性探索 underused server
• Relay 只保留最新 5 个 checkpoint: 既省磁盘也"功能性正确"——更老的 checkpoint 产出的 rollout 反正会被 trainer 拒绝
• SHA-256 完整性: client 装载前比对整体 checksum,失败就丢弃整个 checkpoint(不重传——可能下次的更早出来)
• 未做 P2P: 论文明确说出 P2P 的问题(IP 暴露 → DoS 攻击面增大),所以走 trusted relay

5.2 数字 sanity check

论文报告: 平均 14 min broadcast 完毕,total transferred 62 GB → 平均带宽 590 Mb/s。这是平均到所有 client 的 aggregate。每个 worker 单独看:如果有 N=20 个 worker,每个收 62 GB,total egress = 20 × 62 = 1240 GB / 14min = 11.8 Gb/s,分摊到 5 个 relay 每个 ~2.4 Gb/s——在数据中心带宽内。

6 · Async RL 与 two-step policy lag

Pretraining 的 DiLoCo 用的是"梯度延迟",RL 用的是"policy 延迟"。论文的图 6 把三种 RL 拓扑画在了一起:

6.1 为什么 RL 能容忍 lag 而 pretraining 不行

反向论证: 如果 pretraining 也 lag 2 步会怎样?——梯度直接陈旧,SGD 有用的方向被噪声淹没。RL 的"延迟"在不同位置:它延迟的是 sampling distribution,不是 gradient 本身。GRPO 的 loss 会自动用 importance ratio πθ / πθ_old 重新加权——这一项明确为 off-policy 而生。所以RL 比 pretraining 天然多一道防御 stale data 的机制。

6.2 Lag 的实际限制

论文虽然说 lag=4 还能稳定,但有暗示 lag > 4-5 时 importance ratio 会大量超出 clip 区间 → 大批样本被截掉,等效于学习信号丢失。Section 5 (Discussion) 里提到:"lag 4-5 步可以 hide weight broadcast / verification / KL log-prob 计算等所有 blocking stages"——隐含的最优工作点。

7 · Two-Sided GRPO Clipping & 训练稳定性

7.1 原始 GRPO 的不对称问题

原 GRPO 目标:

当 advantage  > 0(好 rollout):clip 把 r 上限压在 1+ε,防止过度激励。
当 Â < 0(差 rollout):因为外面的 min,clip 在 r 很大时不生效——理由是"鼓励大力远离差 rollout"。

但在 INTELLECT-2 的 32B + async 设定下,r 偶尔会冲到 100+,与负 Â 相乘就是巨大的 loss spike → gradient explosion → 模型崩。原因有二:

• 32B 模型本身梯度噪声大
• async lag → πθ_old 可能落后 2 步,r 的 baseline 已偏移

7.2 修补: 加上一个上界 δ

论文用 ε = 0.2, δ = 4。语义: 仍然鼓励远离差样本,但 r 不能超过 4——避免单个 token 把整个 batch 的 loss 拉飞。

7.3 其他稳定性 patches (实战日记)

7.4 数据 pipeline 的两道筛子

Offline filtering: 用 base model (R1-Distill-7B) 跑 pass@8。保留 1/8 ≤ pass@8 ≤ 4/8 的题。太简单的题所有 group 全对 → advantage = 0 没信号;太难全错 → 同样无信号。论文 Figure 8 显示:不过滤 → reward 几乎不动;过滤 → reward 显著上升。

Online filtering: 即便过滤过,生成时仍可能某 prompt 全对/全错。继续重新采样 prompt 直到攒够 4096 个非零 advantage 样本再训练一步。"副作用刚好是好事": 这等价于把更多算力推向 inference,正符合 decentralized swarm 的算力分布(infer 多 / train 少)。

8 · 实验关键结果

8.1 系统级数字

8.2 Benchmark

8.3 怎么读这张表

• 对 QwQ-32B 微涨 2-3 点(AIME24, LiveCodeBench)。不是大跨越,因为 QwQ 已被 RL 过
• IFEval 略掉(83.4 → 81.5)—— 训练只用数学/代码,没用 IF 数据,正常
• 论文坦白:"想看 huge improvement 需要更好 base 或更高质量数据"——比如换 Qwen3

8.4 Length reward 没收敛

实验目标之一是"用户 prompt 里指定 thinking budget,模型遵守"。结论: 没学会。Length penalty 下降很慢,远不及 1.5B/7B ablation 的速度。论文猜测原因: 32B 模型已有强 prior,length 信号弱,需要更长训练 / 更高 length-reward 权重。

9 · 与同类工作对比

简单说: INTELLECT-2 是这个矩阵里唯一既"async RL"又"trustless permissionless"的组合。NeMo-RL 比它更快(单 cluster),但不能搬到 swarm 上;Tülu 3 与它最像但仍然 centralized。

10 · 与 INTELLECT-1 的 differential

这一节专门给读过 INTELLECT-1 的人。

10.1 哪些抽象层被 carry over 了?

• 异质算力 + 动态 pool: 都靠 orchestrator + 心跳机制
• "假装阻塞通信不存在"的设计哲学: INTELLECT-1 用减少通信频率 (DiLoCo 内层 500 步无通信), INTELLECT-2 用 async overlap
• 开源 + 协议化: Prime Intellect Protocol 直接复用,只是 compute pool 类型改成 "RL"

10.2 哪些是真正"新"的?

• TOPLOC: 全新的 trustless verification 机制,INTELLECT-1 没必要做
• SHARDCAST: pretraining 时 weight 不需要全网广播(每个 worker 都自己有完整 model);RL 时需要
• Two-sided GRPO clip + δ: 32B + async 触发的 instability 才暴露这个问题
• Sampling check: 防"hybrid 攻击"的特殊检查,pretraining 时不存在

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

论文承认的局限

• QwQ-32B 已被 RL 过,头发都快秃了再涨 2-3 点是上限了。要看大跨越得换 base
• Length reward 没学会,32B 比小模型更顽固
• Orchestrator + discovery service 仍是中心化(单点故障);未来打算上 DHT
• Inference worker 必须是 bare-metal / VM(直连 Docker daemon),不能跑在 Kubernetes pod 里
• Code execution 当前仅限算法 challenge(自带 sandbox 即可);更复杂任务需要更强隔离

我的怀疑 + 待验证

1. TOPLOC 真实抗攻击率?论文没给 "我们捕获了 X% 的恶意 rollout" 这种数字。在 testnet 跑了两周,有真正的恶意攻击者吗?可能还没到那个对抗强度
2. 2-step async 在 32B 上够稳吗?ablation 用的是 1.5B/2K context。32B 模型的 importance ratio 分布会更胖尾,clip frequency 可能更高,论文没汇报 32B 的 clip ratio 时间序列
3. 14 min broadcast 是 bottleneck 还是 capacity?如果换 100B+ 模型(310+ GB),broadcast 会增到 70 min。要么 lag 加到 5-7,要么换更激进的压缩(int8 weight → ~80 GB)。论文没讨论 scaling
4. Cherry-pick 防御靠的 deterministic seed,但 worker 可以"挑节点 ID"。如果 worker 故意申请多个 node address,一直挑出 hash 落在简单题上的那些?论文没说 address 是否绑定 stake / KYC
5. SHARDCAST relay 是中心化的。如果 5 个 relay 全宕,整个训练停摆。论文承认了 P2P 是 future work
6. "vLLM log_prob 不稳定" 这个发现—— 是版本问题还是结构性?如果是结构性,所有用 vLLM 做 RL rollout 的工作都要重算 log_prob,这是个不大不小的 implicit overhead
7. QwQ 比 R1-Distill 难训这个观察 → 是不是说明"二次 RL"会越来越难,reasoning 模型可能存在"RL 资本耗尽"现象?这对未来 reasoning model 持续学习是个隐忧

个人 take

这是一篇系统工程论文,不是模型论文。它的真正贡献不在 +2 AIME24,而在把 RL trustless decentralized 这个概念从 ppt 推到能跑出 32B 的工程现实。三个组件(PRIME-RL, TOPLOC, SHARDCAST)都是完整工程实现,有理由相信它们会成为下一波 decentralized 训练框架的基础设施——尤其当 reasoning 模型规模和 inference compute 进一步扩大的时候。

但同时要清醒: 它的"permissionless"目前仍在 testnet 状态。真正的对抗性测试(有金钱激励的攻击者)还没到。在那之前,TOPLOC 的"incentive-compatible 因为攻击者不知道哪条会被检"的论证只能算合理的,不能算验证过的。

记忆点

精读笔记 v1 · 2026-05-07 · 配套论文 PDF: /data/szhang967/papers/paper-notes/INTELLECT2_2505.07291.pdf · 姊妹篇: INTELLECT-1