Ubuntu下CUDA的卸载和安装，看起来只是几条命令的事，真正上手才发现坑不少：有人把驱动一起卸了导致黑屏，有人用run方式装完发现nvcc对不上号，还有人下载的runfile解压时报“gzip: stdin: invalid compressed>sudo apt-get --purge remove "cuda-toolkit-*" "cuda-cudart-*" "cuda-nvcc-*" "cuda-nvrtc-*" "cuda-nvtx-*" "cuda-nvml-*" "cuda-command-line-tools-*" "cuda-libraries-*" "cuda-libraries-dev-*" "libcublas-*" "libcublas-dev-*" "libcufft-*" "libcufft-dev-*" "libcurand-*" "libcurand-dev-*" "libcusolver-*" "libcusolver-dev-*" "libcusparse-*" "libcusparse-dev-*" "libnpp-*" "libnpp-dev-*" "libnvjpeg-*" "libnvjpeg-dev-*" "nsight-*" "nvvm-*"

然后执行sudo apt-get autoremove --purge清理无用依赖。如果你确定要连CUDA源里的驱动包也清理，再执行sudo apt-get --purge remove "cuda-drivers-*"，但这会动驱动，必须谨慎。更稳妥的做法是：先卸载Toolkit，重启后确认nvidia-smi还能正常显示，再决定是否处理驱动。如果你之前安装的是cuda元包，可以执行sudo apt-get --purge remove cuda cuda-12-4，但执行前用apt-get -s remove cuda模拟一次，看它准备删除哪些包。模拟输出里如果出现nvidia-driver、nvidia-dkms、xserver-xorg-video-nvidia，立刻停手，改用精确包名卸载。我自己的习惯是，卸载前先sudo apt-mark hold nvidia-driver-*把驱动锁住，防止APT误删。卸载完成后，再sudo apt-mark unhold nvidia-driver-*恢复。这个技巧在同时存在多个CUDA源和系统驱动时特别管用。

2.3 清理源、密钥、环境变量和残留目录

包卸载完不代表CUDA干净了。deb方式通常还会留下APT源、GPG密钥、环境变量和符号链接。先检查/etc/apt/sources.list.d/下有没有cuda.list、cuda-ubuntu*.list、nvidia-cuda*.list，有就删除或移到备份目录。再检查/usr/share/keyrings/下有没有cuda-*.gpg、nvidia-*.gpg，如果不再使用CUDA源，可以移除。执行sudo apt-get update确认没有残留报错。环境变量方面，检查~/.bashrc、~/.zshrc、/etc/profile.d/、/etc/environment中是否还有/usr/local/cuda相关PATH和LD_LIBRARY_PATH，把对应行注释掉或删除。符号链接/usr/local/cuda如果还指向已删除的版本，也要移除：sudo rm -f /usr/local/cuda。如果/usr/local/下还有空的cuda-12.4目录，可以手动删除。动态库配置方面，检查/etc/ld.so.conf.d/下是否有cuda.conf、cuda-12-4.conf，删除后执行sudo ldconfig。最后用whereis cuda、whereis nvcc、locate cuda | head做一次残留扫描。注意locate数据库可能未更新，可以先sudo updatedb。如果这些残留不清理，下次安装新版本时，shell可能仍然优先找到旧路径，出现nvcc版本混乱。我遇到过最隐蔽的一次，是/etc/ld.so.conf.d/cuda.conf还指向旧版本，导致程序运行时加载了旧的libcudart.so，编译没问题，一跑就崩。

2.4 卸载后验证与回滚思路

卸载完成后，分三层验证。第一层，驱动层：执行nvidia-smi，能显示GPU信息、驱动版本正常，说明驱动没被误删。第二层，Toolkit层：执行nvcc -V，如果提示找不到命令，说明Toolkit已移除；如果还能显示版本，说明PATH里还有旧路径或包没删干净。第三层，框架层：进入Python执行import torch; print(torch.cuda.is_available())，如果返回False且没有报动态库错误，说明CUDA运行时依赖已经断开，属于预期结果。如果返回错误如libcudart.so.12: cannot open shared object file，说明还有程序在找旧库，需要检查环境变量和ldconfig。回滚思路也很重要：如果你只是卸载Toolkit，保留驱动，回滚就是重新安装对应版本；如果你误删了驱动，需要进入TTY或恢复模式，重新安装推荐驱动：sudo ubuntu-drivers devices查看推荐版本，sudo ubuntu-drivers autoinstall，然后重启。如果系统已经黑屏，可以在GRUB菜单选择Advanced options，进入recovery mode，选择root shell，联网后执行驱动重装。这个流程一定要在远程操作前心里过一遍。我的经验是，卸载CUDA之前先确认自己能否物理接触机器或有无快照，否则不要轻易动驱动。

