Prhub

#2484 docs: add disaggregated RL rollout guide

原始 PR 作者 nanjiangwill 合并时间 2026-08-13 06:39 文件变更 7 提交数 18 评论 0 代码增减 +359 / -12

执行摘要

新增分离式 RL rollout 架构指南,同步 6 个文档页面

训练与 rollout 的资源画像完全不同:训练 ranks 构成长期存续、紧耦合的集群,而 rollout 需求是突发性的,可以在全球范围内动态扩容 GPU。PR body 明确说明:Making rollout an independent service lets miles add or remove inference capacity without resizing the trainer, place rollout where GPUs are available, isolate replica failures, and keep fully async generation supplied。同时这种分离要求 RL 特有的正确性契约——miles 必须发布不可变的 policy 版本、在 rollout 请求上表达版本需求、并记录每条返回轨迹由哪个版本生成。指南还澄清了 --rollout-external 的定位(挂接外部引擎而非外部服务),并把 disk-delta 定位为当前的发布基础。

值得精读,尤其 Topologies 表、--rollout-external 的定位说明、disk-delta 5 步生命周期与 policy-version 契约部分。对于要接入或实现外部 rollout 服务的工程师,这份文档就是接口契约草案;对纯功能使用者,重点看 Quick Start 与 Training Backends 中被同步修改的 --update-weight-transfer-mode 说明。设计上值得借鉴的是文档先定义契约、再等实现落地的先行方式,以及 commit 序列中对外部项目表述的克制处理。

讨论亮点

该 PR 没有任何 inline review 评论(comments_count = 0、review_comments_count = 0),唯一正式审核是 Zhichenzzz 的空正文 APPROVED。可观察的讨论体现在 18 个提交的演进序列中:

1) 对第三方参考实现 Stitch(Modal 团队)的定位经历 identify Stitch reference integration → avoid priority claim for Stitch → keep Stitch mention focused → link Stitch's miles-fork notes from the rollout-service contract 四轮收敛,说明作者刻意控制表述分寸,避免读者把外部项目误读为官方路线图优先级。
2) 测量数据经历 add Kimi K2.6 weight-sync measurement → simplify weight-update measurements → focus rollout weight-sync measurements → tighten rollout measurement context 多轮瘦身,最终只保留与 rollout 权重同步直接相关的上下文。
3) use lowercase miles in rollout guide 统一了产品名拼写规范;合并阶段由 Zhichenzzz 补入对 Nan Jiang / Modal 团队与 Jason Mancuso 的致谢,并把 Stitch 的 miles-fork 笔记互链进外部服务契约段落。

实现拆解

  1. 新增核心指南页:docs/advanced/disaggregated-rollout.md(+332 行)。以训练与 rollout 资源画像差异开篇论证解耦价值;用三行拓扑表区分 miles-managed rollout / Attached SGLang engines / External rollout service,明确前两种当前已支持、第三种 coming soon;给出独立 GPU 布局示例(--actor-num-nodes 1、--rollout-num-gpus 8、--rollout-num-gpus-per-engine 2)与外部引擎挂接参数(--rollout-external、--rollout-external-engine-addrs),并强调 --rollout-external 不会移交权重更新所有权。
  2. 梳理权重同步路径:用表格对比 --update-weight-transfer-mode 三档——broadcast(NCCL 默认)、p2p(RDMA 直写,集群内优化)、disk-delta(共享存储发布版本化增量);随后给出 disk-delta 的 5 步发布/激活生命周期(CPU snapshot → 字节对比 → 原子发布 weight_vNNNNNN/ → 本地物化与校验 → 暂停 reload 激活),并说明 XOR 与 overwrite 两种编码的取舍(XOR 紧凑但只能应用一次,overwrite 更大但幂等)。
  3. 注册导航并联动既有页面:docs/docs.json 在 Advanced Features > Scale & Reliability 分组插入新页面(置于 p2p-weight-transfer 与 disk-offload 之间);docs/advanced/index.md 新增指南卡片并更新段首特性列表;pd-disaggregation.md 增加范围区分互链;quick-start.md、training-backend.md、fully-async.md 三处将权重传输描述从二分(broadcast/p2p)扩展为三分(含 disk-delta),并把广播表述改为中性的按配置模式同步。
  4. 迭代打磨与验证:18 个提交完成多轮内容收敛(详见评论区精华);验证手段为 git diff --check、python -m json.tool docs/docs.json 与全量内部链接检查,未引入自动化测试。
文件 模块 状态 重要度
docs/advanced/disaggregated-rollout.md 高级指南 added 5.2
docs/docs.json 站点导航 modified 2.36
docs/advanced/index.md 高级入口 modified 2.23
docs/user-guide/fully-async.md 用户指南 modified 2.23
docs/getting-started/quick-start.md 快速上手 modified 2.02
docs/user-guide/training-backend.md 训练后端 modified 1.96
docs/advanced/pd-disaggregation.md 阶段拆分 modified 1.42

分析完成后,这里会展示 LLM 生成的相对完整源码片段和详细注释。

评论区精华

没有提炼出高价值讨论线程

当前评论区没有形成足够清晰的争议点或结论,后续有更多讨论时会体现在这里。

风险与影响

1) 文档与 CLI 契约漂移:指南密集出现 --rollout-external、--rollout-external-engine-addrs、--update-weight-disk-dir、--update-weight-local-checkpoint-dir 及 XOR/overwrite 等开关与编码名,若对应实现尚未合入或命名调整,本指南会成为误导源;PR 把外部服务标注为 coming soon 已降低此风险,但实现侧需跟进对齐。
2) 数据时效性:Kimi K2.6 权重同步测量涉及具体数字,模型规模与网络环境变化后容易过期。
3) 无自动化验证:仅依赖 json.tool 与链接检查,docs/docs.json 结构与页内锚点(如 training-backend#3-choosing-the-gpu-layout)后续改动可能失配。
4) 影响面:7 个文件、6 个页面联动改文案,其中 Quick Start 与 Training Backends 是高频入口,措辞变化需与真实行为保持一致。

对读者(用户/工程师):首次获得跨集群、跨 region 解耦 rollout 的完整指南,明确了三种拓扑与三种权重同步模式的选择依据,以及 --rollout-external 的真实语义。对团队:以文档先行方式锁定 policy-version 契约与包中立边界的术语体系,为后续外部 rollout 服务实现提供设计锚点与接口草案。对文档站点:新增一个 Advanced 页面并联动 6 页,Advanced Features > Scale & Reliability 分组导航路径发生变化。整体影响范围中等偏上(对 rollout 功能线是奠基性文档),但无运行时影响,风险集中在文档与未来实现的一致性上。

文档与 CLI 契约漂移风险 coming-soon 预告内容 测量数据易过期 无自动化测试覆盖

关联 Issue

未识别关联 Issue

当前没有检测到明确关联的 Issue 链接,后续同步到相关引用后会出现在这里。

完整报告

参与讨论