戰(zhàn)：版本匹配與踩坑記錄)
1. 在16.04上做這件事前先想清楚三件事1.1 為什么Ubuntu 16.04折騰GLIBC和Python生態(tài)的年代差先說(shuō)個(gè)現(xiàn)實(shí)問(wèn)題Ubuntu 16.04發(fā)布于2016年自帶GLIBC 2.23而mmdetection的現(xiàn)代版本和配套編譯工具鏈很多編譯產(chǎn)物都依賴更高的GLIBC版本。之前我在一臺(tái)老機(jī)器上直接照搬新教程結(jié)果在import torch那一步就報(bào)GLIBC_2.29 not found當(dāng)時(shí)整個(gè)人是懵的。這個(gè)報(bào)錯(cuò)的意思很直白你想用的PyTorch或mmcv編譯時(shí)是基于新版系統(tǒng)的動(dòng)態(tài)庫(kù)鏈接的GLIBC符號(hào)在你的系統(tǒng)里根本不存在。解決辦法不是去網(wǎng)上找一堆不安全的二進(jìn)制替換libc而是老老實(shí)實(shí)選擇一套和系統(tǒng)年代匹配的版本組合。同樣的問(wèn)題也出現(xiàn)在Python層面。16.04系統(tǒng)自帶的Python 3.5已經(jīng)非常老了很多新版本的mmdet、mmcv都不再兼容Python 3.5。我在實(shí)際配置中把它鎖定在Python 3.7不追新原因后面會(huì)展開(kāi)說(shuō)。所以入手16.04裝mmdetection的第一認(rèn)知就是不要試圖全上最新版本而是要構(gòu)建一套“古董但自洽”的版本矩陣。誰(shuí)先接受“老系統(tǒng)配老版本”這個(gè)現(xiàn)實(shí)誰(shuí)就能少踩三分之二的坑。適合看這篇內(nèi)容的人我總結(jié)一下手里正好有16.04的老機(jī)器、或者因?yàn)轱@卡驅(qū)動(dòng)原因只能留在16.04、再或者在某些工控設(shè)備上必須用老內(nèi)核的人。如果你的機(jī)器可以隨便裝20.04以上系統(tǒng)我建議你直接上新系統(tǒng)別回頭。1.2 顯卡、驅(qū)動(dòng)、CUDA三角約束先搞定在裝任何軟件之前先把顯卡型號(hào)確認(rèn)清楚。在16.04這種老系統(tǒng)上顯卡驅(qū)動(dòng)版本和CUDA版本是互相鎖死的順序不能亂。我當(dāng)時(shí)的做法是三步走。第一步用lspci | grep -i nvidia查看顯卡型號(hào)第二步去NVIDIA官網(wǎng)看該型號(hào)支持的最新驅(qū)動(dòng)版本第三步根據(jù)驅(qū)動(dòng)版本反推CUDA版本。實(shí)際中遇到過(guò)這樣一個(gè)例子一臺(tái)機(jī)器是GTX 1080 Ti驅(qū)動(dòng)版本390.xx這個(gè)驅(qū)動(dòng)最高只支持到CUDA 9.2左右。這意味著你最多也就用PyTorch 1.0左右的版本mmdetection基本沒(méi)法跑。這時(shí)候就得考慮升級(jí)驅(qū)動(dòng)到440以上才能用CUDA 10.2。顯卡驅(qū)動(dòng)版本可用的CUDA版本可搭配的PyTorch建議390.xxCUDA 9.2及以下PyTorch 1.0以下不推薦跑mmdetection418/430CUDA 10.1/10.2PyTorch 1.5~1.8450CUDA 11.0/11.3PyTorch 1.8~1.10這里額外提一句如果你連顯卡都沒(méi)有只想用CPU跑一跑示例那也請(qǐng)保持CPU版PyTorch的版本對(duì)應(yīng)關(guān)系不要混裝。1.3 是不是非16.04不可很多人的掙扎在于周?chē)坛潭际?8.04、20.04自己這臺(tái)機(jī)器偏偏是16.04。這時(shí)候我通常給出的建議排序是能上20.04就上20.04這是最優(yōu)解一套新版本組合隨便配。因?yàn)槔巷@卡或軟件依賴無(wú)法升級(jí)系統(tǒng)的選擇16.04 老版本組合也就是本文的主題。既不能換系統(tǒng)、又想用新功能——可以考慮用Docker容器在Docker里跑新版Ubuntu鏡像。但這對(duì)顯卡直通和nvidia-container-toolkit有要求而且16.04主機(jī)內(nèi)核老Docker的gpu參數(shù)兼容性需要專門(mén)測(cè)試我試下來(lái)反倒是裸裝更快。我個(gè)人的傾向是如果確定留在16.04就干脆把心氣放平把本文推薦的老版本組合當(dāng)標(biāo)準(zhǔn)答案不要再惦記mmdetection最新的3.0版本。2. 驅(qū)動(dòng)、CUDA與conda虛擬環(huán)境一鍋端式的準(zhǔn)備方案2.1 禁用nouveau安裝NVIDIA驅(qū)動(dòng)16.04自帶的nouveau開(kāi)源驅(qū)動(dòng)和NVIDIA閉源驅(qū)動(dòng)之間的沖突是環(huán)境安裝的第一道坎。不把它禁掉裝完驅(qū)動(dòng)重啟后大概率出現(xiàn)黑屏或循環(huán)登錄。操作順序是這樣的編輯配置文件sudo vim /etc/modprobe.d/blacklist-nouveau.conf寫(xiě)入下面兩行內(nèi)容blacklist nouveau options nouveau modeset0更新內(nèi)核配置并重啟sudo update-initramfs -u sudo reboot重啟后先確認(rèn)nouveau沒(méi)被加載lsmod | grep nouveau如果沒(méi)有任何輸出說(shuō)明禁用成功。接著去NVIDIA官網(wǎng)下載對(duì)應(yīng)顯卡的runfile安裝包直接.run文件安裝比apt源里的版本更可控特別是老環(huán)境。安裝命令chmod x NVIDIA-Linux-x86_64-450.142.run sudo ./NVIDIA-Linux-x86_64-450.142.run -no-x-check -no-nouveau-check裝完用nvidia-smi驗(yàn)證。如果顯示驅(qū)動(dòng)版本和顯存信息說(shuō)明驅(qū)動(dòng)沒(méi)問(wèn)題。這一步看似基礎(chǔ)但我見(jiàn)過(guò)太多人跳過(guò)后在mmdet訓(xùn)練時(shí)報(bào)各種CUDA相關(guān)崩潰回頭查才發(fā)現(xiàn)是驅(qū)動(dòng)層的cuda版本根本不兼容。2.2 CUDA與cuDNN安裝盡量用runfile而不是deb包CUDA和cuDNN的安裝方式會(huì)影響后期mmcv編譯的順利程度。16.04上用deb包安裝有個(gè)問(wèn)題它會(huì)把驅(qū)動(dòng)也一并更新掉導(dǎo)致你辛辛苦苦裝好的驅(qū)動(dòng)版本被覆蓋。所以我的方案是驅(qū)動(dòng)用runfile裝CUDA也用只裝工具庫(kù)的方式不動(dòng)驅(qū)動(dòng)。CUDA下載頁(yè)里選擇Linux、x86_64、Ubuntu 16.04版本對(duì)應(yīng)的runfile。假設(shè)我們選用CUDA 10.2wget https://developer.download.nvidia.com/compute/cuda/10.2/Prod/local_installers/cuda_10.2.89_440.33.01_linux.run sudo sh cuda_10.2.89_440.33.01_linux.run安裝時(shí)注意在提示是否安裝驅(qū)動(dòng)時(shí)選No只安裝CUDA Toolkit。然后設(shè)置環(huán)境變量把下面內(nèi)容加到~/.bashrcexport PATH/usr/local/cuda-10.2/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda-10.2/lib64:$LD_LIBRARY_PATHcuDNN的安裝更簡(jiǎn)單把下載的cudnn-10.2-linux-x64-v8.2.1.32.tgz解壓然后把文件內(nèi)容拷貝到CUDA目錄下tar -xzvf cudnn-10.2-linux-x64-v8.2.1.32.tgz sudo cp cuda/include/cudnn*.h /usr/local/cuda/include/ sudo cp cuda/lib64/libcudnn* /usr/local/cuda/lib64/這一步完成后記得同步一下軟鏈接否則編譯時(shí)可能出現(xiàn)libcudnn.so.8 not found。這是老系統(tǒng)上非常經(jīng)典的坑因?yàn)?6.04不太會(huì)主動(dòng)刷新動(dòng)態(tài)庫(kù)緩存。2.3 conda環(huán)境與Python 3.7給所有依賴建一個(gè)隔離區(qū)到這一步我強(qiáng)烈建議裝Anaconda或Miniconda絕對(duì)不要直接用系統(tǒng)Python。16.04自帶Python 3.5且很多系統(tǒng)工具鏈依賴它直接覆蓋會(huì)出大問(wèn)題。Miniconda對(duì)老系統(tǒng)更友好安裝命令wget https://repo.anaconda.com/miniconda/Miniconda3-py37_4.12.0-Linux-x86_64.sh bash Miniconda3-py37_4.12.0-Linux-x86_64.sh安裝時(shí)一路yes最后初始化conda。創(chuàng)建虛擬環(huán)境conda create -n mmdet python3.7 -y conda activate mmdet為什么鎖Python 3.7因?yàn)閙mdetection 2.x時(shí)代的官方README和大量預(yù)編譯的mmcv wheel都明確支持Python 3.7而且3.7在AGES工具箱里兼容性最高。整個(gè)mmdet全家桶對(duì)這個(gè)Python版本支持得最穩(wěn)實(shí)際測(cè)試中3.8也可以但在16.04的GLIBC限制下3.7的輪子最聽(tīng)話。3. mmcv與mmdetection的版本匹配系統(tǒng)成敗的分水嶺3.1 版本對(duì)應(yīng)關(guān)系別信任何單點(diǎn)教程mmcv和mmdetection的版本匹配關(guān)系極其嚴(yán)格不同大版本之間API有變化連配置字段都可能改過(guò)名。在16.04上我最終是裝成了mmdetection 2.25.1 mmcv-full 1.7.5 PyTorch 1.10.0 CUDA 10.2這一組合。這個(gè)搭配的思考邏輯是Python 3.7 PyTorch 1.10 CUDA 10.2在老驅(qū)動(dòng)能用、且版本不要太老之間取了平衡。mmcv-full 1.7.5這個(gè)版本提供豐富的預(yù)編譯包選項(xiàng)支持PyTorch 1.10。mmdetection 2.25.1是2.x系列的后期版本功能足夠且配置組織方式成熟。這里還需要看一個(gè)關(guān)鍵對(duì)應(yīng)表mmcv與mmdet官方支持關(guān)系mmdetection版本mmcv全版本2.25.1mmcv-full 1.5.1, 1.8.02.18.1mmcv-full 1.4.6, 1.7.02.10.0mmcv-full 1.3.8, 1.4.0別小看這些區(qū)間mmcv版本裝高了或裝低了輕則警告重則直接報(bào)AttributeError或KeyError比如mmdet里用到的某個(gè)函數(shù)在mmcv新版本里被改名了。3.2 安裝PyTorch與mmcv-full的完整命令先裝PyTorch 1.10.0對(duì)應(yīng)CUDA 10.2直接用conda安裝最省事conda install pytorch1.10.0 torchvision0.11.0 torchaudio0.10.0 cudatoolkit10.2 -c pytorch -y這里有個(gè)易錯(cuò)點(diǎn)如果你預(yù)先下載了本地wheel安裝必須保證wheel是CUDA 10.2編譯的。我曾經(jīng)貪快用了pip install torch1.10.0默認(rèn)源結(jié)果拉到了CPU版本訓(xùn)練時(shí)torch.cuda.is_available()一直返回False排查了半天才發(fā)現(xiàn)基礎(chǔ)裝錯(cuò)了。接著裝mmcv-full。有兩個(gè)選擇一是直接用官方預(yù)編譯wheel二是源碼編譯。在16.04上如果預(yù)編譯wheel能匹配到你的Python和CUDA版本那是最快路徑如果報(bào)找不到對(duì)應(yīng)的wheel就老老實(shí)實(shí)從源碼編譯。預(yù)編譯方式pip install mmcv-full1.7.5 -f https://download.openmmlab.com/mmcv/dist/cu102/torch1.10/index.html源碼編譯方式預(yù)編譯失敗時(shí)的備選git clone -b v1.7.5 https://github.com/open-mmlab/mmcv.git cd mmcv pip install -r requirements/optional.txt MMCV_WITH_OPS1 FORCE_CUDA1 pip install -e .注意源碼編譯時(shí)MMCV_WITH_OPS1這個(gè)環(huán)境變量不能省不然只會(huì)裝純Python版本后續(xù)運(yùn)行檢測(cè)時(shí)會(huì)報(bào)一些算子在自定義CUDA擴(kuò)展上缺失的錯(cuò)誤。3.3 驗(yàn)證安裝是否真的可用裝完后我建議不止做import測(cè)試而是直接跑一次簡(jiǎn)單測(cè)試看CUDA是否可用python -c import torch; print(torch.__version__, torch.cuda.is_available()) python -c import mmcv; print(mmcv.__version__) python -c import mmdet; print(mmdet.__version__)同時(shí)在Python里跑一個(gè)小算子import torch from mmcv.ops import nms boxes torch.tensor([[0, 0, 10, 10, 0.9]], dtypetorch.float32).cuda() keep nms(boxes, torch.tensor([0.5]).cuda(), 0.4) print(keep)如果這段輸出正常說(shuō)明整個(gè)CUDA編譯鏈路都是通的可以進(jìn)入數(shù)據(jù)準(zhǔn)備階段了。很多人在這一步直接卡住有的報(bào)torch.cuda.is_available() False有的報(bào)nms算子加載失敗。前者多半是PyTorch版本和CUDA不匹配后者多半是mmcv未安裝帶ops的版本。4. 數(shù)據(jù)集準(zhǔn)備與配置文件改動(dòng)訓(xùn)練前最后的硬骨頭4.1 COCO格式目錄結(jié)構(gòu)就是規(guī)則mmdetection默認(rèn)推薦COCO格式數(shù)據(jù)集。如果你手上是VOC或自建數(shù)據(jù)集推薦先轉(zhuǎn)成COCO格式因?yàn)楹罄m(xù)一切可視化腳本、評(píng)測(cè)接口都基于這個(gè)格式省得繞路。目錄組織如下data/ coco/ annotations/ instances_train2017.json instances_val2017.json train2017/ 000001.jpg 000002.jpg ... val2017/ 000001.jpg ...自建數(shù)據(jù)集時(shí)你需要寫(xiě)一個(gè)腳本把標(biāo)注轉(zhuǎn)換為COCO json最少包含categories、images、annotations三個(gè)節(jié)點(diǎn)。提醒一句images里的id和annotations里的image_id必須一致否則訓(xùn)練時(shí)數(shù)據(jù)加載會(huì)直接報(bào)找不到圖片的index這個(gè)初學(xué)最容易漏。4.2 配置文件繼承體系從base到sub-configmmdetection的配置成熟度很高“拿來(lái)改”比“從零寫(xiě)”靠譜太多。它的邏輯是先有基礎(chǔ)配置再逐層覆蓋字段。實(shí)際訓(xùn)練時(shí)主要改三個(gè)文件configs/_base_/datasets/coco_detection.py改數(shù)據(jù)路徑、訓(xùn)練圖片尺度、數(shù)據(jù)增強(qiáng)參數(shù)。configs/_base_/schedules/schedule_1x.py改學(xué)習(xí)率、step、總epoch數(shù)。configs/_base_/default_runtime.py改checkpoint保存間隔、日志配置、工作目錄。比如我們訓(xùn)練SSD或Faster R-CNN通常會(huì)創(chuàng)建一個(gè)新配置文件_base_ [ ../_base_/datasets/coco_detection.py, ../_base_/schedules/schedule_1x.py, ../_base_/default_runtime.py ] model dict( typeFasterRCNN, backbonedict(...), ... ) data dict( samples_per_gpu2, # 每個(gè)GPU的batch大小 workers_per_gpu2, # 每個(gè)GPU的DataLoader線程數(shù) ) optimizer dict(lr0.02/8) # 如果samples_per_gpu調(diào)整過(guò)學(xué)習(xí)率也要等比調(diào)整我當(dāng)時(shí)自作主張把samples_per_gpu調(diào)成4卻沒(méi)動(dòng)學(xué)習(xí)率結(jié)果損失直接NAN后來(lái)參照官方文檔里“l(fā)inear scaling rule”把學(xué)習(xí)率調(diào)小才恢復(fù)。4.3 數(shù)據(jù)增強(qiáng)與類別匹配中的隱藏要求模型頭和數(shù)據(jù)集類別數(shù)必須匹配。COCO默認(rèn)是80類如果你用自建數(shù)據(jù)集只有3個(gè)類別必須在配置里顯式覆蓋model dict( roi_headdict( bbox_headdict( num_classes3, )), ... )這個(gè)問(wèn)題很隱蔽因?yàn)椴桓采w也不會(huì)報(bào)錯(cuò)默認(rèn)80類會(huì)和你的標(biāo)注id對(duì)不上導(dǎo)致所有框都往錯(cuò)誤的類別上套。我在某次實(shí)驗(yàn)里完全沒(méi)注意訓(xùn)練了很久mAP一直很低直到可視化檢測(cè)結(jié)果才發(fā)現(xiàn)類別全亂這屬于白跑幾個(gè)小時(shí)的經(jīng)典失誤。數(shù)據(jù)增強(qiáng)方面mmdet的默認(rèn)pipeline已經(jīng)包含隨機(jī)翻轉(zhuǎn)、隨機(jī)縮放、多尺度resize。在16.04老機(jī)器上如果顯存不寬裕建議把img_scale從(1333, 800)改成(1000, 600)訓(xùn)練速度會(huì)提升明顯mAP損失在接受范圍內(nèi)。5. 訓(xùn)練流程實(shí)操?gòu)拿钚械交謴?fù)斷點(diǎn)5.1 單卡訓(xùn)練命令與常見(jiàn)參數(shù)一切就緒后進(jìn)入訓(xùn)練conda activate mmdet cd /path/to/mmdetection python tools/train.py configs/faster_rcnn_r50_fpn_1x_coco.py --work-dir work_dirs/my_experiment參數(shù)說(shuō)明--work-dir保存日志和checkpoint的目錄不設(shè)置時(shí)會(huì)自動(dòng)生成在work_dirs/下。--cfg-options臨時(shí)修改配置比如--cfg-options optimizer.lr0.01適合做小實(shí)驗(yàn)時(shí)用。--resume-from從指定checkpoint恢復(fù)。--auto-resume自動(dòng)從最近一次中斷點(diǎn)恢復(fù)這個(gè)參數(shù)在2.x版本里很實(shí)用。啟動(dòng)后日志會(huì)輸出每個(gè)epoch的loss、bbox_mAP等指標(biāo)。這里有個(gè)小習(xí)慣啟動(dòng)訓(xùn)練后別急著離開(kāi)先等兩三個(gè)iteration確認(rèn)loss在合理范圍比如0.5到2之間震蕩如果一開(kāi)始loss就NAN立刻CtrlC回去查配置別心疼這幾分鐘。5.2 多卡訓(xùn)練與GPU選擇如果你的老機(jī)器插了多張顯卡可以用官方腳本bash tools/dist_train.sh configs/faster_rcnn_r50_fpn_1x_coco.py 2 --work-dir work_dirs/my_experiment其中2是GPU卡數(shù)。但是16.04機(jī)器多為老平臺(tái)PCIe帶寬和CPU都可能是瓶頸。實(shí)測(cè)下來(lái)雙卡加速往往達(dá)不到2倍甚至?xí)驗(yàn)橥ㄐ砰_(kāi)銷(xiāo)拖慢。所以老機(jī)器上我反而推薦先單卡跑通再考慮分布式的test-time augmentation或推理加速。顯存不夠是另一個(gè)高頻問(wèn)題。如果訓(xùn)練時(shí)報(bào)CUDA out of memory優(yōu)先做三件事把samples_per_gpu降到1。把img_scale進(jìn)一步縮小。開(kāi)啟梯度累積在配置里使用optimizer_config dict(grad_clipNone, typeGradientCumulativeOptimizerHook, cumulative_iters4)。這個(gè)梯度累積技巧在顯存受限時(shí)堪稱救星等效增大batch size又不炸顯存。5.3 訓(xùn)練中途崩潰怎么續(xù)訓(xùn)練跑著跑著因?yàn)闄C(jī)房斷電、SSH斷開(kāi)、顯存溢出被殺進(jìn)程是常態(tài)。mmdetection的斷點(diǎn)續(xù)訓(xùn)機(jī)制很完善做法是python tools/train.py configs/faster_rcnn_r50_fpn_1x_coco.py --resume-from work_dirs/my_experiment/epoch_10.pth它會(huì)從epoch 10繼續(xù)訓(xùn)練優(yōu)化器狀態(tài)、學(xué)習(xí)率調(diào)度都會(huì)一并恢復(fù)。如果不想手動(dòng)指定--auto-resume會(huì)自動(dòng)找最新的checkpoint。迭代過(guò)程中還建議定期把配置文件復(fù)制到work_dirs里留檔比如cp configs/faster_rcnn_r50_fpn_1x_coco.py work_dirs/my_experiment/否則后續(xù)想回溯當(dāng)時(shí)實(shí)驗(yàn)用的哪套參數(shù)會(huì)非常被動(dòng)。評(píng)測(cè)模型時(shí)用python tools/test.py configs/faster_rcnn_r50_fpn_1x_coco.py work_dirs/my_experiment/epoch_12.pth --eval bbox注意--eval bbox只評(píng)測(cè)檢測(cè)框如果要評(píng)測(cè)分割結(jié)果要改成segm參數(shù)用錯(cuò)了不會(huì)報(bào)錯(cuò)但輸出metric缺失容易誤判。6. 我在16.04上踩過(guò)的坑編譯、訓(xùn)練中的典型報(bào)錯(cuò)與排查鏈路6.1 編譯報(bào)錯(cuò)別只看最后一行要看完整日志源碼編譯mmcv時(shí)最常見(jiàn)的報(bào)錯(cuò)是error: command gcc failed with exit status 1這個(gè)錯(cuò)誤信息太籠統(tǒng)90%以上的人卡在這里。我當(dāng)時(shí)的排查思路是往上翻日志找到真正的根源。通常有幾種情況缺少python頭文件需要先conda install python-dev或conda install python3.7-dev。缺少CUDA頭文件確認(rèn)/usr/local/cuda/include/cuda.h存在。gcc版本太老如果CUDA 10.2自帶驅(qū)動(dòng)的約束官方要求gcc 5.4沒(méi)問(wèn)題但如果升級(jí)到CUDA 115.4就不夠了需要gcc 7.5。說(shuō)到gcc16.04默認(rèn)gcc是5.4。解決辦法是apt安裝gcc-7sudo add-apt-repository ppa:ubuntu-toolchain-r/test sudo apt update sudo apt install gcc-7 g-7 sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-7 70 sudo update-alternatives --install /usr/bin/g g /usr/bin/g-7 70注意如果換gcc版本之前已經(jīng)編譯過(guò)的CUDA工具鏈不一定需要重裝但重新編譯mmcv時(shí)一定要確認(rèn)gcc --version是預(yù)期版本。6.2 訓(xùn)練中出現(xiàn)NAN的排查鏈路NAN是訓(xùn)練階段最常見(jiàn)的臟數(shù)據(jù)類問(wèn)題在16.04老環(huán)境里還多了一個(gè)特殊性硬件穩(wěn)定性降低某個(gè)PCIe插槽接觸不良或電源供電不足也可能隨機(jī)產(chǎn)生NAN。我的排查順序是先排除數(shù)據(jù)如果隨機(jī)抽樣幾百?gòu)堯?yàn)證圖片loss都在合理范圍那數(shù)據(jù)本身沒(méi)問(wèn)題。再看學(xué)習(xí)率線性縮放規(guī)則batch減半那么lr也要減半否則NAN概率極高。檢查BN層的num_batches_tracked低batch size下BN統(tǒng)計(jì)不穩(wěn)定可以在配置里norm_cfg dict(typeBN, requires_gradTrue)改成SyncBN或減小lr進(jìn)一步觀察。硬件層面查dmesg | grep -i error看有沒(méi)有GPU相關(guān)報(bào)錯(cuò)用nvidia-smi -pl 200給老卡降一點(diǎn)功耗墻訓(xùn)練穩(wěn)定性會(huì)好很多。這里強(qiáng)調(diào)一下環(huán)境越老越不能把NAN直接歸因到算法要按層、按數(shù)據(jù)、按硬件一步步隔離才能找到真兇。6.3 GPU利用率上不去、CPU爆滿的老機(jī)器優(yōu)化16.04老機(jī)器CPU核數(shù)普遍不多訓(xùn)練時(shí)GPU利用率經(jīng)常只在30%左右波動(dòng)這是因?yàn)镈ataLoader在瘋狂做圖像解碼和resizeCPU成了瓶頸。解法data dict( samples_per_gpu2, workers_per_gpu4, # 適當(dāng)調(diào)大worker數(shù) )workers_per_gpu從2調(diào)到4或6通常能讓GPU利用率明顯回升。但也不要盲目開(kāi)太大worker太多會(huì)造成內(nèi)存占用飆升老機(jī)器內(nèi)存不夠時(shí)反而觸發(fā)swap速度暴跌。我的一般經(jīng)驗(yàn)是內(nèi)存16G配2~4個(gè)worker32G以上配8個(gè)也沒(méi)問(wèn)題。還有一個(gè)容易被忽略的點(diǎn)可以用torch.backends.cudnn.benchmark True在輸入尺寸固定時(shí)開(kāi)啟cudnn自動(dòng)調(diào)優(yōu)對(duì)小數(shù)據(jù)集訓(xùn)練有明顯加速效果。老機(jī)器上跑訓(xùn)練最忌諱看著GPU沒(méi)吃滿就著急換大batch很多時(shí)候瓶頸不在GPU而在數(shù)據(jù)管線和IO。先診斷再優(yōu)化才是正道。最后再分享一個(gè)實(shí)際操作中的體會(huì)Ubuntu 16.04 mmdetection這套配置如果你能接受“不追新、版本鎖死、一切按部就班”的心態(tài)其實(shí)是可以很穩(wěn)定地跑起來(lái)的。我多次在重裝環(huán)境后照著一份自制的版本清單裝基本半小時(shí)內(nèi)能恢復(fù)到昨天的工作狀態(tài)。建議你也把最終成功的版本組合和安裝命令寫(xiě)成一份備忘而不是依賴記憶。老系統(tǒng)的容錯(cuò)率低但確定性高一次配好持續(xù)使用體驗(yàn)反而比每次升級(jí)都要折騰的人舒暢得多。 Ubuntu 16.04搭建mmdetection實(shí)戰(zhàn)：版本匹配與踩坑記錄
1. 在16.04上做這件事前先想清楚三件事1.1 為什么Ubuntu 16.04折騰GLIBC和Python生態(tài)的年代差先說(shuō)個(gè)現(xiàn)實(shí)問(wèn)題Ubuntu 16.04發(fā)布于2016年自帶GLIBC 2.23而mmdetection的現(xiàn)代版本和配套編譯工具鏈很多編譯產(chǎn)物都依賴更高的GLIBC版本。之前我在一臺(tái)老機(jī)器上直接照搬新教程結(jié)果在import torch那一步就報(bào)GLIBC_2.29 not found當(dāng)時(shí)整個(gè)人是懵的。這個(gè)報(bào)錯(cuò)的意思很直白你想用的PyTorch或mmcv編譯時(shí)是基于新版系統(tǒng)的動(dòng)態(tài)庫(kù)鏈接的GLIBC符號(hào)在你的系統(tǒng)里根本不存在。解決辦法不是去網(wǎng)上找一堆不安全的二進(jìn)制替換libc而是老老實(shí)實(shí)選擇一套和系統(tǒng)年代匹配的版本組合。同樣的問(wèn)題也出現(xiàn)在Python層面。16.04系統(tǒng)自帶的Python 3.5已經(jīng)非常老了很多新版本的mmdet、mmcv都不再兼容Python 3.5。我在實(shí)際配置中把它鎖定在Python 3.7不追新原因后面會(huì)展開(kāi)說(shuō)。所以入手16.04裝mmdetection的第一認(rèn)知就是不要試圖全上最新版本而是要構(gòu)建一套“古董但自洽”的版本矩陣。誰(shuí)先接受“老系統(tǒng)配老版本”這個(gè)現(xiàn)實(shí)誰(shuí)就能少踩三分之二的坑。適合看這篇內(nèi)容的人我總結(jié)一下手里正好有16.04的老機(jī)器、或者因?yàn)轱@卡驅(qū)動(dòng)原因只能留在16.04、再或者在某些工控設(shè)備上必須用老內(nèi)核的人。如果你的機(jī)器可以隨便裝20.04以上系統(tǒng)我建議你直接上新系統(tǒng)別回頭。1.2 顯卡、驅(qū)動(dòng)、CUDA三角約束先搞定在裝任何軟件之前先把顯卡型號(hào)確認(rèn)清楚。在16.04這種老系統(tǒng)上顯卡驅(qū)動(dòng)版本和CUDA版本是互相鎖死的順序不能亂。我當(dāng)時(shí)的做法是三步走。第一步用lspci | grep -i nvidia查看顯卡型號(hào)第二步去NVIDIA官網(wǎng)看該型號(hào)支持的最新驅(qū)動(dòng)版本第三步根據(jù)驅(qū)動(dòng)版本反推CUDA版本。實(shí)際中遇到過(guò)這樣一個(gè)例子一臺(tái)機(jī)器是GTX 1080 Ti驅(qū)動(dòng)版本390.xx這個(gè)驅(qū)動(dòng)最高只支持到CUDA 9.2左右。這意味著你最多也就用PyTorch 1.0左右的版本mmdetection基本沒(méi)法跑。這時(shí)候就得考慮升級(jí)驅(qū)動(dòng)到440以上才能用CUDA 10.2。顯卡驅(qū)動(dòng)版本可用的CUDA版本可搭配的PyTorch建議390.xxCUDA 9.2及以下PyTorch 1.0以下不推薦跑mmdetection418/430CUDA 10.1/10.2PyTorch 1.5~1.8450CUDA 11.0/11.3PyTorch 1.8~1.10這里額外提一句如果你連顯卡都沒(méi)有只想用CPU跑一跑示例那也請(qǐng)保持CPU版PyTorch的版本對(duì)應(yīng)關(guān)系不要混裝。1.3 是不是非16.04不可很多人的掙扎在于周?chē)坛潭际?8.04、20.04自己這臺(tái)機(jī)器偏偏是16.04。這時(shí)候我通常給出的建議排序是能上20.04就上20.04這是最優(yōu)解一套新版本組合隨便配。因?yàn)槔巷@卡或軟件依賴無(wú)法升級(jí)系統(tǒng)的選擇16.04 老版本組合也就是本文的主題。既不能換系統(tǒng)、又想用新功能——可以考慮用Docker容器在Docker里跑新版Ubuntu鏡像。但這對(duì)顯卡直通和nvidia-container-toolkit有要求而且16.04主機(jī)內(nèi)核老Docker的gpu參數(shù)兼容性需要專門(mén)測(cè)試我試下來(lái)反倒是裸裝更快。我個(gè)人的傾向是如果確定留在16.04就干脆把心氣放平把本文推薦的老版本組合當(dāng)標(biāo)準(zhǔn)答案不要再惦記mmdetection最新的3.0版本。2. 驅(qū)動(dòng)、CUDA與conda虛擬環(huán)境一鍋端式的準(zhǔn)備方案2.1 禁用nouveau安裝NVIDIA驅(qū)動(dòng)16.04自帶的nouveau開(kāi)源驅(qū)動(dòng)和NVIDIA閉源驅(qū)動(dòng)之間的沖突是環(huán)境安裝的第一道坎。不把它禁掉裝完驅(qū)動(dòng)重啟后大概率出現(xiàn)黑屏或循環(huán)登錄。操作順序是這樣的編輯配置文件sudo vim /etc/modprobe.d/blacklist-nouveau.conf寫(xiě)入下面兩行內(nèi)容blacklist nouveau options nouveau modeset0更新內(nèi)核配置并重啟sudo update-initramfs -u sudo reboot重啟后先確認(rèn)nouveau沒(méi)被加載lsmod | grep nouveau如果沒(méi)有任何輸出說(shuō)明禁用成功。接著去NVIDIA官網(wǎng)下載對(duì)應(yīng)顯卡的runfile安裝包直接.run文件安裝比apt源里的版本更可控特別是老環(huán)境。安裝命令chmod x NVIDIA-Linux-x86_64-450.142.run sudo ./NVIDIA-Linux-x86_64-450.142.run -no-x-check -no-nouveau-check裝完用nvidia-smi驗(yàn)證。如果顯示驅(qū)動(dòng)版本和顯存信息說(shuō)明驅(qū)動(dòng)沒(méi)問(wèn)題。這一步看似基礎(chǔ)但我見(jiàn)過(guò)太多人跳過(guò)后在mmdet訓(xùn)練時(shí)報(bào)各種CUDA相關(guān)崩潰回頭查才發(fā)現(xiàn)是驅(qū)動(dòng)層的cuda版本根本不兼容。2.2 CUDA與cuDNN安裝盡量用runfile而不是deb包CUDA和cuDNN的安裝方式會(huì)影響后期mmcv編譯的順利程度。16.04上用deb包安裝有個(gè)問(wèn)題它會(huì)把驅(qū)動(dòng)也一并更新掉導(dǎo)致你辛辛苦苦裝好的驅(qū)動(dòng)版本被覆蓋。所以我的方案是驅(qū)動(dòng)用runfile裝CUDA也用只裝工具庫(kù)的方式不動(dòng)驅(qū)動(dòng)。CUDA下載頁(yè)里選擇Linux、x86_64、Ubuntu 16.04版本對(duì)應(yīng)的runfile。假設(shè)我們選用CUDA 10.2wget https://developer.download.nvidia.com/compute/cuda/10.2/Prod/local_installers/cuda_10.2.89_440.33.01_linux.run sudo sh cuda_10.2.89_440.33.01_linux.run安裝時(shí)注意在提示是否安裝驅(qū)動(dòng)時(shí)選No只安裝CUDA Toolkit。然后設(shè)置環(huán)境變量把下面內(nèi)容加到~/.bashrcexport PATH/usr/local/cuda-10.2/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda-10.2/lib64:$LD_LIBRARY_PATHcuDNN的安裝更簡(jiǎn)單把下載的cudnn-10.2-linux-x64-v8.2.1.32.tgz解壓然后把文件內(nèi)容拷貝到CUDA目錄下tar -xzvf cudnn-10.2-linux-x64-v8.2.1.32.tgz sudo cp cuda/include/cudnn*.h /usr/local/cuda/include/ sudo cp cuda/lib64/libcudnn* /usr/local/cuda/lib64/這一步完成后記得同步一下軟鏈接否則編譯時(shí)可能出現(xiàn)libcudnn.so.8 not found。這是老系統(tǒng)上非常經(jīng)典的坑因?yàn)?6.04不太會(huì)主動(dòng)刷新動(dòng)態(tài)庫(kù)緩存。2.3 conda環(huán)境與Python 3.7給所有依賴建一個(gè)隔離區(qū)到這一步我強(qiáng)烈建議裝Anaconda或Miniconda絕對(duì)不要直接用系統(tǒng)Python。16.04自帶Python 3.5且很多系統(tǒng)工具鏈依賴它直接覆蓋會(huì)出大問(wèn)題。Miniconda對(duì)老系統(tǒng)更友好安裝命令wget https://repo.anaconda.com/miniconda/Miniconda3-py37_4.12.0-Linux-x86_64.sh bash Miniconda3-py37_4.12.0-Linux-x86_64.sh安裝時(shí)一路yes最后初始化conda。創(chuàng)建虛擬環(huán)境conda create -n mmdet python3.7 -y conda activate mmdet為什么鎖Python 3.7因?yàn)閙mdetection 2.x時(shí)代的官方README和大量預(yù)編譯的mmcv wheel都明確支持Python 3.7而且3.7在AGES工具箱里兼容性最高。整個(gè)mmdet全家桶對(duì)這個(gè)Python版本支持得最穩(wěn)實(shí)際測(cè)試中3.8也可以但在16.04的GLIBC限制下3.7的輪子最聽(tīng)話。3. mmcv與mmdetection的版本匹配系統(tǒng)成敗的分水嶺3.1 版本對(duì)應(yīng)關(guān)系別信任何單點(diǎn)教程mmcv和mmdetection的版本匹配關(guān)系極其嚴(yán)格不同大版本之間API有變化連配置字段都可能改過(guò)名。在16.04上我最終是裝成了mmdetection 2.25.1 mmcv-full 1.7.5 PyTorch 1.10.0 CUDA 10.2這一組合。這個(gè)搭配的思考邏輯是Python 3.7 PyTorch 1.10 CUDA 10.2在老驅(qū)動(dòng)能用、且版本不要太老之間取了平衡。mmcv-full 1.7.5這個(gè)版本提供豐富的預(yù)編譯包選項(xiàng)支持PyTorch 1.10。mmdetection 2.25.1是2.x系列的后期版本功能足夠且配置組織方式成熟。這里還需要看一個(gè)關(guān)鍵對(duì)應(yīng)表mmcv與mmdet官方支持關(guān)系mmdetection版本mmcv全版本2.25.1mmcv-full 1.5.1, 1.8.02.18.1mmcv-full 1.4.6, 1.7.02.10.0mmcv-full 1.3.8, 1.4.0別小看這些區(qū)間mmcv版本裝高了或裝低了輕則警告重則直接報(bào)AttributeError或KeyError比如mmdet里用到的某個(gè)函數(shù)在mmcv新版本里被改名了。3.2 安裝PyTorch與mmcv-full的完整命令先裝PyTorch 1.10.0對(duì)應(yīng)CUDA 10.2直接用conda安裝最省事conda install pytorch1.10.0 torchvision0.11.0 torchaudio0.10.0 cudatoolkit10.2 -c pytorch -y這里有個(gè)易錯(cuò)點(diǎn)如果你預(yù)先下載了本地wheel安裝必須保證wheel是CUDA 10.2編譯的。我曾經(jīng)貪快用了pip install torch1.10.0默認(rèn)源結(jié)果拉到了CPU版本訓(xùn)練時(shí)torch.cuda.is_available()一直返回False排查了半天才發(fā)現(xiàn)基礎(chǔ)裝錯(cuò)了。接著裝mmcv-full。有兩個(gè)選擇一是直接用官方預(yù)編譯wheel二是源碼編譯。在16.04上如果預(yù)編譯wheel能匹配到你的Python和CUDA版本那是最快路徑如果報(bào)找不到對(duì)應(yīng)的wheel就老老實(shí)實(shí)從源碼編譯。預(yù)編譯方式pip install mmcv-full1.7.5 -f https://download.openmmlab.com/mmcv/dist/cu102/torch1.10/index.html源碼編譯方式預(yù)編譯失敗時(shí)的備選git clone -b v1.7.5 https://github.com/open-mmlab/mmcv.git cd mmcv pip install -r requirements/optional.txt MMCV_WITH_OPS1 FORCE_CUDA1 pip install -e .注意源碼編譯時(shí)MMCV_WITH_OPS1這個(gè)環(huán)境變量不能省不然只會(huì)裝純Python版本后續(xù)運(yùn)行檢測(cè)時(shí)會(huì)報(bào)一些算子在自定義CUDA擴(kuò)展上缺失的錯(cuò)誤。3.3 驗(yàn)證安裝是否真的可用裝完后我建議不止做import測(cè)試而是直接跑一次簡(jiǎn)單測(cè)試看CUDA是否可用python -c import torch; print(torch.__version__, torch.cuda.is_available()) python -c import mmcv; print(mmcv.__version__) python -c import mmdet; print(mmdet.__version__)同時(shí)在Python里跑一個(gè)小算子import torch from mmcv.ops import nms boxes torch.tensor([[0, 0, 10, 10, 0.9]], dtypetorch.float32).cuda() keep nms(boxes, torch.tensor([0.5]).cuda(), 0.4) print(keep)如果這段輸出正常說(shuō)明整個(gè)CUDA編譯鏈路都是通的可以進(jìn)入數(shù)據(jù)準(zhǔn)備階段了。很多人在這一步直接卡住有的報(bào)torch.cuda.is_available() False有的報(bào)nms算子加載失敗。前者多半是PyTorch版本和CUDA不匹配后者多半是mmcv未安裝帶ops的版本。4. 數(shù)據(jù)集準(zhǔn)備與配置文件改動(dòng)訓(xùn)練前最后的硬骨頭4.1 COCO格式目錄結(jié)構(gòu)就是規(guī)則mmdetection默認(rèn)推薦COCO格式數(shù)據(jù)集。如果你手上是VOC或自建數(shù)據(jù)集推薦先轉(zhuǎn)成COCO格式因?yàn)楹罄m(xù)一切可視化腳本、評(píng)測(cè)接口都基于這個(gè)格式省得繞路。目錄組織如下data/ coco/ annotations/ instances_train2017.json instances_val2017.json train2017/ 000001.jpg 000002.jpg ... val2017/ 000001.jpg ...自建數(shù)據(jù)集時(shí)你需要寫(xiě)一個(gè)腳本把標(biāo)注轉(zhuǎn)換為COCO json最少包含categories、images、annotations三個(gè)節(jié)點(diǎn)。提醒一句images里的id和annotations里的image_id必須一致否則訓(xùn)練時(shí)數(shù)據(jù)加載會(huì)直接報(bào)找不到圖片的index這個(gè)初學(xué)最容易漏。4.2 配置文件繼承體系從base到sub-configmmdetection的配置成熟度很高“拿來(lái)改”比“從零寫(xiě)”靠譜太多。它的邏輯是先有基礎(chǔ)配置再逐層覆蓋字段。實(shí)際訓(xùn)練時(shí)主要改三個(gè)文件configs/_base_/datasets/coco_detection.py改數(shù)據(jù)路徑、訓(xùn)練圖片尺度、數(shù)據(jù)增強(qiáng)參數(shù)。configs/_base_/schedules/schedule_1x.py改學(xué)習(xí)率、step、總epoch數(shù)。configs/_base_/default_runtime.py改checkpoint保存間隔、日志配置、工作目錄。比如我們訓(xùn)練SSD或Faster R-CNN通常會(huì)創(chuàng)建一個(gè)新配置文件_base_ [ ../_base_/datasets/coco_detection.py, ../_base_/schedules/schedule_1x.py, ../_base_/default_runtime.py ] model dict( typeFasterRCNN, backbonedict(...), ... ) data dict( samples_per_gpu2, # 每個(gè)GPU的batch大小 workers_per_gpu2, # 每個(gè)GPU的DataLoader線程數(shù) ) optimizer dict(lr0.02/8) # 如果samples_per_gpu調(diào)整過(guò)學(xué)習(xí)率也要等比調(diào)整我當(dāng)時(shí)自作主張把samples_per_gpu調(diào)成4卻沒(méi)動(dòng)學(xué)習(xí)率結(jié)果損失直接NAN后來(lái)參照官方文檔里“l(fā)inear scaling rule”把學(xué)習(xí)率調(diào)小才恢復(fù)。4.3 數(shù)據(jù)增強(qiáng)與類別匹配中的隱藏要求模型頭和數(shù)據(jù)集類別數(shù)必須匹配。COCO默認(rèn)是80類如果你用自建數(shù)據(jù)集只有3個(gè)類別必須在配置里顯式覆蓋model dict( roi_headdict( bbox_headdict( num_classes3, )), ... )這個(gè)問(wèn)題很隱蔽因?yàn)椴桓采w也不會(huì)報(bào)錯(cuò)默認(rèn)80類會(huì)和你的標(biāo)注id對(duì)不上導(dǎo)致所有框都往錯(cuò)誤的類別上套。我在某次實(shí)驗(yàn)里完全沒(méi)注意訓(xùn)練了很久mAP一直很低直到可視化檢測(cè)結(jié)果才發(fā)現(xiàn)類別全亂這屬于白跑幾個(gè)小時(shí)的經(jīng)典失誤。數(shù)據(jù)增強(qiáng)方面mmdet的默認(rèn)pipeline已經(jīng)包含隨機(jī)翻轉(zhuǎn)、隨機(jī)縮放、多尺度resize。在16.04老機(jī)器上如果顯存不寬裕建議把img_scale從(1333, 800)改成(1000, 600)訓(xùn)練速度會(huì)提升明顯mAP損失在接受范圍內(nèi)。5. 訓(xùn)練流程實(shí)操?gòu)拿钚械交謴?fù)斷點(diǎn)5.1 單卡訓(xùn)練命令與常見(jiàn)參數(shù)一切就緒后進(jìn)入訓(xùn)練conda activate mmdet cd /path/to/mmdetection python tools/train.py configs/faster_rcnn_r50_fpn_1x_coco.py --work-dir work_dirs/my_experiment參數(shù)說(shuō)明--work-dir保存日志和checkpoint的目錄不設(shè)置時(shí)會(huì)自動(dòng)生成在work_dirs/下。--cfg-options臨時(shí)修改配置比如--cfg-options optimizer.lr0.01適合做小實(shí)驗(yàn)時(shí)用。--resume-from從指定checkpoint恢復(fù)。--auto-resume自動(dòng)從最近一次中斷點(diǎn)恢復(fù)這個(gè)參數(shù)在2.x版本里很實(shí)用。啟動(dòng)后日志會(huì)輸出每個(gè)epoch的loss、bbox_mAP等指標(biāo)。這里有個(gè)小習(xí)慣啟動(dòng)訓(xùn)練后別急著離開(kāi)先等兩三個(gè)iteration確認(rèn)loss在合理范圍比如0.5到2之間震蕩如果一開(kāi)始loss就NAN立刻CtrlC回去查配置別心疼這幾分鐘。5.2 多卡訓(xùn)練與GPU選擇如果你的老機(jī)器插了多張顯卡可以用官方腳本bash tools/dist_train.sh configs/faster_rcnn_r50_fpn_1x_coco.py 2 --work-dir work_dirs/my_experiment其中2是GPU卡數(shù)。但是16.04機(jī)器多為老平臺(tái)PCIe帶寬和CPU都可能是瓶頸。實(shí)測(cè)下來(lái)雙卡加速往往達(dá)不到2倍甚至?xí)驗(yàn)橥ㄐ砰_(kāi)銷(xiāo)拖慢。所以老機(jī)器上我反而推薦先單卡跑通再考慮分布式的test-time augmentation或推理加速。顯存不夠是另一個(gè)高頻問(wèn)題。如果訓(xùn)練時(shí)報(bào)CUDA out of memory優(yōu)先做三件事把samples_per_gpu降到1。把img_scale進(jìn)一步縮小。開(kāi)啟梯度累積在配置里使用optimizer_config dict(grad_clipNone, typeGradientCumulativeOptimizerHook, cumulative_iters4)。這個(gè)梯度累積技巧在顯存受限時(shí)堪稱救星等效增大batch size又不炸顯存。5.3 訓(xùn)練中途崩潰怎么續(xù)訓(xùn)練跑著跑著因?yàn)闄C(jī)房斷電、SSH斷開(kāi)、顯存溢出被殺進(jìn)程是常態(tài)。mmdetection的斷點(diǎn)續(xù)訓(xùn)機(jī)制很完善做法是python tools/train.py configs/faster_rcnn_r50_fpn_1x_coco.py --resume-from work_dirs/my_experiment/epoch_10.pth它會(huì)從epoch 10繼續(xù)訓(xùn)練優(yōu)化器狀態(tài)、學(xué)習(xí)率調(diào)度都會(huì)一并恢復(fù)。如果不想手動(dòng)指定--auto-resume會(huì)自動(dòng)找最新的checkpoint。迭代過(guò)程中還建議定期把配置文件復(fù)制到work_dirs里留檔比如cp configs/faster_rcnn_r50_fpn_1x_coco.py work_dirs/my_experiment/否則后續(xù)想回溯當(dāng)時(shí)實(shí)驗(yàn)用的哪套參數(shù)會(huì)非常被動(dòng)。評(píng)測(cè)模型時(shí)用python tools/test.py configs/faster_rcnn_r50_fpn_1x_coco.py work_dirs/my_experiment/epoch_12.pth --eval bbox注意--eval bbox只評(píng)測(cè)檢測(cè)框如果要評(píng)測(cè)分割結(jié)果要改成segm參數(shù)用錯(cuò)了不會(huì)報(bào)錯(cuò)但輸出metric缺失容易誤判。6. 我在16.04上踩過(guò)的坑編譯、訓(xùn)練中的典型報(bào)錯(cuò)與排查鏈路6.1 編譯報(bào)錯(cuò)別只看最后一行要看完整日志源碼編譯mmcv時(shí)最常見(jiàn)的報(bào)錯(cuò)是error: command gcc failed with exit status 1這個(gè)錯(cuò)誤信息太籠統(tǒng)90%以上的人卡在這里。我當(dāng)時(shí)的排查思路是往上翻日志找到真正的根源。通常有幾種情況缺少python頭文件需要先conda install python-dev或conda install python3.7-dev。缺少CUDA頭文件確認(rèn)/usr/local/cuda/include/cuda.h存在。gcc版本太老如果CUDA 10.2自帶驅(qū)動(dòng)的約束官方要求gcc 5.4沒(méi)問(wèn)題但如果升級(jí)到CUDA 115.4就不夠了需要gcc 7.5。說(shuō)到gcc16.04默認(rèn)gcc是5.4。解決辦法是apt安裝gcc-7sudo add-apt-repository ppa:ubuntu-toolchain-r/test sudo apt update sudo apt install gcc-7 g-7 sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-7 70 sudo update-alternatives --install /usr/bin/g g /usr/bin/g-7 70注意如果換gcc版本之前已經(jīng)編譯過(guò)的CUDA工具鏈不一定需要重裝但重新編譯mmcv時(shí)一定要確認(rèn)gcc --version是預(yù)期版本。6.2 訓(xùn)練中出現(xiàn)NAN的排查鏈路NAN是訓(xùn)練階段最常見(jiàn)的臟數(shù)據(jù)類問(wèn)題在16.04老環(huán)境里還多了一個(gè)特殊性硬件穩(wěn)定性降低某個(gè)PCIe插槽接觸不良或電源供電不足也可能隨機(jī)產(chǎn)生NAN。我的排查順序是先排除數(shù)據(jù)如果隨機(jī)抽樣幾百?gòu)堯?yàn)證圖片loss都在合理范圍那數(shù)據(jù)本身沒(méi)問(wèn)題。再看學(xué)習(xí)率線性縮放規(guī)則batch減半那么lr也要減半否則NAN概率極高。檢查BN層的num_batches_tracked低batch size下BN統(tǒng)計(jì)不穩(wěn)定可以在配置里norm_cfg dict(typeBN, requires_gradTrue)改成SyncBN或減小lr進(jìn)一步觀察。硬件層面查dmesg | grep -i error看有沒(méi)有GPU相關(guān)報(bào)錯(cuò)用nvidia-smi -pl 200給老卡降一點(diǎn)功耗墻訓(xùn)練穩(wěn)定性會(huì)好很多。這里強(qiáng)調(diào)一下環(huán)境越老越不能把NAN直接歸因到算法要按層、按數(shù)據(jù)、按硬件一步步隔離才能找到真兇。6.3 GPU利用率上不去、CPU爆滿的老機(jī)器優(yōu)化16.04老機(jī)器CPU核數(shù)普遍不多訓(xùn)練時(shí)GPU利用率經(jīng)常只在30%左右波動(dòng)這是因?yàn)镈ataLoader在瘋狂做圖像解碼和resizeCPU成了瓶頸。解法data dict( samples_per_gpu2, workers_per_gpu4, # 適當(dāng)調(diào)大worker數(shù) )workers_per_gpu從2調(diào)到4或6通常能讓GPU利用率明顯回升。但也不要盲目開(kāi)太大worker太多會(huì)造成內(nèi)存占用飆升老機(jī)器內(nèi)存不夠時(shí)反而觸發(fā)swap速度暴跌。我的一般經(jīng)驗(yàn)是內(nèi)存16G配2~4個(gè)worker32G以上配8個(gè)也沒(méi)問(wèn)題。還有一個(gè)容易被忽略的點(diǎn)可以用torch.backends.cudnn.benchmark True在輸入尺寸固定時(shí)開(kāi)啟cudnn自動(dòng)調(diào)優(yōu)對(duì)小數(shù)據(jù)集訓(xùn)練有明顯加速效果。老機(jī)器上跑訓(xùn)練最忌諱看著GPU沒(méi)吃滿就著急換大batch很多時(shí)候瓶頸不在GPU而在數(shù)據(jù)管線和IO。先診斷再優(yōu)化才是正道。最后再分享一個(gè)實(shí)際操作中的體會(huì)Ubuntu 16.04 mmdetection這套配置如果你能接受“不追新、版本鎖死、一切按部就班”的心態(tài)其實(shí)是可以很穩(wěn)定地跑起來(lái)的。我多次在重裝環(huán)境后照著一份自制的版本清單裝基本半小時(shí)內(nèi)能恢復(fù)到昨天的工作狀態(tài)。建議你也把最終成功的版本組合和安裝命令寫(xiě)成一份備忘而不是依賴記憶。老系統(tǒng)的容錯(cuò)率低但確定性高一次配好持續(xù)使用體驗(yàn)反而比每次升級(jí)都要折騰的人舒暢得多。