本篇选取 5 篇相关论文，覆盖 RL 训练框架、RDMA 通信层、推理 I/O 优化和 agentic 调度，与 TensorHub 在权重传输这一核心问题上形成多维对比。
HybridFlow / veRL (2409.19256) — TensorHub 的直接 baseline 和集成目标。veRL 是 TensorHub 运行其上的 RLHF 训练框架，其 hybrid single/multi-controller 设计处理 RLHF dataflow 编排（model placement、parallel group 管理、transfer protocol 抽象），TensorHub 则替换 veRL 默认的权重传输机制（NCCL broadcast 或 UCX point-to-point）。veRL 的 @register + transfer protocol 抽象天然适配 ROS——TensorHub 仅需 ~40 行代码即可集成。两系统垂直互补：veRL 决定"何时传、传给谁"，TensorHub 决定"如何传、从哪传"。TensorHub 的实验 baseline 正是 veRL 的默认权重传输路径。Kind: baseline。
fabric-lib (2510.27656) — TensorHub 的通信层对照和潜在替代。两者都构建在 RDMA 之上实现 LLM 系统中的高吞吐数据传输。TensorHub 内部使用 Mooncake transfer engine（RDMA），fabric-lib 提供跨 ConnectX-7 和 AWS EFA 的可移植 RDMA P2P 抽象。fabric-lib 的 RL 权重传输 benchmark（1T 参数，1.3s，256→128 GPU）是最直接可比的数据点。更关键的是，fabric-lib 的 Table 5 延迟分解揭示了权重传输链路中的真实瓶颈分布：FSDP full_tensor() 占 42%，跨 rank 同步占 29%，RDMA submit 仅占 2.1%——这对评估 TensorHub pipeline replication 的实际贡献至关重要。Kind: related。
DualPath (2602.21548) — 共享 RDMA + InfiniBand 深度工程经验，但面向推理 I/O 而非训练权重传输。DualPath 聚合 decode engine 空闲 SNIC 带宽加速 KV-Cache 加载；TensorHub 聚合正在接收权重的 rollout worker 的 NIC 上行带宽加速权重分发。两者独立发现了同一个系统洞察：大规模 GPU 集群中存在大量空闲 NIC 带宽，可通过 DAG 拓扑聚合。DualPath 部署于 DeepSeek（1152 GPU），TensorHub 部署于 ByteDance（1024 GPU）——两者是当前公开报道中经过千 GPU 级生产验证的 RDMA 系统双雄。Kind: related。
Adaptive Placement / FlexRLHF (2312.11819) — 较早的 RLHF 框架，首先系统性识别"训练-推理分离"作为 RLHF 加速的关键策略。FlexRLHF 的 Disaggregated 策略通过 Shadow Actor/Critic 物理分离训练和推理运行时，创造了 standalone rollout 模式——正是 TensorHub 显式优化的场景。FlexRLHF 实现了 11× 加速，但其权重同步仅用"periodic parameter broadcast"一笔带过，完全未考虑传输效率。TensorHub 填补了 FlexRLHF 留下的这个空白：分离之后，权重怎么高效送达？Kind: related。
ThunderAgent (2602.13692) — 共享 RL rollout 服务场景。ThunderAgent 的 program-aware 调度优化 rollout 推理引擎侧（KV-cache 管理、workflow 生命周期、thrashing 防控），TensorHub 优化 rollout 权重分发侧（trainer→rollout 传输）。ThunderAgent 在 RL rollout 中实现 1.79–3.92× 吞吐提升（via 调度），TensorHub 在 elastic rollout 中实现 4.8×（via 传输）。两者服务同一个生产目标：最大化 rollout 吞吐以最小化 RL 训练的 policy lag。ThunderAgent 的发现"PD 分离在 agent workload 下退化"与 TensorHub 的部署上下文相关——TensorHub 在 RL rollout 中不使用 PD 分离，而是统一的 rollout engine。Kind: related。
TensorHub 的核心 delta 是 Reference-Oriented Storage (ROS) ——从存储层面彻底消除数据所有权，将 GPU 上已有的模型权重副本直接作为可 RDMA 读取的不可变引用，结合 pipeline replication 实现带宽随参与者线性增长的 DAG 传输拓扑。
| 维度 | TensorHub | HybridFlow/veRL | fabric-lib | DualPath | FlexRLHF | ThunderAgent |
|---|---|---|---|---|---|---|
| 优化目标 | 权重传输延迟 | RLHF 训练吞吐 | RDMA 可移植性 | KV-Cache I/O 带宽 | 模型放置效率 | RL rollout 调度 |
| 核心抽象 | ROS (无所有权引用) | Hybrid controller | TransferEngine | Dual-path data path | Placement ratio | Agentic program |
| 传输模型 | Pull-based (任意 peer) | Push (NCCL/UCX barrier) | P2P WriteImm | Load + RDMA relay | Push (AllGather) | N/A (调度层) |
| Fan-out 策略 | Pipeline replication DAG | Broadcast barrier | Full-cluster P2P | Adaptive path selection | N/A | N/A |
| Trainer stall | 消除 | 有 (需 barrier) | 有 (AllGather) | N/A (推理系统) | 有 (同步发送) | N/A |
| 弹性支持 | Spot-aware retention | 无 | 无 | 无 | 异构 GPU | 无 |
| 跨 DC | TCP seeding + local RDMA | 无 | 无 | 无 | 无 | 无 |
| 容错 | 三级 (client/spot/server) | Checkpoint | 依赖底层 | 未涉及 | 未提及 | Release GC |
| 集成复杂度 | ~40 LoC | 自身是框架 | ~2K LoC 估计 | ~5K LoC (内部) | 中等 | 3 处改动 |
| 规模验证 | 1024 GPU | 64 GPU | 384 GPU | 1152 GPU | 128 GPU | 16 GPU |
| 开源 | 否 | 是 (veRL) | 是 | 否 | 否 | 是 |
TensorHub vs HybridFlow/veRL — 垂直互补的因果链。veRL 定义了 RLHF 训练的编排语义（hybrid single/multi-controller + 3D-HybridEngine + auto device mapping），TensorHub 优化了编排中"最重的一条边"——权重从 trainer GPU 到 rollout GPU 的传输。veRL 的 transfer protocol（@register + collect/distribute）天然适配 TensorHub：Actor 的 collect 从 NCCL AllGather 替换为 tensorhub.publish()，distribute 从 send/recv 替换为 tensorhub.replicate()。但这也暴露了 veRL 原始 transfer 设计的脆弱性——NCCL 的静态通信组和全局 barrier 在 elastic/cross-DC 场景完全失效（NCCL 任一节点故障导致全组崩溃），说明 veRL 的 transfer protocol 抽象当初没考虑 beyond-collective 的传输方案。TensorHub 的成功集成（~40 LoC）既证明了 veRL 抽象的可扩展性，也定义了下一代 RLHF 框架对 weight transfer 层的最低要求。
TensorHub vs fabric-lib — 权重传输的真实瓶颈在哪里？ fabric-lib Table 5 的延迟分解提供了极具说服力的剖析：1T 参数传输 1.3s 中，full_tensor() FSDP unsharding 占 42%（518ms），跨 rank 同步占 29%（357ms），RDMA submit 仅占 2.1%（26ms）。如果这个瓶颈分布在 TensorHub 场景中也成立（TensorHub 基于 veRL，veRL 支持 FSDP/ZeRO），那么 pipeline replication 优化的是全链路中最小的环节。TensorHub 的 6.7× standalone stall reduction 可能主要来自两个非 pipeline 因素：(1) 消除 NCCL 全局 barrier（对应 fabric-lib 中 29% 的 "waiting for ranks"）和 (2) ROS 的 publish 零开销消除 trainer stall。Pipeline replication 的带宽放大效果可能被 full_tensor() 瓶颈吃掉。但 TensorHub 与 fabric-lib 有一个关键差异：TensorHub 可能使用 RDMA Direct 模式（长期分配的 tensor 直接注册到 RNIC），绕过了 FSDP unsharding。论文使用 Mooncake transfer engine 而非 FSDP，这个差异使 fabric-lib 的瓶颈分解不能直接套用——但论文缺乏同等粒度的 breakdown 来验证这一推测。
TensorHub vs DualPath — "找到空闲 NIC 带宽"的通用设计模式。两者独立发现了同一个系统洞察在不同场景的应用：DualPath 发现 DE 端 SNIC 空闲可帮 PE 读 KV-Cache；TensorHub 发现正在 replicate 的 rollout worker 其上行 NIC 空闲可帮后续 worker 读 weights。Pipeline replication 和 dual-path loading 在数学上是同一问题——将单源 fan-out 变成 DAG 拓扑以聚合带宽。但实现路径截然不同：DualPath 需要精密的 InfiniBand VL QoS 流量隔离（推理通信和 KV-Cache 传输共享 CNIC，必须硬件级区分优先级），TensorHub 利用 RDMA 全双工的天然双向性（接收和发送使用 NIC 不同物理通道，不需要 QoS 隔离）。TensorHub 的方案更 elegant——不需要额外硬件配置，不依赖 InfiniBand VL。从可复现性角度看，TensorHub 的 pipeline replication 原理更通用（仅需 RDMA 全双工），DualPath 的 CNIC-centric data path 更特化（需要 InfiniBand VL + PCIe 拓扑知识）。
TensorHub vs FlexRLHF — 两年半的技术演进链。FlexRLHF（2023-12）首先证明"训练-推理运行时分离可获 11× 加速"，但将权重同步视为已解决问题（"periodic parameter broadcast"）。到 TensorHub（2026-04），standalone rollout 已成为 production 标配（veRL、OpenRLHF 均默认支持），分离后的权重传输从"已解决"变成"核心瓶颈"——1T 模型的 NCCL broadcast 需要全部 1024 GPU 同步等待最慢节点，stall 达 ~5800s。这是一条清晰的因果链：FlexRLHF 证明"分离是对的" → veRL 实现"分离 + NCCL 同步" → TensorHub 实现"分离 + 无 barrier 同步"。FlexRLHF 的另一个遗留问题——异构 GPU 支持（仅 14.5% 额外加速）——在 TensorHub 的 cross-DC 方案中得到真正解决：跨数据中心部署天然支持异构硬件，且 TensorHub 的 19× stall reduction 远超 FlexRLHF 的异构收益。
TensorHub vs ThunderAgent — 同一 RL 循环的两端优化。RL rollout 端到端时间 = 权重更新延迟（TensorHub 优化） + rollout 推理延迟（ThunderAgent 优化）。两者收益理论上可叠加，但存在交互效应：ThunderAgent 的 program-aware 调度在 rollout 推理期间维护 workflow 状态（Reasoning/Acting），TensorHub 的权重更新会导致所有 in-progress workflows 使用过时的模型权重。ThunderAgent 面临的选择是——在权重更新时中断 workflow 还是用旧版本继续？TensorHub 的 smart skipping 机制（rollout 发现新版本正在 seeding 时跳过）和 ThunderAgent 的 program state machine 可以协同：用旧版本继续 Acting 状态的 program，用新版本开始新的 program，用 TensorHub 的 progress counter 追踪哪些 worker 已就绪。
TensorHub 的独有增量：
以下攻击针对 TensorHub L2 §6 论证链中的具体步骤。
Attack 1: "rollout 占 >90% 时间"的前提正在被异步 RL 侵蚀 (L2 §6 step 1)
TensorHub 的 motivation 建立在"rollout 时间远大于 training 时间，推动 standalone/elastic/cross-DC 扩展"的观察上。但这一数据点来自同步 RL 训练——trainer 必须等 rollout 全部完成才能执行下一步训练。2026 年的 RL 训练越来越倾向异步化：AReaL、StreamRL 等框架支持 asynchronous rollout，trainer 不再等待最慢的 rollout worker。在异步模式下，weight transfer latency 不再是 critical path——trainer 持续训练，rollout 用"稍旧"的权重即可（staleness tolerance 为 k 版本）。TensorHub 的 smart skipping 机制暗示团队已意识到这一趋势，但论文没有量化异步 RL 下的收益。如果 staleness tolerance 为 k=3 且 training step time 为 10s，则 weight transfer latency 只要低于 30s 即可——NCCL 的 ~5s stall 已远低于此阈值。6.7× stall reduction 在同步模式下意义重大，在异步模式下可能过度优化了非瓶颈环节。FlexRLHF 的 Disaggregated 策略也利用了 PPO 的 off-policy 特性——Shadow 模型参数周期性同步而非实时同步——这证明 RL 训练对权重延迟有天然的 tolerance，TensorHub 论文应讨论这一关键上下文。
Attack 2: Pipeline replication 的带宽放大被 FSDP unsharding 瓶颈抵消 (L2 §6 step 6)
论文声称 pipeline replication 将 fan-out 从单源瓶颈转为带宽放大 DAG，Figure 7(b) 证明线性 vs 二次方扩展。但 fabric-lib Table 5 揭示了隐藏瓶颈：1T 参数传输中 FSDP full_tensor() 占 42%，跨 rank 同步占 29%，RDMA submit 仅占 2.1%。如果 TensorHub 也使用类似的模型并行分片策略（论文说 "mocked 1T" 用 16 shards），那么每个 rollout worker 收到 shard 后可能还需要本地 reshape/unpack——这些本地操作不受 pipeline replication 影响。论文的 microbenchmark Figure 7(a) 使用预分配的连续 50 GB tensor，完全绕过了 real-world 的 weight layout 转换开销。端到端 standalone 实验（Figure 9）中 TensorHub 的 6.7× 优势包含三个不可分的因素：(a) RDMA vs NCCL 的传输效率差异，(b) 消除全局 barrier 的协调改善，(c) pipeline replication 的带宽放大。缺乏 fabric-lib 级别的 breakdown 使我们无法判断 pipeline replication 到底贡献了多少——也许 (a)+(b) 就足以解释 6× 以上的改善，pipeline replication 是锦上添花而非雪中送炭。
Attack 3: 中心化 reference server 的扩展性和可用性 (L2 §6 step 7)
TensorHub 的弹性和拓扑感知能力依赖中心化 reference server。论文声称 server 仅处理轻量引用元数据，但没有给出 server throughput 上限。以 1T 模型 1024 GPU 为例：16-shard model-parallel 下每个 replica 包含 16 个 worker，每个 training step 可能产生 ~64 个 replicate 事务（64 个 rollout replica × 1 次 update）、~4 个 publish 事务（4 trainer replica）、相应的 unpublish + consistency transaction。Server 使用 Ray named actor（单线程 Python），若 training step 为 10s，server 需每秒处理 ~10 个事务——在 1024 GPU 下尚可。但 frontier model training 趋势为 10K+ GPU：10× 规模下 server 每秒 ~100 事务，且每个事务涉及 replica 枚举、load-based source selection、consistency check。更严重的是 server failure：论文的 stateless recovery 设计虽优雅（所有 client 重置为 unpublished，下一轮 publish 重建），但意味着 server 故障会中断所有进行中的 pipeline replication。对 cross-DC 场景尤其致命——正在 TCP seeding 的 replica 被中断后必须从头开始，cross-DC stall 可能从 ~3s 暴涨到 seeding duration 级别。论文未测试 server failure 在 cross-DC 场景下的恢复代价。
Attack 4: ROS "无额外存储空间"忽略了 retention offload 的隐藏成本 (L2 §6 step 5)
ROS 声称满足"无额外存储空间"目标（五目标之一），因为它直接引用 GPU 上已有权重。但 retention protocol 要求：当最后一个非 spot replica 要 unpublish 时，offload 到 CPU 内存作为兜底。论文声称"极少触发"但未量化。在以下场景中 offload 可能频繁发生：(1) 快速训练循环（step time <10s）中 trainer publish 新版本后立即 unpublish 旧版本，如果慢速 rollout worker 还在 replicate 旧版本，offload 被触发；(2) elastic 场景中 spot 实例大规模被抢占，大量 replica 消失后剩余非 spot replica 要 unpublish 时必须 offload。以 1T 模型 66 GB/shard × 16 shard = ~1 TB 为例，offload 需要 PCIe 传输 ~1 TB 到 CPU memory。论文实验节点有 1800 GB CPU memory，但这个 memory 同时被 RL optimizer states（可达数百 GB for Adam）、数据 pipeline、Python/Ray runtime 竞争。fabric-lib 的分析也证实 FSDP unsharding 本身就需要大量 CPU staging memory。
Attack 5: Baseline 对比缺少关键中间方案 (L2 §6 step 9)
TensorHub 的 baseline 是 NCCL broadcast 和 UCX point-to-point（均通过 Ray driver 协调）——这是 2023-2024 年的 standard practice。但论文自身基于 Mooncake transfer engine（RDMA），存在一个未被评估的中间 baseline："Mooncake P2P direct"——不使用 ROS 抽象，直接用 Mooncake 的 RDMA Write 做点对点传输（类似 fabric-lib 的 RL weight transfer 方案）。fabric-lib 已证明这种 direct P2P 方案可达 1T 参数 1.3s（利用全集群 NIC 带宽）。如果 "Mooncake P2P direct" 也能达到类似性能，那 TensorHub 的 6.7× 优势大部分来自"RDMA 替代 NCCL"的技术选型差异，而非 ROS + pipeline replication 的抽象创新。论文需要这个中间 baseline 来分离两个贡献。此外缺少与 ByteCheckpoint（同公司的 checkpoint 系统，Table 1 提到但未评估）和 StreamRL（异步 RL 权重同步）的对比。veRL 自身的 FSDP-based weight sync 作为 TensorHub 的 "nearest neighbor" baseline 也未被单独评估。
Attack 6: 事务语义在大规模 model-parallel 下的开销 (L2 §6 step 8)
Sharding consistency 的事务语义（Figure 6）在 model-parallel 场景引入同步开销。1T 模型有 16 shard，每个 replica 的 replicate 需 16 个 worker 参与同一事务。事务中第一个 worker 的请求锁定版本视图，后续 15 个 worker 消费缓存状态。如果第一个 worker 和最后一个 worker 的 replicate 请求之间存在时间差（因 GPU 异构性、网络拥塞或 pipeline replication 的到达时间差异），事务窗口会拉长。在事务窗口期间，trainer 要 unpublish 该版本必须等待（因为 unpublish 需要 drain 进行中传输 + 事务中的所有 worker 完成）。论文 microbenchmark 用 1:1 source:target（Figure 7a），不能展示 16-shard × 多 replica 下的事务争用行为。DualPath 的 closed-form 分析（Eq. 1-9）在类似的并发场景下给出了 bottleneck-free 区间——TensorHub 缺乏同等的形式化分析来保证在给定 shard 数、replica 数和网络拓扑下事务不会成为新瓶颈。
范式定位：TensorHub 代表 RL 训练基础设施从"搬运数据"到"引用数据"的范式转变。传统 parameter server、NCCL broadcast、Ray object store 都遵循"数据所有权"模型——数据必须被序列化、复制、存储到某处，接收方从该处取回。ROS 消除了所有权概念：数据始终在原地（GPU HBM），只是注册了一个轻量引用允许远端 RDMA 直读。publish 的语义从"把数据推到 store"变成"把地址告诉 server"——这是一个类似 RDMA 对 TCP 的革命性简化：不是在旧抽象上优化传输效率，而是消除了传输的必要性本身。Pipeline replication 进一步放大了这个范式：每个 replica 既是消费者又是生产者，数据"涟漪式扩散"而非"广播式分发"。
ByteDance RL 生态集成：TensorHub 的依赖栈由三层组成：
相比 DualPath 对 DeepSeek 内部组件（3FS、FlashMLA、DeepGEMM、DeepEP）的深度绑定，TensorHub 的依赖栈对外部团队显著更友好——三个依赖全部已开源。论文估计外部复现核心思想 ~2K 行代码，关键壁垒是 pipeline replication 的并发控制（progress counter 原子性、partial-replica 故障恢复、tiny-tensor compaction 的 zero-copy 解包），而非生态锁定。
采纳信号：
竞争方案生态位对比：
| 生态位 | 方案 | TensorHub 相对优势 | TensorHub 相对劣势 |
|---|---|---|---|
| RL 权重同步 | NCCL broadcast | 消除全局 barrier + trainer stall + elastic 支持 | NCCL 更简单、通用、已有完善工具链 |
| RDMA P2P 传输 | fabric-lib direct P2P | Pipeline replication DAG 带宽放大 + 全局调度 | fabric-lib 跨 vendor（EFA+CX）且已开源 |
| 分布式存储 | Ray object store | 160× 更快（RDMA vs serialize-deserialize） | Ray 不需要 RDMA 硬件 |
| 弹性训练 | Elastic Horovod/NCCL | Spot churn 无 barrier + server stateless recovery | Elastic NCCL 不需要中心化 server |
| 跨 DC 训练 | TCP direct | Smart skipping + offload seeding 减 19× stall | TCP 不需要 RDMA 基础设施 |
| RL 编排层 | veRL native | 垂直集成、互补 | TensorHub 是 veRL 的可选 plugin，非必需 |
| Rollout 推理 | ThunderAgent | 正交互补——可叠加 | 不优化推理调度和 KV-cache 管理 |
定位判断：TensorHub 在同步 RL 训练、大模型（>100B）、大规模 rollout（>100 GPU）的交集场景下价值最大——此时 NCCL broadcast 的全局 barrier 和 straggler 放大效应导致数千秒级 stall，TensorHub 的 ROS + pipeline replication 可将其压缩到数百秒级。对外部团队的价值主要在三个可移植设计思想：(1) ROS 的无所有权引用——可在任何 P2P 通信层上实现；(2) pipeline replication 的 DAG 带宽放大——利用 RDMA 全双工的通用原理；(3) reference server 的轻量全局视图——实现拓扑感知和弹性而不引入全局 barrier。这三个思想的外部价值不依赖 ByteDance 的具体实现，可在 fabric-lib + veRL/OpenRLHF 上渐进式实现。
方向 1: TensorHub + ThunderAgent 联合优化 RL 循环。当前 RL 循环中 TensorHub 优化 trainer→rollout 权重传输，ThunderAgent 优化 rollout 内的 LLM 推理调度，两者独立运行。但存在协同空间：TensorHub 的 pipeline replication 使不同 rollout worker 在不同时间完成权重更新——worker A 完成 replicate 可立即开始推理，而 worker B 还在等待。如果 ThunderAgent 的 global waiting queue 能订阅 TensorHub 的 progress counter 事件，就可以实现"权重到达即推理"的细粒度流水线：worker A 完成后 ThunderAgent 立即分配新 workflow，无需等待全部 worker 就绪。具体实现：TensorHub 的 reference server 在 replica 注册为新 source 时发出事件→ThunderAgent scheduler 收到后将该 worker 标记为 "ready for version N+1"→新 agentic program 被路由到该 worker。这将 pipeline replication 的"增量就绪"特性暴露给调度层，有望进一步削减 RL 的 weight update bubble。
方向 2: ROS 抽象扩展到 KV-Cache 传输。TensorHub 的 ROS 为 RL 权重设计，但其核心设计假设（数据高度复制、计算期间不可变、短生命期）在 PD 分离推理的 KV-Cache 中同样成立——agentic workload 的 KV-Cache 在 prefill 完成后不可变（只追加新 token 的 KV），DualPath 报告 98.7% 命中率意味着同一 KV-Cache 被多次引用，生命期由 decode 完成决定。如果把 DualPath 的 KV-Cache 管理替换为 ROS——prefill 完成后 publish KV 引用，decode engine 通过 replicate 获取——ROS 的 reference server 自动做 least-loaded 调度（无需 DualPath 的三级分类 scheduler），pipeline replication 甚至可以让已获取 KV-Cache 的 decode engine 向其他 PE 提供服务（DualPath 未探索的"decode engine 互帮互助"模式）。关键挑战：KV-Cache 比权重大得多（数百 GB for 64K context）且更新频率更高（每 64 token 写一次），ROS 的 mutability contract 需要适配 append-only 语义。
方向 3: 基于 fabric-lib 的可移植 TensorHub。TensorHub 使用 Mooncake transfer engine，Mooncake 不支持 AWS EFA。fabric-lib 的 TransferEngine 提供跨 ConnectX-7 和 EFA 的统一抽象（ImmCounter + reliable-but-unordered）。将 TensorHub 的 ROS client library 构建在 fabric-lib 之上可使 TensorHub 从 ConnectX-only 扩展到云原生 RDMA。关键技术契合点：pipeline replication 需要 polling progress counter 的低延迟机制——fabric-lib 的 WriteImm + ImmCounter 天然支持（每个 tensor chunk 传输完成后 ImmCounter 递增，downstream worker poll ImmCounter 判断 prefix 就绪程度）。fabric-lib 的 UVM Watcher 甚至可以实现 CUDA-graph-compatible 的 progress tracking。fabric-lib 在 RL 权重传输场景已达 1T 参数 1.3s——在此之上叠加 TensorHub 的 pipeline replication 和 ROS 全局调度，有望在 EFA 上也实现线性扩展的带宽放大。
方向 4: 异步 RL 下的 version-aware pipeline。TensorHub 的 smart skipping 允许 rollout 跳过正在 seeding 的版本。更激进的设计是 version-aware pipeline：不同 rollout worker 同时获取不同版本的权重——worker A 正在用 version N 做 rollout，worker B 在获取 version N+1，worker C 在获取 version N+2。ROS 的 retention protocol 天然支持保留最近 k 个版本。结合异步 RL 的 staleness tolerance，version-aware pipeline 可消除所有权重更新等待——每个 worker 总在获取"自己能用的最新版本"，trainer 永远不 stall，rollout 永远不 stall。FlexRLHF 的 Shadow Model periodic sync 和 TensorHub 的 smart skipping 都是这个方向的初步探索，但未走到"完全异步 multi-version pipeline"。关键设计问题：(a) retention 策略需平衡版本多样性和 GPU memory（保留 k 个版本需 k 倍 GPU memory），(b) RL 算法对 staleness 的 tolerance 需要形式化建模——PPO 的 clipped objective 对旧策略有天然约束，GRPO 更宽松。
方向 5: 形式化 pipeline replication 吞吐模型。TensorHub L2 §4 明确指出缺乏 pipeline replication 的 $T(N)$ 闭合表达式。DualPath 的 Eq. 1-9 为 dual-path 操作区间提供了完整的 closed-form 分析——类似的形式化对 TensorHub 至关重要。一个可行的模型：给定 $N$ 个 rollout worker 同时请求 shard 大小 $S$、NIC 带宽 $B$、pipeline 并发深度 $k$（每个 source 同时服务的最大 requester 数），completion time 近似为 $T(N) = S/B + \lceil (N-1)/k \rceil \cdot S/B$。结合 Mooncake RDMA 88% 实际效率（Figure 7a），可推导给定 $N$、$S$、$B$、$k$ 下的 stall time 上界。进一步引入 shard consistency 的事务窗口 $\Delta_{\text{txn}}$ 和 retention offload probability $p_{\text{off}}$，可以得到端到端的 stall time 期望和尾部分布——指导 production 部署的 trainer:rollout 比例和 retain 策略选择。
方向 6: 分层 ROS — GPU + DRAM + SSD 权重存储。当前 ROS 假设权重始终在 GPU HBM（publish 注册 GPU memory reference）。但 1T+ 模型的 ZeRO-Offload 将 optimizer states 和部分权重 offload 到 CPU DRAM 是常见实践。扩展 ROS 到多层存储：GPU 上的 hot weight shard（RDMA Direct 零拷贝）→ DRAM 上的 warm offload copy（DMA + RDMA 二跳）→ SSD 上的 cold checkpoint（io_uring + RDMA 三跳）。publish 可注册任意层级的 reference，replicate 时自动选择最快可用源——peer GPU 有 hot copy 则直接 RDMA Read，只有 DRAM copy 则 H2D→RDMA 两跳。TensorHub 的 retention protocol offload 已涉及 GPU→DRAM 降级，DualPath 的 3FS 存储层提供了 SSD 级别的参考。将两者统一：ROS 成为跨 HBM→DRAM→SSD→distributed storage 的通用引用存储层，retention 策略控制数据在各层的生命期——hot→warm→cold 的自然降级路径。