史上最全大语言模型训练中的网络技术盘点

作者简介:张景涛,陈永铭,主要研究方向为领域定制架构的演进及关键技术。

编者按:大语言模型的爆发式增长对网络提出了更高要求,产学研各界纷纷开始探索,围绕网络架构、网络协议等取得了丰富的实践进展。本文不同于其他只是局限于网络协议类详解的文章,从多维角度立体分析了大语言模型训练中的网络技术应用,以飨读者。

1.引言

人工智能的基础设施在大语言模型训练和推理过程中发挥了关键的作用。随着大语言模型规模不断增大,其对计算和通信的需求也在不断增加。高性能网络是人工智能基础设施的重要组成部分,引起了业界的广泛关注。

大语言模型(Large Language Model)的扩展定律[40]和涌现能力[9]驱动大语言模型参数数量的持续增大,目前大语言模型的参数规模已经扩展到万亿级别,如此巨大的训练任务远超单个服务器的计算和存储能力,需要通过构建包含大量服务器的高性能计算集群来共同完成这些任务。这些服务器节点之间通过高性能网络互联,将工作负载分布在多个节点上加速训练过程。因此,网络性能直接决定了这些服务器节点间的通信效率[31,32],进而影响整个计算集群的吞吐量和性能。并且随着模型规模持续扩大,其带来的分布式训练规模和通信量将会井喷式增长。

综合目前业界的应用以及当前的技术现状,大语言模型的训练网络主要面临着以下重大挑战:

大规模并行扩展:大语言模型的训练需要在数千甚至数万个GPU上进行并行训练,这给网络组网带来了巨大的挑战,需要设计高效的网络拓扑结构和路由算法。

高通量和低延迟:大语言模型训练过程中,不同的GPU之间需要交换大量的数据[23,24]。这可能会导致通信瓶颈[31,32],进而影响训练的效率。尤其是对于大语言模型训练任务而言,整体训练进度的完成往往取决于最后一条消息的到达时间,这使得网络尾延迟指标的重要性大大提高。

高昂的网络成本:大语言模型训练网络的建设和维护成本非常高昂,需要探索新的方法来降低成本,使LLM训练网络更加经济。传统上分布式训练系统网络相关的成本[25]只占到整个基础设施成本的10%左右,而大语言模型的网络成本占比已经提高到总成本的20%。

高可靠和高可用:大语言模型的训练周期比较长,计算节点和网络故障都会导致整个训练过程的重启,进而导致整个训练周期的延长,因此大语言模型的训练对网络的可靠性和可用性有着更高的要求。据统计,在某个千亿大模型的训练总时长中[11],真正用于模型训练的时间只有50%,其他时间都用于处理故障以及进行断点恢复。

本文进一步研究和探讨网络技术在大语言模型训练中的应用。首先阐述了同构和异构网络的特点与优势,然后针对网络的关键技术点,综述互联协议、网络拓扑、拥塞控制等技术在大语言模型训练中的研究进展和成果。随之介绍了业界知名的大语言模型训练网络,并讨论了大语言模型训练网络的未来发展趋势。

2.训练网络分类

大语言模型训练网络有很多种分类方法,比如英伟达根据训练网络的规模、支持的业务类型和用户数量等维度,将网络分为AI factory和AI cloud两种类型。

本文从网络技术类型角度将训练网络分为同构网络和异构网络两种:

1、同构网络以Google TPU为代表,通过使用ICI互联协议,采用3D的环形网格网络构建TPU集群;
2、异构网络以英伟达 GPU训练服务器为代表,网络整体是由两个子网络组成,第一个子网络(使用NVLINK或者其他自研的高速总线)用于服务器内部的加速器之间的互联,另一个子网络(使用以太网、RoCE或者IB)用于服务器之间的高速互联。

2.1.同构网络

业界知名的同构网络类型,其中之一就是Google TPU使用的自定义网络,另外一个就是Intel的Gaudi2 全RoCE互联方案。

图1 Google TPUV4 组网拓扑

Google TPUV4[3]使用自定义网络协议ICI进行高速互联,ICI网络是TPU集群专用网络,在ICI网络内部由64颗TPU和16颗CPU组成一组(即称为一个TPU Slice),通过直连的铜质电缆连接在4*4*4的三维 Cube里面,而在这个ICI网络之外就是OCS光学背板互连。Google SuperPod在AI工作负载方面具有性能和总拥有成本的优势,这得益于TPU从微架构到系统架构的整体设计,旨在协同特定模型和算法,以充分发挥出极致的并行性能和扩缩效益。

图2 Intel Gaudi组网示意图

