13.7.1。數(shù)據(jù)并行訓練

讓我們回顧一下分布式訓練的數(shù)據(jù)并行訓練方法。我們將使用它來排除本節(jié)中的所有其他內(nèi)容，因為它在實踐中實施起來要簡單得多。由于現(xiàn)在 GPU 有足夠的內(nèi)存，因此幾乎沒有任何用例（除了圖上的深度學習）首選任何其他并行策略。圖 13.7.1描述了我們在13.5 節(jié)中實現(xiàn)的數(shù)據(jù)并行的變體 。其中的關鍵方面是在將更新的參數(shù)重新廣播到所有 GPU 之前，梯度的聚合發(fā)生在一個 GPU (GPU 0) 上。

圖 13.7.1左：單 GPU 訓練。右圖：多 GPU 訓練的一種變體：(1) 我們計算損失和梯度，(2) 所有梯度都聚集在一個 GPU 上，(3) 發(fā)生參數(shù)更新并將參數(shù)重新分配給所有 GPU。

回想起來，在 GPU 0 上聚合的決定似乎是臨時的。畢竟，我們還不如聚合在 CPU 上。事實上，我們甚至可以決定在一個 GPU 上聚合一些參數(shù)，在另一個 GPU 上聚合一些其他參數(shù)。只要優(yōu)化算法支持這一點，就沒有我們不能這樣做的真正原因。例如，如果我們有四個具有相關梯度的參數(shù)向量 g1,…,g4我們可以在一個 GPU 上聚合梯度gi (i=1,…,4).

這種推理似乎是武斷和輕率的。畢竟，數(shù)學自始至終都是一樣的。然而，我們正在處理真實的物理硬件，其中不同的總線具有不同的帶寬，如第 13.4 節(jié)所述 。考慮一個真實的 4 路 GPU 服務器，如圖13.7.2所示。如果連接特別好，它可能有 100 GbE 網(wǎng)卡。更典型的數(shù)字在 1–10 GbE 范圍內(nèi)，有效帶寬為 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 發(fā)送到第四個 GPU 需要 30 毫秒（每次傳輸需要 10 毫秒 = 160 MB / 16 GB/s）。再加上 30 毫秒來傳回權重向量，我們總共需要 60 毫秒。如果我們將所有數(shù)據(jù)發(fā)送到 CPU，我們會受到 40 毫秒的懲罰，因為四個 GPU 中的每一個都需要將數(shù)據(jù)發(fā)送到 CPU，總共需要 80 毫秒。最后假設我們能夠將梯度分成 4 個部分，每個部分 40 MB。現(xiàn)在我們可以同時在不同的 GPU 上聚合每個部分因為 PCIe 交換機在所有鏈路之間提供全帶寬操作。這需要 7.5 毫秒而不是 30 毫秒，同步操作總共需要 15 毫秒。簡而言之，根據(jù)我們同步參數(shù)的方式，同一操作可能需要 15 毫秒到 80 毫秒不等。 圖 13.7.3描述了交換參數(shù)的不同策略。

圖 13.7.3參數(shù)同步策略。

請注意，在提高性能方面，我們還有另一種工具可供使用：在深度網(wǎng)絡中，需要一些時間來計算從頂部到底部的所有梯度。即使我們?nèi)栽诿τ跒槠渌麉?shù)組計算梯度，我們也可以開始同步某些參數(shù)組的梯度。 有關如何在 Horovod中執(zhí)行此操作的詳細信息，請參見例如Sergeev 和 Del Balso ( 2018 )。

13.7.2。環(huán)同步

當談到現(xiàn)代深度學習硬件上的同步時，我們經(jīng)常會遇到大量定制的網(wǎng)絡連接。例如，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 提供）。

事實證明，最佳同步策略是將網(wǎng)絡分解為兩個環(huán)，并使用它們直接同步數(shù)據(jù) （Wang et al. , 2018）。圖 13.7.5 說明網(wǎng)絡可以分解為具有雙 NVLink 帶寬的一個環(huán) (1-2-3-4-5-6-7-8-1) 和一個 (1-4-6-3- 5-8-2-7-1) 具有常規(guī)帶寬。在這種情況下設計高效的同步協(xié)議并非易事。

