一、硬件层疑难杂症：隐蔽性故障排查

硬件问题的核心是 “物理状态异常”，但表现可能被软件层掩盖（如 “驱动崩溃” 实际是硬件接触不良），需结合物理检查和工具验证。

1. GPU 频繁 “掉卡”（随机离线，无规律）

现象：nvidia-smi突然显示某块 GPU 消失，重启后恢复，但几小时 / 几天内再次发生；系统日志（dmesg）可能有PCIe Bus Error或GPU has fallen off the bus。
可能原因：

• PCIe 插槽接触不良（灰尘 / 氧化）或主板 PCIe 控制器故障；
• 供电不稳定（GPU 电源接口松动、电源负载超限、电源线老化）；
• 硬件隐性故障（GPU 核心 / 显存微损坏，高负载时触发离线）。

排查与解决：

1. 物理检查：
   • 断电后拔插 GPU，用橡皮擦清洁金手指；检查 PCIe 插槽是否有异物，主板是否有电容鼓包。
   • 核对 GPU 功耗（如 RTX 4090 需 450W），确保电源额定功率≥总功耗（含 CPU / 其他设备），替换 GPU 供电线（优先原装配线）。
2. 工具验证：
   • 用nvidia-smi -q -d POWER监控实时功耗，是否频繁超过 TDP（如突然飙升到 500W）；
   • 开启 PCIe 错误日志：echo 1 > /sys/module/pcieport/parameters/debug，再发生掉卡时查看dmesg，若有Uncorrectable Error，可能是 PCIe 控制器或插槽故障，尝试更换 PCIe 插槽或主板。
3. 压力测试：用nvidia-smi pmon -s u -d 1监控下，运行cuda_memtest（显存测试）或gpu-burn（满负载烤机）持续 24 小时，若高负载时必掉卡，可能是 GPU 硬件故障，需返修。

2. GPU 温度正常但频繁降频（算力骤降 50% 以上）

现象：GPU 温度仅 60℃（远低于阈值 85℃），但nvidia-smi显示Clocks Throttle Reasons中Power或Thermal被触发，算力（如 FP32 吞吐量）从 100TFLOPS 降至 40TFLOPS。
可能原因：

• 虚假温度检测（温度传感器故障，误报高温触发降频）；
• 电源 “功率限制” 被误设（软件层面锁死功率上限）；
• 硬件老化导致电压调节模块（VRM）效率下降，高负载时供电不足触发降频。

排查与解决：

1. 验证温度真实性：
   • 用红外测温枪直接检测 GPU 核心表面温度（与nvidia-smi显示值对比），若差异≥10℃，可能是传感器故障，需更换 GPU。
2. 检查功率限制：
   • 执行nvidia-smi -q -d POWER | grep "Power Limit"，确认是否被手动限制（如误设为 200W，而 GPU 默认 300W），恢复默认：sudo nvidia-smi -pl 300（需替换为 GPU 默认 TDP）。
3. VRM 健康度检测：
   • 用nvidia-smi -q -d VOLTAGE监控核心电压，高负载时若电压波动≥0.1V（如从 1.05V 骤降到 0.8V），可能是 VRM 老化，需更换 GPU 或电源（若电源输出不稳）。

3. ECC 错误持续增长（但未触发硬件离线）

现象：nvidia-smi -q -d ECC显示Uncorrected Errors或Corrected Errors持续累积（每小时增长几十到几百），系统运行暂时正常，但长期可能导致数据错误。
可能原因：

• 显存硬件故障（轻微损坏，ECC 可纠正但持续出错）；
• 内存控制器电磁干扰（GPU 附近有强电磁设备，如未屏蔽的风扇）；
• 固件版本过低（ECC 校验逻辑有 bug）

排查与解决：

1. 定位故障部件：
   • 用nvidia-smi -i <gpu-id> -q -d ECC确认是 “Device Memory” 还是 “Register File” 错误，前者更可能是显存问题。
   • 运行cuda_memtest --device <gpu-id> --iterations 10，若特定地址持续报错，可判定为显存硬件故障，需更换 GPU。
2. 环境优化：
   • 移除 GPU 附近的强电磁设备（如工业风扇），检查机箱接地是否良好（用万用表测接地电阻，应≤4Ω）。
3. 固件更新：
   • 参考厂商手册更新 GPU 固件（如 NVIDIA 数据中心级 GPU 需用nvfwupd工具），部分老固件的 ECC 校验逻辑存在漏洞，更新后可减少误报。

二、驱动 / 固件层疑难杂症：兼容性与稳定性

驱动和固件是硬件与软件的 “桥梁”，其问题常表现为 “间歇性失效” 或 “版本依赖冲突”，且排查依赖日志深度分析。

