推荐语

深入解析GPU互联技术如何提升大模型训练效率，来自一线专家的实战经验分享。

核心内容：
1. 主流GPU网络互联技术（PCIe/NVLink等）的架构特点与性能对比
2. 不同大模型训练场景下的技术选型策略
3. 基于实测数据的性能评估方法与优化建议

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

文章目录

一、引言

二、大模型对 GPU 互联的需求

三、 GPU 主流网络互联技术

（一）PCIe

（二）NVLink

（三）NV-SLI

（四）NVSwitch

（五）GPUDirect

（六）Infiniband

（七）RoCE

（八）iWARP

四、 性能评估

（一）评估指标

（二）评估方法

（三）主要基准测试工具说明及实践

（四）性能评估结果

五、 技术选型建议

六、未来趋势展望

七、总结

一、引言

在人工智能飞速发展的当下，大模型已成为推动诸多领域进步的关键力量。以 GPT-4 为代表，其拥有高达 1.8 万亿的参数，如此庞大的模型规模对计算能力提出了近乎苛刻的要求。单块 GPU 由于计算能力和显存的限制，远远无法满足大模型训练与推理的需求。因此，将多块 GPU 进行高效互联，构建强大的计算集群成为必然选择。在这样的背景下，GPU 主流网络互联技术的优劣直接影响着大模型运行的效率与性能，对其深入研究和精准评估具有重要的现实意义。

二、大模型对 GPU 互联的需求

大模型训练过程涉及海量数据的处理与复杂的运算，数据并行（DP）、流水线并行（PP）、张量并行（TP）和专家并行（EP）等多种并行策略被广泛应用。不同的并行策略对 GPU 互联网络有着不同的要求。

图一、GPU上现有的LLM并行策略

如图，是GPU上现有的大语言模型的常见的并行策略，底层是依赖于GPU及算力网络的。例如，数据并行主要关注数据在不同 GPU 之间的分发与聚合，需要网络具备较高的带宽以保障数据传输的高效性；张量并行则对网络延迟极为敏感，因为它涉及到模型中张量在多个 GPU 间的同步计算，低延迟的网络能够减少计算等待时间，提升整体计算效率。随着模型规模的持续扩张，从最初的百亿级参数迈向如今的万亿级参数，GPU 集群的规模也在不断增大，从几十卡发展到数千卡甚至万卡规模。这使得 GPU 互联网络不仅要满足高带宽、低延迟的要求，还需具备良好的可扩展性，以适应不断增长的计算需求。

三、GPU 主流网络互联技术

为应对大模型在并行策略、带宽、延迟与可扩展性上的严苛诉求，业界先后推出多种 GPU 互联技术，从板级总线到芯片级交换、从节点内高速链路到跨节点 RDMA 网络，层层递进、互为补充。下文按演进顺序逐一剖析这些技术的架构特点、性能边界与适用场景。

（一）PCIe

PCIe（Peripheral Component Interconnect Express）作为一种传统的高速串行计算机扩展总线标准，在早期的 GPU 连接中应用广泛，常用于 GPU 与 CPU 之间的连接。它采用端对端的数据传输链路，链路两端各接入一个设备。

图二、GPU与CPU间通过 PCIe交换机进行硬件互联

如图，在 DGX-1 系统中，多个 GPU 通过 PCIe 交换机连接CPU形成平衡的树状结构。然而，随着 GPU 计算需求的不断提升，PCIe 的局限性愈发明显。与 CPU 和 DRAM 之间的互连相比，PCIe 速度较慢，成为 GPU 加速的性能瓶颈。在多 GPU 系统中，当 GPU 数量增多时，PCIe 容易出现带宽竞争的情况，导致数据传输延迟增加。以 PCIe 3.0 为例，其 16 通道的带宽为 32GB/s，在面对大模型训练中大量数据的高速传输需求时，显得捉襟见肘。尽管 PCIe 不断升级，到 PCIe 6.0 时传输速率高达 64GT/s，16 通道带宽达到 256GB/s，但在 GPU 多卡通信场景下，其效率仍难以满足需求。特别是在 GPU 进行并行计算时，PCIe 链路接口的串并转换会产生网络延时，并且 GPU 发出的信号需先传递到 PCIe Switch，PCIe Switch 的数据处理又会造成额外延时，再加上 PCIe 总线与存储器地址分离，每次访问内存都会加重网络延迟，这些因素综合起来严重影响了 GPU 并行计算的效率。在一些早期搭建的科研计算平台中，使用 PCIe 互联多块 GPU 训练中型图像识别模型时，就因带宽限制和延迟问题，导致训练周期比预期延长了 30%。

