主要区别之一是 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 可能会更具吸引力。