3. Ubuntu下CUDA卸载实操：run方式如何安全移除

3.1 找到runfile安装的uninstaller

run方式安装的CUDA不会出现在dpkg -l里，所以第一步是找到它的安装目录。通常路径是/usr/local/cuda-12.4、/usr/local/cuda-11.8，符号链接/usr/local/cuda可能指向其中之一。进入对应版本目录，查看bin下是否有cuda-uninstaller。新版本CUDA一般提供/usr/local/cuda-12.4/bin/cuda-uninstaller，老版本可能是/usr/local/cuda-11.8/bin/uninstall_cuda_11.8.pl。执行前先ls -l确认文件存在且有执行权限。然后运行：

sudo /usr/local/cuda-12.4/bin/cuda-uninstaller

如果是Perl脚本：

sudo /usr/local/cuda-11.8/bin/uninstall_cuda_11.8.pl

卸载器会列出已安装组件，让你选择要移除的内容。这里要特别小心：如果当初安装时勾选了Driver，卸载器可能会问是否卸载驱动。除非你明确要换驱动，否则不要在这里卸载驱动。选择只移除Toolkit和Samples即可。卸载完成后，/usr/local/cuda-12.4目录可能仍然存在，里面残留一些配置文件或空目录，可以手动确认后删除。如果你不记得当初装了什么，可以查看/usr/local/cuda-12.4/bin下有哪些可执行文件，以及/usr/local/cuda-12.4/lib64下有哪些库，大致判断组件范围。run方式没有包管理器帮你记录依赖，所以人工确认这一步不能省。

3.2 区分只装Toolkit和连驱动一起装的情况

run方式安装时，向导里有一个Driver选项。如果你当时取消了Driver，只装了Toolkit，那么卸载时只处理Toolkit即可，驱动仍由系统APT管理。如果你当时勾选了Driver，情况就复杂了：run安装器可能把NVIDIA驱动装到了/usr/lib/modules、/usr/bin/nvidia-*等位置，并可能覆盖了APT安装的驱动。此时卸载CUDA时如果一并卸载驱动，可能导致nvidia-smi消失；如果不卸载驱动，又可能留下版本冲突。判断方法：执行which nvidia-uninstall，如果存在/usr/bin/nvidia-uninstall，说明run方式安装过驱动。再执行nvidia-smi查看驱动版本，和dpkg -l | grep nvidia-driver对比。如果APT里没有驱动包，但nvidia-smi能用，基本就是run方式装的驱动。这种情况下，我的建议是：先不要动驱动，只卸载Toolkit；等新CUDA装好、验证业务正常后，再考虑是否统一用APT管理驱动。如果确实需要卸载run方式驱动，可以执行sudo /usr/bin/nvidia-uninstall，但之后必须重新安装驱动，否则图形界面可能无法启动。远程机器上执行这个命令等于自断后路，除非你有IPMI、云控制台或快照。

3.3 清理动态库、符号链接和旧环境变量

run方式卸载后，重点清理四类残留。第一类，符号链接：/usr/local/cuda如果还指向已删除目录，执行sudo rm -f /usr/local/cuda。第二类，动态库配置：检查/etc/ld.so.conf.d/下是否有cuda.conf、cuda-12-4.conf，删除后sudo ldconfig。第三类，环境变量：检查~/.bashrc、~/.profile、/etc/profile.d/cuda.sh，把export PATH=/usr/local/cuda/bin:$PATH、export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH注释掉。第四类，安装日志和临时文件：run安装器可能在/var/log/cuda-installer.log、/tmp/cuda*留下日志，可以保留日志用于排查，临时文件可清理。清理完成后，重新打开终端，执行which nvcc确认找不到旧命令。如果nvcc仍然存在，用type -a nvcc查看所有路径，逐个确认来源。有时候系统里还有通过conda安装的nvcc，那就不属于run方式，需要到对应conda环境里处理。我见过有人卸载完run版CUDA后，nvcc还能用，最后发现是conda环境里的cudatoolkit带了一个nvcc，这种情况要区分对待，不能直接把/usr/local删了就完事。

