RollArt: Disaggregated Multi Task Agentic RL Training at Scale

Source

Workflow version: v2
Material type: research-paper
Canonical source: https://arxiv.org/abs/2512.22560
Title: RollArt: Disaggregated Multi-Task Agentic RL Training at Scale
Authors: Wei Gao, Yuheng Zhao, Tianyuan Wu, Shaopan Xiong, Weixun Wang, Dakai An, Lunxi Cao, Dilxat Muhtar, Zichen Liu, Haizhou Zhao, Ju Huang, Siran Yang, Yongbin Li, Wenbo Su, Jiamang Wang, Lin Qu, Bo Zheng, Wei Wang
PDF: https://arxiv.org/pdf/2512.22560v2
TeX Source: https://arxiv.org/e-print/2512.22560v2
Official proceedings page: https://www.usenix.org/conference/osdi26/presentation/gao
Official proceedings PDF: https://www.usenix.org/system/files/osdi26-gao.pdf
Code/Project: https://github.com/alibaba/ROLL
Code snapshot inspected: ba7092fb289d3e8902f55c9952e7a48adf962f14, committed 2026-07-06
Venue: 20th USENIX Symposium on Operating Systems Design and Implementation, OSDI 2026
Published / updated: arXiv v1 提交于 2025-12-27；v2 更新于 2026-06-15；OSDI 2026 会议时间为 2026-07-13 至 2026-07-15
Current version read: arXiv v2 TeX source、arXiv v2 PDF、USENIX proceedings PDF 与上述 ROLL commit
Version / revision read: 2512.22560v2；USENIX camera-ready；ROLL ba7092f
Accessed: 2026-07-13
Subjects: distributed agentic RL, heterogeneous resource scheduling, trajectory-level rollout, asynchronous training, serverless reward

arXiv v2 与 USENIX PDF 都采用 camera-ready 题名和正文结构。公开 ROLL 仓库用于核对当前框架中可见的 env-group queue、过期清理和 train-infer correction 接口；仓库没有标注该 commit 为论文 artifact，因此代码只能作为补充实现证据。

作者与关系

Wei Gao: HKUST；Alibaba Group。
Yuheng Zhao: HKUST。
Tianyuan Wu: HKUST。
Shaopan Xiong: Alibaba Group。
Weixun Wang: Alibaba Group。
Dakai An: HKUST。
Lunxi Cao: HKUST。
Dilxat Muhtar: Alibaba Group。
Zichen Liu: Alibaba Group。
Haizhou Zhao: Alibaba Group。
Ju Huang: Alibaba Group。
Siran Yang: Alibaba Group。
Yongbin Li: Tongyi Lab, Alibaba。
Wenbo Su: Alibaba Group。
Jiamang Wang: Alibaba Group。
Lin Qu: Alibaba Group。
Bo Zheng: Alibaba Group。
Wei Wang: HKUST。

Wei Gao、Yuheng Zhao、Tianyuan Wu、Shaopan Xiong 与 Weixun Wang 为共同一作。作者链连接 Wei Wang 在 HKUST 的系统团队与 Alibaba 的 ROLL、训练基础设施和 Qoder 团队；Wei Gao、Yuheng Zhao、Dakai An、Tianyuan Wu、Lunxi Cao、Shaopan Xiong、Ju Huang、Weixun Wang、Siran Yang、Wenbo Su、Jiamang Wang、Lin Qu、Bo Zheng 与 Wei Wang 也共同参与 RollPacker。ROLL、ROLL Flash、RollPacker 与 RollArt 形成了框架、异步训练、长尾调度和异构资源编排的连续系统线。

阅读目标与判断边界

本笔记聚焦五个问题：

RollArt 所称 disaggregation 分别发生在 stage、task domain、generation phase 和 trajectory 哪些粒度。
suspend -> update -> resume -> recomp 如何保留逻辑轨迹，以及一条轨迹是否会跨 weight versions。
$\alpha$ 实际约束哪个版本差，能否直接代表逐 token off-policy 程度。
Mooncake 数据路径隐藏了哪些传权时间，哪些时间仍在 inference critical path 上暴露。
end-to-end、ablation 和 3000+ GPU 案例各自支持到什么结论范围。

判断边界：