（二）NVLink

NVLink是英伟达推出的专门用于解决传统 PCIe 互连性能瓶颈的高速 GPU 互连技术。它通过提供更高的带宽和更低的延迟，极大地提升了 GPU 之间的通信效率。它采用基于高速信号互连（NVHS）的有线接口，支持 P2P 通信，允许 GPU 直接读写远程 CPU 的主机内存或对等 GPU 的设备内存。其每个链路包含两个子链路，每个子链路又包含八个差分 NVHS 通道，通信效率与数据包大小密切相关，相比 PCIe，其通信效率可提升约两倍。

NVLink 有多个版本，NVLink-V1 作为第一代技术，每个 Pascal P100 GPU 配备四个 NVLink 插槽，可实现 4 倍的单链路带宽。NVLink-V2 是第二代技术，每个 Volta V100 GPU 配备六个 NVLink 插槽，链路带宽提升了 25%，并引入了低功耗运行模式，同时通过增加链路插槽数量，改变了原始网络拓扑结构，在 V100 DGX-1 中形成了快速的骨干环，有效提高了集体通信的效率。

图三、P100-DGX-1和V100-DGX-1的PCIe以及NVLink-V1/V2拓扑结构

如图，是英伟达 DGX-1 系统的两种架构图，展示不同 GPU（P100、V100）搭配不同版本 NVLink 时的连接拓扑。图A，基于 P100 的DGX-1 GPU ，用 NVLink-V1 ，通过 QPI、PCI-e、NVLink 来连接 CPU（C0、C1 ）、GPU（G0 - G7 ）等计算单元。图B，则基于 V100的DGX-1 GPU ，红色加粗 NVLink 体现用 NVLink-V2 连接强化。通过图A及B，可以看出不同硬件组合下DGX-1 系统内部互连设计差异、演进与性能优化逻辑。

到了第五代 NVLink，单个 NVIDIA Blackwell Tensor Core GPU 可支持多达 18 条 NVLink 100GB/s 的连接，总带宽可达 1.8TB/s，与上一代相比带宽翻倍，且超过 PCIe Gen5 带宽的 14 倍以上。像 GB200 NVL72 这样的服务器平台正是利用这项技术，为复杂大型模型提供了更强的可扩展性。例如，在 OpenAI 训练 GPT 系列模型时，基于 NVLink 构建的 GPU 集群，使得多卡之间数据传输效率大幅提升，训练时间显著缩短，助力其快速迭代出更强大的语言模型。

（三）NV-SLI

NV-SLI（Scalable Link Interface）最初是一种用于图形目的的多 GPU 桥接技术。随着英伟达 Turing 架构 GPU 的推出，基于 NVLink-V2 互连技术，NV-SLI 演变成一种新的高速多 GPU 桥接技术。它将两个 GPU 配对，使它们能够相互通信，可共同渲染游戏、运行 GPGPU 任务或共享 GPU 内存空间。不过，需要注意的是，Turing 架构 GPU 仅支持双向 NVLink-SLI，这在一定程度上限制了其应用场景的拓展，相较于其他更具扩展性的互联技术，在大规模 GPU 集群构建方面存在一定的局限性。在一些游戏开发工作室中，使用 NV-SLI 技术配对两块 RTX 2080 GPU，用于实时渲染高分辨率游戏场景，利用其带宽优势实现了流畅的画面渲染，但在处理大规模的游戏 AI 模型训练时，因扩展性不足难以满足需求，本文不展开介绍。

（四）NVSwitch

NVSwitch 是针对新兴应用中的全对全(all-to-all)通信问题推出的基于 NVLink-V2 的交换芯片技术。

图四、Nvidia DGX-2基于NVLink-V2及PCIe3.0的网络拓扑结构

如图，每个 NVSwitch 拥有 18 个 NVLink 端口，能够实现高达 2.4TB/s 的原始双向带宽。它通过两个基板实现，每个基板包含 6 个 NVSwitch，托管 8 个 GPU。每个 GPU 可以同时连接到 6 个 NVSwitch，每个链路的双向带宽为 50GB/s。这种网络拓扑结构使得任何 GPU 都可以与其他 GPU 进行全互联通信，无论是单个基板内还是两个基板之间的通信，都具备高带宽和低延迟的特点，为大模型训练中多 GPU 之间复杂的数据交互提供了高效的解决方案，有效避免了传统网络拓扑中可能出现的通信瓶颈问题。例如，某国家级人工智能实验室在训练超大规模的多模态模型时，采用基于 NVSwitch 的 DGX-2 服务器集群，实现了数千块 GPU 之间的高效通信，大幅提升了模型训练效率，使原本需要数月的训练周期缩短至数周。

