英伟达 H200 GPU 模组服务器深度解析：硬件布局、Linux 驱动、CUDA 与 InfiniBand

H200 服务器不是简单地把几张显卡插进普通机箱。一台典型的八卡 H200 服务器同时包含高功耗 GPU、双路 CPU 与 NUMA 内存、PCIe Root Complex、NVLink/NVSwitch 高速互联、BMC 管理控制器，以及面向 GPU 集群的 InfiniBand fabric。部署时如果只看"GPU 数量和型号"，会漏掉真正决定训练性能的东西：数据在 GPU 显存、主机内存、网卡之间实际走的物理路径。

这篇文章从底层路径出发，把 H200 服务器的硬件布局、Linux 驱动与 CUDA 安装、PCIe/NUMA 诊断、InfiniBand 与 GPUDirect RDMA、NCCL 通信逐层拆开：先说明机制（为什么拓扑、版本、网络组件必须以某种方式工作），再给可复现的命令，最后给出验证方法和常见坑。读完应能独立完成一台八卡 H200 节点的驱动安装、拓扑核查、InfiniBand 调通与上线验收。

说明：H200 服务器存在不同 OEM 设计。以下内容以常见的 H200 SXM/HGX 类平台为重点，同时覆盖 H200 PCIe 服务器。具体槽位、功耗、固件和网卡型号必须以整机厂商手册为准。

#一、H200 模组与服务器硬件布局

#1.1 两种形态：SXM/HGX 与 PCIe

先确定一个基本事实：H200 有两种物理形态，它们的差别不在芯片，而在 GPU 与 GPU、GPU 与主机之间的互联方式。

H200 SXM 模组（常见规格：141 GB HBM3e，显存带宽约 4.8 TB/s，TDP 约 700 W，具体以官方规格书为准）通常成组焊接在 HGX 或类似高密度基板上。基板内嵌 NVSwitch，把 8 颗 GPU 连成两两全速互联的全交叉拓扑（all-to-all）。SXM 形态的供电、散热和机械结构都是专门设计的，不能当作普通 PCIe 卡插入通用插槽。它适合八卡或更高密度的训练节点：单节点内 GPU 之间走 NVLink/NVSwitch，不必经过 PCIe 和 CPU。

H200 PCIe 形态（常见 TDP 约 600 W）使用标准 PCIe 插槽和机箱风道，部署灵活、可混插可替换，但 GPU 与 GPU 之间是否存在 NVLink（通过桥接卡）、是否经过 PCIe switch、是否跨 NUMA，完全取决于具体服务器设计。采购或扩容时不能只看 GPU 数量，还要确认 PCIe 代际、链路宽度、CPU Root Complex 归属和网卡位置。

一个关键区分点：SXM 形态并不是"没有 PCIe"。每颗 GPU 仍然以 PCIe Endpoint 形式出现在主机总线上——主机访问显存（BAR 映射、copy engine DMA、管理通道）都要走这条 PCIe 链路。SXM 的优势只体现在 GPU 对 GPU 的 P2P 路径上：这条路径走 NVLink/NVSwitch，而 PCIe 形态的 GPU 对 GPU 路径要绕过 CPU 与 Root Complex，带宽和延迟都差一个量级（详见 1.3）。

#1.2 典型八卡服务器的逻辑层次

机架服务器
├── BMC/IPMI：带外电源、传感器、固件和远程控制台
├── 双路 CPU：各自拥有 NUMA 内存和 PCIe Root Complex
├── 系统内存：建议按 CPU NUMA 均衡插满，避免单侧内存成为瓶颈
├── GPU 基板：H200 SXM、GPU baseboard、NVLink/NVSwitch
├── 本地盘：系统盘、缓存盘、数据盘，通常使用 NVMe
├── 高速网络：InfiniBand HCA 或 RoCE Ethernet NIC
└── 电源和散热：冗余 PSU、风扇墙、冷板或高压风冷

这张图不是装饰。每个方框都对应一条真实的数据通道：BMC 提供带外故障通道（GPU 消失时先看它）；双路 CPU 决定 NUMA 亲和；GPU 基板决定 GPU 之间的带宽；HCA 决定多机通信的带宽；电源散热决定整机能否稳定跑满峰值。

