AI时代的以太网:应对大规模GPU集群网络挑战

科技   2024-12-16 19:14   北京  

公开课预告

12月19日19:30基流科技技术负责人敬阳将以《大规模异构GPU集群的互联、运维与调度》为主题进行直播讲解,欢迎扫码报名~ 


主要内容
1. AI训练对网络架构的挑战
  • 传统的“接入-汇聚-核心”三层拓扑结构难以应对云原生应用和虚拟化带来的东西向流量激增,其链路利用率低、带宽损耗严重且VLAN跨域受限。
  • 为了满足AI训练,特别是大型语言模型(LLM)训练对GPU规模和算力的需求,需要采用叶脊架构构建后端网络,通过高速互连技术连接服务器内的GPU(Scale-Up)和跨服务器的GPU集群(Scale-Out)。
  • 以太网因其简单性、可扩展性、模块化、成本效益和与现有数据中心生态系统的兼容性而成为Scale-Out网络的首选。然而,以太网固有的丢包问题对AI工作负载,特别是对数据包丢失敏感的AI工作负载,构成了挑战。


2. LLM训练对网络带宽和延迟的要求
  • LLM训练需要大量的GPU进行并行计算,包括数据并行、模型并行、流水线并行和张量并行等。
  • 这些并行计算技术都会产生大量的GPU间通信流量,任何任务延迟或网络拥塞都会严重影响性能。
  • AI架构流量,特别是Scale-Out架构的流量,具有高吞吐量(约100Gbps)、短包长、低往返时间(约10微秒)的特点。因此,需要高效利用所有可用带宽,确保流量均匀分布,并具备快速丢包恢复和重传机制,以及适用于该架构需求的拥塞控制算法。


3. UEC提出的解决方案
为了应对AI工作负载带来的挑战,UEC提出了UET协议和一系列优化策略:
  • 拥塞避免
    • 数据包喷射(Packet Spraying):将数据包分散到所有可用路径,提高链路利用率,但需要接收方具备乱序数据包重组能力。
    • 自适应负载均衡(Adaptive Load Balancing):基于路径拥塞状态信息,动态选择最佳路径,但需要精确的拥塞状态信息和避免乱序传输。
    • 带内遥测(INT):在数据包中添加拥塞信息,使发送方了解网络拥塞状况并调整传输速率。
  • 拥塞控制
    • 高精度拥塞控制(HPCC):针对高带宽、低往返时间环境优化,包括基于发送方的拥塞控制和基于接收方的拥塞控制。
    • 丢包重传
    • 选择性确认(SACK):仅重传丢失的数据包,优化带宽利用率和降低延迟。
    • 数据包修剪(Packet Trimming):将即将丢弃的数据包修剪至64字节,快速通知接收方进行重传。

  • 回传拥塞
    • 网络内集合操作(In-Network Collectives):将集合操作卸载到交换机上,减轻最后链路负载,但需要注意与数据包喷射结合使用时的路径一致性问题。
    • UEC与传统RDMA的比较
    • UEC Transport提供了增强型无损流量、基于流量的拥塞控制、高精度拥塞控制、快速重传、网络内集合操作等功能,以满足AI和HPC网络的需求。
    • 与传统RDMA相比,UEC Transport能够更好地应对AI工作负载带来的挑战,提供更高的带宽利用率、更低的延迟和更强大的拥塞控制能力。

  • 拓扑结构
    • 除了传统的CLOS叶脊拓扑,还有一种轨道优化拓扑(Rail-optimized topology),通过将相同轨道或通道上的GPU连接到同一个轨道交换机,可以减少流量跳数,提高传输效率。
    • 纯轨道拓扑(Rail-only topology)则更进一步,通过在高带宽域内直接转发流量,省去了脊交换机,从而获得更多端口连接GPU。


