什么是 GPU 集群网络、集群大小和集群运算?
引言
在生成式AI(GenAI)和大模型时代,不仅需要关注单个GPU卡的算力,更要关注GPU集群的总有效算力。单个GPU卡的有效算力可以通过该卡的峰值算力来测算,例如,对于Nvidia A100,峰值FP16/BF16稠密算力是312 TFLOPS,单卡有效算力约为~298 TFLOPS [1, 2]。
本篇将聊聊GPU集群网络配置和GPU集群规模以及总有效算力,重点讨论算力网络平面。因为存储和管理网络平面相对比较简单,本文就不赘述了。
GPU集群网络架构示例(两层计算网络)[3]
GPU服务器网卡配置
GPU集群的规模和总有效算力,很大程度上取决于GPU集群网络配置和使用的交换机设备。对于每一款Nvidia GPU服务器,Nvidia都有对应的推荐GPU集群网络配置,例如,对于DGX A100服务器,推荐的服务器之间网络连接是 200 Gbps/卡(即每张A100卡都对应200 Gbps网络连接与其他服务器中的A100卡通信),单台DGX A100服务器配置8张计算网络卡(如InfiniBand 200 Gbps)[1, 2]。
DGX A100 System, Server Block Diagram [2]
那么GPU服务器之间的计算网络带宽是依据什么来确定的呢?
除了成本因素之外,GPU服务器之间的计算网络带宽是由GPU卡所支持的PCIe带宽决定的,这是因为GPU服务器配置的计算网络的网卡是通过PCIe Switch与GPU卡进行连接的(GPU <--> PCIe Switch <--> NIC),那么PCIe的带宽就限制了计算网络的带宽。
举例而言,对于Nvidia DGX A100服务器,因为单张A100卡支持的是PCIe Gen4,双向带宽是64 GB/s,单向带宽是 32 GB/s,即 256 Gbps。所以,为单张A100卡配置 200 Gbps 的网卡就足够了。所以,单看计算网络,Nvidia DGX A100服务器配置的是8张 Mellanox ConnectX-6 InfiniBand 网卡(注:也可以配置 Mellanox ConnectX-7,因为ConnectX-7也支持 200 Gbps)。如果是给A100卡配置 400 Gbps 的网卡,因为受到PCIe Gen4带宽限制,400 Gbps 的网卡作用是发挥不出来的(那么就浪费了很多网卡带宽)。
Nvidia DGX A100 system topology [4]
对于Nvidia DGX H100服务器,因为单张H100卡支持的是PCIe Gen5,双向带宽是128 GB/s,单向带宽是 64 GB/s,即 512 Gbps。所以,为单张H100卡配置 400 Gbps 的计算网卡是Nvidia推荐的标准配置 。单看计算网络,Nvidia DGX H100服务器配置的是8张 Mellanox ConnectX-7 InfiniBand 网卡,单个H100卡拥有 400 Gbps 对外网络连接 [5]。
DGX H100 Configuration [5, 6]
需要说明的是,对于A800和H800服务器的计算网络配置,国内使用A800和H800服务器一般不是采用Nvidia DGX推荐的标准配置。例如,对于A800服务器,计算网卡配置常见的有两种方式:第一种是 8 x 200 GbE,即每张A800卡有单独的200 GbE网卡配置(8张A800卡一共有 ~1.6 Tbps RoCEv2计算网络连接[7]);第二种是 4 x 200 GbE,即每两张A800卡共享一个200 GbE网卡,单卡最高是200 GbE网络,平均每张A800卡有对外100GbE的连接 [7]。第二种方式类似Nvidia DGX V100的设计 [8]。考虑到可以先在A800服务器内进行通信聚合,然后再与其他服务器通信,所以这两种计算网卡配置方式对于整个集群效率的影响基本一致。
H800支持PCIe Gen5,对于H800服务器,常见的计算网卡配置方式是 8 x 400GbE,即每张H800卡有单独的400 GbE网卡配置,每张H800卡都有对外400 GbE的计算网络连接,8张H800卡一共有 ~3.2 Tbps RoCEv2 计算网络连接 [7]。
这里还想谈一下华为昇腾910B NPU卡。昇腾910B支持PCIe Gen5 [15],也就是说理论上昇腾910B单卡可以配置400 GbE的对外网络连接。例如,装配有16卡昇腾910B的服务器一般可以选择配置 8 x 400 GbE网卡,也就是单卡最高是400 GbE网络,平均每卡是200 GbE网络。华为昇腾910B采用的是NPU直出200 GbE的设计,所以每个NPU直接连接的是200 GbE的网络,那么装配有16卡昇腾910B的服务器一般配置 16 x 200 GbE网卡,装配有8卡昇腾910B的服务器一般配置 8 x 200 GbE网卡。
Nvidia使用NVLink和NVSwitch实现了单个服务器内多个GPU之间的高速互联,而使用多个服务器组建集群时,PCIe带宽仍然是主要性能瓶颈(集群网络瓶颈),这是因为当前网卡和GPU卡之间的连接主要还是通过PCIe Switch来连接。随着未来PCIe Gen6(2022年标准发布)普及应用,甚至PCIe Gen7(预计2025年标准发布)普及应用,GPU集群的整体性能又会上一个新台阶。还有2024年将要发布的Nvidia H20也是支持PCIe Gen5。
GPU集群网络和集群规模
上面讨论了单个GPU服务器的网卡配置,接下来讨论GPU集群网络架构(GPU cluster fabrics)和集群规模。实践中最常用的GPU集群网络拓扑是胖树(Fat-Tree)无阻塞网络架构(无收敛设计),这是因为Fat-Tree架构易于拓展、路由简单、方便管理和运维、鲁棒性好,且成本相对较低。实践中,一般规模较小的GPU集群计算网络采用两层架构(Leaf-Spine),而规模较大的GPU集群计算网络采用三层架构(Leaf-Spine-Core)。这里 Leaf对应接入层(Access),Spine对应汇聚层(Aggregation),Core对应核心层。
三层Fat-Tree计算网络示例 [9]
假设一个GPU集群的计算网络里采用相同的交换机,每台交换机端口数为P,使用两层Fat-Tree无阻塞计算网络(Leaf-Spine),一个GPU集群里GPU卡的数量最多为 P*P/2 [9, 14]。
在两层Fat-Tree无阻塞计算网络里(Leaf-Spine),第一层中每一台Leaf交换机用P/2个端口来连接GPU卡,另外P/2个端口向上连接Spine交换机(无阻塞网络要求向下和向上连接数量相同)。第二层中每台Spine交换机也有P个端口,可以向下最多连接P台Leaf交换机,所以在两层Fat-Tree无阻塞计算网络里最多有P台Leaf交换机,所以总的GPU卡的数量最多为P*P/2。因为有P个Leaf交换机,每台Leaf交换机有P/2个端口向上连接Spine交换机,所以有P/2个Spine交换机。
例如,对于Nvidia A100集群,假设使用40端口的交换机(如Nvidia Mellanox QM8700),在使用两层Fat-Tree计算网络情况下,一个A100集群最大可以有800个A100卡(40*40/2 = 800)。
两层Fat-Tree计算网络示例 [10]
值得注意的是,如果一台GPU服务器内已经有卡间高速互联了(如NVLink和NVSwitch),则同一台服务器中的GPU卡不应该连接到相同的Leaf交换机上;不同服务器中的编号相同的GPU卡(例如,A服务器中的3号卡 与 B服务器中的3号卡)应该尽量连接到同一个Leaf交换机上,以便提高分布式计算效率(例如,提高跨服务器AllReduce操作的效率)。
需要特别说明的是,对于GPU服务器内没有卡间高速互联解决方案的(例如,L20服务器、L40S服务器),需要尽量将一台服务器内的GPU卡连接到同一台Leaf交换机上 [4],以便避开跨NUMA通信。
我们从上面的分析可以看到,假设使用128端口的交换机,两层Fat-Tree无阻塞计算网络能够接入的最大GPU数量仅为8192(128*128/2 = 8192)。如果要构建更大规模的GPU集群,我们需要从两层计算网络扩展到三层计算网络。
对于规模较大的GPU集群,一般需要采用三层计算网络架构。假设一个GPU集群计算网络里采用相同的交换机,交换机端口数为P,对于三层Fat-Tree无阻塞计算网络(Leaf-Spine-Core),一个GPU集群里GPU卡的数量最多为 P*P*P/4 [9, 14]。
从两层Fat-Tree网络向三层Fat-Tree网络扩展,我们可以把两层Fat-Tree网络看成一个单元(即一个两层Fat-Tree子网络)。因为每台Spine交换机有一半端口向下连接Leaf交换机(每台Spine交换机最多只能连接P/2个Leaf交换机),另一半端口向上连接Core交换机,所以每个两层Fat-Tree子网络里只能有P/2个Leaf交换机。在无阻塞网络里,各层的连接数量都要保持相同,所以Spine交换机和Leaf交换机的数量相同。
因为Core交换机也有P个端口,可以连接P个这样的两层Fat-Tree子网络,所以三层Fat-Tree无阻塞计算网络(Leaf-Spine-Core)中一共有P*P/2个Leaf交换机和P*P/2个Spine交换机,所以GPU卡的总数量最多为(P/2)*(P*P/2),即 P*P*P/4。Spine交换机向上连接Core交换机的连接数为P*P*P/4,所以一共有P*P/4个Core交换机。
H800 GPU集群网络拓扑举例 [11]
从上面的分析我们看到,GPU集群的规模是由计算网络的架构和交换机的端口数决定的(当然,GPU集群规模也受限于机柜、供电、制冷和机房等硬件因素)。我们在下表中举例说明集群规模与交换机端口数的关系,以三层Fat-Tree无阻塞网络为例。
如果一个服务器内有M个GPU共享一个网卡,则GPU总数量要乘以M。例如,如果一个服务器内的两个GPU卡共享一个网卡,例如,装有8卡的A800服务器配置的是 4 x 200 GbE网卡方案,那么GPU卡的总数量还要乘以2(参考Nvidia DGX V100 [8])。
我们从上面的表格可以看到,基于三层Fat-Tree无阻塞网络构建的GPU集群,其规模能够满足大部分大模型训练和分布式计算的需求了,所以就不再需要考虑四层或者更复杂的网络拓扑了。
在上面的分析中,我们假设了整个GPU集群计算网络都是使用相同的交换机,如果Leaf、Spine、Core分别使用不同的交换机(甚至某一层都可能使用不同的网络交换机),那么对于GPU集群网络和集群规模的分析就变得比较复杂了。
GPU集群算力
一个GPU集群的有效算力可以用下面公式表示:Q = C*N*u。其中,Q表示集群总有效算力;C表示集群中单个GPU卡的峰值算力;N表示集群中GPU卡的数量;u表示集群中GPU卡的算力利用率。这里,C是指一个计算任务使用N个GPU卡所能获得的总有效算力。如果使用GPU集群进行大模型训练,那么算力利用率u就是我们常说的MFU (Model FLOPS Utilization)。
关于算力利用率u,我们要进一步区分算力利用率与线性加速比k。即便是我们在使用单张GPU进行计算,也有算力利用率的问题(相应的,也有显存利用率的问题,Model Bandwidth Utilization (MBU)[12]),例如,单卡算力利用率 u = 75%。如果一个计算任务里使用了N个GPU卡,那么算力利用率u一般会随着GPU数量N的增加而变小;总有效算力C会随着N的增加而增加,直到饱和(即N增加的边际效用递减)。一个GPU集群的总有效算力C随着N增加的变化速度就是线性加速比k。
GPU集群总有效算力随着GPU卡数量的变化情况示例 [11]
举例而言,Q1 = C*N1*u1,Q2 = C*N2*u2,那么 k = (Q2/N2) / (Q1/N1) = u2/u1,这里假设 N2 >= N1(所以u2 <= u1),且 Q2 >= Q1。
假设理想情况下,单卡算力利用率 u2 = u1,即线性加速比k为100%,那么随着N的增加,集群总有效算力线性增加。这里线性加速比是说集群总有效算力随着GPU卡数量增加而变化的情况,假设k为100%,那就是完美的线性增长。虽然假设线性加速比k为100%,但是单卡的有效利用率可能会比较低,例如,u2 = u1 = 50%。所以,算力利用率和线性加速比是从两个不同的维度来描述GPU集群性能。
如果假设 u1 = 45.29%(@N1 = 3584),u2 = 42.19%(@N2 = 10752),那么线性加速比就是k = 93% [13]。
实践中,GPU集群的线性加速比受到很多因素影响,包括GPU卡的峰值算力、显存容量、显存带宽、卡间互联方式、服务器间的网络带宽、网络架构、网络交换机、软件和算法等等。在比较好的情况下,一般可以做到线性加速比在90%以上。对于大规模GPU集群,GPU算力利用率一般在50%左右。
参考文献
Introduction to the NVIDIA DGX A100 System
DGX A100 review: Throughput and Hardware Summary - Microway
“GPT们”背后,谁来支撑大模型训练需要的极致算力?-腾讯云开发者社区-腾讯云
GPU 进阶笔记(一):高性能 GPU 服务器硬件拓扑与集群组网(2023)
Introduction to the NVIDIA DGX H100 System
THE NVLINK-NETWORK SWITCH
高性能计算集群 实例规格-文档中心-腾讯云
NVIDIA DGX-1 With Tesla V100 System Architecture
Al智能计算中心网络架构设计实践 | 飞速(FS)社区
How Many Optical Transceivers are Needed for A GPU?
鹅厂发布的这个算力集群,最快4天训练万亿参数大模型-腾讯云开发者社区-腾讯云
LLM Inference Performance Engineering: Best Practices
Acing the Test: NVIDIA Turbocharges Generative AI Training in MLPerf Benchmarks
一文读懂智算中心网络
华为Atlas 300T A2 训练卡 技术白皮书 - 华为企业业务
上一篇: 在激流第 3 层交换机上配置 DHCP
下一篇: 使用第 3 层交换机互通不同的 vlan
推荐阅读
-
【2022新手指南】Java编程进阶之路 - 六、技术架构篇 ### MySQL索引底层解析与优化实战 - 你会讲解MySQL索引的数据结构吗?性能调优技巧知多少? - Redis深度揭秘:你知道多少?从基础到哨兵、主从复制全梳理 - Redis持久化及哨兵模式详解,还有集群搭建和Leader选举黑箱打开 - Zookeeper是个啥?特性和应用场景大公开 - ZooKeeper集群搭建攻略及 Leader选举、读写一致性、共享锁实现细节 - 探究ZooKeeper中的Leader选举机制及其在分布式环境中的作用 - Zab协议深入剖析:原理、功能与在Zookeeper中的核心地位 - RabbitMQ全方位解读:工作模式、消费限流、可靠投递与配置策略 - 设计者视角:RabbitMQ过期时间、死信队列与延时队列实践指南 - RocketMQ特性和应用场景揭示:理解其精髓与差异化优势 - Kafka详细介绍:特性及广泛应用于实时数据处理的场景解析 - ElasticSearch实力揭秘:特性概述与作为搜索引擎的广泛应用 - MongoDB认知升级:非关系型数据库的优势阐述,安装与使用实战教学 - BIO/NIO/AIO网络模型对比:掌握它们的区别与在网络编程中的实际应用 - Netty带你飞:理解其超快速度背后的秘密,包括线程模型分析 - 网络通信黑科技:Netty编解码原理与常用编解码器的应用,Protostuff实战演示 - 解密Netty粘包与拆包现象,怎样有效应对这一常见问题 - 自定义Netty心跳检测机制,轻松调整检测间隔时间的艺术 - Dubbo轻骑兵介绍:核心特性概览,服务降级实战与其实现益处 - Dubbo三大神器解读:本地存根与本地伪装的实战运用与优势呈现 ----------------------- 七、结语与回顾
-
什么是 GPU 集群网络、集群大小和集群运算?
-
[集群聊天项目] 木铎网络库 - 什么是木铎网络库?
-
趣谈留言队列,搞清楚留言队列到底是什么!-说到消息队列,洪觉大概能猜到人们听到消息队列的反应,大致可以分为以下几类人。 第一类人,懵懵懂懂,刚上大学接触编程,还没用过消息队列,甚至还以为消息队列就是代码里面要新建一个List之类的;第二类人,听过消息队列,了解消息队列,但具体是什么还不是太明白,只知道一说到消息队列,脑海里马上出现了三组词,削峰、异步、解耦;第三类人,用过消息队列,对它有一定了解,但不知道为什么要这样设计,消息队列有什么样的前世今生,是如何演化到现在的模式的?**第四类人,已经对消息队列有了足够的了解,可以阅读本帖作为复习和温习。**你属于哪一类?无论你对消息队列了解多少,读完这篇文章后,我相信你都会有所收获。 什么是消息队列?我们为什么要使用消息队列?真的只是因为它看起来很勉强、很常用吗?当然不是,一项技术的出现往往是为了解决某种痛点,我们就从这个痛点出发,看看消息队列到底是为了解决什么问题而诞生的。 相信大家在工作之前,或者工作中接触单片机的次数会多一点,不管什么业务都一股脑塞进一个系统里,这种情况下接触消息队列的场景会比较少。但随着业务的增长,量上去了,单机系统就很难维护了,也扛不住并发量的增长,就需要把原来的单体应用拆分成多个服务。例如,牛奇网采用分布式架构,将原来的单体系统拆分成用户服务、题库服务、求职服务、论坛服务等,每个分布式节点都有一个集群,保证高可用性。 那虽然在这样的微服务架构下,如果某个核心业务并发量过大,系统就扛不住了。比如淘宝、淘票票、拼多多、京东等电商场景中的支付场景,你在某宝下单并支付后,调用支付服务,完成支付后,还需要更新订单的状态,这个时候就需要调用订单服务,那我们平时也下单,除了简单完成这些操作外,还会给你相应的积分;商家也会收到订单消息,并给您发送旺旺消息,确认订单无误;同时,也会给您发送消息,确认订单无误。确认订单无误;同时您还可以查看您的物流状态;还有系统为了给您推荐更适合您的商品,会根据您的订单做类似的推荐等等,我说的这些都是当我们下单后,肉眼可以感知到系统所做的动作。 **一个支付动作如果还需要调用那么多服务,等他们响应成功,最后再告诉用户你支付成功了,用户在系统中的整个体验会非常糟糕。**设想一下,假设请求服务+处理请求+响应总共需要 50ms,我们上面列出的场景:支付服务、订单服务、积分服务、商家服务、物流服务、推荐服务,总共需要 300ms。
-
阿里味 "的《Redis核心实践全彩手册》给你,还学不会转行--Redis基本是必考点。在 "阿里味 "的《Redis核心实战全彩手册》里,你还是学不会转行--Redis基本是必考点: - Redis 常见的性能问题有哪些?Redis 最常见的性能问题有哪些,如何解决?--性能相关 - Redis 缓存的雪崩、击落和穿透到底意味着什么?如何处理?--缓存相关 - Redis 主从集群有哪些常见问题?如何解决?--可用性 - 现有的 Redis 实例有 6GB 的存储空间,预计将来会扩展到 32GB,你能提供解决方案并分析其优势和潜在问题吗?--可扩展性相关 毕竟,10 家公司中至少有 8 家的架构系统中都有 Redis,基本上可以说是 IT 基础架构的必备系统。 因此,Redis 的开发和运维是很多大厂的重要工作,也是我们必须掌握的技术栈。 不过,Redis 毕竟是一个复杂的键值数据库,在实际使用中,有非常多的技术点需要注意,比如:各种数据结构、数据持久化机制、分片集群、主从集群等等。 一不小心,性能就会每况愈下,失去 "快 "的最大特点!