调研报告：Off-policy rollout 应该使用哪个 Actor？——Holosoma FastSAC 与 UniLab 的实践

[TATP-233]

摘要

这个问题表面上是“rollout 要不要把 actor D2D 一遍”，实际包含两个独立问题：

1. 算法语义：off-policy 是否要求采样策略永远等于 learner 中刚更新完的策略？
2. 系统所有权：rollout 与 learner 是否持有同一个 actor 对象、处于同一进程和同一设备？

结论是：

• Off-policy 允许 replay buffer 中的数据来自旧的行为策略，因此 rollout actor 可以有有限滞后；但“允许滞后”不等于滞后没有代价。
• 是否复制 actor 不是 SAC 理论本身决定的，而是由进程、设备和并发边界决定。
• Holosoma FastSAC 的 rollout 与优化器直接共享同一个 self.actor，不需要常规 actor 参数拷贝。
• UniLab 当前 off-policy runner 的 collector 是独立进程并持有独立 actor，因此必须同步权重；当前 CUDA collector 的实现是 learner 参数写入 CPU shared-memory snapshot，再由 collector 做 H2D 和设备内 apply，严格说不是 learner GPU 到 collector GPU 的直接 D2D。
• SAC 的 target critic 用于 bootstrap 稳定性，不是 rollout actor，也不意味着需要 target actor。

本文只做理论澄清和当前代码审计，不提出新的 execution path，也不在缺少 benchmark 的情况下主张替换 UniLab 的同步协议。

一、理论上：行为策略、当前策略和目标网络是三件事

记：

• μ：执行 rollout、生成 transition 的行为策略；
• πθ：learner 正在优化的当前 actor；
• Qφ̄：用于 critic bootstrap 的 target critic。

Replay buffer 中的 transition 可以来自历史策略：

(s, a, r, s′) ~ μ

SAC 更新 critic 时，stored action a 来自 replay；bootstrap 的 next action 则由当前策略采样：

a′ ~ πθ(· | s′)
y = r + γ (Qφ̄(s′, a′) - α log πθ(a′ | s′))

因此 SAC 不要求 μ 与当前 πθ 完全相同，也不要求每做一次梯度更新就立刻阻塞所有 collector。Replay 本身就包含多版本行为策略产生的数据。

但 policy lag 仍然会改变数据分布。滞后过大时，可能出现：

• replay 中新数据与当前策略访问分布差距增大；
• critic 对当前 actor 所需区域的数据覆盖变差；
• learner 吞吐增加，但 sample efficiency 或训练稳定性下降。

所以同步频率是吞吐、策略新鲜度和一致性之间的工程权衡，而不是“off-policy 所以永远不用同步”。

二、什么时候需要 actor 副本

架构	Rollout 使用什么	是否需要参数同步
同进程、同设备、串行 collect/update	同一个 actor 对象	不需要
独立进程，即使在同一 GPU	collector 自己的 actor 实例	需要 IPC/共享快照等机制
learner GPU 与 rollout GPU 分离	rollout GPU 上的 actor replica	需要跨设备发布
异步 actor-learner	最近一次收到的 actor version	需要周期同步，并接受可控 lag

关键判断不是“是不是 off-policy”，而是：参数存储是否由 rollout 和 optimizer 共同拥有。

三、Holosoma FastSAC 代码审计

审计基线：amazon-far/holosoma@6e146b0。

1. Rollout 与优化器是同一个 actor

在 setup 中，actor 直接创建在训练 device 上；随后：

self.policy = self.actor.explore
self.actor_optimizer = AdamW(self.actor.parameters(), ...)

证据：fast_sac_agent.py#L266-L332。

self.policy 是 self.actor.explore 的绑定方法，而 optimizer 持有同一个 self.actor.parameters()。这里没有第二个 rollout actor。

2. 每轮先 collect，再更新；下一轮自然看到新参数

训练循环先在 torch.no_grad() 下调用 policy(...)，执行一个 vectorized env step并写入 replay，然后执行若干 critic/actor updates：

证据：fast_sac_agent.py#L650-L775。

由于 collect 和 update 串行访问同一参数存储，下一轮 rollout 自动读取更新后的 actor，不存在“learner actor 再拷给 rollout actor”的步骤。

Rollout 使用的是 SAC 随机策略而非确定性均值，且 explore 本身带 @torch.no_grad()：fast_sac.py#L125-L146。

3. 有 target critic，没有 target actor

Holosoma 创建并 Polyak 更新 qnet_target，但没有为 rollout 创建 actor target/snapshot。这个 target critic 只服务 Bellman bootstrap：fast_sac_agent.py#L303-L317、fast_sac_agent.py#L770-L774。

