多卡训练遇CUDA error 802？从驱动到PCIe的排查与修复全攻略

多卡机器上跑训练跑得好好的，某天突然一个CUDA error: 802拍在脸上，很多人的第一反应是代码写错了。其实 802 这个错误码（CUDA_ERROR_SYSTEM_NOT_READY）和代码的关系往往不大，它说的是 CUDA 运行时的底层依赖——驱动、GPU 设备、驱动与内核模块之间的通信出了问题。尤其多卡机器，情况比单卡复杂得多，我今天就把自己在多台多卡服务器上排查这个错误的完整过程、原因分析、修复手段一次讲清楚，希望能帮你少走些弯路。

这个错误在单卡机器上偶尔也会出现，但多卡机器上的触发频率和排查难度会明显高一个档次。它不挑显卡品牌，也不挑 CUDA 版本，无论是 3090、4090、A100 还是 V100 的机器，我都遇到过。这篇文章会把 802 错误的核心原理、排查步骤、多卡专属坑位以及修复工具全部梳理出来，适合正在被这个错误折磨的深度学习从业者、运维同学，也适合想提前了解这类故障处理思路的开发者。

1. 先搞清楚这个错误到底在说什么

1.1 802错误的本质：CUDA运行时与驱动失联

CUDA_ERROR_SYSTEM_NOT_READY直译过来是"系统未就绪"。CUDA 的运行时库（libcudart）在调用 GPU 设备时，需要经过一套完整的下发链条：你的程序 -> CUDA Driver API -> NVIDIA 内核驱动模块（nvidia.ko、nvidia_uvm.ko） -> 显卡硬件。这个链条上任何一个环节失灵，最终表现都可能是 802。

我在实际排查中发现，802 错误有一个非常典型的时间点：不是程序启动时立刻报，而往往是跑了一段时间之后才突然中断，然后后续所有 CUDA 调用全部失败。这很关键。如果程序一启动就报 802，大概率是驱动加载有问题；如果跑着跑着才报，那多半是运行过程中某个节点把设备"踢出去"了。

从底层机制来看，CUDA Runtime API 在每次调用cudaMemcpy、cudaLaunchKernel、cudaDeviceSynchronize等操作时，要先向 driver 查询设备状态。如果 driver 返回设备不可用，运行时就会把这个状态映射成具体的错误码。802 正是这种映射的产物，但它没有单一根因，更像是一个"综合故障信号"。

需要区分的是，802 和常见的 719（CUDA_ERROR_DEVICE_UNAVAILABLE）、999（CUDA_ERROR_UNKNOWN）不一样。719 通常表示设备存在但当前被占用或不可用，999 是未知内部错误，而 802 明确指向"设备还插在 PCIe 槽位上，但系统层面已经无法访问它了"。诊断思路上，802 需要优先排查驱动内核模块状态、NVML 是否还能枚举到设备、以及操作系统是否已经将设备从 PCI 总线上摘除。

1.2 为什么多卡机器上更容易触发

多卡机器的 802 触发概率比单卡高很多，这不是玄学，有明确的物理和软件层面的原因。

第一，功耗和供电。多块 GPU 满载运行时，整机功耗经常冲到 1500W 以上，如果电源余量不足或供电线路老化，瞬时掉压会导致某块卡直接掉线。掉线之后，驱动层面看到的就是"设备不见了"。

第二，PCIe 链路质量。多卡通常需要插在多个 PCIe 插槽上，配合拆分支架（如 PCIe Switch、NVLink 桥接等），链路拓扑比单卡复杂。任何一条链路的信号质量问题，都可能让系统在运行中触发 PCIe AER（Advanced Error Reporting），进而把设备标记为不可用。

第三，散热和温度。多卡机箱内部风道设计不好，相邻卡之间的温差可能超过 15 度，温度超过阈值后 GPU 会触发热保护，但有时保护机制并不能让设备优雅降级，而是直接"假死"。

