★ FEATURED ARTICLE “nvidia-smi: command not found”大概是 Linux 装显卡驱动时最经典、也最让人摸不着头脑的报错。我第一次遇到是在一台刚装完系统的服务器上当时还以为是显卡坏了折腾半天才发现只是驱动没装上。后来搞多了就明白这个报错本身不复杂但它背后可能对应着完全不同的几类问题驱动压根没装、驱动装了但内核模块没加载、PATH 环境变量被人改了或者你根本是在容器里调用一个不存在的宿主命令。这篇文章我按自己排障的习惯来写给你一套从判断、修复到验证的完整流程读完基本不会再被这个报错卡住。1. 先稳住快速判断这个报错属于哪一类问题很多初学者看到“command not found”就以为系统出大问题了实际上这句话的含义非常直白shell 沿着 PATH 环境变量里列出的目录去找 nvidia-smi 这个可执行文件结果没找到。就这么简单。但关键在于“为什么没找到”这背后的原因可能大不相同。我一般会先做三分钟自查把问题归类到某个方向再去处理。1.1 报错信息里藏着两条线索“command not found”和“No such file or directory”是两种完全不同的错误我见过不少人把这两个搞混然后在错误的方向上浪费好几个小时。bash: nvidia-smi: command not found说明 shell 按 PATH 找了一圈所有目录里都没有叫 nvidia-smi 的文件。这种情况多半是驱动未安装或者安装时没有把可执行文件放进 PATH 能搜到的目录。bash: /usr/local/cuda/bin/nvidia-smi: No such file or directory这个不是“找不到命令”而是你明确指向了一个路径但该路径下没有这个文件。常见于你手动导出了某个 CUDA 路径但对应目录其实不存在或者 CUDA 被卸载/移动了。遇到报错先别急着搜“重装驱动”看一眼报错原文到底属于哪种能帮你少走一半弯路。1.2 三分钟自查动手之前先问自己几个问题我在替别人排查这类问题时一般会先问三个问题对方回答完问题基本就锁定了一半这台机器以前跑过 GPU 任务吗如果是一台全新机器或者刚装完操作系统那大概率是驱动未安装直接跳到 3.1 那套方案。你最近动过什么升级过内核改过 PATH装过 conda删过 CUDA或者从 Docker 容器里跑 nvidia-smi任何一条都可能导致命令“消失”。是所有人、所有终端都报错还是只有某个终端报错这能帮你判断是系统级问题还是用户级配置问题。这三个问题的答案直接决定你接下来应该读 3.2 还是 3.3 的内容。2. nvidia-smi 到底是个什么命令它为什么会“消失”要把问题解决得彻底得先搞清楚 nvidia-smi 是什么、从哪里来、依赖什么。2.1 先明白 nvidia-smi 的来历nvidia-smi 是 NVIDIA 显卡驱动自带的管理工具全称是 NVIDIA System Management Interface。它的职责是查询 GPU 状态、显存占用、温度、功耗、驱动版本和 CUDA 版本等信息。平时我们用nvidia-smi看显存够不够当容器跑不起来时用nvidia-smi看驱动还在不在可以说它就是 NVIDIA GPU 的“体检仪”。重要的是它不是独立安装的一个软件而是跟着 NVIDIA 驱动程序一起安装的。也就是说你的系统里如果压根没有 NVIDIA 驱动那 nvidia-smi 就根本不存在报错是必然的。它同时还依赖内核中加载的 nvidia 内核模块和/dev/nvidia*设备节点驱动装好了但模块没加载、设备节点没生成命令即使存在也无法正常工作。2.2 命令“消失”的四类典型原因我把实际排障中遇到的 case 归成四类基本覆盖了 95% 以上的场景原因类型典型症状判断方法驱动未安装新系统、刚装完系统、从未装过 NVIDIA 驱动lspci | grep -i nvidia能看到显卡硬件但/usr/bin/nvidia-smi不存在驱动已装但模块加载失败驱动安装后没重启、升级内核后未重编模块、Secure Boot 阻止找不到/dev/nvidia*dmesg里有 NVRM 相关报错PATH 配置变化手动设置过 PATH、conda 环境干扰、多版本 CUDA 切换find / -name nvidia-smi 2/dev/null能找到文件但 shell 就是说 not found容器/虚拟环境隔离Docker 容器内跑 nvidia-smi 报错宿主机正常查看宿主机nvidia-smi是否正常其中第一类最简单第四类常见于深度学习环境第二类最容易被忽视第三类则最容易耗光人的耐心。3. 按场景给出修复方案从驱动安装到环境修复一步步来下面我按照实际排查中从简到繁的顺序写出每种场景的实操步骤。注意无论哪种方案涉及系统级操作都需要 root 权限建议先用sudo -i或确保你的用户有 sudo 权限。3.1 场景A全新机器驱动从未装过这是最单纯的情况。前提是你已经确认lspci | grep -i nvidia能看到 NVIDIA 显卡。注意lspci 能看到显卡只能代表硬件被系统识别和驱动没有任何关系很多人在这里产生误判。以最常见的 Ubuntu/Debian 系系统为例我推荐优先用发行版仓库安装驱动而不是去官网下载 .run 文件。原因是 apt 安装能自动处理内核头文件、DKMS 模块注册等一系列脏活而且驱动版本经过发行版测试兼容性有保障。步骤如下# 1. 先更新系统软件源和所有包 sudo apt update sudo apt upgrade -y # 2. 查看推荐的驱动版本 ubuntu-drivers devices # 3. 一键安装 sudo apt install nvidia-driver-535 # 版本号以ubuntu-drivers devices输出为准 # 4. 重启 sudo reboot重启之后直接敲nvidia-smi。正常情况你会看到一张表格里面有 GPU 型号、驱动版本、显存占用等信息。这里有个小经验新装驱动后无论如何都要重启一次不能偷懒。因为内核模块的加载和/dev/nvidia*设备节点的创建都发生在系统初始化阶段不重启的话很容易出现“版本对不上”或“设备不存在”的怪问题。如果你用的是其他 Linux 发行版思路一致只是包管理器不同。比如 fedora 用dnf install akmod-nvidiaArch 系用pacman -S nvidia nvidia-utils。不管哪种发行版优先使用包管理器来装都是我最推荐的做法。3.2 场景B驱动装了却照样报 not found这种情况比场景A多得多。常见于“明明按教程装好了驱动过几天升级了内核重启后就不能用了”或者“装完驱动没重启就直接跑命令”。处理顺序建议这样来第一步重启试一次。如果驱动装完到现在还没重启过先重启再看。很多人卡在这一步问题却不是问题本身。第二步确认命令文件在不在系统里。# 检查常见安装路径 ls -l /usr/bin/nvidia-smi ls -l /usr/lib/x86_64-linux-gnu/nvidia/ 2/dev/null ls -l /usr/local/cuda/bin/nvidia-smi 2/dev/null如果find / -name nvidia-smi 2/dev/null能找到文件但 shell 敲 nvidia-smi 还是 not found那问题出在 PATH 上。先把文件所在目录加进 PATH 就能立刻验证export PATH/usr/local/cuda/bin:$PATH nvidia-smi如果这样能跑通再把它写进~/.bashrc或/etc/profile.d/cuda.sh做到永久生效。注意这里加 PATH 一定要用$PATH把原有的带上否则会覆盖系统原有的所有命令路径引发新的连锁问题。第三步检查内核模块是否加载。命令文件存在只是第一步模块加载失败同样会导致 nvidia-smi 无法工作。lsmod | grep nvidia如果没有输出说明模块没加载尝试手动加载sudo modprobe nvidia如果 modprobe 报错看dmesg | tail -50或dmesg | grep -i nvidia通常会提示原因。我在 4.1 和 4.3 里写了最常见的两类内核版本不匹配和 Secure Boot 签名拦截。3.3 场景CDocker 容器里报错这个场景在跑深度学习的人里太常见了。宿主机上nvidia-smi一切正常一进容器就报nvidia-smi: command not found有人就会去容器里装驱动这是最要命的行为。容器共享宿主机的内核驱动必须装在宿主机容器里永远不应该装 NVIDIA 驱动。容器里的 nvidia-smi 是容器运行时通过挂载方式注入的。正确的处理方式是使用 NVIDIA Container Toolkit# 宿主机安装工具包以Ubuntu为例 sudo apt install nvidia-container-toolkit # 重新启动 Docker 服务 sudo systemctl restart docker # 测试容器内访问 GPU docker run --rm --gpus all ubuntu nvidia-smi如果容器里能输出 GPU 信息说明环境正常。如果宿主机同样报 not found那说明问题不在容器回到 3.2 或 3.1 解决宿主机驱动。另外如果运行容器时用的是老版本 Docker不支持--gpus参数或者 19.03 以前的 nvidia-docker 方式还需验证宿主机上的nvidia-container-runtime是否正确配置。总之记住一句话容器是用户态隔离不是隔离驱动。3.4 场景Dconda 环境或其他虚拟环境误伤这个我之前在一个开发者那儿遇到过他在 conda 里折腾了半天 CUDA发现进到 conda 环境后 nvidia-smi 就报 not found退出 conda 就正常。折腾一圈原因是他把某个 conda 包的 bin 目录加到了 PATH 前面而那个目录里没有 nvidia-smi把系统路径的优先级覆盖了。这类问题的排查方法很简单# 在报错的环境里看看 nvidia-smi 到底被解析到哪 which nvidia-smi type -a nvidia-smi # 看看当前 PATH 到底是什么 echo $PATH | tr : \n如果发现 PATH 里排在前面的路径有问题调整环境变量即可。另外特别提醒不要在 conda 里安装任何叫 nvidia-smi 的包来“补缺”这些包基本都不是真正的驱动工具反而会把环境搞得更乱。nvidia-smi 应该来自系统驱动和 Python 虚拟环境无关。4. 避坑清单这些细节才是反复踩坑的根源排障类工作最怕的不是主干流程不懂而是那些不起眼却能把人折磨疯的细节。下面几条我按踩坑频率从高到低排列值得你收藏。4.1 内核版本与驱动版本不匹配这是驱动装好之后最常见的“后遗症”。NVIDIA 驱动是内核模块必须针对当前运行的内核编译。Linux 内核升级后驱动模块如果没有重新编译就会悄悄失效重启后 nvidia-smi 报错。包管理器安装的驱动一般通过 DKMS 机制自动处理这个问题这也是我推荐 apt 的原因。升级内核后 DKMS 会自动帮你把 nvidia 模块针对新内核重编一遍。但如果看到这种报错ERROR: An error occurred while performing the step: Install DKMS kernel module多半是没装内核头文件导致的。解决办法sudo apt install linux-headers-$(uname -r) sudo dpkg-reconfigure nvidia-dkms-535 # 版本号按实际调整检查驱动版本和内核是否匹配可以看# 当前内核版本 uname -r # 驱动模块是否存在 modinfo nvidia | grep ^version4.2 nouveau 驱动冲突这个坑在较老的或特殊配置的机器上经常出现。nouveau 是最初就随内核一起加载的开源 NVIDIA 驱动它会和官方闭源驱动抢占设备导致官方驱动无法正常工作。检查是否被 nouveau 占用lsmod | grep nouveau如果有输出需要禁用 nouveau 并重建 initramfs。典型做法是创建配置文件sudo bash -c echo blacklist nouveau /etc/modprobe.d/blacklist-nouveau.conf sudo bash -c echo options nouveau modeset0 /etc/modprobe.d/blacklist-nouveau.conf sudo update-initramfs -u sudo reboot注意这步非常关键不重建 initramfs、不重启blacklist 就相当于没配。重启后再跑lsmod | grep nouveau应该没有输出这时才能继续装官方驱动。4.3 Secure Boot 挡住内核模块这是新设备上越来越常见的坑。UEFI 安全启动开启时系统只允许加载有合法签名的内核模块。NVIDIA 驱动模块如果没有经过签名即使装好了也会在加载时被拒。判断方式是dmesg | grep -i secure或直接看 modprobe 报错。解决的思路有两条最省事进 BIOS 关掉 Secure Boot。个人学习、内部开发机通常没有严格要求关掉最省心。合规方式用 mokutil 导入自签的模块签名流程比较长需要图形交互。我自己的经验是如果是用来学习的单机或者内部测试服务器直接关 Secure Boot省下大量时间。如果是生产服务器或安全要求高的环境再走签名流程。但你得先知道这个问题的存在否则永远不会想到驱动被安全启动“拦杀”了。4.4 别频繁重装驱动来“碰运气”见过不少同学一看到 nvidia-smi 报错就重装驱动重装完还是不行于是再重装形成死循环。重装不是万能的它在驱动文件损坏时有效但在内核头文件缺失、模块加载被拦截、PATH 配置错误时毫无作用。我的建议每重装一次之前先花五分钟把 dmesg、lsmod、PATH 三个东西查一遍。这三个检查能覆盖 95% 的“重装解决不了的问题”比盲目重装高效得多。4.5 排查问题速查表检查项命令正常状态异常可能PCI 设备识别lspci | grep -i nvidia能看到显卡型号硬件未识别查 PCIe 连接驱动文件ls /usr/bin/nvidia-smi文件存在未安装驱动内核模块lsmod | grep nvidia能看到 nvidia 相关条目模块加载失败设备节点ls /dev/nvidia*有 nvidia0、nvidiactl 等模块未加载或权限不足加载日志dmesg | grep -i nvr无错误信息可看到具体 error5. 事后验证与环境加固装好驱动只是开始修好报错不算完工验证完成、环境稳定才是。我习惯每次搞定后走一遍完整的验证流程并顺手把环境稍微加固一下避免下次再踩同一个坑。5.1 看懂 nvidia-smi 的输出敲下nvidia-smi后正常输出是一个表格上半部分是驱动摘要下半部分是实时 GPU 状态。重点看三个字段Driver Version驱动版本例如 535.86.05这个要和 CUDA 版本的兼容性要求对照。CUDA Version指驱动支持的最高 CUDA 版本不是说系统里已经装了 CUDA。Memory-Usage显存占用跑任务之前先扫一眼确认没有别人占满显存。还可以用nvidia-smi -L列出所有 GPU在多卡机器上检查是不是每张卡都被识别出来了。这一步能帮你发现自己机器明明是双卡结果驱动只识别出一张的尴尬情况。5.2 写一个环境检查脚本每次开机后手动敲一串检查命令太烦了。我把自己常用的检查逻辑写成了一个脚本放在~/check_gpu.sh跑一次就能定位大部分问题#!/bin/bash echo GPU 硬件 lspci | grep -i nvidia || echo [FAIL] 未检测到 NVIDIA 显卡 echo nvidia-smi 路径 which nvidia-smi || echo [FAIL] nvidia-smi 不在 PATH echo 内核模块 lsmod | grep nvidia | head -5 || echo [FAIL] nvidia 模块未加载 echo 设备节点 ls /dev/nvidia* 2/dev/null || echo [FAIL] 无 /dev/nvidia* 设备 echo 驱动版本与内核 echo 内核版本: $(uname -r) cat /proc/driver/nvidia/version 2/dev/null || echo [FAIL] 驱动版本信息不可读把这个脚本和开机自启绑定或者干脆养成跑一次的习惯能在问题刚冒头时就发现而不是等正式跑训练时才被打断。5.3 我自己的几个使用习惯分享给你作参考踩过这么多坑之后我给自己定了几条规矩第一能用发行版仓库装的就不去官网下载 .run 文件。apt/dnf 天然解决了依赖、DKMS、卸载、升级等问题灵活性牺牲一点稳定性提升一大截。非要装特定版本时优先添加官方 NVIDIA 的 apt 仓库而不是下载 .run。第二不轻易手动改系统级 PATH。多版本 CUDA 的需求尽量用update-alternatives或容器来隔离而不是在.bashrc里反复 export。第三每次内核升级后都主动检查一次。升级完内核顺手跑一遍上面的脚本十秒钟的事能避免之后所有“突然跑不起来”的玄学问题。说句实在话nvidia-smi 报 not found 这件事本身很小但它映射出来的系统状态问题很值得认真对待。驱动、模块、路径、容器这四个层面以后你排查任何 GPU 环境问题时都会用到。按照这篇文章的顺序来先判断再动手别盲目的重装基本一次就能解决。
阅读完成 · 觉得有帮助？
