Inter-GPU Communication Technology

March 2025

优化的GPU间通信

GPU间的通信可以分为节点间通信（Inter Node Communication）和节点内通信（Intra Node Communication）。

节点内通信 (Intra Node Communication):
- 共享内存 (Shared Mem)
- PCIe
- NVLink/NVSwitch
节点间通信 (Inter Node Communication):
- TCP/IP
- RDMA

上图展示了系统内部和系统之间的通信方式。在系统内部，GPU间通过共享内存、PCI或NVLink进行通信。系统间的通信则通过套接字（Sockets）、InfiniBand或其他插件进行。底层通信方式包括NVLink、PCI、共享内存、套接字、InfiniBand及其他网络。

NVIDIA GPUDirect

GPUDirect技术旨在为需要GPU与其他设备之间进行快速数据传输的HPC（高性能计算）及其他应用提供支持。

GPUDirect是NVIDIA Magnum IO的组件之一。
它为GPU与网络接口和/或NVMe存储之间的数据传输提供了一条更短的路径。
通过使用GPUDirect，多个GPU、第三方网络适配器、固态硬盘（SSD）和其他设备可以直接读写GPU设备内存。
不再需要在主机内存中为适配器维护已分配内存空间的副本，从而释放了系统内存并大大降低了延迟。
其结果是显著提升了运行在NVIDIA GPU上的应用程序的数据传输性能。

NVIDIA GPUDirect 产品系列

GPUDirect 产品系列是 Magnum IO 的一部分，其产品结构如下：

GPUDirect Peer to Peer (P2P): 实现GPU到GPU的拷贝，以及通过内存结构（PCIe, NVLink）直接进行加载和存储操作。
GPUDirect for Video: 针对基于帧的设备优化了传输管线，高效地将视频帧传入和传出NVIDIA GPU内存。
GPUDirect Storage: 提供本地或远程存储（如NVMe或NVMe-oF）与GPU内存之间的直接数据路径。
GPUDirect RDMA: 实现远程系统中NVIDIA GPU之间的直接通信。

时间线

GPUDirect技术的发展历程及其在不同CUDA版本中的支持情况：

2010年 (支持CUDA 3.1+) - 加速通信 (Accelerated Communication): GPUDirect支持通过共享固定内存（pinned host memory）在第三方PCI Express网络和存储设备之间进行加速通信。
2011年 (支持CUDA 4.0+) - 对等网络 (Peer to Peer, P2P): GPUDirect P2P增加了在同一PCI Express根端口上的GPU之间直接加载、存储和访问数据传输的功能。
2012年 (支持CUDA 5.0+) - RDMA: GPUDirect远程直接内存访问（RDMA）使第三方PCI Express设备能够绕过CPU主机内存直接访问GPU，用于节点间通信。
2016年 (支持CUDA 8.0+) - 异步 (Async): GPUDirect Async允许GPU与第三方设备之间进行直接同步。例如，它允许NVIDIA GPU在无需GPU干预的情况下，直接等待并轮询排队到网络适配器的通信操作完成。
2020年 (支持CUDA 10.0+) - RDMA与存储 (Storage): GPUDirect RDMA在Jetson Xavier平台上得到支持，并驱动基于AGX Xavier Linux的平台。GPUDirect Storage与存储合作伙伴合作发布。
2022年 (支持CUDA 12.0+) - 异步 (Async): InfiniBand GPUDirect Async (IBGDA) 使用GPUDirect Async-kernel-initiated (Async-KI) 来实现GPU SM与NIC IBGDA的直接交互，GPU和NIC直接交换通信所需的必要信息。

理解GPUDirect的工作原理

GPU之间的数据传输（无加速通信）

在没有加速通信的情况下，DGX A100系统中的数据传输路径如下：
1. 数据从GPU传输到系统内存中的CUDA驱动程序缓冲区。
2. 数据被复制到网卡缓冲区。
3. 数据被传输出去到另一个节点。

GPUDirect：采用加速通信的数据传输

使用GPUDirect后，数据传输路径得到优化：
* 无需将数据复制到系统内存中。
* 数据直接从GPU内存传输到另一台服务器。网络接口卡需要位于同一个根集线器（root hub）上。