第四，软件层面的资源竞争。多卡程序如果用 NCCL 做集合通信，频繁的 kernel launch 和显存分配会让nvidia-uvm模块承受很大压力，uvm 模块一旦出现锁异常或 DMA 映射失败，也可能诱发设备的不可用状态。

所以，排查多卡机器上的 802，不能只盯着驱动，必须把硬件健康、电源、散热、PCIe 链路、驱动模块整体过一遍。下面我会按排查的先后顺序给出可落地的操作步骤。

2. 收到802前的系统体检：第一轮排查

2.1 先看nvidia-smi是否还活着

遇到 802 之后，第一件事不是重装 CUDA，而是先跑一个命令：

nvidia-smi

这个命令能直接反映 NVML（NVIDIA Management Library）和内核驱动的通信状态。我在排查时遇到过几种典型的输出：

• 正常输出：能看到每张卡的型号、温度、显存占用、驱动版本。
• No devices were found：NVML 完全枚举不到 GPU，这说明内核驱动加载失败，或设备已经从 PCIe 总线上消失。
• Failed to initialize NVML: Driver/library version mismatch：驱动和 NVML 库版本对不上。
• 卡在被枚举到，但其中一张卡显示ERR!或温度、功耗字段是N/A。

如果nvidia-smi本身就报错，那几乎可以断定 802 的根因在驱动层或硬件层，和 CUDA 版本无关。这时候不要浪费时间在改代码上。

紧接着再跑一条：

nvidia-smi -L

这条命令会列出所有 GPU 的 UUID。如果某张卡在列表中缺失，那么就是这张卡掉了。在多卡机器上，802 错误通常会带设备序号，比如CUDA error: 802 at device 3，这个序号和nvidia-smi -L的枚举顺序是能对上的（前提是没有设置CUDA_VISIBLE_DEVICES做重映射）。

我建议大家把这些输出重定向到文件里留档：

nvidia-smi -L > gpu_list.txt 2>&1 nvidia-smi > nvidia_smi_status.txt 2>&1

为什么建议留档？因为 802 经常是间歇性的，第一次nvidia-smi可能正常，过几分钟就报错了。留档可以对比不同时间点设备的枚举状态，定位是否同一张卡反复掉线。

2.2 查dmesg和系统日志里的NVRM报错

如果nvidia-smi显示设备缺失或异常，下一步就要看内核日志。Linux 下直接查 dmesg：

dmesg -T | grep -i -E "nvrm|nvidia|pcie|aer|timeout" | tail -100

-T参数会把时间戳转成可读格式。我在多台机器上见过的高频报错包括：

NVRM: GPU at 0000:3b:00.0 has fallen off the bus NVRM: GPU 0000:3b:00.0 is already on the bus NVRM: Xid (PCI:3b:00): 79, GPU has fallen off the bus nvidia-nvlink: Unhandled error interrupt

其中Xid 79是显卡"掉总线"的典型标志。出现这行日志，基本就说明系统层面的 PCIe 通信已经中断。还要留意有没有NVRM: failed to copy user data、NVRM: os_schedule这类伴随日志，它们能帮你判断是通信问题还是驱动内存管理问题。

除了 dmesg，还要看系统日志：

journalctl -k --since "1 hour ago" | grep -i -E "nvrm|nvidia|pcie|aer"

有些发行版把内核日志统一交给 journald 管理，dmesg 里未必能翻到全部历史。两条命令配合使用，能看到从 802 发生时刻往前推的系统状态变化。

2.3 驱动版本与CUDA版本的匹配检查

确认内核驱动模块状态后，再看版本匹配。这一步容易被人忽略，在多卡机器上尤其容易踩坑——因为很多时候服务器是多人共用的，今天这个人装了个新 CUDA，明天那个人升级了驱动，环境早就乱了。

检查当前加载的驱动版本：

cat /proc/driver/nvidia/version