3.4 run方式卸载后的驱动恢复

如果你在run方式卸载时把驱动也移除了，或者驱动被破坏，恢复步骤要稳。首先进入TTY：按Ctrl+Alt+F3，登录后停止显示管理器，Ubuntu 22.04/20.04通常用sudo systemctl stop gdm3或sudo systemctl stop lightdm。然后确认当前驱动状态：nvidia-smi应该报错，lsmod | grep nvidia应该没有输出。接着安装推荐驱动：

sudo ubuntu-drivers devices sudo ubuntu-drivers autoinstall

如果ubuntu-drivers不可用，可以sudo apt-get update后sudo apt-get install nvidia-driver-550，版本号以推荐为准。安装完成后执行sudo update-initramfs -u，再sudo reboot。重启后如果进入图形界面，检查nvidia-smi。如果仍然黑屏，可能是nouveau冲突或Secure Boot签名问题。nouveau禁用检查/etc/modprobe.d/blacklist-nouveau.conf，Secure Boot可以在BIOS里临时关闭，或者给DKMS模块签名。这个恢复流程看起来长，但比在图形界面里反复重启有效。我个人在远程服务器上从不轻易卸载驱动，因为一旦SSH断开，恢复成本极高。如果必须换驱动，优先用APT包管理，避免run方式驱动和APT驱动混用。

4. deb方式安装CUDA：从版本选择到环境变量配置

4.1 选CUDA版本别只看最新：先看框架和驱动

安装CUDA前，先回答三个问题：你要跑什么框架？框架官方推荐哪个CUDA版本？当前驱动最高支持哪个CUDA版本？以PyTorch为例，官网会给出稳定的CUDA组合，比如PyTorch 2.x可能推荐CUDA 11.8或12.1，而不是最新版CUDA 12.6。盲目装最新版，可能遇到torch.cuda.is_available()为False，或者编译自定义算子时报错。查看驱动支持：nvidia-smi右上角显示最高支持版本。如果驱动是535，最高支持CUDA 12.2，你装CUDA 12.4 Toolkit可能编译通过但运行失败，因为驱动不够新。此时要么降Toolkit，要么升级驱动。再看系统版本：Ubuntu 22.04对应仓库ubuntu2204，Ubuntu 20.04对应ubuntu2004，不能混用。最后看磁盘空间：CUDA Toolkit完整安装可能占用5GB到10GB，/usr/local和/var/cache/apt要有足够空间。我的习惯是，在项目初期就固定一个CUDA版本，写到Dockerfile或环境文档里，避免团队成员各自装不同版本。如果必须多版本共存，也尽量控制在两个大版本以内，比如11.8和12.1，方便切换。

4.2 添加NVIDIA官方仓库与keyring

现代CUDA deb安装推荐用keyring方式，比旧版手动复制密钥更省事。以Ubuntu 22.04、CUDA 12.4为例：

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.deb sudo dpkg -i cuda-keyring_1.1-1_all.deb sudo apt-get update

如果下载慢，可以换用就近镜像源，但要注意镜像同步可能滞后，版本不全时仍以官方源为准。添加完成后，执行apt-cache search cuda-toolkit确认能看到cuda-toolkit-12-4等包。如果你用的是旧版local deb包，步骤是：

sudo dpkg -i cuda-repo-ubuntu2204-12-4-local_12.4.0-550.54.14-1_amd64.deb sudo cp /var/cuda-repo-ubuntu2204-12-4-local/cuda-*-keyring.gpg /usr/share/keyrings/ sudo apt-get update

