8×B200训练卡死？Fabric Manager版本与驱动不匹配致NVLS失效的排查记录

前两天接了一个 8×B200 服务器通信卡死的工单，现象很有代表性：8 卡训练任务跑到集合通信阶段，不报错、不崩溃、GPU 利用率也不高，就像被人点了穴一样卡死在原地。反复看日志、抓调用栈、缩最小复现，最后才揪出元凶——Fabric Manager 的版本和 GPU 驱动对不上，导致 NVLS 建不起来。B200 这类 Blackwell 平台的机器，NVLink Switch 拓扑是性能命脉，这个坑一旦踩上，排障成本非常高。所以我把完整排查过程和修复步骤整理出来，希望能帮到正在跑多卡训练、或者准备上 8×B200 的同学，少走几趟弯路。

1. 排障前传：一次"静默卡死"的训练任务

1.1 现象：不报错的挂起最磨人

机器配置是 8×B200，跑的是典型的数据并行 + 模型并行混合训练，启动命令用 torchrun 拉起 8 个 rank。任务启动后，前几步还能正常跑，到了某个 allreduce 或者梯度同步点，整个进程组就像被定住一样，loss 不再变化，GPU 利用率掉到个位数，但显存占用还维持在原位。

这种"静默卡死"最磨人，因为它没有任何明确报错。没有 OOM，没有 CUDA error，没有段错误，nvidia-smi 看每张卡都正常在线，进程也活着，SSH 进去 ps 能看到训练进程还在。如果不是有超时看门狗，它能在那儿挂一整天。

我第一反应是把复发窗口缩到最小。用 py-spy dump 一下主进程的调用栈，发现线程集体停在 NCCL 的集合通信等待上，具体调用是 ncclDevCommPlayBook 之类的底层同步点，业务代码本身没有任何死锁迹象。再用 strace 看 syscall，就是正常的 futex 等待和 epoll 等待，说明进程不是陷入 IO 卡死，而是在等某个下层信号。

这时候基本可以确定：问题不在 PyTorch 层，也不在模型代码，而是 NCCL 或者它依赖的硬件通信栈出了问题。接下来的排查重点就转向了通信链路本身。

1.2 第一反应：确认不是业务代码问题

为了快速排除业务代码干扰，我写了一个最朴素的集合通信验证脚本，只做一件事：让 8 个进程各自持有一个张量，做一次分布式聚合，然后退出。

import torch import torch.distributed as dist dist.init_process_group(backend="nccl") torch.cuda.set_device(dist.get_rank()) t = torch.ones(1024, dtype=torch.float32).cuda() with torch.no_grad(): dist.all_reduce(t) if dist.get_rank() == 0: print("allreduce OK", t.sum().item()) dist.destroy_process_group()

用同样的启动方式拉起 8 个 rank，毫不意外地卡死了。这个结果其实让我松了口气，因为这意味着问题高度集中在通信栈上，可以跳过排查业务代码的漫长过程，直接看硬件链路和 NCCL 的运行日志。

这里有个经验要说：遇到多卡任务挂起，不要一上来就在大训练脚本里加注释、改代码，那是在用最慢的方式缩小范围。一定要先做一个最小复现，把问题的责任边界切清楚。最小复现能不能复现，本身就是最重要的诊断信息。

2. 排查路径：从 NCCL 超时到 NVLink 状态

2.1 NCCL 日志是第一个突破口

最小复现卡死后，我用 NCCL 的调试环境变量重新跑了一遍，把通信层的交互过程完整打出来。这一步非常关键，强烈建议任何多卡通信问题都先做这件事：

export NCCL_DEBUG=INFO export NCCL_DEBUG_SUBSYS=ALL export NCCL_DEBUG_FILE=/tmp/nccl_debug_$RANK.log

这里的 NCCL_DEBUG_FILE 容易被忽略，但性能调优和排障时一定要设。多卡场景下，如果所有 rank 的日志混着往 stdout 打，顺序乱成一团，根本没法看。按 rank 分开落盘后，才能逐张卡对时间线。

