【问题标题】:When is TensorFlow's ParameterServerStrategy preferable to its MultiWorkerMirroredStrategy?TensorFlow 的 ParameterServerStrategy 何时优于其 MultiWorkerMirroredStrategy?
【发布时间】:2020-12-02 01:58:52
【问题描述】:

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

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

【问题讨论】:

    标签: tensorflow tensorflow2.0 distributed-computing


    【解决方案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),并要求他们在文档中添加用例以使其更清晰。