PyTorch教程-13.7。参数服务器

随着我们从单个 GPU 转移到多个 GPU，再转移到包含多个 GPU 的多台服务器，可能都分布在多个机架和网络交换机上，我们的分布式和并行训练算法需要变得更加复杂。细节很重要，因为不同的互连具有非常不同的带宽（例如，NVLink 可以在适当的设置下跨 6 个链路提供高达 100 GB/s 的速度，PCIe 4.0（16 通道）提供 32 GB/s，而即使是高速 100GbE 以太网也只能达到到 10 GB/秒）。同时，期望统计建模师成为网络和系统方面的专家是不合理的。

Smola 和 Narayanamurthy ( 2010 )在分布式潜变量模型的背景下引入了参数服务器的核心思想 。随后在Ahmed等人中描述了推拉语义。( 2012 )以及Li等人对系统和开源库的描述 。（2014 年）。在下文中，我们将激励效率所需的组件。

13.7.1。数据并行训练

让我们回顾一下分布式训练的数据并行训练方法。我们将使用它来排除本节中的所有其他内容，因为它在实践中实施起来要简单得多。由于现在 GPU 有足够的内存，因此几乎没有任何用例（除了图上的深度学习）首选任何其他并行策略。图 13.7.1描述了我们在13.5 节中实现的数据并行的变体 。其中的关键方面是在将更新的参数重新广播到所有 GPU 之前，梯度的聚合发生在一个 GPU (GPU 0) 上。

图 13.7.1左：单 GPU 训练。右图：多 GPU 训练的一种变体：(1) 我们计算损失和梯度，(2) 所有梯度都聚集在一个 GPU 上，(3) 发生参数更新并将参数重新分配给所有 GPU。

回想起来，在 GPU 0 上聚合的决定似乎是临时的。毕竟，我们还不如聚合在 CPU 上。事实上，我们甚至可以决定在一个 GPU 上聚合一些参数，在另一个 GPU 上聚合一些其他参数。只要优化算法支持这一点，就没有我们不能这样做的真正原因。例如，如果我们有四个具有相关梯度的参数向量 g1,…,g4我们可以在一个 GPU 上聚合梯度gi (i=1,…,4).

这种推理似乎是武断和轻率的。毕竟，数学自始至终都是一样的。然而，我们正在处理真实的物理硬件，其中不同的总线具有不同的带宽，如第 13.4 节所述 。考虑一个真实的 4 路 GPU 服务器，如图13.7.2所示。如果连接特别好，它可能有 100 GbE 网卡。更典型的数字在 1–10 GbE 范围内，有效带宽为 100 MB/s 至 1 GB/s。由于 CPU 的 PCIe 通道太少而无法直接连接到所有 GPU（例如，消费级 Intel CPU 有 24 条通道），我们需要一个 多路复用器。CPU 在 16x Gen3 链路上的带宽为 16 GB/s。这也是每个人的速度GPU 连接到交换机。这意味着设备之间的通信更加有效。

图 13.7.2一个 4 路 GPU 服务器。

为了论证，我们假设梯度为 160 MB。在这种情况下，将梯度从所有剩余的 3 个 GPU 发送到第四个 GPU 需要 30 毫秒（每次传输需要 10 毫秒 = 160 MB / 16 GB/s）。再加上 30 毫秒来传回权重向量，我们总共需要 60 毫秒。如果我们将所有数据发送到 CPU，我们会受到 40 毫秒的惩罚，因为四个 GPU 中的每一个都需要将数据发送到 CPU，总共需要 80 毫秒。最后假设我们能够将梯度分成 4 个部分，每个部分 40 MB。现在我们可以同时在不同的 GPU 上聚合每个部分因为 PCIe 交换机在所有链路之间提供全带宽操作。这需要 7.5 毫秒而不是 30 毫秒，同步操作总共需要 15 毫秒。简而言之，根据我们同步参数的方式，同一操作可能需要 15 毫秒到 80 毫秒不等。 图 13.7.3描述了交换参数的不同策略。

图 13.7.3参数同步策略。

请注意，在提高性能方面，我们还有另一种工具可供使用：在深度网络中，需要一些时间来计算从顶部到底部的所有梯度。即使我们仍在忙于为其他参数组计算梯度，我们也可以开始同步某些参数组的梯度。 有关如何在 Horovod中执行此操作的详细信息，请参见例如Sergeev 和 Del Balso ( 2018 )。

13.7.2。环同步

当谈到现代深度学习硬件上的同步时，我们经常会遇到大量定制的网络连接。例如，AWS p3.16xlarge 和 NVIDIA DGX-2 实例共享图 13.7.4的连接结构。每个 GPU 通过 PCIe 链路连接到主机 CPU，该链路最高运行速度为 16 GB/s。此外，每个 GPU 还有 6 个 NVLink 连接，每个连接都能够双向传输 300 Gbit/s。这相当于每个链接每个方向大约 18 GB/s。简而言之，总 NVLink 带宽明显高于 PCIe 带宽。问题是如何最有效地使用它。

图 13.7.4 8 个 V100 GPU 服务器上的 NVLink 连接（图片由 NVIDIA 提供）。

事实证明，最佳同步策略是将网络分解为两个环，并使用它们直接同步数据 （Wang et al. , 2018）。图 13.7.5 说明网络可以分解为具有双 NVLink 带宽的一个环 (1-2-3-4-5-6-7-8-1) 和一个 (1-4-6-3- 5-8-2-7-1) 具有常规带宽。在这种情况下设计高效的同步协议并非易事。

图 13.7.5将 NVLink 网络分解为两个环。