Intel的Gaudi处理器[12,15]突破传统,采用了独特的设计策略。不同于使用高性能总线进行节点内部互联,Gaudi直接在处理器内部集成了RoCE接口。例如,Gaudi2内部整合了21个100G RoCE接口。在HLS-1(类似于英伟达的DGX服务器)中,支持8块Gaudi加速卡,每块卡利用7个100G RoCE接口实现了八块卡之间的全连接(all to all)互联。此外,另外的14个100G RoCE接口用于实现HLS-1服务器之间的互联。

2.2.异构网络

以NVIDIA为代表的异构网络组网模式,保证了系统的整体性能并降低系统组网成本。H100的GPU服务器[30]由8个搭载ConnectX-7 NIC的GPU组成,这些GPU可以通过连接到NVSwitch的高速NVLink互相通信,各个GPU通过每个方向上3600Gbps的NVLink连接到一组NVSwitch。服务器内的8个GPU可以通过其 400Gbps的ConnectX-7 NIC连接到外部交换机。

图3 Nvidia DGX H100服务器

3.关键技术点

3.1.互联协议

大语言模型网络的互联技术通常分为两类,一类称为总线互联协议(典型总线包括NVLink、PCIE、CCIX、CXL等),用于加速芯片之间短距离、小规模和高通量互联;另一类称为网络互联协议(典型网络互联技术包括RoCE、iWARP、infiniband等),用于服务器集群之间进行长距离、大规模的数据通信。

随着总线和网络技术的发展,这两类技术已经出现了逐渐融合的趋势,比如英伟达NVLink4.0已经可以支持256个GPU的互联,CXL在其规范中也提到将来支持机架间的互联。

表1互联协议对比

3.1.1.总线互联协议

常见的总线互联协议包括英伟达的NVLink[14]、AMD的infinity fabric[63]、PCI-SIG组织发布的PCIE[64]和CXL联盟推出的开放式互联新标准CXL[62]。英伟达的NVLink是目前大模型训练网络中最具代表性的总线互联协议,本章将以其为主线进行介绍。

NVLink于2014年3月的NVIDIA GTC 2014上发布,2016发布的P100是搭载NVLink的第一款产品,单个GPU具有160GB/s的带宽,相当于PCIe Gen3 * 16带宽的5倍。GTC 2017上发布的V100搭载的NVLink 2.0将GPU带宽提升到了300GB/s,大约是PCIe的10倍,到了最新一代H100支持NVLink4.0,双向带宽更是提升到了900GB/s。

图4 Nvidia NVLink路标

通过分析现有与NVLink协议相关的技术论文[6],可以得到以下结论:

1.在底层链路延迟方面(NVLink2.0 VS PCIE 3.0),NVLink只有PCIE延迟的55%;
2.系统的延迟不仅取决于底层链路延迟,还与软硬件的整体配合关系巨大。在reduce场景下,NVLink延迟意外高于PCIE协议(18us VS 14us),但是在Broadcast、reduce_scatter、all_gather场景下延迟更低,且不同通讯模式下NVLink延迟表现非常稳定。

用于连接 GPU 服务器中的 8 个 GPU 的 NVLink 交换机也可以用于构建连接 GPU 服务器之间的交换网络。Nvidia 在 2022 年的 Hot Chips 大会上展示了使用 NVswitch 架构连接 32 个节点(或 256 个 GPU)的拓扑结构。由于 NVLink 是专门设计为连接 GPU 的高速点对点链路,所以它具有比传统网络更高的性能和更低的开销。

表2 总线协议对比

3.1.2.网络互联协议

表3 InfiniBand与RoCEv2技术特性对比

自1999年问世以来,InfiniBand(简称IB)[29,34,35]一直被视为高性能互联的替代技术,在服务器、存储和网络基础设施中得到广泛应用。由于其高速率、低延迟和零包丢失的特点,IB长期在高性能计算、AI集群和数据中心领域处于应用的前沿地位。

IB协议秉持简单高效设计理念,同时支持多种通信模式,通过基于信用的流量控制实现设备间的零丢包传输目标。IB交换机全面支持远程直接内存访问(RDMA),从而实现GPU间的直接内存互联。然而,在架构和扩展能力方面,IB存在一定局限性。

相比之下,以太网应用范围更广,通过优先级流量控制(PFC)等机制实现零丢包传输,并通过RoCEv2[26,27,28,33]实现了RDMA封装传输。随着技术的进步,以太网在大规模AI集群中替代IB的程度不断增加。代表性的拥塞控制方案如DCQCN、HPCC等已得到广泛应用,部分云服务商已经使用了规模超过32KGPU的以太网架构。

2023年7月,由英特尔、AMD、惠普企业、Arista、Broadcom、思科、Meta和微软等长期深度参与HPC和网络领域的公司牵头,共同宣布成立超以太网联盟(Ultra Ethernet Consortium)。该联盟的目标是创建一个“基于以太网的完整通信堆栈架构”,使其像以太网一样具有普及性和成本效益,同时提供超级计算互连所需的性能。联盟明确了以下理想特性:灵活的传输顺序、现代的拥塞控制机制、多路径和分组喷射,以及更大的可扩展性和端到端遥测。