核心实验依赖 H800/H20、CPU/Kubernetes、内部 serverless 和 Mooncake 组成的 disaggregated infrastructure。
end-to-end step time 只平均 5 个 iterations；多数结果没有 seed、置信区间或显著性检验。
Sync、Sync+、One-off 与 AReaL 由作者在同一系统内实现或复现；Laminar 只做 feature decomposition。
论文说明使用 GRPO、batch size 512 和 group size 8，没有展开 loss、behavior logprob、importance correction、KL、optimizer 或 mixed-version token 的处理。
公开 ROLL commit 含 group-aware async queue 与可选 train-infer correction，但缺少论文中的 Mooncake、hw_mapping、serverless decorator 和 paper-specific reproduction entry；当前代码不能反推 OSDI 实验配置。

证据口径：

论文事实：camera-ready 正文、图表、表格和生产案例直接披露的机制与数字。
作者主张：作者对资源亲和、staleness、可扩展性和生产稳定性的解释。
本地分析：版本时间线、RL 数据契约、选择偏置、critical path 和公开代码映射的审计。

论文脉络

1. 研究问题、背景和价值

Agentic RL 的一条样本包含多轮 LLM -> action -> environment -> observation。随着历史增长，每一轮都可能重新处理长 prompt；工具和 sandbox 又引入 CPU、磁盘、网络与容器启动延迟。轨迹完成后，rule、code 或固定 reward LLM 才开始评分，trainer 还要把新权重送回 rollout 集群。

这些阶段的资源特征并不统一：

工作负载	主要资源特征	典型等待
training	compute、collective communication	rollout 数据或传权 barrier
多轮 generation	growing-context prefill，compute-heavy	环境返回、同批慢轨迹
少轮长 response	decode，HBM-bandwidth-heavy	token generation
environment	CPU、容器、磁盘与网络 I/O	`reset` / `step` 重尾
reward	bursty；固定模型或无状态函数	一批轨迹集中完成后的峰值
weight update	数十 GB 跨集群传输	低带宽 Ethernet 上的同步等待

RollArt 研究的问题是：如何让每类 workload 使用合适资源，同时保持 trajectory、reward、training batch 和 model version 之间的数据依赖。系统需要同时处理资源错配与跨阶段同步；只增加 rollout GPU 会保留环境长尾和传权等待。

2. 已有路径留下的缺口

路径	已解决的部分	RollArt 关注的剩余约束
monolithic RL framework	单控制器、trainer/rollout 编排	stage 通常共享同类 GPU，CPU env 与 elastic reward 仍是外部系统
train/rollout disaggregation	两阶段可独立扩缩	generation 内部仍按统一 GPU class 处理
one-off asynchronous RL	training 与上一批 rollout 重叠	一轮仍等待整批 stale trajectories 完成
trajectory-level async	完成样本可提前流动	task-domain hardware affinity、serverless reward 和跨集群 weight store 仍需组合
PD-disaggregated serving	prefill/decode 使用不同 worker	RL 还要管理 environment、reward、group 和 version lifecycle

论文的贡献来自这组组合约束。单独的异步、serverless 或 PD serving 都已有先例；RollArt 将它们放进一个 agentic RL runtime，并给出 task-domain affinity 与生产规模证据。

3. 作者可能的思考路径

本地重建如下：先把 training step 分解后，作者发现成功 SWE-bench iteration 中 generation 只占约 54%，environment failure 可以把 env.reset 推到 rollout time 的 78%。随后把 generation 再分解为 prefill-heavy 和 decode-heavy，H800/H20 的性能次序随任务类型反转。reward LLM 的专用 GPU 利用率又只有 7.4%，跨集群权重传输则随模型增大到数十秒。

这组观测导出四个要求：任务域需要硬件亲和映射；环境交互需要降到 trajectory 粒度；固定 reward 需要共享弹性容量；training/rollout 需要允许有限版本差。Resource、data、control 三个 plane 随后分别承载资源声明、worker 实现和异步状态机。

4. 核心假设或切入点

RollArt 依赖六个条件：

同一 task domain 的 turn、prefill 和 decode profile 在训练期间足够稳定，静态 affinity 声明可持续使用。
environment timeline 可以按 trajectory 解耦，独立 callback 的调度开销低于 batch barrier 的长尾成本。
reward 参数固定或逻辑无状态，remote invocation 与 autoscaling 不改变 reward 语义。
$\alpha$ 限制的样本年龄足以控制异步训练质量，本文 workload 中 $\alpha=1$ 可兼顾 step time 与 time-to-score。
Mooncake store、跨集群 Ethernet 与 inference 内部高速网络允许 push/pull 大部分重叠。
较早完成的冗余环境样本仍能代表目标训练分布，或其选择偏差对结果可接受。

前五项获得 profiling 或局部 ablation 支持。第六项在正文中没有单独测量。