检查编译驱动时的内核版本和当前内核是否一致：

modinfo nvidia | grep ^version uname -r

驱动版本和 CUDA 版本的兼容矩阵，NVIDIA 官方文档里有，但现场排查时更快的做法是直接跑一个测试程序，用cudaGetDeviceProperties拿 CUDA 运行时版本和驱动版本：

nvidia-smi | head -20

nvidia-smi右上角会显示CUDA Version，这个值是当前驱动支持的最高 CUDA 版本，不是已安装的 CUDA 版本。如果你编译程序用的 CUDA 版本比驱动支持的版本高，虽然大部分情况下能跑，但在某些边界操作上会出现异常。我见过不止一次因为驱动太老、而 CUDA toolkit 太新导致 802 的案例，虽然 802 的直接触发原因是驱动崩溃，但版本不一致是导火索。

这里我一般建议：多卡生产环境，驱动版本和 CUDA 版本不要追新，选稳定版本组合。比如 A100 机器我常用 470.xx 或 525.xx 驱动配 CUDA 11.4 或 12.0，4090 这类新卡则用 535.xx 或更新的驱动。版本选择不能只看"能用"，还要看显存分配、NCCL 通信是否稳定。

3. 针对性的修复流程与操作实录

3.1 场景一：驱动已被系统更新/升级破坏

这个场景是最常见也最好修的。Linux 系统在自动更新内核后，NVIDIA 驱动模块需要重新编译安装，如果没做这步，驱动模块和当前内核不匹配，整个nvidia模块就是加载不进去的。

复现路径通常是：

1. 系统自动更新，内核版本从 5.15.0-78 变成了 5.15.0-86。
2. 原来的 NVIDIA 驱动是通过 runfile 安装的，对应的.ko文件还编译在旧内核路径下。
3. 重启后，新内核加载不到 nvidia.ko，或者加载的是旧内核的模块导致签名校验失败。
4. 应用调用 CUDA，直接报 802。

修复步骤并不复杂，关键是别乱。我先确认模块是否能加载：

sudo modprobe nvidia lsmod | grep nvidia

如果没有任何输出，就说明模块没加载成功。接下来看错误：

sudo dmesg -T | grep -i nvidia | tail -30

常见错误是Unknown symbol in module或Invalid module format。这类错误意味着模块版本与当前内核不兼容，需要重新编译安装驱动。

推荐做法是彻底卸载旧驱动后安装当前内核对应的版本。卸载命令取决于当初的安装方式。runfile 方式安装的，找到安装包后执行：

sudo ./NVIDIA-Linux-x86_64-535.129.03.run --uninstall

apt 或 dnf 安装的就用对应包管理器卸载。卸载完成后安装匹配的驱动：

chmod +x NVIDIA-Linux-x86_64-535.129.03.run sudo ./NVIDIA-Linux-x86_64-535.129.03.run --no-cc-version-check

--no-cc-version-check是跳过 gcc 版本检查，因为在某些新系统上 gcc 版本高于驱动支持范围，不加这个参数会安装失败。安装完必须重启，重启后才能保证内核模块加载路径正确。

注意：不要在驱动加载失败的情况下先去重装 CUDA toolkit，那是本末倒置。CUDA 只是一个用户态库，驱动才是和硬件打交道的核心，驱动起不来，CUDA 装多少遍都没用。

3.2 场景二：多卡P2P通信导致的链路不稳定

第二个高频场景是 P2P（Peer-to-Peer）通信导致的设备失联。NCCL 在多卡训练时需要用到 P2P 传输，而 P2P 依赖 PCIe BAR 映射和 NVLink。如果系统在 P2P 初始化过程中出现 DMA 映射失败，可能导致设备状态异常。

从这个角度来说，排查 802 时可以临时关闭 P2P 试试。NCCL 提供了环境变量控制：

export NCCL_P2P_DISABLE=1

