如何用nvidia-smi验证美国GPU服务器的显卡识别与驱动状态

“nvidia-smi 能显示表格，就说明显卡和驱动都正常”这句话只在有限条件下成立。它至少证明当前用户空间工具能够通过 NVML 与 NVIDIA 驱动通信，并在执行命令的这一时刻枚举到部分或全部 GPU；但它不能单独证明显卡数量完整、驱动与业务框架兼容，也不能排除历史硬件错误。

验证美国GPU服务器时，建议依次检查基础输出、GPU 清单、结构化字段和内核日志。只有当 nvidia-smi 正常退出、GPU 数量与交付配置一致、型号及 UUID 可读取、驱动版本明确，并且日志中没有未处理的设备丢失或持续性 Xid 错误时，才能认为“显卡已识别且驱动基础状态正常”。

nvidia-smi 实际验证了哪几层状态

GPU 能被业务使用，通常涉及三个层次：

1. PCIe 硬件层：操作系统是否能看到显卡对应的 PCIe 设备。
2. 内核驱动层：NVIDIA 内核模块是否加载并绑定到设备。
3. 用户空间管理层：nvidia-smi 是否能通过 NVML 与内核驱动通信。

因此，lspci 能看到 NVIDIA 设备，不代表驱动已经可用；而 nvidia-smi 能显示设备，则通常说明上述三个层次已经基本连通。但这仍不等同于 CUDA Toolkit、PyTorch、TensorFlow 或其他业务程序已经兼容。

美国GPU服务器的物理位置不会改变这些判断逻辑。需要注意的是，远程服务器可能采用宿主机直通、虚拟 GPU、容器隔离或 MIG 切分，命令应在正确的系统层级执行，看到的 GPU 数量也要与实际分配数量比较，而不是直接与物理服务器中的显卡总数比较。

先确认命令执行环境

以下命令以常见 Linux 服务器为主，均为查询操作，不会修改驱动配置。先确认发行版、内核版本以及 nvidia-smi 所在位置：

cat /etc/os-release
uname -r
command -v nvidia-smi

如果通过 Docker、Kubernetes 或其他容器环境登录，建议先确认当前是在宿主机还是容器内。容器内没有 nvidia-smi，可能只是镜像未包含该工具；容器内只能看到一张卡，也可能是 NVIDIA_VISIBLE_DEVICES 或容器运行参数限制，而不是宿主机漏识别。

对于容器场景，应优先在宿主机执行完整验证，再检查容器的 GPU 分配情况。

第一条命令：确认驱动能否与 GPU 通信

直接运行：

nvidia-smi
rc=$?
printf 'nvidia-smi exit code: %s\n' "$rc"

正常情况下会显示驱动版本、CUDA 兼容版本、GPU 型号、显存占用、温度、功耗状态以及进程列表等信息，并返回退出码 0。

需要重点查看以下字段：

不同 GPU 型号、驱动版本和虚拟化方式支持的字段并不完全相同。个别字段显示 N/A，应先确认该硬件或运行模式是否支持，不能直接判定显卡故障。

用设备清单核对数量、型号和 UUID

基础表格容易漏看多卡服务器中的缺失设备，建议继续执行：

nvidia-smi -L

典型输出会为每张 GPU 显示索引、型号和 UUID。验证时至少核对：

• GPU 数量是否与服务器实际分配配置一致；
• 每个 GPU 索引是否都能正常列出；
• 型号是否符合预期；
• UUID 是否稳定且没有重复；
• 是否启用了 MIG，以及输出中是否包含 MIG 实例。

还可以用结构化查询减少人工看表时的遗漏：

nvidia-smi --query-gpu=index,name,uuid,pci.bus_id,driver_version,memory.total --format=csv,noheader

该命令适合保存为交付记录或在运维脚本中处理。若要统计物理 GPU 数量，应先确认查询命令执行成功，再统计行数：

nvidia-smi --query-gpu=index --format=csv,noheader | wc -l

如果启用了 MIG，物理 GPU 与 MIG 计算实例并不是同一概念。此时不能仅根据 nvidia-smi -L 的总行数判断显卡数量，应区分以 GPU 开头的物理设备和缩进显示的 MIG 实例。

UUID 可用于定位具体设备，但对外提交故障截图或日志时，建议根据内部资产管理要求决定是否脱敏。