1. 驱动加载成功但nvidia-smi报 “Unknown Error”

现象：modprobe nvidia无报错，lsmod | grep nvidia显示模块加载，但nvidia-smi返回Failed to initialize NVML: Unknown Error，重启后可能自愈。
可能原因：

• 驱动与内核版本 “伪兼容”（如内核小版本差异，如 5.4.0-100 与 5.4.0-101）；
• 固件与驱动版本不匹配（如 GPU 固件是 2022 年版本，驱动是 2024 年新版本，存在接口不兼容）；
• 内核安全模块（如 SELinux/AppArmor）阻止驱动访问硬件资源。

排查与解决：

1. 核对版本兼容性：
   • 查 NVIDIA 驱动官网，确认驱动版本支持当前内核（如驱动 550.54.14 支持 Linux 内核 5.4-6.8）；
   • 用uname -r看内核版本，若内核升级后未重装驱动，需重新编译驱动（dkms install nvidia/<version>）。
2. 检查固件匹配性：
   • 运行cat /sys/class/drm/card*/device/firmware_version获取 GPU 固件版本，对比厂商推荐的驱动 - 固件搭配表（如 NVIDIA A100 需固件 94.02.xx 搭配驱动 535+）。
3. 安全模块排查：
   • 临时关闭 SELinux：setenforce 0，若nvidia-smi恢复正常，需在/etc/selinux/config中添加驱动路径到白名单（如/usr/bin/nvidia-smi）

2. 驱动升级后 GPU 性能骤降（算力减半）

现象：从驱动 525 升级到 550 后，相同应用的 GPU 利用率从 90% 降至 40%，耗时翻倍，但nvidia-smi显示无降频。
可能原因：

• 驱动默认启用 “节能模式”（新驱动的 PowerMizer 策略变更）；
• 新驱动对特定 CUDA API 的实现方式调整（如cudaMemcpy优化逻辑变更，与老应用不兼容）；
• 驱动与 GPU 微架构不匹配（如用数据中心驱动跑游戏卡，或反之）。

排查与解决：

1. 调整 PowerMizer 模式：
   • 用nvidia-settings -a [gpu:0]/PowerMizerMode=1（强制高性能模式，需安装 nvidia-settings）；
   • 检查nvidia-smi -q -d CLOCK，确认 “Graphics Clock” 和 “SM Clock” 是否达到标称值。
2. 验证驱动类型：
   • 数据中心 GPU（如 H100）需用 “Data Center Driver”（而非 “Game Ready Driver”），可通过nvidia-smi --query-gpu=driver_type --format=csv查看，若为WDDM（Windows）或Game（Linux），需卸载后安装对应类型驱动。
3. 回滚与对比测试：
   • 回滚到原驱动版本（如 525），若性能恢复，说明是新驱动兼容性问题，可联系厂商提交 bug report，或在应用中添加适配参数（如 CUDA_API_PER_THREAD_DEFAULT_STREAM=1）。

三、软件应用层疑难杂症：资源冲突与逻辑漏洞

软件层问题常与 “应用行为” 强相关，表现为 “特定场景必现”，需结合应用日志和 GPU 监控工具定位。

1. 多进程共享 GPU 时，某进程突然被 “Kill” 但无 OOM 日志

现象：2 个进程共享 1 块 24GB GPU，总显存占用 18GB（未达上限），其中一个进程突然被终止，dmesg无Out of memory，应用日志仅显示 “Signal 9 (SIGKILL)”。
可能原因：

• 进程触发 GPU “页表溢出”（GPU 页表内存不足，而非显存）；
• 应用访问非法 GPU 地址（如越界访问，触发硬件保护机制）；
• 容器环境中cgroup限制了 GPU 资源（如nvidia-container-runtime的隐性限制）。

排查与解决：

1. 监控 GPU 页表：
   • 用nvidia-smi -q -d PAGE_RETIREMENT查看是否有 “Page Retirement”（页表失效）；
   • 对 NVIDIA GPU，页表大小与显存正相关（如 24GB 显存对应约 1GB 页表），多进程创建大量小显存块时可能耗尽页表，可通过export CUDA_DEVICE_MAX_CONNECTIONS=8减少连接数（降低页表占用）。
2. 调试应用行为：
   • 用cuda-gdb调试进程，在崩溃时查看调用栈，是否有cudaMemcpy越界（如size参数错误）；
   • 运行valgrind --tool=memcheck --leak-check=full <app>，检测 CPU 侧内存泄漏是否间接导致 GPU 资源异常。
3. 容器限制检查：
   • 若在 Docker/K8s 中，检查nvidia-smi -c是否有CGroup Limits，或kubectl describe pod <pod-name>查看nvidia.com/gpu.memory是否被误设（如限制为 10GB）。