注意local包版本号里带驱动版本，但安装时可以不装驱动。如果你只想要Toolkit，选择cuda-toolkit-12-4包，而不是cuda元包。cuda元包会安装驱动、工具、库、文档等全套内容，体积大且容易覆盖现有驱动。这一点在已有稳定驱动的机器上尤其重要。我一般会在安装前执行apt-get -s install cuda-toolkit-12-4模拟一次，看它准备安装哪些依赖，确认不会删除现有驱动。

4.3 安装toolkit元包而不是cuda大包

确认源可用后，安装：

sudo apt-get install -y cuda-toolkit-12-4

如果你需要特定组件，也可以只装cuda-nvcc-12-4、cuda-cudart-12-4、libcublas-dev-12-4等。安装完成后，检查/usr/local/cuda-12.4是否生成，/usr/local/cuda符号链接是否自动创建。有时候APT安装不会自动创建/usr/local/cuda，需要手动：

sudo ln -sf /usr/local/cuda-12.4 /usr/local/cuda

安装cuDNN时，如果通过APT，可以用sudo apt-get install libcudnn8 libcudnn8-dev，但要注意cuDNN版本和CUDA版本匹配。NVIDIA官方仓库里cuDNN包名可能随版本变化，例如libcudnn8、libcudnn9。安装后用dpkg -l | grep cudnn确认。如果你不用APT装cuDNN，也可以下载tar包手动复制到CUDA目录，但那样升级和卸载都更麻烦。deb方式最大的优势就是组件可查、可升级、可卸载，所以尽量让能走APT的都走APT。我踩过的一个坑是，手动复制cuDNN头文件到/usr/local/cuda/include，后来卸载CUDA时这些文件残留，导致新版本编译时引用了旧cuDNN头，出现奇怪符号错误。deb方式虽然包多，但清理时反而有迹可循。

4.4 配置PATH、LD_LIBRARY_PATH与ld.so.conf

安装完成后，环境变量要配。推荐在~/.bashrc末尾添加：

export PATH=/usr/local/cuda-12.4/bin${PATH:+:${PATH}} export LD_LIBRARY_PATH=/usr/local/cuda-12.4/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}

如果你希望使用符号链接方便切换，也可以写/usr/local/cuda/bin和/usr/local/cuda/lib64。两种写法各有优劣：写死版本号更明确，切换时需要改环境变量；写符号链接更灵活，但多版本切换时要改链接。对于多版本共存，我更推荐写死版本号，然后在需要时用脚本切换。除了PATH和LD_LIBRARY_PATH，还可以配置/etc/ld.so.conf.d/cuda-12-4.conf，内容为/usr/local/cuda-12.4/lib64，然后sudo ldconfig。这样不依赖LD_LIBRARY_PATH，系统级程序也能找到CUDA库。但要注意，如果同时配置多个CUDA版本到ld.so.conf，可能导致加载顺序混乱，通常只保留当前主用版本。配置完成后，执行source ~/.bashrc，用echo $PATH和echo $LD_LIBRARY_PATH确认。如果LD_LIBRARY_PATH过长，可能影响其他库加载，建议只在需要时设置，或者用/etc/ld.so.conf.d替代。这个取舍要根据你的使用场景决定。

4.5 验证安装：nvcc、nvidia-smi、bandwidthTest

验证分三步。第一步，nvcc -V应该输出CUDA编译版本，如Cuda compilation tools, release 12.4。第二步，nvidia-smi应该正常显示GPU和驱动版本，且右上角CUDA Version不低于Toolkit版本。第三步，编译运行一个sample或写一个小程序。可以安装cuda-samples-12-4，然后：

cd /usr/local/cuda-12.4/samples/1_Utilities/bandwidthTest sudo make ./bandwidthTest

如果看到Result = PASS，说明驱动、Toolkit、GPU通信正常。没有samples也没关系，可以写一个简单的CUDA程序：

cat > test.cu <<'EOF' #include <cstdio> int main(){ printf("hello cuda\n"); return 0; } EOF nvcc test.cu -o test ./test

如果能编译运行，说明Toolkit基本可用。再进Python验证：

python -c "import torch; print(torch.__version__, torch.version.cuda, torch.cuda.is_available())"

