編譯過深度學(xué)習(xí)框架的人十有八九都被“計(jì)算能力Compute Capability”這個(gè)東西卡過。要不就是編譯時(shí)刷出一排Unsupported gpu architecture要不就是同一個(gè)安裝包在這塊卡上跑得好好的換到另一塊卡上直接報(bào)no kernel image is available for execution on the device。我第一次在 caffe 上踩這個(gè)坑時(shí)硬生生折騰到凌晨?jī)牲c(diǎn)最后才發(fā)現(xiàn)問題就出在一個(gè)小數(shù)字上——GPU 計(jì)算能力。這篇就把這個(gè)數(shù)字的前因后果講透順手給出 caffe / pytorch / tensorflow 里設(shè)置計(jì)算能力的具體寫法和翻車應(yīng)急預(yù)案。適合所有需要從源碼構(gòu)建框架的開發(fā)者、算法工程師以及被 CUDA 環(huán)境逼到懷疑人生的人。1. 先搞懂“計(jì)算能力”這個(gè)數(shù)字它就是 GPU 的架構(gòu)版本號(hào)1.1 數(shù)字拆解主版本號(hào)是“代”次版本號(hào)是“檔”計(jì)算能力Compute Capability寫出來長(zhǎng)這樣8.6、7.5、9.0。它本質(zhì)上就是 GPU 硬件架構(gòu)的版本號(hào)前一位代表大代際后一位代表同代際里的細(xì)分檔位。比如8.6意味著這是 Ampere 大架構(gòu)下的消費(fèi)卡檔位RTX 3090 就是 8.6。而 A100 同樣是 Ampere 架構(gòu)卻是8.0。同一個(gè)架構(gòu)代際內(nèi)不同芯片的指令集和硬件特性有差異所以才有8.0、8.6、8.9這種細(xì)分編號(hào)。在編譯參數(shù)里這個(gè)數(shù)字還會(huì)變成兩種寫法sm_86SASS 目標(biāo)架構(gòu)生成的就是這塊卡直接執(zhí)行的機(jī)器碼。compute_86PTX 目標(biāo)架構(gòu)生成的是中間表示后續(xù)可以由驅(qū)動(dòng)現(xiàn)場(chǎng)編譯到具體 GPU。我見過不少新手把sm_75和compute_75當(dāng)成一回事其實(shí)它們對(duì)應(yīng)的是兩種不同形態(tài)的產(chǎn)物這也是后面絕大多數(shù)編譯坑的根源。1.2 一張表看懂各大架構(gòu)的計(jì)算能力區(qū)間我把這些年主流的 GPU 架構(gòu)按計(jì)算能力梳理了一下方便對(duì)號(hào)入座架構(gòu)代際計(jì)算能力典型 GPU 型號(hào)大概年代Fermi2.0 / 2.1GTX 4xx / 5xx2010 左右Kepler3.0 / 3.5 / 3.7GTX 680 / Tesla K402012 左右Maxwell5.0 / 5.2 / 5.3GTX 750 / GTX 9802014 左右Pascal6.0 / 6.1Tesla P100 / GTX 1080 Ti2016 左右Volta7.0Tesla V1002017 左右Turing7.5RTX 2080 Ti / RTX 20602018 左右Ampere8.0 / 8.6A100 / RTX 30902020 左右Ada Lovelace8.9RTX 40902022 左右Hopper9.0H1002023 左右2024 年之后的新架構(gòu)計(jì)算能力已經(jīng)突破 10.x后續(xù)還會(huì)有新編號(hào)具體以廠商官方規(guī)格頁為準(zhǔn)。記住這張表的核心規(guī)律不同計(jì)算能力的 GPU它們的 SASS 機(jī)器碼是不通用的但 PTX 有更強(qiáng)的跨代兼容能力。1.3 計(jì)算能力決定了哪些實(shí)實(shí)在在的事情這個(gè)數(shù)字不只是一個(gè)“型號(hào)標(biāo)簽”它背后綁定了一整套硬件特性能力。具體來說指令集版本不同sm_86 能用的某些匯編指令sm_75 是不認(rèn)的。編譯器要針對(duì)具體計(jì)算能力生成對(duì)應(yīng)指令。Tensor Core 等特性不同8.0 以上的 Ampere 架構(gòu)對(duì) Tensor Core 的支持方式、WMMAwarp matrix multiply-accumulate指令版本都不一樣新框架的某些算子會(huì)針對(duì)高版本計(jì)算能力做專門優(yōu)化。CUDA Toolkit 版本兼容范圍不同老版本的 CUDA Toolkit 不一定認(rèn)識(shí)新計(jì)算能力。比如 CUDA 10.x 去編譯sm_86的代碼基本直接報(bào)錯(cuò)因?yàn)槟莻€(gè)年代還沒有 Ampere 的編譯器支持。運(yùn)行時(shí)行為不同程序跑起來后驅(qū)動(dòng)需要根據(jù) GPU 的計(jì)算能力加載對(duì)應(yīng)內(nèi)核匹配不上就崩。所以在深度學(xué)習(xí)框架的編譯場(chǎng)景里計(jì)算能力直接決定了“你編出來的這個(gè)庫到底能跑在哪些 GPU 上”。2. 編譯框架時(shí)為什么要跟這個(gè)數(shù)字較勁2.1 GPU 代碼的“提前編譯”與“運(yùn)行時(shí)兜底”很多框架PyTorch、TensorFlow、Caffe在安裝時(shí)都會(huì)把 CUDA 算子源碼提前編譯成二進(jìn)制而不是每次運(yùn)行都現(xiàn)場(chǎng)編譯。這個(gè)模式叫 AOTAhead Of Time提前編譯它和純 JITJust In Time運(yùn)行時(shí)編譯不同。AOT 的問題是你得在編譯時(shí)告訴編譯器“請(qǐng)按哪一代 GPU 的架構(gòu)來生成代碼”。如果你寫死了sm_86那生成的就是 RTX 30 系列認(rèn)識(shí)的機(jī)器碼一旦把編譯產(chǎn)物拿到計(jì)算能力 7.5 的 RTX 2080 上跑驅(qū)動(dòng)根本沒有辦法執(zhí)行這份 SASS 代碼因?yàn)樗鼔焊徽J(rèn)識(shí)。現(xiàn)代 CUDA 編譯有個(gè)兜底機(jī)制可以在生成 SASS 機(jī)器碼的同時(shí)也生成一份 PTX 中間代碼。PTX 像“跨架構(gòu)的應(yīng)急預(yù)案”當(dāng)驅(qū)動(dòng)發(fā)現(xiàn)當(dāng)前 GPU 沒有匹配的 SASS 時(shí)會(huì)嘗試把 PTX 現(xiàn)場(chǎng) JIT 成當(dāng)前計(jì)算能力能跑的代碼。但前提是你在編譯時(shí)確實(shí)附上了 PTX很多人恰恰漏了這一手。2.2 參數(shù)設(shè)高、設(shè)低、干脆不設(shè)分別是啥后果我把三種常見情況可能引發(fā)的后果列一下設(shè)得太高例如只寫8.9在老 GPU 上直接no kernel image。編譯產(chǎn)物像是專門給新卡寫的一封信老卡連拆信的機(jī)會(huì)都沒有。設(shè)得太低例如只寫5.0幾乎所有 GPU 都能兼容但新架構(gòu)的新指令全用不上。Tensor Core 加速等于擺設(shè)推理和訓(xùn)練性能會(huì)明顯偏低。干脆不設(shè)置這里的風(fēng)險(xiǎn)最大。不同構(gòu)建腳本的默認(rèn)值五花八門有的默認(rèn)只編當(dāng)前機(jī)器上探測(cè)到的架構(gòu)有的默認(rèn)編一個(gè)非常保守的老架構(gòu)。你在這臺(tái)機(jī)器上編譯時(shí)可能一切正常換到另一張卡上就跑不了。我見過一個(gè)最經(jīng)典的場(chǎng)景某人在一臺(tái) RTX 4090 機(jī)器上編譯完 PyTorch看起來很順利部署到一臺(tái) T4 推理機(jī)上直接崩。后來我把編譯日志翻出來發(fā)現(xiàn)TORCH_CUDA_ARCH_LIST是空的構(gòu)建腳本默認(rèn)抓到了 4090 的 8.9老卡當(dāng)然顆粒無收。2.3 誰在讀取這個(gè)設(shè)置CMake、nvcc 與框架腳本的協(xié)作從底層邏輯看設(shè)置計(jì)算能力最終都會(huì)轉(zhuǎn)化成 nvcc 的-gencode參數(shù)。比如-gencode archcompute_86,codesm_86 -gencode archcompute_86,codecompute_86第一行生成針對(duì) 8.6 的 SASS第二行生成 8.6 版本的 PTX。不同框架只是把“如何拼這串參數(shù)”包裝成了變量PyTorch 用環(huán)境變量TORCH_CUDA_ARCH_LISTTensorFlow 用TF_CUDA_ARCHSCaffe 用 CMake 的CUDA_ARCH_BIN和CUDA_ARCH_PTX現(xiàn)代 CMake 工程用CMAKE_CUDA_ARCHITECTURES所以你理解了底層原理后再去看這些變量名就會(huì)覺得它們只是同一個(gè)東西的“外號(hào)”。3. 查自己 GPU 計(jì)算能力的三條路線3.1 命令行直接查最省事的方法是用 nvidia-smi 的查詢模式。普通nvidia-smi只能看到型號(hào)、顯存、驅(qū)動(dòng)信息看不到計(jì)算能力但只要加兩個(gè)字段就能直接輸出nvidia-smi --query-gpuname,compute_cap --formatcsv輸出大概是這樣NVIDIA GeForce RTX 3090, 8.6這個(gè)辦法適合快速確認(rèn)手頭機(jī)器到底是什么架構(gòu)。3.2 官方規(guī)格表對(duì)號(hào)入座如果手頭沒有機(jī)器或者想查一批 GPU 的規(guī)格直接去 GPU 廠商的 CUDA 支持矩陣頁面。這個(gè)頁面會(huì)按計(jì)算能力從小到大列出所有支持 CUDA 的 GPU 型號(hào)。比如你想知道 Tesla T4 是多少搜一下就能看到是 7.5A100 是 8.0H100 是 9.0。查表的另一種方式是直接用 CUDA Toolkit 自帶的 deviceQuery 示例/usr/local/cuda/samples/1_Utilities/deviceQuery/deviceQuery運(yùn)行后最后幾行會(huì)輸出CUDA Capability Major/Minor version number: 8.6。3.3 在代碼里動(dòng)態(tài)獲取如果你要在程序里動(dòng)態(tài)判斷 GPU 能力可以直接問 CUDA Runtime。C 語言寫法是用cudaGetDevicePropertiesPython 里如果用 PyTorch 則更簡(jiǎn)潔import torch # 返回一個(gè)元組比如 (8, 6) print(torch.cuda.get_device_capability(0))這個(gè)我在寫需要自適應(yīng)選 kernel 的代碼時(shí)經(jīng)常用先查計(jì)算能力再?zèng)Q定走哪個(gè)優(yōu)化分支避免在運(yùn)行時(shí)調(diào)用不支持的算子。3.4 常用 GPU 速查參考表個(gè)人常備版我把自己平時(shí)頻繁用到的型號(hào)整理成了參考表編譯時(shí)填參數(shù)基本都用得上GPU 型號(hào)計(jì)算能力備注GTX 1080 Ti6.1老但還能跑Tesla T47.5推理常見RTX 2080 Ti7.5Turing 代表V1007.0Volta適合老 CUDA 環(huán)境A1008.0Ampere 數(shù)據(jù)中心卡RTX 30908.6Ampere 消費(fèi)卡RTX 40908.9AdaH1009.0Hopper只要把這張表記在心里編譯時(shí)選架構(gòu)就有了基本盤。4. PyTorch 源碼編譯TORCH_CUDA_ARCH_LIST 怎么填4.1 環(huán)境變量的填法與格式PyTorch 從源碼編譯時(shí)讀取的是環(huán)境變量TORCH_CUDA_ARCH_LIST。格式是空格分隔的列表export TORCH_CUDA_ARCH_LIST7.5 8.0 8.6編譯時(shí)它會(huì)逐個(gè)生成對(duì)應(yīng)的 SASS 代碼。比如包含 7.5 和 8.6就等于給 nvcc 傳了兩組-gencode參數(shù)最終產(chǎn)出的動(dòng)態(tài)庫里嵌入了兩套機(jī)器碼。這里有個(gè)容易忽略的點(diǎn)如果你是用官方編譯好的 PyTorch wheel 包是不需要管這個(gè)變量的官方包默認(rèn)包含了常見計(jì)算能力的支持自己搞反而容易出問題。只有當(dāng)你需要從源碼定制編譯或者要編譯自定義 CUDA 擴(kuò)展算子時(shí)才需要真正關(guān)心它。4.2 多架構(gòu)與“PTX”的組合策略在 PyTorch 的環(huán)境變量里單個(gè)架構(gòu)后面可以加PTX例如export TORCH_CUDA_ARCH_LIST7.5 8.0 8.6PTX意思是為 8.6 生成 SASS 機(jī)器碼同時(shí)額外生成一份 compute_86 的 PTX 中間代碼。這個(gè) PTX 是給“未來可能出現(xiàn)的更高計(jì)算能力 GPU”準(zhǔn)備的。比如某臺(tái)機(jī)器是計(jì)算能力 8.9 的新卡驅(qū)動(dòng)看到 8.6 的 SASS 沒法用但發(fā)現(xiàn)有 compute_86 的 PTX就會(huì)現(xiàn)場(chǎng)把它 JIT 成 8.9 能跑的代碼。雖然性能不一定是最優(yōu)但至少能跑起來。我建議的策略很直接把你手頭最老的目標(biāo)卡、當(dāng)前主力卡都寫上最后一個(gè)檔位加PTX兜底。例如開發(fā)機(jī)器是 RTX 3090但部署機(jī)器還有 RTX 2080 Tiexport TORCH_CUDA_ARCH_LIST7.5 8.6PTX這樣既照顧了老卡又保留了新卡的優(yōu)化空間。4.3 一次標(biāo)準(zhǔn)編譯實(shí)操示例一個(gè)比較典型的源碼編譯流程是這樣conda create -n build_env python3.10 conda activate build_env conda install cmake ninja export TORCH_CUDA_ARCH_LIST7.5 8.0 8.6PTX git clone --recursive https://github.com/pytorch/pytorch cd pytorch python setup.py develop編譯結(jié)束后可以用 CUDA 自帶工具檢查動(dòng)態(tài)庫里到底嵌入了哪些架構(gòu)cuobjdump --list-elf torch/lib/libtorch_cuda.so | grep sm_正常情況下會(huì)看到類似sm_75、sm_80、sm_86的字樣。這一步能幫你確認(rèn)設(shè)置是否真的生效非常值得養(yǎng)成習(xí)慣。5. TensorFlow 源碼編譯TF_CUDA_ARCHS 與 bazel 參數(shù)5.1 官方 configure 階段和 bazel action_envTensorFlow 從源碼編譯用的是 bazel在 configure 階段會(huì)生成一份配置。其中控制計(jì)算能力的變量是TF_CUDA_ARCHS。老版本 TensorFlow 的 configure 腳本會(huì)讓你手動(dòng)輸入架構(gòu)例如Please specify a list of comma-separated CUDA compute capabilities you want to build with.你也可以在編譯時(shí)直接通過環(huán)境變量覆蓋TF_CUDA_ARCHS7.5 8.0 8.6 bazel build --configcuda //tensorflow/tools/pip_package:build_pip_package注意這里同樣是空格分隔。最終 bazel 會(huì)把架構(gòu)列表解析成 nvcc 的 gencode 參數(shù)。5.2 老參數(shù) -arch / -gencode 其實(shí)還在用有些老教程里寫的不是TF_CUDA_ARCHS而是往 bazel 編譯選項(xiàng)中直接塞 nvcc 參數(shù)--copt-archsm_75或者更完整的--copt-gencodearchcompute_75,codesm_75 --copt-gencodearchcompute_75,codecompute_75這種寫法在特殊環(huán)境下依然有效因?yàn)樗苯幼饔糜?nvcc。不過維護(hù)成本高切到新架構(gòu)要改一堆地方還是用TF_CUDA_ARCHS更省心。5.3 TF 場(chǎng)景下容易忽略的兩件事第一件TensorFlow 官方預(yù)編譯包的架構(gòu)范圍是固定的。如果你是自己從源碼構(gòu)建定制版別把架構(gòu)范圍設(shè)得太窄否則模型在另一種 GPU 上加載時(shí)會(huì)直接報(bào)找不到內(nèi)核。第二件TensorFlow 對(duì) PTX 的處理在各版本間有變化。新版框架總體上是按架構(gòu)列表生成 SASS但對(duì)“未來架構(gòu)兜底”的支持不像 PyTorch 那樣直白。如果拿不準(zhǔn)穩(wěn)妥做法是把目標(biāo)機(jī)器范圍內(nèi)所有可能用到的計(jì)算能力都列進(jìn)去哪怕稍微增大一點(diǎn)編譯產(chǎn)物體積。我遇到過有人圖省事只寫了8.0結(jié)果 A100 上跑得好好的換到 T4 上模型加載直接掛。這就是典型的“只考慮當(dāng)下機(jī)器、沒考慮部署環(huán)境”的翻車現(xiàn)場(chǎng)。6. Caffe 與通用 CMake 工程CMAKE_CUDA_ARCHITECTURES6.1 Caffe 的老式寫法CUDA_ARCH_BIN 和 CUDA_ARCH_PTXCaffe 的構(gòu)建腳本有一套歷史悠久的變量體系CUDA_ARCH_BIN負(fù)責(zé)寫 SASS 要覆蓋哪些計(jì)算能力CUDA_ARCH_PTX負(fù)責(zé)寫 PTX 兜底檔位。編譯時(shí)這樣設(shè)cmake .. \ -DCUDA_ARCH_BIN75 86 \ -DCUDA_ARCH_PTX75這條命令的意思是生成 7.5 和 8.6 兩份 SASS 代碼同時(shí)為 7.5 準(zhǔn)備一份 PTX。如果你的目標(biāo)是只對(duì)當(dāng)前 GPU 優(yōu)化不想管其他型號(hào)也可以把CUDA_ARCH_BIN設(shè)成你機(jī)器對(duì)應(yīng)的計(jì)算能力數(shù)字。老項(xiàng)目的坑在于不同版本的 Caffe 對(duì)這個(gè)變量的解析格式不完全一致有的版本要求寫成7.5有的版本要求寫成75。遇到編譯不過時(shí)先檢查是不是數(shù)字格式的問題。6.2 現(xiàn)代 CMake 寫法CMAKE_CUDA_ARCHITECTURES如果你用的是較新的 CMake 和自定義 CUDA 工程推薦直接使用標(biāo)準(zhǔn)變量CMAKE_CUDA_ARCHITECTURES。這個(gè)變量從 CMake 3.18 開始支持分號(hào)分隔多個(gè)架構(gòu)cmake .. -DCMAKE_CUDA_ARCHITECTURES75;80;86注意這里的分號(hào)和前面環(huán)境變量的空格分隔不一樣。忘了帶引號(hào)的話shell 可能把分號(hào)理解成命令分隔符會(huì)直接裂開。CMake 3.24 以上版本還支持幾個(gè)關(guān)鍵字native直接用當(dāng)前機(jī)器探測(cè)到的計(jì)算能力適合只在本機(jī)部署。all支持所有已知架構(gòu)靈活但編譯時(shí)間極其感人。all-major覆蓋每個(gè)大代際里的主力架構(gòu)比 all 輕量不少。6.3 三個(gè)實(shí)用檔位native、多架構(gòu)組合、全家族覆蓋根據(jù)實(shí)際用途我一般推薦三檔只在本機(jī)跑-DCMAKE_CUDA_ARCHITECTURESnative最省事編出來也只認(rèn)當(dāng)前卡。要換機(jī)器、架構(gòu)范圍明確-DCMAKE_CUDA_ARCHITECTURES75;80;86速度適中兼容性兼顧。要交付給多人/多卡環(huán)境、架構(gòu)不確定保守起見寫61;75;80;86;89;90。代價(jià)是編譯時(shí)間和動(dòng)態(tài)庫體積都會(huì)上升換來的是“裝上就能跑”的踏實(shí)感。我記得 CMake 官方對(duì)這個(gè)變量的默認(rèn)值還鬧過一陣子如果不顯式設(shè)置新版本 CMake 在啟用 CUDA 語言時(shí)會(huì)直接警告甚至報(bào)錯(cuò)要求你必須顯式指定架構(gòu)。這不是 CMake 矯情而是它發(fā)現(xiàn)太多人因?yàn)槟J(rèn)值不明確而在換機(jī)器后翻車了。7. 編譯和運(yùn)行階段的高頻翻車現(xiàn)場(chǎng)7.1 編譯期Unsupported gpu architecture這個(gè)報(bào)錯(cuò)通常長(zhǎng)這樣Unsupported gpu architecture compute_86出現(xiàn)原因一般有兩個(gè)第一CUDA Toolkit 版本太老編譯器根本不知道sm_86/compute_86這個(gè)架構(gòu)。比如老版本 CUDA 10.x 就認(rèn)不出 8.6。解決辦法是升級(jí) CUDA Toolkit或者把目標(biāo)架構(gòu)改成當(dāng)前工具鏈認(rèn)識(shí)的舊架構(gòu)。第二CMake 的架構(gòu)列表里有拼寫錯(cuò)誤。比如手滑把86寫成了6CMake 會(huì)一臉懵地表示不認(rèn)識(shí)。查一遍變量值里有沒有漏數(shù)字、多標(biāo)點(diǎn)就好。7.2 編譯期ptxas fatal error我遇得比較多的是這種ptxas fatal : Unsupported version or architecture這個(gè)信息比上一條更底層。ptxas 是 CUDA 工具鏈里負(fù)責(zé)把 PTX 編譯成 SASS 的程序它對(duì)架構(gòu)的接受范圍更敏感。最常見的場(chǎng)景是你設(shè)置了很高的計(jì)算能力編號(hào)例如寫了compute_90但實(shí)際 CUDA Toolkit 版本還不夠新ptxas 不認(rèn) 9.0于是當(dāng)場(chǎng)報(bào)錯(cuò)。解決辦法也很直接查看工具鏈支持的架構(gòu)上限把目標(biāo)架構(gòu)調(diào)低或者升級(jí) CUDA Toolkit兩者必有一項(xiàng)。7.3 運(yùn)行期no kernel image is available for execution on the device這個(gè)錯(cuò)誤幾乎全是在換機(jī)器后才出現(xiàn)RuntimeError: CUDA error: no kernel image is available for execution on the device原因是當(dāng)前 GPU 的計(jì)算能力在程序編譯的 SASS 列表里找不到對(duì)應(yīng)項(xiàng)而且程序里也沒有附帶能 JIT 到當(dāng)前架構(gòu)的 PTX。比如用 RTX 4090 編譯出的庫只帶了 8.9 的 SASS放到 RTX 30908.6上跑8.9 的機(jī)器碼它不認(rèn)又沒有 8.6 的 PTX 兜底自然直接崩。碰到這個(gè)報(bào)錯(cuò)不要急著懷疑代碼邏輯先回去看編譯時(shí)架構(gòu)列表范圍把目標(biāo)部署機(jī)器的計(jì)算能力加進(jìn)去重編一次。7.4 高頻問題速查表我把常見情況整理成表方便直接對(duì)照現(xiàn)象常見原因處理思路編譯報(bào) Unsupported gpu architectureCUDA 版本太老 / 拼寫錯(cuò)誤升級(jí)工具鏈或修正架構(gòu)編號(hào)ptxas fatal: Unsupported version目標(biāo)架構(gòu)超出工具鏈支持范圍降檔或升級(jí) CUDA Toolkit運(yùn)行報(bào) no kernel imageSASS 和 PTX 都與當(dāng)前卡不匹配把目標(biāo)架構(gòu)加入編譯范圍重編CMake 報(bào) CUDA_ARCHITECTURES 相關(guān)錯(cuò)誤變量未設(shè)置或格式不對(duì)顯式指定架構(gòu)列表用引號(hào)包裹換機(jī)器后部分算子極慢只編了最低兼容架構(gòu)新卡特性沒啟用增加新計(jì)算能力檔位重新編譯排查這類問題時(shí)我還有個(gè)習(xí)慣先跑一行nvidia-smi --query-gpuname,compute_cap --formatcsv把當(dāng)前機(jī)器的計(jì)算能力確認(rèn)掉再去看編譯日志里實(shí)際生成了哪些架構(gòu)兩步就能定位九成問題。8. 折騰這么多次我最后想說的幾件事第一件編譯框架前一定要先想清楚“這個(gè)庫到底要在哪些機(jī)器上跑”。只服務(wù)于本機(jī)直接native或者寫當(dāng)前計(jì)算能力就行要交付部署就必須把目標(biāo)機(jī)器范圍拉出來逐個(gè)核對(duì)架構(gòu)列表。第二件多架構(gòu)列表確實(shí)會(huì)讓編譯變慢、包體變大但這是值得的。一個(gè)包含75;80;86;89;90的庫體積可能多個(gè)幾百 MB換來的是在所有主流量級(jí) GPU 上“裝好即跑”遠(yuǎn)比在生產(chǎn)環(huán)境里重編框架省時(shí)間。第三件學(xué)會(huì)用cuobjdump --list-elf檢查編譯產(chǎn)物。不管是 PyTorch 的.so還是 Caffe 的動(dòng)態(tài)庫編譯完以后花十秒看一下里面嵌了哪些 sm 架構(gòu)就能確認(rèn)設(shè)置到底有沒有生效。這一步看著不起眼卻幫我避過無數(shù)個(gè)“以為配好了其實(shí)是默認(rèn)值在撐場(chǎng)面”的坑。最后再分享一個(gè)小經(jīng)驗(yàn)團(tuán)隊(duì)多人共用構(gòu)建機(jī)時(shí)架構(gòu)列表最好統(tǒng)一寫進(jìn)構(gòu)建腳本或 Dockerfile 里別依賴某個(gè)人手動(dòng) export。否則一個(gè)人改環(huán)境變量、另一個(gè)人不知道編譯出的包帶回各自的機(jī)器上互相甩鍋的場(chǎng)景你就等著吧。