Meta：大规模分布式AI训练的RoCE网络（论文）
参考：Meta：大规模分布式AI训练的RoCE网络（演讲/文章）
内容概括
1.引言
随着模型规模与复杂性的急剧提升，对HPC基础设施的需求亦随之攀升。为应对此挑战，Meta研发了一种基于RoCE网络的解决方案，以支撑其大规模分布式AI训练工作负载。本文旨在详尽阐述Meta的RoCE网络设计、架构及其运营经验，内容涵盖网络拓扑、路由策略、传输层优化以及可观测性等方面。
2.背景
在分布式AI训练中，模型与数据被分割至多个GPU上，此过程利用多种并行化策略以增进训练效率。此间需频繁进行大规模数据交换，尤其是集体通信操作，诸如AllReduce、AlltoAllv及AllGather等。此类操作对网络带宽与延迟有着极高的要求，而传统TCP/IP网络在处理此类流量时表现欠佳，故而Meta选用RoCE作为应对之策。
3.硬件架构
训练节点：训练节点配备有多个GPU，并通过NVSwitch实现互连。每个GPU均配备有专用的RDMA NIC，以实现GPU间的直接通信，从而规避主机CPU与内存的瓶颈。 网络拓扑：Meta的RoCE网络采用两级Clos拓扑结构，称为“AI Zone”。机架训练交换机（RTSW）作为叶交换机，通过铜缆连接机架内的GPU；而集群训练交换机（CTSW）则作为脊柱层，通过光纤连接所有RTSW。CTSW配备有深度缓冲区，以吸纳网络中的瞬时拥塞，并在扩展RoCE域以支持更大规模AI模型时，引入汇聚训练交换机（ATSW）以连接多个AI Zone。 前后端网络分离：Meta实施了前后端网络的分离设计。前端网络负责数据引入、检查点及日志记录等任务，而后端网络则专门用于GPU间的通信。此设计简化了网络管理，并使得前后端网络能够独立发展。
4.路由策略
ECMP的局限：默认的等价多路径（ECMP）路由方案因其随机性而在低熵AI流量下导致负载不均衡及性能下降。 路径固定与增强型ECMP：尽管Meta尝试了路径固定方案，但在机架部分分配或网络故障时，其性能会受到影响。因此，Meta实施了增强型ECMP（E-ECMP），通过队列对（QP）扩展及自定义哈希来增加流量熵，从而改善负载均衡。 集中式流量工程：Meta开发了集中式流量工程（TE）控制器，根据实时流量需求与网络拓扑动态优化流量路由。尽管TE能够提供更好的负载均衡与性能，但在多链路故障情况下可能导致性能下降，并增加了软件的复杂性与管理开销。因此，TE主要应用于以排序任务为主的集群。 Flowlet切换：作为未来发展方向，Meta正在探索Flowlet切换技术，以实现更具适应性与可扩展性的路由解决方案。Flowlet切换通过硬件辅助机制对端口负载变化做出快速响应，从而实现更优的负载均衡与拥塞管理。
5.传输层优化
DCQCN的挑战：最初，Meta采用数据中心量化拥塞通知（DCQCN）作为拥塞控制机制，但发现其难以满足AI训练工作负载的特定需求。 接收端驱动流量准入：Meta转向了一种接收端驱动的流量准入机制，该机制通过集体通信库实现。其利用CTS数据包在接收端调节流量注入，以防止网络过载。此外，Meta还在所有交换机与NIC上部署了基于差分服务代码点（DSCP）的优先级流控（PFC）及无损队列，以降低网络拥塞与数据包丢失。 深度缓冲区：为进一步增强网络的稳健性，Meta在CTSW中使用了深度缓冲区，以有效吸纳瞬时拥塞，从而防止因瞬时流量突发而引起的性能下降。
6.经验教训
协同调优：Meta强调网络、传输与集体通信库的协同调优对于实现最佳性能的重要性。通过调整NVIDIA集体通信库（NCCL）配置、优化消息大小、协议及控制消息优先级，Meta显著提升了RoCE性能。 拓扑与路由的影响：网络拓扑与路由策略对整体训练性能具有显著影响。Meta的实践表明，通过不断优化网络结构、路由策略及流量工程，能够有效满足日益增长的需求。 可观测性工具：为有效监控与管理RoCE网络，Meta开发了一整套可观测性工具，能够收集RDMA硬件计数器、监控PFC状态、追踪缓冲区利用率及网络可达性等，从而助力运营商快速识别并解决潜在问题。 故障排除案例：Meta分享了一些故障排除案例，凸显了运营大规模RoCE网络的复杂性。这些案例强调了持续监控网络延迟、进行全面验证及性能回归测试的重要性，以及建立有效检测与警报系统的必要性。
7.相关工作
当前RDMA网络研究多聚焦于存储网络应用，而针对其在大规模AI训练环境中的应用则鲜有报道。Meta的工作为理解RoCE在分布式AI训练场景中的独特挑战与机遇提供了重要洞见。此外，其他研究者亦在探索多种网络与AI的协同设计原则，以优化分布式训练的性能，包括新型网络拓扑、改进的集体通信算法及自动化的模型并行化技术等。
8.结论
Meta的大规模RoCE网络设计与运营经历了持续的演进，以应对日益增长的计算密度与规模需求。通过前后端网络分离、先进的路由方案、集体通信流量模式的优化以及全面的可观测性工具的实施，Meta成功构建了高性能、可靠且可扩展的网络基础设施，以支撑其分布式AI训练工作负载。Meta的经验凸显了对训练工作负载特征的深入理解以及将这些知识有效转化为网络设计的重要性，最终推动了分布式AI训练基础设施的发展。
----------
摘要
网络拓扑（Network Topology）：为了适应AI硬件平台的快速迭代，我们将基于GPU的训练任务划分为独立的“后端”网络，以提高网络资源利用率和管理灵活性。 路由（Routing）：考虑到AI训练负载的不均衡性和突发性，我们迭代部署了多种路由方案，以实现接近最优的流量分布，提升网络性能。 传输（Transport）：在拥塞管理方面，我们最初尝试使用DCQCN（Data Center Quantized Congestion Notification）机制，后又转向利用集体通信库（collective library）本身提供的拥塞控制功能，以获得更好的性能和稳定性。 运维（Operations）：我们分享了在大规模AI网络运维过程中积累的经验，包括开发的工具和故障排查案例，旨在为业界提供有益参考。
1 引言
人工智能（AI），尤其是在图像识别、自然语言处理和推荐系统等领域的广泛应用，对通信提出了更高的要求。分布式训练，作为AI模型训练的一种重要方法，给数据中心的网络基础设施带来了巨大的压力。例如，一个典型的生成式AI任务可能需要数千个GPU协同工作数周。为了满足这种快速增长的需求，构建可靠且高性能的网络基础设施成为了数据中心网络设计中的一个关键问题。
在分布式训练任务中，GPU之间的通信通常分为两个阶段：节点内通信和节点间通信。节点内通信指同一台服务器内多个GPU之间的通信，通常采用高速互联技术（如NVLink【26】）；而节点间通信指不同服务器上的GPU之间的通信，需要通过网络来实现。业界常用的节点间通信方式包括基于TCP/IP或其变种（如fastsocket【7】）的通信以及专有互联（如InfiniBand【23】、NVSwitch【26】、Elastic Fabric Adaptor【2】和Inter-rack ICI【8】）。虽然专有互联能够提供更高的性能，但其专有性限制了部署的灵活性。
RoCE遵循RDMA verbs语义，这种语义在训练负载社区中得到了广泛应用，有助于现有训练应用的平滑过渡并促进新应用的开发。 使用以太网使我们能够利用现有数据中心的大部分设计组件和工具。这样我们就可以采用Clos拓扑构建网络，并复用现有的工具来简化操作。 整个堆栈基于开放标准，并得到了多个厂商的支持，确保了网络基础设施的兼容性和灵活性。
在设计和运维RoCE网络的过程中，我们积累了丰富的经验：
专用后端网络：我们构建了一个专门用于分布式训练的后端网络，使其能够独立于数据中心的其他网络进行演进、运维和扩展。为了支持大语言模型（LLM），我们将后端网络扩展到了数据中心规模，并在训练任务调度器中引入了拓扑感知。
路由方案的演变：考虑到默认的ECMP（等价多路径）路由及其替代方案在初期阶段的性能表现不佳，我们部署了集中化流量工程和增强型ECMP相结合的方案，以实现训练负载的最优负载分布。
集体通信的拥塞控制：我们发现很难通过微调RoCE部署中常用的拥塞控制方案DCQCN来显著改善分布式训练任务的集体通信完成时间。因此，我们通过集体通信库设计了一种接收端驱动的流量准入机制，从而获得了更好的性能。这需要对集体通信库配置和底层网络配置进行协同调整，以实现最佳性能。
我们成功地将RoCE网络从原型扩展到了支持数千个GPU的集群。RoCE集群支持广泛的生产级分布式GPU训练任务，包括排序、内容推荐、内容理解、自然语言处理和生成式AI模型训练等。我们之前已经分享了支持多达3.2万个GPU的RoCE集群的高层设计【18】。
虽然RoCE曾经是网络研究的热点【3, 6, 9, 19】，但其主要应用一直集中在存储网络上。目前关于RoCE在大规模AI训练场景中的部署研究相对较少。本文深入探讨了RoCE网络的扩展，以实现每个集群中数千个GPU的互联。我们的经验表明，通过对工作负载的深入理解，并在拓扑、路由、传输和运维流程等网络组件上进行精心设计，RoCE完全能够满足大规模AI训练的需求。
本文的工作不涉及任何伦理问题。
2 背景
2.1 分布式模型训练
分布式训练通过将模型和/或输入数据分片（sharding）至多个GPU上，结合不同的并行策略来实现扩展。典型的训练过程包括重复的训练迭代，每次迭代由前向传播生成损失、反向传播计算梯度，以及优化器更新参数组成。在每次迭代中，参与训练的GPU需要多次同步梯度或更新的参数。该同步过程要求GPU之间在毫秒级内传输大量数据，并在多次迭代中重复，直至模型收敛。因此，需要网络具备高带宽及低且可预测的延迟特性。
2.2 RoCE和集体通信
RDMA（Remote Direct Memory Access，远程直接内存访问）是一个行业标准，用于硬件加速的通信方式。RDMA实现了包括读取和写入在内的“verbs”API。与基于TCP/IP的通信相比，RDMA跳过了发送端和接收端的内核，直接在应用内存之间传输数据，而TCP/IP需要将数据包发送到内核，再复制到内存中。RoCEv2是一种实现RDMA的协议：RDMA的verbs消息被封装在以太网/IPv6/UDP数据包中，通过普通以太网网络传输。封装和解封的操作由RDMA网卡（NIC）硬件处理。
集体通信库（collective communication library）作为训练负载与NIC之间的软件抽象层，通过verbs API层进行交互。它将集体通信（例如AllReduce）转化为逻辑拓扑实现（例如环形或树形），并进一步分解为在GPU之间进行点对点数据传输的调度，这些传输依赖verbs的支持，以实现最佳性能。集体库通过在源和目标NIC上创建的队列对（Queue Pairs，QP）调度verbs调用。例如，NCCL【25】使用RDMA写操作来实现所有集体算法和点对点语义。每对GPU之间的事务可通过多个通道进行，每对NIC之间的事务可以通过多个队列对完成。
表1展示了分布式训练中常用的主要集体通信的特征及其特定要求。首先，集体通信类型由并行策略决定。例如，分布式数据并行（Distributed Data Parallel，DDP）【14】使用AllReduce，全分片数据并行（Fully Sharded Data Parallel，FSDP）【41】使用AllGather和ReduceScatter。排序模型（例如DLRM【21】）使用AlltoAllv（矢量化的AlltoAll）来分配嵌入，实现模型并行。
其次，集体通信可生成多样化的网络流量模式。例如，AlltoAllv在所有端点间形成全网格流量模式，可能会导致高峰值拥塞。然而，由于其活跃流较多，使用哈希方案可减少持续拥塞的风险。
第三，集体操作的逻辑拓扑选择对网络拥塞和GPU间的数据交换有影响。例如，AllReduce在环形与树形拓扑下实现时，会产生不同的拥塞和哈希冲突问题。NCCL会根据GPU数量和消息大小优化这些具体选择。然而，该方法也存在一些限制，包括硬编码配置文件导致的不准确性、某些消息大小或大规模作业下的性能次优表现，以及在某些实现中集体算法的无关性。
2.3 训练负载
为了了解生产环境中集体通信的实际情况，我们利用Chakra【33】收集了2023年第四季度约3万个随机选择的训练任务的集体通信统计数据。
图1a展示了任务规模的分布。值得注意的是，我们的分析中不包括GPU数量大于128的长尾部分，因此排除了LLM任务。然而，由于多维并行的应用，分析GPU数量最多为128的任务对大型LLM任务仍具有高度相关性。
该分布显示大部分任务的GPU数量是8的倍数，这是因为我们在每个主机上安装8个GPU，不建议部分主机使用。为了展示不同模型使用的集体通信类型的多样性，我们按类型细分了集体通信。正如图1b所示，基于DDP的模型中AllReduce和AlltoAll(v)占主导，而FSDP中的主要集体通信为AllGather和ReduceScatter。消息大小指集体通信操作中传输的数据元素数量。我们选择了两种不同的模型，观察到消息大小的分布差异很大（如图2所示）。不同模型的传输数据量和流量模式也有所不同，这激发了我们在后续章节中解释的路由和传输选择。
任务规模的趋势：截至撰写本文时，排序模型主要覆盖8至256个GPU。展望未来，GPU数量更大的任务正变得越来越普遍，它们消耗的GPU时间也在逐步增加。这是由于排序模型的规模持续增长，对LLM来说，这一趋势更加显著。例如，Llama3的大规模变体在我们拥有2.4万个GPU的RoCE集群上使用了1.6万个GPU进行训练【18】。
每个集体通信的GPU数量趋势：无论是排序任务还是LLM，集体通信操作的GPU数量增长速率并没有与任务规模相同。这是因为在部署大型模型时采用了多维并行，从而限制了最大的集体通信GPU数量在数百个，即使任务运行时使用数万GPU。因此，本文接下来的内容将重点关注涉及16至128个GPU的集体通信操作。
2.4 挑战
构建满足分布式AI训练需求的RoCE网络面临多项挑战：
训练模型的快速演进：训练模型的快速发展需要网络带宽达到400Gbps甚至更高，且系统规模扩展至数万GPU。虽然初期排序任务的规模尚属适中，但LLM训练已知会同时占用数万加速器【8】，而排序任务的规模也在增长【39】。在构建如此庞大的网络的同时，维持高效的GPU间通信构成了显著的挑战（见第3节）。
流量模式中的低熵：分布式训练的流量模式在UDP 5元组中表现出低熵特性，如表2所示。这是第2.2节讨论的集体通信的结果。通常，一个GPU只服务于一个训练任务，其逻辑拓扑通常是稀疏的，这为通过路由实现流量的均衡分布以达到最佳性能带来了巨大挑战（见第4节）。
不同层级的网络拥塞：分布式训练生成了独特的全网格和分层流量模式（如环形或树形），它们各自会产生不同的拥塞模式，如表2中缓冲区占用情况所示。这些流量模式可在图3中看到。之前的RDMA部署中对于此类流量模式的拥塞问题尚无标准化的最佳实践（见第5节）。
协同调优的需求：集体通信库（例如NCCL）在RoCE互连中可能表现出低效的开箱即用（out-of-box）性能，这源于开发环境与生产环境的差异。这需要对集体库与网络配置进行协同调优，以获得最佳性能（见第6节）。流量模式中的低熵可能导致少数网络路径比其他路径承载更多流量，从而在这些路径上产生持续性拥塞。此外，即便流量分布完美，集体通信流量模式如AlltoAll仍可能产生微突发（microbursts）。这两种模式均可能对性能产生负面影响，但其表现形式和解决方法有所不同。因此，本文将前一种问题的解决方案放在第4节，后一种问题的解决方案在第5节进行讨论。
3 硬件
本节将介绍用于训练节点的硬件以及网络，以便为其上的软件系统做铺垫。
3.1 训练节点
训练模型和数据集规模的增加已使得将训练过程限制在单个GPU上不可行。这也需要更高的计算能力和内存，给网络带来显著压力，因此需要专门设计的扩展系统。
第一代训练节点设计ZionEX【20】，结合了通用CPU与NVIDIA A100 GPU。更新一代的Grand Teton【17】基于H100 GPU。ZionEX和Grand Teton的系统架构相似，唯一区别是GPU的NVLink互连。图4展示了Grand Teton的内部结构。节点分为三个托架——CPU托架包含2个CPU和前端NIC，交换机托架包含4个PCIe Gen5交换机、NVMe存储以及8个RDMA NIC，GPU托架包含8个GPU。GPU通过NVSwitch【26】实现全互连。每个GPU与一个NIC一对一映射。当训练任务使用GPU少于8个时，GPU之间的通信在节点内部进行，不涉及网络操作。对于较大规模的任务，RDMA NIC启用GPUDirect技术，使GPU到GPU的流量可以绕过主机及主机内存瓶颈。
3.2 网络
训练集群依赖于两种独立网络：前端网络（FE）用于数据引入、检查点记录及日志记录，后端网络（BE）则用于训练，如图5所示。
前端网络：训练机架连接至数据中心网络的FE和BE。FE包含多个网络层次【1】——机架交换机（RSW）、架构交换机（FSW）等层次，这些网络层次托管存储库，为GPU提供训练任务所需的输入数据。我们确保在机架交换机上有足够的带宽入口，以不影响训练任务。
后端网络：BE是一个专门的结构，用于连接所有RDMA NIC，采用无阻塞架构，在集群中任意两个GPU之间实现高带宽、低延迟和无损传输，无论其物理位置如何。该后端结构利用RoCEv2协议，通过网络在UDP数据包中封装RDMA服务进行传输。
3.3 演进
我们的BE网络经历了多次变革。最初，我们的GPU集群使用简单的星形拓扑，将少量AI机架连接至中心以太网交换机，运行不可路由的RoCEv1协议。此设置在GPU规模和交换机冗余方面有明显的局限性，因此我们迅速转向基于结构的架构，以扩展可扩展性并提高可用性。
AI Zone：我们为AI机架设计了两级Clos拓扑，称之为AI Zone，如图6所示。机架训练交换机（RTSW）作为叶交换机，通过基于铜线的DAC电缆提供机架内GPU的扩展连接。由模块化集群训练交换机（CTSW）组成的脊层（spine tier）在所有机架之间提供横向扩展连接。CTSW具有深度缓冲区，静态分配至机箱内的端口。RTSW通过单模光纤和400G可插拔光模块连接至CTSW。
数据中心级和拓扑感知调度：AI Zone设计支持大量GPU无阻塞互连。然而，诸如LLM等AI前沿技术对GPU规模的需求已超出单个AI Zone的提供能力。为满足这一需求，我们设计了一个汇聚训练交换机（ATSW）层，将数据中心建筑内的CTSW连接起来，扩大RoCE域，超出单个AI Zone的范围。需要注意的是，跨AI Zone的连接设计上是超额预订的，通过ECMP（等价多路径）平衡网络流量。为了缓解跨AI Zone流量的性能瓶颈，我们增强了训练任务调度器，使其在将训练节点分配至不同AI Zone时找到“最小切割”，以减少跨AI Zone流量，从而缩短集体操作的完成时间。调度器通过学习GPU服务器在逻辑拓扑中的位置来推荐任务的排序分配。
3.4 讨论
前端网络与后端网络的分离是RoCE部署中的早期、重要的设计决策，这主要是因为我们预计两者会各自独立发展。此外，分离AI训练流量简化并加速了路由和传输设计的迭代，因为两者的流量特性截然不同且经常存在相互冲突的需求。最终，物理隔离确保了理想的网络环境，以适应对延迟敏感的RoCE操作。
4 路由
上述计算能力和网络拓扑的扩展引发了如何高效平衡和路由大规模训练流量的问题。AI训练负载的主要特点包括：(a) 低熵：与传统数据中心工作负载相比，AI工作负载的流量数量和多样性更小，流量模式通常是重复且可预测的。(b) 突发性：在时间维度上，流量通常以毫秒级的时间间隔呈现“启停”特性。(c) 大象流量（elephant flows）：每个突发的流量强度可以达到NIC的线速。以下描述了我们路由设计的各个演进阶段，以应对这些挑战。
4.1 ECMP和路径固定
4.1.1 ECMP
我们最初考虑使用广泛采用的ECMP（等价多路径），它基于5元组（源IP和目标IP、源UDP端口和目标UDP端口、协议）对流量进行随机分配。然而，正如预期的那样，由于流量熵低，ECMP在训练负载中表现不佳。
由于集体通信中的大多数流量大小相同，我们使用最大-平均比（MMR），即最繁忙链路上的流量数与每条链路的平均流量数的比率来量化ECMP的不平衡性。在16条链路上的1000个流量模拟中，平均MMR超过1.2。而在实际情况中，情况更糟，如表2所示。此负载均衡不理想导致大象流量发生碰撞的可能性增大，从而引发严重拥塞，降低了网络吞吐量和任务性能。
4.1.2 路径固定
作为替代方案，在初期部署时我们设计并应用了一种路径固定方案。该方案根据目标“切片”（RTSW下行链路的索引）将数据包路由到特定路径。当每个机架完全分配给同一任务且网络无故障时，此方案效果良好。然而，这种情况很少出现。我们发现，机架可能部分分配给任务，机架中的两个主机仅一个使用上行链路带宽。该任务分配方式导致特定RTSW的上行链路流量分布不均，造成拥塞，使训练性能下降超过30%。此外，一旦上行链路或CTSW发生故障，受影响的流量被ECMP不均匀地重新分配到其他CTSW，重新分配的流量与现有流量发生冲突，导致整个训练任务变慢。
4.1.3 短期与长期解决方案
为减轻流量冲突的即时影响，我们将RTSW上行链路的带宽提高了2倍，从而使RTSW上行链路的容量比RTSW下行链路的容量少2倍。虽然此举如第6.2节所述缓解了即时性能影响，但此方案成本较高，因为需要2倍的网络容量。因此，我们将此方案视为短期缓解措施，并继续推进路由设计的进一步演进。
4.2 通过QP扩展增强ECMP
接下来，我们重新审视了ECMP，旨在通过集体库中的队列对（QP）扩展（QP Scaling）软件功能增加分层集体通信的流量数量。
4.2.1 QP扩展
QP扩展功能可通过多个QP发布消息，将每个NIC到NIC流量分散为多个流量。我们注意到，即使启用此功能并激活更多的QP，低熵问题仍然存在。调试后发现，尽管不同QP数据包的目标UDP端口按预期保持相同，但在一些极端情况下，源UDP端口也相同，导致熵未按预期增加。
4.2.2 定制哈希
为解决这一问题，我们配置了交换机执行增强ECMP（E-ECMP），利用交换机ASIC的UDF功能在RoCE数据包的目标QP字段上进行额外哈希。这提高了熵，与未进行QP扩展的基本ECMP相比，我们观察到E-ECMP与QP扩展结合在AllReduce集体通信中的性能提升可达40%（见图7）。
4.2.3 QP的权衡平衡
QP缓冲是RDMA NIC中的稀缺资源，而QP资源在排序和LLM工作负载中的使用有所不同。因此，对于排序工作负载，我们选择QP=4，因为其全网格通信（如AlltoAll）已经具有相对较高的熵。结果见图8。而对于LLM工作负载，我们使用QP扩展因子为16，因为其涉及分层集体通信，如AllReduce。
4.2.4 不同的QP扩展方法
我们评估了两种QP扩展策略。第一种方法将每条消息从单一QP分散到多个QP上，产生多个流量，但同时也在网络上产生了更小的消息量以及多个ACK。第二种方法将每条消息轮流发布到不同的队列上。基于我们在生产环境中与NCCL的测试，我们观察到后者表现较佳。此功能通过增加分层集体通信（如AllReduce）的网络流量数量，提高了ECMP的可扩展性。
4.2.5 寻求超越E-ECMP的动机
虽然我们通过QP扩展提升了ECMP性能，但此路由方案中的哈希本质具有一定的随机性是其固有缺陷。此外，根据工作负载类型自定义QP扩展因子和方法虽然在短期内可行，但长期来看增加了运营的复杂性。
4.3 集中式流量工程
ECMP和路径固定方法在硬件方面存在局限性，因此我们开发了集中式流量工程（Traffic Engineering，TE）控制器，基于我们在[5]和[31]中的经验。TE控制器根据实时工作负载和拓扑输入动态优化路由。图9展示了TE的架构概览，说明其如何优化动态路径分配。
4.3.1 控制平面
控制平面的设计包含三个部分：首先，Collector负责创建端到端训练集群的实时拓扑。它通过利用拓扑生成服务从内部数据仓库中的网络模型引导一个静态拓扑，并基于我们的内部链路状态路由协议Open/R提供的链路状态构建动态拓扑，以捕获实时网络状态。其次，TE引擎（TE Engine）结合流量矩阵采集服务提供的流量bps和训练任务调度器的任务分配，生成流量矩阵，即TE分配流的字节计数。TE引擎运行受限最短路径优先（Constrained Shortest Path First，CSPF）算法处理实时拓扑和流量矩阵，每30秒周期性地生成优化的流量分配方案。最后，交换机编程器（Switch Programmer）将流量分配转换为特定设备的数据平面原语，以实施路由决策。
4.3.2 数据平面
数据平面通过覆盖默认路由策略的方式运行。默认路由由BGP提供，确保集群中所有前缀的连接。TE基于优化后的流量分配在RTSW上覆盖这些默认路由决策，从而为RDMA流量提供主路由。TE包括能够将<源端口，目标前缀>元组与转发至下一跳的操作相关联的技术。使用源+目标元组提供了更细粒度的流量管理，同时使用目标前缀有助于在硬件中控制这些条目规模。具体而言，我们利用硬件提供的精确匹配表（Exact Match，EM）覆盖默认路由。当主条目因故障缺失时，由BGP确定的路由决策为RDMA流量提供备用路径。
4.4 TE与E-ECMP的比较
下面我们通过流量级别的网络模拟展示TE和E-ECMP的性能评估，随后是生产基准测试结果。我们还描述了每种方案的操作复杂性。
4.4.1 模拟
生产环境下的任务调度模拟结果显示，在非最优任务调度场景下，对于每个源-目标对使用4个QP的E-ECMP，平均完成时间比理想状态延长了40%。将QP扩展至32可改善性能：最差情况从理想状态的20%提升至52%。然而，大多数任务仍无法达到理想状态。相比之下，TE在网络有足够容量时可以实现100%的利用率。然而，当链路可用性由于故障下降至低于1:1的订阅比时，E-ECMP可能表现优于TE。
4.4.2 基准测试评估
在受控环境中，使用真实NCCL基准测试[16, 24]观察到，TE在16条上行链路的设置中相比E-ECMP实现了更均衡的链路利用率。在E-ECMP下，链路利用率波动较大：在最大带宽的40-90%之间，而TE则能稳定地达到最大带宽的80%，降低了最差情况的影响。如图10所示，在固定的集群规模（128个训练节点）下，TE在AllReduce和AlltoAll集体通信中的性能比E-ECMP高出5-10%。
4.4.3 TE的操作经验及经验教训
我们在基于排序的AI Zone中部署了TE，以E-ECMP作为备用路由方案来处理因故障导致的流量。我们观察到TE在有效负载均衡方面与早期的路径固定路由方案相似，在仿真和基准测试中表现良好（见第6.2节）。然而，仿真和实际部署显示，TE在网络中多条链路发生故障时也容易出现性能下降问题。我们最初认为这些情况在仿真中较为罕见，但在实践中发生频率比预期高。此外，TE增加了软件复杂性和管理开销。在AI Zone的部署中可以管理，但在数据中心规模上未使用TE，因为更大网络规模将导致更高的复杂性和开销。计算上，由于需要处理另一层交换机（ATSW）和伴随的路径多样性，TE的计算负载增加。E-ECMP因此在数据中心规模集群中提供了更好的操作折衷。因此，TE主要用于以排序任务为主的集群，而E-ECMP是数据中心规模部署的主要路由方案。
4.5 未来方向：Flowlet切换
尽管TE和E-ECMP分别在不同部署中应用，但正如前文所述，每种方法都存在操作上的权衡。Flowlet切换[35]是一种替代方案，用于解决这些路由方案所面临的问题。此技术[35]依赖于在流量中寻找间隙。当找到流量中的间隙时，Flowlet引擎会根据负载将流量重新分配到新的ECMP成员端口。这是一种由首跳交换机（RTSW）支持的硬件辅助方案，能够以微秒级粒度响应端口负载的变化。在测试中，此方案在链路负载均衡方面表现出更佳效果，尤其是在拥塞和多链路故障的情况下。此方案的适应性帮助它在所有工作负载中以最小的QP扩展（4）实现了可扩展性。不需要基于具体工作负载进行定制的QP扩展，这减轻了E-ECMP的相关问题。硬件支持该方案有助于缓解TE在软件复杂性方面的顾虑。
乱序数据包：由于在活动流上进行路径重新分配，流量的重新分配可能导致数据包乱序。管理乱序数据包是此技术的一个重要方面，需要对flowlet间隔进行调整。理论上，该间隔需要约为网络往返时间的一半，以确保同一流中的前一批数据包至少已到达目的地后，才重新分配路径，从而大幅减少数据包乱序的发生。如图11所示，随着间隔的增加，乱序数据包数量呈非线性下降。在256-512微秒的flowlet间隔范围内，乱序数据包少于1个/秒。另一方面，缩短flowlet间隔将导致更积极的负载均衡。然而，负载均衡的过于激进在性能上会有递减收益。例如，在200G实验环境下（图11），对于A2A集体通信，在256微秒和512微秒的flowlet间隔之间，性能差异并不显著。我们能够调整flowlet间隔以在实现最优负载均衡和吞吐量的同时，将乱序数据包的影响降至可忽略不计的水平。
基于负载的路径分配：在高间隔条件下，Flowlet切换倾向于类似ECMP，其中流量在流的整个生命周期内静态分配端口。有趣的是，即使在这种场景中，Flowlet切换表现出的负载均衡效果仍优于ECMP，这是因为它基于端口质量（负载）而非哈希来选择初始端口。因此，即便在流的生命周期内路径不发生变化，Flowlet机制仍能基于当前端口负载做出更优的路径选择决策。在无长期流量的工作负载中，我们仍能从此机制中获益。
状态：在初始测试中我们发现，Flowlet切换能够以更低的运营成本实现与TE相似的性能。Flowlet切换的未来推广计划将取决于早期部署的信号。我们将在未来工作中涵盖此类推广的结果以及更深入的权衡分析。
4.6 讨论
最初，我们发现由于ECMP效率低下导致链路利用率低，并导致性能不稳定[9]。为缓解这一问题，我们临时扩建了网络。与此同时，我们通过多个阶段改进了路由，包括静态路由、动态路由和流量工程，以实现稳定和高效的训练。路由方案的演变及其对性能稳定性的正面影响将在第6.2节中基于生产数据进行展示。考虑到分布式训练工作负载的不断发展，我们相信这是一个重要的持续研究领域。
5 传输层
本节深入探讨传输设计及与第2.4节列出的网络拥塞相关挑战的解决方案。第4节讨论了解决因负载均衡效率低下而导致的持久拥塞的方法。即便流量分布完美，像AlltoAll这样的集体通信模式也可能引起瞬时缓冲区积压和微爆现象，如表2所示。这种现象需要流量控制和拥塞控制，以避免流量丢失并实现可预测的尾部延迟，从而获得可预测的性能。我们将首先描述利用DCQCN的初步尝试，以及我们如何转向在集体库层面通过接收端驱动的准入控制（receiver-driven admission control）来管理拥塞。
5.1 实现
我们实施了多种传输配置，以在RoCE环境中实现高带宽、低且可预测的延迟。我们与NIC供应商合作，以支持具有Linux内核驱动的GPUDirect，从而更好地管理软件栈。我们在所有网络交换机和NIC上使用基于DSCP的PFC和单个无损队列，防止在三层网络连接中出现数据包丢失。我们依赖于“回退N”重传机制（go-back-N re-transmit）来应对由于不健康的网络组件或链路波动导致的罕见数据包丢失。然而，确认数据包（ACK或NACK）上的数据包丢失可能导致持续数毫秒的本地ACK超时（Local ACK Timeout，LAT）。因此，快速识别和隔离不健康的网络组件和链路，以及谨慎调整LAT持续时间，对于可预测的训练工作负载性能至关重要。
5.2 拥塞控制
尽管PFC（优先级流控）有助于避免因拥塞导致的数据包丢弃，但在持续拥塞期间逐跳的PFC传播可能导致头阻塞（HoL），从而引发流量不公平和性能下降。在200G部署中，我们最初采用了此前RDMA部署推荐的DCQCN（数据中心拥塞控制机制）。我们的实施步骤包括：a）交换机在拥塞事件期间对在途数据包进行ECN标记；b）接收端NIC生成并发送拥塞通知包（Congestion Notification Packet, CNP），提示需减缓流量；c）发送端根据接收到的CNP减小相应流量的注入量。
5.2.1 DCQCN在集体通信中的调优局限
在200G和400G RDMA部署的实践中，我们发现DCQCN这一RoCE中广泛应用的拥塞控制机制对于训练集体通信的效果有限。
调优DCQCN具有挑战性：最初，我们在200G RDMA部署中采用了严格的ECN阈值配置以最大限度减少PFC的触发。然而在实际应用中，虽然严格的阈值有助于避免PFC，但在某些极端情况下，这显著降低了集体通信的吞吐量表现。尽管本文未展示极端情况下的回归数据，图12展示了在32 GPU的AllReduce基准测试中，严格的ECN阈值导致集体通信完成时间轻微增长（约5%）。
因此，我们在CTSW中恢复为放宽的ECN阈值（5 MB）并在128 GPU的AlltoAll测试中优化了NIC中的其他DCQCN设置。该测试呈现了训练中的最差拥塞和队列积压情况。我们尝试了激进和放宽的DCQCN设置。图13展示了在几种不同的放宽DCQCN设置组合下，完成时间略微缩短（约3%）。但在所有情况下，拥塞指标如PFC恶化了2-3倍，这降低了我们通过DCQCN避免头阻塞和延迟增加的初衷。
因此，我们在CTSW中保持放宽的ECN标记，允许缓冲区积压，同时保留默认的DCQCN设置。
400G的经验：在400G部署的过程中，我们尝试进一步调优DCQCN以适应新的网络速度和拓扑。然而，即使采用了默认DCQCN设置和较200G网络加倍的ECN阈值，性能依然受到了影响。进一步调查发现，固件中的DCQCN实现发生了变化，引入了计数CNP错误等问题，且降低了可见性。最终，在400G部署中我们未使用DCQCN，转而仅依靠PFC进行流控，不涉及任何其他传输层拥塞控制（但在高层集体库中仍使用拥塞管理机制）。我们观察到训练集体通信性能稳定且无持续拥塞现象。此决策的间接好处在于便于监控，在网络中遇到慢速接收端或瞬时拥塞时，可通过监测NIC暂停持续时间来评估影响，从而得知其停止发送或接收的时间百分比，而不必同时查看拥塞通知包和PFC指标。
5.2.2 通过集体库的接收端驱动流量准入
为缓解400G及以上的拥塞，我们协同设计了集体库与RoCE传输，以实现接收端驱动的流量准入，从而提高性能。图14展示了生产训练集群中GPU到GPU通信架构，主要采用两阶段复制和通过NCCL集体库进行的接收端通信。每个GPU的高带宽内存（HBM）维护多条通道以并行传输分块的集体消息。发送端GPU线程首先将数据从计算缓冲区复制到可用的通道缓冲区。仅在接收到来自接收端的发送许可（CTS）数据包后，发送端CPU代理线程才会发起RDMA写请求，CTS数据包包括大小和内存信息。接收端GPU线程再将通道缓冲区内容复制到目标计算缓冲区。最后，双方的CPU代理线程回收通道缓冲区，且接收端CPU代理在通道缓冲区准备好后发送另一个CTS数据包。
我们有效地利用此机制作为接收端驱动的流量准入，以限制网络中的在途流量量，尤其是在拥塞开始积累时。然而，正确的配置设置仍然具有挑战性，因为：1）由于GPU线程资源竞争，通道数目受到限制；2）通道缓冲区大小的设置需更仔细地平衡拥塞传播与带宽利用率，以应对RoCE的粗粒度流控和可能的端主机速度不一致问题。
因此，我们采取了两个步骤以提高性能。首先，在不同训练作业大小和集体通信类型中实验确定了适当的通道数和通道缓冲区大小参数。其次，我们在交换机中为CTS数据包实施了高优先级队列，以加速通知并减轻潜在的带宽饥饿问题。
为了展示此机制的有效性，我们在400G网络上仅启用PFC的情况下进行了16:1汇聚实验，如表3所示。我们对比了流量生成器Perftest [27]与一个循环NCCL Gather集体测试。尽管Gather集体在我们的生产训练中很少使用，但它在集体通信中生成最严重的汇聚，充分考验了我们的机制。两个测试均运行五分钟，产生相同流量的16:1汇聚。我们在Perftest中观察到头阻塞现象。CTSW中的深缓冲区吸收了大量拥塞，但不足以防止反压传递至发送端NIC。然而，在Gather集体情况下未观察到PFC反压。为了模拟生产中观察到的慢速接收端场景，我们进一步将Gather集体中接收端的带宽限制至仅为其容量的25%。我们发现我们的机制能适应吞吐量变化。接收端NIC在RTSW上发送的TX暂停持续时间达75%，但RTSW吸收了全部拥塞，未对CTSWs产生反压。
此实验突显了集体库通过接收端驱动流量准入控制网络拥塞的效果。
5.2.3 吸收网络内部拥塞
我们的AI区基于两级Clos架构（见3.2节）。我们在RTSW中使用了具有共享和浅缓冲架构的交换机，而在CTSW中则使用了深缓冲交换机。通过在端口上静态划分了这些大型缓冲区，我们有效利用了它们。这种较大的端口缓冲区有助于吸收瞬时拥塞，并确保面向端口的反压以减少跨端口的头阻塞。鉴于我们骨干交换机的高阶交叉能力，我们将这种无阻塞架构视为最小化拥塞的附加保障层。
5.3 讨论
拥塞控制一直是RDMA网络研究的重点领域【15, 43】。DCQCN在面向存储的网络中被视为“黄金标准”。但我们在分布式AI训练工作负载中的经验提供了一个不同的视角，需针对特定需求调整拥塞控制算法。尽管在过去4年中关闭了DCQCN，并使用多个RTSW向深缓冲的CTSW发送PFC，我们并未遇到生产AI训练流量导致CTSW持续向RTSW发送PFC的情况。特别值得评估的是在不使用传输层拥塞控制的情况下进行操作的可行性。当前的解决方案依赖于集体通信库与网络之间的精确协调，并可能依赖于GPU与网络间的相对吞吐量，这在所有场景中未必适用。我们鼓励研究社区在这一主题上投入更多关注。
6 经验总结
6.1 网络与集体通信的协同调优
在实现接近AI训练工作负载的理论上限通信性能过程中，我们进行了对集体通信库、传输和网络层相互作用的调优。我们在许多情况下将RoCE的原始性能提升了2倍以上，如图15所示。
我们观察到，NCCL在原始状态下可能表现欠佳，这主要是由于开发者的环境与我们的生产环境存在差异。开发环境的某些假设包括：极低的RTT延迟（<10微秒）、自适应路由机制、无过订阅的非阻塞拓扑。这些假设导致在架构中做出了一些次优选择，如在发布小消息时进行的两阶段复制；依赖于关键路径中的控制消息（CTS）的接收方发起架构；以及在大型组（例如Ring用于AllGather）中积累延迟的有限逻辑拓扑。在适应性方面，我们生产环境中的NCCL能够学习并适应服务器拓扑，但缺乏对网络拓扑的默认感知。
更高的空闲RTT：在我们的生产环境中，由于CTSW交换机采用虚拟输出队列（VOQ）架构，且需要从出队队列向入队队列交换信用信息，导致了更高的空闲RTT（约22微秒）。这种高延迟要求对传输的消息大小进行调整，同时确保网络上有更多的未完成数据。这包括调整通道缓冲区大小及传输消息大小，以达到最佳性能。对于AllGather、ReduceScatter等对延迟敏感的集体操作，增大消息和中间缓冲区的大小提升了性能。
会合消息的性能影响：接收方发起的通信架构依赖于Clear to Send（CTS）和确认（ACK）等会合消息。在生产环境中，我们观察到拥塞积累导致这些消息在返回路径上的延迟。我们在NCCL中添加了测量发送方等待这些消息的平均延迟的功能，成功将延迟从P90的43微秒减少到4微秒。更改CTS消息的QoS优先级作为集体库的改进措施得以实施。对于ACK数据包，我们利用RTSW ASIC的功能修改了DSCP标记，以使其进入不同优先级。
小消息：NCCL【25】针对小规模集体操作通过以下两种策略实现最佳性能：1）使用不同的逻辑拓扑来实现同一集体操作，例如Tree与Ring；2）使用不同的低延迟或高带宽协议（如Simple、LL128、LL）来应对在跨越GPU内存与PCIe/RDMA边界时的内存屏障。每种拓扑或协议在集体操作规模较小时或较大时都可能是最优的。然而，选择特定逻辑拓扑或协议的时机由一个静态调优模型计算，该模型假设了较低的网络延迟（无论负载如何）。这导致了不利的权衡和较差的性能。我们在下面解释了逻辑拓扑与协议的延迟权衡。
在实现小规模或中等规模集体操作的最佳性能时，我们通过调整调优算法来选择递归逻辑拓扑（Tree）或使用更大消息传输的拓扑（基于轨道的Alltoall）以及协议（LL128），这在比NCCL默认选择的集体规模更大时更为适用。发布较大消息有助于减少CTS和完成消息的数量。
CTSW延迟：尽管上述调优确保了集体操作性能达到我们的基线RTT的最佳水平，但我们也通过使用VOQ架构的CTSW减少了RTT。这包括更积极的出队至入队端口的信用分配，无论是在初始分配还是在信用的增长曲线上。对于层次化集体操作，尤其是对延迟敏感的小规模操作，我们注意到性能提升了15%。其他增强措施包括调整NIC的PCIe信用和放宽排序、基于网络拓扑的排名分配，以及消除由NIC发送的0字节消息导致的问题，虽然这些问题被InfiniBand支持，但以太网交换机不支持。这些改进确保了我们的RoCE网络能够在较高网络RTT下为AI训练提供最佳性能。
6.2 路由与拓扑的影响
我们从路由与拓扑的角度检视了ZionEX AI Zones（基于200G）的发展历程。图16显示了每个阶段（时间段）数万个作业的性能，按标准化AllReduce集体带宽【24】量化。
第1阶段的后台网络拓扑从RTSW到CTSW的订阅比为1:1，而第2阶段的拓扑为1:2的欠订阅。第1阶段和第2阶段都使用静态路由，并存在流量冲突。在从第1阶段迁移到第2阶段后，随着额外容量的增加，性能显著提升。第1阶段性能低且不稳定的原因是前述静态路由引发的流量冲突。第2阶段的欠订阅解决了这一性能问题，但需要投资2倍的网络基础设施。
第3阶段显示了在网络环境迁移到流量工程控制后，依旧保持1:2欠订阅时的性能。可以看到其性能与第2阶段相似，但更为稳定。在第4阶段，我们进一步将欠订阅比降至1:1.125，从而在不影响性能的前提下回收了CTSW的硬件资源。我们并未完全将欠订阅减少至1:1，以便在多达两条链路故障时提供缓冲。
6.3 可观测性工具
在运营这些RoCE后端网络时，我们需要对所有网络组件（包括网络架构、路由、传输层）以及集体通信进行可观测性管理，以便快速排查故障或解决工作负载变慢的问题。
6.3.1 面向任务的网络错误
RDMA对网络问题极为敏感，因此会影响GPU训练效率。为了快速检查训练工作流背后的RDMA网络状态，我们建立了遥测系统，自动收集网络交换机、NIC、PCIe交换机和GPU的RDMA硬件计数器。我们确定了三个关键计数器来识别网络问题：(1) Out-of-Sequence（OOS）：由NIC检测到的乱序数据包数量。这有助于我们识别并分析由于网络交换机异常或NIC硬件缺陷导致的多次丢包现象。某些情况下，这种传输指标显示问题存在，但其他地方未报告任何丢包。(2) Link Flap计数器：该计数器可以指示NIC检测到的硬件和软件链路抖动。(3) Local Ack Timeouts（LAT）：发送端的队列对（Queue Pair）的ACK定时器超时次数。超时会影响性能并在某些情况下导致任务失败。在RoCET系统中，当任务失败时，这些计数器会直接报告给用户，明确提示网络中某些组件可能存在异常。
6.3.2 面向运维的网络错误
我们在网络中构建了防护机制，不仅监控和检测异常，还执行自动缓解措施以修复其中的许多问题。
PFC Watchdog：在RTSW和CTSW设备上启用该功能，用于捕捉由于死锁或异常NIC持续发送PFC帧导致的长时间PFC暂停（超过200毫秒）。
缓冲区阈值与拥塞丢包：我们在RTSW设备上监控缓冲区使用情况。当缓冲区利用率超过80%时会发出警报，这通常表示持续的拥塞或存在bug。在实际操作中，我们未曾超过此阈值。此外，我们还监控因拥塞导致的数据包丢失。由于我们网络是无损网络，这种丢包不常见，主要是由于配置错误导致。
可达性：我们有多种内部工具，定期通过向不同节点发送ping包检测网络设备的健康状态和连接性，以检测网络中的正常运行状况或异常丢包和延迟。
6.4 故障排查案例
在本节中，我们分享一些案例，展示运营这种RoCE网络的复杂性。
6.4.1 性能基线
在一次集群启动时，我们检测到性能回退。我们发现所监控的拥塞指标均在基线范围内。进一步调查显示，唯一的差异是CTSW上使用的软件映像版本不同。在将CTSW映像降级到基线版本后，性能数据重新对齐。随后，我们与供应商合作以了解这两个版本之间的差异，并发现设备的内部数据包调度更改导致了端口间更高的延迟。该事件表明我们需要在后端网络中进行持续的延迟监控，无论是在负载下（有拥塞）还是在空闲时（网络不饱和）。
影响：该问题显示了需要在负载和空载条件下测量并监控延迟，以确保我们能发现由各种因素引起的回退。我们现在通过生成合成流量和库仪表化来捕捉这些数据，并建立基线。
6.4.2 AI训练任务的动态特性
我们在迁移到支持TE控制器的训练集群中，观察到几个CTSW报告了RoCE流量丢失。此次迁移涉及对CTSW进行重新配置、QoS设置更改、RTSW的路由调整以及NIC的PCIe信用升级。仅有少量交换机在迁移后报告了流量丢失，但总体丢失量足以影响某些任务。
经过调查，我们将问题追溯到多个并行事件的复杂交互。流量丢失的主要原因是对CTSW中SRAM缓冲区大小的旧假设导致的错误。当缓冲区超过一半时，流量会尾部丢包。SRAM缓冲区溢出仅在某些加剧因素组合下出现，包括：(1)一次固件升级，使RoCE数据包传输更为激进；(2)具有突发流量模式的训练任务；以及(3)引入H100 GPU，这些设备具有更强的计算能力和更高的I/O需求。
影响：该事件显示在部署更改前进行全面验证和性能回归检查的重要性。需要注意的是，在面向AI训练任务的RoCE网络问题中，我们必须应对训练任务的动态特性。大部分训练任务具有实验性，因此很难预测其流量模式并进行彻底的端到端测试。该事件强调了具备有效的检测和报警系统以便快速识别和响应问题的重要性。
7 相关工作
RDMA网络的部署经验：传统上，RDMA网络主要应用于存储领域，以降低CPU开销和网络延迟【3, 6, 9, 19】。已有大量研究致力于解决RDMA大规模部署中的问题，如拥塞控制【15, 43】、可靠性【9, 10, 28, 38】和性能隔离【40】。据我们所知，我们是首个全面呈现大规模AI训练部署RDMA网络所面临挑战和经验的团队，包括拓扑、路由和运维等方面的深入探讨。
AI网络改进：已有许多研究致力于优化AI工作负载的网络性能。例如，现有工作提出新的网络拓扑【36, 37】，以更好地适应分布式训练的流量需求和特性。BytePS【12】通过有效利用CPU和带宽资源加速了分布式训练，同时许多研究也在探索如何利用网络带宽加速集体通信【4, 30, 32】。【29】提出了一种结合拥塞控制和调度的创新方案来加速训练。本文通过分享我们在AI训练中优化RDMA的大规模部署经验和最佳实践，进一步展示了RDMA在AI训练中的巨大潜力。
网络与AI的协同设计：先前的研究已经证明了网络通信与AI训练协同设计的优势。例如，TPU集群通过3D并行化优化了大模型训练【13】，而Neo与ZionEX结合4D并行化优化了大规模DLRM训练的通信【20】。有些研究还提出了自动化模型并行化的方法【34, 42】。本文中，我们分享了类似的协同设计原则，强调了通过深入理解分布式训练工作负载的速度、规模和集体通信需求，对RDMA网络进行针对性优化，从而为分布式AI训练基础设施的进步做出贡献。
8 结论
为了满足日益增长的计算密度和规模需求，大规模RoCE网络的设计和运维已经逐步演变，以更好地支持分布式AI训练工作负载。通过分离前端网络和后端网络、采用多种路由方案以及优化集体流量模式，我们成功构建了高性能且可靠的网络基础设施。这些设计和洞见强调了深入理解训练工作负载的重要性，并表明将这些理解转化为网络组件设计，是推动分布式AI训练基础设施发展的关键。
参考资料：Gangidi, A., et al. (2024). RDMA over Ethernet for Distributed AI Training at Meta Scale. Proceedings of the ACM Symposium on Operating Systems Principles. Retrieved from https://dl.acm.org/doi/10.1145/3651890.3672233.
---【本文完】---
近期受欢迎的文章：
更多交流，可加本人微信
（请附中文姓名/公司/关注领域）