抓到的日志里出现了典型的 NVLS 无法初始化的痕迹。NCCL 在初始化阶段会检测机器是否具备 NVLink Switch 能力，如果检测通过，会打印类似 "Initializing NVLS (NVLink Switch) plugin" 的信息，并在拓扑构建阶段标记 NVLS 可用。这次日志里，NVLS 的初始化被跳过，随后所有 rank 开始尝试建立点对点通信，然后就在握手阶段超时，出现 "NCCL WARN: Timeout waiting for remote" 之类的循环重试。

这说明 NCCL 自己是想走 NVLS 的高速通道的，但底层告诉它通道不存在。换句话说，硬件层面的 NVLink 组网没有真正就绪。

2.2 NVLink 与 NVSwitch 状态检查

接下来我把目光从 NCCL 挪到 GPU 和交换机的状态上。B200 平台和以前的 8 卡 A100/H100 直连拓扑有一个本质区别：B200 的单卡 NVLink 带宽和端口数都上了一个台阶，8 张卡往往不通过 GPU 之间两两直连来组网，而是通过 NVSwitch 做全互联。这种拓扑下，NVSwitch 的健康状态直接决定 GPU 之间的通信能不能通。

先看最基础的：

nvidia-smi

驱动识别正常，8 张卡都在，没有出现 "ERR!" 的降级标记。但只看这个远远不够，要专门看 NVLink 链路状态：

nvidia-smi nvlink -s

正常预期是每对链路都显示 Active，带宽协商正常。实际输出里，链路的 Power State 显示为 Inactive，或者干脆是 N/A。我再查 NVSwitch 本身：

nvidia-smi nvswitch -q

结果里有明显的异常状态。NVSwitch 的 fabric 状态没有处于 ON，端口状态大量处于 DOWN 或者未完成初始化的状态。换句话说，交换机硬件是好的，但上层的数据面没有真正拉起来。

再配合拓扑矩阵看一眼：

nvidia-smi topo -m

GPU 之间本该出现 NVLink 连接的拓扑关系，实际上完全没有体现，矩阵里只剩 PCIe 的连线。这个现象基本锁定：问题出在 NVLink fabric 的建立环节，而不是某一颗 GPU 的物理故障。

2.3 Fabric Manager 服务的可疑状态

NVLink fabric 的建立，在 Blackwell 平台上依赖一个关键用户态服务，叫 Fabric Manager（FM）。它负责管理 NVSwitch，也就是配置端口、建立路由、维护 fabric 的整体状态。FM 没跑起来，或者跑起来但没有正常工作，NVSwitch 就只是一台"通电但不干活"的交换机。

检查这个服务非常直接：

systemctl status nvidia-fabricmanager.service

第一眼看过去服务确实是 active 的，进程还活着，没有 crash。但我又翻了系统日志：

dmesg | grep -i -E "fabric|nvlink|nvswitch"

dmesg 里出现了非常扎眼的内容：NVRM 在反复尝试和 FM 做版本协商，但每次协商都失败，打印出来的驱动版本号和 FM 版本号对不上。日志大意是：驱动期望的 Fabric Manager 版本和当前实际加载的版本不一致，fabric bringup 被中止，NVSwitch 端口初始化停止。

这一刻问题已经浮现出来了：Fabric Manager 服务进程在跑，但它跑的版本和服务器的驱动不匹配，导致它实际上没有任何作用。接下来要做的就是确认这个版本差异到底差在哪。

3. 根因定位：版本不一致如何击穿 NVLS

3.1 NVLS 在 8×B200 平台上的角色

先解释一下 NVLS 到底是什么，因为很多第一次上 Blackwell 平台的同学对它的认知可能还停留在"NCCL 的一个新特性"上。

NCCL 里的 NVLS 全称是 NVLink Switch，指的是 NCCL 利用 NVSwitch 的交换能力来构建集合通信算法。传统 8 卡直连拓扑下，NCCL 的 allreduce 依赖 GPU 两两之间的 P2P 链路，通信路径受限于小型拓扑的维度。而在 NVSwitch 全互联拓扑下，所有 GPU 通过交换机交换数据，NCCL 可以构建更大的通信环和更大的通信域，甚至可以把交换机本身纳入归约操作，让数据在交换机层面完成聚合，而不是全部在 GPU 端跑一轮。