（五）GPUDirect

GPUDirect 是推出的一项重要技术，它允许第三方 PCIe 设备（尤其是 InfiniBand 主机通道适配器 HCA）直接访问 GPU 设备内存，而无需 CPU 协助或通过主内存进行数据传输。这一特性显著提高了节点间 GPU 通信的效率，因为它减少了 CPU 的负担，并且能够实现更快速的数据传输。

GPUDirect 通过 GPU 供应商提供的操作系统内核扩展，返回 GPU 设备内存的直接内存访问（DMA）总线映射。这意味着，当用户创建 InfiniBand 区域时，InfiniBand 驱动程序会调用相关例程获取 DMA 映射，最终将正常的 InfiniBand 虚拟内存结构返回给用户程序。这样，用户程序就可以像操作正常的 CPU 内存一样，直接对 GPU 设备内存进行操作，从而实现高效的数据传输和处理。

此外，GPUDirect 技术还包括 GPUDirect RDMA（远程直接内存访问），它进一步扩展了 GPUDirect 的功能，允许在不同节点的 GPU 之间直接传输数据，而无需 CPU 的介入。这在高性能计算和数据中心环境中尤其有用，因为它可以显著减少延迟并提高整体系统的性能。

图五、GPUDirect 1.0 vs. GPUDirect RDMA

如图，展示两种GPUDirect传输数据方式，其中GPUDirect 1.0的数据传输需要经过CPU和系统内存中转，路径冗长，导致效率较低。GPUDirect RDMA则允许InfiniBand网卡直接访问GPU内存，绕过CPU和系统内存，实现GPU到GPU的高效、直接传输。

（六）Infiniband

Infiniband（IB) 是专为 RDMA（远程直接内存访问）设计的网络，从硬件级别保证了可靠传输。RDMA是一种允许计算机在不经过CPU干预的情况下直接访问另一台计算机内存的技术，通常用于节点间的通信。它就像连接不同城市的铁路或长途公路，适合长距离、大规模数据的传输，虽然速度可能不如NVLink快，但在跨节点通信中具有高效、稳定的特点。

Infiniband 具备更高的带宽和更低的时延，非常适合高性能计算、大数据分析等对 IO 高并发、低时延要求极高的场景。在大模型训练的分布式系统中，Infiniband 能够为多机之间的互联提供高效的数据传输通道。

图六、GPU机器内互联 vs. 机器间互联

如图，展示了多机 GPU 集群网络架构：机器内（红色）实现 GPU 互连，跨机（蓝色）通过基于InfiniBand的RDMA 通信，经基础网络设备（黑色）连接，支撑分布式并行计算的高速数据交互，比如多机多GPU训练。

在一些大型的数据中心中，采用 Infiniband 网络连接各个计算节点，可实现节点之间数百 GB/s 甚至更高的带宽传输。然而，Infiniband 的缺点也较为明显，其成本较高，不仅需要配备专门的 IB 网卡，还需使用 IB 交换机，这使得整个系统的建设成本大幅增加，在一定程度上限制了其在一些对成本较为敏感的场景中的广泛应用。谷歌在训练大型语言模型时，就采用了 Infiniband 网络构建数据中心集群，尽管成本高昂，但凭借其高带宽和低延迟特性，大幅提升了模型训练速度，助力其在人工智能领域保持领先地位。

（七）RoCE

RoCE（RDMA over Converged Ethernet）是基于以太网实现 RDMA 功能的技术。与 Infiniband 不同，RoCE 可以使用普通的以太网交换机，这大大降低了硬件成本。它通过在以太网上实现 RDMA 协议，使得数据可以直接远程访问内存，无需操作系统内核过多介入，从而不占用 CPU 资源，显著提高数据传输性能并降低延迟。在实际应用中，对于一些对成本较为敏感且对网络性能有一定要求的大模型训练场景，RoCE 成为了一种较为理想的选择。

图七、使用GPU的典型TCP/IP应用程序与使用RoCE RDMA的应用程序之间的区别

如图，对比了两台计算机间传统TCP/IP（蓝色）与 RDMA-RoCE（绿色）的通信流程，前者数据需经CPU、内核缓冲区，依赖CPU处理，开销大。 后者数据则直接在用户缓冲区与NIC间传输，绕过CPU和内核，减少延迟与CPU负载，提升通信效率。RDMA通过网卡直接访问远程内存，实现了用户空间到用户空间的零拷贝传输，而TCP/IP需内核协议栈处理，性能更低。