中国移动联合合作伙伴共同推出了全调度以太网(GSE)[42]。全调度以太网是具备无阻塞、高吞吐、低时延的新型以太网架构。全调度以太网架构自上而下分为三层,分别为控制层、网络层和计算层,引入一种全新的动态全局队列调度机制。动态全局调度队列(DGSQ)按需、动态基于数据流目标设备端口创建,为了节省队列资源数量,甚至可以基于目标或途经设备的拥塞反馈按需创建。基于 DGSQ 的调度可实现在整个网络层面的高吞吐、低时延、均衡调度。

总体来看,随着RoCEv2等技术的成熟[27]、全调度以太网[42]以及超以太网联盟[36]的成立,以太网在AI集群互联场景中的地位不断提升,多种网络互连技术在持续进化中共同推动着计算互联的发展。

3.2.网络拓扑

大语言模型训练网络对网络拓扑的规模、扩展性、网络直径、可靠性、功耗和成本提出了更高的要求,比如训练网络的扩大需要设计更小的网络直径来降低网络延迟,具体拓扑选择上也需要考虑组网需要的路由器、线缆带来的互联成本,网络拓扑需要具有足够的扩展性以支持后续规模的动态扩容等等。

在高性能计算的发展中,Torus无疑占据了比较重要的位置,比如cray的T3D、T3E均采用了3D Torus的结构。随着硬件条件的成熟,高维的Torus结构也已经被很多主流的高性能计算系统采用,最典型的就是fujisu公司推出的K computer采用的6D Torus结构。

胖树结构[20]是目前在大语言模型训练网络中常见的拓扑结构,胖树是一个灵活性和扩展性都比较好的拓扑结构,随着网络规模的扩大,其二分带宽也会随着等规模增加。

图5 胖树拓扑图

相比于Torus结构,胖树网络路由算法更容易实现,有更低的网络直径,网络性能相对出色。但是胖树网络在扩展至更大规模网络时需要增加网络层数,从而导致链路数随之指数增长,会大大增加网络成本。

Dragonfly是由John Kim等人在2008年的论文[5]中提出,它的特点是网络直径小、成本较低,对于高性能计算有着非常大的优势。现在已经被运用在使用Cray XC系列网络的各种超算中。

图6 DragonFly拓扑图

Dragonfly网络虽然在成本、降低交换芯片连接端口数量等方面有一定优势,但是面对整体网络计算节点的增多,Dragonfly、Dragonfly+等网络结构依然要面临网络连线较为复杂,网络总体设计成本仍然偏高以及整体网络所需的全局光纤数偏高等挑战。

除了上述拓扑结构,腾讯的星脉网络[58]、MIT和META的rail-only[8]等还提出了定制化拓扑结构,这些拓扑结构专门针对大语言模型的通信需求进行设计,旨在提升性能的同时显著降低成本。

3.3.拥塞控制

大语言模型训练作为典型的大规模数据密集型应用场景,为了应对不断增长的高吞吐量和超低延迟需求,优秀的拥塞控制算法成为必要的配置。

现有的拥塞控制算法可以根据拥塞控制驱动点的位置,即发送端、交换机或接收端进行分类。发送端驱动的方法中发送端利用在ACK数据包中携带的信息判定拥塞并触发控制动作,如DCTCP[47]、DCQCN[49]、TIMELY[48]和HPCC[50]。DCTCP[47]是数据中心网络的第一个拥塞控制算法,它利用ECN标记在往返时间内调整速率。DCQCN[49]与DCTCP类似,但更准确地结合了ECN信息。TIMELY[48]则基于RTT进行控制。HPCC[50]利用每一跳带内网络遥测(INT)来调整速率和发送窗口。此类方法较为成熟部署也最为广泛,但它们往往受到长反馈延时的影响,难以有效应对瞬时突发流量。此外,在这方向上近些年一些基于强化学习的拥塞控制算法也不断出现,如RL-CC[51]、DeepCC[52]和Pareto[53]等。

交换机侧控制的方法是在交换机上监控流量生成显式反馈控制报文来减少控制环路的延迟。RoCC[56]基于交换机上的队列长度,通过PI(Proportional Integral)算法实现控制。PACC[54]则以动态间隔监测队列长度,区分突发流量和拥塞,并直接从交换机生成通知。此类方法较为精确但是又往往依赖于特殊的交换机,限制了部署的范围。

接收端驱动的方法在接收端检测拥塞状况并产生驱动报文以调节流量。例如RCC [55]结合了显式窗口分配和迭代窗口调整并在接收端实现控制。

3.4.运维技术