GPUDirect Peer to Peer (P2P)

GPUDirect P2P 实现了GPU之间的直接传输。

GPUDirect Transfer: 数据直接传输到另一个GPU的内存中。
GPUDirect Access: 如果GPU位于相同的PCIe域（通过PCIe进行P2P）或存在NVLink路径（通过NVLink/NVSwitch进行P2P），则对等GPU可以相互直接访问和传输数据。
计算延迟最小化。
无需CPU参与驱动中继数据（staging data）。
消除了PCIe拓扑中的瓶颈。
与NVLink或PCI Express兼容（此示例中显示了NVLink）。

RDMA提升吞吐量并降低延迟

RDMA（远程直接内存访问）通过直接向应用程序内存或从应用程序内存传输数据来提升性能。下图对比了传统的TCP/IP通信和RDMA over InfiniBand的路径。TCP/IP需要在用户空间、内核空间和硬件之间进行多次数据拷贝，而RDMA绕过了内核，显著减少了开销。

NVIDIA GPUDirect RDMA

GPUDirect RDMA 可带来高达10倍的性能提升。

下图对比了有无GPUDirect时网络数据处理的差异：
* 无GPUDirect: 网络由CPU和CPU内存处理。这需要 2 次完整的拷贝操作和 2 次PCIe事务。
* 使用GPUDirect: 网络直接与GPU内存交互。这需要 0 次完整的拷贝操作和 1 次PCIe事务。

使用GPUDirect RDMA可以降低GPU利用率、CPU使用率和延迟。

附加资源

NVLINK 和 NVSwitch

NVLINK

NVLink是一种高速互联技术，其大规模性能随架构发布而不断提升。

上图展示了从2014年到2024年NVLink技术的发展：
* P100: 第1代 NVLink
* V100: 第2代 NVLink
* A100: 第3代 NVLink
* H200: 第4代 NVLink
* GB200: 第5代 NVLink
其带宽（GB/sec）呈阶梯式显著增长。

NVSWITCH

NVSwitch 通过扩展NVLink连接，实现了更大规模的GPU集群。

规格参数表摘要:

特性	第一代	第二代	第三代	NVLink Switch
NVLink域内直接连接的GPU数量	最多8个	最多8个	最多8个	最多576个
NVSwitch GPU-to-GPU带宽	300GB/s	600GB/s	900GB/s	1,800GB/s
总聚合带宽	2.4TB/s	4.8TB/s	7.2TB/s	IPB/s
支持的NVIDIA架构	Volta™	Ampere	Hopper™	Blackwell

NVSwitch对于多GPU推理至关重要

对于大模型、长上下文长度或低延迟的场景，多GPU是必需的。

下图对比了传统的Mesh拓扑和使用NVSwitch的拓扑结构。在8-GPU配置下，Mesh拓扑通过点对点连接，带宽受限于直连链路（0.2 TB/s）。而NVSwitch提供了一个全连接的网络，使得每个GPU都能以极高的带宽（3.6 TB/s）与其他所有GPU通信。

每GPU带宽对比：

带宽类型	Mesh	NVSWITCH
2-way Bandwidth	0.2 TB/s	3.6 TB/s
4-way Bandwidth	0.6 TB/s	3.6 TB/s
8-way Bandwidth	1.4 TB/s	3.6 TB/s

对LLAMA3推理性能的影响（32k输入，20 tok/sec）：

Mesh：通信时间（Comm. Time）占用了总时间的50%。
NVSWITCH：通信时间几乎可以忽略不计，绝大部分时间用于计算（Compute Time）。

这表明NVSwitch能够显著降低多GPU推理中的通信瓶颈。

NCCL：加速的多GPU集合通信

Page 17: NCCL Logo

NCCL（NVIDIA Collective Communication Library）是一个在GPU上运行的、针对GPU缓冲区的通信库，旨在优化GPU之间的通信。

它支持多种物理连接方式：
- 节点内通信：NVLink, PCI, 共享内存（Shared memory）。
- 节点间通信：Sockets, InfiniBand, 以及其他网络。