圖 13.7.5將 NVLink 網(wǎng)絡分解為兩個環(huán)。

考慮以下思想實驗：給定一環(huán)n 計算節(jié)點（或 GPU），我們可以將梯度從第一個節(jié)點發(fā)送到第二個節(jié)點。在那里它被添加到局部梯度并發(fā)送到第三個節(jié)點，依此類推。后n?1步驟聚合梯度可以在最后訪問的節(jié)點中找到。也就是說，聚合梯度的時間隨著節(jié)點的數(shù)量線性增長。但如果我們這樣做，算法效率會很低。畢竟，任何時候都只有一個節(jié)點在通信。如果我們把梯度分解成 n塊并開始同步塊i從節(jié)點開始i？由于每個塊的大小1/n現(xiàn)在的總時間(n?1)/n≈1. 換句話說，隨著我們增加環(huán)的大小，聚合梯度所花費的時間不會增加。這是一個相當驚人的結果。圖 13.7.6 說明了步驟的順序n=4節(jié)點。

圖 13.7.6跨 4 個節(jié)點的環(huán)同步。每個節(jié)點開始將部分梯度傳輸?shù)狡渥筻従樱钡娇梢栽谄溆亦従又姓业浇M裝的梯度。

如果我們使用跨 8 個 V100 GPU 同步 160 MB 的相同示例，我們將得到大約 2?160MB/(3?18GB/s)≈6ms. 這比使用 PCIe 總線要好，即使我們現(xiàn)在使用 8 個 GPU。請注意，在實踐中，這些數(shù)字會更糟一些，因為深度學習框架通常無法將通信組合成大量突發(fā)傳輸。

請注意，有一個常見的誤解，認為環(huán)同步與其他同步算法根本不同。唯一的區(qū)別是與簡單的樹相比，同步路徑稍微復雜一些。

13.7.3。多機訓練

在多臺機器上進行分布式訓練增加了一個進一步的挑戰(zhàn)：我們需要與僅通過相對較低帶寬的結構連接的服務器進行通信，在某些情況下，這種結構的速度可能會慢一個數(shù)量級以上。跨設備同步很棘手。畢竟，不同機器運行訓練代碼的速度會有細微差別。因此，如果我們想使用同步分布式優(yōu)化， 我們需要同步它們。圖 13.7.7說明了分布式并行訓練是如何發(fā)生的。

1. 在每臺機器上讀?。ú煌模┮慌鷶?shù)據(jù)，將其拆分到多個 GPU 并傳輸?shù)?GPU 內(nèi)存。預測和梯度分別在每個 GPU 批次上計算。

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

3. 梯度被發(fā)送到 CPU。

4. CPU 將梯度發(fā)送到聚合所有梯度的中央?yún)?shù)服務器。

5. 然后使用聚合梯度來更新參數(shù)，并將更新后的參數(shù)廣播回各個 CPU。

6. 信息被發(fā)送到一個（或多個）GPU。

7. 更新后的參數(shù)分布在所有 GPU 上。

圖13.7.7多機多GPU分布式并行訓練。

這些操作中的每一個看起來都相當簡單。而且，事實上，它們可以在一臺機器上高效地執(zhí)行。但是，一旦我們查看多臺機器，我們就會發(fā)現(xiàn)中央?yún)?shù)服務器成為瓶頸。畢竟每臺服務器的帶寬是有限的，因此對于m工作人員將所有梯度發(fā)送到服務器所需的時間是O(m). 我們可以通過增加服務器數(shù)量來突破這個障礙n. 此時每臺服務器只需要存儲O(1/n)的參數(shù)，因此更新和優(yōu)化的總時間變?yōu)?O(m/n). 無論我們正在處理多少工人，匹配這兩個數(shù)字都會產(chǎn)生恒定的縮放比例。在實踐中，我們使用同一臺機器作為工作人員和服務器。 圖 13.7.8說明了該設計（詳見 ( Li et al. , 2014 )）。特別是，確保多臺機器在沒有不合理延遲的情況下工作是非常重要的。