如果torch.cuda.is_available()为True，说明框架层面的CUDA依赖也通了。注意，PyTorch可能自带CUDA运行时，所以即使系统Toolkit版本和torch.version.cuda不完全一致，也可能正常工作。但如果你要编译自定义CUDA扩展，系统nvcc版本必须和PyTorch编译时使用的CUDA版本兼容。这个细节在做目标检测、大模型微调时很关键。

5. run方式安装CUDA：交互选项逐项拆解与避坑

5.1 下载runfile与完整性校验：gzip报错怎么破

run方式安装包通常叫cuda_12.4.0_550.54.14_linux.run，体积2GB到4GB。下载时最容易遇到两个问题：下载不完整和文件损坏。热词里出现的“cuda .run gzip: stdin: invalid compressed>sha256sum cuda_12.4.0_550.54.14_linux.run

对比官网值。如果不一致，说明文件损坏，用wget -c续传或重新下载。下载前检查磁盘空间：df -h /tmp /var/tmp /usr/local，run安装器可能先解压到/tmp，空间不足也会导致奇怪错误。下载完成后，赋予执行权限：

chmod +x cuda_12.4.0_550.54.14_linux.run

如果校验通过但安装仍报gzip错误，可以尝试用bash执行而不是sh，或者把安装包放到不带空格、权限正常的路径。还有一种情况是文件在Windows下经过某些工具传输，换行符或编码被修改，虽然少见，但校验值会变。最稳妥的做法永远是：先校验，再安装。我见过有人连续装了五次都报gzip错误，最后发现是浏览器下载被安全软件截断，换用命令行下载一次就过了。

5.2 安装向导每一项到底勾不勾

执行：

sudo sh cuda_12.4.0_550.54.14_linux.run

向导会先显示协议，输入accept。接着出现选项列表，通常包括Driver、CUDA Toolkit、CUDA Samples、CUDA Demo Suite、CUDA Documentation等。我的建议是：如果你已经有稳定驱动，Driver不要勾选；如果你是新机器且没有驱动，可以勾选Driver，但要接受它可能覆盖系统驱动。Toolkit必须勾选。Samples可选，装上有助于验证，但会占空间。Documentation可选，一般不需要。Demo Suite可选，新手可以不装。Symlink选项建议勾选，它会创建/usr/local/cuda符号链接，方便路径管理。安装路径默认/usr/local/cuda-12.4，不建议改到奇怪位置。如果你的驱动版本低于新CUDA要求，而你又不想现在换驱动，可以只装Toolkit，然后降级Toolkit版本。安装完成后，向导会提示是否安装成功，并建议把环境变量加到.bashrc。不要直接复制整段，按自己的版本号修改。如果勾选了Driver，安装器可能提示需要重启，重启前确认没有重要任务。我个人的做法是，在已有驱动的机器上永远取消Driver，驱动单独用APT管理，这样升级和卸载都更清晰。

5.3 已有驱动时的冲突处理

已有APT驱动的情况下，run安装器如果检测到系统驱动，可能会提示版本不匹配或要求卸载。此时不要让它自动卸载，选择只安装Toolkit。安装完成后，检查nvidia-smi是否仍然正常。如果异常，可能是run安装器修改了/usr/lib/modules或/etc/modprobe.d。可以查看dkms status，看看是否有多个NVIDIA模块版本。如果冲突，考虑卸载run方式驱动，恢复APT驱动。具体步骤：sudo /usr/bin/nvidia-uninstall，然后sudo apt-get install --reinstall nvidia-driver-版本号，再sudo update-initramfs -u，重启。注意，nvidia-uninstall可能会移除当前正在使用的驱动，必须在TTY或可恢复环境下操作。另外一个常见冲突是，系统里同时存在/usr/local/cuda和APT安装的/usr/bin/nvcc。APT安装的cuda-nvcc可能把nvcc放到/usr/bin，而run方式放在/usr/local/cuda/bin。PATH顺序决定使用哪个。用type -a nvcc查看所有路径，确保使用的是你期望的版本。如果混乱，可以卸载其中一个，或者用update-alternatives统一管理。

5.4 安装后的环境配置与多版本符号链接

run方式安装完成后，环境变量配置和deb类似，但路径通常固定为/usr/local/cuda-12.4。在~/.bashrc添加：