5. 方法 / 系统 / 理论框架

5.1 先区分四种“拆分”

拆分对象	决策粒度	RollArt 的实现边界
pipeline stage	trainer / rollout / env / reward	映射到 GPU、CPU/Kubernetes 与 serverless pools
rollout task	task domain	用户用 `hw_mapping` 静态声明，runtime 按 tag 路由并在目标不可用时 fallback
generation phase	prefill / decode	可选 PD disaggregation；P/D 数量由人工配置
rollout progress	trajectory	`LLMProxy`、`EnvManager`、reward callback 独立推进

这里的“动态路由”表示请求到达时按既有声明选择 worker。在线 profiler、自适应 affinity 和自动 P/D ratio 位于 Discussion 的扩展方向，未进入当前系统。

证据定位：§4 System Architecture、§5 Programming Interface、§9 Automating Hardware-Affinity Mapping。

5.2 三个 plane 把声明与调度分开

Resource plane 维护 H800、H20、CPU 和 serverless 资源池，并根据 tag 建立 worker binding。
Data plane 用 Worker / Cluster 封装训练、生成、环境和 reward 实现；register、hw_mapping 与 register_serverless decorator 描述执行方式。
Control plane 用 rollout scheduler、LLMProxy、EnvManager 和 SampleBuffer 管理 trajectory、reward、batch 与版本推进。

这套接口保留 single-controller 编程模型。硬件选择在 pipeline setup 时声明，control plane 在运行期驱动已有映射。

证据定位：§4、§5，Figure 7 与 Listings 1-2。

5.3 轨迹级状态机消除环境 barrier

EnvManager_i
  reset
    -> LLMProxy.ADD(history_i)
    -> generation callback(action_i)
    -> env.step(action_i)
    -> append(observation_i, action_i)
    -> next turn / terminal
    -> async reward
    -> SampleBuffer

每个 EnvManager 持有一条轨迹的历史和 environment lifecycle。inference worker 的 event loop 在 engine step 之间处理 ADD / ABORT，generation 完成后立即 callback。慢环境只延迟自己的下一次请求；reward 在单条轨迹完成后启动。

GRPO group 仍是训练数据契约。group size 8 表示同一 prompt/seed 的 8 条 rollouts 需要成组进入 advantage computation。公开 ROLL commit 中，GroupQueue 保存 group_id、episode_id、create_step 和 rollouts，收齐 group_size 后才向 batch consumer 交付；这说明“trajectory-level execution”与“group-level training consumption”可以同时存在。

证据定位：§6.1、Figure 8；公开代码 rollout_scheduler.py L209-L360。

5.4 $\alpha$ 约束的是 trajectory 起始版本年龄

camera-ready 给出的每轮协议是：

get_batch
  -> suspend new generation requests
  -> load latest weights into inference workers
  -> resume logical trajectories
  -> rebuild KV under new weights
  -> rollout || train_step(sampled batch)

设逻辑轨迹 $\tau$ 在版本 $v_0(\tau)$ 启动，检查时当前 rollout model 为 $n$ 。有效窗口是：

n-v_0(\tau) \le \alpha.

SampleBuffer 在 get_batch 前驱逐超出窗口的 trajectory；并发环境数为 $E$ 时，作者据此把 pending buffer 写成 $O(\alpha E)$ 。公开 ROLL commit 使用 current_step - group.create_step > async_generation_ratio 清理或忽略 group，提供了相同口径的代码对应。

$\alpha$ 衡量从轨迹起点到当前 iteration 的版本年龄。它没有直接给出每个 token 的 behavior version，也没有覆盖 trainer 已开始 update 后形成的版本变化。将 $\alpha$ 称为“逐 token policy lag 上限”会扩大论文结论。

证据定位：§6.2、Figure 9；公开代码 rollout_scheduler.py L274-L292 与 L483-L535。

5.5 逻辑轨迹会跨版本，KV 重算只恢复计算状态

suspend 停止新的 generation request；逻辑轨迹及其 observation/action history 继续保留。换权后，系统在新权重下重建 KV，并从已有历史生成后续 action。若一条轨迹先产生版本 $v$ 的 token，换权后继续产生版本 $v+1$ 的 token，它就是 mixed-version trajectory。

KV recomputation 保证 cached keys/values 与当前权重一致，已经采样的 action token 仍来自旧 policy。GRPO loss 要精确处理这类数据，至少需要知道 response mask、rollout logprob 或分段 behavior version。camera-ready 没有说明这些字段、old-logprob 重算、importance ratio 或 mixed-version mask。