不同 NCCL 版本的变量名略有差异，新版还有NCCL_P2P_LEVEL=LOC这种更细粒度的控制。临时禁用 P2P 后重新跑训练，如果不报 802 了，问题就指向 P2P 链路。

但注意，禁用 P2P 会显著降低多卡通信效率，训练速度可能慢 30% 以上。所以这只是定位手段，不是长期方案。真正解决 P2P 链路问题要从硬件层面入手：

• 检查 NVLink 桥接器是否安装牢固。我见过有机器 NVLink 桥松了，平时跑单卡没问题，一上多卡通信就报错。
• 检查 PCIe 插槽的带宽配置。有些主板在插满多卡时会自动降速到 PCIe 3.0 x8，这种降速会让某些对带宽敏感的操作超时。
• 更新主板 BIOS 到最新版本。多卡机器的 PCIe 拓扑由 BIOS 初始化，老版本 BIOS 在 4 卡以上拓扑上常有不稳定问题。

另外，CUDA_VISIBLE_DEVICES的重映射也可能影响 P2P。假设物理卡的 P2P 拓扑不是完全互联的（比如卡 0 和卡 3 不在同一个 PCIe Switch 下），而程序里把它们设置为可见设备 0 和 1，CUDA 会尝试建立 P2P 连接，失败时可能报 802。排查时可以用nvidia-smi topo -m查看拓扑图：

nvidia-smi topo -m

输出类似：

GPU0 GPU1 GPU2 GPU3 GPU0 X PIX PHB SYS GPU1 PIX X SYS SYS GPU2 PHB SYS X PIX GPU3 SYS SYS PIX X

PIX表示在同一 PCIe Switch 下，PHB表示同一 CPU 根节点，SYS表示跨 CPU。如果某两张卡的 P2P 是SYS级别，它们之间的直接 P2P 传输往往走 QPI/UPI 链路，速度慢且容易出问题。理解这张拓扑图，对定位多卡通信问题非常有帮助。

3.3 场景三：ECC与时钟异常触发的不可恢复错误

在数据中心显卡（A100、V100、A800 等）上，ECC 显存的错误如果积累到一定程度，会触发不可恢复错误（UE），GPU 会自动进入降级状态或直接不可用。这种状态下 CUDA 调用报 802，驱动日志里通常能看到Xid 48（ECC 错误）相关的记录。

诊断方法：

nvidia-smi -q -d ECC

查看每张卡的 ECC 错误计数。重点关注Aggregate Uncorrectable SRAM Errors和Aggregate Uncorrectable DRAM Errors这两项，如果数值在持续增长，说明硬件可能有问题。

对于 ECC 错误，我的处理建议是：

1. 先清理错误计数，确认是否是历史残留：

sudo nvidia-smi --ecc-config=0

2. 如果清理后一段时间内错误计数又快速增长，建议联系厂商进行硬件检测。ECC 错误如果每次都落在固定物理位置，说明显存颗粒可能故障。

此外，还可以检查 GPU 时钟是否异常。某些情况下，因为超频或 PLL 配置异常，GPU 会出现时钟错误。查看当前时钟：

nvidia-smi -q -d CLOCK

如果发现 GPU 的 SM 时钟或显存时钟异常（比如远低于默认值），尝试重置时钟：

sudo nvidia-smi -lgc 0 sudo nvidia-smi -rmc 0

这两条命令把 GPU 和显存时钟恢复为默认策略。在数据中心卡上，也可以用nvidia-smi -q -d SUPPORTED_CLOCKS查询支持的时钟范围，然后手动指定一个保守的值来跑测试。

3.4 场景四：PCIe链路与Resizable BAR问题

第四个高频场景是 PCIe 链路问题。多卡机器在长时间高负载运行后，PCIe 链路可能因为信号完整性问题出现降速或链路抖动，严重时会直接把设备摘除。

诊断链路状态：