#1.3 三种距离：决定训练性能的物理路径

把一次训练 step 里的数据传输画出来，只剩三种"距离"：

• GPU 到 GPU：单节点内数据交换。SXM/HGX 走 NVLink/NVSwitch；PCIe 形态走 PCIe，甚至兜底走主机内存。
• GPU 到 CPU 内存：数据预处理、checkpoint、host 侧算子。路径是 GPU → PCIe 链路 → Root Complex → 本地内存控制器；如果目标内存在另一个 CPU 的 NUMA 节点上，还要穿过 CPU 间互连（Intel UPI / AMD Infinity Fabric），延迟和带宽都劣化。
• GPU 到网络 HCA：多机通信。HCA 挂在哪个 Root Complex 下、与 GPU 是否同侧，决定 NCCL 通信的延迟和走 P2P 还是走主机内存中转。

先量化 NVLink 与 PCIe 的差距。以 PCIe 5.0 x16 为例：单方向约 63 GB/s（双向约 126 GB/s）。H200 SXM 的 NVLink 4.0 总带宽约 900 GB/s（双向），约为 PCIe 5.0 x16 双向带宽的 7 倍。更本质的差异在跳数：PCIe 上的 P2P 要经过 Root Complex，跨 CPU 时还要经过 UPI，每次转发都增加几十到上百纳秒的延迟并占用共享带宽；NVLink 是 GPU 之间的专用直连，NVSwitch 只为 GPU 间转发服务，拓扑确定、路径可控。所以"一个可用的拓扑图比单纯查看 GPU 型号更有价值"——拓扑直接决定三种距离的上限。

#1.4 供电与散热检查

H200 属于高功耗数据中心 GPU。整机电源预算要同时覆盖 GPU 峰值功耗、CPU、内存、磁盘和风扇余量；SXM 基板的供电相数和散热风道一旦设计不足，峰值负载下会出现降频甚至掉卡。

生产环境应从三个层面观察功耗与温度：BMC/IPMI（带外传感器）、机架 PDU（整机电流）、操作系统（驱动读数）。不要为了短期跑分关闭保护机制，也不要在没有厂商支持的情况下修改功率上限。

# 查看 PCIe 设备和 NUMA 节点
lspci -nn | grep -Ei 'nvidia|ethernet|infiniband'
lscpu
numactl --hardware

# 查看内核识别到的 GPU 和日志
dmesg -T | grep -Ei 'nvrm|xid|pcie|iommu'
ls -l /dev/nvidia*

ls -l /dev/nvidia* 是驱动加载后设备节点是否存在的第一道检查：没有 /dev/nvidia0 这类字符设备，后面的 CUDA 一定起不来。

#二、Linux 上安装 NVIDIA 驱动与 CUDA

#2.1 版本规划：为什么 CUDA Toolkit 不能反向决定驱动版本

安装前先明确四个版本：服务器厂商验证过的 GPU 驱动分支、CUDA Toolkit 版本、容器运行时版本、框架版本。

很多人把驱动版本和 CUDA 版本当成一对一关系，这是错的。机制是这样的：Linux 驱动由内核模块（nvidia.ko）和用户态库（libcuda.so）组成；CUDA Toolkit 由编译器（nvcc）、运行时（libcudart）和各类库组成。应用编译时链接 Toolkit 的 libcudart，运行时要调用驱动提供的 libcuda 来执行内核、管理显存。兼容性约束只有一条方向：新版 CUDA Toolkit 运行时要求驱动不低于某个最低版本（NVIDIA 官方文档《CUDA Toolkit and Corresponding Driver Versions》给出每个 CUDA 版本的最低驱动映射表）。反过来不成立——同一套驱动可以运行大量旧版 Toolkit 编译的程序，也可以运行（同一主版本内的 minor version compatibility 范围内）较新的程序，不存在"装了 CUDA 12.4 就必须装某个固定驱动版本"的结论。

