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 )）。特別是，確保多臺機器在沒有不合理延遲的情況下工作是非常重要的。