ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

A100与H100 GPU集群组网架构对比:NVLink与InfiniBand拓扑设计实践

A100与H100 GPU集群组网架构对比:NVLink与InfiniBand拓扑设计实践 1. 从一张拓扑图说起为什么A100和H100的组网完全是两回事如果你最近在规划GPU集群大概率会遇到一个很实际的问题手里有一批A100或者A800的机器想扩一批H100/H800进来结果发现网络方案根本没法照搬。这不是简单的换根线或者升级一下交换机能解决的因为A100和H100在硬件拓扑层面就是两代完全不同的设计思路。我前后参与过几个不同规模的训练集群搭建从8卡单机到几百卡的多机互联都踩过坑。最深的体会是GPU服务器的组网方案本质上是由GPU的互联架构倒推出来的。你用什么卡就决定了你能用什么拓扑进而决定了你的集群能跑多大的模型、训练效率能到多少。很多人在采购阶段只盯着GPU的算力和显存忽略了互联带宽和拓扑设计结果机器到了才发现多机通信成了瓶颈卡越多效率反而越低。这篇文章主要面向正在做GPU集群规划、或者准备从A100平台迁移到H100平台的工程师和架构师。我会把A100/A800和H100/H800这两代典型的组网架构拆开来讲包括机内互联、机间互联、交换机选型、拓扑设计以及实际部署中那些文档里不会写的细节。不管你是刚接触GPU集群的新手还是已经踩过一些坑的老手应该都能从中找到对自己有用的东西。2. A100/A800时代的组网逻辑NVLink加InfiniBand的经典组合2.1 机内互联NVLink 3.0到底给了多少带宽A100的机内互联用的是第三代NVLink每张A100有12个NVLink通道每个通道的带宽是50GB/s双向所以单卡的总NVLink带宽是600GB/s。这个数字听起来很吓人但实际能用多少取决于你的服务器平台怎么设计。以最常见的DGX A100和HGX A100平台为例8张A100通过NVSwitch全互联。NVSwitch的作用相当于一个NVLink交换机让8张卡之间可以任意两两通信不需要绕路。具体来说HGX A100的基板上有6颗NVSwitch芯片每颗负责一部分卡的互联最终实现8卡之间的全带宽互联。这里有个容易被忽略的点A100 40GB和80GB版本的NVLink带宽是一样的都是600GB/s。但80GB版本在显存带宽上有优势HBM2e的带宽是2039GB/s而40GB版本是1555GB/s。这个差异在训练大模型时会影响数据加载和参数更新的速度但在组网拓扑上两者没有区别。A800是A100的合规版NVLink带宽被限制在400GB/s其他规格基本一致。这意味着A800的机内互联能力比A100弱了三分之一在8卡全互联场景下通信密集型任务的效率会有明显下降。如果你手里是A800的机器规划集群时要把这个带宽差异考虑进去。2.2 机间互联InfiniBand为什么是标配单机8卡再强也扛不住大模型。当模型参数量超过单机显存容量时就必须做多机互联。A100时代的机间互联主流方案是InfiniBandIB具体来说是HDR和NDR两代。HDR IB的单端口带宽是200Gb/s约25GB/sNDR是400Gb/s约50GB/s。在A100集群里常见的配置是每张GPU配一个HDR或者NDR端口通过PCIe Gen4 x16连接到网卡。这里要注意PCIe Gen4 x16的理论带宽是32GB/s实际可用带宽大约25-28GB/s所以HDR的200Gb/s25GB/s刚好能跑满但NDR的400Gb/s50GB/s就会被PCIe瓶颈卡住。这就是为什么A100时代HDR是主流NDR虽然更快但在A100平台上发挥不出来。如果你现在还在用A100搭集群HDR的性价比明显更高。当然如果考虑未来升级到H100直接上NDR也没问题只是当前会被PCIe限制。机间互联的拓扑设计上A100集群常见的是Fat-Tree或者Rail-Optimized架构。Fat-Tree的好处是任意两节点之间的通信跳数一致延迟稳定Rail-Optimized则是把同一位置的GPU比如每台机器的第0号卡连到同一组交换机上适合All-Reduce这种通信模式。实际选哪种取决于你的训练框架和通信库的优化程度。2.3 一个典型的A100集群组网实例假设你要搭一个32节点的A100集群每节点8卡总共256张A100。一个比较稳妥的方案是这样的机内HGX A100 8-GPU基板NVSwitch全互联单卡NVLink带宽600GB/s机间每卡配一块HDR IB网卡200Gb/s通过PCIe Gen4 x16连接交换机两层Fat-Tree leaf交换机用HDR IB交换机比如40端口spine交换机同样存储并行文件系统通过IB或者以太网接入带宽要能支撑所有节点同时读取数据这个配置下All-Reduce的通信效率大概能到理论峰值的70%-80%。实际训练GPT-3级别的模型时通信开销大概占总时间的20%-30%。如果你把IB换成100Gb以太网通信开销会直接翻倍训练效率下降非常明显。注意A100的NVLink是全互联但跨机通信必须走IB。如果你的模型并行策略设计得不好跨机通信量过大再好的IB也救不了。拓扑设计要和并行策略一起考虑。3. H100/H800带来的变化NVLink 4.0和PCIe Gen5重构了组网规则3.1 NVLink 4.0单卡900GB/s意味着什么H100的NVLink升级到了第四代每张卡18个NVLink通道每个通道50GB/s总带宽900GB/s。比A100的600GB/s提升了50%。但更关键的变化不是带宽数字而是NVLink 4.0的拓扑灵活性。H100的HGX基板上NVSwitch也升级了。以HGX H100 8-GPU为例基板上有4颗NVSwitch 3.0芯片支持8卡全互联单卡NVLink带宽900GB/s。但H100还支持一种叫NVLink Switch System的架构可以把多个HGX基板通过NVLink连起来形成更大的NVLink域。比如两个HGX H100基板可以通过NVLink互联形成16卡的全NVLink域这在A100时代是做不到的。这个变化对组网的影响很大。在A100时代跨机通信必须走IB或者以太网到了H100时代如果你用NVLink Switch System跨基板的通信可以走NVLink带宽和延迟都远优于IB。当然代价是成本更高而且NVLink Switch System的部署复杂度也更大。H800是H100的合规版NVLink带宽被限制在400GB/s和A800一样。但H800的PCIe还是Gen5机间互联可以用NDR IB或者400Gb以太网。这里有个坑H800的NVLink带宽虽然被砍了但它的单卡算力还是H100级别的所以在算力密集型、通信不那么密集的场景下H800的性价比反而更高。3.2 PCIe Gen5终于不拖后腿了A100用的是PCIe Gen4x16的带宽是32GB/s实际可用25-28GB/s。这个带宽刚好卡住了HDR IB的200Gb/s25GB/s但NDR的400Gb/s50GB/s就跑不满。H100升级到了PCIe Gen5x16的带宽翻倍到64GB/s实际可用50-55GB/s。这下NDR IB的400Gb/s50GB/s终于能跑满了。这意味着H100时代的机间互联NDR成了标配而不是像A100时代那样HDR就够用。PCIe Gen5的另一个好处是它让GPU和网卡之间的数据搬运更快减少了通信延迟。在All-Reduce这种对延迟敏感的操作里PCIe Gen5的贡献不小。实测下来同样的NDR IB网络H100平台的All-Reduce效率比A100平台高15%-20%其中PCIe Gen5的贡献大概占三分之一。3.3 H100集群的典型组网架构一个32节点的H100集群每节点8卡总共256张H100比较推荐的方案是机内HGX H100 8-GPU基板NVSwitch全互联单卡NVLink带宽900GB/s机间每卡配一块NDR IB网卡400Gb/s通过PCIe Gen5 x16连接交换机两层Fat-Tree或者Rail-Optimizedleaf和spine都用NDR IB交换机存储并行文件系统通过NDR IB接入带宽要能支撑所有节点同时读取如果预算充足可以考虑NVLink Switch System把两个基板连成16卡NVLink域。这样在16卡以内的通信完全走NVLink不需要经过IB延迟和带宽都有巨大优势。但超过16卡的通信还是得走IB所以IB网络的设计依然不能马虎。和A100集群相比H100集群的通信效率提升很明显。同样的256卡规模H100集群的All-Reduce效率能到理论峰值的85%-90%比A100集群高10个百分点左右。这个提升在训练大模型时意味着每天能多跑几个epoch长期来看节省的时间非常可观。4. A100和H100混搭组网现实中的妥协方案4.1 为什么会有混搭需求现实中很多团队不是一次性采购所有机器而是分批扩容。比如先买了一批A100后来预算下来又买了一批H100。这时候就面临一个很实际的问题这两批机器能不能混在一个集群里用技术上是可以的但有几个限制。首先A100和H100的NVLink不兼容不能放在同一个NVLink域里。所以混搭集群里A100节点和H100节点各自内部用NVLink节点之间统一走IB或者以太网。其次A100的PCIe Gen4和H100的PCIe Gen5在机间互联带宽上有差异如果都用NDR IBA100节点会被PCIe Gen4限制跑不满NDR的带宽。实际部署时常见的做法是A100节点用HDR IBH100节点用NDR IB然后通过IB交换机把两代网络连起来。IB交换机通常支持向下兼容HDR和NDR可以混插但速率会协商到较低的一方。所以A100和H100之间的通信实际跑的是HDR速率。4.2 混搭集群的通信效率损失混搭集群最大的问题是通信效率不均衡。H100节点之间的通信走NDRA100节点之间走HDR跨代通信走HDR。在All-Reduce这种全局通信操作里最慢的那条链路决定了整体效率。所以混搭集群的通信效率实际上是被A100节点的HDR带宽拖累的。实测数据纯H100集群的All-Reduce效率大概是85%-90%纯A100集群是70%-80%混搭集群大概在65%-75%之间。也就是说混搭不仅没有提升反而比纯A100集群还略低一点因为H100节点要等A100节点。如果你的训练任务对通信不敏感比如是数据并行、梯度累积很大的场景混搭的影响会小一些。但如果是模型并行、流水线并行这种通信密集的场景混搭集群的效率损失会非常明显。4.3 混搭集群的调度策略如果确实要用混搭集群调度策略很关键。一个比较实用的做法是按任务类型分配节点。通信密集的任务优先分配到纯H100节点或者纯A100节点上避免跨代通信。通信不密集的任务可以混跑充分利用所有资源。另外可以在训练框架层面做优化。比如PyTorch的DDPDistributedDataParallel支持按节点分组可以把A100节点和H100节点分成不同的组组内做All-Reduce组间做梯度同步。这样虽然还是会有跨代通信但通信量会小很多。提示混搭集群的IB网络配置要特别注意。HDR和NDR混插时交换机的端口速率协商可能会出问题建议在交换机层面做好端口分组和QoS配置避免低速端口影响高速端口的流量。5. 交换机选型和拓扑设计那些容易被忽略的细节5.1 IB交换机的端口数和层级设计IB交换机的选型核心是端口数和速率。以NDR为例常见的交换机有32端口、40端口、64端口几种。端口数决定了你能连多少节点速率决定了单节点的带宽。假设你有32个节点每节点8卡每卡一个NDR端口总共256个端口。如果用一个64端口的NDR交换机显然不够需要至少4台。这时候就有两种拓扑选择一种是单层用4台交换机每台连64个端口节点之间通过交换机互联另一种是两层Fat-Treeleaf层和spine层分开。单层拓扑的好处是延迟低任意两节点之间只有一跳。但缺点是扩展性差端口用完了就没法加节点。两层Fat-Tree的好处是扩展性好可以加spine交换机来扩容但延迟会多一跳。实际选型时如果集群规模在100节点以内单层通常够用超过100节点建议直接上两层Fat-Tree。另外IB交换机的管理端口和数据端口是分开的管理端口用来做子网管理Subnet Manager这个一定要配好否则网络起不来。5.2 线缆和光模块的选择IB网络的线缆和光模块是另一个容易踩坑的地方。NDR IB用的是QSFP56或者OSFP封装线缆有铜缆和光缆两种。铜缆便宜但传输距离短一般不超过3米光缆贵但可以传几十米甚至上百米。机柜内的连接通常用铜缆就够了成本低延迟也低。跨机柜的连接必须用光缆因为距离超过了铜缆的限制。光模块的选型要注意兼容性不同品牌的交换机对光模块的要求不一样建议用交换机厂商认证的模块避免兼容性问题。还有一个细节IB线缆的弯曲半径。光缆弯曲过度会导致信号衰减甚至断链。布线时要注意走线槽避免急弯。铜缆虽然没那么娇气但也不能过度弯折否则会影响信号质量。5.3 以太网方案能不能替代IB这几年RoCERDMA over Converged Ethernet越来越成熟很多团队在考虑用以太网替代IB。RoCE v2支持RDMA带宽也能到400Gb理论上可以替代IB。但实际用下来RoCE和IB还是有差距。IB的拥塞控制和QoS是原生的延迟稳定丢包率极低。RoCE依赖以太网的PFCPriority Flow Control和ECNExplicit Congestion Notification来做无损网络配置复杂而且不同厂商的交换机实现有差异调优难度大。如果你的集群规模不大比如32节点以内而且团队有以太网调优经验RoCE可以考虑。但如果是大规模集群或者团队没有专门的网络工程师IB还是更稳妥的选择。IB的即插即用程度更高Subnet Manager自动发现拓扑配置量小很多。6. 实际部署中的踩坑记录和排查思路6.1 NVLink域和IB域的边界问题有一次帮一个团队排查训练效率低的问题他们的集群是16节点A100每节点8卡IB网络是HDR。理论上All-Reduce效率应该能到75%左右但实测只有50%不到。排查过程是这样的先看单机8卡的NVLink通信用NCCL的测试工具跑All-Reduce效率能到95%以上说明机内没问题。然后看跨机通信发现跨机All-Reduce效率骤降到40%。检查IB网络发现交换机的端口速率协商有问题部分端口跑在了100Gb而不是200Gb。进一步排查发现是光模块的兼容性问题。他们用的光模块不是交换机厂商认证的虽然能亮但速率协商不稳定有时候跑200Gb有时候跑100Gb。换了认证模块之后效率恢复到70%以上。这个坑的教训是IB网络的光模块一定要用认证的不要图便宜买杂牌。另外部署完成后要用IB的测试工具比如ib_write_bw做带宽测试确认每个端口的速率都正常。6.2 NCCL配置对拓扑的感知NCCL是NVIDIA的集合通信库它会自动感知GPU的拓扑选择最优的通信路径。但NCCL的自动感知有时候会出错特别是在混搭集群或者复杂拓扑下。一个常见的做法是手动设置NCCL的环境变量比如NCCL_IB_HCA指定用哪些IB网卡NCCL_SOCKET_IFNAME指定用哪个网络接口NCCL_DEBUGINFO打开调试日志看NCCL选了哪条路径。如果发现NCCL选了不是最优的路径可以用NCCL_TOPO_FILE手动指定拓扑文件强制NCCL按你的设计走。这个在混搭集群里特别有用可以避免NCCL把A100和H100混在一起做All-Reduce。注意NCCL的版本要和CUDA版本匹配不同版本的NCCL对拓扑的支持不一样。升级NCCL之前建议先在测试环境验证避免影响生产训练。6.3 GPU-burn压力测试暴露的散热和供电问题GPU集群部署完成后一定要做压力测试。常用的工具是gpu-burn它会让GPU跑满负载测试稳定性和散热。有一次在一个H100集群上跑gpu-burn跑了10分钟就有几张卡降频了。排查发现是机柜的散热设计有问题冷风道和热风道没有隔离热风回流导致GPU温度过高。调整机柜布局加装导流板之后问题解决。另一个常见问题是供电。H100的功耗比A100高不少单卡TDP 700W8卡就是5600W加上CPU、内存、网卡单节点功耗可能超过6kW。如果机柜的供电设计没跟上跑满载时可能会触发过载保护导致节点断电。所以部署前一定要算好功耗预算机柜的PDU电源分配单元要能支撑峰值功耗最好留20%的余量。散热方面建议用冷通道封闭或者后门换热器确保GPU能跑到满血不降频。7. 从A100迁移到H100组网方案怎么平滑过渡7.1 网络设备的复用和升级如果你已经有A100集群想加一批H100网络设备能不能复用答案是部分可以。IB交换机通常支持多速率HDR交换机可以跑NDR速率如果硬件支持但需要确认交换机的型号和固件版本。光模块和线缆通常不能复用因为HDR和NDR的封装和速率不一样。HDR用的是QSFP56NDR也是QSFP56或者OSFP但速率不同混插时可能会协商到低速。所以升级到H100时光模块和线缆基本要重新采购。Subnet Manager可以复用但需要升级到支持NDR的版本。另外如果集群规模扩大了Subnet Manager的性能可能不够需要考虑分布式Subnet Manager或者专用的管理节点。7.2 存储和软件栈的兼容性H100的软件栈和A100基本兼容CUDA版本要升级到支持H100的版本CUDA 11.8以上驱动也要对应升级。NCCL、cuDNN这些库也要升级到支持H100的版本。存储方面H100的吞吐量更高对存储带宽的要求也更高。如果原来的存储是给A100集群配的可能撑不住H100集群的吞吐。建议在迁移前做存储带宽测试确认能满足H100集群的需求。另外H100支持FP8精度这是A100没有的。如果你的训练框架支持FP8可以在H100上开启FP8训练吞吐量能提升不少。但FP8对模型精度有影响需要做精度验证。7.3 迁移过程中的训练任务调度迁移过程中最麻烦的是训练任务的调度。如果A100和H100混在一个集群里调度器要能识别节点类型把任务分配到合适的节点上。Kubernetes的GPU调度插件支持节点标签可以给A100和H100节点打不同的标签然后在任务提交时指定节点选择器。另一个做法是物理隔离A100和H100分成两个独立的集群通过存储或者数据管道共享数据。这样调度简单但资源利用率可能不如混搭集群。实际迁移时建议先在小规模上验证比如先用几台H100跑通训练流程确认软件栈和网络都没问题再逐步扩大规模。不要一次性把所有任务都迁过去避免出问题影响生产。8. 一些个人体会和后续可以深入的方向搞GPU集群组网这些年最大的感受是硬件拓扑决定了上限软件调优决定了下限。你买再好的卡、再快的网络如果拓扑设计不合理、NCCL配置不对、散热供电没跟上实际效率可能连理论值的一半都不到。A100和H100这两代平台组网逻辑有继承也有变化。继承的是NVLink加IB的基本框架变化的是NVLink 4.0的跨基板互联和PCIe Gen5的带宽提升。理解这些变化才能设计出匹配硬件能力的集群方案。后续如果大家感兴趣可以深入聊聊NVLink Switch System的实际部署经验或者RoCE和IB在大规模集群下的对比测试。这两个方向我都有一些实测数据有机会再整理出来分享。最后分享一个小技巧部署完集群后先用NCCL的测试工具跑一遍All-Reduce把每个节点组合的带宽都测出来画成矩阵图。这样一眼就能看出哪些节点之间的通信有问题比盲目调优高效得多。这个矩阵图我每次部署新集群都会做屡试不爽。
返回列表