顺带说明一个日常观察点：nvidia-smi 里的 "Driver Version" 是运行期驱动版本，"CUDA Version" 不是当前装的 Toolkit 版本，而是该驱动支持的最高 CUDA 运行时版本——用它可以快速判断驱动是否够新。

数据中心环境优先采用厂商验证矩阵，不要在生产机上直接安装最新驱动；固定驱动分支后，升级 Toolkit 只升 Toolkit，不要顺手升驱动。安装前记录当前内核、发行版、Secure Boot 状态和是否存在旧驱动：

# 采集安装前环境，输出保存到变更记录
uname -a
cat /etc/os-release
mokutil --sb-state 2>/dev/null || true
lsmod | grep -E 'nouveau|nvidia' || true
dpkg -l | grep -E 'nvidia|cuda' || true

mokutil --sb-state 探测 Secure Boot 是否开启——这决定内核模块要不要签名，见 2.3。

#2.2 屏蔽 nouveau

nouveau 是开源的 NVIDIA 驱动，与闭源驱动同时加载会抢设备。标准做法是把 nouveau 加入模块黑名单，并禁止其 framebuffer console 接管（modeset=0）。只有确认当前没有在用 nouveau 的桌面环境（一般服务器无图形界面）时才可跳过；执行前还要确认厂商安装流程没有其他约定。

sudo tee /etc/modprobe.d/blacklist-nouveau.conf >/dev/null <<'EOF'
blacklist nouveau
options nouveau modeset=0
EOF
sudo update-initramfs -u
sudo reboot

重启后确认 nouveau 不再加载：

lsmod | grep nouveau || echo "nouveau 未加载"

#2.3 Secure Boot 与 MOK：内核模块签名机制

Secure Boot 开启时，UEFI 固件只加载签名可信的引导链，Linux 内核同样只加载签名可验证的内核模块。发行版仓库里的 NVIDIA 驱动若带发行版签名（例如 Ubuntu 官方仓库的 nvidia-driver 系列使用 Canonical 密钥签名，该密钥通常随 Secure Boot 一并预置），可以直接加载；自己编译的 DKMS 模块、或厂商提供的未签名模块，则必须把自己的公钥登记进 MOK（Machine Owner Key，机器所有者密钥）——shim 在启动时优先信任 MOK 数据库，登记后内核才认可用这把公钥签名的模块。

# 检查状态
mokutil --sb-state

# 导入用于模块签名的公钥（以实际的 .der 文件路径替换 /root/MOK.der）
sudo mokutil --import /root/MOK.der
sudo reboot
# 重启后进入蓝色 MokManager 界面，选择 Enroll MOK，
# 输入导入时设置的密码完成登记，随后再重启一次生效

安装完成后如果 nvidia-smi 找不到设备，先看 dmesg 里模块是否因签名被拒（module verification failed），再看 PCIe 枚举，不要立刻重复安装多个驱动包。

#2.4 Ubuntu/Debian 安装示例

以 Ubuntu 24.04（x86_64）为例。先安装与当前内核匹配的 headers，再安装发行版数据中心驱动分支：

sudo apt-get update
sudo apt-get install -y linux-headers-$(uname -r)
sudo apt-get install -y nvidia-driver-550-server nvidia-utils-550-server
sudo reboot

实际生产环境可使用 NVIDIA 官方仓库或 OEM 镜像，但必须固定包版本并记录 apt history。nvidia-driver-550-server 是 Ubuntu 对数据中心驱动分支的打包命名，版本号以厂商验证矩阵为准，不要盲目追新。

CUDA Toolkit 单独安装，它来自 NVIDIA CUDA APT 仓库而不是 Ubuntu 主源。先装 keyring 再装具体版本：

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt-get update
sudo apt-get install -y cuda-toolkit-12-4

keyring 包版本可能滚动更新，以 NVIDIA CUDA 下载页当前提供的文件名为准。Toolkit 版本选择原则：与 2.1 的驱动矩阵匹配，宁低勿高。

训练镜像大多跑在容器里，需要容器运行时：

sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

#2.5 驱动验证

# 驱动是否加载、GPU 数量和 ECC 状态
nvidia-smi
nvidia-smi -L
nvidia-smi -q -d ECC,POWER,TEMPERATURE,PCI