实际应用上，在一些中小企业构建的智算平台中，采用 RoCE 技术连接多台服务器，既满足了大模型训练对网络性能的基本要求，又有效控制了成本。某初创的自然语言处理公司，使用基于 RoCE 的网络架构搭建 GPU 集群，在训练智能客服对话模型时，以较低成本实现了高效的数据传输，支撑模型快速迭代优化。不过，RoCE 需要支持 RoCE 的网卡，这在一定程度上对硬件选型有一定的限制。

选型方面，在GPU小集群规模内，可以采用IB或者RoCE网络，两者各有优缺点，根据实际的资金和技术积累来选择，而且RoCE网络内端到端尽量控制在3-5跳以内。对于超过万卡GPU的大集群规模，则IB网络比较稳妥，采用RoCE则需要相对投入更大量的人力和物力。

（八）iWARP

iWARP 是基于 TCP 的 RDMA 网络，它利用 TCP 协议来达到可靠传输的目的。与 RoCE 类似，iWARP 可以使用普通的以太网交换机，但需要支持 iWARP 的网卡。在大型组网情况下，iWARP 的大量 TCP 连接会占用大量的内存资源，对系统规格要求较高。相比 RoCE，iWARP 在性能上可能稍逊一筹，但其在一些对网络可靠性要求较高且对内存资源不太敏感的场景中仍有应用。

图八、iWRP 的复杂网络层 VS. RoCE的简单网络层

如图，差异就在红包框图部分，可以看出 RoCE 以“简化协议栈 + UDP”实现更高效的 RDMA 传输，而 iWARP 因“多层 TCP 封装”复杂度更高。这种设计差异直接影响两者的性能，即RoCE 更侧重低延迟，iWARP 兼容现有 TCP/IP 生态。

应用场景方面，在一些对数据传输准确性要求极高的金融领域相关的大模型训练场景中，iWARP 可凭借其基于 TCP 协议的可靠传输特性，保障数据传输的正确性，但同时需要注意合理配置系统内存资源以应对大量 TCP 连接带来的压力。某银行在训练用于风险评估的金融大模型时，采用 iWARP 技术构建网络，确保了数据在传输过程中的准确性和完整性，为模型的可靠运行提供了保障。

四、性能评估

在深入剖析了多种 GPU 主流网络互联技术的架构特点、演进历程与适用场景后，接下来的关键一步是对其性能展开全面且精准的评估。毕竟，技术的优劣最终需通过实际表现来验证，尤其是在大模型训练这种对效率和性能要求极高的场景中。性能评估将围绕带宽、延迟、通信效率、可扩展性及容错性等核心指标展开，借助专业的基准测试工具与实际大模型训练任务，量化分析各互联技术在不同场景下的表现，为技术选型提供科学依据。

（一）评估指标

带宽：指单位时间内能够传输的数据量，是衡量 GPU 互联网络性能的关键指标之一。在大模型训练中，高带宽能够确保数据在 GPU 之间快速传输，减少数据等待时间，提高训练效率。例如，在数据并行策略中，大量的数据需要在不同 GPU 之间分发与聚合，高带宽的网络能够使这一过程更加高效。

延迟：即数据从发送端到接收端所经历的时间。对于张量并行等对同步性要求较高的并行策略，低延迟的网络至关重要。低延迟可以减少 GPU 之间的计算等待时间，提升整体计算效率，避免因延迟过高导致的计算资源浪费。

通信效率：反映了网络在传输数据时的有效利用率，与数据包大小、传输协议等因素有关。高效的通信效率意味着在相同的带宽条件下，能够传输更多的有效数据，减少传输过程中的开销。

可扩展性：随着大模型规模的不断扩大以及 GPU 集群规模的增加，互联网络需要具备良好的可扩展性，能够方便地增加节点数量，且不会因规模扩大而导致性能大幅下降。例如，在从几百卡规模的 GPU 集群扩展到数千卡甚至万卡规模时，网络仍能保持稳定的性能。

容错性：在大规模的 GPU 集群中，难免会出现个别节点或链路故障的情况。良好的容错性意味着网络能够在出现故障时，快速进行故障隔离和数据重路由，保证整个系统的正常运行，尽量减少故障对训练任务的影响。

（二）评估方法

