如果你從事機(jī)器學(xué)習(xí)，或者碰巧是NVidia的投資者，你一定聽說過GPU對(duì)這個(gè)領(lǐng)域至關(guān)重要。但對(duì)我來說，GPU一直是個(gè)謎。我對(duì)“GPU=快速”有很好的理解，但僅此而已。

 

 

老實(shí)說，這能讓你走得更遠(yuǎn)。我開始著手使用Keras進(jìn)行ML工作，Keras是谷歌的TensorFlow庫之上的API。Keras是一個(gè)設(shè)計(jì)精美的API，它做出了一個(gè)非常實(shí)際的決定:大多數(shù)事情應(yīng)該是簡(jiǎn)單的，困難的事情應(yīng)該是可能的。

正因?yàn)槿绱耍�我真的不需要學(xué)習(xí)任何關(guān)于GPU的知識(shí)。我只是運(yùn)行了一些神奇的操作系統(tǒng)命令和一些神奇的代碼行-嘣!-大規(guī)模模型訓(xùn)練加速。我對(duì)這種情況非常滿意。

然而，在feedly最新的項(xiàng)目中，我們決定試用PyTorch，因?yàn)樗�越來越流行。但也有一些有利的�?shù)據(jù)。新的(強(qiáng)烈推薦的)fast.ai課程順序從Keras切換到PyTorch。 PyTorch模型也贏得了很多最近的Kaggle比賽。

所以我們深入研究并發(fā)現(xiàn)PyTorch通過清晰一致的API使所有事情成為可能。它比Keras更靈活，所以權(quán)衡的是簡(jiǎn)單的事情變得更難，但困難的事情變得更容易。如果你正在嘗試新的或不尋常的模型(或者你碰巧是一個(gè)控制狂)，PyTorch絕對(duì)是一個(gè)更好的選擇。

當(dāng)GPU加速我的PyTorch模型的時(shí)候，我谷歌了一下神奇的“GPU -> on”代碼行，我發(fā)現(xiàn)它不存在!一如既往，Pytorch使這比Keras更難實(shí)現(xiàn)，但是提供了一些關(guān)于如何著手做事的API。所有這一切的結(jié)果是，我不得不咬緊牙關(guān)，建立了一個(gè)關(guān)于GPU如何被用來加速模型訓(xùn)練的心智模型。

為什么GPU很快

模型通常具有許多很多參數(shù)。例如，流行的VGG圖像分類模型有大約1.4億個(gè)參數(shù)，分為16層!在運(yùn)行推理(預(yù)測(cè))時(shí)，你需要將輸入數(shù)據(jù)(圖像)傳遞到每個(gè)圖層，通常將該數(shù)據(jù)乘以圖層參數(shù)。在訓(xùn)練期間，你還必須稍微調(diào)整每個(gè)參數(shù)以更好地?cái)M合數(shù)據(jù)。那是很大的計(jì)算量!

CPU很擅長(zhǎng)快速完成一些事情。 這通常很好，有足夠的分支(如果用戶這樣做，那樣做)，以及大規(guī)模并行性實(shí)際上不可能的其他順序約束。GPU很好，可以做很多“慢”的事情。由于它們最初用于執(zhí)行圖形要求，因此它們希望一次性完成大量工作(考慮將圖像的所有像素轉(zhuǎn)換為灰度)。所以這里有一個(gè)權(quán)衡，對(duì)于ML來說GPU由于可以并行完成這些巨大的算術(shù)運(yùn)算而贏得大量時(shí)間。

具體來說，我的macbook有一個(gè)運(yùn)行速度為3.1Ghz且有4個(gè)內(nèi)核的CPU。NVidia K80 GPU擁有近5000個(gè)內(nèi)核，盡管運(yùn)行速度要慢得多——562Mhz。雖然這樣做并不公平，但你可以看到K80的時(shí)鐘速度大約慢了6倍，但是并行速度提高了1250倍。

如何考慮GPU

PyTorch不是代碼行“GPU -> on”，而是“CUDA”張量。CUDA是一個(gè)用于在GPU上執(zhí)行操作的庫�；�本上，PyTorch要求你聲明要在GPU上放置的內(nèi)容，然后你可以像往常一樣執(zhí)行操作。所以我想，讓我們?cè)囍�在GPU上添加一個(gè)圖層:

 

 

我運(yùn)行代碼，立即得到了一個(gè)錯(cuò)誤在隱藏層計(jì)算中:

 

 