sudo lspci -vvv -s 3b:00.0 | grep -i -E "LnkSta|LnkCap|DevSta"

LnkSta（Link Status）显示当前链路速度和宽度，比如5GT/s x16。如果发现链路宽度从 x16 掉到 x8 或更窄，说明链路不稳定。

此时重新探测 PCIe 设备可能恢复：

echo 1 > /sys/bus/pci/devices/0000:3b:00.0/remove sleep 3 echo 1 > /sys/bus/pci/rescan

但这只是临时恢复手段，不是长久之计。真正解决要从硬件层面排查：

• 清理 PCIe 插槽和显卡金手指的氧化层。
• 检查供电线缆是否插紧，特别是 PCIe 辅助供电线。
• 检查主板 BIOS 中 PCIe 链路速度设置，必要时降为 PCIe 3.0 测试稳定性。

另外一个经常被忽略的点是 Resizable BAR（可调整 BAR 大小）。新版驱动默认开启了 Resizable BAR，如果主板 BIOS 中该功能配置不正确，可能导致 GPU BAR 映射异常。排查方式：

sudo nvidia-bug-report.sh

然后搜索生成的nvidia-bug-report.log.gz中的BAR1信息。如果 BAR1 地址或大小异常，可以在 BIOS 中关闭 Resizable BAR 选项再测试。实测下来，有些主板开启 Resizable BAR 后多卡系统会出现偶发的 802，关闭后问题消失。这类问题通常出在 CPU 直连 PCIe 根端口和 PCIe Switch 混合拓扑的机器上。

4. 多卡机器的特殊坑位：远超单卡的麻烦

4.1 卡间拓扑与P2P互连的稳定性

多卡机器上跑分布式训练，NCCL 的通信路径会直接影响设备稳定性。我遇到过一台 4 卡 A100 机器，只要用NCCL_P2P_LEVEL=PXB就会在训练中期报 802，改用NCCL_P2P_LEVEL=LOC就完全正常。后来发现，这台机器虽然四张卡都在同一个 NUMA 节点，但实际 PCIe Switch 拓扑并不支持全互联。

这里的排查思路是：先跑一下 NCCL 自带的连通性测试，定位是哪两张卡的链路有问题：

cd /usr/local/nccl-tests ./build/all_reduce_perf -b 128M -e 128M -f 2 -g 4

如果报错或超时，再用cudaDeviceCanAccessPeer写一个小测试程序，逐对检查 P2P 能力：

#include <cstdio> #include <cuda_runtime.h> int main() { int deviceCount; cudaGetDeviceCount(&deviceCount); for (int i = 0; i < deviceCount; ++i) { for (int j = 0; j < deviceCount; ++j) { int canAccess = 0; cudaDeviceCanAccessPeer(&canAccess, i, j); printf("Device %d -> Device %d: %s\n", i, j, canAccess ? "P2P OK" : "P2P NO"); } } return 0; }

编译运行：

nvcc -o peer_test peer_test.cu ./peer_test

输出结果结合nvidia-smi topo -m的拓扑图，能非常清晰地看出哪些卡之间有物理链路限制。通过环境变量限制 NCCL 的 P2P 级别，是解决此类问题最快速的手段。

实战心得：很多多卡机器的 802 并不是"硬件坏了"，而是 NCCL 在初始化 P2P 时触发了某个设备驱动状态异常，导致整台机器所有卡全部失联。这时候杀进程、清显存都没有用，只能重置 GPU。

4.2 MIG模式切换导致的状态残留

如果你用 A100 或 A800 这类支持 MIG（Multi-Instance GPU）的卡，MIG 模式的切换也是 802 的高发温床。MIG 模式下，一张物理卡被切分成多个 GPU 实例，每个实例有独立的内存和计算单元。但 MIG 切换时，如果某个实例还被进程占用，或者实例状态没被正确清理，物理卡会进入一种半初始化状态。

