假设与建议

有一些假设，如果没有这些假设，本协议的保证将不再成立。

• 状态机复制以类似于领导者（例如 Raft）的共识协议的机制进行。领导者 **lighthouse** 是单点故障，因此用户应确保将其运行在专用实例上，以避免“吵闹的邻居”引起的故障，并进行自动重启以最大化可用性。

• lighthouse 根据哪些副本健康来动态更改副本成员，并仅对健康的副本集执行法定人数。

  • 此重新配置只有在一个副本最终与两个成员身份重叠时才是安全的。我们目前在 **lighthouse** 上有一个 join_timeout_ms 标志，以增加来自先前成员的副本加入的可能性。

  • 如果存在多个 **lighthouse** 实例且副本连接到不同的实例，则可能达到两个不同的法定人数，因为每个 lighthouse 实例的成员身份都不同。因此，请确保副本连接到同一个 lighthouse 实例。通过将 min_replicas 设置为至少与副本的大多数一样多，也可以避免脑裂（尽管来自先前成员的大多数也应该能够连接到与当前成员身份相同的 lighthouse 实例，以便发生重叠）。

• min_replicas 设置还确定了在最坏情况下 **DDP** 的梯度将平均多少批次。因此，将其设置为一个合理的值以减小模型参数更新中的方差。

• 如果对 **quorum** 的调用超时，副本会崩溃，因此它会被排除在成员组之外，并且将无法参与共识。与共识的典型情况一样，我们需要大多数副本保持健康。在某些情况下，这些超时会导致级联故障，从而导致大多数副本崩溃。总的来说，我们建议将 **manager** 上的 quorum_timeout 设置为一个较高的值，足以让所有进程在需要同步（或使用 **DiLoCo** 或 **LocalSGD** 时的 sync_every 步）后完成训练。

• 同样，manager 上的 timeout 设置也应该足够高，以考虑 **FSDP** 副本完成步骤的可变性。

• 使用 **NCCL** 时，**ProcessGroupNCCL** 为 **FSDP** 发出的集体操作可能会导致死锁（已知问题），从而导致训练进程被终止。

  • 确保这不会发生在大多数副本上，或者尝试为 **DDP** 使用不同的进程组，例如 **Gloo**。

  • 将 TORCH_NCCL_HEARTBEAT_TIMEOUT_SEC 设置得比 quorum_timeout 低，以便进程可以在法定人数超时之前恢复。由 **DDP** 操作发出的操作的超时时间由 timeout 设置确定，因此请确保 quorum_timeout 也大于该值。

• 对 **DiLoCo** 的支持目前处于 alpha 阶段 – 该实现尚未在大规模下进行测试。