# CUDA 编译器和动态库路径
command -v nvcc || true
nvcc --version
ldconfig -p | grep libcudart

# 运行官方或发行版提供的 CUDA sample
./deviceQuery
./bandwidthTest

cuda-samples 需要从 GitHub 获取并构建（新版本 Toolkit 不再随包附带 samples 源码）：

git clone https://github.com/NVIDIA/cuda-samples.git
cd cuda-samples/Samples/1_Utilities/deviceQuery && make && ./deviceQuery
cd ../../2_Core_Features/bandwidthTest && make && ./bandwidthTest

deviceQuery 输出末尾的 Result = PASS、bandwidthTest 能跑出与设备匹配的 H2D/D2H 带宽，才算 CUDA 运行栈打通。

nvidia-smi 能工作不等于 CUDA 应用一定能工作。还要确认 libcuda、libcudart、框架自带 CUDA runtime、容器内用户权限和设备映射一致。不要把多个 CUDA 版本目录混进全局 LD_LIBRARY_PATH——串版本的后果是容器内 libcudart 依赖的驱动特性与宿主机 libcuda 不一致，轻则启动报错，重则行为异常。

#三、GPU、PCIe、NUMA 与系统诊断

#3.1 为什么 GPU 访存受 NUMA/PCIe 拓扑影响

GPU 的 HBM 是它自己的内存，主机内存对 GPU 而言永远是"远端"。任何 GPU 到主机内存的访问（copy engine 的 DMA、UVM 缺页迁移、cudaMemcpy D2H/H2D）都要走这条链：

GPU 显存 ←PCIe 链路→ Root Complex ←内存控制器→ 主机内存

如果目标内存在另一个 CPU 的 NUMA 节点，路径还要增加一段 CPU 间互连（UPI/Infinity Fabric）。后果是双重的：延迟增加（跨节点通常增加上百纳秒量级），而且 UPI 带宽被同一节点上所有跨 NUMA 流量共享，多 GPU 同时访问远端内存会互相挤占。同理，PCIe 是共享链路的串行总线，挂在同一 Root Complex 下的 GPU、HCA、NVMe 会竞争该 Root Complex 到 CPU 的带宽。

所以 affinity 不是玄学：把 GPU 的 host 侧操作（数据加载、NCCL rank 的 CPU 线程、HCA IRQ）绑定到 GPU 所在 NUMA 节点，是让路径最短、不抢 UPI 和远端带宽的工程手段。这也是为什么 numactl --hardware 和拓扑矩阵要"先看再动手"。

#3.2 GPU 状态与 Xid 错误

# 持续观察利用率、显存、功耗和温度
nvidia-smi dmon -s pucm -d 5
nvidia-smi --query-gpu=index,name,uuid,temperature.gpu,power.draw,memory.used,memory.total,utilization.gpu --format=csv

# 查看驱动报告的 Xid 错误
journalctl -k --since "2 hours ago" | grep -Ei 'NVRM|Xid'
dmesg -T | grep -Ei 'NVRM|Xid|fallen off the bus'

Xid 的机理：GPU 驱动（NVRM）在内核侧给 GPU 的多种错误源挂处理函数——SM 的 MMU 缺页或非法访问、显存 ECC 控制器、PCIe 链路错误、电源与热保护看门狗等。任一错误源触发时，驱动把错误类型编码成一个编号写进内核日志，格式形如 NVRM: Xid (PCI:0000:41:00.0): 31，后面常跟 PID、通道、上下文等字段。不同编号对应不同错误源，常见的有：

• 13：图形引擎异常，通常是应用侧非法指令或非法访问（多为应用问题）；
• 31：不可纠正错误（常与显存、上下文相关）；
• 43：驱动停止处理该 GPU（设备消失、链路故障的常见表现）；
• 63/64：单比特（可纠正）/双比特（不可纠正）ECC 错误；
• 79：GPU 从总线上消失（"fallen off the bus"，先查供电、PCIe 链路、插槽、固件）；
• 119：主机侧代码非法内存访问（对应 CUDA 的 CUDA_ERROR_ILLEGAL_ADDRESS）。