大语言模型训练网络不同于传统的数据中心网络,具有训练周期长,中断次数多特点,其特殊的流量特点要求网络运维有更高精度的流量采集能力、更精细化的流量统计能力以及更全面的对流控相关指标的采集和统计能力。只有具备上述能力才能更好使用整个训练网络,快速的发现和定位问题。

《智算中心网络架构白皮书》[10]中认为运维技术的关键技术包括:1)可视化网管系统,实现对整个集群网络和节点内部网络的可视化;2)高精度流量采集,利用交换设备上telemetry功能,具备秒级流量统计、按需订阅和高性能的特点;3)数据可视化展示,通过telemetry采集各项指标,用户选择性的进行前端展示;4)智能化运维,实现自动故障分析、定位和修复。

《星河AI网络白皮书》[11]中首次提出了三层两维可视化运维方案,三层主要是指覆盖基础网络运维、RoCE无损网络通用场景运维和AI网络特有场景运维。两维主要指从监控和排障两个维度,针对三层场景,提供运维和能力手段。

3.5.在网计算

在网计算功能使得网络内部的硬件计算引擎能够在网络通信的过程中卸载复杂操作。在网计算通过网络的交换和端侧设备共同配合的形式得以实现。作为一种内部网络基于树状聚合的机制,在网计算可以支持多个同时的集合操作。交换机被标识为聚合节点,将执行这样的数据reduce操作。 以典型allreduce算子为例,传统的通信交互复杂度为O(logN)(N代表网络节点规模),启动在网计算功能后其交互复杂度变为O(C)(C代表网络层级),与网络节点规模无关,极大减少了计算节点之间的通信交互过程,降低了网络时延,提升了计算效率。

在AI训练网络中最知名的在网计算技术就是英伟达的SHARP(Scalable Hierarchical Aggregation and Reduction Protocol)[17, 18],目前在其infiniband交换机和nvswitch都已经支持。Intel在2018年提出了switchML[19],该系统在其Tofino专用芯片(ASIC)的可编程交换机上实现了AllReduce操作,充分利用了交换机的编程能力。

华为公司NetReduce[22]基于RoCEV2,使用 FPGA 来实现了交换机,实现了数据中心中各粒度的 AllReduce 聚合。此外,论文Flare[21]实现了更灵活的架构,基于开源指令集处理器 RISC-V,使用 sPIN 编程模型设计了一个交换机支持allreduce计算。

3.6.链路负载均衡

在大语言模型的推理和训练应用中,GPU 或其他类型的计算单元的通讯模式通常包括较少的数据流和巨大的每数据流吞吐量,这就极易导致负载不均衡情况的出现。这种不均衡极可能恶化网络通讯状况同时带来带宽资源的浪费。为了解决这个问题,不同的负载均衡(Load balance)方法被提出,在ECMP[37]中数据包使用静态哈希分布到等效的多路径上,该方法以流为传输单元。对于CONGA[38] 和LetFlow [41] , 流片(flowlet)作为传输单元,CONGA根据端到端路径条件的全局信息的实时状态选择流量最佳的下一跳。Letflow根据预定时间间隔对数据包集群进行分类,并随机选择每个集群的转发端口。DRILL [39] 通过采用随机策略与工作负载结合的机制选择转发端口,Hermes[40] 将流量传输划分,根据路径和流的状态决定是在流水平重新路由短流还是在数据包水平重新路由长流。

3.7.高性能通信库

在大语言模型训练和推理网络中,高性能通信库扮演着关键的角色,它们负责优化数据传输和通信,加速AI工作负载,提高整体性能。常见的高性能通信库包括:

NCCL(NVIDIA Collective Communications Library)[43],它由NVIDIA开发,专为GPU集群通信而设计。针对NVIDIA GPU进行了优化,支持高效的点对点和集体通信操作,适用于深度学习框架如TensorFlow和PyTorch。
OpenMPI[44]:一个开源的消息传递接口(MPI)实现,用于并行计算。适用于多种硬件和网络拓扑,支持各种通信模式,广泛应用于科学计算和大规模数据分析。
Horovod[45]: Uber工程团队开发的集合通信库支持多种深度学习框架,如TensorFlow、PyTorch和MXNet。同时支持通信优化,以加速分布式训练。
Gloo[46]: Facebook开源的通信库为分布式深度学习和模型并行计算而设计, 具有高性能的点对点和集体通信实现,适用于各种硬件和网络环境。
ACCL[57]:ACCL(Alibaba Collective Communication Library)是一款高性能通信库,提供了AllReduce、AllToAllV、Broadcast等常用集合操作接口以及点到点Send/Recv接口,为多机多卡训练提供高效的通信支持。

此外还有其他厂家根据自己的硬件平台定制的集合通信库,比如TCCL(Tencent Collective Communication Library)、HCCL(Huawei Collective Communication Library)等等,这些高性能通信库有助于克服在大规模AI工作负载中可能遇到的通信瓶颈,提高模型训练和推理的效率。选择适当的通信库通常取决于硬件架构、网络拓扑和具体的应用场景。