当前 ROLL commit 可选地重算 trainer-side old_log_probs，并可依据 old_log_probs - infer_logprobs 生成 IS weight 或 filter mask；IS 和 filters 默认关闭。该接口说明公开框架已经具备 train-infer mismatch 监测/校正路径，也无法证明 RollArt 实验启用了它，更无法恢复论文未记录的每段 behavior policy。

证据定位：§6.2 Weight Synchronization Protocol；公开代码 base_config.py L421-L479、train_infer_corrections.py L65-L173。

5.6 Mooncake 把传权从同步 push 改成发布与按需 pull

trainer GPU
  -> bucketize weights, e.g. 1 GB
  -> cross-cluster push over Ethernet
  -> CPU-resident Mooncake store
  -> inference workers pull latest buckets
  -> local load / model switch

trainer 将每份 bucket 写一次，inference worker 再从 store 拉取。push、pull 和 rollout 可以重叠；Exposed Weight Pull 记录 rollout 无法覆盖的残余 pull 时间。由此，Mooncake 优化的是 critical-path exposure，传输字节数仍然存在，store 还增加一次中转。

论文表 4 的 8B/14B/32B Weight Push 为 32.4/67.8/127.3s，Accumulated Pull 为 6.2/16.3/29.7s，最终暴露的 pull 为 1.4/5.1/9.6s。作者将 67% 到 78% 的 pull 隐藏在其他工作后面；push 是否完全不阻塞下一次 trainer update，正文没有给出单独时间线。

证据定位：§6.3 Data Movement、§7.4 Asynchronous Weight Transfer，Table 4。

5.7 冗余 rollout 以完成顺序换取尾部容忍

系统可以启动超过目标数量的环境，收齐目标 trajectories 后终止剩余任务。它降低了 straggler 等待，代价是训练样本更偏向较快完成的 environment/trajectory。若运行时与任务难度、response length、reward 或失败概率相关，这种 first-finished selection 会改变采样分布。

论文报告最高 1.62 倍 rollout speedup，没有给出被终止样本的 task/reward/length 分布，也没有使用 inverse-propensity correction。工程部署需要同时记录 completion probability 与训练分布漂移。

证据定位：§6.3 Redundant Environment Rollouts、§7.4 与 Figure 14(b)。

5.8 公开仓库提供部分机制映射

截至 ba7092f：

GroupQueue 保留 GRPO group，并按 create_step 清理过期 group。
RolloutScheduler.suspend() 会 suspend、abort 当前 generation requests 并等待清空；逻辑 env loop 与 group state 位于 scheduler/env actor 中。
async_generation_ratio 控制 ahead generation 和 group age，语义接近论文 $\alpha$ 。
trainer 可重算 old logprobs，并配置 train-infer IS/filter。
仓库全文未出现 Mooncake、论文中的 hw_mapping / register_serverless 名称或 OSDI 复现配置。

因此，公开代码能支持 queue/version 数据结构的存在；paper-specific end-to-end artifact 仍待发布或明确标记。

证据定位：ROLL ba7092f，roll/distributed/scheduler/rollout_scheduler.py、roll/pipeline/agentic/agentic_pipeline.py、roll/utils/train_infer_corrections.py。

关键实验/定理

结果 1：四类 workload 都能成为 step bottleneck

设置：Qwen3-8B/32K、32 张 H800、SWE-bench、batch size 128；比较 5 个成功 iterations 与 5 个包含 environment failure 的 iterations。
结果：成功路径平均 365.7s，generation 约 54%、training 约 23%、environment initialization 约 15%；失败路径平均 513.3s，env.reset 占 rollout time 的 78%。6 H20 与 2 H800 的同成本比较中，FrozenLake 在 H800 上最低为 H20 时间的 0.53 倍，GEM-Math 在 H20 上为 H800 的 0.49 到 0.79 倍。专用 7B reward LLM 的 4 张 H800 平均利用率为 7.4%。
对照是否可比：step breakdown 的成功/失败组来自不同运行状态，只支持瓶颈归因；H20/H800 对照固定模型和任务，并依赖作者引用的 normalized cost 近似。
证据定位：§3 Characterization and Requirements，Figures 3-6，Table 3。
支持的最窄结论：本文 task mix 的 generation、environment、reward 与 weight movement 具有不同硬件和等待特征，统一 rollout GPU class 会产生可测资源错配。

结果 2：端到端收益来自异步与硬件映射的组合

