Linux 更换 CUDA 的低风险路线：先识别来源，再并行验证与回退

Linux 上的 CUDA 故障常被一句“版本不兼容”概括，实际却可能发生在四个不同层次：内核中的显卡驱动、编译工具链、动态运行库，以及 TensorFlow、PyTorch 等上层框架。它们的版本号与安装来源并不总是相同。直接删除目录或先覆盖驱动，容易把本来可用的生产环境一并破坏。稳妥升级的起点不是执行卸载命令，而是建立现状清单和可回退副本。

盘点机器，不要只看一个版本命令

nvidia-smi显示的是当前驱动及其运行状态，nvcc --version反映 shell 找到的编译器工具链，两者输出不同并不必然异常。应用还可能通过虚拟环境自带运行库，不经过系统的 /usr/local/cuda。因此要同时记录 GPU 型号、内核与驱动、已安装工具链目录、环境变量、动态链接结果和框架检测信息。

• 查看系统包管理器中与驱动、CUDA、cuDNN 相关的包。
• 检查 /usr/local 下是否存在多个版本目录及符号链接。
• 记录 PATH、LD_LIBRARY_PATH 与加载器配置。
• 对关键二进制使用链接检查，确认它实际载入哪个运行库。
• 在每个虚拟环境中分别记录框架版本和 GPU 可见性。
• 保存正在使用 GPU 的进程，安排可以中断的维护窗口。

还要识别原来的安装渠道。发行版仓库、厂商软件源、独立运行文件、容器镜像和手工复制文件各有自己的卸载方式。包管理器安装的内容应由包管理器移除；独立安装器通常提供对应的卸载程序；手工删除只适用于确实由手工放置且已核对清单的文件。混用渠道会导致包数据库认为文件仍在，或升级后仍加载遗留库。

先确认是否真的需要更换驱动

工具链升级不总要求同时更新驱动，框架也可能携带它需要的部分用户态库。驱动属于系统级组件，改动会影响所有 GPU 工作负载，风险通常高于增加一个并行工具链。应从目标应用的兼容矩阵倒推最低要求，再比较当前驱动能力。若现有驱动满足目标运行时，保留驱动只安装新工具链，往往能减少重启、显示服务中断和内核模块问题。

nvidia-smi; which nvcc; nvcc --version; readlink -f /usr/local/cuda; ldconfig -p | grep -E 'cuda|cudnn'

这些命令只能帮助定位，不能替代兼容性判断。尤其不要把驱动界面显示的“CUDA Version”直接理解为机器已经安装同名工具链；它更接近驱动能够支持的运行时能力上限。真正用于编译的头文件、库和编译器仍需单独确认。

优先并行安装，让旧环境继续可用

多数工具链可以放在带版本号的目录中并存，例如旧版与新版分别拥有自己的 bin 和 lib64。不要在验证前改写全局符号链接，也不要立即从启动脚本删除旧路径。先为测试账户或单个服务显式设置新目录，在隔离终端中编译和运行最小程序；通过后再切换默认入口。

包管理与独立安装器不能互相“接管”

包管理方式便于跟踪依赖、升级与卸载，适合希望与发行版生命周期协同的机器；独立安装器能提供自包含工具链，但常同时询问是否安装驱动、OpenGL 库、示例和符号链接。服务器上若已有稳定驱动，通常不应在没有必要时让工具链安装器再次覆盖它。带图形桌面的主机还要评估显示管理器停启，远程维护则应准备失去图形界面时的控制通道。

手工复制 cuDNN 头文件和共享库曾是常见做法，但它会丢失包归属与版本关系，也容易让多个版本混在同一目录。若必须手工部署，应保留压缩包、文件清单、权限和目标路径，并避免覆盖无法恢复的旧文件。更可控的办法是使用版本化目录或受管理的软件包，让加载路径明确指向所需组合。

验证顺序从系统到应用逐层推进

1. 驱动层确认 GPU 可见、内核模块正常且无异常占用。
2. 工具链层编译官方或自建的最小设备查询程序。
3. 动态库层检查新进程实际加载的路径，不依赖环境猜测。
4. 框架层在新虚拟环境中枚举设备并执行一次小型张量计算。
5. 业务层运行代表性任务，比较结果正确性、显存与稳定性。
6. 重启或重新登录后复验，排除只在当前 shell 生效的配置。

“能够列出 GPU”只是第一关。框架可能发现设备，却在首次计算时因运行库缺失或算子不兼容而失败；编译成功也不保证运行时加载了同一套库。测试应真正分配显存、执行计算并检查输出。若机器承载多个用户，还要在干净账户或服务启动环境中复验，防止个人 shell 配置掩盖全局问题。

export CUDA_HOME=/usr/local/cuda-X.Y; export PATH=$CUDA_HOME/bin:$PATH; export LD_LIBRARY_PATH=$CUDA_HOME/lib64:${LD_LIBRARY_PATH}

示例中的版本目录必须替换为实际安装位置，且这类临时环境变量适合验证，不应直接当作所有服务的永久配置。生产服务更适合在其启动单元、容器或环境文件中显式声明，避免交互式 shell 与后台进程使用不同路径。动态库也可以通过加载器配置管理，但修改后要刷新缓存并核对解析结果。

回滚不是重新安装，而是恢复已知工作组合

并行安装的优势在于回滚可以很小：恢复符号链接、环境文件或服务镜像，重新启动进程并验证旧组合。若连驱动也变更，则要准备旧软件包、匹配内核和控制台访问，并预留重启窗口。回滚条件应在升级前写清，例如关键作业无法运行、GPU 出现持续错误或性能显著偏离基线，不能等故障发生后才争论是否坚持新版。

升级成功的定义不是新版本出现在命令输出里，而是目标应用在可重复启动的环境中完成代表性工作，同时旧路径仍能在约定时间内恢复。

清理旧版应当发生在观察期之后

当新组合经过重启、定时任务和实际负载验证，并确认没有其他用户或项目引用旧目录，才进入清理。先移除旧版在环境变量和服务配置中的引用，再按原安装渠道卸载；随后检查残留符号链接、加载器缓存和磁盘文件。不要凭目录访问时间判断无人使用，因为部分作业可能按周或按月运行。

一份完整变更记录应保留旧状态、目标兼容依据、安装来源、变更命令、验证结果、当前默认版本和回退步骤。下次升级时，它能迅速解释机器为何同时存在多套库，也能避免再次混用渠道。把驱动、工具链、运行库与框架分层处理，CUDA 更换就不再是一场“卸干净再祈祷能装回去”的冒险，而是一次可观察、可切换、可撤销的工程变更。