一百多台物理GPU服务器每台上面8张卡——这个需求递到我手上的时候我做的第一件事不是画拓扑而是先开计算器。八百多张GPU按单机8卡A100/H100的典型配置来算这已经是一个规模不小的AI训练集群。这套东西一旦跑起来分布式训练的数据搬运量会非常惊人卡间要通信、节点间要通信、存储要通信网络的设计好坏直接决定训练任务能不能吃满算力。组网方案如果在立项阶段拍脑袋后面所有框架拉起大规模训练任务的时候都会为当初的草率买单。这篇文章把这次组网的完整思路和实操过程整理出来从方案选型、拓扑设计、IP规划到配置落地和排障尽量把每一步为什么这么做讲透给后面要搭类似规模GPU集群的人一份可参考的底稿。1. 组网前先算账800多张卡要面对什么样的流量1.1 单机内部的流量和跨机流量是完全两回事每台服务器8张GPU现代AI训练服务器普遍配备NVLink/NVSwitch。以A100为例单机内部8卡通过NVLink全互联卡间带宽能达到900GB/s左右的量级H100这代更是把这个数字推到更高。这意味着单机内部的GPU通信几乎不经过网卡也不需要网络来操心。但一旦模型规模超过单机显存比如千亿参数大模型就必须用张量并行、流水线并行、数据并行这些手段把模型切到多台服务器上。此时跨节点的通信量就不是小事了。数据并行每轮迭代结束要同步梯度梯度大小和模型参数量成正比张量并行的每个Transformer层前向和反向都要做all-reduce。这两种并行方式都会产生大量跨机流量。我习惯用一个粗略的公式估算单次跨机通信量大致等于模型参数量乘以并行通信系数。一个175B参数的模型做数据并行梯度同步一次就要搬约350GBFP16梯度约为参数量乘以2字节。这个数据量如果走千兆以太网光传一次梯度就要近一个小时走200Gbps的IB网络也要十几秒。所以网络带宽不是够用就行而是直接决定训练效率的核心瓶颈。1.2 集群里的流量其实是三类不能全塞一张网这个阶段最容易踩的坑就是把所有流量都往一张网络里塞。一百多台GPU服务器跑起来之后主要流量其实分三类训练通信流量节点间同步梯度、激活重计算等特点是带宽需求极高、延迟敏感、流量模式为周期性的突发。存储流量数据加载、checkpoint保存与恢复。checkpoint动辄几百GB集中写入时会对网络产生很大的吞吐冲击。管理运维流量SSH、监控agent、任务调度、镜像分发。特征是零散、小包、频率高。这三类流量如果混在一起训练流量的突发拥塞会拖慢存储存储checkpoint的集中写入也会冲击训练通信互相打架。我的设计原则很简单三张物理隔离的网络。高带宽低延迟的网络IB或RoCE跑训练通信独立的25G/万兆以太网跑存储再加一张千兆管理网做带外管理。后两张网的投入占比很低但带来的稳定性提升非常明显。1.3 先把网络规模估算出来再动工在画任何拓扑之前先把端口数算清楚服务器数量按108台留一定余量设计每台服务器的训练网卡4张200G HDR IB多轨设计理由后面详细说训练网总端口需求108 x 4 432个200G端口存储网每台服务器2张25G网卡共216个25G端口管理网每台服务器1个管理口100多个千兆端口就够这样一算整个项目的网络规模就清楚了训练网是绝对的重头需要一套能承载432个200G端口、且内部无明显收敛的交换网络。这个规模下小型千兆交换机、普通三层核心都不在考虑范围内必须上专业的IB交换机或者高性能RoCE交换机。2. 方案选型IB、RoCEv2还是普通以太网2.1 三条路各自的优劣在这种规模下实际上只有三条路可选方案单端口带宽典型延迟拥塞控制生态成熟度成本InfiniBand (HDR/NDR)200G/400G亚微秒级内建credit-based流控极高NCCL/OpenMPI原生支持高RoCEv2100G-400G微秒级依赖网络调优依赖PFCECN需精细调参高中高普通以太网TCP10G/25G/100G毫秒级TCP拥塞控制一般需开GDRDMA才能缓解CPU瓶颈中低从这张表能看出普通以太网TCP方案在AI训练场景基本可以直接排除。分布式训练是典型的延迟敏感加突发流量模式TCP的拥塞控制机制在这种场景下效率很低带宽利用率上不去不开RDMA的话数据还要经过内核协议栈额外拷贝CPU先成为瓶颈GPU反而空转——这就是很多人遇到的GPU/CPU/内存占用都不高但训练很卡的典型成因之一。剩下就是IB和RoCEv2的选择。RoCEv2把RDMA跑在以太网上硬件成本比IB便宜不少但代价是它本质上是在尽力而为的以太网上强行实现无损网络依赖PFC优先级流控和ECN显式拥塞通知配合任何一环配置不对都可能出现链路级联的PFC风暴整个集群性能雪崩。IB则是端到端的专有协议credit-based流控天然保证无损由Subnet Manager统一计算路由运维上不需要去抠PFC队列参数。2.2 为什么这个项目我选择IB考虑到这个项目的规模100多台服务器、400多个200G端口、交付周期以及团队运维人力我最终选了IB。核心理由有三个交付确定性RoCE在百卡级已经需要非常细致的调优到800卡规模PFC死锁、哈希不均等问题会被放大排查难度指数上升。IB有硬件层兜底主流深度学习框架对它的支持最充分出问题时的排障链路清晰得多。生态原生性NCCL对IB的支持最成熟几乎不用额外配置就能自动检测并启用RDMA。RoCE还得花精力去调GID、哈希、ECN甚至会因为某个固件版本差异导致性能不稳定。运维心智负担IB有完整的工具链ibstat、ibstatus、ibdiagnet、SM日志链路健康状态一目了然。RoCE的排障则要同时看网卡统计、交换机队列、DSCP标记、PFC计数对团队要求高一个级别。当然如果预算紧张且团队网络功底很强RoCEv2完全能做出很高的性能这个选择没有绝对对错。但能否稳定交付是我在这种规模项目上的第一考量所以我押IB。2.3 端口速率、光模块与线缆选型速率这块我选了200G HDR而不是400G NDR。原因很现实400G NDR交换机目前价格和供货周期都不友好而且HDR 200G已经能喂饱主流单卡的跨机通信需求。从性价比和维护成本看HDR是当前阶段最稳的选择。线缆方面同机柜和相邻机柜之间的短距离互联通常5米以内我用无源高速铜缆DAC成本低、功耗低、故障率低。跨机柜、跨列的长距离互联用有源光缆AOC或者可插拔光模块加光纤。这里有个经验光纤和光模块一定要做配对测试不同品牌模块混插在IB交换机上很容易出现链路协商异常或者误码率偏高。我们就遇到过某一批第三方光模块在交换机上能亮灯但链路反复重置的问题后来全部换成认证兼容列表里的型号问题才消失。省这点模块的钱后面排障的时间和人力成本根本划不来。3. 拓扑设计与地址规划骨架搭对后面不返工3.1 Spine-Leaf无阻塞拓扑这个规模下三层传统树形架构核心-汇聚-接入基本不用考虑。GPU集群需要的是无阻塞或低收敛比的任意节点间通信所以必须用leaf-spine叶脊两层扁平架构。有人会问为什么不用mesh全互联说实话在100台这个量级mesh意味着每台设备要跟所有其他设备直连端口数量和线缆复杂度会爆炸式增长只有极少数超算项目才会这么做机房落地的可维护性非常差。叶脊结构就是工程上最平衡的方案。我按照以下原则设计采用两层Spine-Leaf所有leaf交换机与所有spine交换机全互联训练网使用4轨4 rails设计每台服务器的4张HDR卡分别接向4台不同的leaf交换机这样任意两台服务器之间就有4条等价路径配合负载均衡可以把流量摊到多条链路上spine层数量根据无阻塞要求计算。以40端口HDR leaf交换机为例每台leaf用20个端口下接服务器、20个端口上行到spine那么全部服务器端口数108台 x 4轨 432个端口需要leaf数量432 / 20 21.6取24台leaf留出扩容余量24台leaf x 20个上行口 480个上行端口每台spine为40端口需要spine数量480 / 40 12台所以满配建设就是24台leaf加12台spine合计36台IB交换机这是一个标准的两层无收敛Clos网络。实际执行时如果一部分服务器还没到位可以先按实际端口数打折建设但交换机的机框、电源、光口余量一定要按满配预留不然后面扩容要动骨干代价极大。注意这里的无收敛指的是leaf到spine的带宽和服务器到leaf的带宽相等1:1。对纯数据并行训练1:1是最稳妥的如果场景以推理为主、节点间通信量小2:1甚至3:1收敛比能显著降低硬件成本但训练集群不建议这么省。3.2 存储网和管理网的拓扑存储网相对简单我用了两台25G核心交换机做双上联每机柜一台TOR交换机接服务器的25G存储口配合存储侧的多路径实现冗余。管理网更简单一台千兆接入交换机全部搞定服务器BMC和OS管理口都接这里。三张网完全物理隔离这是维护稳定性的关键。每一张网上面的设备命名、VLAN划分、端口描述都要在项目初期定好规范后面运维才不会被逼疯。3.3 IP地址规划分段清晰粒度到机柜IP规划是整个项目里最不起眼但返工最痛苦的部分。我的原则是分段清晰、可按机柜聚合、可自动扩容、命名能看懂。具体规划如下网络网段掩码用途说明管理网192.168.0.0/24255.255.255.0服务器BMC、交换机管理口存储网10.20.0.0/16255.255.0.0存储集群与计算节点存储口IB训练网 (IPoIB)10.1.0.0/16255.255.0.04轨业务IP带外运维网172.16.0.0/16255.255.0.0备份链路与管理通道IB训练网这个10.1.0.0/16要往下细分。我的做法是按leaf交换机编号划分子网每台leaf对应一个/24比如leaf-01对应10.1.1.0/24leaf-02对应10.1.2.0/24。服务器主机号按机柜号和槽位编码比如一台位于机柜3、第4个U位、第2槽位的机器它的某个轨IP可以规划为10.1.3.x。这样运维看到IP就能大致知道这台机器在哪个柜、哪个位置、接在哪台leaf上排查物理链路故障时能少跑很多路。很多团队在这块吃过亏IP随机分配DHCP地址池一放开设备一多管理网、存储网、训练网IP互相冲突日志里全是ARP混乱想定位机器都困难。规模超过一百台后IP规划一定要当作架构设计的一部分来对待。3.4 IB逻辑子网Subnet Manager和Partition KeyIB网络还有一个以太网没有的概念Subnet ManagerSM。IB网络里必须有一个SM来管理链路状态、分配LID、计算路由。生产环境我建议在管理节点上部署两个SM做主备而且主备切换要提前演练。一旦SM挂了整个IB网络的路由重新收敛所有训练任务都会中断这个事故在百卡集群里是不可接受的。另外可以按业务或团队划分Partition KeyPKey相当于以太网的VLAN。默认所有端口都在同一个默认分区里0x7fff如果多个团队共用一个集群且不希望互相访问对方的存储和训练资源用PKey做隔离。但要注意PKey只是安全边界对性能没有帮助别指望用它来优化流量。4. 落地实操交换机、驱动、网卡与业务配置4.1 交换机侧上线、固件与SM配置IB交换机开箱后第一步是升级固件到统一版本。这一步千万别跳过不同固件版本对HDR链路的信号完整性、误码率表现差别很大混版本时部分交换机会出现隐性问题平时看不出来一到大流量就翻车。固件升级完成后给交换机设置主机名、管理IP、NTP然后配置SM。如果是用交换机自带的SM需要指定一台为主SM、一台为备SM并设置优先级。我习惯的设置是主SM优先级为8备SM优先级为4其余设备默认。这里多说一句SM的配置看似简单但主备切换的时机、扫描间隔这些参数都会影响链路故障时的收敛速度。生产环境建议专门做一次主备切换演练把SM故障后的恢复时间测出来心里有底。4.2 服务器侧MLNX_OFED驱动安装服务器端的关键是把网卡驱动装对。如果是NVIDIA/Mellanox的ConnectX-6 HDR网卡驱动要用MLNX_OFED发行版不要用系统自带的in-tree驱动——自带驱动功能不全性能和稳定性都差一截。安装步骤大致是# 下载与系统匹配的 MLNX_OFED 版本 tar zxvf MLNX_OFED-*.tgz cd MLNX_OFED-* ./mlnxofedinstall --add-kernel-support安装完成后重启然后验证ibstat ibstatus正常的HDR端口应该显示40Gbps x 4条通道即200Gbps的Active状态。如果显示Initializing或者端口速率降级成100G就要开始排查光模块和线缆了。4.3 配置多轨网络与IPoIB每台服务器4张HDR卡分别接向4台leaf交换机这4个口需要在系统里分别配置IPoIB地址。IPoIB就是让IB链路承载IP报文相当于给IB配了一个虚拟以太网。NCCL和应用主要走RDMA Verbs但管理、监控和某些需要socket通信的场景要靠IPoIB。配置示例RHEL系# /etc/sysconfig/network-scripts/ifcfg-ib0 DEVICEib0 TYPEInfiniBand ONBOOTyes BOOTPROTOstatic IPADDR10.1.1.10 NETMASK255.255.255.0配好4个口之后用ibv_devinfo确认能看到4张卡和正确的端口状态再用ibping做跨节点连通性测试。这里容易忽略的是4张卡的PCIe插槽位置也会影响性能尽量把网卡插在CPU直连的PCIe插槽上不要走PCH芯片组转接否则跨CPU访问的延迟和带宽损失会在训练任务里体现出来。4.4 NCCL配置与可用性验证训练框架最终通过NCCL调用网络能力所以网络配好之后至少要跑一遍NCCL带宽测试# 编译NCCL tests make -C nccl-tests mpirun --hostfile hosts -np 64 -ppn 8 ./build/all_reduce_perf -b 128M -e 8G -f 2 -g 1重点看Bus Bandwidth是否随卡数线性扩展。如果两台8卡服务器之间做16卡all-reduce理想值应该接近多张IB卡的聚合带宽如果带宽上不去优先检查多轨配置、链路降速、哈希不均这三个方向。5. 性能实测这套网络实际表现如何5.1 单链路与多轨实测我挑几组有代表性的数据来说单条HDR链路ib_write_bw约197 Gbps200G端口扣除协议开销后这个值正常跨leaf的单条流量因为要经过spine绕行一跳实测在190 Gbps左右4轨聚合4条链路同时打满聚合带宽约780 Gbps接近线性扩展。这说明spine-leaf拓扑和负载均衡基本没有产生明显瓶颈。需要留意的是哈希是基于流特征的对大流量长流来说如果应用侧全是同源同目的的长连接哈希粒度不够细就会出现某条链路打满、其余空闲的问题。NCCL在这个场景表现尚可因为它本身会建立多条QP连接变相打散了流量。5.2 训练任务端的验证接着跑真实的分布式训练做验证我用了8节点64卡混合并行模式数据并行加张量并行通信模式接近千亿参数训练的形态。单次all-reduce时间、端到端吞吐和理论峰值对比整个集群表现得相当稳定网络不再是瓶颈。这里特别想强调一点网络性能测试一定要做端到端的不要只测网络层。很多项目单测IB带宽一切正常一上分布式训练就卡顿原因往往是NCCL版本、驱动版本、固件版本三者不匹配或者多轨配置没生效。所以集群验收阶段我坚持把NCCL的all_reduce_perf作为标准测试项跑完再上训练省得后面瞎猜。5.3 性能调优的几个开关如果实测性能离预期有差距优先检查这几个点NCCL环境变量确认NCCL_IB_DISABLE0并用NCCL_IB_HCAmlx5_0:1,mlx5_1:1,mlx5_2:1,mlx5_3:1显式指定要使用的HCA和端口防止NCCL拿到错误的设备固件与驱动版本对照兼容矩阵确保MLNX_OFED和交换机固件版本配对不要各升级各的IB的服务等级SL和虚拟通道VL划分多租户场景下可以用不同SL隔离流量避免互相干扰。6. 踩坑记录从链路降速到集体卡顿的排查过程6.1 全网链路速率悄悄降到100G罪魁祸首是光模块集群上线跑了一个月后监控突然报了一堆链路降速告警从200G降到100G。刚开始以为是交换机端口故障排查半天发现是某一批第三方光模块在高负载下信号劣化导致链路自动协商降速。最坑的是IB链路降速后不会自动恢复必须手工把端口重置或者直接更换模块。这个问题的教训有两条第一大规模IB组网光模块和线缆尽量用原厂认证的型号至少也要用经过大量验证的品牌库存里备足冗余模块第二监控里一定要有链路速率变化的告警不然降速可能跑好几周才发现等发现时训练效率已经被拖低很久了。6.2 分布式训练资源占用不高但很卡的排查链路这正好对应了很多人遇到的现象GPU利用率和CPU内存都不高但训练就是慢得像卡住。最初我怀疑是代码问题后来把nvidia-smi、ibstat和交换机侧监控同时打开观察才发现网络侧有明显的周期性拥塞每轮迭代的all-reduce阶段都会出现短时大流量由于哈希不均其中两条链路被打满其余链路闲着。排查链路供参考ibstat看端口速率和状态先排除物理层问题到交换机侧看端口收发计数、丢包和重传计数定位是哪条链路拥塞打开NCCL_DEBUGINFO打印每个通信阶段的耗时把瓶颈锁定在通信环节检查哈希策略必要时调整流量的端口范围或哈希因子。最终根因是应用侧同时发起的QP数量过多建连阶段就把某些链路的哈希表打得过载导致流量分布严重不均。调整NCCL的队列深度参数后恢复正常。这种假卡顿在百卡以上集群非常容易出现建议把网络指标全部接入监控大盘别只盯GPU利用率。6.3 扩容和维护时的坑维护时如果不小心误操作把某台leaf交换机的端口关掉所有连到该端口的服务器训练链路会瞬间掉线然后NCCL进入重连回退模式整个训练任务性能骤降甚至超时失败。这个集群一旦跑起来基本没有低峰期每次维护都要提前跟业务方确认操作前先确认端口影响范围能通过管理口带外操作的尽量带外操作。另外提一个容易被忽视的细节IB网络的固件升级窗口一定要避开训练任务。曾经有一次我们升级leaf交换机固件虽然做了多路径冗余但升级过程中SM重算路由导致实时训练任务出现分钟级中断。后来所有网络变更都走变更流程先评估影响、再预约窗口、最后回滚预案才把这类事故压到零。7. 写在最后的经验这次组网从选型到验收我最大的体会是在百卡以上的GPU集群里网络不是辅助设备而是和算力同等重要的基础设施。选型和架构阶段多花的心思会在后面无数个训练任务里加倍回报。如果只能给一条建议那就是提前把地址规划、监控、文档和变更流程做好而不是等集群跑起来再补。我还有一个实际的小技巧给每台服务器和每个网络端口都建立一份档案记录端口连接的交换机、模块型号、固件版本和首次连通时间。这个不起眼的习惯在排障时能省下大量时间上百台机器的情况下靠人脑记忆是绝对不够用的。组网组多了就会发现真正决定一个集群好坏的往往不是那几次漂亮的性能测试数字而是这些细节的严谨程度。