多 GPU 服务器发生互连异常后，操作系统和 nvidia-smi 仍可能列出全部 GPU，普通单卡任务也能运行。如果节点仅凭“设备数量正确”重新进入调度，多 GPU 作业可能改走更慢的路径、在特定 GPU 对上失败，或让集合通信表现变得不稳定。准入判断必须从设备可见性提升到 NVLink 链路和预期拓扑是否完整。
处理流程要保留故障发生时的 GPU 身份、链路状态、Xid/系统事件、拓扑输出和作业信息，然后排空节点。维修、重启或组件更换后，用同一套基线核对每一对预期互连关系，并运行有方向性的点对点和集合通信测试。节点能否回归生产取决于目标工作负载所需路径是否恢复，而不是单一工具显示绿色。
先固定 GPU 身份与预期拓扑
记录 GPU UUID、PCI 地址、槽位或底板映射，以及健康节点上预期的 NVLink 连接矩阵。维修可能改变枚举顺序，不能用 GPU0、GPU1 作为长期身份。准入脚本应比较关系而非列表顺序，并能识别缺失、降宽或状态异常的链路。
故障证据要覆盖多个层次
保存 DCGM/NVML 相关字段、nvidia-smi topo、内核日志、BMC 事件和最近变更，关联具体作业与时间。单个累计计数无法说明问题何时发生，应在排空后采集静态快照，再运行受控负载观察增量。不要在证据不足时直接推断保修或更换结论。
验证替代路径是否掩盖异常
点对点复制或 NCCL 可能通过 PCIe 等替代路径继续完成。测试应覆盖每个预期 GPU 对、不同方向、消息大小和并发，保存路径与带宽时延分布。结果低于健康同型节点时，先核对实际拓扑和协议选择，不能只以任务退出码为准。
准入条件按工作负载分级
单卡池、多卡紧耦合池和维护测试池对互连要求不同。若平台允许降级使用，应通过调度标签隔离，并明确哪些作业可进入；不能让异常节点继续伪装成完整多 GPU 节点。生产多卡池通常要求预期链路、诊断和代表性通信全部恢复。
维修后重建长期基线
组件处理后重新记录 GPU 与互连映射，运行冷启动、长稳和重启复测，确认计数器不再增长。将新基线与工单关联，旧基线保留用于历史审计。驱动、固件或 DCGM 升级也可能改变字段含义，准入规则要随版本受控更新。
从试点到放量的检查项
- 保存 GPU UUID、PCI/槽位与健康节点互连矩阵。
- 关联 DCGM、拓扑、系统日志、BMC 与作业时间线。
- 逐 GPU 对验证方向、消息尺寸、替代路径和集合通信。
- 按单卡与多卡池定义隔离标签和明确准入条件。
- 维修后完成重启、长稳、计数增量和基线更新。
把产品事实转成测试条件
DCGM 提供 GPU 健康、诊断与互连相关的观测和管理能力。
具体字段、诊断级别和支持范围取决于 DCGM、驱动、GPU 平台与系统组合，应以对应版本文档为准。
文中机制与配置边界依据NVIDIA DCGM 文档的当前版本核对；官方说明用于确定候选条件，实际部署仍需结合完整料号、服务器支持清单、软件组合与现场测试。
让工程证据贯穿实施
中科新远是 NVIDIA Networking Elite 合作伙伴。中科新远可结合 GPU 节点、ConnectX 与集群网络协助整理互连基线、通信对照和节点准入记录，让服务器与 Fabric 故障证据能够关联。具体合作范围和项目交付内容以当前有效资质、官方目录及书面确认结果为准。
所有 GPU 都能被 nvidia-smi 识别，能否说明 NVLink 已恢复？
不能。设备枚举只证明 GPU 可见，还要核对预期链路矩阵、状态、错误增量、点对点路径和代表性多 GPU 通信。
WeChat
Profile