相关资源链接：
- 二进制文件: https://developer.nvidia.com/nccl and in NGC containers
- 源代码: https://github.com/nvidia/nccl
- 性能测试: https://github.com/nvidia/nccl-tests

NCCL在深度学习栈中的位置

NCCL是深度学习软件栈中的一个关键组件，位于深度学习框架（如TensorFlow, PyTorch）之下，与CUDNN、CUBLAS等库处于同一层级，共同调用CUDA API来驱动NVIDIA GPU。

NCCL 架构

NCCL为所有平台提供优化的CUDA核心（Kernels），其架构主要包含四个步骤：

拓扑检测 (Topology detection)：构建一个包含所有GPU、网卡（NIC）、CPU、PCI交换机、NVLink和NVSwitch的系统拓扑图。支持为虚拟机（VMs）进行拓扑注入。
图搜索 (Graph search)：进行广泛搜索，以找到最优的环形（rings）或树形（trees）通信路径。该过程包含对每种算法的性能预测和自动调优。
图连接 (Graph connect)：连接跨节点的图。通过PCI、NVLink、GPU DirectRDMA等技术，使用中间先进先出队列（FIFOs）来连接GPU。
CUDA核心 (CUDA Kernels)：执行优化的归约（reductions）和拷贝（copies）操作，以最小化流式多处理器（SM）的使用。同时利用CPU线程进行网络通信。

拓扑检测详解

NCCL的拓扑检测功能为所有平台提供广泛支持，它通过多种来源收集信息来构建精确的系统拓扑图：

CPU架构和供应商: 通过cpuid/arch获取。
PCI拓扑、速度和CPU亲和性: 通过/sys文件系统获取。
NVLink: 通过NVML（NVIDIA Management Library）获取。
InfiniBand (IB): 通过IB Verbs获取IB速度、多端口、socket-direct等信息。
虚拟机拓扑: 从云Hypervisor提供的XML文件（NCCL_TOPO_FILE）中获取。

NCCL能够识别并优化多种硬件配置，例如标准的PCI连接、DGX-1、DGX-2和DGX A100系统。

集合通信 (Collective Communication)

集合通信指的是涉及多个发送者和/或接收者的通信模式。NCCL实现了多种高效的集合通信原语。

以下是几种核心的集合通信操作：

Broadcast (广播)

一个发送者，多个接收者。单个GPU上的数据被复制到所有其他GPU。

Scatter (分散)

一个发送者，数据被分发给多个接收者。发送者GPU上的数据被分割成块，每个接收者GPU接收其中一块。

Gather (收集)

多个发送者，一个接收者。多个GPU上的数据块被收集到一个目标GPU上。

All-Gather (全局收集)

从所有参与者那里收集消息，并将收集到的完整数据分发给所有参与者。每个GPU都将拥有所有其他GPU的数据。

Reduce (归约)

合并来自所有发送者的数据，并将结果传递给一个接收者。通常执行的操作是求和、求最大值等。

All-Reduce (全局归约)

合并来自所有发送者的数据，并将结果传递给所有参与者。这是分布式训练中最常见的操作之一，例如用于同步梯度。

Reduce-Scatter (归约-分散)

合并来自所有发送者的数据，并将结果分布到各个参与者。它先对数据进行归约操作，然后将归约后的结果分散给不同的GPU。

All-to-All (全局交换)

从每个参与者向所有其他参与者分发/收集不同的消息。该操作相当于对分布式数据进行矩阵转置。

环形算法 (Ring Algorithm)

DGX 上的多环（Multi-rings）拓扑结构。下图展示了多个 DGX 节点如何通过多个环形网络连接，以实现高效的 All-Reduce 通信。

节点间通信 (Inter-node communication)

面向高速链路优化的设计 (Rail-optimized design)

下图对比了传统的网络结构设计与面向高速链路优化的设计。

经典网络结构设计 (Classic fabric design)：路由必须完美，以确保所有数据流使用不同的链路。
面向高速链路优化的设计 (Rail-optimized design)：所有流量均本地化到叶节点交换机（leaf switches），因此不可能发生路由冲突。

