nvidia-smi 失败时，先区分设备发现、模块加载和用户库，避免直接重装全部环境。
内核版本、驱动模块与用户态库构成组合；残留包状态和启动配置可能不一致。PCI 可见不表示驱动完成绑定。
一、问题的范围与前提
规格、安装与实际工作条件需要分别核对。接口外形相同不证明电气和数据能力相同，标称性能也不代表目标工况。测量基准、单位和容差应明确，再通过受控对照定位问题。
二、技术分析与方案取舍
GPU 硬件枚举、内核模块加载和用户空间库分别取证。lspci 能看到设备但 nvidia-smi 失败，说明至少还有驱动链需要核对。检查当前内核、模块版本与加载日志，再比较已安装库，避免在多个版本残留时盲目重装。DKMS 编译成功也不保证当前启动内核加载了它；模块签名或启动配置可能形成另一条件。
重启后用实际 CUDA 运算验证，再测试目标容器。卸载前记录已有包和可恢复版本，不能通过删除所有显卡组件掩盖最初原因。服务器上其它工作负载的停止范围需要匹配实际故障。
从允许范围内的只读或低风险验证开始，一次改变一个条件，保留型号规格与必要版本。供电、线材、机械配合和软件配置分开观察。涉及电气维修或设备动作时，按原厂说明与专业操作边界实施，公开文章不复制未核验接线。
三、实现与排查的顺序
- 记录内核和 PCI。
- 检查模块状态。
- 核对安装组合。
- 重启后验证目标程序。
按这个顺序保留中间结果，可以区分输入条件、处理过程和最终输出。前一阶段的条件不成立时，先解释对应错误，再继续后面的试验；单次返回成功不足以覆盖整条链路。
最小示例
1
2
3
4
5
uname -r
lspci -nn -d 10de:
lsmod | rg "^nvidia"
modinfo nvidia
nvidia-smi
示例依赖 Linux 的 lspci、modinfo 与 NVIDIA 工具。先分别核对枚举、内核模块和用户库；rg 不存在时可用 grep。没有模块信息时继续查看当前内核日志，不直接推断硬件损坏。
四、验证和结果解释
交叉测试使用已知可用部件和独立参考工具，结果记录输入条件、观察与排除范围。单个错误码只提供方向，不能证明唯一故障件。工程尺寸和屏幕显示也要分别核验，漂亮模型不等于实物可以装配。
| 需要验证的结果 | 保留的对照 | 不能由此推出的结论 |
|---|---|---|
| 版本对应 | 固定输入与配置、对应输出 | 一次成功代表所有条件成功 |
| 设备可访问 | 中断前后状态与错误阶段 | 没有报错代表结果正确 |
| 应用实际模式运行 | 恢复后的同条件复测 | 临时恢复代表根因已经消失 |
检查重启、重插、重复装配与允许工况变化。小步迭代保留对照，避免同时更换多个变量后无法判断原因。目标精度和实际误差分别表达，探索样件、概念演示和已验收设备不使用同一完成口径。
五、适用边界与结论
不以安装命令退出码代替运行检查，公开日志去除主机与设备身份。
这条路径把“记录内核和 PCI”与“重启后验证目标程序”连在一起，中间保留可复查的条件。实施时优先确认“版本对应”，再检查“应用实际模式运行”；两者都满足，才能在当前样本与配置范围内评价方案。设备、数据或软件版本改变以后，相关假设需要重新验证。
