GPU为什么也会等网络？从机房互联到算力集群

2026/07/28携剑陟峰人

摘要：单张 GPU 的性能很强，多张 GPU 连接起来以后，却不一定能够得到简单相加的集群性能。本文从服务器内部互联、GPU 高速互联、节点间计算网络、存储网络和业务管理网络出发，解释分布式训练为什么会让 GPU 等待网络，并结合我参与直播业务数据中心升级的经历，讨论网络怎样从机房配套走进业务与计算的核心链路。

最近几个月，围绕 AI 算力网络的产品和项目发布明显多了起来。

  • 7 月 23 日，AMD 发布 Pensando Vulcano 800 AI NIC，把 800G 以太网、多平面组网和 MRC 多路径可靠传输放进面向大规模 AI 集群的网络方案中。

  • 7 月 2 日，新华三宣布完成 800G 智算网络全场景互通实测，覆盖 Scale-Up、Scale-Out 和 Scale-Across 三类场景。

  • 6 月 22 日，NVIDIA 公布欧洲正在建设的 35 套 AI 与 HPC 超级计算机，其中多个项目继续采用 Quantum-X800 或 Quantum-2 InfiniBand 网络。

算力观察新闻头版

AMD 和新华三重点推进基于以太网的 AI 网络，NVIDIA 则同时布局 InfiniBand 与 Spectrum-X 以太网，技术路线并不完全相同，但它们都在回答同一个问题：当 GPU 集群从一台服务器扩展到多个机柜、多个数据中心以后，怎样让数据和计算结果及时到达需要它们的节点。

这也说明，算力中心扩容不能只计算增加了多少张 GPU。GPU 数量越多、任务协同越紧密，网络需要承载的数据交换和同步压力就越大。高速网络正在从服务器的配套连接，变成影响集群有效算力的重要部分。

上一篇写存储时，我反复提到一句话：数据供不上，GPU 就可能等待。

但继续沿着数据路径往前走，会发现存储把数据读出来以后，问题并没有结束。只要训练数据保存在远端或共享存储中，它就需要经过网络进入计算节点；模型超过单张卡或单台服务器的承载能力以后，多张 GPU 之间还要不断交换和同步计算数据。

于是就会出现一个看起来有点反直觉的问题：单张 GPU 已经很快了，为什么多张 GPU 放在一起以后，整个任务仍然可能变慢？

多张 GPU 组成集群，不是把它们的性能数字直接相加。每张 GPU 除了完成自己的计算，还要等待数据到达，与其他 GPU 交换结果，并按照任务的并行方式保持同步。任何一条数据路径出现拥塞、抖动或者配置问题，都可能让一部分 GPU 先完成计算，然后停下来等待。

GPU 可能在等存储送来的数据，也可能在等同一个任务里的其他 GPU。网络正好处在这两种等待之间。

GPU等待网络的拼图类比

要理解这种等待，首先不能把算力中心里的所有互联都笼统地叫作“高速网络”。PCIe、NVLink、InfiniBand、以太网和 RoCE 经常出现在同一张 AI 集群架构图里，但它们所处的位置和解决的问题并不相同。

算力中心里并不只有“一张网络”

在传统机房里，我们说网络，通常先想到交换机、路由器、网线、光纤和运营商线路。到了算力中心，网络的范围被进一步拉大了：一台服务器内部有 CPU、GPU、网卡和 NVMe 之间的数据通路；服务器内部或特定系统中的 GPU 之间有高速互联；多台服务器之间还有计算网络、存储网络和业务管理网络。

算力中心整体网络架构

服务器内部：PCIe 与 GPU 高速互联

一台 AI 服务器里，CPU、GPU、网卡和 NVMe 设备需要通过高速 I/O 通道交换数据，PCIe 是其中的重要基础。它解决的是设备怎样在一台服务器内部连接，不能与机房里的以太网或 InfiniBand 交换网络直接放在同一层比较。

GPU 之间还可能使用 NVLink、NVSwitch 等高速互联，让多张 GPU 更高效地交换数据。在不同产品和系统中，这种互联可能位于单台服务器内部，也可能扩展到特定的机架级系统，但它与跨大量服务器节点的计算网络仍然不是同一个层级。

服务器之间：计算网络把节点组织起来

模型和任务超过单台服务器能力以后，计算会扩展到多个节点。此时，服务器需要通过 InfiniBand 或支持 RoCE 的高速以太网等方式进行通信。

