前一陣子有個朋友在服務(wù)器上搭深度學(xué)習(xí)環(huán)境用 conda 建了一個 Python 3.8 的虛擬環(huán)境裝完 PyTorch 準備裝 mmcv 源碼編譯終端立刻拋了句nvcc: command not found。他第一反應(yīng)是 conda 環(huán)境裝壞了差點把 base 環(huán)境整個刪掉。這種情況在 CUDA 11.6 搭配 conda 時尤其常見因為很多項目的 README 都會讓你conda install cudatoolkit11.6可裝完之后你會發(fā)現(xiàn)nvcc --version依然報 not found。原因不是你沒裝對而是 cudatoolkit 里壓根就沒有 nvcc。這篇文章把「conda 環(huán)境下 11.6 版本 nvcc not found」這件事掰開揉碎講清楚。適合正在搭環(huán)境、被各種 CUDA 報錯折騰的同學(xué)也適合一直搞不懂 nvcc、驅(qū)動、cudatoolkit 到底什么關(guān)系的人?？赐昴悴粌H知道怎么解決更明白為什么會有這個問題下次遇到類似情況不用再全網(wǎng)搜。1. 先把問題拆開看nvcc、conda 和 CUDA Toolkit 到底誰是誰1.1 nvcc 不是驅(qū)動也不是運行時庫很多人把 CUDA 相關(guān)的東西混為一談其實這里至少有三個完全不同的東西搞混了后面所有排查都是白費。第一個是 NVIDIA 顯卡驅(qū)動運行在操作系統(tǒng)內(nèi)核層負責(zé)直接和顯卡硬件通信。驅(qū)動通過nvidia-smi查詢可以看到驅(qū)動版本號以及當(dāng)前驅(qū)動支持的最高 CUDA 版本。這個一般是裝系統(tǒng)時或單獨裝驅(qū)動時裝上的跟 conda 沒有任何關(guān)系。第二個是 CUDA 運行時庫也就是libcudart.so、libcublas.so這一堆動態(tài)庫程序跑起來的時候要加載它們。平時寫 Python 代碼PyTorch 裝完就自帶一套 CUDA 運行時庫了所以不裝任何 CUDA Toolkit 也能在 GPU 上跑模型這是大多數(shù)人的實際狀態(tài)。第三個才是 nvcc全稱 NVIDIA CUDA Compiler是 CUDA Toolkit 里的編譯器。它負責(zé)把.cu和.cpp源文件編譯成能在 GPU 上執(zhí)行的機器碼。對應(yīng)到 C 語言里nvcc 就是 gcc對應(yīng)到 Java 里nvcc 就是 javac。那為什么明明torch.cuda.is_available()是 True程序也跑得飛起偏偏一敲 nvcc 就 not found因為運行和編譯是兩碼事。運行只要運行時庫在就行編譯得完整的編譯器工具鏈在場。你家里有做好的菜可以吃不代表你廚房里就有刀和鍋具備自己做飯的條件。1.2 conda 裝的 cudatoolkit 和你以為的 CUDA Toolkit 不是一回事這是 90% 混亂的根源。conda 里有一個包叫cudatoolkit這是 conda 官方渠道或 conda-forge 渠道提供的預(yù)編譯二進制包主要包含運行時庫、部分頭文件和一些 CUDA 工具。注意cudatoolkit這個名字很容易誤導(dǎo)人。它叫 toolkit但實際上默認不包含 nvcc 編譯器尤其是舊版本。你用conda install cudatoolkit11.6裝完后conda list | grep cuda里能看到 cudatoolkit但which nvcc依然是空的。真正包含 nvcc 的是另一個包cuda-toolkit在 NVIDIA 官方 conda 渠道nvidia里。另外NVIDIA 官網(wǎng)提供的本地安裝包cuda_11.6.x_linux.run也是完整的 Toolkit裝完之后的/usr/local/cuda-11.6/bin/nvcc就是 nvcc 本體。用一個生活類比cudatoolkit相當(dāng)于給你一套別人翻譯好的書庫文件你拿來看完全沒問題nvcc相當(dāng)于你寫作需要的那支筆。你沒有筆就只能讀別人寫好的成品自己一個字也寫不出來。PyTorch 幫你把該讀的書都讀完了但你要自己寫 CUDA 擴展時筆就必須自己買。1.3 為什么 PyTorch 能跑但還是報 nvcc not foundimport torch不報錯torch.cuda.is_available()返回 True模型在 GPU 上呼呼跑但一執(zhí)行 nvcc 就 not found——前面已經(jīng)說了原因PyTorch 官方 pip 包把 CUDA 運行時庫全部打進 wheel 了運行時根本不需要系統(tǒng)里有單獨的 CUDA Toolkit。不過下面這些場景沒有 nvcc 就會直接卡死安裝需要編譯的 Python 包比如mmcv-full、detectron2、apex、flash-attention這些安裝腳本會在本機調(diào)用 nvcc 做擴展編譯。沒有 nvcc編譯階段直接報nvcc not found或者Command nvcc not found然后靜默失敗。自己寫 CUDA kernel或者用 setuptools 編譯自定義擴展算子.cu文件必須經(jīng)過 nvcc 編譯這一步繞不開。還有 CMake 構(gòu)建項目時CMake 找 CUDA 依賴是通過找nvcc來定位 CUDA Toolkit 的它找不到 nvcc 就會直接把 CUDA 支持關(guān)掉。所以 PyTorch 能跑而 nvcc not found并不是你環(huán)境壞了而是你缺了編譯工具鏈里最關(guān)鍵的一環(huán)。診斷方向從一開始就要對準這個點。2. 動手診斷三步確認你的 nvcc 到底去哪了2.1 先確定 not found 是哪個層面的問題看見 not found第一個動作永遠是確認搜索路徑而不是盲目重裝。在 Linux 或者 macOS 終端里輸入which nvcc如果輸出為空說明 PATH 里沒有 nvcc系統(tǒng)壓根不知道去哪找它。再試一個conda list | grep -i cuda看看當(dāng)前 conda 環(huán)境里實際裝了哪些 CUDA 相關(guān)的包。常見的局面是cudatoolkit有nvcc沒有。這里 pycharm、vscode 等編輯器終端沒刷新環(huán)境變量也會造成誤判比如你在系統(tǒng)設(shè)置里配了 PATH但當(dāng)前終端還是老環(huán)境輸入nvcc -V自然是 not found。在不正規(guī)的狀態(tài)下哪怕已經(jīng)裝了完整 CUDA Toolkit也會因為 PATH 里沒寫/usr/local/cuda/bin而找不到 nvcc。所以先判斷一下“PATH 里沒有”和“文件根本沒裝”是兩回事思路完全不同。2.2 找到系統(tǒng)里的 nvcc 本體和 CUDA 安裝目錄PATH 里沒有不代表文件不存在先全盤搜索一下。Linux 下執(zhí)行find / -name nvcc -type f 2/dev/null如果系統(tǒng)裝了完整 CUDA Toolkit大概率會找到類似/usr/local/cuda-11.6/bin/nvcc這樣的路徑。常見的還有/opt/cuda/bin/nvcc取決于當(dāng)時安裝時的自定義選項。再順手看一下ls -l /usr/local/ | grep cuda會有/usr/local/cuda、/usr/local/cuda-11.6這類目錄。注意/usr/local/cuda經(jīng)常是一個軟鏈接指向具體的版本目錄比如cuda-11.6。軟鏈接的好處是路徑固定切換版本只用改鏈接不用改 PATH。Windows 下用 PowerShell 或者 cmdwhere nvcc如果提示找不到去默認安裝目錄看一眼C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.6\bin\nvcc.exeWindows 上 CUDA Toolkit 默認裝在C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\下面每個版本一個v11.6這樣的目錄。如果你能找到這個目錄說明 nvcc 本體就在剩下的問題純粹是環(huán)境變量沒配好。2.3 用兩個命令理解當(dāng)前 CUDA 狀態(tài)nvcc --version 與 nvidia-smi搞清 nvcc 的位置之后再用兩個命令對照確認當(dāng)前狀態(tài)。nvcc --version顯示的是 CUDA Toolkit 的編譯版本也就是你機器上這套編譯工具鏈的版本。nvidia-smi右上角顯示的 CUDA Version不是 Toolkit 版本而是當(dāng)前顯卡驅(qū)動支持的最高 CUDA 版本。打個比方驅(qū)動是“地基”Toolkit 是“磚頭鋼筋”nvcc 是“施工隊”。地基決定了最高能蓋多少層樓施工隊決定你手上這批材料能蓋成什么樣。這兩者的關(guān)系是Toolkit 版本必須不高于驅(qū)動支持的最高 CUDA 版本。比如你驅(qū)動顯示 CUDA Version 12.4那 Toolkit 用 11.6、12.0、12.4 都可以向后兼容沒問題。反過來說如果你驅(qū)動只支持 CUDA 11.6卻裝了一個 12.0 的 Toolkit跑起來大概率會出錯。對照完這兩個命令你基本就能確定如果是驅(qū)動太老導(dǎo)致 Toolkit 跑不了那不是 nvcc not found 的問題而是版本不兼容問題。如果 nvcc 文件存在但 PATH 沒配那就是純環(huán)境變量問題。如果文件根本不存在那就是 Toolkit 沒裝完整。3. 實操解決從臨時方案到一勞永逸的配置方式3.1 臨時方案先把 PATH 指過去讓當(dāng)前會話先能用確定 nvcc 文件存在之后最簡單粗暴的方式是手動把它的目錄加進 PATH。Linux 下執(zhí)行export PATH/usr/local/cuda-11.6/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda-11.6/lib64:$LD_LIBRARY_PATH然后驗證nvcc --version如果看到 Cuda compilation tools 的版本信息說明這次會話里 nvcc 已經(jīng)能用了。但注意export 只在當(dāng)前終端生效關(guān)掉重開就沒了。這一步適合先確認“哦原來只是沒配環(huán)境變量”不適合作為最終方案。Windows 下臨時加路徑在 cmd 里寫set PATHC:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.6\bin;%PATH%同樣只對當(dāng)前窗口有效。這個階段如果還報 not found就要考慮是不是你手動 export 的路徑本身就不對或者 nvcc 文件權(quán)限有問題換用ls檢查一下文件是否可執(zhí)行。3.2 推薦方案用 conda 在環(huán)境內(nèi)安裝完整 CUDA Toolkit如果你的需求是“這個 conda 環(huán)境里就要有 nvcc”不想碰系統(tǒng)的任何配置那么最干凈的做法是直接在 conda 環(huán)境里裝 NVIDIA 官方渠道的完整 Toolkit。conda install -c nvidia cuda-toolkit11.6注意渠道必須是nvidia不是 conda-forge 也不是 default。conda-forge里有一個cuda-toolkit包名但依賴解析經(jīng)常出問題版本也往往不是官方同步節(jié)奏。用 NVIDIA 官方渠道最穩(wěn)。裝完之后在當(dāng)前環(huán)境下找 nvccwhich nvcc正常情況下會在 conda 環(huán)境的bin目錄下類似/home/user/miniconda3/envs/your_env/bin/nvcc。再跑nvcc --version確認版本是 11.6。這個方案的好處是環(huán)境隔離conda 環(huán)境刪了 nvcc 也一起刪了不會污染系統(tǒng)也不會影響服務(wù)器上其他人。注意包名區(qū)別如果是舊教程讓你裝cudatoolkit11.6那仍然沒有 nvcc別被坑。如果你網(wǎng)絡(luò)環(huán)境不好conda 解析依賴很慢可以把-c nvidia和-c conda-forge一起用順序注意把nvidia放前面避免版本被 conda-forge 搶跑。3.3 系統(tǒng)方案軟鏈接統(tǒng)一入口版本切換最方便如果你經(jīng)常在多個項目之間切換 CUDA 版本官方推薦的系統(tǒng)級做法是建立統(tǒng)一軟鏈接。假設(shè)你機器上裝了多個 CUDA 版本/usr/local/cuda-11.6 /usr/local/cuda-12.0分別指向到同一個/usr/local/cudasudo ln -s /usr/local/cuda-11.6 /usr/local/cuda然后 PATH 里只寫通用入口export PATH/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda/lib64:$LD_LIBRARY_PATH以后切換版本只需要改軟鏈接指向不用改 PATH。這一步適合你不想每次進 conda 環(huán)境都重新配變量、也不想在 conda 環(huán)境里反復(fù)裝包的場景。它和 conda 方案并不沖突很多實際工作環(huán)境是兩者同時用的系統(tǒng)級給 nvcc 建軟鏈接conda 環(huán)境里裝 cudatoolkit 滿足運行時依賴。強調(diào)一下ln -s如果目標(biāo)軟鏈接已存在會報錯可以先sudo rm /usr/local/cuda再重新建提前確認這個軟鏈接沒有別的服務(wù)在依賴否則會導(dǎo)致其他程序起不來。3.4 Windows 下的持久配置方式Windows 上如果找到C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.6\bin\nvcc.exe說明 Toolkit 裝好了只是環(huán)境變量沒持久化。圖形界面操作方式其實最直觀右鍵“此電腦” - 屬性 - 高級系統(tǒng)設(shè)置 - 環(huán)境變量在系統(tǒng)變量的 Path 里追加C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.6\bin和C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.6\libnvvp。命令行里用setx也可以setx PATH C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.6\bin;%PATH%注意兩點第一setx會覆蓋原有的系統(tǒng) PATH如果原 PATH 很長又沒有提前備份很容易把其他變量搞亂第二配完之后必須重開終端當(dāng)前窗口的環(huán)境變量是啟動時讀進來的不會自動刷新。另外Windows 上經(jīng)常出現(xiàn)的情況是用戶安裝了多個 CUDA 版本比如 v11.6、v12.2 都有Path 里到底哪個版本靠前哪個生效。要查看當(dāng)前實際生效路徑就用where nvcc輸出結(jié)果里第一條就是實際調(diào)用的那個。4. Windows 和 Linux 下容易踩的版本坑4.1 版本錯位的經(jīng)典現(xiàn)象nvcc 11.6PyTorch 要編譯擴展卻失敗我們假設(shè)你 nvcc 已經(jīng)能用了但更隱蔽的問題來了nvcc --version顯示 11.6你 conda 環(huán)境里 PyTorch 也是 11.6 的 wheel但編譯 mmcv 時還是報錯甚至編完跑起來直接 illegal instruction 或 CUDA error。為什么會這樣因為 nvcc 在編譯時調(diào)用的頭文件和你線程里 PyTorch 自帶的運行時版本匹配是嚴格敏感的。PyTorch 的 wheel 后綴標(biāo)注了 CUDA 版本比如torch-2.0.0cu118它內(nèi)部鏈接的 CUDA 版本是 11.8。你 nvcc 是 11.6編譯出的二進制對象文件里引用的某些版本符號在 11.8 的 runtime 里不兼容。所以版本對齊的原則是nvcc 的版本必須跟 PyTorch 的 CUDA wheel 版本一致或者盡量靠近最好是相同主版本且不低于 runtime 版本。裝了 PyTorch cu118 的nvcc 就用 11.8裝了 cu116 的nvcc 就用 11.6。這也是為什么項目 README 里明確寫了 11.6 時你要保證 nvcc 也是 11.6 而不是 12.x。處理方式很簡單用前文提到的 conda nvidia 源安裝對應(yīng)版本conda install -c nvidia cuda-toolkit11.6裝完之后再次nvcc --version和python -c import torch; print(torch.version.cuda)對照一下保證二者一致。誤差一個主版本偶爾也能編譯通過但運行時是不是穩(wěn)定就全看運氣了不建議賭。4.2 glibc、GLIBCXX 這類動態(tài)庫報錯其實不是 nvcc 的問題排查過程里很多人會碰到這種報錯/lib/x86_64-linux-gnu/libstdc.so.6: version GLIBCXX_3.4.21 not found /lib/x86_64-linux-gnu/libc.so.6: version GLIBC_2.28 not found這類報錯很容易被誤以為是 nvcc 沒裝好導(dǎo)致的連鎖反應(yīng)實際上它是系統(tǒng) glibc 庫太舊或者 libstdc 版本不夠新。nvcc 編譯出來的二進制在運行時需要這些動態(tài)庫如果你的服務(wù)器是老系統(tǒng)比如 CentOS 7自帶 glibc 版本太低即使 nvcc 編譯成功了運行階段還是會崩。這屬于“編譯成功但運行失敗”的典型場景跟 nvcc not found 不是一回事但經(jīng)常在同一次環(huán)境配置中連續(xù)出現(xiàn)。處理方法有限第一升級系統(tǒng) libstdc這個有風(fēng)險不推薦在共享服務(wù)器上直接動系統(tǒng)庫第二用 conda 環(huán)境把依賴全部隔離在環(huán)境里裝更新的libgcc-ng和libstdcxx-ng讓動態(tài)庫優(yōu)先從 conda 環(huán)境目錄加載。具體做法是先看當(dāng)前 env 里有沒有裝了新版本 C 運行庫conda install -c conda-forge libgcc-ng libstdcxx-ng然后確認 LD_LIBRARY_PATH 里 conda 環(huán)境在前。這一步對很多老服務(wù)器用戶來說是險中求勝如果系統(tǒng) glibc 實在太老比如 GLIBC_2.28 都找不到單純換 libstdc 也不夠得考慮升級操作系統(tǒng)或者用容器方案。4.3 多用戶服務(wù)器上 PATH 互相干擾的坑在共享服務(wù)器上.bashrc里寫死了/usr/local/cuda/bin全局 PATH但另一個用戶裝了新版 CUDA 在~/cuda并且把自己的目錄放到了 PATH 最前面。你切換到他的路徑或者 conda activate 了某個環(huán)境之后PATH 順序會亂掉。conda activate 的核心機制就是修改 PATH把當(dāng)前環(huán)境目錄插到最前面echo $PATH你會看到類似/home/user/miniconda3/envs/your_env/bin:/usr/local/cuda/bin:/usr/bin:...的結(jié)構(gòu)。如果你的 conda 環(huán)境里沒有 nvcc而/usr/local/cuda/bin排在 conda 環(huán)境目錄之后which nvcc理論上能找到但如果 conda 環(huán)境的 bin 下恰好有個同名文件或者軟鏈接壞掉就會表現(xiàn)出奇怪的 not found。我遇到過一種很隱蔽的情況conda 環(huán)境的 bin 目錄里沒有 nvcc但有一個從舊路徑復(fù)制過來的損壞軟鏈接導(dǎo)致系統(tǒng)找了半天找不到目標(biāo)文件直接 not found。刪掉壞鏈接、把 PATH 里真正有效的/usr/local/cuda/bin配上問題就消失了。所以多用戶環(huán)境下我建議把 CUDA 相關(guān)路徑的配置放到/etc/profile.d/cuda.sh統(tǒng)一管理不要每個人都往自己的.bashrc里寫一套最后互相覆蓋才知道問題有多大。5. 常見報錯現(xiàn)場與排查速查表5.1 從實際報錯看典型場景這里列幾個高頻現(xiàn)場很多都是熱詞里反復(fù)出現(xiàn)的bash: nvcc: command not found最常見的原因就是 PATH 沒配或者 Toolkit 沒裝。按第 2 章的步驟先find / -name nvcc找到就走 PATH 方案找不到就走 conda 安裝方案。Windows 提示“nvcc 不是內(nèi)部或外部命令也不是可運行的程序或批處理文件”這個句式基本是 Windows 經(jīng)典文件不存在提示。先去C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.6\bin確認 nvcc.exe 在不在在就把環(huán)境變量配好并重開終端。注意 Windows 11 和舊版 Windows 10 的環(huán)境變量窗口操作差異不大但重開終端這個動作容易被忽略。conda activate報錯提示要先運行conda init這不是 nvcc 的問題而是你安裝 conda 之后沒有初始化 shell。運行一下conda init bash然后重新登錄再激活環(huán)境。這類問題經(jīng)常會和林林總總的 not found 報錯混在一起排查時要分開別混為一談。編譯擴展時報錯找不到cuda.h或cuda_runtime.h說明 nvcc 找到了但頭文件搜索路徑不對。nvcc 編譯時默認會去自身安裝目錄下的 include 找頭文件如果路徑是軟鏈接指向的偶爾也會出現(xiàn)頭文件路徑裂縫。手動把CUDA_HOME環(huán)境變量指到/usr/local/cuda大多數(shù)構(gòu)建系統(tǒng)會尊重這個變量。CMake 報錯CMake Error: CUDA not foundCMake 找 CUDA 有它自己的查找路徑邏輯它會看nvcc所在目錄做了/usr/local/cuda-11.6軟鏈接后如果 CMake 緩存里還殘留舊路徑先刪掉 build 目錄重新 cmake 一次。5.2 排查速查表癥狀可能原因處理方式nvcc: command not foundPATH 未配置或 Toolkit 未安裝先find定位文件再配置 PATH 或 conda 安裝Windows 提示“不是內(nèi)部或外部命令”環(huán)境變量未配置或未刷新配置系統(tǒng) PATH 后重開終端cuda.h找不到CUDA_HOME 未設(shè)置export CUDA_HOME/usr/local/cuda編譯后可運行卻崩GLIBCXX報錯系統(tǒng) libstdc 太老conda 環(huán)境內(nèi)安裝libstdcxx-ngconda activate報 init 錯誤shell 未初始化conda init bash后重新登錄CMake 找不到 CUDA緩存殘留舊路徑刪除 build 目錄重新cmakenvcc 版本和 PyTorch 不一致版本對齊問題用 conda 安裝對應(yīng)cuda-toolkit版本這張表基本覆蓋了我實際排查中的絕大多數(shù)情況。遇到 not found先別急著重裝按順序逐步排除才是效率最高的方式。6. 我的實操心得環(huán)境管理策略與一些建議6.1 推薦的環(huán)境組合策略踩過這么多坑之后我現(xiàn)在給團隊和學(xué)員推薦一套組合拳能少走很多彎路。系統(tǒng)層面服務(wù)器上統(tǒng)一裝一個固定版本的 CUDA Toolkit并且建立/usr/local/cuda軟鏈接。這個 Toolkit 純粹給編譯用裝好之后 PATH 只寫軟鏈接路徑不指向任何帶版本號的目錄。conda 環(huán)境里按 PyTorch 的需求裝對應(yīng)版本的運行時庫比如conda install -c pytorch pytorch torchvision torchaudio cudatoolkit11.6但不要把編譯依賴寄托在 conda 的 cudatoolkit 上因為它不含 nvcc。需要編譯擴展時確保which nvcc指向系統(tǒng)那套 Toolkit并且nvcc --version和 PyTorch 的 CUDA 版本對齊。如果你更希望完全隔離那就用 NVIDIA 官方 conda 渠道把cuda-toolkit打進環(huán)境。這種方式在多人共用服務(wù)器上最省心刪掉環(huán)境什么都不留系統(tǒng)永遠不會被搞臟。代價是每次編譯大項目時conda 環(huán)境里的 nvcc 和系統(tǒng)其他庫結(jié)合時可能出現(xiàn)新的動態(tài)庫路徑問題但總體來說用官方渠道包基本能規(guī)避。6.2 驗證清單三分鐘確認環(huán)境健康配完之后不要直接開始編譯花三分鐘把下面幾條過一遍which nvcc nvcc --version nvidia-smi | head -n 20 python -c import torch; print(torch.__version__, torch.version.cuda, torch.cuda.is_available())四個輸出對照起來看第一個確保能找到 nvcc第二個確保編譯器版本是 11.6第三個確保驅(qū)動支持第四個確保 PyTorch 的 CUDA 版本和上面一致。如果torch.cuda.is_available()是 False但同時 nvcc 又能跑問題很有可能出在驅(qū)動層而不是 conda 環(huán)境內(nèi)的版本配置。6.3 最后分享一個經(jīng)驗我自己在實際維護環(huán)境時最深的體會是not found 這類報錯絕大多數(shù)時候不是文件沒了而是路徑找不到。很多同學(xué)一看到 not found 就重裝一重裝就折騰一下午最后發(fā)現(xiàn)只是少了條 export。所以遇到任何 not found第一反應(yīng)應(yīng)該是where/which/find三連而不是卸載重裝。路徑是環(huán)境管理的第一性問題Conda 里的工具鏈、系統(tǒng)的工具鏈、驅(qū)動自帶的工具鏈經(jīng)常各自為政不在同一個 PATH 體系里搞清楚誰在誰不在問題就已經(jīng)解決了一半。另外一個細節(jié)編輯.bashrc配 PATH 時記得把 export 寫在上方公共區(qū)域不要寫在某個循環(huán)或者條件分支里不然后面開新終端時靜默失效又白白排查半天。如果你用 condaconda init會在.bashrc里寫入一段初始化代碼盡量讓這個初始化保持在文件末尾這樣你的自定義 PATH 不會被 conda 啟動過程覆蓋掉。希望這篇經(jīng)驗?zāi)軒湍愎?jié)省出那一整天用來調(diào)試環(huán)境的時間把精力真正放回模型和業(yè)務(wù)上面。