处理方式很直接，先停掉所有占用 GPU 的进程：

nvidia-smi --query-compute-apps=pid,used_memory --format=csv sudo kill -9 <pid>

然后禁用 MIG 模式：

sudo nvidia-smi -mig 0

强制重置 GPU：

sudo nvidia-smi --gpu-reset

注意，--gpu-reset在有些驱动版本上对 MIG 模式支持的卡无效，需要先切回非 MIG 模式再重置。如果以上操作都无效，那只能重启机器。MIG 模式切换引发的问题，在重启后通常会自愈。

4.3 多卡程序里显存分配导致的隐性失联

还有一种情况，不是驱动崩溃，而是程序自身把多卡机器"玩坏"了。CUDA 在调用cudaMalloc失败后，如果没有正确处理错误，继续往下执行，整个 context 会进入不可恢复状态。在这种状态下，后续所有 CUDA 调用都可能返回 802。

我见过有同事在代码里这么写：

cudaMalloc(&d_ptr, size); // 没有检查返回值 kernel<<<grid, block>>>(d_ptr); cudaDeviceSynchronize();

如果cudaMalloc返回的其实是一个错误码（比如cudaErrorMemoryAllocation），而代码没有检查，后续 kernel launch 和同步操作就会基于一个无效的指针执行，最终驱动报错、整个设备状态异常。在多卡训练中，显存碎片化问题会被放大，所以显存分配失败的几率也更高。

这类问题的解法是代码规范层面的：

• 所有 CUDA Runtime API 调用都要检查返回值。
• cudaDeviceSynchronize之后要单独检查错误。
• 用cudaMemGetInfo在分配前查看剩余显存，提前规避分配失败。

更有效的做法是给 CUDA 调用封装一个宏：

#define CUDA_CHECK(call) \ do { \ cudaError_t err = call; \ if (err != cudaSuccess) { \ fprintf(stderr, "CUDA error at %s:%d code=%d(%s)\n", \ __FILE__, __LINE__, err, cudaGetErrorString(err)); \ exit(EXIT_FAILURE); \ } \ } while (0)

这样出错时能立刻看到是哪一行代码触发的，而不是等驱动崩了才去翻日志。我强烈建议所有多卡训练代码都加上这样的检查。

5. 常见问题速查表与避坑清单

5.1 常见问题速查表

下面这个表，是我在多台机器上排查 802 的实践经验汇总。遇到问题时，可以按这个表快速定位方向。

现象	可能原因	优先排查手段	快速修复
nvidia-smi报 Driver/library version mismatch	驱动更新不完整或系统自动更新破坏了模块	modinfo nvidia+uname -r	重装对应内核版本的驱动
nvidia-smi报 No devices found	内核模块加载失败或设备掉总线	dmesg查 NVRM/Xid 日志	modprobe nvidia，必要时重启
训练中途报 802，nvidia-smi能看到卡	P2P/NVLink 通信异常	nvidia-smi topo -m+ NCCL 测试	设置NCCL_P2P_DISABLE=1验证
某张卡温度/功耗显示 N/A	设备进入保护或掉电	检查散热和供电	关机后重新插拔供电线
多卡通信时报 Xid 79	GPU 掉总线，PCIe 链路不稳	lspci -vvv看链路状态	重新插拔 PCIe 设备
ECC 错误计数持续增长	显存颗粒损坏	nvidia-smi -q -d ECC	清零后观察增长趋势
MIG 模式下卡状态异常	MIG 状态残留	nvidia-smi -mig 0	重启机器

5.2 我在多卡机器上踩过的坑与经验总结

第一个常犯的错误：一上来就重装驱动。802 的根因可能只是电源供电不稳，重装驱动毫无作用，反而浪费时间。我建议在重装驱动之前，先花 10 分钟做上面说的体检流程，至少把nvidia-smi的输出、dmesg的 NVRM 日志、nvidia-smi topo -m的拓扑图截下来，这些信息在后续排查时非常有用。