使用专门的基准测试工具：如 Tartan Benchmark Suite，它可以对多种 GPU 互联技术进行全面测试。通过模拟不同的应用场景和数据传输模式，测量出各项性能指标。例如，在测试带宽时，该工具会向 GPU 互联网络发送大量不同大小的数据包，记录单位时间内成功传输的数据量，从而得出准确的带宽数值。在测试延迟时，它会精确测量数据包从发送到接收的时间差，多次测量取平均值以得到较为准确的延迟数据。

基于实际大模型训练任务进行评估：选取具有代表性的大模型，如 GPT-4、Llama 等，在不同的 GPU 互联网络环境下进行训练。通过对比训练过程中的各项性能指标，如训练时间、收敛速度、模型准确率等，来综合评估互联网络对大模型训练的实际影响。例如，在相同的训练数据集和训练参数下，使用 NVLink 互联的 GPU 集群与使用 PCIe 互联的集群相比，训练时间可能会大幅缩短，这直观地体现了 NVLink 在大模型训练中的优势。

模拟故障场景测试容错性：人为制造节点故障或链路故障，观察 GPU 互联网络的反应。例如，在一个基于 NVSwitch 的 GPU 集群中，突然关闭某个节点的电源，观察网络是否能够快速检测到故障，并将数据流量重新路由到其他正常节点，同时监测训练任务是否能够继续正常进行，以及性能下降的程度，以此来评估网络的容错性能。

下面总结了在不同的评估维度上，所采用的一些通用的方法与工具。对于这些工具，给出了可能的关键参数或测试场景，通过不同的输出指标来反映评估性能。

表一、各维度下的性能评估工具与方法

（三）主要基准测试工具说明及实践

1、 Tartan Benchmark Suite，可模拟数据并行、模型并行、流水线并行等不同策略下的通信负载，精准测量带宽、延迟及通信效率。支持自定义数据包大小（范围 1KB-1GB），能有效检测网络拥塞临界点，为评估网络在不同负载下的表现提供数据支撑。

import numpy as npfrom mpi4py import MPIimport timeimport argparse# 初始化MPI环境comm = MPI.COMM_WORLDrank = comm.Get_rank()size = comm.Get_size()def simulate_communication(data_size, parallel_strategy):    """模拟不同并行策略的通信负载"""    # 创建自定义数据包（1KB-1GB范围）    data = np.random.bytes(data_size)    start_time = time.time()
    if parallel_strategy == "data_parallel":        # 数据并行：广播操作        comm.Bcast(data, root=0)        operation = "Bcast"
    elif parallel_strategy == "model_parallel":        # 模型并行：点对点通信        target = (rank + 1) % size        comm.Send(data, dest=target)        comm.Recv(data, source=(rank - 1) % size)        operation = "P2P"
    elif parallel_strategy == "pipeline":        # 流水线并行：环形通信        if rank == 0:            comm.Send(data, dest=1)        else:            comm.Recv(data, source=rank-1)            if rank < size - 1:                comm.Send(data, dest=rank+1)        operation = "Pipeline"
    end_time = time.time()    latency = end_time - start_time    bandwidth = data_size / latency / 1e9  # 转换为GB/s    return latency, bandwidth, operationdef detect_congestion(max_size=2**30, step=2**20):    """检测网络拥塞临界点"""    results = []    for size in range(2**10, max_size, step):  # 1KB到1GB范围扫描        _, bandwidth, _ = simulate_communication(size, "data_parallel")        results.append((size, bandwidth))
        # 拥塞检测：带宽下降超过10%视为临界点        if len(results) > 1 and results[-1][1] < 0.9 * results[-2][1]:            return results[-2][0]  # 返回临界点数据包大小    return max_sizeif __name__ == "__main__":    parser = argparse.ArgumentParser(description='Tartan Benchmark Suite Simulator')    parser.add_argument('--strategy', type=str, choices=['data_parallel', 'model_parallel', 'pipeline'], default='data_parallel', help='并行策略选择')    parser.add_argument('--size', type=int, default=1048576, help='数据包大小(bytes)')    args = parser.parse_args()    # 执行通信测试    latency, bandwidth, op = simulate_communication(args.size, args.strategy)    if rank == 0:        print(f"[结果] 策略={args.strategy} | 数据包={args.size}字节 | 延迟={latency:.6f}s | 带宽={bandwidth:.2f}GB/s")    # 拥塞检测模式    if args.size == 0 and rank == 0:          threshold = detect_congestion()        print(f"[拥塞检测] 网络拥塞临界点={threshold}字节")