具体编号语义在不同驱动版本可能有差异，以当前驱动版本对应的 NVIDIA Xid 错误列表为准。处理原则：遇到 Xid 先保存完整日志、GPU UUID、作业 ID 和当时拓扑，再决定动作——重启会丢掉现场，同一个 Xid 重启前后原因可能完全不同。区分两类根因：应用侧（13/119 常见，重跑可复现）和硬件或链路侧（79、双比特 ECC、PCIe AER），后者要进 BMC 和固件排查。

#3.3 拓扑与亲和性

# GPU 与 GPU、CPU、NIC 的访问关系
nvidia-smi topo -m
nvidia-smi topo -p2p r

# 查看 GPU 与 NUMA 节点关联
for gpu in 0 1 2 3 4 5 6 7; do
    echo "GPU $gpu"
    nvidia-smi -i "$gpu" --query-gpu=pci.bus_id --format=csv,noheader
done

# 在已确认的 NUMA 节点上运行测试程序
numactl --cpunodebind=0 --membind=0 ./gpu_worker

nvidia-smi topo -m 输出一个矩阵：GPU 之间标 NV#（NVLink 直连）、SYS/NODE（跨 CPU 互连）、PHB/PIX（同 Root Complex 的 PCIe 路径），还会列出 NIC 与各 GPU 的 NUMA 亲和。topo -p2p r 实际做一次 P2P 读测试，给出每对 GPU 之间的实测带宽（GB/s）——比看拓扑文字更直接，NVLink 对与 PCIe 对的数值通常差一个量级。

不要机械地把所有任务绑定到 NUMA 0。正确流程：先看 topo -m 里 GPU 与 CPU、NIC 的归属，把 GPU 的 CPU 线程、数据加载线程、HCA IRQ 都放在同侧；多机训练再让每个 GPU 选择距离更近的 HCA（NCCL 里用 NCCL_IB_HCA 指定）。绑定后用 benchmark 确认，而不是凭感觉——topo -p2p r 和 nccl-tests 就是判据。

#3.4 PCIe BDF、链路与 AER

每颗 GPU 在 PCIe 总线上有一个 BDF（Bus:Device.Function，格式如 0000:41:00.0）。链路状态有"能力值"和"协商值"之分：LnkCap 是硬件能力（如 32 GT/s x16），LnkSta 是当前实际协商结果。发现 LnkSta 低于 LnkCap（能力 x16 协商成 x8，或 32 GT/s 协商成 16 GT/s）就是链路降速，通常与插槽供电、金手指接触、riser 或线缆、固件有关。

# 找到 GPU 的 BDF 后查看链路状态
lspci -D | grep -i nvidia
sudo lspci -vv -s 0000:41:00.0 | grep -E 'LnkCap|LnkSta|AER'

# 查看 IOMMU、AER 和 PCIe 错误
journalctl -k | grep -Ei 'IOMMU|DMAR|AER|PCIe Bus Error'
fwupdmgr get-devices 2>/dev/null || true

AER（Advanced Error Reporting，高级错误报告）是 PCIe 的错误上报机制，分可纠正错误（corrected，如链路训练中的瞬态）和不可纠正错误（uncorrected，再分 non-fatal 与 fatal）。内核日志反复出现 AER: Corrected error received 或 PCIe Bus Error 时，即使业务还没报错也要排查——它往往是链路不稳、供电波纹或固件 bug 的前兆。GPU 消失、链路降速或 AER 错误要结合 BMC 事件、线缆、插槽、固件和电源一起分析，不是单看驱动日志能定位的；生产环境升级固件前确认整机兼容矩阵，并安排回滚窗口。

#四、InfiniBand 网络详细配置与使用

#4.1 组件关系：为什么 Subnet Manager 是必需组件

InfiniBand 不是"插上就能通"的以太网。它的转发模型是：主机侧 HCA 和交换机端口都被 Subnet Manager（SM，子网管理器）分配一个 LID（Local Identifier，本地标识符），交换机按 LID 查转发表（Linear Forwarding Table）转发数据包——没有 MAC 学习、没有生成树，数据平面只认 SM 写进交换机的表项。