Page 32: 对比经典网络结构设计与面向高速链路优化的设计，后者通过流量本地化避免路由冲突。

最佳实践 - 监控与故障总结

NVIDIA 监控套件 (NVIDIA Monitoring Suite)

GPU 和 InfiniBand 监控

SMBPBI
- 提供带外（out-of-band）解决方案，用于监控和管理 NVIDIA GPU。
- 无需接触主机 CPU 系统。
- 监控能力：
- NVLINK 信息，状态，错误计数。
- GPU 速度，错误计数。
- 图形和内存时钟。
- 限制，违规时间。

电源：
- 电源供应状态，限制。
- 功耗，策略违规时间。
能量查询。
温度。
GPU 利用率：
- gouUtil, memUtil, encUtil, decUtil。
GPU 和内存时钟：
- 当前，最小值，最大值。
PCIe：
- 链路状态和错误计数。
ECC/页面重映射：
- ECC 模式，ecc 统计，页面重映射计数。
事件警报。
热点事件。

DCGM-exporter
- NVIDIA 数据中心 GPU 监控工具。
- 开销比 NVML 小。
- 利用 NVIDIA DCGM 为 Prometheus 导出 GPU 指标。
- 关键指标：
- 时钟：DCGM_FI_DEV_SM_CLOCK, DCGM_FI_DEV_MEM_CLOCK
- 温度：DCGM_FI_DEV_GPU_TEMP, DCGM_FI_DEV_MEMORY_TEMP
- 功耗：DCGM_FI_DEV_POWER_USAGE, DCGM_FI_DEV_TOTAL_ENERGY_CONSUMPTION
- PCIe：DCGM_FI_PROF_PCIE_TX_BYTES, DCGM_FI_PROF_PCIE_RX_BYTES
- 内存：DCGM_FI_DEV_MEM_COPY_UTIL, DCGM_FI_DEV_FB_FREE, DCGM_FI_DEV_FB_USED
- XID 错误和违规：DCGM_FI_DEV_XID_ERRORS, DCGM_FI_DEV_POWER_VIOLATION
- 可靠性：DCGM_FI_DEV_RETIRED_DBE, DCGM_FI_DEV_ECC_SBE_VOL_TOTAL, DCGM_FI_DEV_ECC_DBE_VOL_TOTAL, DCGM_FI_DEV_RETIRED_SBE, DCGM_FI_DEV_RETIRED_DBE
- NVLINK：DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL, DCGM_FI_DEV_NVLINK_REPLAY_ERROR_COUNT_TOTAL
- 引擎：DCGM_FI_PROF_GR_ENGINE_ACTIVE, DCGM_FI_PROF_SM_ACTIVE

GPU 额外检查

驱动：lsmod | grep nvidia
lsmod | grep nvidia_peermem
nvswitch
nvidia-fabricmanager.service
GPU 挂起：nvidia-smi 中的 'd' 状态。
应用进程卡死：#nvidia-smi -I +sguild, #ps -o pid,state,pcpu,cmd SPID
监控更多 DCGM/NVML 无法检测到的 GPU 异常（例如 XID 62）。然而，几乎所有的 GPU 错误都会在 dmesg 日志中报告。所以监控 dmesg 日志是被推荐的。
Systemlogmonitor from Node-Problem-Detector 是一个很好的 dmesg 监控程序，支持 Prometheus。

UFM Grafana InfiniBand Telemetry
- 提供一个新的 UFM telemetry Prometheus 端点，带有易于阅读的标签。
- 实时网络监控。
- 支持的指标：
- 端口流量计数器：PortXmitDataExtended, PortRcvDataExtended, PortXmitPktsExtended, PortRcvPktsExtended
- 错误计数器：SymbolErrorCounter, LinkErrorRecoveryExtended, LinkDownedExtended, PortRcvErrorsExtended, PortRcvRemotePhysicalErrorsExtended, PortRcvSwitchRelayErrorsExtended, PortXmitDiscardsExtended, PortXmitConstraintErrorsExtended, PortRcvConstraintErrorsExtended, LocalLinkIntegrityErrorsExtended, ExcessiveBufferOverrunErrorsExtended, VL15DroppedExtended, PortXmitWaitExtended
- 计数器描述：13-Infiniband Counters.pdf

