TensorHub: Scalable and Elastic Weight Transfer for LLM RL Training
TensorHub: Scalable and Elastic Weight Transfer for LLM RL Training #
Chenhao Ye et al. (ByteDance Seed, UW-Madison) | 2026-04 | https://arxiv.org/abs/2604.09107 Category: framework | Tags: RL-training, weight-transfer, RDMA, reference-oriented-storage, elasticity, fault-tolerance, pipeline-replication, cross-datacenter
§1 TL;DR #
TensorHub 提出 Reference-Oriented Storage (ROS)，一种无数据所有权的存储抽象，直接复用 GPU 上已有的模型权重副本通过 RDMA 传输，结合 pipeline replication、拓扑感知调度和容错机制，在 1024 GPU standalone rollout 中减少 GPU stall 6.7×，elastic rollout 加速 4.8×，跨数据中心 stall 减少 19×。
§2 核心三问 #
Q1 痛点：LLM RL 训练中权重传输的效率-灵活性困境 #
Paper's Figure 1 (caption: "RL Workload with Diverse Rollout Strategies"). 左侧为 co-located workers（trainer 与 rollout 时分复用同一 GPU），右侧展示三种 rollout 扩展策略：standalone（专用 GPU）、elastic（spot 实例，可随时被抢占）、cross-DC（跨数据中心异构资源）。模型权重（可达 TB 级）是流水线中的瓶颈数据。
LLM RL 训练是一个 trainer→rollout 的持续迭代循环，每步都需要将新版本模型权重从 trainer 传输到 rollout worker。生产环境中 rollout 时间占训练总时间 >90%，推动了 standalone、elastic（spot 实例）、cross-datacenter 三种扩展策略。这要求权重传输系统同时满足五个目标：
- 拓扑感知：适应网络拓扑和运行时负载
- 弹性：支持动态扩缩容和故障透明恢复
- 最少协调：避免全局 barrier 和 straggler 放大
- 最少数据搬运：源→目标 GPU 直传，无中间跳
- 无额外存储空间：TB 级权重不应有额外副本
- NCCL（集合通信）：高吞吐但需静态通信组，任何节点故障导致全组崩溃，broadcast 是全局 barrier
- UCX（点对点）：灵活但缺乏全局拓扑视图，fan-out 下发送端带宽成为瓶颈
- 分布式存储（Parameter Server, Ray object store）：解耦好但 push-then-pull 翻倍数据搬运。Ray 传 40 GB 需 32 秒 vs GPU-direct RDMA ~0.2 秒（160× 差距）；>300 GB 时 Ray 频繁 OOM 崩溃
- publish(version)：将 GPU 上的权重注册为某版本的引用（非复制），承诺不可变
- replicate(version)：从任意持有该版本的 peer 直接 RDMA 读取到本地 GPU
- unpublish()：撤销不可变承诺前，先 drain 所有进行中的传输
- Mutability Contract：publish 时承诺不修改，mutation 前必须 unpublish 并等待进行中传输完成
- Retention Protocol：worker 声明需保留的版本（如最新 k 个）；当最后一个副本要 unpublish 时，offload 到 CPU 内存作为兜底。Offload 极少触发（PCIe ~48 GB/s，全 GPU offload <2s）
- Stage coverage：覆盖 RL 训练中 trainer→rollout 的权重传输阶段（非推理 serving）
- Serving or training：专为 RL 训练的权重分发设计，支持同步和异步 RL 框架
- Parallelism：natively 支持 model parallelism（sharding），每个 model-parallel group 为一个 replica。评估覆盖 2-shard (9B) 到 16-shard (mocked 1T)
- Deployment mode：多节点，跨多数据中心。评估规模从 16 GPU 到 1024 GPU
- Smart skipping：polling 的 replica 发现 seeding 正在进行时，将新版本视为暂时不可用，避免被慢速 TCP 拖慢
- Offload seeding：seeding replica 创建 CPU 内存 offload buffer，
update()立即返回，TCP 传输在后台进行。以有限 CPU 内存换取 GPU stall 消除 - Client failure：heartbeat 超时后 server 移除整个 replica。进行中传输的源故障由接收方检测并报告，server 选择替代源
- Spot churn：统计 retained 版本的 replica 数时排除 spot 实例。最后一个非 spot replica 失败时返回优雅错误，client 重试下一版本
- Server failure：server 仅维护软状态（引用），client 重置为 unpublished 并连接备份 server，无需恢复前任状态——下一轮 publish 自然重建
- Pipeline replication 吞吐模型：pipeline replication 在理论上应实现接近 $O(1)$ 的单 replica 传输延迟（independent of replica count），但论文未给出闭合表达式描述在 $N$ 个 rollout 同时请求时的精确吞吐量和完成时间分布。一个 $T(N) = T_{\text{seed}} + \frac{N-1}{k} \cdot T_{\text{transfer}}$ 形式的模型（$k$ 为并发 pipeline 深度）可以指导部署时的 trainer:rollout 比例选择。
- GPU stall time 的解析上界：TensorHub 声明消除 trainer stall 且 rollout stall 低于 baseline，但未给出给定网络拓扑（NIC 数量、带宽、cross-DC 链路速率）和工作负载（模型大小、rollout 数量）下的 stall time 上界。类似 DualPath 的 CNIC 带宽约束分析（Eq. 1-9）可以明确 TensorHub 的 bottleneck-free 操作区间。
- Retention protocol 的内存开销模型：offload 频率取决于 publish/replicate 的时序竞赛，论文仅声明"rarely triggered"但未量化在不同 trainer:rollout 比和版本更新频率下的触发概率和 CPU 内存峰值。
- 硬件：NVIDIA Hopper GPU 集群，每节点 160 CPU + 8 GPU + 1800 GB Memory + 4× 400 Gbps RDMA NIC + 1× 200 Gbps VPC NIC
- 传输引擎：基于 Mooncake transfer engine（RDMA）
- RL 框架：ByteDance 生产 RL 框架，基于 veRL (HybridFlow)
- 模型：9B (2 shards, 10 GB/shard)、36B (4 shards, 19 GB/shard)、260B (8 shards, 34 GB/shard)、mocked 1T (16 shards, 66 GB/shard)
- Baselines：NCCL、UCX、Ray Plasma object store、RDMA ideal roofline
- TensorHub 完全消除 trainer stall：
publish是轻量引用传递，trainer 立即恢复训练。NCCL/UCX 需要 Ray driver 协调的全局 barrier - Straggler 放大效应：1T 模型理想传输 2.6s，但 NCCL stall 5.3s、UCX stall 4.0s（1024 GPU 全部等待最慢节点）。TensorHub 将 stall 局部化到 standalone worker（mean 3.1s），总 stall time 减少 6.7×
- 模型越大优势越明显：9B 时优势约 3×，1T 时达 6.7×
- NCCL 不支持 elastic（静态通信组），只有 UCX 作为 baseline
- UCX 的阶梯 CDF 揭示了 standalone→elastic 的串行依赖：elastic 必须等 standalone 从 trainer 拉完，再从 standalone 拉取，多层排队
- TensorHub 的 stall time 与 elastic GPU 数量无关（~1.5s 常数），逼近 RDMA ideal。Reference server 全局视图 + pipeline replication 使所有可用 replica 均匀分担负载
- 4.8× 加速来自消除 UCX 的 stair-shaped 排队延迟
- UCX baseline：每个 rollout replica 独立走 TCP over VPC NIC，所有流争抢单个 200 Gbps NIC，per-GPU stall 7.8s
- TensorHub smart skipping：仅 seeding replica（2 GPU）走 TCP 2.5s，其余 6 GPU 走本地 RDMA 0.45s。跨 DC 流量从 ~80 GB 降至 ~20 GB（4× 减少）
- TensorHub offload seeding：seeding replica 创建 CPU offload buffer 后
update()立即返回，TCP 在后台传输。所有 GPU 的前台 stall 近零 - 综合 19× stall time 减少
- 同 DC 优先，DC 内 least-loaded（引用计数最低的 replica）
- Pipeline replication 下每个 replica 最多服务一个请求，保证 unpublish drain 快速
- RDMA Direct：长期分配的 tensor 直接注册到 RNIC，一侧 RDMA Read 零拷贝（最佳性能）
- RDMA Copy：频繁重分配的 tensor 用后台线程 slice-by-slice 复制到预注册 buffer 再 RDMA Write（避免频繁 RNIC 注册）
- TCP：跨 DC 无 RDMA 时使用
- 硬件亲和：GPU tensor 选择最近的 NIC，RDMA Copy 用同 GPU 上的预注册 region
- TensorHub vs NCCL/UCX：公平。均在 ByteDance 生产 veRL 框架上测试，硬件相同。RDMA ideal roofline 作为参考上界。NCCL/UCX 的劣势主要来自协调开销（全局 barrier）而非传输效率
- Ray object store：仅在微基准中对比，因其性能差距太大（~160× 慢）排除出 RL 实验。公平但也说明 Ray 不适合此场景
- 缺失 baseline：未对比 ByteCheckpoint（同公司，checkpointing 系统）和其他 RL 专用框架（如 StreamRL 的内部权重传输机制）
- 实现规模：3.7K 行 Python + 2.4K 行 C++
- Server：Ray named actor，lazy 实例化
- Client↔Server 通信：Ray RPC
- 传输引擎：基于 Mooncake transfer engine（RDMA）
- 验证：1.3K 行 concurrency tests（受 FoundationDB 启发的确定性模拟测试）+ end-to-end checksum
- Mooncake (Qin et al., 2025, FAST'25)：RDMA 传输引擎
- veRL (Sheng et al., 2025b, EuroSys'25)：RL 训练框架
- Ray (Moritz et al., 2018, OSDI'18)：分布式框架，用于 server actor 和 RPC
- RDMA 全双工利用：接收和发送同时进行，需确保 NIC 的 RX 和 TX 路径不互相干扰。在 Mellanox ConnectX-7 上实测可达接近 2× 单向带宽（接收+发送并行），但需要仔细调优 QP 参数
- Progress counter 的并发安全性：source worker 不断更新 counter，多个 requester 同时读取。需要原子操作保证一致性，且不能用锁（会打断 RDMA 流水线）
- Partial-replica 的故障恢复：当 partially-replicated source 故障时，requester 需要 (a) 检测故障，(b) 确定已接收的 prefix 范围，(c) 从其他 source 续传剩余部分。这涉及 RDMA 层的保守超时 (~4s) 和 server-side 的状态清理
- Tiny-tensor compaction 的 zero-copy 解包：compacted buffer 传输后需在 receiver 端解包到原始 tensor layout，这必须与 RDMA 传输重叠执行以隐藏开销
- Mutability contract 的 drain 机制：
unpublish()不立即生效——server 先标记 replica 不可见（不接受新请求），等待进行中传输完成（at most 1 inflight due to pipeline policy），然后确认。这保证了 buffer reuse 安全性，且等待有界。 - Server 的 stateless recovery：reference server 失败后，新 server 无需任何状态恢复。因为所有数据在 worker GPU 上，server 只需等待下一轮 publish 重建引用。这是 ownership-free 设计带来的优雅副作用——传统 PS 失败需要复杂的 checkpoint recovery。
- RDMA Copy 模式的 slice-by-slice 设计：当 tensor 频繁重分配时，后台线程逐片复制到预注册 buffer 再 RDMA Write。这比重新 RNIC 注册便宜（注册是 heavy OS operation），但引入了 CPU 参与的复制开销。对于 long-lived tensor，RDMA Direct 完全绕过 CPU。
- 对外接口：Python API（
tensorhub.open,register,publish,replicate,update,unpublish,close），支持 CPU 和 GPU tensor - 集成复杂度：极低。veRL 框架上仅需 ~40 行代码修改（对比 NCCL ~450 行、UCX ~1200 行）
- 配置表面：相对简单——主要选择 transfer mode（RDMA Direct/Copy/TCP）和 retain 策略（latest k versions）
- 开源状态：否。TensorHub 为 ByteDance 内部系统
- 生产部署：是。论文明确声明 "deployed in ByteDance production to support cutting-edge RL training"
- 底层依赖的开源：Mooncake 和 veRL 均已开源
- 迁移路径：对于使用 veRL/OpenRLHF 等框架的外部团队，核心思想（reference-passing + pipeline replication over RDMA）可在 ~2K 行内实现。关键壁垒是 Mooncake RDMA 传输引擎的集成和 pipeline replication 的并发控制
- 适用阶段：RL 训练中的 trainer→rollout 权重传输（非推理 serving）
- 并发规模：中到超大规模（16-1024 GPU evaluated；声明单 server 可支撑千级 worker）
- 硬件要求：RDMA NIC（InfiniBand/RoCE）；跨 DC 可降级 TCP 但性能降低
- 框架集成：与 veRL 深度集成；可适配其他 RL 框架（AReaL, OpenRLHF, Laminar 等）只要框架暴露 weight buffer access 点
现有方案各有致命缺陷：
根本原因：传统存储的数据所有权（ownership）带来的序列化、复制和带宽开销。
Q2 方法：Reference-Oriented Storage — 无所有权的存储抽象 #
核心洞察：RL 中的模型权重具有三个特性——(1) 数据并行导致高度复制（多个对等数据源），(2) 推理期间不可变（安全读取无需协调），(3) 短生命周期（只关心最近几个版本）。因此可以不存储任何副本，仅追踪谁的 GPU 上持有哪个版本的权重，按需通过 RDMA 直接读取。
ROS 的三个核心原语：
两个关键协议：
核心技术壁垒：将 pipeline replication 与 ROS 结合实现带宽放大 DAG。利用 RDMA NIC 的全双工特性，正在接收数据的 worker 立即开始向下游提供已接收的部分（通过 progress counter 追踪），将 N-way fan-out 从单源瓶颈转化为带宽随参与者数量线性增长的 DAG 拓扑。这需要精确控制 RDMA 传输的 tensor 级粒度和并发调度，是外部团队最难复现的核心机制。
Q3 结果 #
| 场景 | 指标 | 提升 | 条件 |
|---|---|---|---|
| Standalone rollout | Total GPU stall time | 6.7× reduction vs NCCL | 1T model, 1024 GPUs |
| Elastic rollout | Weight update latency | 4.8× faster vs UCX | 260B model, 8+24 GPUs |
| Cross-datacenter | GPU stall time | 19× reduction vs UCX | 9B model, 16+8 GPUs |
| RDMA bandwidth | Throughput | 22 GB/s (88% theoretical) | 50 GB shard, 1:1 |
| Pipeline replication | Scaling | Linear vs quadratic w/o pipeline | 1-8 rollout groups |
| Engineering effort | Lines of code | ~40 LoC vs ~450 (NCCL) / ~1200 (UCX) | veRL integration |
TensorHub 完全消除 trainer stall（publish 是轻量引用操作），standalone rollout stall 也始终低于 NCCL/UCX。在 elastic 场景中，stall time 与 GPU 数量无关（~1.5s 常数），而 UCX 呈阶梯状 CDF 尾部达 7.2s。跨数据中心通过 smart skipping + offload seeding 实现仅第一个 seeding replica 走 TCP，其余全走本地 RDMA。
§3 架构与方法 #
3.1 System Scope #
3.2 ROS 架构 #
Paper's Figure 2 (caption: "Reference-Oriented Storage Workflow. The server only operates on lightweight references. The bulk weight transfer is directly between clients."). 橙色箭头为轻量引用流（经 reference server），绿色箭头为批量 RDMA 数据流（client-to-client 直传）。Worker-0 publish 后 reference server 记录引用；Worker-1 replicate 时从 server 获取源引用，然后直接 RDMA 读取 Worker-0 的 GPU 内存。Server 从不触碰权重数据。
ROS 由两部分组成：(1) 中心化 reference server：仅维护轻量引用元数据（版本→replica→shard 映射），不存储权重数据；(2) client library：嵌入每个 worker，执行 RDMA 数据传输。
关键设计：所有 weight 副本（无论由 publish 还是 replicate 创建）被视为对等 replica。rollout 不必从 trainer 获取权重，可以从任意 peer 拉取。这使集群具备自愈能力——只要一个 replica 存活，重启的 worker 就能恢复。
3.3 Pipeline Replication #
Paper's Figure 5 (caption: "Pipeline Replication. Worker-0 is the only source, while both Worker-1 and Worker-2 are requesting data. To scale throughput, TensorHub schedules a pipeline where Worker-2 reads partially replicated data on Worker-1."). Worker-0 进度 6/6（完成），Worker-1 进度 4/6（部分完成），Worker-2 进度 1/6（刚开始）。Worker-2 可以从 Worker-1 的已完成部分读取（tensor 1~3 + progress counter），无需等待 Worker-1 全部完成。利用 RDMA NIC 全双工——接收时上行空闲可服务数据。
Pipeline replication 是 TensorHub 将 fan-out 从单源瓶颈转化为带宽放大 DAG 的核心机制。每个正在 replicate 的 worker 维护 progress counter（已接收 tensor 数），新 requester 从 least-loaded 的 source（可以是部分完成的 peer）读取已就绪的前缀，循环读取 counter 直到全部数据到达。
3.4 Sharding Consistency #
Paper's Figure 6 (caption: "Sharding Consistency Example"). 左图（物理时间线）：replica-0 的 shard:0 在 T0 请求 latest 看到 version 12，但 replica-1 在 T1/T2 publish version 13，导致 shard:1 在 T3 看到 version 13——同一 replica 内两个 shard 看到不同版本，造成 SPMD 分歧。右图（事务时间线）：TensorHub 在 replica 粒度强制事务语义，确保 replica-0 的两个 shard 都看到 version 12。
LLM 权重超过单 GPU 内存，需 model parallelism。同一 model-parallel group 必须执行相同代码（SPMD），版本分歧会导致挂起或数据损坏。TensorHub 在 reference server 端以 replica 粒度强制事务语义：第一个 worker 的请求启动事务，后续同组 worker 消费事务缓存的状态。
3.5 Cross-Datacenter Replication #
两阶段模式：(1) Seeding：目标数据中心的第一个 replica 通过 TCP 从源数据中心获取权重；(2) Local pipeline：seeding 完成后，同数据中心内的其他 replica 通过 RDMA pipeline replication 获取。
优化：
3.6 Fault Tolerance #
三级故障处理：
3.7 请求生命周期 #
3.8 Naming Scheme & API #
Paper's Figure 3 (caption: "TensorHub Naming Scheme"). 层级结构：model → version → replica → shard。Rollout-2 通过 replicate 获取 version 3 后，自身也成为可服务后续请求的 replica（虚线框变实线）。支持绝对版本号和相对版本（"latest", "latest-k"）。
核心 API：open → register → publish/replicate/update → unpublish → close。update("latest") 是原子操作，检查版本可用性 + unpublish 旧版本 + replicate 新版本一步完成，避免轮询竞态。
Paper's Figure 4 (caption: "TensorHub Examples"). 左图 (a) co-located trainer & rollout：publish→rollout→unpublish→train 循环。右图 (b) standalone rollout：replicate("latest") 初始化后 update("latest") 轮询。两段代码简洁展示了 TensorHub ~40 行集成的核心——对比 NCCL ~450 行和 UCX ~1200 行。
§4 作者证明 #
无形式化作者证明 — 仅实证
本文是系统论文，无编号方程和形式化推导。所有性能声明均通过实验验证。
需要形式化模型但未提供的三个方面 #
§5 实验与数据 #
5.1 实验环境 #
5.2 微基准测试 #
Paper's Figure 7 (caption: "Microbenchmark Results"). 三个子图：(a) 不同 shard 大小下的传输延迟，(b) pipeline replication 的扩展性，(c) 故障时的传输延迟。
Figure 7(a) — RDMA 带宽效率：TensorHub 始终最低延迟。50 GB shard 传输 2.2s，达 22 GB/s（理论 25 GB/s 的 88%）。NCCL 18.8 GB/s，UCX 18.1 GB/s。Ray object store 慢两个数量级（纵轴截断至 195s），且 >35 GB 时崩溃。TensorHub 的优势来自 RDMA Direct 零拷贝路径和 tiny-tensor compaction（<2 MB tensor 合并传输）。
Figure 7(b) — Pipeline replication 扩展性：关键结果——有 pipeline 时 total GPU stall time 线性增长（斜率接近 RDMA ideal roofline），无 pipeline 时二次方增长。8 个 rollout group 时差距约 2×。这验证了 pipeline replication 将 N-way fan-out 转化为带宽放大 DAG 的核心机制。
Figure 7(c) — 故障透明恢复：pipeline 中 Worker-A 故障后 Worker-B 始终完成传输。故障立即发生时，RDMA 层 ~4s 保守超时后检测并重路由到 trainer 直读。故障发生越晚恢复越慢（因重传延迟），但 2.2s 后故障无影响（B 已完成）。峰值恢复延迟 ~10s（故障发生在 ~1.5s 时），可控。
5.3 Standalone Rollout — 主实验 #
Paper's Figure 8 & 9 (caption: "Weight Transfer Flows with Standalone" and "Standalone Rollout Results"). 上方 Table 3 列出四个模型的参数。中间 Figure 8 对比 baseline（Ray driver 协调 blocking send/recv）vs TensorHub（publish 后无等待，rollout 主动 pull）。下方 Figure 9 bar chart：红色（TensorHub）显著低于绿色（NCCL）和蓝色（UCX），且 TensorHub 无 trainer stall（solid bar），只有 standalone stall（hatched bar）。1T 模型最为突出——NCCL 和 UCX 分别 stall 全部 1024 GPU 达 ~5800s 和 ~4200s，TensorHub 仅 ~700s 且全部来自 standalone。
关键发现：
5.4 Elastic Rollout — Spot 实例 #
Paper's Figure 10 & 11 (caption: "Weight Transfer Flows with Standalone and Elastic" and "Elastic Rollout Results"). 上方 Figure 10：baseline（UCX）中 elastic worker 必须经 standalone 中转，产生 contention；TensorHub 中 elastic 可从任何源（trainer/standalone/peer elastic）获取，始终 load-balanced。下方 Figure 11(a)：随训练步进（x 轴），GPU 数量随 spot 扩缩变化（灰色阴影），UCX stall time（蓝色）剧烈波动 100-180s，TensorHub（红色）稳定 ~50s。下方 Figure 11(b)：step 10 的 per-GPU latency CDF，UCX 呈阶梯状（standalone 8 GPU ~1.5s，最后一批 elastic GPU 等待到 7.2s），TensorHub 近乎竖直跳跃到 ~1.5s。
关键发现：
5.5 Cross-Datacenter — 跨 DC 部署 #
Paper's Figure 12 (caption: "Cross-Datacenter Rollout Results"). 三个子图。左：total standalone GPU stall time——UCX ~62s，TensorHub(skip) ~7.6s，TensorHub(skip+offload) ~3.2s。中：per-GPU latency CDF——UCX 所有 8 GPU 均 ~7.8s；TensorHub(skip) 的 2 GPU（seeding replica）~2.5s、其余 6 GPU ~0.45s；TensorHub(skip+offload) 几乎所有 GPU <1s。右：cross-DC network traffic——UCX ~80 GB/step（每个 replica 独立走 TCP），TensorHub ~20 GB/step（仅 seeding replica 走 TCP 一次）。
关键发现：
5.6 Before-After 对比表 #
| 优化 | 指标 | Baseline | After | 改善 | 条件 |
|---|---|---|---|---|---|
| ROS + Pipeline | Transfer latency | NCCL 2.7s | TensorHub 2.2s | 22 GB/s (88% ideal) | 50 GB, 1:1 |
| ROS + Pipeline | Transfer latency | Ray 195s | TensorHub 2.2s | ~90× | 50 GB, 1:1 |
| Pipeline replication | Stall scaling | Quadratic | Linear | N-way → DAG | 1-8 groups |
| Full system | Standalone stall | NCCL 5848s | TensorHub 673s | 6.7× | 1T, 1024 GPU |
| Full system | Elastic stall | UCX ~150s/step | TensorHub ~50s/step | 4.8× | 260B, 32 GPU |
| Full system | Cross-DC stall | UCX 62s | TensorHub 3.2s | 19× | 9B, 24 GPU |
| Full system | Cross-DC traffic | ~80 GB/step | ~20 GB/step | 4× | 9B, 24 GPU |
| Integration | Code changes | NCCL ~450 / UCX ~1200 LoC | TensorHub ~40 LoC | 11-30× simpler | veRL |
5.7 Scheduling & Resource Management #
Server-side scheduling：
Transfer engine（三种模式）：
Tiny-tensor optimization：LLM 含大量 <2 MB tensor（36B 模型约 500 个 tensor 半数为 tiny），合并到连续 buffer 传输，仅需 ~3 MB 额外内存。
Memory management：无需额外存储空间（ROS 核心设计）。唯一的内存开销是 retention protocol 的 offload（极少触发，单副本 CPU 内存），和 cross-DC offload seeding（每 DC 一份，有限 CPU 内存）。
5.8 Workload Characterization #
| Workload 区间 | TensorHub | Baseline | 原因 |
|---|---|---|---|
| 大模型 + 多 rollout（1T, 1024 GPU） | 显著优于（6.7× vs NCCL） | 全局 barrier + straggler | TensorHub 无 trainer stall + pipeline replication |
| Elastic spot 实例（动态扩缩容） | 显著优于（4.8× vs UCX） | 串行依赖 + 带宽争抢 | 全局调度 + pipeline，stall 与 GPU 数无关 |
| 跨数据中心（TCP 瓶颈） | 显著优于（19× vs UCX） | 每 replica 独立走 TCP | Smart skipping + offload seeding |
| 小模型少 rollout（9B, 1:1） | 优势有限 | NCCL/UCX 尚可 | 网络未饱和，协调开销占比小 |
| Co-located（trainer=rollout 同 GPU） | 等价或更优 | 等价 | 权重在本地，publish/unpublish 开销极小 |
| RDMA 不可用（纯 TCP 环境） | 降级为 TCP 传输 | UCX-TCP | TensorHub 仍有调度和 pipeline 优势，但带宽增益消失 |
5.9 Baselines 公平性分析 #
§6 论证链 #
| Step | 论点 | 证据 | 依赖 |
|---|---|---|---|
| 1 | RL 训练中 rollout 占 >90% 时间，推动 standalone/elastic/cross-DC 扩展 | 引用 veRL、OpenRLHF 等；RLBoost 报告 elastic 可提升 1.97× (§2.1) | — |
| 2 | 权重传输需同时满足拓扑感知、弹性、最少协调、最少搬运、无额外空间五个目标 | 五目标定义 (§2.2)；Table 1 系统对比 | Step 1 |
| 3 | 现有方案均无法同时满足：NCCL 缺弹性+协调重，UCX 缺拓扑感知，Storage 翻倍搬运 | Table 1 + §2.3 定性分析；Ray 32s vs RDMA 0.2s (§2.3) | Step 2 |
| 4 | 数据所有权是 storage 方案额外搬运的根因；RL 权重的复制性+不变性+短命使无所有权可行 | §3 开头三条属性观察 | Step 3 |
| 5 | ROS 通过 publish/replicate/unpublish 原语 + mutability contract + retention protocol 实现无所有权存储 | §3.1-3.3 设计 | Step 4 |
| 6 | Pipeline replication 利用 RDMA 全双工将 fan-out 转为带宽放大 DAG，线性扩展 | Fig 7(b)：linear vs quadratic scaling (§5.1.2) | Step 5 |
| 7 | 中心化 server 的全局视图 + least-loaded 调度实现拓扑感知和弹性 | Fig 11：elastic stall 与 GPU 数无关 (§5.3)；Fig 12：跨 DC smart skipping (§5.4) | Step 5 + 6 |
| 8 | 事务语义 + 故障处理确保 model-parallel 一致性和动态集群正确性 | Fig 6 consistency example (§4.4)；Fig 7(c) failure masking (§5.1.3)；1.3K 行 concurrency tests (§4.6) | Step 5 |
| 9 | 完整系统在三种 rollout 策略下均显著优于 baseline，且集成极简 | 6.7× standalone、4.8× elastic、19× cross-DC、~40 LoC (§5.2-5.4) | Step 6 + 7 + 8 |
§7 实现与工程细节 #
7.1 代码 Cross-Reference #
[实现未公开] — TensorHub 为 ByteDance 内部系统，代码未开源。
依赖的开源组件：
7.2 核心技术壁垒 #
Pipeline replication 的精确实现是外部团队最难复现的部分。表面上 "partially-replicated worker 开始服务下游" 概念简单，但实际需要：