考虑以下思想实验：给定一环n 计算节点（或 GPU），我们可以将梯度从第一个节点发送到第二个节点。在那里它被添加到局部梯度并发送到第三个节点，依此类推。后n−1步骤聚合梯度可以在最后访问的节点中找到。也就是说，聚合梯度的时间随着节点的数量线性增长。但如果我们这样做，算法效率会很低。毕竟，任何时候都只有一个节点在通信。如果我们把梯度分解成 n块并开始同步块i从节点开始i？由于每个块的大小1/n现在的总时间(n−1)/n≈1. 换句话说，随着我们增加环的大小，聚合梯度所花费的时间不会增加。这是一个相当惊人的结果。图 13.7.6 说明了步骤的顺序n=4节点。

图 13.7.6跨 4 个节点的环同步。每个节点开始将部分梯度传输到其左邻居，直到可以在其右邻居中找到组装的梯度。

如果我们使用跨 8 个 V100 GPU 同步 160 MB 的相同示例，我们将得到大约 2⋅160MB/(3⋅18GB/s)≈6ms. 这比使用 PCIe 总线要好，即使我们现在使用 8 个 GPU。请注意，在实践中，这些数字会更糟一些，因为深度学习框架通常无法将通信组合成大量突发传输。

请注意，有一个常见的误解，认为环同步与其他同步算法根本不同。唯一的区别是与简单的树相比，同步路径稍微复杂一些。

13.7.3。多机训练

在多台机器上进行分布式训练增加了一个进一步的挑战：我们需要与仅通过相对较低带宽的结构连接的服务器进行通信，在某些情况下，这种结构的速度可能会慢一个数量级以上。跨设备同步很棘手。毕竟，不同机器运行训练代码的速度会有细微差别。因此，如果我们想使用同步分布式优化， 我们需要同步它们。图 13.7.7说明了分布式并行训练是如何发生的。

在每台机器上读取（不同的）一批数据，将其拆分到多个 GPU 并传输到 GPU 内存。预测和梯度分别在每个 GPU 批次上计算。

来自所有本地 GPU 的梯度聚合在一个 GPU 上（或其中的一部分聚合在不同的 GPU 上）。

梯度被发送到 CPU。

CPU 将梯度发送到聚合所有梯度的中央参数服务器。

然后使用聚合梯度来更新参数，并将更新后的参数广播回各个 CPU。

信息被发送到一个（或多个）GPU。

更新后的参数分布在所有 GPU 上。

图13.7.7多机多GPU分布式并行训练。

这些操作中的每一个看起来都相当简单。而且，事实上，它们可以在一台机器上高效地执行。但是，一旦我们查看多台机器，我们就会发现中央参数服务器成为瓶颈。毕竟每台服务器的带宽是有限的，因此对于m工作人员将所有梯度发送到服务器所需的时间是O(m). 我们可以通过增加服务器数量来突破这个障碍n. 此时每台服务器只需要存储O(1/n)的参数，因此更新和优化的总时间变为 O(m/n). 无论我们正在处理多少工人，匹配这两个数字都会产生恒定的缩放比例。在实践中，我们使用同一台机器作为工作人员和服务器。 图 13.7.8说明了该设计（详见 ( Li et al. , 2014 )）。特别是，确保多台机器在没有不合理延迟的情况下工作是非常重要的。

图 13.7.8顶部：单个参数服务器是一个瓶颈，因为它的带宽是有限的。底部：多个参数服务器存储部分具有聚合带宽的参数。

13.7.4。键值存储

在实践中实施分布式多 GPU 训练所需的步骤并非易事。这就是为什么使用通用抽象是值得的，即具有重新定义的更新语义的键值存储。

跨越许多工作人员和许多 GPU 的梯度计算i 可以定义为

(13.7.1)gi=∑k∈workers∑j∈GPUsgijk,

在哪里gijk是渐变的一部分i在 GPU 上拆分j工人的k. 此操作的关键方面是它是可交换归约，也就是说，它将多个向量变成一个向量，并且应用操作的顺序无关紧要。这对我们的目的非常有用，因为我们不需要（需要）对何时接收哪个梯度进行细粒度控制。此外，请注意，此操作在不同的i.

这使我们能够定义以下两个操作：push和 pull，累积梯度，pull检索聚合梯度。由于我们有很多不同的梯度集（毕竟我们有很多层），我们需要用一个键来索引梯度i. 这种与键值存储的相似性，例如 Dynamo 中引入的键值存储 （DeCandia等人，2007 年）并非巧合。它们也满足许多相似的特征，尤其是在涉及跨多个服务器分布参数时。

键值存储的推拉操作描述如下：

push(key, value)将特定梯度（值）从工作人员发送到公共存储。在那里该值被聚合，例如，通过将其相加。

pull(key, value)从公共存储中检索聚合值，例如，在组合所有 worker 的梯度之后。

通过将有关同步的所有复杂性隐藏在简单的推拉操作背后，我们可以将希望能够用简单术语表达优化的统计建模人员和需要处理分布式同步固有复杂性的系统工程师的关注分离开来。

13.7.5。概括

同步需要高度适应服务器内的特定网络基础设施和连接。这会对同步所需的时间产生重大影响。

环同步对于 p3 和 DGX-2 服务器可能是最佳的。对于其他人可能不是那么多。

当添加多个参数服务器以增加带宽时，分层同步策略效果很好。

13.7.6。练习

你能进一步增加环同步吗？提示：您可以双向发送消息。

是否可以允许异步通信（同时计算仍在进行中）？它如何影响性能？

如果我们在长时间运行的计算过程中丢失了一台服务器怎么办？我们如何设计容错机制来避免完全重新启动计算？

Discussions