半夜训练任务静悄悄崩掉，第二天过来看日志，满屏CUDA_ERROR_SYSTEM_NOT_READY，错误码 802，恰好又是多卡机器。这种情况我遇到不止一次，而且基本都集中在多卡环境：单卡机器很少出这个错，一上多卡就频繁。最初我也以为是驱动版本问题，重装驱动、换 CUDA 版本折腾了一整周，后来才明白 802 的本质和传统“驱动不匹配”完全是两回事。
这篇文章就围绕CUDA Error Code 802 (CUDA_ERROR_SYSTEM_NOT_READY)在多卡机器上的完整排障过程展开，覆盖底层原因、排查步骤、修复方案，以及在代码层面如何提前拦截这个错误，让训练任务不至于因为一张卡掉线就全盘崩溃。适合正在维护多卡训练服务器、推理服务的同学参考，也适合在 OpenCV 编译 CUDA 或跑 llama_cpp_python 等 GPU 加速场景时碰到 802 的读者收藏。
1. 802报错在多卡机器上的典型现场
1.1 所有程序一夜间突然崩掉的凌晨
先说一个最常见的现场：机器平时跑得好好的，某天凌晨训练任务突然报错退出。翻日志看到的是这样的堆栈：
RuntimeError: CUDA error: system not yet ready CUDA kernel errors might be asynchronously reported at some other API call, so the stack trace below might be incorrect.如果用的是 PyTorch，还会在torch.cuda.device_count()或第一个cudaMemcpy的地方直接炸掉；如果是 OpenCV DNN 模块加载 CUDA 引擎，通常是在cv2.dnn.readNetFromONNX之后的第一次net.forward()报错；如果是自研的 CUDA 程序，最常见的触发点是cudaSetDevice、cudaGetDeviceProperties或第一次cudaMalloc。
关键特征是：不是所有卡都不可用，往往只有其中一张或几张开小差。比如四卡机器，nvidia-smi看到 0 号卡、2 号卡、3 号卡都正常，1 号卡显示ERR!或者干脆不在列表里。但程序如果恰好被调度到了 1 号卡，就会在初始化阶段得到 802。
这个“部分故障”的形态是最误导人的。很多人第一反应是重装驱动，但重装完重启后一切正常，过了几天又崩。真正的问题可能根本不在驱动安装本身，而在于某张卡在运行过程中被驱动标记成了不可用状态，驱动不愿意再把这张卡交给 CUDA 运行时使用。
1.2 802与传统“驱动不匹配”这类错误的差异
排障时我习惯先把手头 CUDA 错误码的语义理清楚，避免南辕北辙。CUDA 运行时 API 的错误码里，经常碰到的是下面这几类：
| 错误 | 含义 | 典型场景 |
|---|---|---|
CUDA_ERROR_NO_DEVICE | 没有可用设备 | 驱动未装好、容器没透传 GPU |
CUDA_ERROR_INVALID_DEVICE | 设备序号非法 | 指定了超过实际数量上限的 device id |
CUDA_ERROR_DRIVER_VERSION_MISMATCH | 驱动版本与 CUDA 运行时不匹配 | 编译程序用的 CUDA 版本比驱动支持的更新 |
CUDA_ERROR_SYSTEM_NOT_READY | 系统尚未就绪 | 设备存在但无法初始化、驱动拒绝响应 CUDA 调用 |
CUDA_ERROR_UNKNOWN | 未知错误 | 异步 kernel 失败，或驱动状态异常 |
802 对应的名称是CUDA_ERROR_SYSTEM_NOT_READY，它的原始语义是“系统尚未准备好”。这个“未准备好”不是说你的程序还没初始化，而是说GPU 设备虽然物理上存在且能被驱动枚举到，但驱动认为它当前不具备执行 CUDA 任务的条件。
这和“驱动版本不匹配”有本质区别。版本不匹配通常在编译期或加载期就稳定报错，和硬件状态无关；802 则是运行时状态问题，可能这次重启后消失，下次开机又出现，具有很强的间歇性。如果只用“重启大法”处理，往往治标不治本。
2. 为什么多卡环境最容易触发802：驱动、设备状态与底层的“健康心跳”
2.1 显卡在驱动眼里其实有“OK/ERR”两种状态
NVIDIA 驱动不是把所有 GPU 一视同仁的。它内部会为每个设备维护一个运行状态位，正常时是 OK，一旦检测到某些硬件错误，就会把状态位翻成 ERR，并停止向 CUDA 上层提供该设备。这很像是服务器集群里的“节点健康检查”——驱动自己扮演了健康检查器的角色，GPU 就是被监控的节点。
当状态位为 ERR 时，cudaGetDeviceCount仍可能返回全部数量，因为这些设备在 PCIe 总线上可以被枚举到；但当你试图cudaSetDevice(i)去访问它时，驱动就会直接返回 802。换句话说，802 是驱动层对你说“这张卡我不接待”。
这也是为什么很多人在单卡机器上从来没碰到过 802：单卡环境里那张卡一坏，最常见的表现是nvidia-smi直接看不到显示设备，或者开机直接进不了桌面，根本轮不到某个用户态程序去访问它。多卡机器则不同，坏一张卡不影响其他卡工作，机器整体继续运行，于是某个使用这张卡的进程就会撞上 802。
2.2 Xid错误与“掉卡”是如何一步步把状态位翻成ERR的
驱动把设备状态翻成 ERR，通常不是因为心情不好，而是收到了硬件层的错误报告。在 Linux 的dmesg或/var/log/syslog里，NVRM 驱动会记录一类叫Xid的错误，这是理解 802 根因的核心线索。
常见的 Xid 错误有几类和 802 直接相关：
- Xid 43 / 45：GPU 停止响应或从总线上“掉卡”，多见于供电不稳定、PCIe 链路问题或显卡过热。
- Xid 63 / 64 / 65：GPU 内部 L2 cache 或显存控制器相关错误，通常指向显存本身损坏或超频过度。
- Xid 79：GPU 掉出 PCIe 总线，驱动无法再与设备通信，在热拔插环境、转接线接触不良时会出现。
- Xid 48：显存 ECC 错误累积到一定程度后驱动主动离线该设备。
每次 Xid 错误发生，驱动都会把对应设备标记为不可用。这里有个容易忽略的细节：Xid 错误不一定当场导致进程崩溃。有时错误先记录在日志里，GPU 继续工作一段时间；直到下一次上下文切换或初始化，驱动才真正把设备踢出可用列表，802 就在这个节点出现。所以排查时要回看 Xid 出现的时间点，而不是只看程序崩溃的时间点。
以我踩过的一次为例：四卡训练服务器，某天 1 号卡报 Xid 64，当晚训练没崩；第二天早上任务重启，1 号卡已变成 ERR 状态，所有指定跑在 1 号卡上的新进程全部 802。这种情况如果只看程序日志，会以为驱动昨天夜里才坏，实际上根因在更早。
2.3 多卡调度本身也在放大802的触发概率
多卡环境之所以更容易暴露 802，还有一个原因是调度逻辑把问题“放大”了。单卡机器上，程序通常默认设备 0，设备坏了初始化直接失败，用户一眼看出问题；多卡机器上，任务可能通过CUDA_VISIBLE_DEVICES指定到某张卡，而指定方式往往是“按物理序号写死”或者“按 PyTorch 默认顺序分配”。只要某张卡中间变 ERR，新任务就会撞上去。
更麻烦的是，有些框架会在初始化时并行探测所有设备（比如读取每个设备的属性来算 NCCL 的拓扑），只要有一张卡状态异常，整个进程都会退出，即便你的任务本来只打算用其中两张正常卡。这也是为什么多卡机器上出现 802 后，往往是“全盘崩溃”而不是“个别任务失败”。
加上多卡机器对 PCIe 链路、供电、散热的要求远高于单卡，这类底层问题在多卡环境中出现的绝对次数更多。所以把 802 理解成“多卡环境特有的驱动保护机制”并不夸张。
3. 定位故障卡的完整排查链路
3.1 第一步：nvidia-smi看全局，先分清“哪张卡还在喘气”
碰到 802 的第一件事不是重装驱动，而是先看nvidia-smi的完整输出。重点观察两部分：设备列表里有没有ERR!标志，以及 GPU 利用率、显存、温度是否正常。
nvidia-smi如果某张卡显示ERR!，说明该设备已被驱动标记为不可用，这就是 802 的直接来源。如果所有卡都显示正常，但程序仍然报 802，则需要用查询命令逐卡检查更多属性：
nvidia-smi --query-gpu=index,uuid,name,clocks.sm,power.draw,temperature.gpu,memory.used --format=csv注意对比每张卡的clocks.sm和power.draw。正常空载时显卡的 SM 时钟会降到很低的频率，功率只有几十瓦；如果某张卡的功率异常高但利用率又为 0，或者温度明显高于其他卡几十度，这张卡很可能处于“半死”状态，虽然还没被驱动标 ERR，但随时可能触发 802。
还有一个隐藏信息：显存大小。如果某张卡的实际显存比标称值小（比如 24G 的卡只显示 20G），而且不是 MIG 模式造成的，那基本可以断定这张卡的部分显存已被驱动隔离，属于硬件早期故障信号。
3.2 第二步：dmesg与NVRM日志里的Xid
nvidia-smi只能看到当前状态，要知道“这张卡为什么变成 ERR”，必须去翻驱动日志。Linux 下最直接的入口是dmesg：
dmesg -T | grep -i -E "xid|nvrm|nvidia" | tail -50或者看系统日志：
grep -i -E "xid|nvrm|nvidia" /var/log/syslog | tail -50在输出里找 Xid 错误行，记录三样东西：Xid 的编号、发生时间、关联的 GPU 序号。例如：
May 26 03:14:22 gpu-server kernel: NVRM: Xid (PCI:0000:03:00): 64, ...把多台机器、多次事故的 Xid 编号列成表，会发现规律很清晰：某种编号反复出现，基本就是同一类原因反复触发。比如 Xid 43/45 对应供电或链路问题，Xid 63/64/65 对应显存或 L2 问题。根据编号可以缩小排查方向，而不是盲目换机器配件。
3.3 第三步：ECC计数器与设备复现实验
专业卡（如 A100、V100、RTX 6000 Ada 等）有 ECC 功能，能统计显存错误次数。用下面的命令可以查询：
nvidia-smi -q -d ECC重点看Volatile Uncorrectable（易失性不可纠正错误）和Aggregate Uncorrectable（累计不可纠正错误）两列。只要“不可纠正 ECC 错误”的速度在增长，就说明显存正在持续出问题，这张卡需要尽快更换或降频使用。
消费卡（比如 4090、4060 Ti）没有 ECC 计数器，这时可以用一个小程序直接探测每张卡的可初始化性。下面这段代码会遍历所有设备，逐个尝试初始化并获取属性，返回 802 的那个设备就是这个故障元凶：
#include <cuda_runtime.h> #include <stdio.h> int main() { int count = 0; cudaError_t err = cudaGetDeviceCount(&count); if (err != cudaSuccess) { printf("cudaGetDeviceCount failed: %s\n", cudaGetErrorString(err)); return 1; } printf("Detected %d devices\n", count); for (int i = 0; i < count; i++) { err = cudaSetDevice(i); if (err != cudaSuccess) { printf("GPU %d: set device failed -> %s\n", i, cudaGetErrorString(err)); continue; } cudaDeviceProp prop; err = cudaGetDeviceProperties(&prop, i); if (err != cudaSuccess) { printf("GPU %d: get properties failed -> %s\n", i, cudaGetErrorString(err)); } else { printf("GPU %d: %s OK (sm_%d%d, %u MB)\n", i, prop.name, prop.major, prop.minor, (unsigned)(prop.totalGlobalMem / (1024 * 1024))); } } return 0; }编译运行：
nvcc -o check_cuda check_cuda.cu ./check_cuda正常机器的输出应该是每张卡都 OK；故障机器的输出会针对某张卡显示system not yet ready。这一步基本就能锁定故障设备。
3.4 第四步：确认是驱动层面的问题还是卡本身的问题
找到故障卡后，还有一个关键分流：是这张卡硬件坏了，还是驱动和它“沟通”出了问题。业内有一个实用的区分方法——把故障卡和一张正常卡对调 PCIe 槽位：
- 故障现象跟着卡走，说明显卡本身有问题；
- 故障现象留在原槽位，说明 PCIe 插槽、供电线或主板有问题；
- 两张卡换位后都正常了，大概率是原来的槽位接触不良或供电不足。
没有条件拆机的话，也可以用nvidia-smi -r尝试重置指定 GPU，观察是否恢复：
sudo nvidia-smi -r -i 3-r会触发 GPU 的 reset 操作，适用于某些 ECC 或上下文状态异常。但注意：不是所有卡都支持这个功能，消费级显卡通常不支持；另外服务器里如果这张卡正被其他进程占用（即使进程已经僵死），reset 也会失败，需要先清理进程。
4. 实测有效的三种修复方案与验证方法
4.1 软复位：重载驱动、PCI重新枚举与nvidia-smi -r
对于第一次出现 802 的机器，我建议按“最小干预”原则逐级处理，先软后硬。
第一级是重载 NVIDIA 驱动模块。很多由 Xid 43/45 引起的 802，本质是驱动丢失了和硬件之间的同步状态，重载驱动可以重建这个状态：
sudo rmmod nvidia_drm nvidia_modeset nvidia_uvm nvidia sudo modprobe nvidia_drm nvidia_modeset nvidia_uvm nvidia如果rmmod报“Module in use”，说明有进程还在占用 GPU，需要先停掉相关服务或进程。如果只是想在 GPU 层彻底重启，也可以重启nvidia-persistenced服务：
sudo systemctl restart nvidia-persistenced第二级是完整冷重启机器。别嫌简单粗暴，对于 PCIe 链路状态类错误，主板和卡之间的链路状态机很可能已经处于异常状态，只有断电重启才能把链路恢复干净。这也是为什么“重启大法”在 802 上经常有效的原因。
第三级是针对可重置卡的nvidia-smi -r操作，适合驱动模块重载不够彻底的场景。
如果这三招都不能把 ERR 状态消掉，基本可以判断不是软件状态问题，而是硬件已经“病”了，往下走物理层处理。
4.2 物理层处理：重插、换槽、查供电
物理层处理是很多人容易忽略的一步，但恰恰是解决多卡机器 802 复发问题的关键。
先做重插与除尘。多卡机器长期运行后，PCIe 金手指氧化、插槽积灰是导致链路不稳的常见原因。把故障卡取下来，用橡皮擦擦拭金手指，重新插紧，用扎带固定好防松动。实测中很多“跑几天就报 Xid 43”的卡，重插后能稳定运行几个月。
再做供电排查。多卡满载时单卡功耗动辄 300W 以上，四卡就是 1200W+，电源或供电线一旦撑不住，最先表现的就是 PCIe 供电不稳，进而是 GPU 掉卡。有两个经验值可以参考：每张卡最好都有独立的 8pin/12VHPWR 供电线，尽量不要用一分二转接线；电源额定功率最好留出 30% 以上余量。
最后做换槽测试。主板的不同 PCIe 插槽在电气特性上不完全一致，某些槽位和特定显卡组合会频繁掉链子。把故障卡换到另一个 x16 槽位，观察一两天，如果 Xid 不再出现，就说明原来的槽位有问题，后续只能降级使用或走售后。
4.3 驱动层兜底：锁定/切换驱动版本与清理安装
如果硬件排查后没有明显问题，但 802 仍然间歇出现，下一步要考虑驱动自身的兼容性。这里我强烈建议做两件事：一是锁定一个稳定驱动版本，而不是每次都追最新；二是安装驱动时使用完全干净的方式，避免旧驱动文件残留。
Ubuntu/Debian 系清理旧驱动的常用做法：
sudo apt purge nvidia-* -y sudo apt autoremove -y sudo rm -rf /usr/lib/x86_64-linux-gnu/libcuda* /usr/lib/x86_64-linux-gnu/libnvidia*然后从 NVIDIA 官网下载对应驱动.run文件安装。安装前需要先停掉图形桌面服务（服务器一般没这个困扰），并且确认没有残留的内核模块。安装过程中有一个容易踩的坑：CUDA Toolkit 自带的驱动版本和系统里已装的驱动版本不一致。比如系统装的是 535 驱动，但某个应用自带的 CUDA 运行库要求驱动版本高于 545，一旦用到新的 CUDA 特性，驱动就会返回错误。
所以安装 CUDA Toolkit 时，建议用--toolkit方式只安装 CUDA 工具链，不附带安装驱动，让驱动版本由操作系统单独管理。这样能最大程度避免多个驱动互相覆盖导致的诡异问题。
4.4 修复后的验证清单
修复不等于“重启后能跑通一个测试”，而是要确认故障不再复发。我每次都会做下面这套验证，全部通过才认为修复完成：
nvidia-smi所有卡不再显示ERR!，温度、功耗、显存容量符合预期；- 用上文那段 C 程序遍历所有设备，全部返回 OK 且设备名、显存大小正确；
- 执行一次真实的多卡并发压力测试，比如 PyTorch 里同时起四个进程分别占用四张卡，各跑一轮 matrix multiply，确保上下文初始化不报错；
- 持续监控
dmesg24 小时以上，确认没有新的 Xid 错误出现。
如果验证过程中dmesg又捕捉到新的 Xid 错误，哪怕程序没崩，也说明硬件隐患没有排除，应回到物理层排查，而不是得过且过。
5. 应用层健壮性改造：让程序不再被802一击致命
5.1 初始化阶段全量枚举设备
硬件排查和修复能解决“故障已经发生”的问题，但无法保证以后不再发生。真正成熟的多卡程序应该在初始化阶段就主动识别异常设备，而不是等 CUDA 调用了才被动挨打。
最简单有效的做法是在程序启动时执行一次全量设备健康检查，把返回 802 的设备加入黑名单。PyTorch 环境下可以这样写：
import os import torch def get_healthy_cuda_devices(): healthy = [] for i in range(torch.cuda.device_count()): try: torch.cuda.set_device(i) _ = torch.tensor([1.0], device=f"cuda:{i}") healthy.append(i) except Exception as e: print(f"Device {i} excluded due to: {e}") return healthy healthy = get_healthy_cuda_devices() print("Healthy devices:", healthy)注意实际做健康检查时一定要真正分配一次显存，而不仅是torch.cuda.get_device_name(i)。802 常常发生在创建上下文或分配首个张量的阶段，只读设备名并不能触发上下文初始化。
这个问题在 OpenCV DNN 的 CUDA 后端同样存在。cv2.dnn.DNN_TARGET_CUDA会在第一次推理时才真正初始化上下文，所以即使前面readNet成功，到forward才报 802。这类场景没有简单的 API 预检，只能退化到“先跑一次小图推理”来验证设备可用性，或者用上文 C 程序提前检测。
5.2 失败重试与设备剔除机制
即便做了初始化检查，训练过程中仍然可能因为温度升高、供电波动等原因新出现坏卡。这时如果任务进程已经绑定在故障卡上，唯一能做的就是优雅退出和自动重启。
一个比较实用的模式是把训练脚本包一层 wrapper：任务启动后如果遇到任何 CUDA 错误，先记录日志，然后根据配置决定是否自动换一张卡重启。伪代码如下：
import subprocess import os import time devices = [0, 1, 2, 3] excluded = set() while devices: current = [d for d in devices if d not in excluded] if not current: print("All devices failed, exit") break env = os.environ.copy() env["CUDA_VISIBLE_DEVICES"] = ",".join(map(str, current)) proc = subprocess.run(["python", "train.py"], env=env) if proc.returncode == 0: break # 失败后假设最后一张卡有问题，剔除它再重启 excluded.add(current[-1]) print(f"Exclude device {current[-1]}, remaining: {current[:-1]}") time.sleep(30)这个方案不优雅，但在生产环境非常实用。半夜掉卡后任务能自动换卡续跑，而不是等你第二天上班来救。注意这里排除的规则要和常用框架的“按序号分配”结合：PyTorch 默认把CUDA_VISIBLE_DEVICES按顺序映射为 cuda:0、cuda:1…… 所以剔除逻辑要理解框架的可见设备顺序。
5.3 显存分配时的防御性处理
除了初始化阶段，显存分配阶段也需要防御。复杂一点的多卡任务会有“先用卡 0 加载模型，再迁移到卡 1”的流程，这时如果卡 1 在迁移过程中才出问题，802 就会出现在一个看起来很不相关的调用点。
我建议遵循三条比较稳妥的规则：
- 一次初始化，全程复用：任务启动后先把所有需要用到的设备全部初始化一遍（各分配一个最小的张量），后面再也不用现初始化新卡；
- 分配前自查：每次
cudaSetDevice后立刻检查返回值，不要等到cudaMalloc或 kernel 调用才检查； - 做好 checkpoint：频率不重要，关键是每次 checkpoint 要能覆盖到最近一段训练状态，这样即使 802 崩了，重启后损失也很小。
这些技巧不只针对 802，对CUDA_ERROR_UNKNOWN这类“错误码模糊得像什么都没告诉你”的场景同样管用。把能提前确认的信息在初始化阶段全部确认掉，运行的复杂度会大幅下降。
6. 多卡机器长期稳定运行的预防清单
6.1 开机BIOS与PCIe相关设置
很多多卡 802 的根源其实在 BIOS 设置。服务器主板的 PCIe 配置可能默认开启了一些对显卡不友好的特性，导致链路在高速率下不稳定。经过多次实践，以下几项对多卡稳定性影响最大：
- 强制锁定 PCIe Gen 速率：不要用 Auto，建议手动锁定为
PCIe Gen3或PCIe Gen4。Auto 模式在链路质量下降时反复降速协商，反而更容易触发 Xid 43/45。 - 开启 Above 4G Decoding：多卡大显存版本必须开启，否则系统无法正确映射显存地址空间。
- 关闭 Resizable BAR 或按需开启：Resizable BAR 对训练性能提升有限，但在部分主板上和某些驱动版本搭配时会增加不稳定性。如果在排障中，可以先关闭测试。
- 确认 PCIe 插槽拆分模式：四卡机器要检查主板 BIOS 里 PCIe 插槽的 x16/x8/x4 拆分方式，某些主板插满卡后速率会掉到 x4，虽然不会直接导致 802，但会让显存访问异常，间接诱发问题。
6.2 日常巡检与告警
与其等 802 出现了再救火，不如让问题在变严重之前就暴露。写一个简单的巡检脚本，每 10 分钟执行一次，把异常状态写入日志并触发告警：
#!/bin/bash # gpu_health_check.sh # 1. 检查是否有 Xid 错误 dmesg -T | grep -i xid | tail -20 > /tmp/xid.log if [ -s /tmp/xid.log ]; then echo "[$(date)] Xid errors detected, check /tmp/xid.log" >> /var/log/gpu_health.log fi # 2. 检查 nvidia-smi 中是否有 ERR! 标志 if nvidia-smi | grep -q "ERR!"; then echo "[$(date)] GPU marked as ERR by driver" >> /var/log/gpu_health.log fi # 3. 检查每张卡的 ECC 不可纠正错误 nvidia-smi -q -d ECC | grep -A 5 "Uncorrectable" >> /var/log/ecc_status.log再配合一个简单的看门狗脚本，检测到 802 后自动把故障卡隔离，并重启指定服务：
# 在训练脚本的启动脚本中，预先检查设备健康 for i in $(nvidia-smi --query-gpu=index --format=csv,noheader); do if nvidia-smi -i $i --query-gpu=ecc.errors.uncorrected.volatile.total --format=csv,noheader | grep -v "0" > /dev/null; then echo "GPU $i has uncorrected ECC errors, skip in CUDA_VISIBLE_DEVICES" fi done这套巡检的价值在于：当 Xid 错误第一次出现时，就把它暴露出来，而不是等到 802 第二次、第三次出现才引起重视。
6.3 给训练任务加自动降级能力
最后一个建议和代码有关。多卡训练任务不要写死“必须用满 N 张卡”，而是把设备数量作为参数，允许在卡数减少时以降级模式运行。比如一个 4 卡的任务可以接受 3 卡甚至 2 卡运行，只是 batch size 相应缩小。这样即使某张卡硬件出现问题，任务也不会完全中断。
具体做法是在任务启动脚本里读取当前健康设备列表，然后根据健康设备的数量动态调整 batch size 和CUDA_VISIBLE_DEVICES。实测中这个方案在长周期训练场景收益非常大——当一张卡彻底损坏时，训练从“崩溃后等待人工处理几天”变成“自动降级继续跑，期间不影响产出”。
多卡机器的 802 问题，本质上是硬件可靠性、驱动状态和应用代码三者之间的博弈。硬件问题不一定每次都能提前预判，但通过合理的排查链路、应用层防御和日常巡检，完全可以把它的影响降到可接受范围。至少我在生产环境里，已经能做到 802 出现后 10 分钟内自动隔离故障卡并恢复训练，而不是像最初那样每次都要半夜爬起来手动重启。