2. CUDA 程序运行时 “随机卡死”（无日志，GPU 利用率 100%）

现象：程序运行到某一步骤（如矩阵乘法）时突然卡住，nvidia-smi显示 GPU 利用率 100%，但无进度，无法通过kill终止（需kill -9）。
可能原因：

• 线程束（Warp）死锁（如分支发散导致部分线程无限等待）；
• GPU 核心硬件缺陷（特定指令序列触发锁死，概率性发生）；
• 驱动调度 bug（多流并发时，流同步逻辑错误）。

排查与解决：

1. 定位卡死代码段：
   • 用nvprof --profile-from-start off -o profile.nvvp <app>，在卡死前按Ctrl+C生成 Profile，分析是否卡在__global__函数的特定循环。
   • 简化代码，逐步注释模块，定位到最小复现单元（如删除某段分支逻辑后不再卡死，说明是分支发散问题）。
2. 硬件兼容性测试：
   • 在不同型号 GPU 上运行（如从 RTX 3090 换到 A100），若仅某型号卡死，可能是该型号硬件缺陷，需更新固件或规避特定指令（如用__syncwarp()替代手动同步）。
3. 驱动与 CUDA 版本匹配：
   • 确保 CUDA 版本与驱动兼容（如 CUDA 12.1 需驱动≥530.30.02），用nvcc --version和nvidia-smi核对，若版本不匹配，重新安装对应 CUDA Toolkit。

四、虚拟化 / 集群层疑难杂症：资源隔离与调度异常

在虚拟化（如 vGPU）或集群（如 K8s）环境中，问题常涉及 “多层级配置”，需结合虚拟化日志和节点状态排查。

1. K8s 集群中，GPU Pod 调度成功但启动失败，报 “device not found”

现象：K8s 节点有 2 块 GPU，nvidia-smi正常，但 Pod 调度到节点后启动失败，日志显示failed to allocate device: no devices found，kubectl describe node显示 GPU 资源未被占用。
可能原因：

• nvidia-device-plugin未正确注册 GPU（插件崩溃或权限不足）；
• 节点标签与 Pod 亲和性不匹配（如 GPU 型号标签错误）；
• 容器 runtime 不支持 GPU（如用containerd但未配置nvidia-container-runtime）。

排查与解决：

1. 检查 device-plugin 状态：
   • 查看kubectl logs -n kube-system <nvidia-device-plugin-pod>，若有permission denied: /dev/nvidia0，需在插件部署中添加securityContext.privileged: true。
2. 验证资源标签：
   • 节点 GPU 标签（如nvidia.com/gpu.product=H100）需与 Pod 的nodeSelector一致，用kubectl get node <node> -o jsonpath='{.metadata.labels}'核对，若标签缺失，重启 device-plugin 触发重新标签。
3. runtime 配置检查：
   • 对 containerd，检查/etc/containerd/config.toml中是否配置default_runtime_name = "nvidia"，且[plugins."io.containerd.runtime.v1.linux".runtimes.nvidia]指向正确的nvidia-container-runtime路径。

五、通用排查思路与预防措施

1. 工具链依赖：

   • 硬件层：nvidia-smi（基础监控）、cuda_memtest（显存测试）、gpu-burn（压力测试）；
   • 驱动层：dmesg（内核日志）、nvidia-bug-report.sh（生成驱动诊断报告）；
   • 应用层：nvtop（实时监控）、nsys profile（NVIDIA Nsight Systems，全链路分析）；
   • 虚拟化层：nvidia-smi -l 1（持续监控）、kubectl describe（K8s 资源）。

2. 排查原则：

   • 先 “隔离变量”：逐步排除环境（硬件 / 驱动 / 应用），定位到单一变量（如替换 GPU 后问题消失，说明是硬件问题）；
   • 重 “日志联动”：结合系统日志（dmesg）、驱动日志（/var/log/nvidia）、应用日志，寻找时间点吻合的异常信息；
   • 做 “对比测试”：在正常环境与故障环境中对比参数（如驱动版本、GPU 温度、进程占用），差异点往往是根因。

3. 预防措施：

   • 定期维护：每季度清洁 GPU 灰尘、检查硅脂（散热不良的隐性杀手）、更新驱动 / 固件到稳定版本；
   • 压力测试：新部署 GPU 需通过 72 小时满负载测试（gpu-burn -d 259200）；
   • 监控告警：用 Prometheus+Grafana 监控 GPU 指标（温度 / 功耗 / 显存 / ECC 错误），设置阈值告警（如温度≥85℃、ECC 错误 1 小时增长≥100）。