因此 IB fabric 的控制平面必须有一个 SM 在运行：它通过子网管理报文（SMP）发现拓扑、分配 LID、给每台交换机计算并下发转发表、把端口状态从 INIT 推送到 ARMED 再到 ACTIVE。端口未经过 SM 激活时停留在 INIT，数据包根本不会转发；SM 一旦挂掉，已有转发表还能继续转发存量流量，但新节点加入、链路切换、路径重算都会停摆。这就是"fabric 里至少要有一个 SM"是硬前提的原因：可以跑在专用管理节点，也可以跑在某台计算节点上；规模较大时配置主备 SM（如 OpenSM 的 standby 模式）实现故障接管。

其余组件：HCA 是主机侧适配器（如 ConnectX 系列，驱动为 mlx5）；交换机提供 fabric 转发；用户态 verbs/rdma-core 是 RDMA 编程与工具栈；多机 GPU 训练再由 NCCL 调用 verbs 和 GPUDirect RDMA。

#4.2 安装与基础状态检查

目标主机（以 Ubuntu 为例）先安装基础 RDMA 工具：

sudo apt-get update
sudo apt-get install -y rdma-core ibverbs-providers infiniband-diags perftest

RHEL/CentOS 系发行版通过名为 rdma 的 systemd 服务加载 /etc/rdma/modules 里声明的驱动；Ubuntu 上 rdma-core 由 udev 自动加载模块，一般无需手工启用服务。以 RHEL 系为例的启用方式：

sudo systemctl enable --now rdma

然后逐层确认：verbs 层看到几个设备、设备到网络接口的映射、端口状态、内核 rdma 栈状态。

ibv_devices
ibdev2netdev
ibstat
ibstatus
rdma link show

判定标准：ibstat / ibstatus 显示 State: Active。注意物理层 LinkUp 只是第一步，Active 才表示 SM 已激活端口——这一步不过，后面的地址配置和性能验证都无意义。

#4.3 Subnet Manager 部署

先确认 fabric 里已有 SM 在跑（通常由集群管理方提供），否则在本机部署 OpenSM：

sudo apt-get install -y opensm
sudo systemctl enable --now opensm
sudo systemctl status opensm

部署后验证（见 4.5）：ibnetdiscover 能画出全网拓扑、ibstat 端口 State 为 Active，说明 SM 正常。若多个 SM 同时以 master 运行会互相冲突，生产环境要么只启一个主 SM，要么配置主备（standby）模式。

#4.4 端口与地址配置

原生 verbs 通信（RDMA 读、写、send）不需要 IP 地址，但运维、监控和部分 MPI 与库的路径检查需要 IPoIB（把 IB 端口虚拟成 IP 网络接口）。注意：IPoIB 是"跑在 IB 上的 IP 协议"，不是以太网；不要把 RoCE 的 VLAN/PFC/QoS 配置套到原生 InfiniBand 上——二者的链路层（原生 IB 有链路级流控、无丢包语义 vs RoCE 依赖以太网 PFC/ECN 显式配置）和故障模型完全不同。

# 查看 HCA、端口和接口名（ibdev2netdev 给出 mlx5_0 到 ib0 的映射）
ip -br link
ip -br addr
ibdev2netdev

# 给 IPoIB 接口临时配置地址，接口名以实际系统为准
sudo ip link set ib0 mtu 4092   # 默认通常为 2044，可提高到 4092
sudo ip link set ib0 up
sudo ip addr add 10.20.0.11/24 dev ib0
ping -I ib0 10.20.0.12

# 永久配置应写入 NetworkManager 或 netplan，而不是只执行临时命令
nmcli device status
nmcli connection show

#4.5 Fabric 与性能验证

先验证 fabric 健康，再测性能。fabric 层关注端口错误计数和拓扑完整性：

# 查看端口计数器和错误
perfquery -x
ibqueryerrors -r
iblinkinfo
ibnetdiscover

ibqueryerrors 输出的关键错误计数器：链路误码（symbol/link error）、CRC 错误（物理层重传会导致带宽骤降）、超时重发（packet retransmit）。长时间跑训练前把计数器清零，训练后再看增量。