设置：Qwen3 8B/14B/32B、32K context、GRPO、batch size 512、group size 8；RollArt 使用 96 H800 + 32 H20，baseline 使用 128 H800；训练侧 Megatron 0.12.2，rollout vLLM 0.8.4；跨集群 200 Gbps Ethernet，集群内 400 Gbps InfiniBand。
Baseline：Sync、带 async env/reward 与 serverless 的 Sync+、One-off、AReaL；Laminar 未直接运行。
结果： $\alpha=1$ 相对 Sync+、One-off、AReaL 的 step-time reduction 分别为 2.05、1.35、1.31 倍；相对 Sync 的 throughput 为 2.65 到 4.58 倍。Qwen3-32B 每 10 iterations 验证，目标平均 validation score 为 0.85。
对照是否可比：四个 baseline 在同一代码库实现并共享 Sync+ 优化；RollArt 与 baseline 使用不同 GPU types，成本只按 1:2.85 的 normalized ratio 对齐。
证据定位：§7.1-7.2，Figure 10(a-b)。
支持的最窄结论：在作者给定的异构资源和同代码库 baseline 条件下，RollArt 更快达到指定平均 validation score；实验没有形成跨 seed 的最终能力结论。

结果 3：R1-R4 分别对应不同收益和边界

R1：64 H800 + 24 H20 的 affinity mix 相对 208 H20 快 1.30 到 1.68 倍，相对 72 H800 快 1.12 到 1.37 倍；三种配置按作者的 normalized cost 近似等价。
R2：注入均值 10s、标准差 1 到 10s 的 Gaussian env latency 后，trajectory-level interaction 相对 batch interaction 快 1.23 到 2.27 倍。
R3：三并发数学 RL jobs 中，serverless 方案把本地 4 张 reward GPU 释放给 rollout，并将报告的平均 GPU utilization 从 6% 提到 88%、rollout time 从 158s 降到 77s；它同时改变了 rollout GPU 数量和 reward deployment。
R4： $\alpha=1..6$ 中，更大 bound 最多再改善 1.22 倍 step time； $\alpha=2$ 已出现后期 time-to-score 回退，作者默认 $\alpha=1$ 。
对照是否可比：R1 按估算成本对齐，R2 使用受控合成 latency，R4 只改变 bound；R3 同时改变本地 rollout GPU 数和 reward placement，属于整体部署对照。
证据定位：§7.3，Figures 11-13。
支持的最窄结论：四项设计都在各自实验中产生收益；R2 使用合成长尾，R3 是资源重分配加弹性共享的联合效果， $\alpha=1$ 的质量结论来自单条 time-to-score 曲线。

结果 4：Mooncake 主要降低传权的暴露时间

设置：Qwen3-8B/14B/32B 权重为 15.26/27.51/61.02GB；NCCL 2.26.5 与 Mooncake 0.3.7。
结果：RDMA 相对 TCP 传输快 1.264/2.482/3.140 倍；无 overlap 的 push + accumulated pull 为 38.6/84.1/157.0s，RollArt 的 exposed pull 为 1.4/5.1/9.6s；端到端 step time 改善 1.10 到 1.16 倍。
PD 结果：Qwen3-32B dense 的 1P3D/2P2D 相对对应 colocation 为 1.03/1.05 倍；Qwen3-30B-A3B MoE 为 1.11/1.21 倍，3P1D 因 decode bottleneck 表现最差。
对照是否可比：传权对照固定模型和跨集群拓扑，比较同步暴露与异步 overlap；PD 对照按同一模型、任务和 P/D 配置配对，最优 ratio 仍由人工选择。
证据定位：§3.4、§7.4-7.5，Tables 3-5 与 Figure 14(a)。
支持的最窄结论：异步中转能隐藏大部分 pull latency；PD 收益随模型和 P/D ratio 明显变化，dense 模型中的提升较小。

结果 5：生产案例证明规模存在，也暴露供给不足