不同的并行策略使用不同的方式模拟测试。比如，通过comm.Bcast实现广播通信来测试数据并行，使用 comm.Send/Recv 进行点对点通信来测试模型并行，使用环形通信模式模拟多级流水线来测试流水线并行。

在通信性能测量方面，我们可以通过动态计算延迟和带宽比如：bandwidth = data_size / latency / 1e9。并且通过—size参数调整，来支持1KB-1GB自定义数据包范围。在拥塞临界点检测方面，我们可以通过自动设定扫描数据包大小范围（1KB-1GB），并将带宽下降超过10%时判定为拥塞点。在MPI多节点支持方面，我们可以基于mpi4py实现分布式通信并通过rank和size来区分进程角色等实现。

测试前，需安装mpi4py和numpy，跑测试命令如下：

# 数据并行测试（100MB数据包）mpiexec -n 4 python tartan_bench.py --strategy data_parallel --size 100000000# 拥塞临界点检测mpiexec -n 4 python tartan_bench.py --size 0

2、NCCL Tests，专注于多 GPU 集群的集合通信性能测试，涵盖 All-Reduce、All-Gather、Broadcast 等关键操作，可量化 NVLink 与 PCIe 在集合通信中的效率差异，例如通过对比两者在 All-Reduce 操作中的吞吐量，直观反映技术优劣。

测试代码（nccl_benchmark.cu）如下：基于 nccl-tests官方测试框架（需提前安装 NCCL、CUDA、MPI），通过环境变量控制通信路径。

#include <nccl.h>#include <mpi.h>#include <cuda_runtime.h>#include <iostream>#include <vector>#include <chrono>#define MPICHECK(cmd) do {                          \    int e = cmd;                                    \    if (e != MPI_SUCCESS) {                         \        printf("MPI error %d at %s:%d\n", e, __FILE__, __LINE__); \        exit(EXIT_FAILURE);                         \    }                                               \} while(0)#define NCCLCHECK(cmd) do {                         \    ncclResult_t r = cmd;                           \    if (r != ncclSuccess) {                         \        printf("NCCL error %d at %s:%d\n", r, __FILE__, __LINE__); \        exit(EXIT_FAILURE);                         \    }                                               \} while(0)int main(int argc, char* argv[]) {    // 初始化 MPI    MPICHECK(MPI_Init(&argc, &argv));    int rank, size;    MPICHECK(MPI_Comm_rank(MPI_COMM_WORLD, &rank));    MPICHECK(MPI_Comm_size(MPI_COMM_WORLD, &size));    // 解析命令行参数    size_t min_bytes = 1;      // 1B    size_t max_bytes = 1 << 30; // 1GB    int ngpus = 1;             // 每节点 GPU 数    ncclRedOp_t op = ncclSum;  // 集合操作类型    // 参数解析逻辑（示例：-b 8 -e 1G -g 4）    for (int i = 1; i < argc; ++i) {        if (strcmp(argv[i], "-b") == 0) min_bytes = atoll(argv[++i]);        else if (strcmp(argv[i], "-e") == 0) max_bytes = atoll(argv[++i]);        else if (strcmp(argv[i], "-g") == 0) ngpus = atoi(argv[++i]);    }    // 获取本地 GPU 设备    int local_rank = rank % ngpus;    cudaSetDevice(local_rank);    // 初始化 NCCL    ncclComm_t comm;    ncclUniqueId id;    if (rank == 0) NCCLCHECK(ncclGetUniqueId(&id));    MPICHECK(MPI_Bcast(&id, sizeof(id), MPI_BYTE, 0, MPI_COMM_WORLD));    NCCLCHECK(ncclCommInitRank(&comm, size, id, rank));    // 主测试循环：遍历不同数据大小    for (size_t bytes = min_bytes; bytes <= max_bytes; bytes *= 2) {        // 分配 GPU 显存        float *d_send, *d_recv;        cudaMalloc(&d_send, bytes);        cudaMalloc(&d_recv, bytes);        cudaMemset(d_send, 1, bytes); // 初始化数据        // 同步所有节点        cudaDeviceSynchronize();        MPICHECK(MPI_Barrier(MPI_COMM_WORLD));        // 计时开始        cudaEvent_t start, stop;        cudaEventCreate(&start);        cudaEventCreate(&stop);        cudaEventRecord(start);        // 执行 All-Reduce 操作        NCCLCHECK(ncclAllReduce(            d_send, d_recv, bytes / sizeof(float),             ncclFloat, op, comm, cudaStreamDefault        ));        // 计时结束        cudaEventRecord(stop);        cudaEventSynchronize(stop);        float ms;        cudaEventElapsedTime(&ms, start, stop);        // 计算带宽（GB/s）        double bandwidth = (bytes * 2) / (ms * 1e6) * 1e3; // *2 因 All-Reduce 含发送+接收        if (rank == 0) {            printf("Size: %-10ld | Time: %.3f ms | Bandwidth: %.2f GB/s\n",                    bytes, ms, bandwidth);        }        // 清理        cudaFree(d_send);        cudaFree(d_recv);        cudaEventDestroy(start);        cudaEventDestroy(stop);    }    // 释放资源    NCCLCHECK(ncclCommDestroy(comm));    MPICHECK(MPI_Finalize());    return 0;}