点到点 RDMA 带宽和延迟用 perftest，服务端和客户端必须分别启动：

# 服务端
ib_write_bw -d mlx5_0 -F -s 1048576

# 客户端（地址为服务端 IPoIB 地址）
ib_write_bw -d mlx5_0 -F -s 1048576 10.20.0.12

# 延迟测试同样双端启动
ib_write_lat -d mlx5_0 -F

-d 指定 HCA（mlx5_0），-F 表示不做 CPU cache flush（纯性能测量），-s 指定报文大小——大报文（1 MiB 量级）看带宽，小报文（8 B 量级）看延迟。大报文带宽应接近链路标称速率的 90%（例如 HDR 200Gb/s 链路上约 180+ Gb/s），延迟应在微秒级。记录测试条件：HCA、端口、MTU、消息大小、CPU 绑定、GPU 绑定、是否启用 GPUDirect——带宽低可能来自链路降速、错误重传、NUMA 远端访问、错误的 HCA 选择或交换机配置。

#4.6 GPUDirect RDMA：如何绕过主机内存拷贝

多机 NCCL 通信的性能上限由"数据从显存到线缆怎么走"决定。普通 RDMA 路径：GPU 显存 →（PCIe DMA）→ 主机内存 staging buffer →（PCIe DMA）→ HCA → 线缆，数据在主机内存里中转一次，还多一次显存与主机内存的拷贝（cudaMemcpy），CPU 和内存带宽都被消耗。

GPUDirect RDMA（GDR）的机制是让 HCA 直接对 GPU 显存发起 DMA：主机内存不参与数据面。实现上靠 nvidia-peermem（旧称 nv_peer_mem）内核模块把 GPU 的物理页暴露给 RDMA 栈：NVIDIA 驱动提供 nvidia_p2p_* 接口把显存页固定并映射进 PCIe 地址空间，mlx5 驱动通过该接口拿到 DMA 描述符，HCA 的 DMA 引擎直接读写显存。省掉两次 PCIe 传输和一次主机内存中转，带宽、延迟和 CPU 占用都显著改善。

# 查看 RDMA 设备和 NVIDIA peer memory 相关模块
lsmod | grep -E 'nvidia|ib|rdma'
modinfo nvidia-peermem 2>/dev/null || true

注意：GDR 不是默认就有，需要内核有 nvidia-peermem（驱动安装包通常附带，也可用 NVIDIA 提供的 DKMS 包），且 HCA 驱动要支持 peer memory 回调（mlx5 支持）。没有它 NCCL 仍能工作，只是会退回"IB 读主机内存再拷显存"的路径，性能差一截。perftest 支持用 CUDA 缓冲验证 GDR（具体参数以本机 perftest --help 为准）。

#4.7 NCCL：通信通道选择与 TCP 退化机制

NCCL 是 GPU 集合通信库。它对每一对 GPU 与 GPU、GPU 与 HCA 在启动时做拓扑检测，按能力从高到低选择通信通道：

• 单机内：NVLink P2P 大于 PCIe P2P 大于 SHM（共享内存，经主机内存中转）；
• 跨机：GPUDirect RDMA over IB 大于 IB 读写主机内存 大于 TCP sockets（经主机内存加 IPoIB 或 Ethernet 网络）。

退化到 TCP 的机制：当 NCCL 判断"没有可用的 RDMA 通道"时，自动退回最底层通道——TCP 通信需要 IP 地址、系统调用和内核协议栈，数据还要在显存与主机内存之间拷贝，延迟和带宽都差很多。触发退化的常见原因几乎都是配置而非硬件：

• NCCL_IB_DISABLE=1，或未显式设置但 IB 探测失败；
• NCCL_IB_HCA 写错设备或端口号，或指定端口未 Active；
• 主机没装或没加载 rdma-core 与 mlx5 驱动、HCA 内核栈失败；
• 缺 nvidia-peermem，GDR 被禁用（此时通常退到 IB 主机内存路径而非 TCP）；
• NCCL_SOCKET_IFNAME 指向不存在的接口，或接口 down；
• 防火墙、子网隔离导致 TCP 握手失败（多机时表现为卡在初始连接）。