export CUDA_HOME=/usr/local/cuda-12.4 export PATH=$CUDA_HOME/bin${PATH:+:${PATH}} export LD_LIBRARY_PATH=$CUDA_HOME/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}

如果你有多个版本，比如11.8和12.4，可以写一个切换函数：

cuda_switch() { case "$1" in 11.8) export CUDA_HOME=/usr/local/cuda-11.8 ;; 12.4) export CUDA_HOME=/usr/local/cuda-12.4 ;; *) echo "usage: cuda_switch {11.8|12.4}" return 1 ;; esac export PATH=$CUDA_HOME/bin${PATH:+:${PATH}} export LD_LIBRARY_PATH=$CUDA_HOME/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}} echo "CUDA_HOME=$CUDA_HOME" }

把函数加到.bashrc，执行cuda_switch 12.4即可切换。注意LD_LIBRARY_PATH会累积旧路径，切换前最好清空或重置。我一般会在函数里先去掉旧的/usr/local/cuda*/lib64，再追加新路径，避免混用。符号链接方面，/usr/local/cuda可以指向当前主用版本，执行sudo ln -sf /usr/local/cuda-12.4 /usr/local/cuda。但如果你用环境变量写死版本号，符号链接就不是必须的。多版本共存时，不要同时把多个版本的lib64都加到ld.so.conf，否则运行时可能加载错误版本。这个坑在编译OpenCV、TensorRT等依赖CUDA的库时特别明显。

6. 多版本CUDA共存与切换：环境变量、alternatives、conda和Docker

6.1 环境变量切换法

环境变量切换是最直接的方式。安装多个CUDA版本到/usr/local/cuda-11.8、/usr/local/cuda-12.4，然后在.bashrc里定义函数，按需切换PATH和LD_LIBRARY_PATH。这种方式的优点是简单、即时生效，不影响其他用户。缺点是只对当前shell有效，新开终端需要重新执行，或者依赖.bashrc初始化。可以配合direnv或项目脚本，在进入项目目录时自动切换。比如项目A需要CUDA 11.8，项目B需要CUDA 12.4，可以在项目根目录放一个envrc，进入时自动设置。需要注意的是，LD_LIBRARY_PATH是全局影响，切换后所有新启动的程序都会使用新库，包括系统图形程序。如果切换后出现桌面异常，可以在切换前保存原值，退出时恢复。我的经验是，把切换函数写进.bashrc后，每次开终端默认切到主用版本，其他版本只在特定项目手动切。这样既方便又不容易乱。如果你用zsh，逻辑一样，放到.zshrc即可。

6.2 update-alternatives管理/usr/local/cuda

update-alternatives适合管理系统级默认CUDA链接。假设有11.8和12.4，可以这样注册：

sudo update-alternatives --install /usr/local/cuda cuda /usr/local/cuda-11.8 110 sudo update-alternatives --install /usr/local/cuda cuda /usr/local/cuda-12.4 120

然后切换：

sudo update-alternatives --config cuda

选择对应编号。这样/usr/local/cuda会指向所选版本，环境变量如果写的是/usr/local/cuda/bin，就会跟随切换。优点是系统级统一，多用户共享；缺点是切换需要sudo，且如果同时有人用不同版本，会互相影响。适合个人工作站或团队约定主版本。注意，update-alternatives管理的是符号链接，不会自动管理LD_LIBRARY_PATH。如果你环境变量里写的是/usr/local/cuda/lib64，切换后新开的shell会使用新库，但已经运行的程序不会改变。对于需要编译不同CUDA版本的项目，建议在编译前确认nvcc -V和/usr/local/cuda指向一致。我通常会同时保留环境变量切换法和alternatives，但主用alternatives决定系统默认，项目内用环境变量覆盖。

6.3 conda环境与PyTorch自带的CUDA运行时

