度平臺(tái)環(huán)境準(zhǔn)備：Docker與GPU聯(lián)動(dòng)實(shí)戰(zhàn)指南)
算力調(diào)度平臺(tái)這個(gè)系列寫到第二篇環(huán)境準(zhǔn)備是繞不開的第一道坎。上篇聊了整體架構(gòu)和資源抽象的思路對(duì)平臺(tái)要解決什么問題、怎么把GPU資源池化和切分已經(jīng)有了大方向。這篇接著往下推進(jìn)把最底層的環(huán)境底座搭起來(lái)Docker和GPU聯(lián)動(dòng)。如果你是從這一篇開始看的也不影響環(huán)境準(zhǔn)備這層是獨(dú)立的照著做就行。為什么把環(huán)境準(zhǔn)備單獨(dú)拎出來(lái)寫一篇因?yàn)樗懔φ{(diào)度平臺(tái)后續(xù)所有東西——K8s調(diào)度、GPU顯存隔離、任務(wù)編排、鏡像分發(fā)——都建立在一套能穩(wěn)定運(yùn)行的容器加GPU環(huán)境上。環(huán)境沒搭好后面每一步都會(huì)遇到莫名其妙的坑。比如容器里跑深度學(xué)習(xí)任務(wù)時(shí)提示CUDA不可用或者Docker Desktop一啟動(dòng)就報(bào)虛擬化錯(cuò)誤又或者宿主機(jī)nvidia-smi正常但容器里死活看不到GPU這些問題的根源十有八九都出在環(huán)境準(zhǔn)備階段。這篇會(huì)把Docker安裝、GPU驅(qū)動(dòng)、NVIDIA Container Toolkit、容器內(nèi)GPU驗(yàn)證這幾個(gè)環(huán)節(jié)完整過(guò)一遍附帶我實(shí)際部署中踩過(guò)的坑和排查方法盡量讓你照著做一遍就能把環(huán)境跑通。1. 環(huán)境準(zhǔn)備這件事先想清楚再動(dòng)手1.1 算力調(diào)度平臺(tái)為什么非要Docker加GPU這套組合先明確一個(gè)問題算力調(diào)度平臺(tái)要調(diào)度的是什么表面上是任務(wù)和容器本質(zhì)上調(diào)度的是計(jì)算資源重點(diǎn)是GPU。深度學(xué)習(xí)的訓(xùn)練和推理、大模型的微調(diào)、科學(xué)計(jì)算這些場(chǎng)景對(duì)GPU的依賴遠(yuǎn)超CPU。所以一個(gè)調(diào)度平臺(tái)要真正落地它的底層必須有能力回答三個(gè)問題某個(gè)任務(wù)能用哪張GPU卡、能用多大顯存、任務(wù)跑起來(lái)容器內(nèi)部能不能實(shí)際訪問到GPU的計(jì)算能力。Docker在這里扮演的角色是標(biāo)準(zhǔn)化封裝和隔離。每個(gè)任務(wù)打包成一個(gè)鏡像環(huán)境依賴、CUDA版本、Python環(huán)境全部固化在鏡像里任務(wù)發(fā)到哪臺(tái)機(jī)器跑起來(lái)效果都一樣。GPU則通過(guò)驅(qū)動(dòng)和運(yùn)行時(shí)暴露給容器讓容器內(nèi)的CUDA應(yīng)用可以直通宿主機(jī)顯卡。這套組合的核心價(jià)值在于環(huán)境隔離做到了資源復(fù)用了任務(wù)還保持了可遷移性。如果你不是這次做調(diào)度平臺(tái)只是單純想在自己機(jī)器上跑深度學(xué)習(xí)這套環(huán)境準(zhǔn)備同樣是通用的。本地開發(fā)、模型微調(diào)、論文復(fù)現(xiàn)都需要先過(guò)這一關(guān)。所以這篇內(nèi)容不管你是要搭一個(gè)大平臺(tái)還是只想把單機(jī)GPU環(huán)境搞好都有直接參考價(jià)值。1.2 方案選型為什么是Docker而不是裸機(jī)或虛擬機(jī)聊一下我在環(huán)境選型上的思考過(guò)程。最樸素的做法是在裸機(jī)上裝驅(qū)動(dòng)、裝CUDA、裝Python環(huán)境然后直接跑訓(xùn)練腳本。這在單機(jī)單卡、沒有多人協(xié)作的情況下沒問題但一旦任務(wù)變多、環(huán)境需求沖突比如一個(gè)任務(wù)要CUDA 11.8另一個(gè)要CUDA 12.1裸機(jī)方案就亂了。你總不能每切換一次任務(wù)就重裝一遍環(huán)境這在工程上是不可接受的。虛擬機(jī)方案可以隔離環(huán)境但有兩個(gè)硬傷一是虛擬化層對(duì)GPU的透?jìng)髋渲脧?fù)雜虛擬機(jī)和宿主機(jī)之間的性能損耗在計(jì)算密集型任務(wù)里不可忽略二是虛擬機(jī)動(dòng)輒幾十GB鏡像起停時(shí)間以分鐘計(jì)在調(diào)度場(chǎng)景下完全跟不上節(jié)奏。Docker正好落在中間進(jìn)程級(jí)隔離啟動(dòng)秒級(jí)完成鏡像分層復(fù)用GPU直通時(shí)不引入明顯的性能損耗。對(duì)于算力調(diào)度平臺(tái)這種需要頻繁創(chuàng)建、銷毀任務(wù)運(yùn)行環(huán)境的場(chǎng)景容器是當(dāng)前性價(jià)比最高的方案。這也是為什么當(dāng)下主流AI基礎(chǔ)設(shè)施——K8s、各種訓(xùn)練平臺(tái)、推理服務(wù)框架——幾乎全部以容器為底座。選Docker不是跟風(fēng)是這個(gè)場(chǎng)景下的工程理性。1.3 前置檢查清單動(dòng)手前先花十分鐘確認(rèn)這些事無(wú)論在Linux還是Windows上做環(huán)境準(zhǔn)備有幾項(xiàng)前置條件必須先確認(rèn)不然后面報(bào)錯(cuò)會(huì)報(bào)得你懷疑人生。操作系統(tǒng)版本Docker和GPU驅(qū)動(dòng)對(duì)系統(tǒng)都有版本要求Ubuntu 22.04 LTS是目前兼容性最穩(wěn)妥的選擇。Windows的話建議Windows 11并打開WSL2功能。內(nèi)核版本Linux下Docker對(duì)內(nèi)核有最低版本要求64位系統(tǒng)、內(nèi)核版本建議不低于5.x。太老的內(nèi)核建議先升級(jí)。虛擬化支持Windows上跑Docker Desktop必須開啟CPU虛擬化也就是BIOS里的Intel VT-x或AMD-V。這個(gè)不開Docker Desktop根本起不來(lái)。GPU與驅(qū)動(dòng)版本先確認(rèn)你的顯卡型號(hào)和NVIDIA驅(qū)動(dòng)版本支持情況。老顯卡可能要裝特定版本驅(qū)動(dòng)新顯卡太新反而可能遇到驅(qū)動(dòng)還沒跟上的問題這在部署時(shí)經(jīng)常遇到。磁盤空間AI相關(guān)的鏡像和容器動(dòng)輒幾個(gè)GB到十幾個(gè)GB建議單獨(dú)規(guī)劃一個(gè)容量充足的數(shù)據(jù)盤。我經(jīng)歷過(guò)/var/lib/docker所在分區(qū)被打滿導(dǎo)致所有容器異常退出的事故所以現(xiàn)在一律先把data-root指到大磁盤上。這些檢查項(xiàng)看著瑣碎但每一件都在實(shí)際排障中救過(guò)我的命。花十分鐘確認(rèn)比出問題后再排查兩小時(shí)劃算得多。2. Docker環(huán)境安裝與基礎(chǔ)配置2.1 Linux宿主機(jī)安裝Docker以Ubuntu為例生產(chǎn)環(huán)境我強(qiáng)烈建議直接用Linux裸機(jī)或Linux虛擬機(jī)作為宿主機(jī)。這是算力調(diào)度平臺(tái)真正要跑起來(lái)的地方Windows只適合做開發(fā)調(diào)試。以Ubuntu 22.04為例安裝Docker的過(guò)程可以固化成一個(gè)標(biāo)準(zhǔn)操作sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg lsb-release sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin幾個(gè)容易被坑的點(diǎn)第一不要用系統(tǒng)自帶源里的docker.io包版本老舊后續(xù)容器運(yùn)行時(shí)兼容性差。第二安裝的是docker-ce社區(qū)版這是最主流的選擇不要用早期的docker-engine。第三docker-compose-plugin順手裝上后面編排多容器任務(wù)會(huì)用到。安裝完成后的標(biāo)準(zhǔn)操作是把當(dāng)前用戶加入docker組避免每次執(zhí)行docker命令都要sudo。注意這個(gè)操作有安全邊界docker組內(nèi)的用戶等價(jià)于擁有宿主機(jī)root權(quán)限所以在多人共享的機(jī)器上要謹(jǐn)慎不能為了省事無(wú)腦把所有人加進(jìn)去。sudo usermod -aG docker $USER newgrp docker然后啟動(dòng)并設(shè)置開機(jī)自啟sudo systemctl enable docker sudo systemctl start docker2.2 配置daemon.json存儲(chǔ)、網(wǎng)絡(luò)與日志裝好Docker只是第一步真正讓它在生產(chǎn)環(huán)境里穩(wěn)如老狗靠的是/etc/docker/daemon.json的配置。我常用的一個(gè)基礎(chǔ)配置長(zhǎng)這樣{ data-root: /data/docker, log-driver: json-file, log-opts: { max-size: 200m, max-file: 5 }, registry-mirrors: [], exec-opts: [native.cgroupdriversystemd] }>sudo systemctl daemon-reload sudo systemctl restart docker2.3 Windows場(chǎng)景下的Docker Desktop與WSL2開發(fā)調(diào)試階段很多同事習(xí)慣在Windows上工作。Docker Desktop現(xiàn)在的主流形態(tài)是WSL2后端其實(shí)就是讓Docker跑在一個(gè)輕量級(jí)虛擬機(jī)里。這個(gè)模式下有兩個(gè)前置條件必須滿足BIOS開啟虛擬化并且Windows里裝好WSL2。檢查虛擬化是否開啟任務(wù)管理器性能標(biāo)簽頁(yè)里能看到虛擬化狀態(tài)。如果顯示已啟用繼續(xù)裝WSLwsl --install wsl --set-default-version 2Docker Desktop安裝包下載安裝后在Settings里把Use the WSL 2 based engine勾上。如果這里啟動(dòng)報(bào)錯(cuò)virtualization support wasnt detected先回BIOS確認(rèn)VT-x/AMD-V是否打開再確認(rèn)Windows功能里的Virtual Machine Platform和Windows Hypervisor Platform這兩個(gè)組件是否啟用。Windows上用Docker Desktop要注意文件掛載的性能問題?？缥募到y(tǒng)掛載在WSL2里I/O性能較弱編譯類、大量小文件讀寫的任務(wù)會(huì)明顯卡頓。一個(gè)折中做法是把代碼放到WSL2的Linux文件系統(tǒng)里而不是放在Windows盤符下掛載進(jìn)容器。2.4 安裝后第一件事跑通一個(gè)容器環(huán)境裝好后先用一個(gè)最小的容器驗(yàn)證Docker本身是否正常docker run --rm hello-world看到Hello from Docker!就說(shuō)明Docker守護(hù)進(jìn)程、鏡像拉取、容器啟停這條鏈路都通了。接著跑一個(gè)交互式容器驗(yàn)證基本的終端和網(wǎng)絡(luò)能力docker run -it --rm ubuntu:22.04 bash apt-get update這兩個(gè)小測(cè)試的必要性在于把基礎(chǔ)鏈路和網(wǎng)絡(luò)源的問題提前暴露掉避免后面GPU環(huán)境準(zhǔn)備時(shí)把基礎(chǔ)問題和GPU問題混在一起排查。我見過(guò)有人在一個(gè)網(wǎng)絡(luò)都沒通的Docker環(huán)境里折騰GPU排查了半天最后發(fā)現(xiàn)是鏡像根本拉不動(dòng)白白浪費(fèi)了兩小時(shí)。3. GPU支持打通驅(qū)動(dòng)、運(yùn)行時(shí)與容器3.1 宿主機(jī)GPU驅(qū)動(dòng)安裝與驗(yàn)證Docker就緒后開始處理GPU。第一步確保宿主機(jī)本身能識(shí)別GPU。Linux上安裝NVIDIA驅(qū)動(dòng)有兩類主流方式用apt安裝發(fā)行版?zhèn)}庫(kù)里的驅(qū)動(dòng)包或者用NVIDIA官網(wǎng)的runfile安裝腳本。apt方式在Ubuntu上很省事sudo apt-get update sudo ubuntu-drivers devices sudo apt-get install -y nvidia-driver-550ubuntu-drivers devices會(huì)列出當(dāng)前機(jī)器推薦的驅(qū)動(dòng)版本照著裝就行。裝完重啟執(zhí)行nvidia-smi能看到顯卡型號(hào)、驅(qū)動(dòng)版本、顯存信息說(shuō)明驅(qū)動(dòng)工作正常。這里我提一個(gè)反直覺的細(xì)節(jié)nvidia-smi里的CUDA Version不是系統(tǒng)里安裝的CUDA工具包版本而是當(dāng)前驅(qū)動(dòng)支持的最高CUDA運(yùn)行時(shí)版本。應(yīng)用實(shí)際使用的CUDA版本由容器或應(yīng)用自身的CUDA庫(kù)決定只要不超過(guò)這個(gè)上限即可。很多人把這兩者混為一談導(dǎo)致后面裝CUDA時(shí)選錯(cuò)版本。踩坑提示Ubuntu從22.04開始默認(rèn)啟用Secure Boot如果BIOS里沒關(guān)安裝NVIDIA驅(qū)動(dòng)后模塊可能無(wú)法加載。表現(xiàn)是nvidia-smi提示找不到命令或報(bào)NVIDIA-SMI has failed because it couldnt communicate with the NVIDIA driver。解決辦法有兩種Secure Boot關(guān)閉后重裝驅(qū)動(dòng)或者給DKMS模塊做MOK簽名。命令行簽名流程比較繁瑣環(huán)境準(zhǔn)備階段我直接建議在測(cè)試機(jī)上關(guān)閉Secure Boot生產(chǎn)環(huán)境則要提前規(guī)劃好簽名流程。3.2 安裝NVIDIA Container Toolkit宿主機(jī)能看到GPU不等于容器里能看到GPU。中間缺的關(guān)鍵組件叫NVIDIA Container Toolkit它負(fù)責(zé)在Docker容器啟動(dòng)時(shí)把GPU設(shè)備、驅(qū)動(dòng)庫(kù)和nvidia-smi工具注入到容器的運(yùn)行環(huán)境里。這里解釋一下原理Docker本身不認(rèn)識(shí)GPU硬件。沒有Toolkit時(shí)即使宿主機(jī)的/dev/nvidia0設(shè)備節(jié)點(diǎn)就在那里容器默認(rèn)也訪問不到。NVIDIA Container Toolkit做的事是在容器創(chuàng)建時(shí)通過(guò)prestart hook動(dòng)態(tài)向容器配置注入GPU設(shè)備和驅(qū)動(dòng)庫(kù)讓容器內(nèi)的CUDA應(yīng)用能夠和宿主機(jī)驅(qū)動(dòng)通信。執(zhí)行安裝curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \ sed s#deb https://#deb [signed-by/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g | \ sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit然后配置Docker的運(yùn)行時(shí)sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart dockernvidia-ctk runtime configure這個(gè)命令會(huì)把NVIDIA Container Runtime注冊(cè)到Docker的運(yùn)行時(shí)配置里。重啟Docker后docker info里應(yīng)該能看到Runtimes: nvidia這一項(xiàng)。這一步做完Docker才真正具備了把GPU暴露給容器的能力。3.3 容器內(nèi)nvidia-smi驗(yàn)證驗(yàn)證是最激動(dòng)人心的一步。拉一個(gè)帶CUDA的基礎(chǔ)鏡像從容器里執(zhí)行nvidia-smidocker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi如果你看到宿主機(jī)里那張熟悉的信息表出現(xiàn)在容器內(nèi)說(shuō)明GPU打通了。注意一個(gè)細(xì)節(jié)容器內(nèi)nvidia-smi顯示的Driver Version和宿主機(jī)的驅(qū)動(dòng)版本通常是一致的。因?yàn)槿萜骼锏尿?qū)動(dòng)庫(kù)直接借用宿主機(jī)驅(qū)動(dòng)容器內(nèi)并沒有真正的驅(qū)動(dòng)內(nèi)核模塊。這是正常設(shè)計(jì)不是配置錯(cuò)了。再驗(yàn)證一下容器能否真正執(zhí)行CUDA計(jì)算。用一個(gè)帶CUDA runtime的鏡像在容器內(nèi)跑一段GPU運(yùn)算docker run --rm --gpus all nvidia/cuda:12.4.0-runtime-ubuntu22.04 bash -c cat /usr/local/cuda/version.json如果只是想確認(rèn)設(shè)備可用可以寫一段小的CUDA樣例程序或者直接驗(yàn)證PyTorch。但是要注意整個(gè)CUDA鏡像體積不小動(dòng)輒兩三個(gè)GB。如果只為了驗(yàn)證環(huán)境用nvidia/cuda:12.4.0-base-ubuntu22.04就夠了。3.4 PyTorch GPU環(huán)境實(shí)測(cè)GPU環(huán)境和Docker打通后再上一個(gè)大名鼎鼎的PyTorch做最終驗(yàn)證。這一步模擬的是真實(shí)的深度學(xué)習(xí)運(yùn)行環(huán)境。首先拉取官方PyTorch鏡像docker run -it --rm --gpus all -v /workspace:/workspace pytorch/pytorch:2.3.0-cuda12.1-cudnn8-runtime bash容器內(nèi)執(zhí)行python -c import torch; print(torch.__version__); print(torch.cuda.is_available()); print(torch.cuda.device_count()); print(torch.cuda.get_device_name(0))如果輸出True和你的顯卡型號(hào)算力調(diào)度平臺(tái)的單機(jī)GPU環(huán)境就算真正落定了。這一步能跑通說(shuō)明驅(qū)動(dòng)、Container Toolkit、Docker、CUDA運(yùn)行庫(kù)之間的所有鏈路都是通的。這里有一個(gè)常見問題在容器內(nèi)用pip安裝PyTorch時(shí)默認(rèn)安裝的是CPU版導(dǎo)致運(yùn)行torch.cuda.is_available()返回False。這是因?yàn)镻yTorch從2.0版本開始默認(rèn)pip索引里的包不一定帶CUDA支持。解決辦法是顯式安裝帶CUDA索引的版本。這一點(diǎn)在多臺(tái)機(jī)器上是很容易踩的坑。4. 環(huán)境準(zhǔn)備階段的典型問題與排查實(shí)錄4.1 容器里看不到GPU八成是Toolkit的問題癥狀宿主機(jī)nvidia-smi正常但容器里執(zhí)行nvidia-smi提示command not found或者運(yùn)行帶--gpus all命令時(shí)報(bào)錯(cuò)。排查順序按概率排列第一確認(rèn)docker info里有沒有顯示Runtimes: nvidia沒有就說(shuō)明Container Toolkit沒配置好重新執(zhí)行nvidia-ctk runtime configure并重啟Docker。第二確認(rèn)容器命令里加了--gpus all參數(shù)老版本Docker如果沒有這個(gè)參數(shù)在run時(shí)也看不到GPU。第三確認(rèn)驅(qū)動(dòng)和Toolkit版本兼容性。第四檢查/dev/nvidia*設(shè)備節(jié)點(diǎn)是否存在如果設(shè)備節(jié)點(diǎn)異常多半是驅(qū)動(dòng)模塊加載有問題。按這個(gè)順序排查絕大多數(shù)情況都能定位。4.2 Docker Desktop啟動(dòng)失敗的虛擬化問題Windows場(chǎng)景下Docker Desktop最常見的啟動(dòng)失敗報(bào)錯(cuò)是virtualization support wasnt detected。這個(gè)報(bào)錯(cuò)說(shuō)白了就是WSL2依賴的虛擬化能力沒有就緒。排查從三個(gè)層面展開BIOS里開啟Intel VT-x或AMD-VWindows功能里啟用Virtual Machine Platform和Windows Hypervisor Platform如果Hyper-V和第三方的沙盒軟件沖突比如舊版VMware、部分安卓模擬器也可能導(dǎo)致虛擬化檢測(cè)失敗這種情況下關(guān)閉沖突軟件的虛擬化獨(dú)占功能即可。還有一類特殊情況Windows系統(tǒng)更新補(bǔ)丁導(dǎo)致WSL2內(nèi)核組件損壞。表現(xiàn)是wsl --status異常。用管理員執(zhí)行wsl --update可以修復(fù)。4.3 驅(qū)動(dòng)版本、CUDA版本與鏡像版本的匹配關(guān)系三者的關(guān)系比很多人想象的寬松。NVIDIA驅(qū)動(dòng)具備向后兼容性新的驅(qū)動(dòng)可以運(yùn)行舊版的CUDA但舊驅(qū)動(dòng)跑不了新版CUDA。所以宿主機(jī)驅(qū)動(dòng)的原則是選新不選舊而應(yīng)用鏡像里的CUDA版本按任務(wù)需求來(lái)。舉個(gè)例子宿主機(jī)安裝Driver 550CUDA 12.1、12.4這些鏡像都能跑反過(guò)來(lái)宿主機(jī)驅(qū)動(dòng)是470CUDA 12.4的應(yīng)用鏡像大概率就會(huì)報(bào)CUDA init失敗。所以環(huán)境準(zhǔn)備階段我建議直接安裝當(dāng)前官網(wǎng)主流的穩(wěn)定版驅(qū)動(dòng)給后續(xù)應(yīng)用鏡像留足向上兼容的空間。關(guān)于CUDA鏡像標(biāo)簽的命名需要提一句nvidia/cuda鏡像分為base、runtime、devel三個(gè)層級(jí)。base只包含最基礎(chǔ)的CUDA庫(kù)runtime加了運(yùn)行時(shí)devel才有完整的開發(fā)工具鏈。調(diào)度普通推理任務(wù)用runtime就夠訓(xùn)練任務(wù)需要編譯算子時(shí)選devel。4.4 網(wǎng)絡(luò)不通、鏡像拉取慢的處理思路Docker環(huán)境搭建后下一個(gè)常見痛點(diǎn)是網(wǎng)絡(luò)。鏡像拉取超時(shí)、下載到一半中斷單憑這個(gè)原因就能讓環(huán)境準(zhǔn)備卡住一整天。首要對(duì)策是前面提到的registry-mirrors配置。多填幾個(gè)備選鏡像源。第二個(gè)對(duì)策是給容器配置HTTP代理環(huán)境變量這個(gè)適合公司網(wǎng)絡(luò)需要通過(guò)代理訪問外網(wǎng)的情況。還有一類隱蔽問題是容器內(nèi)的DNS解析異常表現(xiàn)是容器內(nèi)apt-get update失敗但宿主機(jī)網(wǎng)絡(luò)正常。這種問題可以在daemon.json里配dns: [8.8.8.8, 114.114.114.114]解決。另外容器網(wǎng)絡(luò)和宿主機(jī)網(wǎng)段沖突也會(huì)引發(fā)詭異現(xiàn)象。Docker默認(rèn)bridge網(wǎng)絡(luò)的網(wǎng)段是172.17.0.0/16如果宿主機(jī)所在的內(nèi)網(wǎng)正好在同一個(gè)網(wǎng)段容器訪問內(nèi)網(wǎng)服務(wù)就會(huì)出現(xiàn)路由異常。處理方式是修改daemon.json里的bip參數(shù)把這個(gè)網(wǎng)段改掉比如bip: 10.66.0.1/24。4.5 附環(huán)境準(zhǔn)備快速排查表癥狀大概率原因快速處理容器內(nèi)執(zhí)行nvidia-smi: command not foundContainer Toolkit未安裝或未注冊(cè)運(yùn)行時(shí)安裝Toolkit并執(zhí)行nvidia-ctk runtime configure --runtimedockerDocker Desktop啟動(dòng)提示virtualization support未檢測(cè)到BIOS未開虛擬化WSL2組件缺失開啟VT-x/AMD-Vwsl --update宿主機(jī)nvidia-smi失敗驅(qū)動(dòng)未加載或Secure Boot阻擋驅(qū)動(dòng)模塊重啟檢查dmesg容器內(nèi)CUDA應(yīng)用報(bào)版本不匹配驅(qū)動(dòng)版本過(guò)老或應(yīng)用對(duì)應(yīng)CUDA版本過(guò)高升級(jí)宿主機(jī)驅(qū)動(dòng)torch.cuda.is_available()返回False裝了CPU版PyTorch用官方鏡像或指定cu121/cu124索引重新安裝鏡像拉取超時(shí)或中斷鏡像源不穩(wěn)定或網(wǎng)絡(luò)問題配置registry-mirrors必要時(shí)配置代理容器內(nèi)訪問內(nèi)網(wǎng)服務(wù)不通Docker網(wǎng)段和宿主機(jī)局域網(wǎng)沖突修改daemon.json的bip參數(shù)調(diào)整網(wǎng)段日志寫滿磁盤導(dǎo)致容器異常日志無(wú)限增長(zhǎng)data-root空間耗盡配置log-opts限制日志大小將data-root遷移到大分區(qū)5. 環(huán)境準(zhǔn)備完成后下一步往哪走環(huán)境準(zhǔn)備這層踩實(shí)之后算力調(diào)度平臺(tái)才算真正有了地基?；仡欉@篇文章的內(nèi)容核心其實(shí)就三件事Docker正常跑、GPU驅(qū)動(dòng)正常加載、Container Toolkit把GPU暴露給容器。三步走完單機(jī)上的容器化GPU環(huán)境就具備了。這個(gè)過(guò)程中有幾個(gè)我特別想再?gòu)?qiáng)調(diào)的體會(huì)。第一環(huán)境準(zhǔn)備不要趕進(jìn)度每一層都要驗(yàn)證通過(guò)再往下走。宿主機(jī)驅(qū)動(dòng)沒驗(yàn)證就直接裝Toolkit出問題了根本不知道是驅(qū)動(dòng)還是Toolkit的問題。第二Docker的daemon.json要早規(guī)劃磁盤、日志、網(wǎng)段這些都是運(yùn)行時(shí)才暴雷的問題與其等生產(chǎn)環(huán)境出故障再去救火不如現(xiàn)在就把參數(shù)定好。第三日志和監(jiān)控從一開始就要留好后續(xù)做算力調(diào)度時(shí)每個(gè)節(jié)點(diǎn)的GPU利用率、顯存占用、任務(wù)狀態(tài)都要有數(shù)據(jù)可查。接下來(lái)這個(gè)系列要處理的問題會(huì)更復(fù)雜多節(jié)點(diǎn)下怎么統(tǒng)一管理GPU資源任務(wù)調(diào)度怎么做顯存怎么隔離鏡像倉(cāng)庫(kù)怎么搭建。但這些都是在當(dāng)前這套Docker加GPU環(huán)境上繼續(xù)疊加。環(huán)境穩(wěn)了后面的事才有討論的前提。下一篇我會(huì)寫多機(jī)環(huán)境下GPU資源的管理和任務(wù)調(diào)度的初步方案那是算力調(diào)度平臺(tái)真正進(jìn)入到核心邏輯的部分。恰好我手里還有一臺(tái)沒裝驅(qū)動(dòng)的備用機(jī)正好用來(lái)驗(yàn)證多節(jié)點(diǎn)方案到時(shí)候?qū)崪y(cè)數(shù)據(jù)直接寫到下篇里。 算力調(diào)度平臺(tái)環(huán)境準(zhǔn)備：Docker與GPU聯(lián)動(dòng)實(shí)戰(zhàn)指南
算力調(diào)度平臺(tái)這個(gè)系列寫到第二篇環(huán)境準(zhǔn)備是繞不開的第一道坎。上篇聊了整體架構(gòu)和資源抽象的思路對(duì)平臺(tái)要解決什么問題、怎么把GPU資源池化和切分已經(jīng)有了大方向。這篇接著往下推進(jìn)把最底層的環(huán)境底座搭起來(lái)Docker和GPU聯(lián)動(dòng)。如果你是從這一篇開始看的也不影響環(huán)境準(zhǔn)備這層是獨(dú)立的照著做就行。為什么把環(huán)境準(zhǔn)備單獨(dú)拎出來(lái)寫一篇因?yàn)樗懔φ{(diào)度平臺(tái)后續(xù)所有東西——K8s調(diào)度、GPU顯存隔離、任務(wù)編排、鏡像分發(fā)——都建立在一套能穩(wěn)定運(yùn)行的容器加GPU環(huán)境上。環(huán)境沒搭好后面每一步都會(huì)遇到莫名其妙的坑。比如容器里跑深度學(xué)習(xí)任務(wù)時(shí)提示CUDA不可用或者Docker Desktop一啟動(dòng)就報(bào)虛擬化錯(cuò)誤又或者宿主機(jī)nvidia-smi正常但容器里死活看不到GPU這些問題的根源十有八九都出在環(huán)境準(zhǔn)備階段。這篇會(huì)把Docker安裝、GPU驅(qū)動(dòng)、NVIDIA Container Toolkit、容器內(nèi)GPU驗(yàn)證這幾個(gè)環(huán)節(jié)完整過(guò)一遍附帶我實(shí)際部署中踩過(guò)的坑和排查方法盡量讓你照著做一遍就能把環(huán)境跑通。1. 環(huán)境準(zhǔn)備這件事先想清楚再動(dòng)手1.1 算力調(diào)度平臺(tái)為什么非要Docker加GPU這套組合先明確一個(gè)問題算力調(diào)度平臺(tái)要調(diào)度的是什么表面上是任務(wù)和容器本質(zhì)上調(diào)度的是計(jì)算資源重點(diǎn)是GPU。深度學(xué)習(xí)的訓(xùn)練和推理、大模型的微調(diào)、科學(xué)計(jì)算這些場(chǎng)景對(duì)GPU的依賴遠(yuǎn)超CPU。所以一個(gè)調(diào)度平臺(tái)要真正落地它的底層必須有能力回答三個(gè)問題某個(gè)任務(wù)能用哪張GPU卡、能用多大顯存、任務(wù)跑起來(lái)容器內(nèi)部能不能實(shí)際訪問到GPU的計(jì)算能力。Docker在這里扮演的角色是標(biāo)準(zhǔn)化封裝和隔離。每個(gè)任務(wù)打包成一個(gè)鏡像環(huán)境依賴、CUDA版本、Python環(huán)境全部固化在鏡像里任務(wù)發(fā)到哪臺(tái)機(jī)器跑起來(lái)效果都一樣。GPU則通過(guò)驅(qū)動(dòng)和運(yùn)行時(shí)暴露給容器讓容器內(nèi)的CUDA應(yīng)用可以直通宿主機(jī)顯卡。這套組合的核心價(jià)值在于環(huán)境隔離做到了資源復(fù)用了任務(wù)還保持了可遷移性。如果你不是這次做調(diào)度平臺(tái)只是單純想在自己機(jī)器上跑深度學(xué)習(xí)這套環(huán)境準(zhǔn)備同樣是通用的。本地開發(fā)、模型微調(diào)、論文復(fù)現(xiàn)都需要先過(guò)這一關(guān)。所以這篇內(nèi)容不管你是要搭一個(gè)大平臺(tái)還是只想把單機(jī)GPU環(huán)境搞好都有直接參考價(jià)值。1.2 方案選型為什么是Docker而不是裸機(jī)或虛擬機(jī)聊一下我在環(huán)境選型上的思考過(guò)程。最樸素的做法是在裸機(jī)上裝驅(qū)動(dòng)、裝CUDA、裝Python環(huán)境然后直接跑訓(xùn)練腳本。這在單機(jī)單卡、沒有多人協(xié)作的情況下沒問題但一旦任務(wù)變多、環(huán)境需求沖突比如一個(gè)任務(wù)要CUDA 11.8另一個(gè)要CUDA 12.1裸機(jī)方案就亂了。你總不能每切換一次任務(wù)就重裝一遍環(huán)境這在工程上是不可接受的。虛擬機(jī)方案可以隔離環(huán)境但有兩個(gè)硬傷一是虛擬化層對(duì)GPU的透?jìng)髋渲脧?fù)雜虛擬機(jī)和宿主機(jī)之間的性能損耗在計(jì)算密集型任務(wù)里不可忽略二是虛擬機(jī)動(dòng)輒幾十GB鏡像起停時(shí)間以分鐘計(jì)在調(diào)度場(chǎng)景下完全跟不上節(jié)奏。Docker正好落在中間進(jìn)程級(jí)隔離啟動(dòng)秒級(jí)完成鏡像分層復(fù)用GPU直通時(shí)不引入明顯的性能損耗。對(duì)于算力調(diào)度平臺(tái)這種需要頻繁創(chuàng)建、銷毀任務(wù)運(yùn)行環(huán)境的場(chǎng)景容器是當(dāng)前性價(jià)比最高的方案。這也是為什么當(dāng)下主流AI基礎(chǔ)設(shè)施——K8s、各種訓(xùn)練平臺(tái)、推理服務(wù)框架——幾乎全部以容器為底座。選Docker不是跟風(fēng)是這個(gè)場(chǎng)景下的工程理性。1.3 前置檢查清單動(dòng)手前先花十分鐘確認(rèn)這些事無(wú)論在Linux還是Windows上做環(huán)境準(zhǔn)備有幾項(xiàng)前置條件必須先確認(rèn)不然后面報(bào)錯(cuò)會(huì)報(bào)得你懷疑人生。操作系統(tǒng)版本Docker和GPU驅(qū)動(dòng)對(duì)系統(tǒng)都有版本要求Ubuntu 22.04 LTS是目前兼容性最穩(wěn)妥的選擇。Windows的話建議Windows 11并打開WSL2功能。內(nèi)核版本Linux下Docker對(duì)內(nèi)核有最低版本要求64位系統(tǒng)、內(nèi)核版本建議不低于5.x。太老的內(nèi)核建議先升級(jí)。虛擬化支持Windows上跑Docker Desktop必須開啟CPU虛擬化也就是BIOS里的Intel VT-x或AMD-V。這個(gè)不開Docker Desktop根本起不來(lái)。GPU與驅(qū)動(dòng)版本先確認(rèn)你的顯卡型號(hào)和NVIDIA驅(qū)動(dòng)版本支持情況。老顯卡可能要裝特定版本驅(qū)動(dòng)新顯卡太新反而可能遇到驅(qū)動(dòng)還沒跟上的問題這在部署時(shí)經(jīng)常遇到。磁盤空間AI相關(guān)的鏡像和容器動(dòng)輒幾個(gè)GB到十幾個(gè)GB建議單獨(dú)規(guī)劃一個(gè)容量充足的數(shù)據(jù)盤。我經(jīng)歷過(guò)/var/lib/docker所在分區(qū)被打滿導(dǎo)致所有容器異常退出的事故所以現(xiàn)在一律先把data-root指到大磁盤上。這些檢查項(xiàng)看著瑣碎但每一件都在實(shí)際排障中救過(guò)我的命。花十分鐘確認(rèn)比出問題后再排查兩小時(shí)劃算得多。2. Docker環(huán)境安裝與基礎(chǔ)配置2.1 Linux宿主機(jī)安裝Docker以Ubuntu為例生產(chǎn)環(huán)境我強(qiáng)烈建議直接用Linux裸機(jī)或Linux虛擬機(jī)作為宿主機(jī)。這是算力調(diào)度平臺(tái)真正要跑起來(lái)的地方Windows只適合做開發(fā)調(diào)試。以Ubuntu 22.04為例安裝Docker的過(guò)程可以固化成一個(gè)標(biāo)準(zhǔn)操作sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg lsb-release sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin幾個(gè)容易被坑的點(diǎn)第一不要用系統(tǒng)自帶源里的docker.io包版本老舊后續(xù)容器運(yùn)行時(shí)兼容性差。第二安裝的是docker-ce社區(qū)版這是最主流的選擇不要用早期的docker-engine。第三docker-compose-plugin順手裝上后面編排多容器任務(wù)會(huì)用到。安裝完成后的標(biāo)準(zhǔn)操作是把當(dāng)前用戶加入docker組避免每次執(zhí)行docker命令都要sudo。注意這個(gè)操作有安全邊界docker組內(nèi)的用戶等價(jià)于擁有宿主機(jī)root權(quán)限所以在多人共享的機(jī)器上要謹(jǐn)慎不能為了省事無(wú)腦把所有人加進(jìn)去。sudo usermod -aG docker $USER newgrp docker然后啟動(dòng)并設(shè)置開機(jī)自啟sudo systemctl enable docker sudo systemctl start docker2.2 配置daemon.json存儲(chǔ)、網(wǎng)絡(luò)與日志裝好Docker只是第一步真正讓它在生產(chǎn)環(huán)境里穩(wěn)如老狗靠的是/etc/docker/daemon.json的配置。我常用的一個(gè)基礎(chǔ)配置長(zhǎng)這樣{ data-root: /data/docker, log-driver: json-file, log-opts: { max-size: 200m, max-file: 5 }, registry-mirrors: [], exec-opts: [native.cgroupdriversystemd] }>sudo systemctl daemon-reload sudo systemctl restart docker2.3 Windows場(chǎng)景下的Docker Desktop與WSL2開發(fā)調(diào)試階段很多同事習(xí)慣在Windows上工作。Docker Desktop現(xiàn)在的主流形態(tài)是WSL2后端其實(shí)就是讓Docker跑在一個(gè)輕量級(jí)虛擬機(jī)里。這個(gè)模式下有兩個(gè)前置條件必須滿足BIOS開啟虛擬化并且Windows里裝好WSL2。檢查虛擬化是否開啟任務(wù)管理器性能標(biāo)簽頁(yè)里能看到虛擬化狀態(tài)。如果顯示已啟用繼續(xù)裝WSLwsl --install wsl --set-default-version 2Docker Desktop安裝包下載安裝后在Settings里把Use the WSL 2 based engine勾上。如果這里啟動(dòng)報(bào)錯(cuò)virtualization support wasnt detected先回BIOS確認(rèn)VT-x/AMD-V是否打開再確認(rèn)Windows功能里的Virtual Machine Platform和Windows Hypervisor Platform這兩個(gè)組件是否啟用。Windows上用Docker Desktop要注意文件掛載的性能問題?？缥募到y(tǒng)掛載在WSL2里I/O性能較弱編譯類、大量小文件讀寫的任務(wù)會(huì)明顯卡頓。一個(gè)折中做法是把代碼放到WSL2的Linux文件系統(tǒng)里而不是放在Windows盤符下掛載進(jìn)容器。2.4 安裝后第一件事跑通一個(gè)容器環(huán)境裝好后先用一個(gè)最小的容器驗(yàn)證Docker本身是否正常docker run --rm hello-world看到Hello from Docker!就說(shuō)明Docker守護(hù)進(jìn)程、鏡像拉取、容器啟停這條鏈路都通了。接著跑一個(gè)交互式容器驗(yàn)證基本的終端和網(wǎng)絡(luò)能力docker run -it --rm ubuntu:22.04 bash apt-get update這兩個(gè)小測(cè)試的必要性在于把基礎(chǔ)鏈路和網(wǎng)絡(luò)源的問題提前暴露掉避免后面GPU環(huán)境準(zhǔn)備時(shí)把基礎(chǔ)問題和GPU問題混在一起排查。我見過(guò)有人在一個(gè)網(wǎng)絡(luò)都沒通的Docker環(huán)境里折騰GPU排查了半天最后發(fā)現(xiàn)是鏡像根本拉不動(dòng)白白浪費(fèi)了兩小時(shí)。3. GPU支持打通驅(qū)動(dòng)、運(yùn)行時(shí)與容器3.1 宿主機(jī)GPU驅(qū)動(dòng)安裝與驗(yàn)證Docker就緒后開始處理GPU。第一步確保宿主機(jī)本身能識(shí)別GPU。Linux上安裝NVIDIA驅(qū)動(dòng)有兩類主流方式用apt安裝發(fā)行版?zhèn)}庫(kù)里的驅(qū)動(dòng)包或者用NVIDIA官網(wǎng)的runfile安裝腳本。apt方式在Ubuntu上很省事sudo apt-get update sudo ubuntu-drivers devices sudo apt-get install -y nvidia-driver-550ubuntu-drivers devices會(huì)列出當(dāng)前機(jī)器推薦的驅(qū)動(dòng)版本照著裝就行。裝完重啟執(zhí)行nvidia-smi能看到顯卡型號(hào)、驅(qū)動(dòng)版本、顯存信息說(shuō)明驅(qū)動(dòng)工作正常。這里我提一個(gè)反直覺的細(xì)節(jié)nvidia-smi里的CUDA Version不是系統(tǒng)里安裝的CUDA工具包版本而是當(dāng)前驅(qū)動(dòng)支持的最高CUDA運(yùn)行時(shí)版本。應(yīng)用實(shí)際使用的CUDA版本由容器或應(yīng)用自身的CUDA庫(kù)決定只要不超過(guò)這個(gè)上限即可。很多人把這兩者混為一談導(dǎo)致后面裝CUDA時(shí)選錯(cuò)版本。踩坑提示Ubuntu從22.04開始默認(rèn)啟用Secure Boot如果BIOS里沒關(guān)安裝NVIDIA驅(qū)動(dòng)后模塊可能無(wú)法加載。表現(xiàn)是nvidia-smi提示找不到命令或報(bào)NVIDIA-SMI has failed because it couldnt communicate with the NVIDIA driver。解決辦法有兩種Secure Boot關(guān)閉后重裝驅(qū)動(dòng)或者給DKMS模塊做MOK簽名。命令行簽名流程比較繁瑣環(huán)境準(zhǔn)備階段我直接建議在測(cè)試機(jī)上關(guān)閉Secure Boot生產(chǎn)環(huán)境則要提前規(guī)劃好簽名流程。3.2 安裝NVIDIA Container Toolkit宿主機(jī)能看到GPU不等于容器里能看到GPU。中間缺的關(guān)鍵組件叫NVIDIA Container Toolkit它負(fù)責(zé)在Docker容器啟動(dòng)時(shí)把GPU設(shè)備、驅(qū)動(dòng)庫(kù)和nvidia-smi工具注入到容器的運(yùn)行環(huán)境里。這里解釋一下原理Docker本身不認(rèn)識(shí)GPU硬件。沒有Toolkit時(shí)即使宿主機(jī)的/dev/nvidia0設(shè)備節(jié)點(diǎn)就在那里容器默認(rèn)也訪問不到。NVIDIA Container Toolkit做的事是在容器創(chuàng)建時(shí)通過(guò)prestart hook動(dòng)態(tài)向容器配置注入GPU設(shè)備和驅(qū)動(dòng)庫(kù)讓容器內(nèi)的CUDA應(yīng)用能夠和宿主機(jī)驅(qū)動(dòng)通信。執(zhí)行安裝curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \ sed s#deb https://#deb [signed-by/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g | \ sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit然后配置Docker的運(yùn)行時(shí)sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart dockernvidia-ctk runtime configure這個(gè)命令會(huì)把NVIDIA Container Runtime注冊(cè)到Docker的運(yùn)行時(shí)配置里。重啟Docker后docker info里應(yīng)該能看到Runtimes: nvidia這一項(xiàng)。這一步做完Docker才真正具備了把GPU暴露給容器的能力。3.3 容器內(nèi)nvidia-smi驗(yàn)證驗(yàn)證是最激動(dòng)人心的一步。拉一個(gè)帶CUDA的基礎(chǔ)鏡像從容器里執(zhí)行nvidia-smidocker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi如果你看到宿主機(jī)里那張熟悉的信息表出現(xiàn)在容器內(nèi)說(shuō)明GPU打通了。注意一個(gè)細(xì)節(jié)容器內(nèi)nvidia-smi顯示的Driver Version和宿主機(jī)的驅(qū)動(dòng)版本通常是一致的。因?yàn)槿萜骼锏尿?qū)動(dòng)庫(kù)直接借用宿主機(jī)驅(qū)動(dòng)容器內(nèi)并沒有真正的驅(qū)動(dòng)內(nèi)核模塊。這是正常設(shè)計(jì)不是配置錯(cuò)了。再驗(yàn)證一下容器能否真正執(zhí)行CUDA計(jì)算。用一個(gè)帶CUDA runtime的鏡像在容器內(nèi)跑一段GPU運(yùn)算docker run --rm --gpus all nvidia/cuda:12.4.0-runtime-ubuntu22.04 bash -c cat /usr/local/cuda/version.json如果只是想確認(rèn)設(shè)備可用可以寫一段小的CUDA樣例程序或者直接驗(yàn)證PyTorch。但是要注意整個(gè)CUDA鏡像體積不小動(dòng)輒兩三個(gè)GB。如果只為了驗(yàn)證環(huán)境用nvidia/cuda:12.4.0-base-ubuntu22.04就夠了。3.4 PyTorch GPU環(huán)境實(shí)測(cè)GPU環(huán)境和Docker打通后再上一個(gè)大名鼎鼎的PyTorch做最終驗(yàn)證。這一步模擬的是真實(shí)的深度學(xué)習(xí)運(yùn)行環(huán)境。首先拉取官方PyTorch鏡像docker run -it --rm --gpus all -v /workspace:/workspace pytorch/pytorch:2.3.0-cuda12.1-cudnn8-runtime bash容器內(nèi)執(zhí)行python -c import torch; print(torch.__version__); print(torch.cuda.is_available()); print(torch.cuda.device_count()); print(torch.cuda.get_device_name(0))如果輸出True和你的顯卡型號(hào)算力調(diào)度平臺(tái)的單機(jī)GPU環(huán)境就算真正落定了。這一步能跑通說(shuō)明驅(qū)動(dòng)、Container Toolkit、Docker、CUDA運(yùn)行庫(kù)之間的所有鏈路都是通的。這里有一個(gè)常見問題在容器內(nèi)用pip安裝PyTorch時(shí)默認(rèn)安裝的是CPU版導(dǎo)致運(yùn)行torch.cuda.is_available()返回False。這是因?yàn)镻yTorch從2.0版本開始默認(rèn)pip索引里的包不一定帶CUDA支持。解決辦法是顯式安裝帶CUDA索引的版本。這一點(diǎn)在多臺(tái)機(jī)器上是很容易踩的坑。4. 環(huán)境準(zhǔn)備階段的典型問題與排查實(shí)錄4.1 容器里看不到GPU八成是Toolkit的問題癥狀宿主機(jī)nvidia-smi正常但容器里執(zhí)行nvidia-smi提示command not found或者運(yùn)行帶--gpus all命令時(shí)報(bào)錯(cuò)。排查順序按概率排列第一確認(rèn)docker info里有沒有顯示Runtimes: nvidia沒有就說(shuō)明Container Toolkit沒配置好重新執(zhí)行nvidia-ctk runtime configure并重啟Docker。第二確認(rèn)容器命令里加了--gpus all參數(shù)老版本Docker如果沒有這個(gè)參數(shù)在run時(shí)也看不到GPU。第三確認(rèn)驅(qū)動(dòng)和Toolkit版本兼容性。第四檢查/dev/nvidia*設(shè)備節(jié)點(diǎn)是否存在如果設(shè)備節(jié)點(diǎn)異常多半是驅(qū)動(dòng)模塊加載有問題。按這個(gè)順序排查絕大多數(shù)情況都能定位。4.2 Docker Desktop啟動(dòng)失敗的虛擬化問題Windows場(chǎng)景下Docker Desktop最常見的啟動(dòng)失敗報(bào)錯(cuò)是virtualization support wasnt detected。這個(gè)報(bào)錯(cuò)說(shuō)白了就是WSL2依賴的虛擬化能力沒有就緒。排查從三個(gè)層面展開BIOS里開啟Intel VT-x或AMD-VWindows功能里啟用Virtual Machine Platform和Windows Hypervisor Platform如果Hyper-V和第三方的沙盒軟件沖突比如舊版VMware、部分安卓模擬器也可能導(dǎo)致虛擬化檢測(cè)失敗這種情況下關(guān)閉沖突軟件的虛擬化獨(dú)占功能即可。還有一類特殊情況Windows系統(tǒng)更新補(bǔ)丁導(dǎo)致WSL2內(nèi)核組件損壞。表現(xiàn)是wsl --status異常。用管理員執(zhí)行wsl --update可以修復(fù)。4.3 驅(qū)動(dòng)版本、CUDA版本與鏡像版本的匹配關(guān)系三者的關(guān)系比很多人想象的寬松。NVIDIA驅(qū)動(dòng)具備向后兼容性新的驅(qū)動(dòng)可以運(yùn)行舊版的CUDA但舊驅(qū)動(dòng)跑不了新版CUDA。所以宿主機(jī)驅(qū)動(dòng)的原則是選新不選舊而應(yīng)用鏡像里的CUDA版本按任務(wù)需求來(lái)。舉個(gè)例子宿主機(jī)安裝Driver 550CUDA 12.1、12.4這些鏡像都能跑反過(guò)來(lái)宿主機(jī)驅(qū)動(dòng)是470CUDA 12.4的應(yīng)用鏡像大概率就會(huì)報(bào)CUDA init失敗。所以環(huán)境準(zhǔn)備階段我建議直接安裝當(dāng)前官網(wǎng)主流的穩(wěn)定版驅(qū)動(dòng)給后續(xù)應(yīng)用鏡像留足向上兼容的空間。關(guān)于CUDA鏡像標(biāo)簽的命名需要提一句nvidia/cuda鏡像分為base、runtime、devel三個(gè)層級(jí)。base只包含最基礎(chǔ)的CUDA庫(kù)runtime加了運(yùn)行時(shí)devel才有完整的開發(fā)工具鏈。調(diào)度普通推理任務(wù)用runtime就夠訓(xùn)練任務(wù)需要編譯算子時(shí)選devel。4.4 網(wǎng)絡(luò)不通、鏡像拉取慢的處理思路Docker環(huán)境搭建后下一個(gè)常見痛點(diǎn)是網(wǎng)絡(luò)。鏡像拉取超時(shí)、下載到一半中斷單憑這個(gè)原因就能讓環(huán)境準(zhǔn)備卡住一整天。首要對(duì)策是前面提到的registry-mirrors配置。多填幾個(gè)備選鏡像源。第二個(gè)對(duì)策是給容器配置HTTP代理環(huán)境變量這個(gè)適合公司網(wǎng)絡(luò)需要通過(guò)代理訪問外網(wǎng)的情況。還有一類隱蔽問題是容器內(nèi)的DNS解析異常表現(xiàn)是容器內(nèi)apt-get update失敗但宿主機(jī)網(wǎng)絡(luò)正常。這種問題可以在daemon.json里配dns: [8.8.8.8, 114.114.114.114]解決。另外容器網(wǎng)絡(luò)和宿主機(jī)網(wǎng)段沖突也會(huì)引發(fā)詭異現(xiàn)象。Docker默認(rèn)bridge網(wǎng)絡(luò)的網(wǎng)段是172.17.0.0/16如果宿主機(jī)所在的內(nèi)網(wǎng)正好在同一個(gè)網(wǎng)段容器訪問內(nèi)網(wǎng)服務(wù)就會(huì)出現(xiàn)路由異常。處理方式是修改daemon.json里的bip參數(shù)把這個(gè)網(wǎng)段改掉比如bip: 10.66.0.1/24。4.5 附環(huán)境準(zhǔn)備快速排查表癥狀大概率原因快速處理容器內(nèi)執(zhí)行nvidia-smi: command not foundContainer Toolkit未安裝或未注冊(cè)運(yùn)行時(shí)安裝Toolkit并執(zhí)行nvidia-ctk runtime configure --runtimedockerDocker Desktop啟動(dòng)提示virtualization support未檢測(cè)到BIOS未開虛擬化WSL2組件缺失開啟VT-x/AMD-Vwsl --update宿主機(jī)nvidia-smi失敗驅(qū)動(dòng)未加載或Secure Boot阻擋驅(qū)動(dòng)模塊重啟檢查dmesg容器內(nèi)CUDA應(yīng)用報(bào)版本不匹配驅(qū)動(dòng)版本過(guò)老或應(yīng)用對(duì)應(yīng)CUDA版本過(guò)高升級(jí)宿主機(jī)驅(qū)動(dòng)torch.cuda.is_available()返回False裝了CPU版PyTorch用官方鏡像或指定cu121/cu124索引重新安裝鏡像拉取超時(shí)或中斷鏡像源不穩(wěn)定或網(wǎng)絡(luò)問題配置registry-mirrors必要時(shí)配置代理容器內(nèi)訪問內(nèi)網(wǎng)服務(wù)不通Docker網(wǎng)段和宿主機(jī)局域網(wǎng)沖突修改daemon.json的bip參數(shù)調(diào)整網(wǎng)段日志寫滿磁盤導(dǎo)致容器異常日志無(wú)限增長(zhǎng)data-root空間耗盡配置log-opts限制日志大小將data-root遷移到大分區(qū)5. 環(huán)境準(zhǔn)備完成后下一步往哪走環(huán)境準(zhǔn)備這層踩實(shí)之后算力調(diào)度平臺(tái)才算真正有了地基?；仡欉@篇文章的內(nèi)容核心其實(shí)就三件事Docker正常跑、GPU驅(qū)動(dòng)正常加載、Container Toolkit把GPU暴露給容器。三步走完單機(jī)上的容器化GPU環(huán)境就具備了。這個(gè)過(guò)程中有幾個(gè)我特別想再?gòu)?qiáng)調(diào)的體會(huì)。第一環(huán)境準(zhǔn)備不要趕進(jìn)度每一層都要驗(yàn)證通過(guò)再往下走。宿主機(jī)驅(qū)動(dòng)沒驗(yàn)證就直接裝Toolkit出問題了根本不知道是驅(qū)動(dòng)還是Toolkit的問題。第二Docker的daemon.json要早規(guī)劃磁盤、日志、網(wǎng)段這些都是運(yùn)行時(shí)才暴雷的問題與其等生產(chǎn)環(huán)境出故障再去救火不如現(xiàn)在就把參數(shù)定好。第三日志和監(jiān)控從一開始就要留好后續(xù)做算力調(diào)度時(shí)每個(gè)節(jié)點(diǎn)的GPU利用率、顯存占用、任務(wù)狀態(tài)都要有數(shù)據(jù)可查。接下來(lái)這個(gè)系列要處理的問題會(huì)更復(fù)雜多節(jié)點(diǎn)下怎么統(tǒng)一管理GPU資源任務(wù)調(diào)度怎么做顯存怎么隔離鏡像倉(cāng)庫(kù)怎么搭建。但這些都是在當(dāng)前這套Docker加GPU環(huán)境上繼續(xù)疊加。環(huán)境穩(wěn)了后面的事才有討論的前提。下一篇我會(huì)寫多機(jī)環(huán)境下GPU資源的管理和任務(wù)調(diào)度的初步方案那是算力調(diào)度平臺(tái)真正進(jìn)入到核心邏輯的部分。恰好我手里還有一臺(tái)沒裝驅(qū)動(dòng)的備用機(jī)正好用來(lái)驗(yàn)證多節(jié)點(diǎn)方案到時(shí)候?qū)崪y(cè)數(shù)據(jù)直接寫到下篇里。