所以 NCCL 环境变量不能盲目复制：

# NCCL 多机测试时显式指定网卡，并打开日志
export NCCL_DEBUG=INFO
export NCCL_SOCKET_IFNAME=ib0
export NCCL_IB_HCA=mlx5_0:1
export NCCL_IB_DISABLE=0
export NCCL_TOPO_FILE=/etc/nccl-topo.xml  # 只有准备好拓扑文件时设置

用 NCCL_DEBUG=INFO 启动一次小规模测试，看启动日志里的通道选择：正常会看到 NET/IB ... via ib0、P2P/NVLINK 之类字样；如果出现 Using network: TCP 或 NET/SOCKET，就是退化到了 TCP，按上面的原因清单逐项查，而不是继续调大 batch 压测。

验证工具是 nccl-tests，遵循"先用 nccl-tests 验证单机和多机，再接入训练框架"：

git clone https://github.com/NVIDIA/nccl-tests.git
cd nccl-tests && make

# 单机八卡（单进程多线程模式，不需要 MPI）
./build/all_reduce_perf -b 8 -e 8G -f 2 -g 8

# 多机（需要已安装可用的 MPI，例如 OpenMPI）
mpirun --hostfile hosts -np 16 ./build/all_reduce_perf -b 8 -e 8G -f 2 -g 8

-b/-e/-f 表示消息大小从 8 B 到 8 GiB 按 2 倍递增，-g 8 表示每个 rank 用 8 张卡。判定：单机 all_reduce 大消息应接近 NVLink 拓扑的实际可达带宽（H200 八卡通常在数百 GB/s 量级，以实测为基线），多机大消息应显著高于 TCP 回退水平；同时对照 NCCL_DEBUG 日志确认没有静默退化。把第一轮结果存成基线，之后任何拓扑、驱动、固件变更都对比它。

#五、上线验收清单

把硬件、驱动、拓扑和网络作为一个整体验收，并保存基线：

nvidia-smi -q > nvidia-smi-q.txt
nvidia-smi topo -m > topo.txt
ibstat > ibstat.txt
journalctl -k --since "1 hour ago" | grep -Ei "NVRM|Xid|AER|PCIe" || true

验收标准：GPU 数量和 UUID 符合资产记录，lspci 链路没有降速（LnkSta 等于 LnkCap），HCA 端口 State 为 Active，压力测试期间不新增 Xid、AER 或 ECC 错误，nccl-tests 结果不低于基线。出现 GPU 消失时先保存 BMC、内核日志和作业信息，再处理——先取证、后动作。

#六、常见失败模式与边界

• nvidia-smi 正常但 CUDA 应用报 CUDA_ERROR_NO_DEVICE：先查 /dev/nvidia* 权限、容器设备映射和 LD_LIBRARY_PATH 串版本。
• 反复出现 Xid 43 或 79 且伴随 AER：别再重装驱动，转向供电、插槽、线缆、固件和 BMC 事件排查。
• ibstat 显示 State: INIT：SM 未激活端口，查 SM 是否在跑、端口是否被禁用。
• perftest 大报文带宽只有标称的几分之一：查链路协商速率（rdma link show、ibstat）、ibqueryerrors 错误计数、NUMA 亲和和 CPU 绑定。
• NCCL 日志出现 TCP：按 4.7 的清单逐项核对，不要直接加 NCCL_IB_DISABLE=1 强行关掉 IB。
• 什么时候不该照抄本流程：单机单卡推理、不使用 RDMA 的多机 CPU 通信等场景，不需要部署 SM、perftest 和 GPUDirect 全套验证；按需求裁剪，别为流程而流程。

下一步建议：把本文的验收命令固化成节点上线脚本，把厂商、内核、驱动、固件和 NCCL 基线一并记录，每次变更硬件、升级驱动或固件后重新执行并对比基线；多机规模下再接入集群级监控（SM 状态、HCA 错误计数、GPU Xid 汇总），让"单节点能跑"变成"集群可运维"。