mirror of
https://github.com/openmlsys/openmlsys-zh.git
synced 2026-04-13 18:11:09 +08:00
change content in chapter 10 parameter server (#194)
Co-authored-by: Luo Mai <luo.mai.cs@gmail.com>
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
## 参数服务器
|
||||
|
||||
接下来,我们介绍另一种常见的分布式训练系统实现:参数服务器。TensorFlow原生提供了参数服务器的实现。而其他框架,例如PyTorch和MindSpore,则需要用户使用第三方的参数服务器实现,例如PS-Lite。
|
||||
接下来,我们介绍另一种常见的分布式训练系统实现:参数服务器。常见的深度学习框架以不同方式提供了参数服务器。TensorFlow和MindSpore原生提供了参数服务器的实现;PyTorch需要用户使用框架提供的Rpc接口自行实现;还有一些框架则需要用户使用第三方的参数服务器实现,例如PS-Lite。
|
||||
|
||||
### 计算和存储分离
|
||||
|
||||
@@ -40,8 +40,8 @@ distribution),这会导致部分稀疏参数在训练过程中被访问的
|
||||
|
||||
解决数据热点问题的关键是利用在没有副本的情况下,通用的做法是每隔一段时间将所有参数在外存中保存一份检查点(checkpoint)。当出现机器故障时,首先所有的训练必须停止,等待故障的机器恢复上线,然后从外存中重新加载检查点。这就会导致从上一次保存检查点到故障发生时的数据全部丢失。保存一次检查点的开销随模型大小而增加,训练大模型时通常每隔1-2小时保存一次。因此无副本的参数服务器如果发生故障,会丢失最多1-2小时的数据。
|
||||
|
||||
解决参数服务器故障和数据热点问题的常用技术是构建模型主从副本。(Master-slave
|
||||
replication)。一份参数在多个机器上拥有副本,并指定其中一个副本作为主副本。训练服务器的所有更新操作都向主副本写入并同步至从副本上。如何取得共识确定哪一个副本是主副本是分布式系统领域一个经典问题,已经有了相当多的成熟的算法,例如Paxos和Raft。此外,主副本上的更新如何复制到从副本上也同样是分布式系统领域的经典共识问题。通常系统设计者需要在可用性(Availability)和一致性(Consistency)之间做出取舍。如果参数服务器副本间采用强一致性的复制协议(例如,链式副本(Chain replication)))则可能导致训练服务器的推送请求失败,即参数服务器不可用。反之,如果参数服务器采用弱一致性的复制协议,则可能导致副本间存储的参数不一致。
|
||||
解决参数服务器故障和数据热点问题的常用技术是构建模型主从副本(Master-slave
|
||||
replication)。一份参数在多个机器上拥有副本,并指定其中一个副本作为主副本。训练服务器的所有更新操作都向主副本写入并同步至从副本上。如何取得共识确定哪一个副本是主副本是分布式系统领域一个经典问题,已经有了相当多的成熟的算法,例如Paxos和Raft。此外,主副本上的更新如何复制到从副本上也同样是分布式系统领域的经典共识问题。通常系统设计者需要在可用性(Availability)和一致性(Consistency)之间做出取舍。如果参数服务器副本间采用强一致性的复制协议(例如,链式副本(Chain replication))则可能导致训练服务器的推送请求失败,即参数服务器不可用。反之,如果参数服务器采用弱一致性的复制协议,则可能导致副本间存储的参数不一致。
|
||||
|
||||
### 掉队者问题
|
||||
|
||||
@@ -49,6 +49,6 @@ replication)。一份参数在多个机器上拥有副本,并指定其中一
|
||||
training)。同步训练一般会有助于训练系统达到更好的模型精度,但是当系统规模变大,我们往往会在系统中引入掉队者(Straggler)。掉队者出现的原因很多。常见的原因包括:掉队者设备可能和其他设备不在同一个机柜中,因此掉队者的通讯带宽显著小于其他设备。另外,掉队者设备也可能和其他进程共享本地的服务器计算和通讯资源,形成资源竞争,从而降低了性能。
|
||||
|
||||
掉队者对于基于Allreduce的同步训练系统的性能有显著影响,这是因为Allreduce让全部节点参与到平均梯度的计算和通讯中,而每个节点负责等量的数据。因此任何一个掉队者的出现,都会让整个Allreduce操作延迟完成。为了解决这个问题,人们也会使用参数服务器来计算平均梯度。一种常见的设计是:训练服务器训练出本地梯度后,会把本地梯度全部推送到参数服务器。参数服务器在等到一定数据训练服务器(例如说90%的训练服务器)的本地梯度后,就开始计算平均梯度。这样可以确保平均梯度的计算不会被落后者的出现延误。计算好的平均梯度马上推送给全部训练服务器,开始下一轮训练。
|
||||
0
|
||||
|
||||
解决掉队者的另外一种常见做法是利用参数服务器实现**异步训练**(Asynchronous
|
||||
training)。在一个异步训练系统中,每个训练服务器在训练开始时,有相同的模型参数副本。在训练中,他们计算出本地梯度后会马上将本地梯度推送到参数服务器,参数服务器将推送的梯度立刻用于更新参数,并把更新好的参数马上推送回对应的训练服务器。在这个过程中,不同的训练服务器很可能会使用不同版本的模型参数进行本地梯度的计算,这种做法有可能会伤害模型的精度,但它同时让不同训练服务器可以按照各自的运算速度来推送和拉取参数,而无需等待同伴,因此避免了掉队者对于整个集群性能的影响。
|
||||
Reference in New Issue
Block a user