设置：过去 9 个月的数千个 jobs；其中一个 Qoder hundreds-of-billions-parameter MoE job 使用 3000+ GPUs 运行一周，training:generation GPU ratio 为 1:5， $\alpha=1$ 。
结果：prompt/response 最长约 12k/46k tokens，task 平均 turns 为 1 到 48；每步最大 response length 超过均值 5 倍并峰值达 9 倍，最大 environment turns 超过均值 40 倍。最长 iteration 为 1.5h，阻塞 get_batch 最多造成 62% iteration time 的 GPU idleness；移除该等待的理想训练时间改善为 22%。资源比与 prefix cache 调整使前 25 steps 累计时间改善 1.66 倍。多级 Docker image cache 把 env.reset success rate 提到 99.99% 以上；一周观察到一次系统 failure。
对照是否可比：这是单个生产 job 的前后调优与 trace characterization，配置在资源比、prefix cache 和环境缓存上同时变化，缺少并行运行的对照 job。
证据定位：§8 RollArt in Production，Figure 15。
支持的最窄结论：系统已在 Alibaba 的超大规模 agentic RL job 上运行；该案例仍受 trajectory supply 和 environment initialization 影响，且未公开 raw trace、模型、数据或成本拆分。

实验设置与 baseline 审计

维度	审计结果
模型与任务	Qwen3 8B/14B/32B；SWE-bench、WebShop、FrozenLake、GEM-Math、GEM-Game；数学任务使用 Qwen2.5-7B reward LLM。
RL 数据契约	GRPO，batch 512，group 8，uniform task sampling；group identity 可从当前 ROLL code 映射，camera-ready 未披露 rollout logprob、mixed-version segment 或 importance correction。
训练超参	KL、entropy、learning rate、optimizer、clip、warmup、训练步数与 seed 披露不足。
系统配置	96 H800 + 32 H20、CPU clusters、internal serverless、Mooncake 0.3.7、NCCL 2.26.5、vLLM 0.8.4、Megatron 0.12.2。
指标	5-iteration average step time；token throughput；每 10 iterations 的 average validation score；target 0.85。
compute matching	baseline 使用 128 H800；RollArt 使用 96 H800 + 32 H20。作者按 H20:H800 normalized cost 1:2.85 估算 RollArt 每 GPU-hour 成本约为 baseline 的 83%；真实采购、功耗与机会成本未披露。
implementation matching	Sync/Sync+/One-off/AReaL 在 RollArt codebase 内实现；AReaL 与原仓库仍可能存在实现差异；Laminar 没有直接运行。
R3 可归因性	serverless 方案同时增加 rollout GPU、移除 dedicated reward GPU 并使用共享平台；6% 到 88% 不能拆成单一机制的净效应。
统计强度	多数图无 error bars、seed 或 confidence interval；production 是单个大规模案例。
artifact	ROLL 公开且持续演进；截至 `ba7092f` 缺少完整 RollArt reproduction mapping。

证据链强度评估

强证据

camera-ready 用 Figures 3-6 将 generation、environment、reward 与 weight transfer 分别量化，问题分解完整。
R1-R4 各有独立实验，Mooncake 还给出 push、accumulated pull 和 exposed pull 分解。
USENIX proceedings 页面、PDF、arXiv v2 和 ROLL 公开仓库共同确认论文身份与系统项目。
生产案例给出 turn/length tail、get_batch idle、environment failure 和 cache optimization 的具体统计。

中等强度证据

同代码库 baseline 降低实现环境差异，同时保留作者复现偏差。
$\alpha=1$ 的 time-to-score 方向与曲线一致，缺少多 seed 稳健性。
当前 ROLL code 支持 group age 与 correction 接口，commit 时间晚于论文实验，且未被标为 artifact。

需要谨慎的推论

1.31 到 2.05 倍属于特定资源拓扑和 baseline 的 step-time reduction，无法直接泛化为所有集群的训练加速。
Laminar 对比来自能力分解；隔离实验的 speedup 不能直接相乘形成严格下界。
3000+ GPU 案例证明运行规模，模型质量、资源效率和总成本仍缺少公开对照。
静态 task-domain affinity 在该生产 workload 中保持稳定，动态 agent workload 需要重新 profile。

OpenReview / 审稿意见吸收

Page type: proceedings
Match confidence: high
Observed at: 2026-07-13
Venue status: USENIX OSDI 2026 proceedings page和 camera-ready PDF 已公开；TeX acknowledgment 指明 shepherd Shadi Noghabi 与 anonymous reviewers。
Public reviews: USENIX 页面没有公开 HotCRP review、rating、confidence 或 author rebuttal。
Reviewer consensus: 无公开文本可恢复。
对可信度的影响: OSDI proceedings status 与 camera-ready 增强论文身份和审稿流程可信度；baseline fairness、统计波动、RL correction 和 artifact completeness 仍按公开证据单独审计。
证据定位：https://www.usenix.org/conference/osdi26/presentation/gao

本地讨论补充

1. “trajectory-level”需要同时保留 group 语义

