GPU对调定位法：8 卡 RTX 6000D 掉卡，如何用对调缩小故障范围

大模型推理基础设施实战系列 · 第 9 篇

上一篇的8卡算力服务器，排查难点是"证据边界"；本篇的 8 卡服务器，难点换成"定位"：8 张卡里哪一张、还是槽位、还是供电？答案来自一次设计良好的对调实验——这是硬件现场最便宜、也最容易被做错和误读的定位手段。

1. 背景与问题：NCCL 压测中途，8 卡变 7 卡

故障节点（脱敏代号 gpu-node-025）配置 8 张 NVIDIA RTX 6000D（单卡显存 85,651 MiB，功率上限 600 W），驱动 595.91.07。节点在执行 8 卡 NCCL all_reduce_perf 测试期间突然掉卡；现场重启一次后 GPU 临时恢复，随后再次复现相同问题。

两个初始事实划定了本文的范围：

两次故障快照 nvidia-smi 均只识别 7 张卡，内核最终记录 Node Reboot Required；
现场排查结论为 GPU 供电异常——但到本文整理时，尚无修复完成及复测通过的记录。现有日志直接证实的是"GPU 掉总线"；"供电异常"来自现场反馈，具体是板上供电、外接接口、线缆还是其他供电部件，仍需补充检测或更换验证。

尚未提供的材料也先列清楚：

BMC 供电告警、PCIe 枚举输出及硬件维修记录。

2. 事件级联：从首条 Xid 79 到整机要求重启

内核日志（dmesg -T | grep -i xid，共 15 条）拼出了 28 秒内故障扩大的全过程：

Xid 事件级联

三个 Xid 的语义边界（依据 NVIDIA Xid Catalog）：

错误记录	本次含义与证据范围
Xid 79	驱动经 PCIe 无法访问 GPU。本次多次指向 F4:00，明确记录掉总线；该错误码本身不能唯一确定供电故障点
Xid 143	GPU 初始化错误。本次具体文本是轮询 FSP 启动完成时报错（status 0x65），发生于首条掉总线之后，不能仅凭此认定固件为根因
Xid 154	恢复动作变更通知。先 GPU Reset Required，后 Node Reboot Required；8 个地址都出现该通知，不等于 8 张卡分别硬件损坏

17:42:58 的 nvidia-smi 文本输出只剩 7 张卡：可见 03:00、04:00、73:00、74:00、83:00、85:00、F3:00，缺失 F4:00。注意此时可见卡均处于 P8、利用率 0%、温度 24°C——这是故障后的空闲快照，不能据此反推掉卡瞬间的温度、电压或功率。

3. 对调实验：一次交换，把故障范围收窄到"随卡走"

现场随后做了关键一步：将 F3:00 与 F4:00 两个位置的两张 GPU 对调。涉及的两张卡（SN 已脱敏为尾号）：

GPU（SN 尾号）	对调前位置与状态	对调后位置与状态
尾号 7380	F3:00 / slot6，可识别	F4:00 / slot7，可识别（SN 迁移由现场明确提供）
尾号 5187	F4:00 / slot7，初始掉卡对象	按两卡互换推定移至 F3:00 / slot6；该位置对调后不可识别

对调后（20:02:00 截图）仍只识别 7 张卡：可见地址里 F4:00 回来了，F3:00 消失了。

对调实验前后对照

定位判断：对调前缺 F4:00、对调后缺 F3:00，同时原 F3:00 的尾号 7380 在 F4:00 可识别——故障呈现跟随原 F4:00 对应 GPU 迁移的特征。这一结果支持优先定位尾号 5187 这张卡，而不能仅因对调后 F3:00 缺失就反过来说 slot6 是固定故障槽位。

4. 对调结论的三条边界

对调实验便宜好用，但结论很容易被读过头。本案必须保留三条边界：

对调范围未记录。 现场未说明供电线缆、转接件是否随 GPU 一同移动。若有随卡迁移的部件，故障范围就包括这些部件，不能只写"卡坏了"；
可见 ≠ 健康。 尾号 7380 对调后可识别，仅证明该时刻可见，不代表已通过持续负载测试；

