PyTorch教程13.7之参数服务器

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说明了分布式并行训练是如何发生的。

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

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

3. 梯度被发送到 CPU。

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

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

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

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

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

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