执行层的一条 trajectory 可以独立前进，GRPO 的 advantage 仍要求同 prompt/seed 的 siblings 成组消费。公开 ROLL 的 GroupQueue 正好展示了这两个粒度：单环境异步提交，queue 收齐 group_size 后交付。阅读类似系统论文时，应分别问 producer、buffer、advantage group 和 trainer batch 的粒度。

2. $\alpha$ 的最窄解释

$\alpha$ 控制 current version - trajectory start version。换权后的 KV recomputation 会保留旧 action token，并在新 policy 下继续，因此 $\alpha=1$ 仍允许两个相邻 versions 出现在同一逻辑轨迹中。它提供 age admission control 和 buffer bound，逐 token off-policy bias 还要通过 behavior logprob、mask 或 IS 评估。

3. Mooncake 数字需要按 critical path 阅读

Accumulated Pull 是所有拉取累计花费，Exposed Pull 是 overlap 后仍阻塞的部分。1.4 到 9.6s 表示残余暴露时间，不能解释为全部 weight movement 成本。Table 4 中 32B push 仍为 127.3s，只是大部分通信与 rollout 同时发生。

4. serverless 实验包含资源重分配

local setup 用 8 张 GPU 中的 4 张 rollout、4 张 reward；serverless setup 把本地 8 张都交给 rollout，再调用外部弹性 reward pool。158s 到 77s 同时来自 rollout capacity 翻倍、reward sharing 和 remote overlap。论文支持整体部署方案有效，尚未隔离 serverless 调度器本身的净收益或总 GPU-second 成本。

5. 后续复验指标

每条 trajectory 记录 start_version、每个 action segment 的 behavior_version、buffer age 与 train version。
报告被冗余 rollout 终止样本的 task、length、reward 与 failure 分布。
分开测量 trainer publication stall、Mooncake push、per-worker pull、model load 和 KV reconstruction。
用 online profiler 与静态 domain tag 做同预算比较，记录 profile drift 和 routing regret。
发布 OSDI 配置、commit、容器、serverless cost 与 AReaL reproduction mapping。

主要启发

Agentic RL 的资源模型需要覆盖 prefill、decode、environment、reward、training 和 weight movement，stage 名称不足以描述硬件亲和。
调度粒度是数据契约的一部分：trajectory 可以独立执行，GRPO sibling 仍需成组，trainer 仍按 global batch update。
staleness 指标应明确起点、终点和粒度。start-version age、completion age、buffer age、train-time lag 与 token-level behavior mismatch 含义不同。
异步通信实验应同时报告 total work 和 exposed critical-path work，防止把 overlap 解释成传输消失。
straggler mitigation 会改变完成样本的选择机制；吞吐提升需要与采样分布漂移一起评估。

局限

静态 affinity 依赖任务域先验；online profiler 和自动 P/D ratio 尚未实现或评测。
camera-ready 没有公开 mixed-version trajectory 的 behavior logprob、loss mask、IS 或其他 correction 配置。
redundant environment rollout 可能引入 completion-time selection bias，论文只报告系统 speedup。
R3 将 serverless、共享 reward capacity 与更多本地 rollout GPU 组合，缺少统一 GPU-second、成本和能耗对照。
end-to-end 只平均 5 iterations，time-to-score 无多 seed 区间；最终模型能力与 held-out generalization 证据有限。
AReaL 为作者复现，Laminar 只有 feature decomposition；跨系统排序需要第三方 artifact 复验。
生产案例缺少 raw trace、模型结构、数据、reward、总 GPU hours 和故障日志。
公开 ROLL 仓库持续演进，当前 commit 还不能重建论文全部机制和结果。

跨论文关系

与 HybridFlow / VERL：HybridFlow 解决 RLHF dataflow 与 placement 表达；RollArt 把 placement 扩展到 task-domain GPU affinity、CPU environment、serverless reward 和跨集群 weight store。
与 Laminar：Laminar 保持单 trajectory 的 behavior version 一致，并让 rollout 在本地 batch drain 后独立拉权重；RollArt 会在换权后重算 KV 并继续逻辑轨迹，以 $\alpha$ 限制起始版本年龄。两者分别选择 version-consistent trajectory 与 bounded mixed-version continuation。
与 slime 官方仓库 / GLM-5：slime/GLM-5 更明确披露 TITO、rollout logprob 与 direct IS；RollArt 更完整地覆盖异构资源池和 environment/reward placement。结合阅读可看出系统 overlap 与 RL correction 需要分别记录。
与 Seer：Seer 在同步 rollout 内优化 context scheduling、global KVCache 与 speculative decoding；RollArt 在 pipeline 外层优化 task placement、trajectory progression 和 train-rollout overlap。
与 Bebop：Bebop 降低单次 decode 的 token cost；RollArt 降低环境 barrier、资源错配和 weight-transfer exposure。decode engine 可成为 RollArt inference pool 的内部组件。
与 SAO：SAO 显式使用 rollout logprob 和双侧 mask 处理 stale token，并改变 advantage estimator；RollArt 重点约束 trajectory start age 和系统资源。SAO 补充了 RollArt camera-ready 未展开的 token-level correction 维度。
与 Kimi K2/K2.5：Mooncake 在 Kimi 基础设施中承担 KV/数据传输角色，在 RollArt 中承担跨集群 weight store；同一中间存储范式被用于 serving state 与 RL weight movement。