怎样才算通过基础验证

一次相对完整的基础验证应同时满足以下条件：

• nvidia-smi 返回退出码 0；
• 顶部能够正常显示 Driver Version；
• 所有预期 GPU 都出现在设备列表中；
• GPU 型号、显存容量和分配配置相符；
• 每张 GPU 都能读取 UUID 和 PCI Bus ID；
• 多卡环境中没有某张卡单独显示 ERR!、未知状态或设备句柄错误；
• 内核日志中没有持续出现的设备掉线、初始化失败或未处理 Xid 错误。

其中，显存占用、GPU 利用率、温度和功耗属于运行状态指标，不宜用一个统一数值作为所有型号的健康阈值。判断异常时应结合具体 GPU 型号、散热设计、空闲或满载状态以及硬件厂商给出的限制。

命令不存在，不等于服务器没有显卡

如果出现以下提示：

nvidia-smi: command not found

它只说明当前 Shell 无法找到命令，常见原因包括：

• NVIDIA 管理工具未安装；
• 驱动只安装了一部分组件；
• 命令目录不在当前用户的 PATH 中；
• 当前位于没有挂载 NVIDIA 工具的容器内；
• 登录的并不是实际分配 GPU 的系统环境。

可以先查询常见位置：

command -v nvidia-smi
ls -l /usr/bin/nvidia-smi /usr/local/bin/nvidia-smi 2>/dev/null

如果在宿主机上确认命令确实不存在，应先核对 Linux 发行版、内核和原有驱动来源，再选择匹配的软件包。不要在不清楚当前驱动版本和安装方式时，直接混用发行版仓库、NVIDIA 官方安装程序和第三方仓库，否则可能造成内核模块与用户空间库版本不一致。

无法与驱动通信时，先区分硬件识别和驱动加载

常见错误为：

NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver.

这类错误说明 nvidia-smi 已经存在，但无法通过 NVML 正常访问驱动。应从较低风险的查询开始，而不是立即重装或重启。

先检查 PCIe 层是否能看到 NVIDIA 设备：

lspci -Dnn | grep -i nvidia

如果系统没有安装 lspci，该命令本身也会报找不到命令，不能因此判断没有 GPU。

• 能够看到 NVIDIA 设备：说明硬件至少已呈现给操作系统，应继续检查驱动模块。
• 完全看不到 NVIDIA 设备：需要检查服务器是否实际分配了 GPU、虚拟化直通是否完成，或者设备是否在宿主机层被屏蔽。虚拟机内部看不到设备时，仅在客户机中重装驱动通常无效。

继续检查内核模块：

lsmod | grep -E '^(nvidia|nouveau)'
cat /proc/driver/nvidia/version 2>/dev/null

若 lspci 能看到显卡，但没有任何 NVIDIA 模块，应检查驱动是否针对当前内核构建成功。对于使用 DKMS 的环境，可在已安装 DKMS 工具时查询：

dkms status
uname -r

如果同时看到 nouveau 和 NVIDIA 相关模块，或者设备实际绑定到了其他驱动，可以根据具体 Bus ID 查询：

lspci -nnk -s 0000:65:00.0

其中 0000:65:00.0 必须替换为服务器实际显示的 PCI Bus ID，不应照抄示例。

Driver/library version mismatch 应如何判断

若输出类似：

Failed to initialize NVML: Driver/library version mismatch

通常表示正在运行的 NVIDIA 内核模块与当前用户空间 NVML 库版本不一致。这种情况常发生在驱动软件包更新后，旧内核模块仍在运行，或者系统中混入了不同来源的驱动文件。

可以对比当前加载的模块版本和磁盘中的模块信息：

cat /proc/driver/nvidia/version
modinfo -F version nvidia 2>/dev/null
ldconfig -p | grep libnvidia-ml.so

如果 /proc/driver/nvidia/version 与 modinfo 显示的版本不一致，往往意味着磁盘上的模块已更新，但当前内核仍加载旧版本。此时不要反复覆盖安装驱动，应先确认：

• 是否刚完成驱动或内核升级；
• 是否有 GPU 计算任务仍在运行；
• 系统使用的是发行版软件包、DKMS 还是 NVIDIA 独立安装程序；
• 是否具备远程控制台和启动失败后的恢复手段。

