TensorFlow 的 ParameterServerStrategy 何时优于其 MultiWorkerMirroredStrategy？

Posted 2023-02-23

【中文标题】TensorFlow 的 ParameterServerStrategy 何时优于其 MultiWorkerMirroredStrategy？

【英文标题】：When is TensorFlow's ParameterServerStrategy preferable to its MultiWorkerMirroredStrategy?

【发布时间】：2020-12-02 01:58:52

【问题描述】：

在跨多个服务器和 GPU 训练神经网络时，我想不出ParameterServerStrategy 比MultiWorkerMirroredStrategy 更可取的场景。

ParameterServerStrategy 的主要用例是什么？为什么它比使用MultiWorkerMirroredStrategy 更好？

【参考方案1】：

MultiWorkerMirroredStrategy 用于跨多个工作人员的同步分布式训练，每个工作人员可以有多个 GPU

ParameterServerStrategy：支持参数服务器。可用于多GPU同步本地训练或异步多机训练。

主要区别之一是 ParameterServerStrategy 可用于异步训练，而 MultiWorkerMirroredStrategy 用于同步分布式训练。在 MultiWorkerMirroredStrategy 中，模型中所有变量的副本保存在所有工作人员的每个设备上，并且需要一种通信方法来保持所有变量同步。相反，在 ParameterServerStrategy 中，模型的每个变量都放在一个参数服务器上。

这很重要，因为：

在同步训练中，所有工作人员在训练时期和步骤方面保持同步，其他工作人员需要等待失败或被抢占的工作人员重新启动才能继续。如果失败或被抢占的工作人员由于某种原因没有重新启动，您的工作人员将继续等待。

与 ParameterServerStrategy 相比，每个 worker 独立运行相同的代码，但参数服务器运行的是标准服务器。这意味着虽然每个工作人员将在所有 GPU 上同步计算单个梯度更新，但工作人员之间的更新是异步进行的。仅在第一个副本上发生的操作（例如递增全局步骤）将在每个工作人员的第一个副本上发生。因此，与 MultiWorkerMirroredStrategy 不同的是，不同的 worker 不会相互等待。

我想问题是，您是否认为工人会失败，并且在 MultiWorkerMirroredStrategy 时延迟重新启动他们会减慢培训速度吗？如果是这样的话，也许 ParameterServerStrategy 更好。

编辑： cmets 中问题的答案：

PSS 的唯一好处是它可以更好地抵抗 比 MWMS 更失败的工人？

不完全是 - 即使工作人员在 MWMS 中没有失败，因为工作人员仍然需要同步，但可能存在网络瓶颈。

如果是这样，那么我想它只会在对许多人进行培训时才有用 工人，说 20 或更多，或者工人将 训练期间的失败率很低（可以通过定期保存来避免 快照）。

也许不是，这取决于情况。也许在您的情况下，失败的可能性很低。在其他人的情况下，可能会有更高的概率。对于相同数量的工人，工作时间越长，工作中发生故障的可能性就越大。为了进一步说明（用一个过于简单的例子），如果我有相同数量的节点，但它们只是速度较慢，它们可能需要更长的时间来完成一项工作，因此在此期间发生任何类型的中断/故障的可能性更大工作。

（可以通过保存常规快照来避免）。

不确定我理解您的意思 - 如果工作人员失败，并且您保存了快照，那么您并没有丢失数据。但是工人仍然需要重新启动。在失败和重新启动之间的过渡期间，其他工作人员可能正在等待。

I/O 饱和难道没有可能的好处吗？如果更新是 异步的，I/O 会在时间上更加分散，对吧？但也许 这个好处被它使用更多的 I/O 所抵消了？您可以...吗 请详细说明一下？

我先尝试从概念的角度来回答。

我会说尝试从不同的角度看待它 - 在同步操作中，您正在等待其他事情完成，并且您可能会闲置直到某件事为您提供所需的东西。 相比之下，在异步操作中，您做自己的工作，当您需要更多工作时，您会提出要求。

对于同步操作或异步操作哪个更好，没有硬性规定。视情况而定。

我现在尝试从优化的角度来回答：

I/O 饱和难道没有可能的好处吗？如果更新是 异步的，I/O 会在时间上更加分散，对吧？但也许 这个好处被它使用更多的 I/O 所抵消了？您可以...吗 请详细说明一下？

在分布式系统中，您的瓶颈可能是 CPU/GPU、磁盘或网络。现在网络真的很快，在某些情况下比磁盘还快。根据您的工人配置 CPU / GPU 可能是瓶颈。所以这真的取决于你的硬件和网络的配置。

因此，我会进行一些性能测试，以确定您系统的瓶颈所在，并针对您的具体问题进行优化。

编辑：其他后续问题：

最后一件事：根据您的经验，PSS 在哪些用例中使用？一世 意思是，PSS 和 MWMS 显然都适用于大型数据集（或 否则一台机器就足够了），但是模型呢？将 PSS 更适合大型模型？根据您的经验，MWMS 是否更多 经常使用？

我认为成本和正在解决的问题类型可能会影响选择。例如，AWS 和 GCP 都提供“现货实例”/“抢占式实例”，它们是可以随时取走的大幅折扣服务器。在这种情况下，使用 PSS 可能是有意义的——即使机器故障不太可能发生，一个实例可能会在没有通知的情况下被简单地拿走，因为它是一个“现场实例”。如果使用 PSS，那么服务器消失对性能的影响可能没有使用 MWMS 时那么大。 如果您使用的是专用实例，这些实例是专用于您的，不会被带走——唯一的中断风险是机器故障。在这种情况下，如果您可以利用性能优化或插件架构，MWMS 可能会更具吸引力。

【讨论】：

@MiniQuark 我更新了我的答案以尝试回答您的后续问题，以便更好地格式化它。

啊，谢谢，我删除了我的评论以使其更清楚，但您已经在并行回答。很清楚。最后一件事：根据您的经验，PSS 在哪些用例中使用？我的意思是，PSS 和 MWMS 显然都适用于大型数据集（否则单台机器就足够了），但是模型呢？ PSS 会更适合大型模型吗？根据您的经验，MWMS 的使用频率更高吗？

再次感谢。如果你不介意，我会在截止日期前开放赏金，让其他人有机会回答。感谢您的精彩回答！

一点也不。您甚至可以考虑查找这些标签的热门人并邀请他们回答。

@MiniQuark - 我认为标记某人只有在他们已经是讨论的一部分时才有效，所以 Marco-cerliani 和 mrry 可能不会看到你的问题。你应该在他们的讨论上标记 + 评论是查看您的消息的一部分（我已要求他们查看此问题）。你也可以考虑在 tensorflow 文档论坛上发帖，例如 (groups.google.com/a/tensorflow.org/forum/#!forum/docs)，并要求他们在文档中添加用例以使其更清晰。