在高性能计算与人工智能领域飞速发展的当下,数据传输的效率与稳定性已成为决定计算任务成败的关键因素。IB 网络以其卓越的高带宽、超低延迟和可靠的远程直接内存访问(RDMA)技术,为大规模分布式训练、科学计算等场景提供了无与伦比的网络支持。无论是构建大型数据中心集群,还是运行对网络要求严苛的深度学习任务,NVIDIA GPU 物理机与 IB 网络的深度融合都展现出强大的协同优势。本指南将系统梳理 NVIDIA GPU 物理机环境下 IB 卡和GPU相关常见问题,并介绍 gpu-burn 测试完整操作流程,帮助您快速掌握处理对策,解锁高效计算的新可能。
一、IB(InfiniBand)背景介绍
在高性能计算与数据中心网络领域,RoCE(RDMA over Converged Ethernet)和 NVIDIA IB(InfiniBand)是实现高速数据传输的两大主流技术,它们虽都支持远程直接内存访问(RDMA),但在架构、性能和应用场景上存在显著差异。
| 维度 | RoCE(RDMA over Converged Ethernet) | NVIDIA IB(InfiniBand) |
|---|---|---|
| 网络类型 | 基于以太网(Ethernet)的 RDMA 协议 | 专用高速网络架构(独立于以太网) |
| 物理介质 | 普通以太网交换机、网线(支持 10/25/100G 等) | 专用 IB 交换机、光纤 / 铜缆(支持 100/200/400G 等) |
| 延迟 | 微秒级(通常 1-10 μs) | 纳秒级(通常 < 1 μs,更低延迟) |
| 协议复杂度 | 依赖以太网 QoS(如 PFC/ETS)避免拥塞 | 内置流量控制(如 Credits),无需额外配置 |
| 典型场景 | 通用数据中心、混合网络环境 | 高性能计算(HPC)、AI 训练集群(如 NVIDIA DGX) |
二、多卡互联问题
2.1 硬件与驱动类
| 问题现象 | 排查指令 | 预期结果 |
|---|---|---|
| IB 设备未识别 | ibv_devices | 显示设备列表(如 mlx5_0) |
| 驱动版本异常 | mst status -v | 固件版本与硬件匹配(如 20.35.1012) |
| GPU 多卡未识别 | nvidia-smi -L | 列出所有物理 GPU |
2.2 网络连通性类
| 问题现象 | 排查指令 | 操作建议 |
|---|---|---|
| 设备状态异常 | ibstat mlx5_0 | State=Active,Physical state=LinkUp |
| 防火墙阻断 | systemctl status firewalld | 关闭防火墙或放行 UDP 4096-65535 端口 |
| LID 通信失败 | ibping -L <对端LID> | Loss%=0 |
| IP 通信失败 | ping <对端IB IP> | 网络可达(延迟 < 1ms) |
2.3 其他常用指令
ibv_devinfo # 列出所有 IB 网卡(如 mlx5_0、mlx5_1)
ibv_devinfo -d mlx5_0 # 列出mlx5_0网卡信息
ibdev2netdev # 查看网口映射关系
cat /sys/class/infiniband/mlx5_0/ports/1/pkeys/0 # 带内查询IB网卡唯一pkey
三、IB卡性能测试问题
3.1 连通性测试
3.1.1 服务端启动(LID 模式)
ibping -S -C <设备名> -P <端口号> 示例:ibping -S -C mlx5_0 -P 1
3.1.2 客户端测试(LID 模式)
ibping -c 10000 -f -C <设备名> -P <端口号> -L <服务端LID>示例:ibping -c 10000 -f -C mlx5_0 -P 1 -L 59
3.1.3 预期输出结果
Sent与Received包数一致,Loss%为 0。
3.2 带宽与时延测试
3.2.1 带宽测试
ib_write_bw -a -d mlx5_0 --report_gbits # 单流带宽测试(本地回环)
ib_write_bw -a -F 192.168.30.6 -d mlx5_0 --report_gbits # 跨节点带宽测试(指定对端IP)
3.2.2 时延测试
ib_write_lat -a -d mlx5_0 # 单向时延测试
3.2.3 其他测试
ib_read_bw、ib_send_bw、ib_read_lat、ib_send_lat等等。
四、系统内核与GPU驱动兼容性问题
4.1 内核模块冲突
涉及组件包括Nvidia Gpu driver、CUDA与cudnn、OFED、nvidia-fabricmanager。
4.1.1 问题一:Nvidia的驱动版本和nvidia-fabricmanager的版本不一致
Ubuntu系统可能会自动升级Nvidia驱动版本--apt -y update / upgrade,导致nvidia-fabricmanager版本和Nvidia驱动版本不一致,或者客户升级/关闭了nvidia-fabricmanage,导致无法正常使用多卡训练。
排查指令:
dpkg --list | grep linux-image # 查看可用的内核版本
uname -r # 查看正在使用的内核是否为新内核,若不是新内核则reboot重启系统后默认使用新内核
nvidia-smi # 显示GPU相关信息
nvcc --version # 检查 CUDA 是否正常工作
cat /proc/version | grep CuDNN # 检查 CuDNN 是否正常工作
ibstat # ib卡State为 active 并且 Link Layer 为: InfiniBand 则正常
ibv_devinfo # 检查端口的模式是否为 InfiniBand
systemctl status nvidia-fabricmanager # 验证nvidia-fabricmanager
nvidia-smi topo -m # 显示GPU内外拓扑结构和连接关系
4.1.2 问题二:系统内核与Nvidia驱动、CUDA、cuDNN的版本不一致
NVIDIA GPU驱动支持的Linux内核版本:https://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html#runfile-nvidia-driver
CUDA支持的Linux内核版本:https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html
cuDNN支持的Linux内核版本:https://docs.nvidia.com/deeplearning/cudnn/latest/
4.1.3 问题三:GPU内存常驻
使用root用户或sudo权限运行以下命令来设置GPU驱动的内存常驻模式:nvidia-smi -pm 1
需要注意的是,启用GPU驱动的内存常驻模式会持续占用系统资源,并增加能耗。因此,在使用完毕后,如果不再需要常驻模式,建议将其禁用,以节省资源和能源。可以使用以下命令将GPU驱动程序设置为非常驻模式:nvidia-smi -pm 0
4.2 内核升级
使用包管理器APT(Advanced Package Tool)进行内核升级是最简单的方法。进行任何系统更改之前,务必备份重要数据和配置文件,以防意外发生。
查看当前内核版本:uname -r
升级步骤如下:
(1)更新软件包列表,确保软件包列表是最新的:
sudo apt update -y
(2)升级现有软件包:
sudo apt upgrade -y
(3)搜索可用的内核版本:
apt list | grep linux-image #查看可用版本
apt list --installed | grep linux-image #查看已安装版本
(4)安装新内核:
sudo apt install linux-image-<version>
#例如sudo apt install linux-image-5.4.0-159-generic,确保<version>替换为选择的内核版本号
(5)更新引导加载程序:
sudo update-grub
#内核升级后需要更新引导加载程序,以便在启动时可以选择新的内核版本。
(6)重新启动系统: 内核升级完成后,重新启动系统,以使更改生效。
reboot
(7)验证新内核版本
uname -r4.3 内核版本回滚
回滚到旧版本内核的步骤如下:
1、启动时选择旧内核:在系统启动时,通常会显示一个引导菜单,选择要启动的内核版本。这通常是在 GRUB 引导菜单中完成的。在这个菜单中,选择先前的稳定内核版本,而不是新内核。
2、进入系统:选择旧内核后,让系统继续启动。
3、卸载新内核:一旦进入系统并确保旧内核能够正常工作,可以卸载新内核。使用以下命令卸载新内核:
#查看已安装的内核版本
dpkg --list | grep linux-image
#查看服务器启动内核的顺序
cat /boot/grub/grub.cfg | grep menu
#(可选)删除新内核
sudo apt remove linux-image-<kernel_version>
#其中 <kernel_version>是要删除的内核版本号。
#例如 sudo apt remove linux-image-5.4.0-159-generic
#修改默认内核版本,改为GRUB_DEFAULT="一级目录>旧内核版本”
sudo gedit /etc/default/grub4、更新引导程序:删除新内核后,更新引导程序以反映这些更改。运行sudo updata-grub命令来更新 GRUB 配置。
5、重新启动系统:完成以上步骤后,重新启动系统以确保引导程序已更新并且系统可以正常引导到旧内核。reboot
6、验证内核版本:运行umane -r命令验证系统是否已回滚到先前的稳定内核版本。
五、gpu-burn 测试完整操作流程
5.1 环境准备
# 安装基础编译工具
yum install -y gcc make git
# 验证CUDA是否正确安装(若系统已显示CUDA 12.4,需确保环境变量配置)
nvcc -V
echo $PATH | grep cuda
echo $LD_LIBRARY_PATH | grep cuda
# 如果提示nvcc未找到,配置CUDA环境变量(临时生效)
export PATH=/usr/local/cuda-12.4/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda-12.4/lib64:$LD_LIBRARY_PATH
# 永久生效可将上述两行添加到 /etc/profile 或 ~/.bashrc5.2 下载并编译 gpu-burn
# 克隆gpu-burn源码
git clone https://github.com/wilicc/gpu-burn.git
cd gpu-burn
# 编译(基于系统CUDA版本自动适配)
make
# 验证编译结果(生成gpu_burn可执行文件)
ls -l gpu_burn5.3 执行 GPU 压力测试
# 测试指令一(测试600秒,详细打印输出)
./gpu_burn -v 600
# 测试指令二(仅测试第0块GPU,持续300秒)
CUDA_VISIBLE_DEVICES=0 ./gpu_burn 300
# 测试指令三(测试第1、3、5块GPU,持续1小时(3600秒))
CUDA_VISIBLE_DEVICES=1,3,5 ./gpu_burn 3600
# 测试期间可新开终端监控 GPU 状态:实时监控GPU使用率、温度、功耗(每2秒刷新一次)
watch -n 2 nvidia-smi
# 或监控关键指标(温度/使用率/功耗)
nvidia-smi --query-gpu=index,temperature.gpu,utilization.gpu,power.draw --format=csv -l 25.4 测试结果验证(以八卡H800为例)
83.0% proc'd: 9240 (42060 Gflop/s) - 11480 (51638 Gflop/s) - 11200 (51623 Gflop/s) - 11200 (51528 Gflop/s) - 11200 (51271 Gflop/s) - 11200 (51632 Gflop/s) - 11200 (51584 Gflop/s) - 9240 (42053 Gflop/s) errors: 0 - 0 - 0 - 0 - 0 - 0 - 0 - 0 temps: 49 C - 60 C - 64 C - 72 C - 74 C - 56 C - 57 C - 40 C
Summary at: Mon Dec 22 16:37:51 CST 2025
。。。
100.0% proc'd: 11200 (42057 Gflop/s) - 13720 (51631 Gflop/s) - 13720 (51630 Gflop/s) - 13720 (51538 Gflop/s) - 13720 (51249 Gflop/s) - 13720 (51639 Gflop/s) - 13720 (51583 Gflop/s) - 11200 (42057 Gflop/s) errors: 0 - 0 - 0 - 0 - 0 - 0 - 0 - 0 temps: 50 C - 60 C - 64 C - 72 C - 75 C - 57 C - 57 C - 40 C
。。。
Tested 8 GPUs:
GPU 0: OK
GPU 1: OK
GPU 2: OK
GPU 3: OK
GPU 4: OK
GPU 5: OK
GPU 6: OK
GPU 7: OK