在過去的10個(gè)月里，在PyTorch Lightning工作期間，團(tuán)隊(duì)和我已經(jīng)接觸過許多結(jié)構(gòu)PyTorch代碼的風(fēng)格，我們已經(jīng)發(fā)現(xiàn)了一些人們無意中引入瓶頸的關(guān)鍵地方。

我們非常小心地確保PyTorch Lightning不會(huì)對(duì)我們?yōu)槟阕詣?dòng)編寫的代碼犯任何這些錯(cuò)誤，我們甚至?xí)跈z測(cè)到這些錯(cuò)誤時(shí)為用戶糾正這些錯(cuò)誤。然而，由于Lightning只是結(jié)構(gòu)化的PyTorch，而你仍然控制所有的PyTorch，因此在許多情況下，我們不能為用戶做太多事情。

此外，如果不使用Lightning，可能會(huì)在無意中將這些問題引入代碼。

為了幫助你訓(xùn)練得更快，這里有8個(gè)技巧，你應(yīng)該知道它們可能會(huì)減慢你的代碼。

在DataLoaders中使用workers

第一個(gè)錯(cuò)誤很容易糾正。PyTorch允許同時(shí)在多個(gè)進(jìn)程上加載數(shù)據(jù)。

在這種情況下，PyTorch可以通過處理8個(gè)批次繞過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)存顯示它是滿的但你很確定你的模型沒有使用那么多？這種開銷稱為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ì)于性能來說是非常糟糕的，因?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)用，無論你是在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)練速度的方法，我們沒有看到很多人使用這種方法。在你的模型進(jìn)行16bit訓(xùn)練的部分，數(shù)據(jù)從32位變到到16位。這有幾個(gè)優(yōu)點(diǎn):

1.  你使用了一半的內(nèi)存(這意味著你可以將batch大小翻倍，并將訓(xùn)練時(shí)間減半)。
2.  某些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

如果沒有Lightning，最后一條建議可能很難實(shí)現(xiàn)，但你可以使用cprofiler這樣的工具來實(shí)現(xiàn)。然而，在Lightning中，你可以通過兩種方式獲得所有在訓(xùn)練期間所做的調(diào)用的總結(jié)：

首先，內(nèi)置的basic profiler

Trainer(profile=True) 

可以給出這樣的輸出：

或者是高級(jí)的profiler: 

profiler = AdvancedProfiler()  
trainer = Trainer(profilerprofiler=profiler) 

得到更小粒度的結(jié)果：