编译如下：

# 依赖：NCCL、CUDA、OpenMPInvcc nccl_benchmark.cu -o nccl_benchmark \    -I/path/to/nccl/include \    -L/path/to/nccl/lib -lnccl \    -I/path/to/mpi/include -L/path/to/mpi/lib -lmpi

可通过如下方式运行，具体参数设定，可根据我们实际的测试场景进行：

# 单机多卡（4 GPU）mpirun -np 4 ./nccl_benchmark -b 8 -e 1G -g 4# 多机多卡（2节点，各4 GPU）mpirun -np 8 \    -H node1:4,node2:4 \    -x NCCL_DEBUG=INFO \    -x NCCL_P2P_DISABLE=1 \  # 强制禁用 NVLink，使用 PCIe    ./nccl_benchmark -b 128M -e 1G -g 4

根据上述测试脚本，我们可以在相同数据量下：

# NVLink 模式（默认）Size: 1073741824 | Time: 12.4 ms | Bandwidth: 172.58 GB/s# PCIe 模式Size: 1073741824 | Time: 36.7 ms | Bandwidth: 58.31 GB/s

对比启用（NCCL_P2P_DISABLE=0）和禁用（=1）NVLink 的带宽，会发现NVLink 带宽显著高于 PCIe（约 3 倍），适合大规模数据并行。

3、定制化脚本，通过 PyTorch/CUDA 编写点对点带宽测试脚本，可直接测量 GPU 间的数据传输速率，NVLINK带宽测试代码如下：

import torchn_gpus = torch.cuda.device_count()  # 获取GPU数量data_size = 1024**3 * 4  # 1GB数据（单精度浮点数）for i in range(n_gpus):    for j in range(i+1, n_gpus):        # 在GPU i上生成1GB随机数据        data = torch.randn(1024**3, device=f"cuda:{i}")          # 初始化计时事件        start_event = torch.cuda.Event(enable_timing=True)        end_event = torch.cuda.Event(enable_timing=True)        # 记录开始时间        start_event.record()        # 跨GPU复制数据        data.copy_(device=j)          # 记录结束时间        end_event.record()        # 同步确保计时准确        torch.cuda.synchronize()        # 计算带宽（单位：GB/s）        bandwidth = data_size / start_event.elapsed_time(end_event) * 1000 / 1e9          print(f"GPU {i}→{j} 带宽：{bandwidth:.2f} GB/s")

（四）性能评估结果

下面将给出GPU各网络互联模式下的性能评估结果，所有数据均来自论文《Evaluating Modern GPU Interconnect: PCIe, NVLink, NV-SLI, NVSwitch and GPUDirect》（https://arxiv.org/pdf/1903.04611）图 5–7、19–20、25–27、28–29 的实测结果，误差 < 5%。

分别从启动延迟、持续带宽、带宽与GPU数量、带宽与消息大小关系进行简单的性能展示与说明。

图九、三种硬件配置下的不同的网络互联模式下的启动延迟

如图，从P2P来看，最短消息（4 B）的端到端通信时间；NVSwitch < NVLink-V2 ≈ NV-SLI < InfiniBand < PCIe，NVSwitch 仅 0.7 µs，PCIe 高达 20 µs。其他两种情况，结果也差不多。

图十、三种硬件配置下的不同的网络互联模式下的持续带宽

如图，在 1 GB 负载下可长期保持的传输速率；NVSwitch > NVLink-V2 > NV-SLI > NVLink-V1 > InfiniBand > PCIe，NVSwitch 双向可达 140 GB/s。

图十一、不同的网络互联模式下带宽与GPU数量的性能关系

如图，当 GPU 数从 2 增加到 16 时，PCIe 带宽 线性下降，而 NVSwitch 带宽 线性上升 并稳定在 160 GB/s，证明 NVSwitch 的扩展性最佳。