对于 8×B200 这类平台，NVLS 不是"加分项"，而是"默认主路径"。因为 B200 的 NVLink 带宽非常高，如果不走 NVLS，NCCL 只能退回 PCIe 或者其他低速通道，这个降级在训练任务上几乎是灾难性的：本来几个 GB 的梯度同步只需要毫秒级，降级后可能变成秒级，整体训练吞吐直接断崖。

更麻烦的是，在这个拓扑下 NVLS 不是你想关就能关的，它检测到 NVSwitch fabric 不可用后，不会主动报一个清晰错误，而是试图用其他方式继续初始化，最终在握手环节超时挂住。这就是这次"静默卡死"的根本来源：NVLS 建不起来，NCCL 又没法完成优雅降级。

3.2 版本协商失败的故障机制

为什么 Fabric Manager 版本不一致会导致这么严重的问题？原因在于 NVIDIA 的驱动和 FM 是严格配套发布的。驱动里对应的 NVSwitch 内核模块，和 FM 用户态守护进程之间，有一套版本协商机制，两者必须严格对齐，FM 才能接管并配置交换机。

可以把它类比成一台交换机的控制器架构：GPU 和 NVSwitch 是数据面硬件，Fabric Manager 是控制面软件，两者之间通过明确的协议通信。当控制面软件和数据面固件之间的协议版本不一致，控制器会拒绝下发配置，交换机端口就不会被初始化。

在这台机器上，驱动版本和 FM 包的版本差了一个大版本。FM 进程虽然在运行，但它的协议实现和内核模块期望的版本不匹配，协商失败后，fabric 停留在未初始化状态。NVSwitch 端口没有进入转发模式，NVLink 链路显示 Inactive，NCCL 的 NVLS 检测自然失败。

这里还有一个容易被忽略的点：多节点环境里，哪怕只有一台机器的 FM 版本和其他节点不一致，整个 NVLink fabric 的全局状态也可能被破坏。因为 NVSwitch 跨节点组网时，所有参与节点的 FM 版本必须是一致的，否则建立全局 fabric 的过程就会在某一步中止。所以全集群的 FM 版本一致性，和驱动版本一致性一样重要。

3.3 确认版本差异的几条命令

确认版本差异其实只要几条命令，非常快：

nvidia-smi --query-gpu=driver_version --format=csv dpkg -l | grep -i fabric

在 RPM 系的系统上把 dpkg 换成 rpm -qa | grep -i fabric 即可。我在这台机器上看到的结果是：驱动版本是 570.82，而 Fabric Manager 包停留在 555 系列。差了整整一个版本线，协商当然不可能成功。

还有一个可以交叉验证的命令：

nvidia-fabricmanager -v 2>&1 | head

输出显示的 FM 版本和包管理器里查到的一致。到这里，根因已经板上钉钉，不需要再猜了。

顺带说一句，检查 FM 版本这件事应该被写进节点上线脚本。很多人装完驱动就以为万事大吉了，但驱动包里默认是不带 FM 的，FM 需要单独从 NVIDIA 的仓库安装。如果安装时用的源不对，或者包版本被缓存锁住，就容易出现这种"驱动升级了、FM 没跟上"的错位。

4. 修复操作：统一版本、重启服务、完整验证

4.1 按驱动版本严格对齐 FM 包

修复思路说起来很简单：把 FM 版本对齐到驱动版本。但这一步实际操作有一些讲究，不能随便挑一个最新版装上去。

首先要确认这台机器上驱动是哪个系列，然后去 NVIDIA 官方仓库找对应系列的 FM 包。例如驱动是 570.82，就应当安装 nvidia-fabricmanager-570，并且把包版本精确指定为 570.82。

sudo apt install -y nvidia-fabricmanager-570=570.82-1

如果仓库里自动源已经配好，也可以直接指定包名安装，但最好还是显式带上版本号，避免依赖解析把 FM 升到另一个驱动系列。这里要特别提醒：千万不要只升级驱动而不升级 FM，反过来也一样，这两者必须同步更新。最好的做法是把驱动包和 FM 包放进同一批变更里，一起升级，一起回滚。

4.2 重启服务与现场清理

安装好正确的 FM 包后，需要让服务重新加载：

sudo systemctl daemon-reload sudo systemctl restart nvidia-fabricmanager.service systemctl status nvidia-fabricmanager.service

