算力集群 基础介绍(一)
多轨接入时GPU服务器的多张显卡会接入不同Leaf交换机,跨轨道的流量能经Spine层转发,仅需两跳就可实现任意GPU间的灵活通信,适配复杂分布式训练的各类通信需求,但布线需用光纤等,成本和功耗较高。DP数据并行----通信操作:All Reduce----单卡通信量:GB级别----通信卡数为全部卡、多组-----通信需求:高吞吐、无拥塞。PP流水线并行----通信操作:Sent/Rev----
高效算力集群
-
集群总算力=单服务器算力×联接规模×联接效率×联接可用率
-
服务器集群规模是前提,网络吞吐效率是关键,可用率是保障
-
联接规模:千卡、万卡...
-
联接效率:网络吞吐量的能力直接或间接影响整个网络效率
-
-
组网规模
-
胖树架构的单POD容量完全取决于单设备端口能力,单设备端口密度越大,大规模组网能力越强
-
单台盒式可支持:128*400G------二层盒盒--------可实现8K卡
-
AI算力集群特点
-
吞吐大、时延低、无拥塞的网络支持
-
AI集群通信特点:
-
DP通信同号卡之间的All Reduce数据
-
DP数据并行----通信操作:All Reduce----单卡通信量:GB级别----通信卡数为全部卡、多组-----通信需求:高吞吐、无拥塞
-
-
PP通信对尾时延极度敏感,所以尽量选择单跳通信
-
PP流水线并行----通信操作:Sent/Rev----单卡通信量:MB级别----通信卡数为多机2卡-----通信需求P2P低尾延时
-
-
POD数量越少,跨POD上Spine的流量越少,拥塞概率越低,要求单POD包含尽量多的GPU
-
集群网络的带宽越大越好,跳数越少越好,单POD规模越大越好
-
组网中的多轨接入与单轨接入
单轨与多轨组网场景及优缺点
-
单轨网络:
整个集群只有一个统一的、大规模的非阻塞交换网络,整个GPU集群构建在一个大型CLOS Fabric上。所有GPU间通信都在这一套网络内进行。
-
描述:
-
优点:
-
网络利用率高,无带宽闲置;
-
管理简单,只有一个平面;
-
延迟一致。
-
缺点:
-
故障域大,网络核心的故障或维护可能影响整个集群;
-
对核心交换机规模和端口密度要求高;
-
流量干扰,计算流量、存储流量、管理流量可能相互竞争。
-
-
多轨网络:
集群被划分为多个独立的、较小规模的交换机网络(轨道),GPU服务器跨轨连接。将网络功能物理隔离为多个独立的平面,最常见的是参数面、存储面、管理面分离。
-
描述:
-
优点:
-
故障隔离,一个平面故障不影响其他平面;
-
可以分期建设,每个轨道可以独立扩容;
-
对单台核心交换机要求低。
-
缺点:
-
网络利用率不均,存在轨道之间通信的瓶颈
-
管理复杂度高,有多个网络平面
-
跨轨通信需要上层路由,会增加延迟。
-
-
组网场景
-
单轨: 适用于千卡以下中、小规模AI/HPC集群,或对成本和运维简易性要求高的场景。
-
多轨(尤其是参数/存储/管理分离): 是大规模、超大规模AI集群(千卡以上)的标准实践。
-
1.
-
张量并行(TP)中的All gather和Reduce scatter通信,在参与张量并行的GPU内部发生,主要在HB(高带宽)域内;
-
数据并行(DP)中的All reduce通信,涉及所有GPU,但通信量相对较小,主要在NIC域内;
-
流水线并行(PP)中的P2P通信,通常在NIC域内,但可以通过优化保持在同一个轨道(Rail)内。
-
根据GPU服务器接入模式的不同,通常会分成单轨接入和多轨接入。多轨接入情况下,根据整体网络结构的不同分为轨道优化架构(Rail-optimized)和纯轨架构(Rail-only)。
-
多轨组网
-
同卡流量互访是频繁的,多轨可以一跳直达,单轨要跨POD,至少需要三跳(卡-leaf-spine)
-
部署方式:同机8块GPU分别连接到8台leaf,同Leaf下为同卡号GPU;
-
多轨部署特点:单POD下GPU数量更多,POD内一跳转发无拥塞;跨POD上Spine转发的流量更少,产生拥塞概率低
-
轨道优化架构:完全契合标准Leaf - Spine拓扑。轨道交换机对应Leaf层,额外保留Spine层交换机。多轨接入时GPU服务器的多张显卡会接入不同Leaf交换机,跨轨道的流量能经Spine层转发,仅需两跳就可实现任意GPU间的灵活通信,适配复杂分布式训练的各类通信需求,但布线需用光纤等,成本和功耗较高。
-
纯轨架构:只有Leaf层轨道交换机。同一轨道内的同卡号GPU可直接通信,而不同轨道的GPU跨域通信需经自身所在域内转发才能实现。它虽牺牲了部分跨轨道通信灵活性,但大幅减少了Spine层硬件投入,布线还可采用低成本DAC铜缆,适合训练场景单一、追求成本优化的集群。
-
-
单轨组网
-
部署方式:同机8块GPU全部连接到1台leaf,单个Leaf视为单轨;
-
多轨部署特点:单POD下GPU数量较少,单POD内一跳转发无拥塞;跨POD上Spine转发的流量更多,产生拥塞概率高
-
单轨部署时,Leaf交换机可以采用ToR(Top of Rack,机柜顶部)或MoR(Middle of Rack,机柜中部)的部署方式,从而可以在接入层面采用DAC铜缆接入,DAC铜缆散热好、功耗低、可靠性高、综合成本也更核算。
-
-
多轨组网+大容量Leaf是支撑POD的关键
-
多轨部署POD规模大于单轨,且POD下容纳的卡数会更多,跨POD流量拥塞概率低
-
盒框式交换机
-
盒盒组网、框盒组网的影响面:
-
盒式设备占用空间、功耗会更小、性价比高
-
框式设备有线卡,有网板,虽然端口更多,但功耗大、体积大、实现的原理会更复杂
-
-
框式报文转发至少需要三跳(LineCard--Fabric--LineCard);盒式里面是单芯片,一跳即可。
-
时延差距
-
框式:线卡内部的一跳可能是多芯片,导致显卡内部跨芯片,然后到网板的过程中,流量运行更复杂,假设出现故障,定位和恢复也更复杂。
-
组网方案
-
单节点组网
-
二层盒盒
-
leaf-spine之间负载均衡技术ECMP静态哈希,动态的负载均衡技术、逐流、逐包技术
-
-
框盒组网
-
盒式-款式(线卡----网板)相当于三层
-
META采用RoCE技术构建两万卡大模型网络
-
-
三层盒盒
-
万卡以上可以再加core、Super- spine switch
-
网络架构规划
-
不同组网区域的带宽要求不同
-
参数网络/后端 400G,根据GPU性能决定
-
存储网100G、200G
-
业务网、管理网25G左右
-
-
千卡组网实例
Spine台数=总卡/单台spine下行口数=8台
-
参数网千卡图--设备选用128口400G的交换机
-
1K组网:leaf台数=总卡/单台leaf下行口数=16台
-
leaf连接GPU的方式:
-
部署为二层以太网口,部署interface vlan网关,为GPU网卡分配业务网段
-
8台leaf为一组,可以称为一个Segment。Segment=leaf数/8=2组
-
一台服务器的八个网卡,分别连接到一个Segment的8台leaf-----单归属单挂方式
-
-
leaf连接Spine的方式:
-
部署为三层路由口,通常为30位互联网段。
-
spine8台,leaf16台,均分的话leaf到每一台spine有8根线。16×64÷8=8根。每两台Spine-leaf之间是8根线。
-
-
-
二层Spine-Leaf组网的拥塞控制部署
-
Spine-Leaf通常会有拥塞,同卡号leaf层即可解决,leaf到spine多打一也许会有拥塞
-
部署:
-
RDMA网卡可运行DCQCN算法、RTTCC、HPCC等
-
leaf连接GPU网卡端口、leaf连接Spine端口、Spine连接Leaf端口,均可部署PFC+ECN
-
交换机水线、动态调优
-
spine-core核心层时 推荐只开启ECN,PFC的组网规模和环路的影响可能会产生失锁
-
-
-
二层Spine-Leaf组网---路由规划---路由协议选择
-
Underlay的路由协议建议选择EBGP
-
Spine相同AS号
-
Leaf不同AS号,可以解决环路的问题
-
Leaf AS相同优点:路由属性相同,路由可以汇总,减少Update报文数量------智算组网本身架构简单、路由量少
-
Leaf AS相同缺点:需要学习其他Leaf的路由,需要配置allow-as-path破解AS-path防环机制
-
-
-
二层Spine-Leaf组网---路由规划---Leaf网段规划
-
leaf发布不同网段路由
-
每台leaf的网段不同,明细路由和流量可以明确找到下一跳,不会有组播或广播的现象,无需发布明细的主机路由。spine收到某一台leaf网段路由,可以直接去往这台leaf,不会去往所有的leaf。
-
-
leaf发布相同网段路由
-
-
二层Spine-Leaf组网---路由发布流程
①leaf4学习到D网卡的ARP,形成本地直连路由,优先级0;
②leaf4将直连网卡的网段路由发布给spine1/2,spine1/2形成BGP路由,优先级255;
③spine1/2将该网段路由发给leaf1/2/3,leaf1/2/3形成BGP路由,优先级255;
CLOS基础架构及扩展
-
CLOS架构最简洁的部署方式是Spine-Leaf的两层网络架构。
-
两层CLOS架构下,能够接入的服务器网口数量受到限制,当网络规模较大时,就需要对两层CLOS架构进行扩展,对应的扩展模式主要有两种,分别是基于虚拟机框的扩展方式和基于Pod的扩展方式。
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目,面向数字基础设施四大核心场景(服务器、云计算、边缘计算、嵌入式),全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐
所有评论(0)