Reference Intake Brief

Target

Intended target system: 论文档案中的 agentic RL infrastructure 主线。
Existing related assets: HybridFlow / VERL、Laminar、SAO。
Proposed form: v2 独立论文笔记、收紧后的索引核心信号、完整作者链接和 commit-pinned code audit。

Reusable Elements

stage、task-domain、phase、trajectory 四层 disaggregation 检查表。
$n-v_0(\tau)\le\alpha$ 的精确 staleness 口径与 mixed-version audit。
total transfer / exposed critical-path transfer 的通信实验读法。
trajectory execution、GRPO group consumption 和 trainer batch 的多粒度数据契约。
redundant first-finished rollout 的采样偏置检查。

Risks

Copyright/over-copying: 使用机制重建和数字摘录，未复制连续正文。
Unsourced or unverifiable claims: mixed-version、selection bias 与 artifact mapping 已标为本地分析并给出推理边界。
Version drift: 公开 ROLL commit 晚于论文实验，所有代码判断都固定到 ba7092f。
Platform dependence: H20/H800 cost、内部 serverless、Kubernetes 与 Mooncake 条件已经写入结论边界。

Skipped

Material	Reason
公开 reviewer comments	USENIX proceedings 没有公开 HotCRP review、rating 或 rebuttal。
论文实验的逐 token correction	camera-ready 未披露，当前 ROLL 的可选 correction 不能替代论文配置。
完整 reproduction run	未找到标明 RollArt artifact 的 commit、配置和内部 serverless/Mooncake 环境。
production raw trace	公开材料只有聚合图表与文字统计。

Recommendation

Decision: merge

Why: RollArt 的核心价值来自把 task-domain hardware affinity、trajectory-level environment execution、serverless reward、bounded asynchronous training 与跨集群 weight movement 放入同一 agentic RL runtime。精修后的档案同时保留了其系统证据与 RL 数据契约缺口，可作为后续异步 Agentic RL 论文的资源、版本和采样审计基准。

Source #

作者与关系 #

阅读目标与判断边界 #

论文脉络 #

1. 研究问题、背景和价值 #

2. 已有路径留下的缺口 #

3. 作者可能的思考路径 #

4. 核心假设或切入点 #

5. 方法 / 系统 / 理论框架 #

5.1 先区分四种“拆分” #

5.2 三个 plane 把声明与调度分开 #

5.3 轨迹级状态机消除环境 barrier #

5.4 α\alphaα 约束的是 trajectory 起始版本年龄 #

5.5 逻辑轨迹会跨版本，KV 重算只恢复计算状态 #

5.6 Mooncake 把传权从同步 push 改成发布与按需 pull #

5.7 冗余 rollout 以完成顺序换取尾部容忍 #

5.8 公开仓库提供部分机制映射 #

关键实验/定理 #

结果 1：四类 workload 都能成为 step bottleneck #

结果 2：端到端收益来自异步与硬件映射的组合 #

结果 3：R1-R4 分别对应不同收益和边界 #

结果 4：Mooncake 主要降低传权的暴露时间 #

结果 5：生产案例证明规模存在，也暴露供给不足 #

实验设置与 baseline 审计 #

证据链强度评估 #

强证据 #

中等强度证据 #

需要谨慎的推论 #

OpenReview / 审稿意见吸收 #

本地讨论补充 #

1. “trajectory-level”需要同时保留 group 语义 #

2. α\alphaα 的最窄解释 #

3. Mooncake 数字需要按 critical path 阅读 #

4. serverless 实验包含资源重分配 #

5. 后续复验指标 #

主要启发 #

局限 #

跨论文关系 #

Reference Intake Brief #

Target #

Reusable Elements #

Risks #

Skipped #

Recommendation #