隨著我們從單個 GPU 轉(zhuǎn)移到多個 GPU,再轉(zhuǎn)移到包含多個 GPU 的多臺服務(wù)器,可能都分布在多個機架和網(wǎng)絡(luò)交換機上,我們的分布式和并行訓(xùn)練算法需要變得更加復(fù)雜。細(xì)節(jié)很重要,因為不同的互連具有非常不同的帶寬(例如,NVLink 可以在適當(dāng)?shù)脑O(shè)置下跨 6 個鏈路提供高達(dá) 100 GB/s 的速度,PCIe 4.0(16 通道)提供 32 GB/s,而即使是高速 100GbE 以太網(wǎng)也只能達(dá)到到 10 GB/秒)。同時,期望統(tǒng)計建模師成為網(wǎng)絡(luò)和系統(tǒng)方面的專家是不合理的。
Smola 和 Narayanamurthy ( 2010 )在分布式潛變量模型的背景下引入了參數(shù)服務(wù)器的核心思想 。隨后在Ahmed等人中描述了推拉語義。( 2012 )以及Li等人對系統(tǒng)和開源庫的描述 。(2014 年)。在下文中,我們將激勵效率所需的組件。
13.7.1。數(shù)據(jù)并行訓(xùn)練
讓我們回顧一下分布式訓(xùn)練的數(shù)據(jù)并行訓(xùn)練方法。我們將使用它來排除本節(jié)中的所有其他內(nèi)容,因為它在實踐中實施起來要簡單得多。由于現(xiàn)在 GPU 有足夠的內(nèi)存,因此幾乎沒有任何用例(除了圖上的深度學(xué)習(xí))首選任何其他并行策略。圖 13.7.1描述了我們在13.5 節(jié)中實現(xiàn)的數(shù)據(jù)并行的變體 。其中的關(guān)鍵方面是在將更新的參數(shù)重新廣播到所有 GPU 之前,梯度的聚合發(fā)生在一個 GPU (GPU 0) 上。
回想起來,在 GPU 0 上聚合的決定似乎是臨時的。畢竟,我們還不如聚合在 CPU 上。事實上,我們甚至可以決定在一個 GPU 上聚合一些參數(shù),在另一個 GPU 上聚合一些其他參數(shù)。只要優(yōu)化算法支持這一點,就沒有我們不能這樣做的真正原因。例如,如果我們有四個具有相關(guān)梯度的參數(shù)向量 g1,…,g4我們可以在一個 GPU 上聚合梯度gi (i=1,…,4).
這種推理似乎是武斷和輕率的。畢竟,數(shù)學(xué)自始至終都是一樣的。然而,我們正在處理真實的物理硬件,其中不同的總線具有不同的帶寬,如第 13.4 節(jié)所述 。考慮一個真實的 4 路 GPU 服務(wù)器,如圖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 條通道),我們需要一個 多路復(fù)用器。CPU 在 16x Gen3 鏈路上的帶寬為 16 GB/s。這也是每個人的速度GPU 連接到交換機。這意味著設(shè)備之間的通信更加有效。
為了論證,我們假設(shè)梯度為 160 MB。在這種情況下,將梯度從所有剩余的 3 個 GPU 發(fā)送到第四個 GPU 需要 30 毫秒(每次傳輸需要 10 毫秒 = 160 MB / 16 GB/s)。再加上 30 毫秒來傳回權(quán)重向量,我們總共需要 60 毫秒。如果我們將所有數(shù)據(jù)發(fā)送到 CPU,我們會受到 40 毫秒的懲罰,因為四個 GPU 中的每一個都需要將數(shù)據(jù)發(fā)送到 CPU,總共需要 80 毫秒。最后假設(shè)我們能夠?qū)⑻荻确殖?4 個部分,每個部分 40 MB。現(xiàn)在我們可以同時在不同的 GPU 上聚合每個部分因為 PCIe 交換機在所有鏈路之間提供全帶寬操作。這需要 7.5 毫秒而不是 30 毫秒,同步操作總共需要 15 毫秒。簡而言之,根據(jù)我們同步參數(shù)的方式,同一操作可能需要 15 毫秒到 80 毫秒不等。 圖 13.7.3描述了交換參數(shù)的不同策略。
請注意,在提高性能方面,我們還有另一種工具可供使用:在深度網(wǎng)絡(luò)中,需要一些時間來計算從頂部到底部的所有梯度。即使我們?nèi)栽诿τ跒槠渌麉?shù)組計算梯度,我們也可以開始同步某些參數(shù)組的梯度。 有關(guān)如何在 Horovod中執(zhí)行此操作的詳細(xì)信息,請參見例如Sergeev 和 Del Balso ( 2018 )。
13.7.2。環(huán)同步
當(dāng)談到現(xiàn)代深度學(xué)習(xí)硬件上的同步時,我們經(jīng)常會遇到大量定制的網(wǎng)絡(luò)連接。例如,AWS p3.16xlarge 和 NVIDIA DGX-2 實例共享圖 13.7.4的連接結(jié)構(gòu)。每個 GPU 通過 PCIe 鏈路連接到主機 CPU,該鏈路最高運行速度為 16 GB/s。此外,每個 GPU 還有 6 個 NVLink 連接,每個連接都能夠雙向傳輸 300 Gbit/s。這相當(dāng)于每個鏈接每個方向大約 18 GB/s。簡而言之,總 NVLink 帶寬明顯高于 PCIe 帶寬。問題是如何最有效地使用它。
事實證明,最佳同步策略是將網(wǎng)絡(luò)分解為兩個環(huán),并使用它們直接同步數(shù)據(jù) (Wang et al. , 2018)。圖 13.7.5 說明網(wǎng)絡(luò)可以分解為具有雙 NVLink 帶寬的一個環(huán) (1-2-3-4-5-6-7-8-1) 和一個 (1-4-6-3- 5-8-2-7-1) 具有常規(guī)帶寬。在這種情況下設(shè)計高效的同步協(xié)議并非易事。
考慮以下思想實驗:給定一環(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)的大小,聚合梯度所花費的時間不會增加。這是一個相當(dāng)驚人的結(jié)果。圖 13.7.6 說明了步驟的順序n=4節(jié)點。
如果我們使用跨 8 個 V100 GPU 同步 160 MB 的相同示例,我們將得到大約 2?160MB/(3?18GB/s)≈6ms. 這比使用 PCIe 總線要好,即使我們現(xiàn)在使用 8 個 GPU。請注意,在實踐中,這些數(shù)字會更糟一些,因為深度學(xué)習(xí)框架通常無法將通信組合成大量突發(fā)傳輸。
請注意,有一個常見的誤解,認(rèn)為環(huán)同步與其他同步算法根本不同。唯一的區(qū)別是與簡單的樹相比,同步路徑稍微復(fù)雜一些。
13.7.3。多機訓(xùn)練
在多臺機器上進(jìn)行分布式訓(xùn)練增加了一個進(jìn)一步的挑戰(zhàn):我們需要與僅通過相對較低帶寬的結(jié)構(gòu)連接的服務(wù)器進(jìn)行通信,在某些情況下,這種結(jié)構(gòu)的速度可能會慢一個數(shù)量級以上。跨設(shè)備同步很棘手。畢竟,不同機器運行訓(xùn)練代碼的速度會有細(xì)微差別。因此,如果我們想使用同步分布式優(yōu)化, 我們需要同步它們。圖 13.7.7說明了分布式并行訓(xùn)練是如何發(fā)生的。
-
在每臺機器上讀取(不同的)一批數(shù)據(jù),將其拆分到多個 GPU 并傳輸?shù)?GPU 內(nèi)存。預(yù)測和梯度分別在每個 GPU 批次上計算。
-
來自所有本地 GPU 的梯度聚合在一個 GPU 上(或其中的一部分聚合在不同的 GPU 上)。
-
梯度被發(fā)送到 CPU。
-
CPU 將梯度發(fā)送到聚合所有梯度的中央?yún)?shù)服務(wù)器。
-
然后使用聚合梯度來更新參數(shù),并將更新后的參數(shù)廣播回各個 CPU。
-
信息被發(fā)送到一個(或多個)GPU。
-
更新后的參數(shù)分布在所有 GPU 上。
這些操作中的每一個看起來都相當(dāng)簡單。而且,事實上,它們可以在一臺機器上高效地執(zhí)行。但是,一旦我們查看多臺機器,我們就會發(fā)現(xiàn)中央?yún)?shù)服務(wù)器成為瓶頸。畢竟每臺服務(wù)器的帶寬是有限的,因此對于m工作人員將所有梯度發(fā)送到服務(wù)器所需的時間是O(m). 我們可以通過增加服務(wù)器數(shù)量來突破這個障礙n. 此時每臺服務(wù)器只需要存儲O(1/n)的參數(shù),因此更新和優(yōu)化的總時間變?yōu)?O(m/n). 無論我們正在處理多少工人,匹配這兩個數(shù)字都會產(chǎn)生恒定的縮放比例。在實踐中,我們使用同一臺機器作為工作人員和服務(wù)器。 圖 13.7.8說明了該設(shè)計(詳見 ( Li et al. , 2014 ))。特別是,確保多臺機器在沒有不合理延遲的情況下工作是非常重要的。
評論
查看更多