典型问题-1

NVLink/NVSwitch 问题

已知问题:
- NVSwitch Sxids
- NVLink 故障
- NVLink 总线错误
建议:
- 清空所有作业 (Drain all the jobs)
- 重置设备 (Reset the device)
- 重置整个 NVLink fabric (Reset the complete NVLink fabric)
- 重启系统 (Reboot the system)
- 运行现场诊断 (Field Diags) 以理解错误

驱动相关问题

已知问题:
- Xid 61/62/119/120
- 'nvidia-smi' 挂起问题
- 内核崩溃问题
- 在 nvidia-smi 中 GPU 丢失，伴随内核日志中 RmlnitAdapter 错误
- 在 NS 状态下，使用 NVLINK P2P 性能不佳
- nvidia-peermem UAF (use-after-free) 问题
建议:
- 完整列出用于关键信息的日志，包括 dmesg 和内核消息日志
- 输出 nvidia-bug-report.sh
- 如果是未知问题，发送捕获的日志给 NV SA 进行分析

性能问题

已知问题:
- GPU 时钟下降
- 在启用 VF 或虚拟机中，NCCL 检测到错误的硬件拓扑
- 在裸金属平台上启用 IOMMU/ACS
- GDR 级别设置为 SYS
- TCP 连接数超过系统限制
建议:
- 设置 NCCL_DEBUG 为 "WARN" 将使 NCCL 在返回错误前打印明确的警告消息
- 检查 ACS/IOMMU 配置
- 检查 nvidia-peermem 服务
- 检查 RoCE/IB 最佳配置
- 在单节点上运行 allreduce 测试
- 在多节点上运行 allreduce 测试

GPU 其他问题

已知问题:
- GPU SDC (静默数据损坏, Silent Data Corruption)
- LLM SDC (NaN 问题)
建议:
- 缩小范围到一个节点或一个 GPU 来运行应用
- 运行 dcgm diag -r 3
- 运行 dcgm diag --eud
- 如果仍然无法检测到此类 SDC 问题，报告 Nvbug
- TinyMegv2: 应用级检查，检查多轮运行的损失/梯度一致性
- 截至目前，只有 DCGM EUD 和 TinyMeg2 可以识别 NaN 问题

典型问题-2

GPU 丢失 (GPU LOSS)

已知问题:
- 基板已知 bug (永久性丢失)
- FPGA 固件已知 bug (间歇性丢失)
- GPU 过热
- XID 62
- 未知问题：正在调试中
建议:
- 升级 Delta FW 至 22.05 或更高版本
- 通过 BMC 限制 GPU 温度
- 使用最新的 470 驱动

ECC

已知问题:
- GPU UCE (不可纠正错误) 将终止正在运行的作业
建议:
- ECC 错误是硬件内存错误，Tesla GPU 可以恢复，理解 ECC 并进行监控。
- XID 48 – 重置并重新启动
- XID 94 – 重新启动
- XID 95 – 重置并重新启动
- SRAM UCE > 0
- 重映射失败：已发生
注意:
- V100: 动态页面退休 (Dynamic Page Retirement)
- A100: 行重映射 (Row remapping)

作业挂起 (JOB HANG)

已知问题:
- 启动时挂起
- 裸金属 ACS/IOMMU 关闭
- 运行时挂起
- XID 79/74/UCE/61/62
- 驱动死锁
- 主动退出挂起状态
- Pytorch: 设置超时时间
- NCCL API: NcclCommGetAsyncError, NcclCommAbort
建议:
- 预启动配置检查
- 监控日志更新以检测运行时的挂起
- XID 74/61/62 – 升级驱动至最新的 470 版本
- 监控 XID79/UCE 故障，替换健康节点并重新启动

网络 (NETWORK)

已知问题:
- 链路抖动 (Link flapping)
- 运行 tcpdump 导致的性能抖动
建议:
- 升级 NIC FW 至 28.35.4030 或更高版本
- 升级 NIC 驱动至 NVIDIA DOCA v2.8.0 或更高版本
- 监控 NIC 端口状态和网络流量