為什么?我立即知道它與我添加的.cuda()代碼有關(guān)，但我不知道為什么。在思考了GPU應(yīng)該如何加速之后，我意識(shí)到，“當(dāng)然它不工作，一個(gè)張量在GPU上，另一個(gè)仍然在主內(nèi)存中!”一切都搞定了。Pytorch允許在GPU內(nèi)存中分配張量，然后使用GPU對(duì)這些張量進(jìn)行操作。但是這些操作的結(jié)果會(huì)怎樣呢?讓我們?cè)囋嚵硪粋�(gè)例子:

 

 

這是GPU內(nèi)存中的另一個(gè)張量!經(jīng)過更多的反復(fù)試驗(yàn)，我發(fā)現(xiàn)我不得不改變自己的思維方式。原來我以為內(nèi)存、CPU和GPU都混在一起了:

 

 

我意識(shí)到我需要這樣想:

 

 

從本質(zhì)上說，CPU/主內(nèi)存和GPU/GPU內(nèi)存都位于各自的小宇宙中。來自軟件工程背景的我開始將GPU操作看作是一個(gè)REST API。當(dāng)你使用REST API時(shí)，真正的成本是來回發(fā)送數(shù)據(jù)。在本地執(zhí)行任務(wù)的速度與在遠(yuǎn)程服務(wù)器上執(zhí)行任務(wù)的速度一樣快。但是你要避免的是大量的數(shù)據(jù)來回傳輸，因?yàn)檫@是純粹的開銷。

把這個(gè)類比往前推，我們可以看到，當(dāng)然，PyTorch matmul結(jié)果是一個(gè)GPU張量是有道理的。這樣就很容易在GPU上進(jìn)行進(jìn)一步的操作，而不需要將數(shù)據(jù)傳送到主內(nèi)存，然后再返回到GPU。所以如果我們想要使用GPU，我們真的想要GPU上的所有參數(shù)，因?yàn)檫@些參數(shù)將會(huì)被反復(fù)使用在前向傳遞中產(chǎn)生預(yù)測(cè)然后在后向傳遞中更新。每一批特性都必須被傳送到GPU內(nèi)存中。但是中間的和最終的結(jié)果(比如隱藏層的輸出)只能存在于GPU內(nèi)存中。我們需要做的就是不斷向GPU發(fā)送命令，告訴它如何操作參數(shù)和權(quán)重。

因此，在API類比中，我們只做兩個(gè)“重”請(qǐng)求(在上圖中加星標(biāo)的)，一個(gè)用于初始化權(quán)重，另一個(gè)用于在訓(xùn)練后獲得最終權(quán)重。但我們可能會(huì)在這兩個(gè)請(qǐng)求之間發(fā)出數(shù)百萬個(gè)輕量級(jí)請(qǐng)求來訓(xùn)練模型。

GPU性能的提高是真實(shí)的，而且是驚人的

那么什么樣的加速是可能的呢?PyTorch有一個(gè)不錯(cuò)的MNIST小例子我們可以使用。使用CPU運(yùn)行10個(gè)epoch需要153秒，使用GPU需要83秒。我們可以從理論上說，更大的模型可以獲得更大的收益。 不錯(cuò)，真不錯(cuò)。

一些實(shí)驗(yàn)

這一切都很棒。經(jīng)過一番思考和一些糟糕的繪圖之后，我對(duì)GPU的了解要好得多，并且所需的額外編碼也不錯(cuò)。但我的想法是否正確?回答這個(gè)問題的最好方法是建立一個(gè)實(shí)驗(yàn)。我想向自己證明運(yùn)輸數(shù)據(jù)是工作流程的“緩慢部分”。所以我嘗試了以下三件事：

1.做一個(gè)200x200矩陣乘以numpy，一個(gè)高度優(yōu)化的CPU線性代數(shù)庫。

2.使用PyTorch cuda張量在GPU上進(jìn)行200x200矩陣乘法運(yùn)算。

3.使用PyTorch cuda張量在GPU上進(jìn)行200x200矩陣乘法運(yùn)算，每次都來回復(fù)制數(shù)據(jù)。

正如預(yù)期的那樣，GPU只運(yùn)行得更快，這一次大約是6倍。有趣的是,1和3幾乎花費(fèi)了相同的時(shí)間。GPU操作的效率幾乎完全被數(shù)據(jù)傳輸?shù)牡托�所平�?

標(biāo)簽： 代碼 服務(wù)器 谷歌

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。