RoCE 不是与以太网并列的另一种物理网络，而是在以太网上实现 RDMA 的技术路线。RDMA 通过减少 CPU 参与和内存复制，让数据能够更高效地在不同节点之间传输；它是一种数据传输机制，不是一款网卡或交换机。

提醒

InfiniBand 与基于 RoCE 的以太网都可以承担高性能集群通信任务，但协议、生态、网络设计和运维方式不同。实际选择哪条路线，不能只比较端口速率，还要看集群规模、现有网络、软件生态、建设成本和团队能力。

存储、业务和管理网络各有边界

训练数据可能从对象存储、分布式文件系统或并行文件系统进入计算节点，检查点又要周期性写回存储。存储网络与计算网络可以在物理上分开，也可能共享部分基础设施。前者边界清楚但成本更高，后者可以复用设备，却要更仔细地处理带宽分配、拥塞和流量隔离。

用户提交任务、业务系统调用模型、监控系统采集指标、运维人员管理设备，则需要业务与管理网络。它们不直接参与 GPU 之间的集合通信，却决定集群能否被正常使用、维护和恢复。

所以，理解算力中心网络，第一步不是记住更多缩写，而是知道每条链路连接谁、传输什么，以及它在整个任务中承担什么工作。

传统网络负责传输，AI网络还要支撑协同计算

传统互联网业务通常会把请求分配到不同服务器。每台服务器处理自己的连接和业务逻辑，一台机器变慢，影响的可能只是被分配到这台机器上的部分请求。通过负载均衡、服务副本和故障转移，业务还可以绕开异常节点。

传统网络与AI计算网络对比

分布式 AI 训练不完全一样。多张 GPU 可能共同完成同一次训练，大家计算的是同一个模型，只是各自承担不同的数据或不同部分的计算。它们不仅需要在开始时取得数据，还要在计算过程中交换结果。

以常见的数据并行为例，同一批训练数据会被分成多个部分，交给不同 GPU 处理。每张 GPU 完成本地计算，得到自己这部分数据对应的梯度；随后，各个 GPU 需要汇总梯度，并让模型参数保持一致，才能继续下一轮训练。

All-Reduce 是集合通信中的一种常见操作。多个 GPU 分别提供自己的结果，系统完成汇总以后，再把结果同步给所有参与者。它可能随着一轮轮计算反复进行，而不是只在训练开始或结束时发生一次。NCCL 官方文档对 All-Reduce 的定义也是：在多个参与者之间完成归约，并让每个参与者获得归约结果。

这时，计算和通信就发生了直接关系。某张 GPU 已经完成本地计算，但同步还没有结束，它就可能需要等待。集群规模扩大以后，参与通信的 GPU 更多，数据经过的链路和交换节点也可能增加，网络对整体效率的影响随之变得明显。

这并不意味着集群性能完全由最慢的一条链路决定。不同模型、并行策略和软件优化方式，对通信的依赖程度不同；系统也可以让一部分通信与计算重叠，减少等待。但通信不会凭空消失，模型怎样拆分、GPU 怎样分组、任务被调度到哪些节点，都会改变网络需要承担的工作。

训练和推理对网络的要求也不完全相同。大规模训练更关注节点之间持续的数据交换、集合通信和整体吞吐。如果一台服务器能够完整承载推理模型，多台服务器只是各自处理不同用户请求，网络更接近传统在线业务；如果模型必须跨多张 GPU 或多个节点部署，卡间和节点间通信仍然会影响 Token 生成速度和服务时延。

网络传输的已经不只是一次业务请求，而可能是决定下一轮计算能否继续的数据。

带宽够大，GPU集群为什么还是可能很慢

既然网络会影响计算效率，一个直接的想法是：把网卡和交换机换成更大的带宽，问题不就解决了吗？

更大的带宽当然重要，但它只解决了“路够不够宽”的问题。可以把 GPU 集群想象成一座由多个车间共同生产的工厂：GPU 节点是不同车间，训练数据和计算结果是需要运送的原料、零件和生产记录，网络则是连接这些车间的道路与运输系统。

一个车间完成自己的工序以后，可能要等其他车间送来零件或汇总后的生产记录，才能进入下一步。如果其中一批关键零件迟迟没有到，车间里的机器即使性能再强，也只能暂时停下来。

带宽与端到端网络瓶颈

大门口有八车道，不代表全程都有八车道

