我们团队年初接到一个任务搭建一套支撑大模型训练和科学计算的GPU集群规模是100多台物理GPU服务器每台满配8张GPU卡。整个集群加起来就是800多张卡这个体量在中小企业里已经不算小了无论是硬件采购、网络架构还是后期的运维方式跟实验室里几台机器凑在一起玩完全是两个世界。这篇文章我从头到尾梳理一遍把组网过程中的设计思路、关键选型、实操步骤和踩过的坑都记录下来给准备做同类事情的同行一个完整的参考。我默认你看到这篇文章时至少已经清楚GPU服务器是什么——简单说就是一台x86主机里面插了8张加速卡通过PCIe或NVLink互联专门干并行计算这种体力活。组网这件事的核心不是把这些机器用网线连起来就完事而是要设计一张高性能、低延迟、可扩展、易运维的网络让800多张卡在训练任务里像一台机器那样协同工作。这篇文章适合集群的规划者、运维工程师、算法团队里负责基础设施的同学以及所有准备把自己的训练任务从单机搬到多机的人。1. 项目背景与整体设计思路1.1 需求拆解100台8卡GPU服务器意味着什么我们先算一笔账。100多台物理服务器每台8张卡取个整数按120台算就是960张GPU卡。假设单卡算力是主流A100级别的80 TFLOPSFP16 Tensor Core那整个集群的峰值算力大约是76.8 PFLOPS。这个算力规模放在两年前够得着全球TOP500超算的尾巴今天虽然不算顶尖但已经足够跑千亿参数级别的大模型预训练或者同时支撑几十个中型训练任务并行。这也是为什么AI公司都在疯狂堆GPU——算力这东西单机永远是杯水车薪只有集群才能产生质变。组网到底要解决什么问题核心矛盾就一个GPU算得飞快但卡与卡之间、服务器与服务器之间要把数据搬来搬去。搬得快训练效率就高搬得慢再强的GPU也得在那闲着等数据。大模型训练有个著名的规律如果网络带宽不够多卡训练的加速比会迅速饱和甚至出现“卡越多训练越慢”的诡异现象。所以组网的第一目标是把数据搬运的瓶颈降到最低让分布式训练的通信开销不再成为短板。从实际使用场景看这个集群主要跑两类负载一类是深度学习训练特征是数据并行和模型并行混合需要频繁做梯度同步对网络延迟特别敏感另一类是科学计算比如分子动力学模拟、CFD仿真特征是大规模MPI通信既吃带宽又吃延迟。这两种负载对网络的需求高度一致——低延迟、高带宽、无丢包这就决定了网络方案的大方向。1.2 组网方案选型InfiniBand还是RoCEv2组网方案的大方向无非两种InfiniBandIB和RoCEv2RDMA over Converged Ethernet v2。前者是高性能计算领域的正统血脉后者是近年来随着以太网生态成熟而崛起的性价比之选。我们在这两者之间纠结了相当长时间最后综合算力和预算做出了选择。这里把对比摊开讲对比维度InfiniBandRoCEv2最大单端口速率目前400GbpsNDR规划中800G当前以太网主流的400G也能跑丢包处理无损网络硬件级流控依赖PFC等流控机制配置复杂生态成熟度超算和AI集群的老牌选择NCCL/MPI支持深度优化互联网大厂用得很多但需要精细调优成本交换机和线缆单价高整体溢价明显可以用现有以太网设备成本低不少运维门槛需要子网管理器概念相对独立和现有网络体系无缝兼容兼容性NVIDIA收购Mellanox后与自家GPU结合最好通用性强但也因此少了专用优化我们最后选了InfiniBand。原因不复杂第一这个集群的核心负载就是深度学习和HPCNVIDIA的GPU和IB网络在硬件和软件层面都有深度协同比如GPUDirect RDMA可以让数据绕过CPU和内存直接送到远端GPU这在RoCE环境下也能做但效果打折第二IB是真正的无损网络专为RDMA设计不像RoCE要小心翼翼地伺候流控参数从长期运维角度省心很多第三后期扩展时IB的规模和稳定性上限更高超大规模集群的成熟案例远超RoCE。如果你只是搭个16台机器以内的小集群预算又有限RoCEv2完全够用。但到了我们这个规模稳定性和确定性压倒一切多花的钱买的是安心。1.3 集群网络架构三张网各司其职一个大规模的GPU集群网络上不能只有一根线。我们最终把物理网络分成三张物理隔离的平面各干各的活计算网络跑训练数据、梯度同步、MPI消息走InfiniBand这是整个集群的高速公路。存储网络连接分布式存储集群我们是GPFS你也可以用Lustre、BeeGFS或Ceph走以太网按25G/100G起步。存储网络最好和计算网络物理隔离否则大文件读写会冲击训练通信。管理网络连接BMC/IPMI口、PXE启动物理机、SSH登录、监控数据上报走普通千兆/万兆以太网即可。管理面独立的好处是即使计算网络炸了你还能远程登录服务器排查故障。有人会问存储网络和管理网络能不能合一我的建议是千万别。管理和业务混在一起一次日志采集风暴就可能把训练通信卡到崩溃。三张网分离虽然布线麻烦一些但后续运维的省心程度完全值得。2. 硬件选型与拓扑规划的关键决策2.1 计算节点配置不只盯着GPU看先说服务器本身。100多台8卡GPU服务器市面上主流的选择是NVIDIA HGX平台的整机比如DGX系列或者各大服务器厂商基于HGX的定制机。HGX平台的关键是每8张GPU通过NVLink全互联或者通过NVSwitch连接卡间通信带宽高达600GB/s量级这比走PCIe跨节点通信快了一个数量级。所以节点内部通信问题HGX已经替你解决了组网要解决的是节点和节点之间的通信。节点其他硬件的选型思路我的经验是始终围绕着“别让任何部件拖GPU后腿”来CPU每台双路选Intel Xeon或AMD EPYC核心数不用太多频率也别追求极致主流型号就够。GPU计算不依赖CPU算力CPU主要忙着喂数据、搬内存。内存单机512GB起步大模型推理或科学计算里CPU侧压缩、预处理环节其实很吃内存。有条件上1TB别省。系统盘两块SSD组RAID1装操作系统和软件环境容量960GB或1.92TB就够。数据盘如果需要本地暂存数据集可以加一块3.84TB或7.68TB的NVMe SSD。但我们集群的主要存储走的是集中式并行文件系统本地盘只做临时缓存。网卡每台服务器1张100G/200G IB网卡用于计算网络1张25G以太网卡用于存储网络1张千兆网卡用于管理网络。千兆管理口一般是主板自带另外两张是PCIe插槽扩展卡。2.2 网络硬件选型交换机、线缆与模块IB网络有两种常见组网架构Fat-Tree胖树和Dragonfly。对于100多台服务器这个规模Fat-Tree是最成熟、最好理解的选择。我们实际采用的拓扑是两层Leaf-SpineLeaf层接入层每台Leaf交换机下挂若干台GPU服务器。我们用了25台Leaf交换机每台Leaf带5~6台服务器Leaf端口速率200G。Spine层核心层7台Spine交换机Leaf和Spine之间全互联。Spine端口速率400G。为什么要这样做因为每个Leaf到Spine有多条上行链路可以形成ECMP等价多路径流量可以在多条路径间负载均衡。比如Leaf-1有7条上行分别连到7台Spine某两台服务器之间的通信就不需要抢占同一条链路而是由ECMP哈希算法分散到多条路径上。这种拓扑扩展性也好服务器不够了加LeafLeaf不够了加Spine带宽不够了升级端口速率改动都是局部性的。交换机选的是NVIDIA Quantum系列Mellanox被NVIDIA收购之后IB交换机品牌也统一归到NVIDIA了。你也许会问为什么不选其他品牌IB市场本来就是NVIDIA一家独大没有第二个选择好在它的产品确实成熟稳定。线缆方面短距离3米内用无源铜缆DAC便宜又可靠跨机柜或Leaf到Spine的距离稍长用有源光缆AOC。我的经验是能上铜缆就上铜缆光模块故障率始终高于铜缆而且铜缆没有清洁问题拔插即用。2.3 IP地址与子网规划提前想好否则后面全是坑IP地址规划别看是基础工作做不好后期全是麻烦。我的规划原则是“三层分离语义化命名预留扩展”。管理网络沿用已有的10.0.0.0/8网段新集群划一个独立子网比如10.60.0.0/16。子网内按机柜和服务器角色继续划分比如10.60.1.0/24是1号机柜的BMC网段10.60.2.0/24是1号机柜的PXE/操作系统网段。这样一个网段对应一个柜子出问题的时候通过IP就能快速定位物理位置。存储网络单独划一个10.70.0.0/16子网也按机柜细分。计算网络用的是IB走的是LID寻址而不是IP但在IB上也可以配IPoIBIP over InfiniBand方便测试连通性。我们从10.80.0.0/16里给每台服务器分配一个固定IP方便跑测试脚本的时候批量操作。规划IP的时候一定要把三年的扩展空间留出来。一次规划到位后面扩容时不用动老配置这个经验是踩了扩容的坑才明白的。3. 组网实施从零到一的全流程实录3.1 IB网络配置细节见真章IB网络的灵魂是子网管理器Subnet ManagerSM。没有它所有IB设备就是一堆散沙连link都起不来。目前主流的SM是opensm可以跑在某个服务器上也可以配置为交换机内置模式。我们用的是双SM冗余方案一台服务器跑主SM另一台作为备SM避免单点故障。配置步骤大概是这样在所有IB网卡上安装驱动。Mellanox网卡用官方NVIDIA MLNX_OFED驱动包安装命令很简单但要注意内核版本匹配。我们的操作系统是Rocky Linux 8直接下载对应版本的rpm包一条yum install就搞定了。确认IB链路起来。装完驱动后ibstat看端口状态正常应该是Active链路速率显示200Gb/s。如果状态是Init或Down一般是对端设备没起来、线缆松动或者速率协商失败。启动opensm子网管理器。先用一台机器手动拉起systemctl start opensm然后通过sminfo查看子网管理信息。所有交换机和网卡激活之后用ibnetdiscover画出整个IB拓扑确认124台服务器全部在线。配置LID静态分配可选。opensm默认动态分配LID重启后可能变化。对需要固定寻址的场景可以在opensm配置里做Static LID Mapping但日常运维其实不太需要这一步。IB网络配置最大的感受是——协议虽然老但设计得确实严谨。基本不需要你手工调什么把SM跑起来拓扑发现和路由转发都是自动完成的。前提是硬件和线缆别出问题。3.2 管理网络与PXE批量部署一百多台机器怎么装系统新增100多台服务器如果一台一台用U盘装系统人都得装疯。这里有一个规模化部署的标配手段PXE Kickstart无人值守安装。PXE的原理简单说就是服务器开机后从网卡启动通过DHCP拿到IP地址和TFTP服务器地址然后从TFTP服务器下载引导内核内核启动后再从HTTP/NFS服务器拉取完整的安装源和自动应答文件全程无需人工干预。我们的管理网络里专门拆了一台DHCP/TFTP/HTTP服务器来做PXE。流程大致是在PXE服务器上准备好操作系统镜像Rocky Linux 8的ISO解压到一个HTTP目录。写好Kickstart配置文件ks.cfg里面定义分区、软件包、时区、root密码、网络配置等。重点是把安装后执行的脚本%post写好自动装好GPU驱动、IB驱动、监控Agent这样系统起来就是能用的状态。在服务器BMC界面开启PXE启动并确保管理网口连着配置好的交换机。开电全部机器同时装机。120台机器同时PXE启动TFTP和HTTP服务器压力会瞬间飙高我们对PXE服务器做了并发优化调整nginx的worker进程数把Kickstart文件放到内存盘实测整个集群批量装机大约一个多小时全部完成。装机过程中最容易翻车的是网络驱动问题——网卡太新、内核里没有驱动PXE阶段就失败了。所以采购硬件的时候一定要确认和操作系统内核的兼容性或者提前做好驱动注入。3.3 GPUDirect RDMA与NCCL让数据绕开CPU直达GPU这是整个组网方案里技术含量最高的一环。GPUDirect RDMA允许GPU的数据不经过CPU和主机内存直接从网卡搬运到对端服务器的GPU显存大幅降低通信延迟和CPU占用。默认情况下数据要从GPU显存复制到CPU内存网卡再从CPU内存取走两次拷贝浪费时间还占用CPU。有了GPUDirect RDMA网卡通过PCIe BAR直通机制直接访问GPU显存地址整个过程没有CPU参与。要让GPUDirect RDMA生效需要满足几个条件网卡和GPU挂在同一个PCIe Switch或同一颗CPU的PCIe域下数据路径越短越高效。这也是HGX平台的优势——GPU和网卡都直连CPU的PCIe通道拓扑非常干净。安装NVIDIA驱动时开启NVreg_EnableGPUReset等参数确保PCIe设备reset不干扰GPU。使用NCCLNVIDIA Collective Communications Library跑多机通信。NCCL专门为英伟达GPU做了深度优化支持IB网络的GPUDirect RDMA路径。验证GPUDirect RDMA是否生效最直观的方法是看NCCL的测试输出。跑一个allreduce测试如果日志显示# Chunksize和带宽接近预期上限且latency在几微秒级别说明路径是通的。如果通信走了CPU迂回延迟会高出好几个数量级一眼就能看出来。3.4 存储网络挂载测试别让存储拖后腿计算网络搞定后存储网络也是个关键环节。我们的集中式存储是并行文件系统GPFS现在叫IBM Storage Scale底层是若干台存储节点通过100G以太网把存储网络和计算网络隔离开。挂载测试看起来简单但要留意一个点确定存储网络用的是独立网卡而非计算网卡。很多部署翻车在服务器上有多个网卡系统默认路由走了管理口或IB口导致挂载后读写速度惨不忍睹。我们通过静态路由表把存储网段的流量强制指向存储网卡避免了路由混乱的问题。实测从存储拉取一个GB级文件到本地速度跑到2GB/s左右这基本接近25G单网卡的极限了。如果后续需求变大可以通过多网卡bonding或升级100G网卡来提升。4. 性能测试与调优实录4.1 单机GPU压测先确认每台机器是好的组网完成后的第一件事不是跑分布式而是确认每一台机器本身健康。我们的测试流程分三层第一层基础信息检查。用nvidia-smi确认8张卡全部可见驱动和CUDA版本正常没有卡处于ERROR状态。再用nvidia-smi -q查每张卡的时钟、温度、显存容量排除异常硬件。第二层GPU压力测试。工具很多我们用的是gpu-burn一个专门压GPU计算和显存带宽的小工具。跑个5~10分钟观察功耗、温度和是否报错。如果有卡频繁报Xid错误抓紧联系厂商换卡不要心存侥幸。第三层NVLink连通性验证。HGX平台8卡之间通过NVLink全互联带宽极高。用nvidia-smi nvlink -s检查每张卡和其他7张卡的link状态正常情况下每对卡应该有12条NVLink链路A100是12条H100是18条全部显示Active才合格。这三种测试全部通过的机器才算具备入集群的资格。这个筛选过程很重要别等到分布式训练跑起来才发现某台机器有故障卡排查起来极其痛苦。4.2 网络通信压测把集群带宽天花板摸清楚单机没问题接下来就是验证网络。IB网络性能测试用的是Mellanox自带的ib_write_bw和ib_read_bw工具也有perftest包里的其他工具。我的习惯是分三步测两节点点对点测试随机挑两台机器跑到测试带宽。200G IB理论上限是21GB/s净带宽实际能跑到18~19GB/s就算正常。如果只有几GB/s先查网卡速率是不是协商成100G了再用ibping测延迟。多对节点并发测试同时让10对节点互跑带宽看整体是否均衡。这一步可以暴露ECMP哈希不均的问题——如果某条链路带宽高、其他链路空闲负载均衡策略需要优化。全集群MPI测试用Intel MPI Bench或OSU Micro Benchmarks跑AllReduce、AllGather等集合通信操作看延迟和带宽是否符合预期。NCCL也自带nccl-tests直接测GPU到GPU的集合通信性能这是最贴近真实训练场景的指标。我们4机32卡跑NCCL AllReduce测试单次消息大小16MB总线带宽能到100GB/s以上延迟在几十微秒量级这说明GPUDirect RDMA路径正常、网络没有明显瓶颈。4.3 大规模训练冒烟测试真实负载下的终极检验网络压测只是模拟最终还得让真实任务来检验。我们的冒烟测试方案是跑一个GPT类模型的预训练脚本32卡起步逐步扩展到128卡、512卡观察加速比是否线性。有一个残酷的规律分布式训练的加速比永远不会是线性的。32卡可能达到91%的线性加速比512卡可能就掉到75%甚至更低。这是因为通信开销随规模增长而增长不可避免。我们能做的是把通信开销降到最低——NCCL调优参数、选择最佳网络路径、减少Checkpoint写入频率等。我们的目标是512卡训练时加速比不低于85%。最终通过合理设置NCCL_BUFFSIZE、NCCL_LL128_PROTOCOL等参数各型号GPU和NCCL版本合适参数不同要实测后确认512卡全量训练跑起来了实际吞吐量接近理论预期的83%左右作为生产集群完全合格。5. 运维监控与常见问题排查实录5.1 带外管理与监控体系一百多台机器怎么管集群规模一大机器故障就成了常态不是运气问题而是概率问题。所以从第一天开始就要建立完整的监控和告警体系。带外管理走BMC/IPMI。每台服务器的BMC口接入管理网络分配固定IP。日常巡检我们写了个脚本每分钟Ping一遍所有BMC IP挂掉的自动告警。通过IPMI可以远程开关机、看硬件状态、挂载ISO重装系统即使操作系统彻底挂了也能远程操作这是大规模运维的救命稻草。业务层面的监控我们用的是Prometheus Grafana组合。每台服务器部署node_exporter和nvidia_gpu_exporter采集CPU、内存、磁盘、网络流量、GPU利用率、显存占用、温度、功耗等指标统一汇总到Prometheus再画到Grafana面板。再配一套Alertmanager阈值触发就推送到企业微信/钉钉比如GPU温度超过85℃、显存ECC错误率上升、IB端口降速率。这里要特别提醒GPU的ECC错误监控一定要做。显存出现可纠正的ECC错误是早期老化信号多起来之后离不可纠正错误和卡挂掉就不远了。提前发现提前处理能避免训练到一半因坏卡崩溃的惨剧。5.2 典型故障与排查方法速查运维半年多遇到过各种奇奇怪怪的问题。挑几个典型的写出来给大家当排查思路的参考问题现象可能原因排查手段解决方案IB链路状态Down线缆松动、光模块损坏、速率协商失败ibstat看端口状态iblinkinfo看交换机侧信息重新插拔换线缆确认两端速率一致GPU显示ERR!状态硬件故障或驱动崩溃nvidia-smi -q查Xid错误码查系统日志dmesg尝试复位GPU不行就换卡分布式训练通信很慢NCCL走了TCP或RoCE回退路径NCCL_DEBUGINFO跑小测试看日志中通信路径确认IB网卡加载正确驱动设置NCCL_IB_DISABLE0存储读写速度远低于预期路由走了错误网卡、bonding没生效ip route get确认数据路径修静态路由表调整bond配置某机柜整体网络异常交换机挂掉或上行链路中断先查交换机状态再看Leaf到Spine链路重启交换机检查光模块和线缆GPU温度突然飙升散热故障或机房空调失效nvidia-smi看风扇转速和温度曲线检查服务器风扇报修机房环境还有一个藏得很深的问题值得单独提驱动升级导致IB卡驱动和opensm版本不匹配造成整个网络性能大幅下降。这种问题不直接报错但性能指标怎么测都不对。排查了好几天最后发现是部分机器MLNX_OFED版本不一致。从那以后我们把驱动加入了配置管理所有机器锁死同一个版本升级必走灰度流程彻底杜绝了这类问题。5.3 运维避坑心得与经验总结最后分享几条压箱底的教训都是实实在在花钱买来的经验固件版本统一再大规模部署。所有服务器BIOS、BMC、网卡固件、GPU VBIOS在入网前必须刷到同一版本并且记录在案。混合版本跑一段时间就会出现一些“玄学”问题——有的机器性能异常有的机器兼容性报错查起来非常痛苦。线缆标签必须做细。100多台机器上千根线没有标签系统一根线出问题就要靠摸。我们给每条线配了唯一编号两端贴在物理位置同时在文档里记录对应的交换机端口和服务器网口定位故障速度快了十倍。关键操作前必须备份配置。交换机、BMC、PXE服务器的配置改动操作前要快照备份。有一次调PFC参数手滑把整个网络的流控配置搞乱了恢复现场如果没有备份那真是灾难。留好冗余资源。整个集群不要100%投入使用至少留1~2台服务器和几条备用链路作为冗余。硬件故障的时候能立刻把业务切换到备用节点而不是停机等备件。这个集群从规划到上线大约花了三个月投入的人力不算多但前期的设计和后期的运维规范确实省了无数功夫。组网本身不难难的是在每一个环节都做对选择、不埋雷。希望这篇文章能帮你少走一些弯路。