4. 多 GPU 也不是每轮复制 rollout actor

每个 rank 在本地 GPU 上持有 actor 和环境。初始化时从 rank 0 broadcast 参数，训练时 all-reduce gradients，各 rank 的 optimizer 随后得到一致更新：fast_sac_agent.py#L354-L401。

因此它是同步数据并行下的本地共享 actor，不是独立 actor-learner 系统中的周期 D2D rollout replica。

四、UniLab 当前实践：独立 collector 必须同步 actor

审计基线：unilabsim/UniLab@e326847。

UniLab 的架构边界与 Holosoma 不同。

1. Learner 建立版本化 shared-memory snapshot

DoubleBufferOffPolicyRunner 根据 learner actor 的 state dict 建立 SharedWeightSync，然后 spawn 独立 collector：

• double_buffer_runner.py#L264-L266
• double_buffer_runner.py#L324-L361

因此 collector 不可能直接引用 learner 进程中的 Python actor 对象。

2. Collector 构造自己的 actor

Collector 在 collector_infer_device 上重新构造 actor，并从 snapshot 加载初始权重：worker.py#L282-L315。

运行中它检查 snapshot version；发现新版本后才 apply 到本地 actor：worker.py#L343-L359。

所以 UniLab rollout 使用的是 collector_actor(version=v)，而不是 optimizer 正在原地修改的 learner.actor。

3. 权重在 learner 更新后发布

Learner 完成一轮 critic/actor updates 后调用：

weight_sync.write_weights(self.learner.actor.state_dict())

证据：double_buffer_runner.py#L626-L699。

sync_collection 控制 collector/learner 的阶段协调；它不表示双方共享同一个 actor 参数对象。Double buffering 仍允许 collection 与 learning 重叠，因此也不应把它简单理解成“每一个 action 都严格使用刚完成的 learner update”。

4. 当前传输路径不是直接 D2D

SharedWeightSync.write_weights 对 learner tensor 执行 detach().cpu().numpy()，写入 CPU shared memory：weight_sync.py#L64-L86。

CUDA collector 使用持久化 pinned-host/device staging：先复制 shared-memory snapshot，再做一次 flat H2D，最后在设备内 apply 到 actor tensors：weight_sync.py#L161-L232。

因此当前路径可概括为：

learner actor (GPU)
  -> CPU shared-memory snapshot
  -> collector staging (pinned host)
  -> collector device actor

如果 collector 在 CPU，则是 shared-memory 到 CPU actor 的 copy；如果 collector 在 accelerator，则存在 H2D。是否值得改成 CUDA IPC、P2P 或其他路径，必须由 profile/benchmark 证明，不能仅凭“看起来多拷了一次”下结论。

默认 SAC 配置选择 accelerator collector、env_steps_per_sync: 1：conf/offpolicy/algo/sac.yaml#L1-L23。

五、直接回答原问题

问题	Holosoma FastSAC	UniLab off-policy runner
Rollout 用训练 actor 吗？	是，同一个 self.actor 对象	语义上来自 learner actor，但物理上是 collector 本地 replica
每轮需要 actor D2D 吗？	不需要，没有独立 rollout replica	需要发布/应用权重；当前实现是 shared memory +（CUDA collector 时）H2D，不是直接 D2D
Rollout 一定使用绝对最新参数吗？	下一轮串行 rollout 使用刚更新后的共享参数	使用 collector 已应用的最新 snapshot version，允许架构定义的 lag
Target critic 是 rollout 网络吗？	不是	不是
是否需要 target actor？	SAC 本身不需要	不应仅为 rollout 同步而引入 target actor

六、对 UniLab 的建议

这次审计没有发现“理论上必须改成共享 actor”这样的结论。相反，当前 actor replica 是独立进程 contract 的自然结果。更值得明确的是可观测性和术语：

1. 文档中区分 learner actor、collector actor replica、target critic。
2. 明确 sync_collection 是阶段调度语义，不是参数对象共享或零 policy lag 的承诺。
3. 如果后续诊断收敛或性能，优先记录 published_policy_version、collector_policy_version、version lag 和 weight-sync wall time。
4. 只有 profile 表明权重发布是实质瓶颈时，才讨论 CUDA IPC/P2P/D2D；同时评估跨平台、进程隔离、生命周期和一致 snapshot 的永久维护成本。
5. 如果未来新增真正的同进程同步 runner，则可以共享 actor 并省掉 snapshot；但这属于新的 execution path，需要单独决策，不能作为本讨论的顺手改造。

希望后续讨论聚焦两个可验证问题：当前训练中 policy-version lag 的实际分布是多少，以及 weight sync 在端到端 step time 中占比多少。二者都应先测量，再决定是否需要架构变化。