参考资料
Large Language Models - The HW connection
https://www.linkedin.com/pulse/large-language-models-hardware-connection-sharada-yeluri
GPU Fabrics for Gen AI Workload
https://www.linkedin.com/pulse/gpu-fabrics-genai-workloads-sharada-yeluri-j8ghc/
SwitchAgg:A Further Step Towards In-Network Computation
https://arxiv.org/abs/1904.04024
UEC Introduction
https://www.youtube.com/watch?v=PwxQ_8kqNBE
Networking for AI and HPC, and Ultra Ethernet
https://www.youtube.com/watch?v=0roIi1pscts
==========
数据中心网络的发展历史中,当前广泛采用的一种网络架构便是“接入-汇聚-核心”三层拓扑结构。该拓扑主要服务于客户端-服务器架构,其中流量模式以南北向为主。观察此架构图,汇聚层以下构成单一的L2域,采用生成树协议(STP)来规避L2环路。
该拓扑存在的弊端包括:
  • 链路利用率低:STP虽避免了环路,但也导致环路中的部分链路未得到充分利用,甚至闲置。
  • 带宽损耗严重:一旦汇聚或接入交换机发生故障,几乎会导致一半带宽的丢失。
  • VLAN限制:由于汇聚层以下为单L2域,VLAN无法跨域,意味着两台服务器无法共享同一VLAN,否则将引发冲突。

随着云原生应用和虚拟化在数据中心中的快速增长,数据中心内部的东西向流量(即服务器间流量)也随之激增。传统拓扑在处理此类东西向流量时力不从心,因此催生了叶脊架构(Leaf-spine Architecture)。在此架构中,服务器连接至叶交换机,叶交换机与脊交换机形成全互连或CLOS拓扑。
该拓扑的优势包括:
  • 高可用性:通过叶交换机与脊交换机间的等价多路径(ECMP)实现高可用带宽。与L2的环路预防机制不同,叶脊架构中叶交换机以上的部分为L3层,天然支持多路径路由。
  • VxLAN技术:支持多租户环境,使得服务器层的VLAN能够跨不同L3域重用。例如,连接至叶交换机1的服务器与连接至叶交换机3的服务器可使用相同VLAN,且分属两个独立网络域。
  • 卓越的可扩展性:网络高度可靠。单个脊交换机故障仅影响其连接部分,其他脊交换机仍能重新路由流量至叶交换机层。多机箱链路聚合(LAG)适用于故障切换。通过增加叶交换机和脊交换机数量,无需影响现有连接,即可轻松扩展网络架构。