还有一个本案没踩、但很常见的坑：物理 slot 编号不等于 nvidia-smi 的 GPU 索引，掉卡后设备索引会重排（对调后截图里 GPU 索引 6 已对应 F4:00）。后续采集和报修应同时记录 SN、GPU UUID、PCI 地址、物理 slot 四元组，避免索引重排造成定位错误。

5. 测试与证据管理：别让复测覆盖掉故障证据

现场原始测试命令（保留环境变量与参数原貌，本文仅整理记录，未连接故障节点执行）：

source /root/ncclenv
export CUDA_DEVICE_ORDER=PCI_BUS_ID
export CUDA_VISIBLE_DEVICES=0,1,2,3,4,5,6,7
export NCCL_IB_HCA='=mlx5_0:1,mlx5_1:1,mlx5_4:1,mlx5_5:1'
export NCCL_IB_GID_INDEX=3
export NCCL_P2P_LEVEL=PHB
export NCCL_DEBUG=INFO   # 其余 NCCL_* 设置略

numactl --interleave=all ./all_reduce_perf \
  -b 8M -e 8G -f 2 -n 100 -w 20 -g 8 -c 1 \
  2>&1 | tee /var/tmp/nccl-manual/all_reduce_perf.log

测试范围 8M 至 8G、消息大小 2 倍递增、8 卡

三条证据管理纪律：

复测前先确认 8 张 GPU 均可识别，否则测的不是同一个系统；
原命令使用固定日志文件名——复测前归档已有日志，避免 tee 覆盖故障证据；
单独记录测试程序退出码，不要只看终端打印。

6. 后续排查与修复验收：什么叫"修好了"

结合反复掉总线、重启仅临时恢复、故障随对调迁移这三点，后续处理应围绕疑似故障卡及其供电连接展开（按厂商维护流程，断电操作）：

留存现场证据：完整内核日志、nvidia-smi -q、SN/UUID 对照、lspci -Dnn、NCCL 日志、BMC SEL；核对服务器与 BMC 时间，关联掉卡时刻的供电、PCIe 和热插拔事件；
明确对调范围：GPU、供电线缆及转接件是否一起移动，拍照核对尾号 5187 的当前位置；
检查供电部件：供电插头、线缆、连接器及板上供电状态，结合 BMC 告警定位；
单变量验证：用已知正常的卡或供电部件逐项替换，逐次记录 SN、slot、供电支路与结果——避免同时换多个部件后无法判断根因；
补齐闭环：更换/修复部件、时间、维修单号；换卡保存新旧 SN 及完整复测日志。

修复后的验收条件（不满足就不许结案）：

8 张 GPU 均正常识别，SN、UUID、PCI 地址与物理槽位记录一致；
重新执行原 8 卡测试，完整覆盖 8M 至 8G，程序成功结束且数据校验无错误；
多轮测试及约定的持续负载时段内无再次掉卡，内核无新增相关 Xid 79/143 或要求恢复的 154，BMC 无新增相关供电异常；
保存复测起止时间、轮次、退出码和日志。

7. 效果与总结

已确认	未确认 / 边界
F4:00 反复 Xid 79 掉总线，内核要求整机重启	供电异常的具体部件（板上供电/接口/线缆）未定
故障随对调迁移，优先定位尾号 5187	随卡部件（线缆/转接件）是否一同迁移未记录
对调后 7 卡可见、缺失位置随卡变化	尾号 5187 对调后位置为推定；7380 未经持续负载验证

四条经验：

对调是 8 卡现场最便宜的一阶定位手段——一次交换能增强“故障随移动部件迁移”的证据，但不能彻底排除间歇性槽位或平台问题，但结论范围跟着对调范围走；
四元组登记（SN+UUID+PCI+slot）要抢在掉卡前做好——掉卡后索引重排，事后补登记处处是坑；
Xid 154 全员出现 ≠ 全员损坏——恢复策略升级是系统级通知，先找第一条 Xid 79 的地址；
没有验收标准的维修不是闭环——"重启能认"和"修好"之间隔着完整量程复测、持续负载和日志留存。

下一篇：错误表象在 NCCL/MPI 层，根因却在 NVSwitch 物理链路——CUDA 802 不是 NCCL 网络故障：H20 NVSwitch 物理链路排查实录。

系列目录

数据声明：本文依据现场描述、原始 SN 清单、终端文本与截图整理，整理方未连接故障节点执行命令