今天訓(xùn)練faster R-CNN時，發(fā)現(xiàn)之前跑的很好的程序（是指在運(yùn)行程序過程中，顯卡利用率能夠一直維持在70%以上），今天看的時候，顯卡利用率很低，所以在想是不是我的訓(xùn)練數(shù)據(jù)torch.Tensor或者模型model沒有加載到GPU上訓(xùn)練，于是查找如何查看tensor和model所在設(shè)備的命令。

import torch
import torchvision.models as models
model=models.vgg11(pretrained=False)
print(next(model.parameters()).is_cuda)#False

data=torch.ones((5,10))
print(data.device)#cpu

上述是我在自己的筆記本上（顯然沒有GPU）的打印情況。

上次被老板教授了好久，出現(xiàn)西安卡利用率一直很低的情況千萬不能認(rèn)為它不是問題，而一定要想辦法解決。比如可以在加載訓(xùn)練圖像的過程中（__getitem__方法中）設(shè)定數(shù)據(jù)增強(qiáng)過程中每個步驟的時間點(diǎn)，對每個步驟的時間點(diǎn)進(jìn)行打印，判斷花費(fèi)時間較多的是哪些步驟，然后嘗試對代碼進(jìn)行優(yōu)化，因?yàn)閠orhc.utils.data中的__getitem__方法是由CPU上的一個num_workers執(zhí)行一遍的，如果__getitem__方法執(zhí)行太慢，則會導(dǎo)致IO速度變慢，即GPU在大多數(shù)時間都處于等待CPU讀取數(shù)據(jù)并處理成torch.cuda.tensor的過程，一旦CPU讀取一個batch size的數(shù)據(jù)完畢，GPU很快就計算結(jié)束，從而看到的現(xiàn)象是：GPU在絕大多數(shù)時間都處于利用率很低的狀態(tài)。

所以我總結(jié)的是，如果GPU顯卡利用率比較低，最可能的就是CPU數(shù)據(jù)IO耗費(fèi)時間太多（我之前就是由于數(shù)據(jù)增強(qiáng)的裁剪過程為了裁剪到object使用了for循環(huán)，導(dǎo)致這一操作很耗時間），還有可能的原因是數(shù)據(jù)tensor或者模型model根本就沒有加載到GPU cuda上面。其實(shí)還有一種可能性很小的原因就是，在網(wǎng)絡(luò)前向傳播的過程中某些特殊的操作對GPU的利用率不高，當(dāng)然指的是除了網(wǎng)絡(luò)（卷積，全連接）操作之外的其他的對于tensor的操作，比如我之前的faster R-CNN顯卡利用率低就是因?yàn)镽PN中的NMS算法速度太慢，大約2-3秒一張圖，雖然這時候tensor特征圖在CUDA上面，而且NMS也使用了CUDA kernel編譯后的代碼，也就是說NMS的計算仍然是利用的CPU，但是由于NMS算法并行度不高，所以對于GPU的利用不多，導(dǎo)致了顯卡利用率低，之前那個是怎么解決的呢？

哈哈，說到底還是環(huán)境的問題非常重要，之前的faster R-CNN代碼在python2  CUDA9.0 pytorch 0.4.0 環(huán)境下編譯成功我就沒有再仔細(xì)糾結(jié)環(huán)境問題，直接運(yùn)行了，直到后來偶然換成python3 CUDA9.0 pytorch 0.4.1 環(huán)境才極大地提高了顯卡利用率，并且通過設(shè)置了幾十個打印時間點(diǎn)之后發(fā)現(xiàn)，真的就是NMS的速度現(xiàn)在基本能維持在0.02-0.2數(shù)量級范圍內(nèi)。

下圖分別表示之前（顯卡利用率很低）時的NMS處理單張圖像所消耗的時間（之所以會有長有短是因?yàn)槲抑С植煌直媛实膱D像訓(xùn)練），后面一張圖是GPU利用率一直能維持在很高的情況下NMS處理時間，由于數(shù)據(jù)增強(qiáng)部分的代碼完全沒有修改，故而換了環(huán)境之后我就沒有再打印數(shù)據(jù)增強(qiáng)每個步驟所消耗的時間了。

以上這篇pytorch查看torch.Tensor和model是否在CUDA上的實(shí)例就是小編分享給大家的全部內(nèi)容了，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論