在 Ubuntu 上装完驱动或 CUDA Toolkit 之后 nvidia-smi 看不到 GPU，先要分清是哪一类失败：命令本身不存在、命令存在但提示无法与驱动通信、能执行但设备列表为空。这三种情况指向的原因完全不同，直接重装驱动往往白费时间。最快的判断路径是先看 lspci 能否枚举到 NVIDIA 设备，再看内核模块有没有加载，最后才回到驱动包版本和 Secure Boot 签名上。如果 lspci 里根本没有 NVIDIA 设备，问题在虚拟化、PCIe 或 BIOS 层面，继续在系统里折腾驱动没有意义。
先确认物理设备可见性，再确认内核模块加载情况，最后才处理驱动包。适用于物理机或已直通 GPU 的云主机；如果lspci看不到 NVIDIA 设备、或运行在未配置 GPU 透传的容器里，就不属于驱动排查范围。判断依据是lspci输出、lsmod是否加载 nvidia 模块、dmesg中的 NVRM 报错。回退方式是保留可用旧内核启动项，或退回ubuntu-drivers devices给出的推荐版本。
先确认当前场景和目标
动手前先确认三件事，能避免把时间花在错误方向上。第一，机器形态：物理机、带 GPU 直通的云主机、虚拟机，还是容器。容器里运行 nvidia-smi 需要宿主机驱动正常并通过 nvidia-container-toolkit 之类的运行时把设备暴露进来，宿主机没装好，容器里怎么调都不通。第二，失败的具体表现：执行命令时是提示 command not found，还是出现类似 NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver 的报错，还是正常输出但看不到设备行。第三，安装方式：用 apt 从 Ubuntu 仓库装、用 ubuntu-drivers 自动装，还是用官方 .run 文件装。混装最容易出问题，因为两套包会互相覆盖文件。
目标也要说清楚：让 nvidia-smi 能列出 GPU 型号、驱动版本和显存信息，且不报错。至于 CUDA Toolkit 是否可用，是下一步的事——nvidia-smi 只依赖驱动，不依赖 Toolkit，所以它失败时先别怀疑 CUDA 版本。
可以先跑这几条命令收集信息，把结果留下来再决定改哪里：
lspci -nn | grep -i nvidia
lsmod | grep -E 'nvidia|nouveau'
mokutil --sb-state
dkms status
dmesg | grep -iE 'nvrm|nvidia' | tail -n 30判断条件很直接：lspci 有 NVIDIA 显示或 3D 控制器条目，说明硬件层可见；lsmod 里有 nvidia、nvidia_modeset、nvidia_uvm 才算模块加载成功；如果只看到 nouveau 在跑，说明开源驱动还占着设备。
按这个顺序处理
第一步，排除开源驱动占用。nouveau 加载后 NVIDIA 闭源驱动无法接管设备。检查 /etc/modprobe.d/ 下是否有禁用 nouveau 的配置，内容通常是 blacklist nouveau 和 options nouveau modeset=0，写好后需要执行 sudo update-initramfs -u 并重启才生效。第二步，看 Secure Boot。开启 Secure Boot 时，未签名的内核模块会被拒绝加载，dmesg 里通常会出现模块加载失败或签名相关的提示。要么在 BIOS 里关掉 Secure Boot，要么在安装驱动过程中完成 MOK 密钥注册，这两条路选一条，不要半途中断。第三步，检查 DKMS 状态。内核升级后模块没有为新内核重建，是 nvidia-smi 突然失效的常见原因，dkms status 里能看到模块与内核版本的对应关系，必要时执行 sudo dkms autoinstall。
如果前面都正常但驱动确实没装好，再考虑清理重装。下面的片段是通用骨架，版本号需要按 ubuntu-drivers devices 给出的推荐值替换，不要照抄某个固定数字：
# 查看可用与推荐的驱动版本
ubuntu-drivers devices
# 清理已有驱动包（确认没有依赖业务后再执行）
sudo apt purge '^nvidia-.*' '^libnvidia-.*'
sudo apt autoremove
# 安装推荐版本，<推荐版本号> 从上一步输出里取
sudo apt install nvidia-driver-<推荐版本号>
sudo reboot之前用 .run 文件装过的机器，建议先用脚本自带的 --uninstall 卸载干净再走 apt，否则残留的库文件会干扰新驱动。服务器上如果不需要图形界面，用 apt 包安装一般不需要额外处理 OpenGL 相关选项；只有用 .run 文件在带桌面的机器上安装时，才需要考虑是否加 --no-opengl-files 之类的参数，避免覆盖系统图形库。
改完后怎么验证
重启后按顺序验证，每一步都要看到预期信号再往下走。先执行 nvidia-smi -L，正常应列出每块 GPU 的型号和 UUID。再执行 nvidia-smi，顶部会显示驱动版本和该驱动支持的 CUDA 版本，下方是设备表格，列出显存占用和进程信息。注意这里的 CUDA 版本表示驱动能支持的上限，不等同于已安装的 Toolkit 版本，后者用 nvcc --version 查看，两者不一致并不一定是故障。
nvidia-smi -L
nvidia-smi
cat /proc/driver/nvidia/version
lsmod | grep nvidia如果 nvidia-smi 正常但 CUDA 程序仍报错，再检查 Toolkit 与驱动的版本对应关系，以及 CUDA_HOME 和动态库路径是否指向正确的安装目录。验证驱动是否真的稳定，可以再跑一次 dmesg | grep -i nvrm，确认没有新的错误记录；有 Xid 类报错说明问题在硬件或驱动交互层面，不只是安装问题。
容易忽略的边界
虚拟机与容器场景里，宿主机驱动正常不代表客户机可用，需要确认 GPU 直通或设备挂载是否配置到位，这类环境里在客户机内重装驱动通常无效。笔记本双显卡机型，NVIDIA 设备可能被电源管理策略挂起，lspci 可见但模块未加载，需要结合具体机型确认。内核版本与驱动版本存在兼容区间，过于新的内核上装较旧的驱动，编译模块可能直接失败，此时应优先选 Ubuntu 仓库里跟随内核更新的驱动版本，而不是硬上最新或最旧的包。
不适用的情况也要说明：Secure Boot 关闭策略在企业受控设备上未必允许；清理驱动包可能连带卸载依赖这些包的桌面组件或其他软件，操作前应确认影响范围。回退建议是先保留一个能正常启动的旧内核条目，改坏时可以从中选择启动；如果安装驱动前备份过 /etc/X11/xorg.conf 或相关配置，出问题时可以直接还原。临时性的规避手段，比如切回 nouveau 或换用软件渲染，只能当作恢复可操作状态的手段，不能当作解决方案。