此网络拓扑主要用于数据中心内服务器与存储的连接。
鉴于GPU架构在AI和HPC工作负载中的讨论日益热烈,我们将聚焦于最繁重的AI工作负载之一:LLM训练。
让我们回顾LLM如何影响GPU规模的网络。
LLM通过深度学习算法在大型数据集上训练,以生成类似人类的输出。数据集由海量单词构成,这些单词被转换为整数序列,即tokens。典型数据集包含数百亿至数万亿个tokens。LLM具有参数(或称权重),这些通过学习获得的变量决定了模型如何预测和生成输出。训练过程中,权重会被调整以产生可预测输出,涉及tokens、参数等关键术语。
让我们来看一些具体数据。
上图展示了数据集中的海量单词如何转换为tokens。
顺时针方向,有一张表格,列出了几个热门模型(如GPT-3和LLaMA)在token和参数规模上的数据。
以GPT-3为例,该模型拥有1750亿参数。训练过程中,需近1TB内存存储这些参数,训练状态会定期保存至存储作为检查点。每个检查点需4TB内存。当前高端GPU典型内存容量约为80GB,因此显然单个GPU无法容纳如此规模的参数。
顺时针方向,我们计算GPT-3的需求。GPT-3拥有1750亿参数,30亿tokens,每个token的每个参数需进行六次浮点运算以训练模型,因此总运算量约为3.15 × 10²³ FLOPS。假设一个GPU的性能为67 Teraflops/秒,则训练该模型需约4.7 × 10⁹秒。若希望在一个月内完成训练(假设GPU24小时不间断运行),则所需GPU数量约为1800个。考虑到加载数据集、模型或检查点至存储的时间,实际所需GPU数量可能远超1800个。
在上一张幻灯片中,我们探讨了训练工作负载的规模如何决定所需GPU的数量,鉴于单个GPU无法处理整个数据集或模型。接下来,让我们聚焦于训练过程中用于同步GPU集群的并行计算类型。
第一种并行计算类型是数据并行性(Data Parallelism)。如其名所示,数据集被分割成多个小批次,每个GPU处理一个小批次进行前向传播(forward pass)以训练模型并作出预测。随后,通过反向传播(backward pass)收集梯度。这个过程——前向传播、反向传播和梯度聚合——会循环多次,直至模型收敛。
第二种并行计算类型是模型并行性(Model Parallelism),它与数据并行性形成对比。在此情况下,模型本身被分割成多个部分,每个GPU负责处理一部分。前向传播时,每个GPU计算其负责部分的输出,并将结果传递给下一个GPU。反向传播时,梯度则逆向传递,最终返回至第一个GPU。模型并行性具有顺序依赖性,因为每个GPU必须等待其后续GPU的输出。
第三种类型是流水线并行性(Pipeline Parallelism),它融合了数据并行性和模型并行性的特点。鉴于模型并行性可能导致GPU长时间空闲,流水线并行性通过将数据集的小批次进一步分割为微批次来最小化这种空闲。每个GPU在处理微批次和模型分区的同时,一旦第一个GPU完成前向传播并将输出发送至下一个GPU,它便立即开始处理下一个微批次,从而减少空闲时间。
流水线并行性会增加GPU间的通信流量。如图左侧所示,底部表示第一个GPU,它处理第一个微批次并将其发送至上方的下一个GPU。随后,该GPU继续处理下一个微批次。这一过程减少了GPU的空闲时间,但相应地增加了GPU间的整体通信流量。
接下来要讨论的并行计算类型是张量并行性(Tensor Parallelism)。这类似于将流水线并行性进一步细化。它将计算密集型的流水线部分或模型参数分布在多个GPU上,以降低每个GPU的计算和内存负担。张量并行性会积极地从其他GPU收集和分发信息,这与其他类型的并行性相比,显著增加了GPU间的通信流量。
例如,在前向传播中,通过行分割的矩阵乘法需要进行一次All-Reduce操作。从上述并行性技术中我们可以看出,无论采用哪种并行性类型,GPU间的通信流量都会非常大。在训练过程中,任何任务延迟或网络拥塞都可能严重影响性能。当然,延迟和链路利用率在提升性能方面同样扮演着至关重要的角色。
我们已经讨论了并行性和GPU间通信流量,现在来探讨一下输出如何在GPU之间传输。
GPU是如何相互通信的呢?我们之前讨论了在前向传播中传递预测,以及在反向传播中聚合结果。这些操作是通过一种称为集合通信(Collectives)的机制来实现的。集合通信有多种形式,我在此列出了一些常见类型。由于大多数人可能对这些集合通信方式有所了解,我不再详细展开。例如,All-Reduce会将来自所有GPU的数据进行聚合,并将结果分发给所有成员,而Reduce-Scatter则是将所有成员的数据聚合后,将结果分发至其他成员。
这些集合通信操作促进了GPU间的通信,并产生了大量流量。
在前面的幻灯片中,我们不仅讨论了训练大型模型所需的GPU规模,还探讨了这些GPU如何通过GPU间通信来协同工作以提高效率。接下来,我们将讨论GPU集群或AI架构的拓扑,并了解其设计。
如图所示,有三种网络在发挥作用:
  • 前端网络(Frontend Network):这基本上是我们之前提到的CLOS拓扑,用于连接数据中心内的服务器和存储网络。这里没有变化,仍然采用ECMP、VSS、SL等技术。
  • 后端网络(Backend Network):用于连接服务器和机架内的GPU。后端网络有两种类型:
    • Scale-Up网络(Scale-Up Network):这种网络通过高速互连(如NVLink或Infinity Fabric)将同一服务器内的GPU连接起来。该配置可以扩展到60–72个GPU。然而,这与训练LLM所需的GPU规模相比仍然不足。为了实现这种规模,我们采用了第二种类型的后端网络:
    • Scale-Out网络(Scale-Out Network):在这种网络中,每个服务器中的GPU通过网络交换机连接到其他机架或服务器的GPU集群。Scale-Up网络和Scale-Out网络的一个关键区别在于,在Scale-Out网络中,典型的内存访问大多通过RDMA进行,并涉及网络交换机。