很多人用conda安装PyTorch，会发现即使系统没装CUDA Toolkit，torch.cuda.is_available()也是True。这是因为PyTorch的conda包或pip wheel里自带了CUDA运行时库，它们被放在conda环境或pip包的nvidia目录下。此时系统CUDA Toolkit主要影响nvcc编译，而PyTorch运行时使用的是自带的CUDA runtime。你可以在conda里安装cudatoolkit=11.8或cuda-toolkit=12.4，但要注意和PyTorch版本匹配。查看PyTorch使用的CUDA版本：python -c "import torch; print(torch.version.cuda)"。查看系统nvcc版本：nvcc -V。两者可以不同，但如果你要编译CUDA扩展，最好保持一致。conda环境的优先级高于系统PATH时，which nvcc可能指向conda环境里的nvcc。如果你希望使用系统CUDA，可以调整PATH顺序，或者卸载conda里的cudatoolkit。我的建议是：运行时依赖交给PyTorch自带的CUDA，编译时依赖明确使用系统Toolkit，并在项目文档里写清楚。这样可以避免“明明nvidia-smi正常，torch也能用，但编译扩展报找不到nvcc”的困惑。

6.4 Docker场景下宿主机驱动与容器toolkit关系

Docker里跑CUDA，关系要理清：宿主机只需要安装NVIDIA驱动和nvidia-container-toolkit，不需要在宿主机安装CUDA Toolkit。容器镜像里会自带CUDA Toolkit和cuDNN。运行容器时加--gpus all，容器内就能访问GPU。宿主驱动版本决定容器内可用的最高CUDA运行时版本，所以如果宿主机驱动太老，新镜像可能跑不起来。检查方法：宿主机nvidia-smi看驱动版本，容器内nvcc -V看Toolkit版本。两者不需要完全一致，但驱动要满足容器CUDA的最低要求。如果你在容器里编译，容器内的nvcc和系统CUDA路径都是镜像自带的，不会受宿主机/usr/local/cuda影响。这样其实更干净。迁移项目时，用Dockerfile固定CUDA版本，比在宿主机反复卸载安装更省心。注意，nvidia-container-toolkit不是CUDA Toolkit，它只是让容器访问GPU的运行时，不要混淆。宿主机上不建议再装一套CUDA Toolkit，除非你确实需要在宿主机编译。我的经验是，开发环境用Docker，宿主机只保留驱动，能避免大量版本冲突。

7. 常见问题与排查技巧实录

7.1 nvidia-smi正常但nvcc找不到或版本不对

nvidia-smi正常说明驱动没问题，nvcc找不到说明CUDA Toolkit没装或PATH没配。先执行which nvcc，如果没有输出，检查/usr/local/cuda/bin/nvcc是否存在。如果存在，把/usr/local/cuda/bin加入PATH。如果不存在，说明Toolkit没装，需要安装cuda-toolkit-版本号。如果nvcc -V显示的版本和nvidia-smi右上角版本不同，这是正常的：nvidia-smi显示驱动最高支持版本，nvcc显示Toolkit版本。但如果nvcc版本高于驱动支持版本，运行CUDA程序可能报错。可以用表格快速判断：

排查时先看路径，再看版本，最后看框架。不要一上来就重装系统。

7.2 安装报gzip stdin invalid compressed data的几种原因

这个错误几乎都发生在runfile安装阶段，原因主要有四类。第一，下载不完整：网络中断、浏览器截断、磁盘满导致文件尾部缺失。解决：sha256sum校验，重新下载。第二，文件传输损坏：通过某些工具复制时被修改。解决：重新从官方下载，或用rsync传输。第三，/tmp空间不足：run安装器需要解压到临时目录。解决：df -h /tmp，如果空间小，可以设置TMPDIR到空间大的分区，例如export TMPDIR=/home/user/tmp再安装。第四，安装包本身与架构不匹配：下载了错误架构的包。解决：确认uname -m是x86_64，下载对应包。如果是Ubuntu 22.04，选linux.run，不要选linux_arm64.run。还有一个隐蔽原因：文件系统只读或权限异常。解决：把安装包放到/home下执行，避免/mnt只读挂载。排查顺序建议：先校验，再查空间，再换目录，最后重新下载。我遇到过一次，安装包校验通过但安装仍报gzip错误，最后发现/tmp挂载在内存盘且已满，清理后一次通过。

7.3 CUDA与驱动版本不匹配导致PyTorch不可用