交换机端口和网卡的速率，可以理解成工厂门口一段道路的通行能力。门口有八车道，当然比两车道能承载更多货车，但货车从一个车间到另一个车间，经过的不只有这一段路。

中间可能存在较窄的内部道路，也可能有多个车间共用的路口。训练数据读取、检查点写入和 GPU 之间的通信如果共享部分链路，就像运送原料、成品和生产记录的货车同时驶入同一个路口。单个端口的标称速率再高，也不能直接代表整条路径的有效带宽。

车间的位置和交通状况同样重要

两个需要频繁交换零件的车间相邻，运输距离短，经过的路口也少；如果它们位于园区两端，货车就要经过更多道路和中转节点。

放到 GPU 集群里，同一台服务器内的 GPU 可能通过 NVLink、NVSwitch 或 PCIe 通信；跨服务器以后，数据还要经过网卡和交换网络；如果节点分布在不同机柜，通信路径会进一步拉长。因此，**网络拓扑和任务调度不能完全分开。**调度系统如果只知道“这里还有空闲 GPU”，却不知道这些 GPU 之间的连接关系，就可能把需要紧密协同的任务分配到不合适的节点上。

道路拥堵也不会总是表现为彻底中断。有时大部分货车能够正常到达，只有部分批次偶尔延迟。对应到网络，就是设备和端口都在线，但短时间的队列积压、突发流量、丢包和重传，仍然可能让某一轮通信变慢。

专用货车也需要配套的道路规则

RoCE 可以类比成让专用货车在现有以太网道路上进行更高效的运输。它利用 RDMA 减少 CPU 参与和数据中转，但不是换上一批专用货车以后，整套物流系统就会自动变快。

道路怎样划分车道、路口怎样通知车辆减速、发生拥堵后如何控制流量，都需要配套规则。RoCE 网络中的 PFC、ECN、DCQCN 等机制，可以先理解成不同环节的交通管理办法。这里所说的“无损网络”，更适合作为一个设计和运行目标，而不是物理上永远不会丢失任何数据包。

GPU、网卡、交换机、驱动、固件、操作系统以及 CUDA、NCCL 等通信软件也要一起工作。硬件参数满足要求，只能说明道路和车辆已经准备好；应用有没有走到正确的通信路径、系统能否识别真实拓扑，仍然需要部署和测试。

网络彻底中断时容易报警，最难定位的是所有设备看起来都正常，训练任务却越来越慢。排查时需要把 GPU 利用率、任务阶段、通信耗时、端口队列、丢包、重传和实际调度拓扑放在一起看，而不是让网络团队和计算团队分别证明自己的设备“没有坏”。

算力网络的建设目标，不是单独修一段最宽的路，而是让数据在真实拓扑和真实负载下，稳定、及时地到达需要它的 GPU。

从直播业务的数据中心建设，看网络怎样成为业务的一部分

这种“网络设备正常，不代表业务一定正常”的认识，并不是到了 GPU 集群才出现。过去参与直播业务的数据中心建设时，我已经开始感受到，网络不仅是服务器接入机房的配套，而是业务能否稳定交付的一部分。

2023 年前后，我参与了一个直播业务数据中心的改造升级。业务采用 IDC 机房托管，我主要负责整体升级方案设计和项目实施管理。随着业务量快速增长，原有服务器和网络资源逐渐接近瓶颈。项目一方面计划在原有服务器基础上增加约一倍的资源，另一方面把数据中心骨干链路从 40G 升级到 100G。

直播业务数据中心改造与流量走向

直播并不是主播把视频直接发送给每一位观众。在我们当时的架构里，主播推流先进入 ZLMediaKit 集群，由 Media Server 完成直播流接入和转发，再由源站向 CDN 提供内容。数据中心不直接承载全部观众的下行流量，但推流接入、内部处理、源站和向 CDN 供源中的任何一段出现问题，都会传递到最终播放体验。

直播业务对网络的要求，很难只用“出口带宽够不够”概括。主播来自不同地区和运营商，推流路径是否稳定，会影响直播数据能否持续进入平台；数据中心内部还存在流媒体服务器、源站和其他业务系统之间的东西向流量；向 CDN 供源则会形成持续的出口流量。

