新闻中心

NVSwitch 服务器为什么要单独核对 Fabric Manager:驱动可用不等于 Fabric 就绪 NEWS DETAIL

资讯分类 · 选型与兼容 作者 · 中科新远技术编辑部 审核人 · 中科新远 发布时间 · 2026-08-03 更新时间 · 2026-08-04 来源 · NVIDIA Fabric Manager 文档
NVSwitch 服务器为什么要单独核对 Fabric Manager:驱动可用不等于 Fabric 就绪
场景示意图,不对应具体设备型号、端口布局或技术拓扑。

在采用 NVSwitch 的 HGX、DGX 或等价集成平台中,仅看到全部 GPU 被操作系统和驱动枚举,不能证明 NVSwitch Fabric 已经完成初始化,也不能证明多 GPU P2P 与集合通信路径可用。Fabric Manager 属于这类系统的软件栈组成部分,但并非所有独立 GPU 服务器都需要安装。采购或升级前必须先确认服务器是否使用 NVSwitch、属于哪一代平台,再核对对应 Fabric Manager 与驱动组合。

这也是一个典型的兼容性问题:单个软件包“可以安装”不等于完整组合得到支持。内核、GPU 驱动、Fabric Manager、系统固件、GPU/NVSwitch 拓扑、容器和通信库共同决定节点状态。若资产表只记录 CUDA 和驱动版本,后续重装、镜像升级或节点替换很容易漏装服务,结果是单卡任务正常,多卡任务失败或路径异常。

直接答案是:先以完整平台身份建立矩阵,再以 Fabric 状态和多 GPU 通信做准入。不要从另一代 HGX/DGX、普通 PCIe GPU 服务器或不同虚拟化模式复制结论。

Fabric Manager 官方适用范围

NVIDIA Fabric Manager 文档面向采用 NVSwitch 的单节点 HGX 与 DGX 系统,介绍 NVSwitch 软件栈、部署、虚拟化与高可用等内容。

NVSwitch 用于连接多条 NVLink 并支持系统内多 GPU 通信;Fabric Manager 的具体职责和运行方式会随 NVSwitch 代际与平台变化。

Fabric Manager、GPU 驱动、系统平台与虚拟化模式的兼容关系必须按对应版本文档和服务器支持资料确认。

本文关键机制依据NVIDIA Fabric Manager 文档的当前公开版本核对。官方资料用于界定候选能力,实际项目仍需结合完整型号、软件版本、支持矩阵与现场测试。

先判断服务器是否处于适用范围

核对整机厂商与型号、GPU 基板、GPU/NVSwitch 代际、系统拓扑和官方支持资料。普通不含 NVSwitch 的 PCIe GPU 服务器与 NVSwitch 平台的软件要求不同,不能因安装包存在就默认部署。资产记录要保留完整机型和硬件修订,而不是只写 GPU 型号。若供应商集成方式不明确,应通过服务器文档和技术支持确认。

Fabric Manager 解决的不是 GPU 枚举

GPU 驱动负责设备访问的核心部分,NVSwitch Fabric 还涉及交换芯片、链路、拓扑与分区等状态。不同代际的软件栈可能采用不同管理方式,必须以目标平台文档为准。服务进程存活只是控制面条件之一,不能代替 NVLink/NVSwitch 状态、拓扑关系、P2P 和真实集合通信测试。

兼容矩阵至少包含哪些字段

矩阵应包含整机平台、GPU/NVSwitch 代际、BIOS/BMC/系统固件、操作系统与内核、GPU 驱动分支、Fabric Manager 包、CUDA 容器、NCCL 以及虚拟化或 MIG 模式。每个组合记录官方依据、内部验证日期、节点池范围和回退版本。只写“最新版”无法重建,也不能支持故障对比。

安装和升级路径要按节点池控制

候选组合先进入隔离节点,完成驱动与 Fabric Manager 安装或升级,检查服务日志、Fabric 状态和拓扑,再运行目标容器。生产升级先排空节点,保存旧状态和软件清单,升级后通过准入才恢复调度。同一分布式作业不应跨未经批准的混合组合,避免问题被误判为网络或框架抖动。

多 GPU 验证必须覆盖路径差异

先验证设备身份和预期拓扑,再做 GPU 对之间的 P2P、带宽与访问测试,并运行与生产相近的 NCCL 集合通信。不同 GPU 对、消息规模和并发可能经过不同路径,单一 All-Reduce 结果不足。测试同时采集 Fabric Manager、驱动、系统事件和通信日志,把失败映射到具体 GPU、链路与时间。

虚拟化与分区不能沿用裸机结论

当平台采用 GPU 直通、共享 NVSwitch、MIG 或服务虚拟机时,Fabric Manager 的位置、权限和启动顺序可能发生变化。文章不能给出脱离平台的统一部署命令。设计时需根据官方虚拟化章节与供应商方案核对支持模式,并验证租户隔离、重启、迁移或宿主维护后的恢复。

风险边界集中在错配与误准入

常见风险包括驱动与 Fabric Manager 组合未经验证、节点镜像漏包、服务启动早于依赖、维修后拓扑变化,以及监控只检查进程。价格、授权、保修和原厂支持不能由版本号推断。节点出现 Fabric 错误时先排空和保留证据,不使用反复重启掩盖硬件、固件或链路问题。

回退也要恢复 Fabric 运行状态

回退前保留软件包、配置、服务状态、GPU 身份、拓扑和通信基线。恢复旧驱动与 Fabric Manager 后,重新启动并不代表结束,还要再次完成 Fabric 状态、P2P、NCCL、容器和调度准入。若平台不支持原地降级,应预先准备节点重装和节点池切换方案。

NVSwitch 节点兼容与准入步骤

  1. 确认整机、GPU 基板和 NVSwitch 代际。
  2. 按官方资料绑定驱动、Fabric Manager、固件与系统组合。
  3. 保存服务日志、Fabric 状态和预期拓扑。
  4. 覆盖不同 GPU 对的 P2P 与集合通信验证。
  5. 测试重启、服务异常、节点维修和虚拟化边界。
  6. 执行软件回退并重新完成节点准入。

所有多 GPU 服务器都需要安装 NVIDIA Fabric Manager 吗?

不是。Fabric Manager 主要面向使用 NVSwitch 的特定系统和模式。普通 PCIe 多 GPU 服务器不能仅因 GPU 数量多就套用同一要求,必须按完整平台和官方支持资料确认。

兼容判断需要落到完整服务器

中科新远是 NVIDIA Networking Elite 合作伙伴。中科新远可结合 GPU 服务器与 NVIDIA Networking 环境协助整理平台身份、驱动/Fabric Manager 组合和多 GPU 准入记录,不把单项可安装误写成整机兼容。具体合作范围和项目交付内容以当前有效资质、官方目录及书面确认结果为准。

继续核对产品、方案与测试