在完成任务停止、维护窗口确认和远程恢复准备后，重启可能使新模块生效，但它不是所有版本不匹配问题的唯一修复方法。若文件来自多个安装源，应先统一驱动来源，否则重启后仍可能复现。

设备数量不足或单卡异常时查看内核日志

nvidia-smi 能运行，但只显示部分显卡，同样不能视为验证通过。先把识别结果与 PCIe 设备对应起来：

nvidia-smi --query-gpu=index,name,pci.bus_id,uuid --format=csv,noheader
lspci -Dnn | grep -i nvidia

如果 lspci 中的 NVIDIA GPU 数量多于 nvidia-smi，说明部分设备已出现在 PCIe 层，但没有被驱动正常管理。此时应检查本次启动以来的内核日志。

在使用 systemd 的 Linux 系统上：

sudo journalctl -k -b --no-pager | grep -iE 'nvrm|nvidia|xid|fallen off'

在没有 systemd、但允许读取内核缓冲区的系统上：

sudo dmesg -T | grep -iE 'nvrm|nvidia|xid|fallen off'

这些命令只读取日志。部分系统会限制普通用户访问内核日志，因此可能需要 sudo 权限。

需要关注的并不是所有包含 nvidia 的记录，而是反复出现的初始化失败、Xid 错误、设备句柄不可用或 “fallen off the bus”等信息。Xid 是一类错误编号，不同编号对应的原因和处理方式不同，应结合发生时间、GPU UUID、业务负载和对应驱动文档判断，不能看到任意一条历史 Xid 就直接认定显卡损坏。

如果美国GPU服务器使用 UTC，而运维人员按本地时间提交故障，排查日志前还应确认时区：

timedatectl status

日志时间没有对齐时，很容易把旧错误误认为当前故障。

不要把 CUDA Version 当成 CUDA Toolkit 版本

nvidia-smi 顶部显示的 CUDA Version，是当前驱动声明可支持的 CUDA 兼容能力，并不是系统中实际安装的 CUDA Toolkit 版本。

要检查 Toolkit 编译器，可运行：

command -v nvcc
nvcc --version

但即使 nvcc 不存在，也不能说明 GPU 驱动异常。很多深度学习环境使用 Python 包、容器镜像或框架自带的 CUDA 运行库，并不要求宿主机安装 nvcc。

因此应分别判断：

• nvidia-smi 验证驱动与 GPU 的基础通信；
• nvcc --version 验证可见的 CUDA Toolkit 编译器；
• PyTorch、TensorFlow 等框架自己的检测命令验证应用层能否调用 GPU。

这三项不能互相替代。

Windows Server 上的对应检查

如果服务器运行 Windows Server，可以在 PowerShell 中执行：

Get-Command nvidia-smi.exe -ErrorAction SilentlyContinue
nvidia-smi.exe
nvidia-smi.exe -L
nvidia-smi.exe --query-gpu=index,name,uuid,pci.bus_id,driver_version,memory.total --format=csv,noheader

如果命令不在 PATH 中，可以检查常见安装位置，但该路径并非所有驱动版本都相同：

$tool = "$env:ProgramFiles\NVIDIA Corporation\NVSMI\nvidia-smi.exe"
Test-Path $tool
if (Test-Path $tool) {
    & $tool
}

支持 PnpDevice 模块的系统还可以查询显示设备状态：

Get-PnpDevice -Class Display |
    Format-Table Status, FriendlyName, InstanceId -AutoSize

PowerShell 中的判断标准与 Linux 相同：命令存在只是第一步，还要核对设备数量、型号、UUID、驱动版本及错误信息。

修复后应进行两轮复核

完成驱动调整、模块重新加载或计划内重启后，不要只看一次 nvidia-smi 表格。建议重新执行：

nvidia-smi
nvidia-smi -L
nvidia-smi --query-gpu=index,name,uuid,pci.bus_id,driver_version,memory.total --format=csv,noheader

随后再次检查本次启动的内核日志：

sudo journalctl -k -b --no-pager | grep -iE 'nvrm|nvidia|xid|fallen off'

第一轮用于确认启动后的设备枚举和驱动加载，第二轮应在实际业务启动后进行，用来确认 GPU 不会在创建计算上下文或承受负载后掉线。nvidia-smi 通过只能认定驱动基础链路可用；业务能否正常运行，仍需用服务器上真实使用的框架、容器或计算任务完成应用层验证。