4.业界知名的大模型训练网络

很多的云厂商、互联网公司纷纷结合自己的技术优势,通过自研和外部合作的方式搭建起自己的大语言模型训练网络的基础设施。

腾讯采用高性能RDMA网络[58],采用自研网络协议TiTa、定制化集合通信库TCCL、多轨道网络拓扑再加上自研全栈网络运营系统搭建星脉网络集群,支持10万卡的超大规模,具备3.2T通信带宽,提升40%的GPU利用率,节省30-60%的模型训练成本,为AI及大语言模型训练带来10倍的通信性能提升。

阿里推出高性能AI训练计算平台-灵骏[59],使用基于内存语义的低延迟、高带宽可线性扩展的磐久高性能网络predFabric,采用自研Solar-RDMA高速网络协议,并结合网络协议硬件化,芯片化延时降低至2微秒,实现了5倍的通信性能提升,千卡并行计算效率高达90%。

百度联合英伟达共同完成容纳万卡规模以上的IB网络[10],提供单集群EFLOPS级别的算力。整个网络采用8通道架构,通道内spine和leaf交换机做fullmesh全互联。为了减少跨交换机通信,采用网络架构感知方法,训练任务调度时将同一个任务调度到同一个汇聚组内。对于跨汇聚组的通信,通过汇聚组信息对全局GPU做有序化处理,减少跨交换机流量。

英伟达推出了面向超大规模生成式 AI 的加速以太网平台——Spectrum-X[60],其拥有无损网络、动态路由、流量拥塞控制、多业务性能隔离等主要特性,能够满足云上部署AI或生成式AI工作负载对网络性能的要求,有助于节约训练成本、缩短训练时间,加速大模型走向面市。

MIT和Meta团队发布了名为“Rail-Only”的全新大语言模型架构设计[8],对专门用于训练大型语言模型的 GPU 集群的传统any-to-any网络架构提出了挑战。Rail-Only架构通过将GPU分组,组成一个高带宽互联域(HB域),然后再将这些HB域内的特定的GPU跨接到特定的Rail交换机,虽然增加了跨域通信的路由调度复杂度,但是通过合理的HB域和Rail交换机设计,整体架构可以大量减少交换机的使用,最多可以降低75%的网络通信。

微软与OpenAI独家合作打造了一台性能位居全球前五,拥有超过28.5万个CPU核心、1万个GPU,每GPU拥有400Gbps网络带宽的超级计算机——Azure AI超算平台[61],主要用于大规模分布式AI模型训练。

2024年2月字节跳动联合北京大学的研究团队发表论文[65],介绍了他们用于训练大语言模型的生产系统MegaScale。MegaScale搭建超过10000块GPU的单一集群,在12288个GPU上训练175B LLM模型时,实现了55.2%模型FLOP利用率。该系统还包含了一套诊断工具用于监控系统组件和事件,找出根本原因,并实现容错功能。

5.展望

随着大语言模型规模的不断增大,对网络的带宽、延迟、可靠性和健壮性的要求也越来越高。未来的大语言模型训练网络组网将向以下几个方向发展:更高的带宽、更低的延迟、更加可靠的组网以及自动化智能运维。结合上述发展方向,大语言模型训练网络组网存在以下几个研究领域:

新型网络拓扑:针对大语言模型训练网络研究新的拓扑结构,以提高网络的带宽和降低网络的延迟。例如,可以研究基于Clos拓扑结构和Dragonfly拓扑结构的混合拓扑结构,以兼顾网络的带宽和延迟。

优化流量工程算法:为优化网络中的数据流向,减少网络拥塞,研究新的流量工程算法。例如,可以研究基于机器学习的流量工程算法,以动态调整网络中的数据流向,避免网络拥塞。

智能运维管理技术:在网络管理技术上进一步深入研究,以尽可能简化网络的管理和维护。例如,可以研究基于人工智能的网络管理技术,以自动发现和修复网络故障,并根据网络的实时状态进行优化。

领域定制高速互联技术:观察AI大模型网络流量特点,针对关键技术如协议定义、拥塞和流量控制等进行针对性优化,以期更好的适配大模型网络的训练特点。同时在架构设计上需要有足够的灵活性允许引入新的功能,使其具备持续演进的能力。

这些研究领域对于大语言模型训练网络组网的未来发展至关重要。通过对这些领域的深入研究,我们可以研发出更高效、更可靠、更安全以及更智能的AI大模型训练网络,以满足大语言模型训练的需求。

6.参考文献