在Scale-Out网络中,以太网成为部署的主要选择之一。为何选择以太网?因为它具有简单性、可扩展性、模块化、成本效益高以及能够很好地融入现有数据中心生态系统的优势。然而,在Scale-Out网络中使用以太网仍面临挑战,主要是以太网固有的丢包问题。AI工作负载对数据包丢失非常敏感。
这张图直观地展示了Scale-Up与Scale-Out网络架构。如你所见,在Scale-Up域内,给定服务器中的GPU通过高速互GPU链路相互连接。灰色框内嵌有一个蓝色框,代表NVLink互连。这些GPU通过NIC进一步连接到Scale-Out域中的叶交换机。值得注意的是,Scale-Out网络中的叶脊拓扑与我们之前幻灯片中展示的CLOS网络架构颇为相似。
该网络为GPU间提供了All-to-All连接能力,意味着从任一GPU出发,均可访问网络中的其他任意GPU。这是网络配置的标准范式,特别是在作为LLM训练的基础设施提供商时尤为重要。在此情境下,多个不同类型的模型能够共享同一网络进行训练。这种All-to-All的CLOS架构及拓扑能够灵活适应各种流量模式,并展现出卓越的可扩展性。
当数据从叶交换机流向脊交换机时,带宽得到不断提升,从而支持大规模训练任务所需的高效且可扩展的AI架构。
在此网络规模的架构中,还存在一个分支,我们称之为轨道优化拓扑(Rail-optimized topology)。它与前一张图中展示的All-to-All拓扑存在细微差异。关于这种拓扑,有一篇颇具启发性的论文中探讨了一种双域拓扑结构:一个是高带宽域,另一个是NIC域。
----------
Rail-only: A Low-Cost High-Performance Network for Training LLMs with Trillion Parameters
https://arxiv.org/abs/2307.12169
该论文介绍了一种专门为高效、经济地训练LLM而设计的新型网络架构。批评了传统的any-to-any网络设计,认为LLM表现出稀疏的通信模式,不需要如此广泛的连接。提出的Rail-only网络消除了典型GPU集群中的主干层,在保持与传统设置相当的训练性能的同时,将网络成本降低了38%至77%,功耗降低了37%至75%。此外,它支持混合专家(MoE)模型,All-to-All通信的开销最小化,提高了其对故障的鲁棒性,并优化了专为LLM训练而设计的数据中心中的资源使用。
----------
高带宽域位于服务器内部,数据传输速率极高;而NIC域则是由NIC连接而成的网络区域。可以将这两个域与这种拓扑中的Scale-Up网络和Scale-Out网络进行类比。观察GPU,会发现连接到交换机的相同轨道或通道(称为轨道交换机,如红线所示),例如服务器1中的GPU 1与服务器2中的GPU 2均连接到了同一个轨道交换机。
这种拓扑的设计动机源于不同类型并行性中集合通信方式的应用。例如,张量并行性常采用Scatter和Gather方法,这些方法对带宽有着极高的要求。参与张量计算的GPU通常会在同一服务器的高带宽域内保持连接。
流水线并行性则使用大量点对点流量,因为信息需要在流水线的各个阶段之间传递。在这种情况下,可以通过特定的GPU等级或GPU轨道将流量从一个阶段传递到下一个阶段,从而保持流量在轨道内部流动。相比之下,在之前的CLOS拓扑中,流量总是需要从一个GPU流经叶交换机、脊交换机,再到另一个叶交换机,完成三跳路由。而这种拓扑则能够将其减少为一跳。
大多数并行和集合操作要么可以保持在高带宽域内完成,要么在某些情况下,即便它们跨越NIC域,也能保持在轨道内部流动,而无需进入脊交换机。
还有一种变体,即纯轨道拓扑(Rail-only topology)。在轨道优化拓扑中,例如服务器1的GPU 1到服务器2的GPU 2的流量通常会经过:GPU 1到轨道1,再到脊交换机1,然后到轨道2,最终到达GPU 2。但在纯轨道拓扑中,流量可以在高带宽域内直接从GPU 1通过轨道2到达GPU 2,而无需经过脊交换机。
通过这种流量转发方式,脊交换机通常可以被完全省略。因此,它被称为纯轨道拓扑。保持在纯轨道层级的一个显著优势是,你可以获得更多的端口来连接轨道交换机上的GPU。
截至目前,我们已讨论了工作负载规模及其对后端网络的影响,并涉及了一些物理层或转发层的后端拓扑。那么,流量需求方面又如何呢?在之前的幻灯片中,我曾提及以太网是一种有损技术,并且在AI架构中仍存在一些局限性。
那么,AI架构流量,特别是Scale-out架构的流量特性究竟是什么呢?它要求具备高吞吐量,通常约为100 Gbps,同时包长较短,典型的往返时间仅为10微秒。Scale-out架构的关键在于必须有效利用所有可用带宽,并确保流量的均匀分布。GPU流量通常较大,与典型的服务器间流量存在差异,因此应高效采用负载均衡方案,如路径感知(Path-aware)、自适应(Adaptive)或无损(Lossless)负载均衡方式。此外,还需具备快速的丢包恢复和重传机制,以避免产生高延迟,并结合适用于该架构需求的拥塞控制算法以实现最佳性能。
超以太网联盟(UEC)正致力于满足这些要求,并不断改进以太网以更好地支持AI工作负载。他们的工作不仅涉及流量工程问题,还涵盖了从Libfabric API到传输层和链路层的多个层级。
接下来,我们将深入探讨超以太网传输层(Ultra Ethernet Transport,简称UET),特别是其数据包传输子层(Packet Delivery Sub-layer)。在此,我们将介绍一些优化策略,旨在高效应对网络拥塞问题。
首先,让我们简要回顾一下当前数据中心网络中针对RDMA流量的拥塞避免方案。RDMA技术通常结合RoCEv2或融合以太网(Converged Ethernet)等技术使用,并通过DCQCN机制来处理拥塞。DCQCN方案主要包含以下两个组件:
ECN(显式拥塞通知,Explicit Congestion Notification)机制,用于向接收方发送拥塞信号。当网络出现拥塞时,数据包会被标记上ECM(拥塞标记),接收方在接收到此类标记后,会触发一个CNP(拥塞通知包,Congestion Notification Packet)返回给发送方,指示其降低发送速率。
PFC(优先级流量控制,Priority Flow Control)机制,旨在通过控制包丢失来确保流量的无损传输。它通过发送PA帧来操作,当交换机处于拥塞状态时,PA帧会通知上游交换机停止传输流量,从而防止丢包事件的发生。PA帧会向上游传播,形成一道保护屏障。
然而,DCQCN方案也面临着一些挑战:
PFC是基于优先级的控制机制,而非基于流量本身,因此可能会引发PFC风暴,导致死锁情况的出现,进而增加尾延迟。这是因为拥塞控制机制具有停停走走的特性。
ECN同样不是基于流量的控制机制,其触发可能会影响到同一发送方和接收方之间的其他数据流。此外,配置PFC和调优缓冲区的过程也相当繁琐复杂。
鉴于RoCEv2的当前特性,它难以满足GPU架构对于流量的高要求。
那么,针对这些问题,有哪些改进方案呢?
第一个改进方案旨在提升链路利用率(Link Utilization)。数据包喷射(Packet Spraying)、TC/CP或RDMA等实现方式通常期望数据包能够按顺序到达接收方。一旦出现数据包乱序或丢失的情况,它们就会被视为拥塞的信号,从而触发拥塞控制机制或丢包重传过程。为了解决这个问题,ECMP技术通过根据数据包字段和UDP源端口计算的哈希值来选择路径,确保流量能够按顺序从发送方传递到接收方。
然而,ECMP并非完美的负载均衡技术。例如,在一条800 Gbps的链路上,如果有8个流量流,每个流的流量为80 Gbps,并分布在32台服务器上,那么最差的链路将会超载1.4倍。正如我们所知,平行计算技术高度依赖于低延迟的GPU间流量传输,其性能往往取决于最慢的链路。因此,一旦某条链路出现超载情况,就会对整个训练过程产生负面影响。
为了解决这个问题,我们可以采用数据包喷射技术,将给定流量的数据包分布到所有可用的路径中,直至到达目的地。接收方将会接收到乱序的数据包,并需要借助先进的硬件来重新组合这些数据包。虽然数据包喷射技术优化了链路利用率,但它也带来了新的问题:如何准确识别拥塞的发生位置?特别是难以判断拥塞是发生在中间交换机上,还是发生在交换机与GPU之间的最终链路(即回传拥塞)上。
由于数据包喷射技术预计会导致数据包的乱序传递,因此接收方必须能够区分丢包和因网络条件延迟到达的包。如果等待时间过长,可能会增加延迟。
另一个方案是向发送方提供关于所有可用路径的实时拥塞状态信息。如图所示,发送方可以定期轮询或使用遥测机制来确定到目标的所有可用路径的拥塞状态。
在基于流量的负载均衡方案中,当一个流量流到达交换机时,交换机会根据该端口的负载情况选择最不繁忙的链路进行传输。例如,如果交换机有三条不同的链路指向目标地址,它会选择负载最轻的一条链路进行传输。然而,交换机无法获知下游的拥塞状态信息,这可能导致路径选择不够理想。
为了解决这个问题,这个方案通过考虑从源地址到目的地址的整个路径上的拥塞状态信息来提高性能。它甚至可能在传输过程中将一个流量流从一条路径切换到另一条路径上。但这需要精心调优以避免乱序传输的发生,或者确保接收方能够处理乱序到达的数据包。
为了实现这个方案,必须有一个机制在后台运行并定期提供所有可用路径的准确实时拥塞状态信息。这将显著提升网络中的拥塞处理能力和流量传输效率。
那么,如何收集路径的拥塞状态信息呢?我们有一种被称为CC(拥塞控制,Congestion Control)或带内遥测(In-band Telemetry,简称INT)的拥塞信令机制。在这种方法中,数据路径上的每个节点都会在数据包中添加关于拥塞水平的元数据。例如,在图中所示的场景中,发送方的数据包会经过三个交换机,每个交换机都会向数据包中添加一些相关信息。这些信息通常包括队列深度、缓冲区水平、链路利用率等关键指标。
实现这一功能有两种主要方式:
我们可以将元数据直接嵌入到实际的数据包中。
或者,我们可以采用某种定期探测机制来收集这些信息。
当接收方接收到包含元数据的数据包时,它可以将这些信息反馈给发送方。这样,发送方就能够了解网络中各个部分的拥塞情况。基于这些反馈信息,发送方可以实施特定的算法来应对不同的拥塞场景。如图所示,三个交换机处于不同的拥塞级别(红色表示最高拥塞级别)。当发送方获得这些信息后,它可以通过调整传输速率来避免拥塞的发生,并确保拥塞交换机与接收方之间的链路在所有发送方之间得到公平使用。如果没有这些反馈信息作为指导,发送方可能会盲目地发送数据而导致网络拥塞加剧,进而引发流量的停停走走现象以及延迟、丢包和重传等问题的出现。
实施此方案的成本在于需要专业硬件的支持,这些硬件能够以相当高的速率在每个跳点处插入元数据。
HPCC(高精度拥塞控制,High-Precision Congestion Control)适用于高带宽、低往返时间(RTT)的环境。拥塞控制协议需确定在任意时刻以何种速率发送流量,并迅速提升至链路速度。例如,在HPC应用中,常需传输大量数据,有时高达1MB或80MB。通常情况下,如幻灯片所示,一个数据块通过800Gbps链路传输仅需10微秒,大约为一个往返时间。
在此情境下,传输80MB数据需8个往返时间。若使用TCP协议,其窗口会逐渐增大,导致不必要的网络负载。此外,发生拥塞时,需迅速回退,因为传统拥塞控制机制,如ECN,响应过慢。
HPC拥塞控制分为以下两种类型:
  • 基于发送方的拥塞控制(Sender-based):类似于TCP,多个发送方独立运作,采用各自算法检测丢包和拥塞。发生拥塞时,它们调整带宽份额,以较小比例发送数据。Delay Mark和Trim被用作拥塞指示器。该方法受TCP启发,但针对高带宽、低RTT环境进行了优化。
  • 基于接收方的拥塞控制(Receiver-based):在此方法中,接收方为传入的发送方分配信用,并控制发送方的流量发送速率。这对于管理回传拥塞(Incast)情况尤为有效,即多个发送方将数据发送至同一接收方。接收方控制流量,以确保最后一条链路既不过载也不闲置。