PyTorch报错“CUDA driver version is insufficient for CUDA runtime version”，通常是因为PyTorch自带的CUDA运行时版本高于驱动支持版本。比如驱动支持CUDA 11.8，但你装了PyTorch cu121版本。解决方式有两种：升级驱动，或者换PyTorch版本。查看驱动最高支持版本：nvidia-smi右上角。查看PyTorch编译版本：python -c "import torch; print(torch.version.cuda)"。如果驱动是470，最高支持CUDA 11.4，那么PyTorch cu118可能无法运行，需要升级驱动到520以上，或安装cu113版本的PyTorch。升级驱动可以用ubuntu-drivers autoinstall，但要注意内核和Secure Boot。换PyTorch版本更简单，去官网找对应CUDA版本的安装命令。我的经验是，先固定驱动版本，再选PyTorch版本，最后选系统Toolkit版本。顺序不要反。如果多个项目需要不同CUDA，优先用conda环境或Docker隔离，而不是反复升降系统驱动。系统驱动是共享资源，改动影响面大。

7.4 卸载后黑屏、循环登录、分辨率异常的急救

卸载CUDA后黑屏或循环登录，通常是驱动被误删或损坏。急救步骤：重启，在GRUB菜单选择Advanced options，进入recovery mode，选择root shell。如果有网络，执行sudo apt-get update，然后sudo apt-get install --reinstall nvidia-driver-推荐版本。如果不知道推荐版本，执行ubuntu-drivers devices查看。安装完成后sudo update-initramfs -u，sudo reboot。如果仍然黑屏，检查/etc/modprobe.d/blacklist-nouveau.conf是否禁用了nouveau，确保没有冲突。Secure Boot开启时，DKMS模块可能未签名，可以在BIOS关闭Secure Boot或手动签名。循环登录还可能是.Xauthority权限问题，可以删除~/.Xauthority后重启，但这种情况较少见。分辨率异常通常是驱动未加载，用nvidia-smi确认。如果nvidia-smi报“couldn't communicate with NVIDIA driver”，说明驱动没装上。远程机器黑屏时，用SSH登录后检查systemctl status gdm3，必要时重启显示管理器。我个人的急救包里常备一个USB启动盘和一台可物理接触的显示器，远程操作前一定先确认有带外管理。

7.5 磁盘空间、权限、下载慢等杂项排查

CUDA相关操作很吃磁盘。安装前检查/usr/local、/var/cache/apt、/tmp、/home空间，建议至少留20GB。卸载后可以用sudo apt-get autoremove --purge和sudo apt-get clean清理缓存。下载慢时，优先用命令行wget -c或curl -L -O，支持续传。如果官方源慢，可以配置就近镜像源，但要注意镜像同步状态，版本不一致时以官方校验值为准。权限方面，所有系统级安装都用sudo，但不要把整个/usr/local权限改成777，这会带来安全隐患。环境变量文件.bashrc属于用户，不要用sudo修改，否则会导致登录时权限错误。如果遇到Permission denied，先看文件所有者和权限，用ls -l确认。还有一个常见问题：sudo nvcc -V和普通用户nvcc -V结果不同，因为PATH不同。排查时统一用普通用户执行，除非确实需要系统级路径。最后，建议定期用df -h和du -sh /usr/local/cuda-*查看占用，多个版本共存时很容易吃掉几十GB。

7.6 我踩过的三个坑和一个固定习惯

第一个坑，用apt purge "*cuda*"把cuda-drivers删了，连带驱动消失，远程机器直接失联，最后靠云控制台恢复。第二个坑，run方式安装时勾选了Driver，和APT驱动混用，导致nvidia-smi版本和dkms status对不上，重装驱动才解决。第三个坑，下载runfile没校验，安装时报gzip错误，反复重试浪费一晚上，后来发现是文件下载不完整。现在我的固定习惯是：任何CUDA操作前，先执行nvidia-smi、nvcc -V、dpkg -l | grep -i cuda、ls -l /usr/local | grep cuda，把结果保存到~/cuda_backup_日期.txt；卸载时先模拟，再执行；安装后先用bandwidthTest和PyTorch验证；多版本只用环境变量切换，不轻易改系统默认。这套流程看起来啰嗦，但能保证在需要降级、升级、迁移时，十分钟内理清当前状态。CUDA环境搭建不是一锤子买卖，把版本关系和管理习惯理顺，比记住多少条安装命令都重要。