如果只是 FM 版本不一致，没有更深的固件异常，通常这一步之后 NVSwitch 就会开始初始化。但我在实际处理中遇到过一种情况：切换版本后，FM 虽然重启了，交换机却依然停留在半初始化状态。这是因为 fabric 的旧状态没有被完全清除。

这种情况的稳妥做法是直接重启节点，让 GPU、NVSwitch、内核模块和 FM 全部重新走一遍初始化流程。生产环境里重启节点要提前报备，但比起在一堆残留状态里反复试错，干净重启反而是最快最安全的方案。如果实在不能重启，可以考虑卸载并重新加载 NVIDIA 相关内核模块，但前提是节点上没有正在运行的 GPU 进程，风险较大，不做推荐。

4.3 全链路验证恢复

修复完成后，验证环节不能只看 FM 服务状态，要把整个链路从底层到应用层完整走一遍。

第一步，看链路状态：

nvidia-smi nvlink -s nvidia-smi nvswitch -q

这次 NVLink 链路全部变成 Active，NVSwitch 的 fabric 状态变为 ON，端口也全部 UP。再看一下 nvidia-smi topo -m，GPU 之间又重新出现了 NVLink 的拓扑连线。

第二步，跑之前那个最小 allreduce 脚本，并且打开 NCCL_DEBUG。这次日志里出现了 NVLS 初始化成功的关键字，NCCL 确认 NVLS 可用，并且实际启用了 NVLS 的通信路径。allreduce 瞬间完成，8 个 rank 结果一致。

第三步，回归真实训练任务。直接拉起之前的训练脚本，跑到之前卡死的那个阶梯点，正常通过，梯度同步耗时恢复正常，吞吐回升。到这里，故障才算真正闭环。

5. 同类问题排查清单与避坑经验

5.1 快速诊断命令速查表

这次排障用到的命令其实不多，但每一条都很关键。我把它们整理成一张速查表，下次遇到类似问题可以直接按顺序来一遍：

建议把"驱动版本对比 FM 版本"这一步提前到所有步骤的最前面，因为它是成本最低的检查项，却经常能直接定案。

5.2 实战心得与注意事项

排障之外，还有几条经验值得记住。

第一，Blackwell 平台的机器，Fabric Manager 和驱动必须维护在同一版本线。升级驱动时不带 FM、或者用了错误仓库的 FM 包，是最常见的翻车姿势。我在处理这台机器时还发现，之前安装 FM 的 apt 源里混了旧版本的缓存，导致即使执行了安装命令，解析出来的还是老包。处理完后我顺手清理了缓存并固定了源，避免同类问题复发。

第二，FM 服务正常不等于 fabric 正常。服务是 active 的，只是说明进程活着，不代表它成功完成了 NVSwitch 的配置。判断是否真正可用，一定要看 nvidia-smi nvswitch -q 里的 Fabric State，这是最接近真相的状态。

第三，不要在训练任务运行期间重启 FM。NVSwitch 的端口在任何状态下都承载着 GPU 之间的流量，热重启 FM 会让所有依赖 NVLink 的通信瞬间中断，甚至导致整机范围的级联超时。如果必须在运行中的集群上做 FM 变更，先停任务，再变更，再拉起，这个顺序不能乱。

第四，多节点环境里，把 FM 版本一致性检查写进巡检脚本。单节点版本的错位会拖累全局 fabric，而这种问题在任务还没跑到集合通信阶段时，可能根本不会暴露。每次驱动升级后，最好在测试环境里做一次全链路集合通信验证，再批量推生产。

最后再分享一个小技巧：排查这类问题时，NCCL 的日志文件一定要按 rank 分开保存，并且尽量用 NCCL_DEBUG_SUBSYS=ALL 把底层事件打全。很多多卡通信问题，单看一张卡的日志看不出名堂，但把 8 张卡的日志放在时间轴上对齐，卡在谁身上、等的是谁，一目了然。这次从发现 FM 版本不一致到完成修复，真正花在定位上的时间其实很短，大部分时间都耗在确认"服务活着但没有干活"这个假象上。希望这篇记录能帮你在下次遇到类似卡死时，少绕这个弯。