这些是UEC目前正在研究的部分拥塞控制技术。
我们在前一张幻灯片中讨论了如何避免拥塞,但丢包在所难免。在TCP启动并基于丢包调整窗口大小之前,会发生重传。选择性确认(Selective Acknowledgement,SACK)与Go-back-N帧的工作机制不同,后者要求从丢失点重新发送数据包。相反,SACK允许发送方仅重传丢失的数据包,从而优化带宽并降低延迟。
然而,要实现快速重传,接收方必须迅速检测丢包。当使用数据包喷射等技术时,问题变得更为复杂,因为数据包喷射会导致乱序传输。在此情况下,接收方无法仅凭序列号轻松判断哪个数据包丢失。那么,接收方如何迅速得知数据包丢失呢?
数据包修剪(Packet Trimming)在数据包因网络拥塞即将被丢弃时发挥作用。与其丢弃整个数据包,交换机会将数据包修剪至64字节(包括相关信息),并通过高优先级路径发送至接收方。接收方收到修剪后的数据包时,可识别出该数据包已被丢弃,并启动重传请求。
接收方触发选择性确认,以重传丢失的数据包给发送方。发送方随后可使用选择性确认作为拥塞指示器,这不仅能使其重传数据包,还能采取适当措施管理拥塞,如将流量转移至其他路径。
我们讨论了拥塞避免、拥塞控制和丢包情况下的重传技术。网络中另一种严重的拥塞形式是回传拥塞(Incast),它发生在GPU或KN与其连接设备的最后交换节点。在此情况下,无法采用备用路径,发送方解决问题的唯一方法是减少流量,并更公平地使用该链路。这会增加延迟,尤其是在使用All-Reduce集合通信时,需集成来自所有GPU的梯度,并将结果发送回所有GPU。单个GPU将来自所有其他GPU的信息汇总,导致大量流量集中到一个特定的GPU上。
如图所示,最后链路处于严重拥塞状态,因为多个GPU以多对一的模式向其发送数据。在网络集合通信中,一些集合操作被卸载到交换机上,交换机可在多个节点聚合流量,从而减轻最后链路的负载。图中展示了一个聚合树,每个节点聚合下游流量并将其转发至上游。这种技术减轻了网络的压力,提高了整体效率。
然而,在将网络内集合操作与数据包喷射结合使用时需谨慎,因为网络内集合操作期望流量沿着通过相同交换机的特定路径流动。将两者结合使用可能会导致路径一致性问题。
此表格探讨了AI和HPC网络的要求,以及UEC Transport与传统RDMA相比所提供的功能及其优势。
我相信我们已涵盖了大部分内容,除了安全性方面。UEC Transport内置了安全功能,但这部分内容将留待另一个会议讨论。除此之外,我们已讨论了上述所有要点。
总结本次会议:我们讨论了LLM规模的重要性,特别是为何需要大量GPU来执行训练任务。我们还探讨了GPU网络架构的概念、类型及其连接方式。我们涵盖了Scale-up和Scale-out网络架构,以及以太网为何成为这些网络的主要方案之一。此外,我们讨论了CLOS规模扩展和轨道优化拓扑规模扩展拓扑结构。我们还讨论了集群中的流量需求以及UEC如何解决现代工作负载所带来的新挑战。
----------
参考资料:Raguraman Sundaram, Celestica. "Ethernet in the Age of AI: Adapting to New Networking Challenges." YouTube, November 19, 2024. https://www.youtube.com/watch?v=gDVipgme3Rc.

—END—


点击下方名片


即刻关注我们


算力猩
隶属于智猩猩,关注计算芯片创新,解读中国算力突破。
 最新文章