图十二、不同的网络互联模式下的带宽与消息大小的关系

如图，消息 ≥4 MB 时才能打满链路带宽；NVSwitch 最早饱和且峰值最高（≈140 GB/s），PCIe 需要更大消息才能逼近上限（≈24 GB/s）。

为了更加清晰的反映出GPU各互联网络技术的性能指标，总结下表如下：

表二、GPU互联网络性能比较

如表所示，在大模型训练场景中，GPU互联网络性能表现不一：

a) NVLink/NVSwitch：在服务器内部的GPU互联中表现出色，特别适合高性能计算和大模型训练场景

b) Infiniband：跨节点通信的最佳选择，提供高带宽低延迟的节点间互联

c) RoCE：性价比高，基于以太网实现RDMA，适合构建大规模集群

d) PCIe：虽然不断发展，但作为通用接口已无法满足大模型训练的海量数据传输需求

e) GPUDirect：作为技术增强方案，与其他互联技术结合使用可显著提升节点间通信效率

在现代大规模GPU集群中，通常会采用混合架构（如节点内使用NVLink/NVSwitch，节点间使用Infiniband或RoCE）来获得最佳的整体性能。

五、技术选型建议

为了应对不同的应用场景，我们在设计大模型场景的GPU网络互联方案时，建议针对不同的场景，选择不同的技术，以满足性能与成本的双赢。

表三、各场景下，技术组合与选型推荐

六、未来趋势展望

随着大模型参数规模向十万亿级迈进，GPU 互联技术正从“带宽竞赛”转向“异构融合与系统级协同”。CXL 3.0 将在 2026 年前后把 CPU、GPU 与内存统一到缓存一致性的扁平地址空间，使显存池化、细粒度算子卸载成为现实；硅光互联 800 Gbps 乃至 1.6 Tbps 模块的成熟，将把跨节点总带宽推进到 TB/s 级别，同时功耗下降 40% 以上。InfiniBand SHARP v4 及后续版本继续在网络芯片内完成归约、广播等集体操作，可把 All-Reduce 延迟再降 70%，与 NVSwitch 形成“节点内+节点间”全栈加速。由 AMD、Intel、Google 等发起的 UALink 联盟则试图打破 NVLink 的封闭生态，推出 2025 年面世的开放标准，预计 2027 年形成与 NVLink 分庭抗礼的第二条高速链路。

综合来看，未来五年 GPU 互联将呈现“三横两纵”格局：横向是 PCIe-CXL-NVLink/UALink 的链路演进，纵向是 InfiniBand-RoCE 的跨节点网络分层；软硬件协同设计、光子计算、网络内计算将共同把千卡训练扩展为万卡、十万卡，支撑 E 级 AI 算力的落地。

七、总结

本文系统梳理了大模型场景下的 8 种 GPU 网络互联技术，从单机 PCIe/NVLink 到跨节点 InfiniBand/RoCE等。在 GPT-4 及后续十万亿参数模型的推动下，GPU 互联已从“单机总线”演进为“分布式高速交换矩阵”。PCIe 仍是最通用的基线，但带宽与延迟已逼近物理极限；NVLink/NVSwitch 凭借 1.8 TB/s 单机带宽与 5 μs 级延迟，成为单机八卡到七十二卡场景的不二之选；InfiniBand 以 400–800 Gbps 的跨节点带宽和 SHARP 网络内计算，成为千卡、万卡集群的黄金标准；RoCE v2 在 200–400 Gbps 区间给出性价比最优解，适合预算受限的中小规模训练；GPUDirect、GPUDirect RDMA 通过与 NVLink、InfiniBand、RoCE 的组合，将 CPU 绕开的零拷贝优势发挥到极致，使端到端通信效率提升 30% 以上。

性能评估可知，NVLink 在 All-Reduce 基准中的有效带宽是 PCIe 的 3 倍，InfiniBand 千卡扩展效率仍可保持在 82% 以上，而 RoCE 在 512 卡规模下能以 60% 成本提供 75% 的性能。

面向未来，CXL 3.0 将统一内存语义与链路协议，硅光互联把跨节点带宽拉升到 1 TB/s，UALink 则提供开放可替代的高速通道；我们后续在设计时，需在“节点内 NVSwitch + 节点间 InfiniBand”的成熟方案基础上，提前规划 CXL 内存池化与硅光网络的试点部署，以在 2027 年前后平滑过渡到十万卡级 E 级 AI 集群，这样可以持续释放大模型训练的算力红利。