RL Post-Training 框架横向对比 (2026 春)
速读卡片 (TL;DR)
一句话:2026 年的 RL post-training 已经从"PPO + RLHF 时代的脚本玩具"升级成"GRPO + reasoning + agentic 时代的 frontier-scale 系统",主流大五是 veRL / AReaL / slime / NeMo-RL / OpenRLHF,大致沿"hybrid engine"和"disaggregated async"两条路线分化。
立场:asynchybriddisaggregated Async 已经是确定方向;争议在 hybrid engine(actor / rollout 共置 GPU,如 veRL / OpenRLHF)还是 disaggregated(rollout / training 完全解耦,如 AReaL / slime)。Reasoning 工程优先选前者,agentic / 大规模 MoE 优先选后者。
1 · 为什么会有这么多框架
1.1 历史脉络: 从 RLHF 到 reasoning 再到 agentic
2022–2023 是 RLHF 时代: InstructGPT 范式下,主要工作是 PPO + reward model 对齐人类偏好。彼时框架的代表是 trlX、DeepSpeed-Chat、OpenRLHF。瓶颈在 训练侧(critic / reward 同时占显存),rollout token 短(~512),并不是核心问题。
2024 年 DeepSeekMath 提出 GRPO,o1 / R1 把 reasoning trace 拉到 4k–32k token,问题彻底翻转: generation 占了 RL step 的 65–72%(NeMo-RL × EAGLE3 论文实测)。这一阶段催生了:
- veRL / HybridFlow (字节 Seed, 2024-09 arXiv): 把 actor 和 rollout 放到同一组 GPU共享显存,sleep/wake 切换 — 显存利用率高。
- AReaL (清华 IIIS + 蚂蚁, 2025-05): 干脆把 rollout 和 training 拆成两个 cluster,通过 RPC / staleness-enhanced PPO 异步推进。
- slime (智谱 THUDM, 2025): GLM-4.5/4.6/4.7 背后的 RL 栈,Megatron + SGLang 桥接,sync / async 双模。
2025 下半年起 agentic RL 又推一把: 多轮、tool-call、长 episode、单步内可能调外部 search / code interpreter,使得 rollout 的延迟分布从"近似齐整"变成"极度长尾"。prime-rl、Laminar、OpenRLHF v0.8 的 agentic 模式都是这一拨的产物。
1.2 主要分歧轴
| 维度 | 选项 A | 选项 B | 取舍 |
|---|---|---|---|
| 同步性 | Sync (alternating) | One-step / fully / trajectory async | A 简单 reproducible;B 利用率高,需处理 policy lag |
| 引擎布局 | Hybrid engine (共置) | Disaggregated (RPC 解耦) | A 显存高效;B 可扩展、调度灵活 |
| 编排 | Ray | Megatron / NCCL native | A 弹性 + 多控制器;B 性能、紧耦合 |
| Rollout backend | vLLM | SGLang / 自研 | A 生态成熟;B radix cache / 多模态更友好 |
| 算法主轴 | GRPO + DAPO | PPO + 自研 (CISPO / IcePop / PRIME) | 大势已是 critic-free, GRPO 家族 |
2 · 框架画像 — 主流大五
2.1 veRL / HybridFlow
团队:ByteDance Seed → 现在由社区共同维护。
arXiv:2409.19256 (HybridFlow 论文)。
GitHub:
volcengine/verl。设计亮点:
- Hybrid single + multi-controller: 用 Ray 做 actor-style 多控制器分发,但每个 worker 内部走经典 SPMD;dataflow 层面像 single-controller(易写),计算层面像 multi-controller(高效)。
- Hybrid engine: 训练 actor 和 rollout actor 共享同一组 GPU 显存,通过 sleep / wake / weight resharding 切换,极大提高 GPU 利用率。
- 2025-12 公开成功跑 1T 参数 GRPO + LoRA on 64×H800,目前 frontier-scale 实战记录最深的开源框架。
局限:代码量大、入门曲线陡;hybrid engine 在 sequence parallel + ZeRO-3 + sleep mode 组合下偶发 NCCL 死锁;agentic 多轮支持比 AReaL 晚。
veRL 的核心论点是: 经典 RLHF 框架(DeepSpeed-Chat 风格)把 actor / critic / reward / rollout 分四组 GPU,内存浪费严重;但纯 SPMD 又不便编写复杂数据流。HybridFlow 提出"外层 single-controller 描述 dataflow,内层 multi-controller 跑 SPMD"的两层架构,以 Ray 做编排底座,并把 actor 与 rollout 放进共享 GPU 显存的 hybrid engine—— actor 训练时 rollout 进 sleep,显存交还给 actor;rollout 时反之。这套设计在 70B–235B MoE 上把 RL step time 减小 30–50%。社区生态层面,veRL 是大五里 contributor 数量、开源 PR 量最大的框架,基本所有新算法(DAPO、IcePop、TIS、CISPO)首发都先开 veRL 分支。它的代价是 抽象层多—— Worker / Resource Pool / Single-Controller / Megatron Backend 四层在小集群跑 demo 时显得过重,但在 256+ GPU 是非常划算的。
2.2 AReaL
团队:IIIS Tsinghua + inclusionAI (Ant)。
arXiv:2505.24298 (NeurIPS'25 spotlight)。
GitHub:
inclusionAI/AReaL。设计亮点:
- Fully async: rollout cluster 和 training cluster 完全解耦,通过 trajectory queue 推送数据,无 lockstep。
- Staleness-enhanced PPO: 修正旧 trajectory 的 importance ratio,让 policy lag 在大 staleness (≥4 步) 下依然稳定收敛。
- 实测 up to 2.77× 端到端 speedup vs sync,且 reward 收敛轨迹与 sync 几乎重合。
局限:需要双 cluster + 中间 trajectory queue,部署比 hybrid engine 复杂;早期 staleness 调参敏感,新版引入自动 staleness budget 缓解。
AReaL 是把"RL 训练 = 一个生产-消费系统"这件事认真当回事的框架。它的判断是: rollout 长尾必然存在(reasoning trace 长度方差大、agentic 工具调用更甚),lockstep sync 的 utilization 上限注定不高;与其反复优化 hybrid engine 的 sleep/wake 切换,不如从设计层就把两端解耦。AReaL 论文最有价值的贡献是 staleness-enhanced PPO 的稳定性证明 —— 它用一个轻量的 importance ratio 修正,把"用 4 步前的 policy 生成的 trajectory 也能稳定训练"这件事变成数学保证而不是 hack。2025 年下半年 AReaL 显著向 agent 方向倾斜,推出 "RL Bridge" 接口,把 agent framework(LangGraph、AutoGPT 风格)直接接到 RL backbone,这一步走在 veRL 前面。
2.3 slime
团队:THUDM / 智谱 AI。
arXiv:无独立论文,但作为 GLM-4.6 / GLM-4.7 报告的关键基础设施被引用。
GitHub:
THUDM/slime。设计亮点:
- Megatron + SGLang 直连: training 走 MegatronLM(tensor + pipeline + sequence + context parallel),rollout 走 SGLang(radix cache + structured output 友好)。
- 同时支持 sync + async 双模:小作业 sync 简单 reproducible,大规模 MoE async 收敛。
- 已成功用于 GLM-4.5 / 4.6 / 4.7 (300B+ MoE);并被 P1 / TritonForge / RLVE 等 RLVR 工作复用。
局限:非 Megatron 用户上手成本高;SGLang 后端在某些 tokenizer / chat template 边界上比 vLLM 兼容性弱;社区文档比 veRL 少。
slime 在大五里是"最像生产代码"的一个—— 它没有像 veRL 那样追求"在一切 dataflow 上抽象优雅",而是直接选择 Megatron-LM 训练 + SGLang rollout 这个工业组合。智谱内部的训练惯性是 Megatron,所以 slime 不试图重新发明 backbone 而是做"桥"。它的 sync 模式跑 GRPO 时几乎和单机脚本一样直观;async 模式则用一个轻量的 stale-buffer 配合 Megatron 的 distributed optimizer 实现重叠。slime 真正的看点是 SGLang 这条 rollout 路径在 agentic 场景下更顺手 —— SGLang 的 structured output、grammar、Python interpreter 连接器,在 RL trajectory 阶段比 vLLM 更原生。GLM 系列从 4.5 到 4.7 的能力跃迁,RL 段的工程能力 slime 是关键支柱。最近 P1 / TritonForge / RLVE 等论文都把 slime 作为 default RL framework,证明它已经超越"自家自用"成为公共基础设施。
2.4 NeMo-RL
团队:NVIDIA。
arXiv:无独立 framework 论文,但姊妹论文 NeMo-RL × EAGLE3 (2604.26779) 是 spec decoding 集成展示。
GitHub:
NVIDIA/NeMo-RL (前称 NeMo-Aligner)。设计亮点:
- 多轮 + 环境抽象做得最系统(
Env/Tool/Trajectory接口),用于 INTELLECT-3-style agentic 流。 - 原生集成 speculative decoding(EAGLE-3 head 可以直接挂 vLLM rollout 上),为 frontier-scale 上 ~2.5× e2e 加速提供路径。
- FP8 训练 / FP4 inference / TransformerEngine 这些 NVIDIA 内核加速能直接吃到。
局限:"NVIDIA-flavored" — NeMo 配置体系庞大;非 NVIDIA 卡支持有限;社区 PR 速度比 veRL 慢。
NeMo-RL 的产品哲学和别家不同:它不追求"开箱即用最快上手",而是把"把 RL 当成一个深度集成进 NVIDIA 软件栈的子模块"做得很完整。它把 environment / tool / trajectory 抽象做成一等公民—— 这点其它框架(尤其 OpenRLHF 早期)都很弱。NVIDIA 把 NeMo-RL 当成"展示什么是 frontier-scale RL"的官方 reference: 既能跑 405B,也能集成 EAGLE-3 spec decoding,还能跟 NVIDIA Earth-2 / BioNeMo 这些 domain 应用打通。最近 INTELLECT-3 报告里讨论的 agentic flow 中,NeMo-RL 提供了多轮 trajectory 接口的设计参考(虽然他们最后用 prime-rl)。看 姊妹笔记 01: spec decoding × NeMo-RL 的集成是该框架的代表性样板。
2.5 OpenRLHF
团队:社区驱动 (主导贡献来自 OpenLLMAI 与多家研究机构)。
arXiv:2405.11143 (OpenRLHF 报告)。
GitHub:
OpenRLHF/OpenRLHF。设计亮点:
- Ray-native: 用 Ray Actor 把 actor / critic / reward / rollout 分开管理,容易理解、容易拓展。
- 训练后端 DeepSpeed (ZeRO-3),rollout 后端 vLLM,组合简单。
- v0.8.0 (2025) 加入了显式的 async 模式 + agentic RL 支持,补上了对 reasoning / agent 工作负载的短板。
局限:大模型 (≥200B) 的并行能力弱(无 Megatron 后端)、非 hybrid engine 模式 GPU 利用率不如 veRL;agentic / 多轮支持是后补的、API 不如 NeMo-RL 系统。
OpenRLHF 是大五里"最适合从 0 到 1 跑通一遍 GRPO"的框架。它的代码结构最薄、抽象最少:一份 actor、一份 critic、一份 reward、一份 vLLM rollout,Ray 负责把它们粘起来。对小团队、对学术 reproduction、对"想看清楚 RLHF 数据流到底是怎么走的",OpenRLHF 还是首选。它的弱点很明显—— DeepSpeed ZeRO-3 在 200B 级别难以高效;hybrid engine 没有原生支持;agentic / 多轮直到 v0.8 才有。所以 2025 下半年 OpenRLHF 的角色更像"教学 + 中等规模生产":你不会用它训 1T MoE,但你会用它训一个 14B 数学 RL 模型,因为部署最便宜。社区维护活跃,issue 响应快,文档清晰。
3 · 第二梯队 (Notable supporting)
3.1 prime-rl (Prime Intellect)
PrimeIntellect-ai/prime-rl。使用方:INTELLECT-2 / INTELLECT-3。
prime-rl 是 Prime Intellect 在 INTELLECT-2 (笔记 07) 时孵化的 RL 框架,INTELLECT-3 (笔记 08) 把它定位成"三件套之一": prime-rl + prime-environments + prime-protocol(后两者是环境定义和分布式协议)。它的特点是为 大规模 agentic RL 设计 —— rollout 可以跨数据中心、节点级 fault-tolerant、和 prime-environments 的 diverse env library 紧密耦合。INTELLECT-3 在 prime-rl 上跑了 thousands-of-environment 的 verifiable RL,并提出 "recursive language models"——RL 训练自己产生新的 RL training problems。这是 2026 上半年最有"研究方向感"的 RL 框架。
3.2 Laminar
Laminar 提出的论点是:agentic RL 的 trajectory 长尾分布在同一个 batch 内——有的 trajectory 一秒结束、有的几分钟。step-level async (AReaL 风格) 还是要等"这一批 trajectory 都好了再 train",依然有等待。Laminar 进一步把粒度下放到 trajectory: 每条 trajectory 完成就立刻进入 training queue,training side 维护一个 stale-aware PPO budget。实测在 multi-turn / tool-call workload 上比 step-level async 再快 1.5–2×。Laminar 目前没有自己独立产品化,但它的设计原则(把"完成事件"作为调度单位)在 AReaL / prime-rl 的最新版里已经渗透。
3.3 LlamaRL
Meta 的内部 RL 框架,PyTorch 原生(无 Ray、无 Megatron 抽象层),靠 PyTorch FSDP-2 + torch.distributed 直接走。最大卖点是简单:整个 framework 的核心代码非常薄。论文报告 8B/70B/405B 上比 DeepSpeed-Chat 加速 up to 10.7×。它和 PipelineRL 共享一个观察 —— 与其引入复杂的多控制器抽象,不如把 generation 和 training 在 step 内做精细 overlap。LlamaRL 没有 hybrid engine,而是 disaggregated 但通过 NCCL 直接共享 weights,延迟极低。Meta 内部 Llama 系列 post-training 几乎都跑在它上面,但开源版本社区参与度有限。
3.4 PipelineRL (ServiceNow)
PipelineRL 的招牌是 inflight weight update: 当 rollout 还在生成长 trajectory 的中段时,后台已经悄悄把新 weights 推送给了 rollout engine,rollout 在不重启 KV cache 的前提下"切档"到新策略,从下一 token 开始就用新参数。这跟 chunked sync(把长 trajectory 切段、段间同步)是两回事 —— inflight 不切 trajectory,只切 weights。这种粒度比 trajectory-level async 更细,但工程实现要求严格(KV cache + weights 一致性窗口)。ServiceNow 在 7B / 32B 数学 RL 上展示了 1.3–1.6× 收益,但 frontier-scale 还没看到公开复现。
3.5 HybridFlow paper = veRL 的学术起点
HybridFlow 是 veRL 在学术界的"出生证明"。论文里把 hybrid single+multi-controller、hybrid engine、3D parallelism resharding 这三件事讲清楚了;真要深入理解 veRL 的设计思想,这篇论文是必读。社区里有时把 HybridFlow 和 veRL 当两个名字混用,严格说前者是论文 + 原型,后者是社区开源版本(及其后续演进)。
4 · 横向对比表 — 主流大五
| 维度 | veRL | AReaL | slime | NeMo-RL | OpenRLHF |
|---|---|---|---|---|---|
| 异步性 | sync + one-step async | fully async | sync + async (双模) | sync + one-step async | sync (v0.8 起 async) |
| 引擎共置 | hybrid engine | disaggregated | disaggregated | hybrid + disaggregated 双模 | hybrid (Ray colocate) 可选 |
| 分布式编排 | Ray + SPMD worker | RPC + custom scheduler | Megatron native + lightweight RPC | Megatron-Core / NeMo | Ray + DeepSpeed |
| Rollout backend | vLLM / SGLang | SGLang (主) / vLLM | SGLang | vLLM (+ EAGLE-3) | vLLM |
| 训练 backend | FSDP / Megatron / DeepSpeed | Megatron / FSDP | Megatron-LM | Megatron-Core + TE | DeepSpeed ZeRO-3 |
| 算法 | PPO / GRPO / DAPO / DPO / RLOO / IcePop / TIS | PPO / GRPO / DAPO + staleness-PPO | PPO / GRPO / DAPO / GLM-自研 | PPO / GRPO / DPO / 多轮 RL | PPO / GRPO / DPO / KTO / IPO |
| 多轮 / 工具 | 支持 (社区 verl-multi-turn) | 原生 (RL Bridge for Agent) | 支持 (SGLang grammar) | 原生 (Env / Tool / Trajectory 接口) | v0.8 起 |
| VLM 支持 | 是 (Qwen-VL, LLaVA) | 是 | GLM-V 系列已验证 | 是 | 部分 |
| 主要使用方 | ByteDance Seed, vivo, 阿里, MiniMax M1 部分 | 蚂蚁, 清华, agentic 研究社区 | 智谱 GLM-4.x, P1, TritonForge, RLVE | NVIDIA 内部 + INTELLECT-3 参考 | 大量学术团队 + 中小工业团队 |
| License | Apache-2.0 | Apache-2.0 | Apache-2.0 | Apache-2.0 | Apache-2.0 |
| 活跃度 | ★★★★★ (社区最大) | ★★★★ (论文驱动) | ★★★★ (智谱 + 外部) | ★★★ (NVIDIA 主导) | ★★★★ (老牌) |
| frontier 实证 | 1T GRPO+LoRA / 64×H800 | ~200B reasoning / agent | GLM-4.7 (300B+ MoE) | 235B (sim 2.5× e2e) | ≤ 70B |
5 · 设计选择详解
5.1 Sync vs Async (四种节奏)
讨论要点:从 reproducibility 角度,sync > one-step > fully > trajectory;从 utilization 角度,顺序倒过来。大多数生产团队的甜点是 one-step async + hybrid engine(veRL 默认)或 fully async + disaggregated(AReaL)。LlamaRL 实测在 fully async 下与 sync 的 reward 差异 < 1%,说明 staleness-aware PPO 已经把"async 失控"的担忧基本消除。
5.2 Hybrid Engine vs Disaggregated
这两条路线的对赌点是: "GPU 显存有多金贵 vs 集群规模有多大"。在中等规模 (≤256 GPU) hybrid engine 几乎一定占优——你买不起两套独立的 100+ H800。当规模大到一定程度(>1024 GPU,frontier MoE),disaggregated 反而更有道理:rollout side 可以用更便宜的卡(L40S / A100)、training side 集中用 H100/B200,而且两侧的并行策略可以独立优化(rollout 用 TP=2 + DP 大;training 用 TP=8 + PP=8 + EP)。slime / AReaL 的实测在 GLM-4.6 / 200B 级别已经验证了 disaggregated 的扩展性。
5.3 Sharding 策略
四个角色的并行可以独立选择:
| 角色 | 典型并行 | 注意 |
|---|---|---|
| Actor (training) | TP × PP × SP × ZeRO / FSDP | 大模型常 TP=8, PP=4–8, EP for MoE |
| Rollout (vLLM/SGLang) | TP only (DP 自动 batch) | 常用 TP=1/2/4,内存盯 KV cache |
| Critic / Reward (PPO 时) | 同 actor 或更小 | GRPO 已无 critic,这一项消失 |
Hybrid engine 框架(veRL)需要做权重 reshard—— actor 训练时是 TP=8 + PP=4 的布局,切到 rollout 时变成 TP=2 + DP=16,中间要一次 all-to-all 重排。这是 veRL 工程实现里最 tricky 的一段。Disaggregated 框架(slime/AReaL)只需要把 actor 的最新 weights 序列化成 rollout 友好的布局推过去,实现简单,但每步多一次 weight 网络传输。NeMo-RL 的"fast weight transfer"利用 NVLink + NCCL 把这部分压到 1–2s。
5.4 Inflight weight updates (PipelineRL 的 signature)
常规 async 的最小调度单位是 step(或 trajectory): 一个 trajectory 生成完才同步 weights。Inflight weight update 进一步把粒度切细到 token: rollout engine 跑到 trajectory 中段,后台已经把新 weights swap 进 GPU,接下来这条 trajectory 后半段是用新 weights 生成的。这跟 chunked sync(把 32k trajectory 切 4 段、段间同步)的区别是 inflight 不重启 KV cache—— 同一条 trajectory 物理上连续生成,只是参数换了。理论上这会引入"同一 trajectory 内分布混合"的问题,但 PipelineRL 实测在 7B / 32B 数学 RL 上 reward 与 sync 持平,且 e2e 加速 1.3–1.6×。这是 2026 上半年最具潜力的"未广泛采用但论证完整"的设计;猜测会被 veRL / slime 后续吸收。
6 · 选型决策树 / 推荐场景
常见场景速查
- Reasoning post-training (GRPO + 数学/代码 RL): 选
veRL或slime— 二者生态最成熟、算法跟进最快 - Agentic RL (多轮 + 工具 + 长 episode): 选
AReaL(论文级支持)或prime-rl(跨节点 env 库) - 大规模 (>200B) frontier 训练:
veRL(1T 验证)或NeMo-RL(NVIDIA 内部 / 235B 仿真) - 刚开始做 RLHF, 团队小:
OpenRLHF上手最快,Ray 原生,代码量薄 - 需要 speculative decoding 集成:
NeMo-RL直接支持(参考 姊妹笔记) - 需要 MoE 训练:
veRL(1T LoRA 已跑)或slime(GLM-4.6 已跑 300B+ MoE) - 偏好生态 + 已有 Megatron 栈:
slime - 低延迟 PyTorch 原生:
LlamaRL(开源版社区小但代码薄)
7 · 趋势 + 我的判断
7.1 Async 是确定方向
从 AReaL (2.77×)、LlamaRL (10.7× vs DeepSpeed-Chat)、Laminar (再 1.5–2×)、PipelineRL (inflight 1.3–1.6×) 这条证据链看,async 在 reward 收敛轨迹基本不动的前提下,e2e 提速可观。同步 RL 的死穴是 generation 长尾把 GPU 压在 idle,这件事在 reasoning trace ≥ 8k 之后无法回避。2026 内 sync 仍是 sync default 的(教学 / reproducibility),但生产 default 一定是 async。
7.2 Hybrid engine vs disaggregated 还在拉锯
我的判断:大模型场景 disaggregated 更可扩展(slime / AReaL 在 GLM-4.6 / 200B 已验证),中等规模 hybrid engine 更省资源(veRL 在 70B / 235B 仍是性价比最高)。两条路线短期不会合并,但 NeMo-RL 这种"双模"框架会越来越多 —— 让用户根据集群规模切换。
7.3 Multi-turn + tool 是 2026 上半年最大变量
所有大五现在都在补多轮支持,但接口标准还没收敛: AReaL 的 RL Bridge、NeMo-RL 的 Env/Tool/Trajectory、OpenRLHF v0.8 的 agent runner、slime + SGLang grammar—— 各家做法都不同。下半年大概会出现某种"事实标准"(可能借鉴 OpenAI Gym / DSPy 的接口风格)。谁的多轮抽象先被多个团队采纳,谁就赢这一轮。
7.4 算法侧 GRPO 是 default,变体百花齐放
GRPO 已经是事实 default (无 critic、batch 内 group baseline),DAPO 是字节家在 GRPO 基础上加 token-level loss + clip-higher,逐渐普及。值得关注的算法变体: CISPO(MiniMax M1, 见 笔记 03)、IcePop(字节)、PRIME(implicit reward)、TIS(truncated importance sampling)。框架谁先适配谁先抢用户。
7.5 Frontier 实证是残酷过滤器
在 frontier-scale (200B+) 跑通过 RL 训练的框架本质是少数: veRL (1T LoRA)、slime (GLM-4.7 300B+ MoE)、NeMo-RL (NVIDIA 内部)、AReaL (~200B agent)。其余框架声称的支持很多停留在 70B 级别。"能跑 ≥200B"会成为 2026 评估 RL 框架的硬指标。
8 · 记忆要点 (Memory points)
两条路线 hybrid engine (veRL/OpenRLHF) vs disaggregated (slime/AReaL)
异步 sync → one-step → fully → trajectory-level (Laminar);staleness-PPO 是把 async 收敛性"证好"的关键
瓶颈 reasoning 时代 generation 占 65–72%,所有框架都在抢这块
backend 训练 = Megatron / FSDP / DeepSpeed;rollout = vLLM / SGLang(SGLang 在 agentic 上略胜)
算法 GRPO default;DAPO / CISPO / IcePop / PRIME / TIS 是变体;PPO 已退潮(critic 太贵)
frontier ≥200B 实证: veRL (1T LoRA) / slime (GLM-4.7) / NeMo-RL (235B sim)
agentic AReaL "RL Bridge" 概念领先;NeMo-RL Env/Tool 抽象最系统;prime-rl 把 env 做成生态
前沿 Inflight weight update (PipelineRL) / trajectory async (Laminar) 是 2026 上半年值得跟的论文
坑 hybrid engine 的 weight reshard 死锁;disaggregated 的 weight broadcast 延迟;async 的 staleness 调参
立场 不存在"最好"的框架,只有"和你团队栈匹配"的框架;先看你已经在用 Megatron / DeepSpeed / Ray 哪一个
Comparison Note v1 · 2026-05-09 · 关联笔记: INTELLECT-2 (prime-rl) · INTELLECT-3 (三件套) · NeMo-RL × EAGLE-3