第二个容易忽略的点：多卡机器上的 Xid 日志不只是记录在 dmesg 里。如果你装了 NVIDIA 的 data center GPU manager（DCGM），它会把错误事件记录到/var/log/dcgm/下。另外，有些容器环境会把宿主机的日志屏蔽，你需要在宿主机上查看，而不是在容器里查。这一点在做容器化部署时尤其容易坑人。

第三个经验：在服务重启之前，先把所有 CUDA 进程杀干净。多卡机器上经常有多个用户同时跑任务，某个用户的任务占着显存，你重启驱动是不行的，必须先 kill 所有相关进程。查占用进程用：

fuser -v /dev/nvidia*

这条命令会列出所有打开 NVIDIA 设备文件的进程，然后按 PID 逐个处理。但要注意，多人共用机器时，不要贸然 kill 别人的进程，先沟通确认。

第四个经验，也是最想强调的：做好规律的健康检查。多卡机器不是装好就能一直稳定跑的。我建议每隔一段时间就手动或定时跑一次：

nvidia-smi --query-gpu=index,utilization.gpu,memory.used,temperature.gpu,power.draw --format=csv

把输出存到日志文件里，观察趋势。如果某张卡的功耗、温度、利用率明显异常，早点处理，别等 802 出来了才去抢救。

5.3 最后的兜底方案：驱动重装与系统重启

如果上面所有排查手段都没能解决问题，那就只能上兜底方案了。我个人的处理顺序是：

1. 先reboot。多卡机器的 802 有很多是运行中瞬时故障引发的，重启能清掉所有残留状态。实测下来，大约三成的 802 重启就好，不需要额外操作。
2. 重启后如果仍然复现 802，再做驱动完整重装。卸载干净后，安装与内核匹配的驱动版本。
3. 驱动重装后仍然有问题，这时候基本可以判定是硬件层面的问题了，需要逐卡排查。关掉机器，把卡从原来的 PCIe 插槽换到另一个插槽，或者在另一台机器上测试这张卡。

兜底方案不只是"最后手段"，也是排除法的一部分。我记得第一次处理 802 时，就是依赖重启和换插槽，才定位到一张 RTX 3090 的金手指氧化导致的问题。换了一个插槽后，整整一个月没有复发。

5.4 关于CUDA版本和驱动的长期稳定组合

最后总结一下我自己的多卡环境稳定组合方案。目前主力生产环境用的是：

• Ubuntu 22.04 LTS，内核 5.15.0-91
• 驱动 535.183.06 或 525.147.05
• CUDA 12.2（配合用户态的 PyTorch 2.3 等）

这套组合在 4090、A100、L40S 上都验证过，稳定性很好。如果你用的是 A100 且对代码兼容性要求高，CUDA 11.8 + 驱动 525.147.05 也是稳妥的选择。

另外一个很多人不知道的做法：锁定内核版本，禁止自动更新。多卡服务器最怕的就是系统自动更新内核，一旦更新，驱动模块大概率失效。Ubuntu 下可以用apt-mark hold linux-image-...锁定当前内核版本，CentOS/RHEL 下则在/etc/yum.conf里加上exclude=kernel*。这一步可以提前避免非常多的麻烦。

排查 802 的过程本质上是一个依赖链的检查过程，从硬件供电、散热、PCIe 链路，到内核模块、驱动版本、CUDA 运行时，再到应用代码，一层一层排除，多数问题都能找到明确的根因。我个人最大的体会是：不要一开始就怀疑 CUDA 版本，也不要一上来就重装驱动。先看清楚错误发生时系统的真实状态，再动手操作，效率会高很多。每台多卡机器的硬件拓扑、供电条件、使用场景各不相同，别人的解法未必直接适用，但排查思路是相通的。希望这篇文章能帮你快速找到问题所在，把时间省下来真正用在训练和调参上。