我们在网络设计中重点考虑了多运营商 BGP 接入、出口带宽扩容，以及核心设备和关键链路冗余。多运营商接入主要改善不同运营商之间的访问路径，并在单条线路故障时保留切换能力；应对直播高峰期的并发流量，则需要扩充出口带宽，并通过路由策略进行流量分担。设备和链路冗余解决的是另一类问题：当核心设备或关键链路故障时，业务不能跟着一起中断。

整个项目在进行上线后试运行时，却出现了大面积的故障，造成了直播高峰期的大面积卡顿。

当时客户端上报的卡顿率在短时间内明显上升，团队最初把注意力放在 CDN 边缘节点的并发能力上。后来我们沿着推流、源站接收、切片处理和 CDN 分发逐段复盘流量路径，发现多条上行链路虽然都处于正常状态，但 ECMP 的流级哈希没有把流量均匀分开，部分大流集中到同一条链路，造成局部拥塞和丢包。

这个现象可以用超市收银台来理解。高峰期即使同时开放了多条收银通道，入口也不一定会根据每辆购物车里的商品数量实时调整队伍，而可能按照某种相对固定的规则进行分配。平时顾客数量多、购物量比较接近时，各条队伍看起来会比较均匀；但如果几辆装满商品的大购物车恰好被分到同一个通道，这边很快就会排起长队，旁边的收银台却可能还有空闲。

此时所有收银台都正常开放，超市的总收银能力也没有完全用完，但排在拥堵通道里的顾客仍然要等待很久。对应到当时的直播网络，多条上行链路都处于在线状态，几股较大的直播流却集中在同一条路径上，最终表现为局部拥塞、丢包和用户端卡顿。

ECMP故障的收银台类比

ECMP 的实际工作方式与这种分流有些相似。它通常根据源地址、目的地址、端口等信息对流量进行哈希，再把不同流分配到多条等价路径。它追求的是统计意义上的分担，并不保证任何时候都绝对均匀。流数量较少或者部分流量特别大时，就可能出现一条链路已经拥堵，其他链路还有余量的情况。

我们随后调整了出口路由和 ECMP 分流策略，并增加了面向单流丢包的端到端路径监测。这个问题不是简单更换一台交换机就能解决，因为设备和链路都处于正常在线状态，真正需要处理的是流量怎样经过这些设备。

这次经历改变了我判断网络问题的方法。以前我会先看设备和端口是否在线，后来更关注一条直播流实际经过了哪些系统、哪些链路，以及问题发生在哪一段。今天再看 GPU 集群，我仍然沿用这套思路：不只看交换机和网卡参数，而是看数据能否按照任务需要稳定到达。

直播业务与 AI 集群的网络负载并不相同。直播传输的是持续产生的音视频流，网络问题会直接表现为卡顿、延迟或中断；GPU 集群除了读取训练数据和写入检查点，还会在计算过程中交换和同步数据，问题更多表现为通信耗时增加、GPU 等待和任务完成时间延长。

**但两者有一个共同点：服务器和网络设备处于在线状态，不等于业务或计算一定处于高效状态。**到了 GPU 集群，网络又往前走了一步，它不仅承载业务数据，还进入了分布式计算过程。

写在最后

一座算力中心部署了多少张 GPU，只能说明它拥有多少物理计算资源。要让这些 GPU 共同完成训练和推理任务，还需要服务器内部互联、节点之间的计算网络、存储网络和通信软件一起工作。

GPU 会等网络，不是因为网络替代了计算，而是因为分布式计算已经把通信放进了任务执行过程。网络出现拥塞、抖动或路径不合理时，设备可能都处于在线状态，训练任务却仍然在等待。

网络也不是所有性能问题的唯一答案。以下问题同样会让 GPU 空闲：

  • 存储供数不足
  • CPU 预处理跟不上
  • 任务调度不合理
  • 软件没有正确使用高速通信路径

算力中心需要把计算、存储、网络、调度和软件放在一起判断。

从直播业务的数据中心建设到今天的 GPU 集群，我看到的不是旧网络被一种全新的网络取代，而是同一个基础问题被放到了更大的规模和更紧密的协同关系里：怎样让数据沿着正确的路径，在需要的时间到达需要它的设备。

理解算力中心，不能只看单张 GPU 有多快、部署了多少张卡，还要看这些 GPU 能不能高效地一起工作。

下一篇，可以继续讨论虚拟化、资源池和任务调度。服务器、存储和网络准备好以后，它们还只是物理资源；怎样把这些资源组织成可以申请、计量、分配和回收的算力，是算力中心需要解决的另一个问题。