[1]Al-Fares, Mohammad, et al. “A Scalable, Commodity Data Center Network Architecture.” ACM SIGCOMM Computer Communication Review, vol. 38, no. 4, 1 Oct. 2008, p. 63, https://doi.org/10.1145/1402946.1402967. Accessed 24 Nov. 2019.
[2]Dong, Jing, et al. EFLOPS: Algorithm and System Co-Design for a High Performance Distributed Training Platform. 1 Feb. 2020, https://doi.org/10.1109/hpca47549.2020.00056. Accessed 26 Dec. 2023.
[3]Jouppi, Norman, et al. TPU V4: An Optically Reconfigurable Supercomputer for Machine Learning with Hardware Support for Embeddings: Industrial Product. No. 23, 2023, arxiv.org/ftp/arxiv/papers/2304/2304.01433.pdf, https://doi.org/10.1145/3579371.3589350.
[4]Kaplan, Jared, et al. “Scaling Laws for Neural Language Models.” ArXiv:2001.08361 [Cs, Stat], 22 Jan. 2020, arxiv.org/abs/2001.08361.
[5]Kim, John, et al. “Technology-Driven, Highly-Scalable Dragonfly Topology.” 2008 International Symposium on Computer Architecture, June 2008, static.googleusercontent.com/media/research.google.com/en//pubs/archive/34926.pdf, https://doi.org/10.1109/isca.2008.19. Accessed 2 Dec. 2020.
[6]Li, Ang, et al. “Evaluating Modern GPU Interconnect: PCIe, NVLink, NV-SLI, NVSwitch and GPUDirect.” IEEE Transactions on Parallel and Distributed Systems, vol. 31, no. 1, 1 Jan. 2020, pp. 94–110, ieeexplore.ieee.org/ielaam/71/8935555/8763922-aam.pdf, https://doi.org/10.1109/tpds.2019.2928289. Accessed 24 Aug. 2023.
[7]Teh, Min Yee, et al. “Design Space Exploration of the Dragonfly Topology.” Semantic Scholar, Springer International Publishing, 2017, www.semanticscholar.org/paper/Design-Space-Exploration-of-the-Dragonfly-Topology-Teh-Wilke/307bf0a28c6a7cb29e771b038fa17dea8603b2ad. Accessed 26 Dec. 2023.
[8]Wang, Weiyang, et al. “How to Build Low-Cost Networks for Large Language Models (without Sacrificing Performance)?” ArXiv (Cornell University), 22 July 2023, https://doi.org/10.48550/arxiv.2307.12169. Accessed 26 Dec. 2023.
[9]Wei, Jason, et al. “Emergent Abilities of Large Language Models.” ArXiv.org, 26 Oct. 2022, arxiv.org/abs/2206.07682.
[10]百度智能云,度小满( 2023/08 ).“智算中心网络架构白皮书” https://cloud.baidu.com/survey/iccbaipishu.html?track=weixin01
[11]华为技术有限公司,中国信息通信研究院云计算与大数据研究所(2023/09). “星河AI网络白皮书”https://e.huawei.com/cn/material/enterprise/8ac74df519ff4fc4ae9aeabe0215adb0
[12]intel(2023/07).“Gaudi®2WhitePaper” https://www.intel.com/content/www/us/en/content-details/784827/gaudi-2-white-paper.html
[13]nvidia(2022/3).” NVIDIA DGX H100 “ https://www.nvidia.com/en-us/data-center/dgx-h100/
[14]Nvidia(2014/12).”NVIDIA® NVLink TM High-Speed Interconnect: Application Performance” http://info.nvidianews.com/rs/nvidia/images/NVIDIA%20NVLink%20High-Speed%20Interconnect%20Application%20Performance%20Brief.pdf
[15]intel(2023/07).“Gaudi® Training Platform White Paper” https://www.intel.com/content/www/us/en/content-details/784830/gaudi-training-platform-white-paper.html
[16]Nvidia(2023/09).”Networking for the Era of AI: The Network Defines the Data Center” https://nvdam.widen.net/s/bvpmlkbgzt/networking-overall-whitepaper-networking-for-ai-2911204
[17]Graham, Richard L, et al. “Scalable Hierarchical Aggregation and Reduction Protocol (SHARP) TM Streaming-Aggregation Hardware Design and Evaluation.” ISC, 1 Jan. 2020, pp. 41–59. Accessed 27 Dec. 2023.
[18]Graham, Richard L, et al. “Scalable Hierarchical Aggregation Protocol (SHArP): A Hardware Architecture for Efficient Data Reduction. “13 Nov. 2016, pp. 1–10, https://doi.org/10.5555/3018058.3018059. Accessed 27 Dec. 2023.
[19]Sapio, Amedeo, et al. “Scaling Distributed Machine Learning with In-Network Aggregation.” Networked Systems Design and Implementation, 1 Apr. 2021, pp. 785–808. Accessed 27 Dec. 2023.
[20]Charles E. Leiserson,“Fat-Trees: Universal Networks for Hardware-Efficient Supercomputing | IEEE Journals & Magazine | IEEE Xplore.” Ieeexplore.ieee.org, ieeexplore.ieee.org/abstract/document/6312192. Accessed 27 Dec. 2023.
[21]Daniele De Sensi, et al. Flare: Flexible In-Network Allreduce. 29 June 2021. Accessed 27 Dec. 2023.
[22]Liu, Shuo, et al. “NetReduce: RDMA-Compatible In-Network Reduction for Distributed DNN Training Acceleration.” ArXiv (Cornell University), 21 Sept. 2020, https://doi.org/10.48550/arxiv.2009.09736. Accessed 27 Dec. 2023.
[23]A. Ivanov, N. Dryden, T. Ben-Nun, S. Li, and T. Hoefler, “Data Movement Is All You
Need: A Case Study on Optimizing Transformers,”in Proceedings of Machine Learning and Systems 3 (MLSys 2021), Apr.2021.
[24]T. Hoefler, D. Alistarh, T. Ben-Nun, N. Dryden, and A. Peste, “Sparsity in Deep
Learning: Pruning and growth for efficient inference and training in neural networks,” Journal of Machine Learning Research, vol. 22, no.241, pp. 1–124, Sep. 2021.
[25]Timothy Prickett Morgan.”META PLATFORMS IS DETERMINED TO MAKE ETHERNET WORK FOR AI”, https://www.nextplatform.com/2023/09/26/meta-platforms-is-determined-to-make-ethernet-work-for-ai/
[26]T. Hoefler, A. Hendel, and D. Roweth, “The convergence of hyperscale data center and high-performance computing networks,” Computer, vol. 55, no. 7, pp. 29–37,2022.
[27]Hoefler, Torsten, et al. “Datacenter Ethernet and RDMA: Issues at Hyperscale.” ArXiv (Cornell University), 7 Feb. 2023, https://doi.org/10.48550/arxiv.2302.03337. Accessed 28 Dec. 2023.
[28]Li, Shenggui, et al. Colossal-AI: A Unified Deep Learning System for Large-Scale Parallel Training. 7 Aug. 2023, https://doi.org/10.1145/3605573.3605613.
[29]mellanox technologies.”Introduction to InfiniBand™”.https://network.nvidia.com/pdf/whitepapers/IB_Intro_WP_190.pdf
[30]Nvidia.”NVIDIA H100 Tensor Core GPU Architecture”.https://resources.nvidia.com/en-us-tensor-core
[31]Tang, Zhenheng, et al. “Communication-Efficient Distributed Deep Learning: A Comprehensive Survey.” ArXiv (Cornell University), 10 Mar. 2020, https://doi.org/10.48550/arxiv.2003.06307.
[32]Zhang, Zhen, et al. “Is Network the Bottleneck of Distributed Training?” ArXiv (Cornell University), 17 June 2020, https://doi.org/10.48550/arxiv.2006.10103. Accessed 29 Dec. 2023.
[33]Guo, Chuanxiong, et al. “RDMA over Commodity Ethernet at Scale.” ACM Special Interest Group on Data Communication, 22 Aug. 2016, https://doi.org/10.1145/2934872.2934908. Accessed 23 Apr. 2023.
[34]Hemmatpour, Masoud, et al. “Communicating Efficiently on Cluster-Based Remote Direct Memory Access (RDMA) over InfiniBand Protocol.” Applied Sciences, vol. 8, no. 11, 24 Oct. 2018, p. 2034, https://doi.org/10.3390/app8112034.
[35]Infiniband Trade Association. InfiniBandTM Architecture Specification Volume 1 Release 1.3, March 2015.
[36]Ultra Ethernet Consortium.https://ultraethernet.org/
[37]Zhou, J., Tewari, M., Zhu, M., Kabbani, A., Poutievski, L., Singh, A., Vahdat, A.,
2014. WCMP: weighted cost multipathing for improved fairness in data centers.
In: Proceedings of the Ninth European Conference on Computer Systems (EuroSys
’14). Association for Computing Machinery, New York, NY, USA, pp. 1–14.
[38]Alizadeh, M., et al., 2014. CONGA: Distributed congestion-aware load balancing for datacenters. In: Proc. ACM Conf. SIGCOMM. pp. 503–514 .
[39]Ghorbani, S., Yang, Z., Godfrey, P.B., Ganjali, Y., Firoozshahian, A., 2017. DRILL: Micro
load balancing for low-latency data center networks. In: Proc. ACM SIGCOMM. pp.
225–238.
[40]Zhang, H., Zhang, J., Bai, W., Chen, K., Chowdhury, M., 2017. Resilient datacenter
load balancing in the wild. In: Proc. ACM SIGCOMM. pp. 253–266.
[41]Vanini, E., Pan, R., Alizadeh, M., Taheri, P., Edsall, T., 2017. Let it flow: Resilient
asymmetric load balancing with flowlet switching. In: Proc. USENIX NSDI. pp.
407–420.
[42]http://www.ecconsortium.org/Uploads/file/20230531/1685518822453247.pdf
[43]NCCL 2020. The NVIDIA Collective Communication Library (NCCL). https://developer.nvidia.com/nccl.
[44]Richard L Graham, Timothy S Woodall, and Jeffrey M Squyres. 2005. Open MPI: A flexible high performance MPI. In International Conference on Parallel Processing and Applied Mathematics. Springer, 228–239.
[45]Alexander Sergeev and Mike Del Balso. 2018. Horovod: fast and easy distributed deep learning in TensorFlow. arXiv:1802.05799 [cs.LG].
[46]Gloo 2020. Collective communications library with various primitives for multi-machine training. https://github.com/facebookincubator/gloo.
[47]M. Alizadeh et al., “Data center tcp (dctcp),” in Proceedings of the ACM SIGCOMM 2010 Conference, ser. SIGCOMM ’10, New Delhi, India, 2010, 63–74,
[48]R. Mittal et al., “Timely: Rtt-based congestion control for the datacenter,”SIGCOMM Comput. Commun. Rev., vol. 45, no. 4, 537–550, 2015,
[49]Y. Zhu, M. Ghobadi, V. Misra, and J. Padhye, “Ecn or delay: Lessons learnt from analysis of dcqcn and timely,” in Proceedings of the 12th International on Conference on Emerging Networking EXperiments and Technologies, ser. CoNEXT’16, 2016, 313–327,
[50]Y. Li et al., “Hpcc: High precision congestion control,” in Proceedings of the ACM Special Interest Group on Data Communication, ser. SIGCOMM ’19, Beijing, China, 2019, 44–58,
[51]C. Tessler et al., “Reinforcement learning for datacenter congestion control,”SIGMETRICS Perform. Eval. Rev., vol. 49, no. 2, 43–46, 2022,
[52]B. He et al., “Deepcc: Multi-agent deep reinforcement learning congestion control for multi-path tcp based on self-attention,” IEEE Transactions on Network and Service Management, vol. 18, no. 4, pp. 4770–4788, 2021.
[53]S. Emara, F. Wang, B. Li, and T. Zeyl, “Pareto: Fair congestion control with online reinforcement learning,” IEEE Transactions on Network Science and Engineering, vol. 9, no. 5, pp. 3731–3748, 2022.
[54]X. Zhong, J. Zhang, Y. Zhang, Z. Guan, and Z. Wan, “Pacc: Proactive and accurate congestion feedback for rdma congestion control,” in IEEE INFOCOM 2022 - IEEE Conference on Computer Communications, 2022, pp. 2228–223
[55]J. Zhang, X. Zhong, Z. Wan, Y. Tian, T. Pan, and T. Huang, “Rcc: Enabling receiver-driven rdma congestion control with congestion divide-and-conquer in datacenter networks,” IEEE/ACM Transactions on Networking, vol. 31, no. 1,pp. 103–117, 2023.
[56]P. Taheri, D. Menikkumbura, E. Vanini, S. Fahmy, P. Eugster, and T. Edsall,“Rocc: Robust congestion control for rdma,” in Proceedings of the 16th International Conference on Emerging Networking EXperiments and Technologies,ser. CoNEXT ’20, Barcelona, Spain, 2020, 17–30.
[57]Dong J B, Wang S C, Feng F et al. ACCL: Architecting highly scalable distributed training systems with highly efficient collective communication library. IEEE Micro,2021, 41(5): 85–92. DOI: 10.1109/MM.2021.3091475.
[58]腾讯星脉高性能计算网络:为AI大模型构筑网络底座.https://cloud.tencent.com/developer/article/2234084
[59]阿里云新一代智能计算:灵骏.https://developer.aliyun.com/article/1004864
[60]Turbocharging Generative AI Workloads with NVIDIA Spectrum-X Networking Platform. https://developer.nvidia.com/blog/turbocharging-ai-workloads-with-nvidia-spectrum-x-networking-platform/
[61]OpenAI’s supercomputer collaboration with Microsoft marks its biggest bet yet on AGI.https://venturebeat.com/ai/openai-microsoft-azure-supercomputer-ai-model-training/
[62]CXL Consortium. “Compute Express Link 3.1 Specification”. Nov 14, 2023
[63]AMD. “AMD Infinity Architecture”.https://www.amd.com/en/technologies/infinity-architecture
[64]PCI-SIG."PCI Express 5.0 specification".May 30, 2019
[65]Jiang, Ziheng, et al. “MegaScale: Scaling Large Language Model Training to More than 10,000 GPUs.” ArXiv.org, 23 Feb. 2024, arxiv.org/abs/2402.15627. Accessed 5 Mar. 2024.


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/26471.html
分享到:
相关文章
条评论

登录后才可以评论

SDNLAB君 发表于24-03-27
0