在過(guò)去的10個(gè)月里，在PyTorch Lightning工作期間，團(tuán)隊(duì)和我已經(jīng)接觸過(guò)許多結(jié)構(gòu)PyTorch代碼的風(fēng)格，我們已經(jīng)發(fā)現(xiàn)了一些人們無(wú)意中引入瓶頸的關(guān)鍵地方。
我們非常小心地確保PyTorch Lightning不會(huì)對(duì)我們?yōu)槟阕詣?dòng)編寫(xiě)的代碼犯任何這些錯(cuò)誤，我們甚至?xí)跈z測(cè)到這些錯(cuò)誤時(shí)為用戶糾正這些錯(cuò)誤。然而，由于Lightning只是結(jié)構(gòu)化的PyTorch，而你仍然控制所有的PyTorch，因此在許多情況下，我們不能為用戶做太多事情。
此外，如果不使用Lightning，可能會(huì)在無(wú)意中將這些問(wèn)題引入代碼。
為了幫助你訓(xùn)練得更快，這里有8個(gè)技巧，你應(yīng)該知道它們可能會(huì)減慢你的代碼。
在DataLoaders中使用workers
第一個(gè)錯(cuò)誤很容易糾正。PyTorch允許同時(shí)在多個(gè)進(jìn)程上加載數(shù)據(jù)。
在這種情況下，PyTorch可以通過(guò)處理8個(gè)批次繞過(guò)GIL鎖，每個(gè)批次在一個(gè)單獨(dú)的進(jìn)程上。你應(yīng)該使用多少workers？一個(gè)好的經(jīng)驗(yàn)法則是:
- num_worker = 4 * num_GPU
https://discuss.pytorch.org/t/guidelines-for-assigning-num-workers-to-dataloader/813/7這里對(duì)此有一個(gè)很好的討論。
警告：缺點(diǎn)是你的內(nèi)存使用也會(huì)增加
Pin memory
你知道有時(shí)候你的GPU內(nèi)存顯示它是滿的但你很確定你的模型沒(méi)有使用那么多？這種開(kāi)銷稱為pinned memory。這個(gè)內(nèi)存被保留為一種“working allocation”類型。
當(dāng)你在一個(gè)DataLoader中啟用pinned_memory時(shí)，它“自動(dòng)將獲取的數(shù)據(jù)張量放在pinned memory中，并使數(shù)據(jù)更快地傳輸?shù)紺UDA-enabled的gpu”
這意味著你不應(yīng)該不必要的去調(diào)用：
- torch.cuda.empty_cache()
避免CPU到GPU的傳輸，反之亦然
- # bad.cpu()
- .item()
- .numpy()
我看到大量使用.item()或.cpu()或.numpy()調(diào)用。這對(duì)于性能來(lái)說(shuō)是非常糟糕的，因?yàn)槊總€(gè)調(diào)用都將數(shù)據(jù)從GPU傳輸?shù)紺PU，從而極大地降低了性能。
如果你試圖清除附加的計(jì)算圖，請(qǐng)使用.detach()。
- # good.detach()
這不會(huì)將內(nèi)存轉(zhuǎn)移到GPU，它會(huì)刪除任何附加到該變量的計(jì)算圖。
直接在GPUs上構(gòu)建張量
大多數(shù)人都是這樣在GPUs上創(chuàng)建張量的
- t = tensor.rand(2,2).cuda()
然而，這首先創(chuàng)建CPU張量，然后將其轉(zhuǎn)移到GPU……這真的很慢。相反，直接在想要的設(shè)備上創(chuàng)建張量。
- t = tensor.rand(2,2, device=torch.device('cuda:0'))
如果你正在使用Lightning，我們會(huì)自動(dòng)把你的模型和批處理放到正確的GPU上。但是，如果你在代碼的某個(gè)地方創(chuàng)建了一個(gè)新的張量(例如：為一個(gè)VAE采樣隨機(jī)噪聲，或類似的東西)，那么你必須自己放置張量。
- t = tensor.rand(2,2, device=self.device)
每個(gè)LightningModule都有一個(gè)方便的self.device調(diào)用，無(wú)論你是在CPU上，多 GPUs上，還是在TPUs上，lightning會(huì)為那個(gè)張量選擇正確的設(shè)備。
使用DistributedDataParallel不要使用DataParallel
PyTorch有兩個(gè)主要的模式用于在多 GPUs訓(xùn)練。第一種是DataParallel，它將一批數(shù)據(jù)分割到多個(gè)GPUs上。但這也意味著模型必須復(fù)制到每個(gè)GPU上，一旦在GPU 0上計(jì)算出梯度，它們必須同步到其他GPU。
這需要大量昂貴的GPU傳輸！相反，DistributedDataParallel在每個(gè)GPU(在它自己的進(jìn)程中)上創(chuàng)建模型副本，并且只讓數(shù)據(jù)的一部分對(duì)該GPU可用。這就像是讓N個(gè)獨(dú)立的模型進(jìn)行訓(xùn)練，除了一旦每個(gè)模型都計(jì)算出梯度，它們就會(huì)在模型之間同步梯度……這意味著我們?cè)诿颗幚碇兄辉贕PUs之間傳輸一次數(shù)據(jù)。
在Lightning中，你可以在兩者之間輕松切換
- Trainer(distributed_backend='ddp', gpus=8)
- Trainer(distributed_backend='dp', gpus=8)
請(qǐng)注意，PyTorch和Lightning都不鼓勵(lì)使用DP。
使用16-bit精度
這是另一種加快訓(xùn)練速度的方法，我們沒(méi)有看到很多人使用這種方法。在你的模型進(jìn)行16bit訓(xùn)練的部分，數(shù)據(jù)從32位變到到16位。這有幾個(gè)優(yōu)點(diǎn):
- 你使用了一半的內(nèi)存(這意味著你可以將batch大小翻倍，并將訓(xùn)練時(shí)間減半)。
- 某些GPU(V100, 2080Ti)可以自動(dòng)加速(3 -8倍)，因?yàn)樗鼈冡槍?duì)16位計(jì)算進(jìn)行了優(yōu)化。
在Lightning中，這很簡(jiǎn)單:
- Trainer(precision=16)
注意：在PyTorch 1.6之前，你還必須安裝Nvidia Apex，現(xiàn)在16位是PyTorch的原生版本。但如果你使用的是Lightning，它同時(shí)支持這兩種功能，并根據(jù)檢測(cè)到的PyTorch版本自動(dòng)切換。
對(duì)你的代碼進(jìn)行Profile
如果沒(méi)有Lightning，最后一條建議可能很難實(shí)現(xiàn)，但你可以使用cprofiler這樣的工具來(lái)實(shí)現(xiàn)。然而，在Lightning中，你可以通過(guò)兩種方式獲得所有在訓(xùn)練期間所做的調(diào)用的總結(jié)：
首先，內(nèi)置的basic profiler
- Trainer(profile=True)
可以給出這樣的輸出：
或者是高級(jí)的profiler:
- profiler = AdvancedProfiler()
- trainer = Trainer(profilerprofiler=profiler)
得到更小粒度的結(jié)果：
原文鏈接:https://mp.weixin.qq.com/s/FcjMmm0EtWrMtKkYbkh5xQ
