2026/9/16 20:21:42
FEATURED · 精选文章 
1. 先算清账800多张卡的集群组网到底在组什么接手这个项目的时候情况很明确100多台物理GPU服务器每台8张GPU卡加起来就是800多张卡的规模。这种体量放在大模型训练和科学计算里并不是超大集群但也早就过了“堆几台机器”的阶段。你首先要搞清楚的不是买什么交换机而是这些卡之间要发生什么样的数据流动流动的量有多大延迟能容忍到多少。这些问题不弄清楚后面组出来的网要么浪费钱要么跑起来天天被骂。这类集群最典型的业务是分布式训练和模型微调。以常见的数据并行训练为例每轮迭代里每个GPU算完自己的小批量梯度需要全局做一次AllReduce把梯度归约到所有卡上再同步更新参数。这一步会产生大量通信流量而且是典型的“东西向流量”——即服务器与服务器之间横向流动。100台设备组成的分布式训练任务一旦网络带宽不够或者转发路径上有瓶颈原本10分钟一个epoch的任务可能拖到40分钟GPU算力全在等数据。所以这张网的核心目标并不是把机器“连起来”而是让任何两张GPU卡之间通信时带宽足够、时延可控、丢包趋近于零。另外还要兼顾管理网和存储网的隔离否则一台机器在安装软件时广播风暴可能把整个训练集群搞崩。简而言之你的组网工作要同时支撑三张逻辑网络管理网、存储网、计算网。这三张网怎么设计、怎么隔离、怎么调优是后面所有技术细节的主线。2. 网络架构选型拓扑、协议和地址规划2.1 拓扑选择两层Spine-Leaf比三层树更适合100多台GPU服务器在物理上通常会分散在几个机柜里。如果每台服务器只连一张计算网卡那计算网口的数量就是100多个如果做双网卡冗余就是200多个接入端口。这种规模下最稳妥、最容易排障的拓扑一定是Spine-Leaf两层架构也就是把一组交换机作为Spine骨干层另一组交换机作为Leaf接入层每个Leaf同时连接到所有SpineLeaf下面挂服务器。为什么不用传统的三层汇聚架构因为在三层架构里一旦汇聚层出现故障它下面挂的所有服务器都会失联而且汇聚层上往往会有多台Leaf的上行流量争抢同一段链路容易形成瓶颈。Spine-Leaf的优势在于“全互联”每台Leaf到所有Spine都有等价路径协议层面可以跑ECMP等价多路径运维层面故障域也被缩小了——坏一台Leaf只影响挂在它下面的那十来台机器坏一台Spine只损失一条冗余路径业务不会中断。按照这个规模我当时的方案是计算网Leaf交换机选24台每台Leaf向下提供8到12个25G/100G端口向上通过2条100G或400G链路连接到Spine。Spine选4台所有Leaf全部接入这4台Spine。这样既保证了任何两节点之间的转发跳数不超过3跳又给未来扩展到200台机器留出了余量。当然如果预算有限可以缩减到2台Spine但冗余性会差一些后续维护窗口不太好安排。2.2 计算网协议RoCEv2还是InfiniBand这是绕不开的十字路口。InfiniBand在性能、生态成熟度和RDMA原生支持上确实很强但价格贵、运维门槛高而且需要专门的子网管理器一般团队上手要适应一段时间。RoCEv2则是跑在普通以太网上的RDMA方案造价便宜能复用现有的以太网运维经验。我这次选的是RoCEv2原因很实在整个机房的基础设施都是标准以太网已有的运维监控、拨测工具、交换机型号都能直接沿用不至于为了一个计算网单独拉一套IB设备。但是RoCE有一个致命前提它对丢包极度敏感。RDMA的流量一旦遇到网络拥塞丢包性能会掉得让人怀疑人生。因此想跑好RoCE底层以太网必须改造成“无损网络”也就是要开启PFC优先级流控和ECN显式拥塞通知让流量按优先级调度从源头避免丢包。必须提醒一句RoCE不是贴个标签就能跑的你需要把交换机、网卡、操作系统的QoS配置完整对齐任何一头没配好测试时都会现原形。如果你们团队完全没碰过RoCE而项目又对时延有硬指标那InfiniBand也值得考虑——不要因为贵就回避关键看总拥有成本。2.3 三张网必须分开管理网、存储网、计算网很多人图省事就用一张网跑所有东西结果训练流量稍微大一点SSH连上去都卡。这个规模下强烈建议分三张独立的物理或逻辑网络。管理网负责带外管理、SSH登录、监控采集和系统安装带宽要求不高万兆足够。管理网的设备可以通过普通千兆、万兆交换机堆叠也可以用带外管理口单独组网。计算网承载GPU之间梯度同步、集合通信等高带宽流量。存储网连接分布式文件系统承载数据集读写、模型checkpoint保存和加载带宽和IOPS都必须保证。尤其训练过程中每隔一段时间要保存checkpoint如果存储网带宽不够会让整个训练卡在等待磁盘写入上。IP规划上建议采用RFC1918私有地址段并预留足够余量。举例来说网络网段示例用途规模管理网10.10.0.0/16带外管理、SSH、监控最多65534个地址足够存储网10.20.0.0/16NFS/Lustre等文件系统按存储节点数量规划计算RoCE网10.30.0.0/16GPU通信每个GPU分配一个IP或按主机聚合同时给每台服务器定好命名规范比如rack编号单位置。例如rack03-gpu007表示3号机柜第7台GPU服务器。组网初期不规范命名的成本会在半年后某个节点报障时十倍还给你。3. 硬件选型与上架细节不光是买对设备3.1 GPU服务器的对外接口配置一台GPU服务器通常有两路CPU、八个PCIe插槽GPU卡可能通过PCIe Switch互联也可能板载NVLink。组网前最容易被忽略的是这些GPU跟网卡之间的PCIe通道到底怎么走、NUMA亲和性如何。我在配置阶段的做法是先用nvidia-smi topo -m查看GPU之间的拓扑结构再结合主板CPU拓扑确定RoCE网卡插在哪个PCIe插槽上最合理。原则是尽量让网卡所在PCIe Switch域和GPU所在域重合或靠近避免跨CPU访问带来的额外延迟。很多分布式训练跑起来性能不对就是网卡插错了PCIe槽位。服务器端计算网口建议用两张100G网卡一张接到Leaf A一张接到Leaf B做成双口绑定。绑定模式不要用主备尽量用负载均衡模式这样可以同时利用两条物理链路。不过在RoCE场景下主备模式反而更安全——因为RoCEv2依赖ECMP做路径分担网卡绑定层面的LACP如果配置不当反而会破坏RDMA流量流向。3.2 交换机端口、光模块和线缆的坑计算网Leaf交换机向下提供25G或100G端口向上到Spine用100G或400G端口。选光模块的时候多模和单模别混。短距离100米内用多模光模块配合SR4线缆超过100米就要上单模光模块配合LR4/LR8线缆。多模比单模便宜但距离和带宽上限低。绝大多数数据中心内部设备间距其实都在100米内多模方案性价比最高。线缆方面有个容易翻车的点光模块的兼容性。尽量选交换机厂商认证过的模块或者同一品牌的整机光模块方案。杂牌光模块虽然便宜但可能出现接口up/down频繁抖动、误码率偏高排查起来极其痛苦。另外每根光纤跳线两端的标签必须和交换机端口、服务器网卡一一对应别指望靠记忆。几百根线不标标签出了问题就是一场灾难。3.3 机柜供电和散热最容易爆的雷100多台8卡GPU服务器的功耗不是小数。单台服务器如果满载跑训练功耗可能到3kW到6kW之间8卡GPU服务器经常更高。一个机柜放10台设备光服务器功耗可能就有50kW普通机柜标准供电根本扛不住。组网之前先算清楚单个机柜内设备的总功耗是否超过机柜的PDU额定功率整排机柜的负荷是否在机房空调制冷和UPS容量内。我见过一个项目网络全通了结果跑高负载训练时过热宕机一查是空调容量不够。这个锅不该由组网工程师背但作为整体交付的一部分你最好提前给出功耗估算表联合机房运维一起确认。4. 组网实操从交换机配置到GPU服务器接入4.1 交换机基础配置VLAN、MLAG和路由以计算网为例我会在Leaf交换机上先单独建一个VLAN用于计算流量。同时和Spine之间跑OSPF或BGP把计算网做三层路由打通。这里有个细节服务器网关通常落在Leaf交换机上所以Leaf交换机既承担二层接入又承担三层网关功能要合理规划SVI地址。为了让服务器高可用两台Leaf之间要做MLAG跨设备链路聚合这样服务器通过双线上联到两台Leaf任何一台Leaf宕机都不会断网。MLAG配置的要点是两台Leaf之间要有专门的peer-link互联链路并通过keepalive链路检测对端状态。配置完成后用show mlag summary确认两台设备的状态一致再开始下挂服务器。下面给一套简化版的关键模板以常见CLI为例具体命令以厂商文档为准# Leaf交换机上 vlan 100 name GPU-Compute # 创建VLAN接口作为网关 interface vlan100 ip address 10.30.0.1/24 # 端口接入服务器并划分进VLAN interface Ethernet1/1 switchport mode trunk switchport trunk allowed vlan 100 # 与另一台Leaf建立MLAG peer-link interface port-channel 1000 switchport mode trunk switchport trunk allowed vlan all为了减小路由故障影响推荐Leaf与Spine之间跑eBGP或OSPF。BGP的收敛速度慢一点但网络规模大时可控性更好OSPF更适合规模较小的集群配置也直观。我这里用的是OSPF因为它不复杂100台规模完全够用。4.2 无损网络配置PFC和ECN是RoCE的命根子RoCE跑在以太网上要保证不丢包就必须对流量做无损处理。PFC的作用是当某个队列拥塞时交换机暂停发送端避免缓存溢出丢包ECN的作用是让交换机在队列变长时给源端打标记源端感知到拥塞后主动降低发送速率。实际配置时要让RDMA流量走一个指定的优先队列。比如用COS3的队列专门跑RoCE然后针对这个队列开启PFC让网络拥塞时优先保障RoCE流量不被丢弃。同时在出口策略里配置ECN阈值让RDMA流量在队列超过阈值时打ECN标记网卡收到Echo后自动降速。例如# 将DSCP 26/27对应到COS 3 qos map dscp-to-cos 26 27 3 # 对COS 3队列开启PFC priority-flow-control mode on priority-flow-control cos 3 force # 启用ECN在出口策略中配置WRED ECN policy-map type qos CNP class COS3 wred random-detect ecn wred ecn threshold 200000配完PFC和ECN并不是万事大吉。要持续监控PFC反压帧的计数正常运行时这个数字应该很低如果PFC触发非常频繁说明网络存在拥塞热点需要优化拓扑或调整阈值。4.3 GPU服务器端的OS和网卡配置服务器上需要安装对应的网卡驱动Mellanox网卡需要安装MLNX_OFED并启用RoCE相关功能。操作系统层面建议关闭网卡的节能模式和LRO/GRO大包卸载因为有些设置会和RoCE冲突。给网卡配置IP后用ibv_devinfo或者rdma link show确认RDMA设备已经起来。如果网卡支持RoCEv2你还需要确认MTU设为9000巨型帧否则TCP/RDMA吞吐可能会受限。MTU设在1500也能通但跑大流量时性能明显差一截。下面是一个简化的网卡配置示例cat /etc/sysconfig/network-scripts/ifcfg-enp65s0f0 EOF DEVICEenp65s0f0 BOOTPROTOnone IPADDR10.30.0.101 PREFIX24 MTU9000 EOF # 加载内核模块并启用RoCE modprobe mlx5_ib配置完后在机器上执行ip a和ibstatus确认设备状态。这一步别偷懒每台机器都过一遍要比事后在训练日志里发现NCCL连接失败高效得多。4.4 存储集群接入别让IO拖了训练后腿存储网的设计比较简单GPU计算节点通过存储网访问并行文件系统NAS网关或存储服务器提供NFS/Lustre/GPFS等协议。存储网和计算网必须隔离否则大文件的读写会和梯度同步抢带宽。在GPU服务器上挂载共享存储时有几个参数值得注意。NFS挂载时建议带上nolock,hard,intr,rsize1048576,wsize1048576提高大块传输效率Lustre或GPFS则建议使用原生客户端性能远好于NFS over TCP。为了容错可以把存储网的bonding也做成主备模式因为存储网出错时数据停滞会造成模型训练直接卡死。5. 性能验证与调优一切配置最终要看效果5.1 物理链路和RDMA连通性测试所有设备上架并配置完成后先做单链路验证。用iperf3测TCP带宽确认链路速率符合预期再使用ib_write_bw或qperf测试RDMA带宽和时延。单条25G/100G链路如果iperf3只能跑到线速的60%左右先看窗口大小和CPU绑定。加-P 8并发流再测通常能拉满。如果并联多流后带宽还是不达标可能网络配置或光模块有问题。RDMA测试同样重要ib_write_bw -d mlx5_0 -a -F # 服务端 ib_write_bw -d mlx5_0 -a -F 10.30.0.102 # 客户端对端IP关注两个指标带宽是否接近线速时延是否在1-2微秒量级同机柜内或5微秒以内跨Spine。时延异常偏高的大概率是网络拥塞或交换机缓存配置不对。5.2 NCCL多机集合通信测试验证完单条RDMA链路还要验证GPU服务器上的NCCL多机通信。NCCL是深度学习和HPC里最常用的GPU集合通信库all_reduce性能直接决定分布式训练的上限。我一般会在每台服务器上编译NCCL Tests然后跨节点跑./build/all_reduce_perf -b 128M -e 8G -f 2 -g 8-g 8代表每台机器8个GPU-b到-e是数据量范围。跑完后看输出的“Out of bounds”和“Avg bus bandwidth”结果在多机环境下如果带宽不到理论值的70%就要重点排查网卡中断均衡、PCIe拓扑和RoCE PFC/ECN参数。多机测试时建议先在2台机器之间跑确认RoCE正常再扩展到10台、50台。因为大规模NCCL如果失败报错信息很抽象不好定位。从小到大逐级扩展能大大缩短排查时间。5.3 用真实训练任务模拟压测最后一步是用实际训练任务做一次烟囱测试。选一个中等规模的模型用DDP或DeepSpeed启动多机训练观察整体吞吐、GPU利用率、训练日志是否中断。这一步主要验证的不只是底层网络还有调度系统、存储系统、容器网络等环节的配合。我在压测时会同时监控nvidia-smi看GPU利用率、mpstat看CPU软中断、sar -n DEV看网卡流量、ibstat看RDMA设备状态。如果GPU利用率长期低于80%优先怀疑数据加载和预处理瓶颈再看网络。这个排查思路可以帮你快速区分是“算不动”还是“等不到”的问题。6. 常见问题与排查技巧实录6.1 网络能Ping通但RDMA Raw Data不通现象服务器之间ping通TCP也能传数据但运行NCCL或ib_write_bw时连接失败。原因通常有几种网卡驱动没启用RoCE功能、交换机或防火墙过滤了RoCE的UDP端口RoCEv2使用UDP端口4791、两端MTU不一致。排查时先用rdma link show确认为RTR状态再用ibv_devinfo看transport层如果port state不是Active检查网卡固件和驱动版本再确认交换机没有针对UDP 4791的默认丢弃策略。6.2 GPU利用率不高但CPU和内存也很空闲很多人遇到的“GPU卡、CPU不高但训练慢”就是网络等待问题。先用perfstat或NCCL_DEBUGINFO跑一轮短任务看集合通信是否长时间阻塞在AllReduce。如果是拿nccl-tests复测并对照理论带宽低于70%就回到底层查PFC、ECN和MTU。有一种容易忽略的情况跨CPU socket访问网卡会导致额外延迟。你最好把网卡中断绑定到和GPU所在NUMA node相关的CPU核上同时确认网卡插槽离GPU的PCIe控制器足够近。6.3 训练任务偶发中断或者NCCL超时偶发问题最难查但有两类原因很常见。一是计算网某些链路拥塞导致ECN/PFC频繁触发最终让RDMA进入退化状态二是交换机端口出现CRC错误或链路抖动的光模块这类故障通常不会直接断网但会造成零星的丢包。建议在交换机上开启端口错误计数监控在服务器端跑ethtool -S查看网卡错误计数。如果看到rx_crc_errors或者symbol_errors在持续增长直接换光模块或光纤大概率能解决。6.4 日常运维从硬件到网络的统一视图800多张卡的集群没有一个可视化的资产管理系统会非常痛苦。至少要做三件事记录每台服务器的资产编号、IP地址、机柜位置、所接交换机端口监控所有网络设备的端口流量、错误计数、光模块温度对计算网部署告警针对PFC计数、ECN标记、端口up/down设置阈值。网络告警最好和GPU监控联动。一旦GPU利用率掉点运维马上能拿到对应的网络设备日志这会极大缩短故障恢复时间。我在实际运维中一直坚持“业务指标异常时网络日志是首要证据”的思路。7. 最后分享几个实战体会这次组网我最深的感受是网络配置本身只占三成工作量剩下七成是规划、验证和排障。你在上架前多花半天把光模块、线缆标签、VLAN规划做好后面能省下一星期痛苦排障的时间。尤其是在这种100台级别的集群上任何事情只要乘以100都会变成大问题——一个网卡驱动版本不对你可能要处理100多台机器一个交换机端口被不小心划进了管理VLAN就可能导致整个计算网出现广播风暴。还有个小技巧任何变更操作前先备份配置文件哪怕只是新增一个VLAN。很多集群故障不是因为配置不先进而是因为有人改了配置没备份回滚时找不到原始版本。所有交换机、服务器的配置做到版本化保存这是底线。对于还在规划阶段的朋友别一上来就追求最贵的方案。先想清楚你的业务真的需要多少带宽、多少时延再决定是RoCE还是InfiniBand、是25G还是100G。网络升级不是一次性买卖留好扩容余量比一次买满更重要。最后把这套网络尽可能做标准化统一的VLAN分配模板、统一的端口配置模板、统一的主机命名规则后续每一个新增节点都能“照着填表”完成接入这样才真正算交付了一套能长久运转的GPU集群网络。
大规模GPU集群组网实战：从Spine-Leaf架构到RoCE无损网络调优
1. 先算清账800多张卡的集群组网到底在组什么接手这个项目的时候情况很明确100多台物理GPU服务器每台8张GPU卡加起来就是800多张卡的规模。这种体量放在大模型训练和科学计算里并不是超大集群但也早就过了“堆几台机器”的阶段。你首先要搞清楚的不是买什么交换机而是这些卡之间要发生什么样的数据流动流动的量有多大延迟能容忍到多少。这些问题不弄清楚后面组出来的网要么浪费钱要么跑起来天天被骂。这类集群最典型的业务是分布式训练和模型微调。以常见的数据并行训练为例每轮迭代里每个GPU算完自己的小批量梯度需要全局做一次AllReduce把梯度归约到所有卡上再同步更新参数。这一步会产生大量通信流量而且是典型的“东西向流量”——即服务器与服务器之间横向流动。100台设备组成的分布式训练任务一旦网络带宽不够或者转发路径上有瓶颈原本10分钟一个epoch的任务可能拖到40分钟GPU算力全在等数据。所以这张网的核心目标并不是把机器“连起来”而是让任何两张GPU卡之间通信时带宽足够、时延可控、丢包趋近于零。另外还要兼顾管理网和存储网的隔离否则一台机器在安装软件时广播风暴可能把整个训练集群搞崩。简而言之你的组网工作要同时支撑三张逻辑网络管理网、存储网、计算网。这三张网怎么设计、怎么隔离、怎么调优是后面所有技术细节的主线。2. 网络架构选型拓扑、协议和地址规划2.1 拓扑选择两层Spine-Leaf比三层树更适合100多台GPU服务器在物理上通常会分散在几个机柜里。如果每台服务器只连一张计算网卡那计算网口的数量就是100多个如果做双网卡冗余就是200多个接入端口。这种规模下最稳妥、最容易排障的拓扑一定是Spine-Leaf两层架构也就是把一组交换机作为Spine骨干层另一组交换机作为Leaf接入层每个Leaf同时连接到所有SpineLeaf下面挂服务器。为什么不用传统的三层汇聚架构因为在三层架构里一旦汇聚层出现故障它下面挂的所有服务器都会失联而且汇聚层上往往会有多台Leaf的上行流量争抢同一段链路容易形成瓶颈。Spine-Leaf的优势在于“全互联”每台Leaf到所有Spine都有等价路径协议层面可以跑ECMP等价多路径运维层面故障域也被缩小了——坏一台Leaf只影响挂在它下面的那十来台机器坏一台Spine只损失一条冗余路径业务不会中断。按照这个规模我当时的方案是计算网Leaf交换机选24台每台Leaf向下提供8到12个25G/100G端口向上通过2条100G或400G链路连接到Spine。Spine选4台所有Leaf全部接入这4台Spine。这样既保证了任何两节点之间的转发跳数不超过3跳又给未来扩展到200台机器留出了余量。当然如果预算有限可以缩减到2台Spine但冗余性会差一些后续维护窗口不太好安排。2.2 计算网协议RoCEv2还是InfiniBand这是绕不开的十字路口。InfiniBand在性能、生态成熟度和RDMA原生支持上确实很强但价格贵、运维门槛高而且需要专门的子网管理器一般团队上手要适应一段时间。RoCEv2则是跑在普通以太网上的RDMA方案造价便宜能复用现有的以太网运维经验。我这次选的是RoCEv2原因很实在整个机房的基础设施都是标准以太网已有的运维监控、拨测工具、交换机型号都能直接沿用不至于为了一个计算网单独拉一套IB设备。但是RoCE有一个致命前提它对丢包极度敏感。RDMA的流量一旦遇到网络拥塞丢包性能会掉得让人怀疑人生。因此想跑好RoCE底层以太网必须改造成“无损网络”也就是要开启PFC优先级流控和ECN显式拥塞通知让流量按优先级调度从源头避免丢包。必须提醒一句RoCE不是贴个标签就能跑的你需要把交换机、网卡、操作系统的QoS配置完整对齐任何一头没配好测试时都会现原形。如果你们团队完全没碰过RoCE而项目又对时延有硬指标那InfiniBand也值得考虑——不要因为贵就回避关键看总拥有成本。2.3 三张网必须分开管理网、存储网、计算网很多人图省事就用一张网跑所有东西结果训练流量稍微大一点SSH连上去都卡。这个规模下强烈建议分三张独立的物理或逻辑网络。管理网负责带外管理、SSH登录、监控采集和系统安装带宽要求不高万兆足够。管理网的设备可以通过普通千兆、万兆交换机堆叠也可以用带外管理口单独组网。计算网承载GPU之间梯度同步、集合通信等高带宽流量。存储网连接分布式文件系统承载数据集读写、模型checkpoint保存和加载带宽和IOPS都必须保证。尤其训练过程中每隔一段时间要保存checkpoint如果存储网带宽不够会让整个训练卡在等待磁盘写入上。IP规划上建议采用RFC1918私有地址段并预留足够余量。举例来说网络网段示例用途规模管理网10.10.0.0/16带外管理、SSH、监控最多65534个地址足够存储网10.20.0.0/16NFS/Lustre等文件系统按存储节点数量规划计算RoCE网10.30.0.0/16GPU通信每个GPU分配一个IP或按主机聚合同时给每台服务器定好命名规范比如rack编号单位置。例如rack03-gpu007表示3号机柜第7台GPU服务器。组网初期不规范命名的成本会在半年后某个节点报障时十倍还给你。3. 硬件选型与上架细节不光是买对设备3.1 GPU服务器的对外接口配置一台GPU服务器通常有两路CPU、八个PCIe插槽GPU卡可能通过PCIe Switch互联也可能板载NVLink。组网前最容易被忽略的是这些GPU跟网卡之间的PCIe通道到底怎么走、NUMA亲和性如何。我在配置阶段的做法是先用nvidia-smi topo -m查看GPU之间的拓扑结构再结合主板CPU拓扑确定RoCE网卡插在哪个PCIe插槽上最合理。原则是尽量让网卡所在PCIe Switch域和GPU所在域重合或靠近避免跨CPU访问带来的额外延迟。很多分布式训练跑起来性能不对就是网卡插错了PCIe槽位。服务器端计算网口建议用两张100G网卡一张接到Leaf A一张接到Leaf B做成双口绑定。绑定模式不要用主备尽量用负载均衡模式这样可以同时利用两条物理链路。不过在RoCE场景下主备模式反而更安全——因为RoCEv2依赖ECMP做路径分担网卡绑定层面的LACP如果配置不当反而会破坏RDMA流量流向。3.2 交换机端口、光模块和线缆的坑计算网Leaf交换机向下提供25G或100G端口向上到Spine用100G或400G端口。选光模块的时候多模和单模别混。短距离100米内用多模光模块配合SR4线缆超过100米就要上单模光模块配合LR4/LR8线缆。多模比单模便宜但距离和带宽上限低。绝大多数数据中心内部设备间距其实都在100米内多模方案性价比最高。线缆方面有个容易翻车的点光模块的兼容性。尽量选交换机厂商认证过的模块或者同一品牌的整机光模块方案。杂牌光模块虽然便宜但可能出现接口up/down频繁抖动、误码率偏高排查起来极其痛苦。另外每根光纤跳线两端的标签必须和交换机端口、服务器网卡一一对应别指望靠记忆。几百根线不标标签出了问题就是一场灾难。3.3 机柜供电和散热最容易爆的雷100多台8卡GPU服务器的功耗不是小数。单台服务器如果满载跑训练功耗可能到3kW到6kW之间8卡GPU服务器经常更高。一个机柜放10台设备光服务器功耗可能就有50kW普通机柜标准供电根本扛不住。组网之前先算清楚单个机柜内设备的总功耗是否超过机柜的PDU额定功率整排机柜的负荷是否在机房空调制冷和UPS容量内。我见过一个项目网络全通了结果跑高负载训练时过热宕机一查是空调容量不够。这个锅不该由组网工程师背但作为整体交付的一部分你最好提前给出功耗估算表联合机房运维一起确认。4. 组网实操从交换机配置到GPU服务器接入4.1 交换机基础配置VLAN、MLAG和路由以计算网为例我会在Leaf交换机上先单独建一个VLAN用于计算流量。同时和Spine之间跑OSPF或BGP把计算网做三层路由打通。这里有个细节服务器网关通常落在Leaf交换机上所以Leaf交换机既承担二层接入又承担三层网关功能要合理规划SVI地址。为了让服务器高可用两台Leaf之间要做MLAG跨设备链路聚合这样服务器通过双线上联到两台Leaf任何一台Leaf宕机都不会断网。MLAG配置的要点是两台Leaf之间要有专门的peer-link互联链路并通过keepalive链路检测对端状态。配置完成后用show mlag summary确认两台设备的状态一致再开始下挂服务器。下面给一套简化版的关键模板以常见CLI为例具体命令以厂商文档为准# Leaf交换机上 vlan 100 name GPU-Compute # 创建VLAN接口作为网关 interface vlan100 ip address 10.30.0.1/24 # 端口接入服务器并划分进VLAN interface Ethernet1/1 switchport mode trunk switchport trunk allowed vlan 100 # 与另一台Leaf建立MLAG peer-link interface port-channel 1000 switchport mode trunk switchport trunk allowed vlan all为了减小路由故障影响推荐Leaf与Spine之间跑eBGP或OSPF。BGP的收敛速度慢一点但网络规模大时可控性更好OSPF更适合规模较小的集群配置也直观。我这里用的是OSPF因为它不复杂100台规模完全够用。4.2 无损网络配置PFC和ECN是RoCE的命根子RoCE跑在以太网上要保证不丢包就必须对流量做无损处理。PFC的作用是当某个队列拥塞时交换机暂停发送端避免缓存溢出丢包ECN的作用是让交换机在队列变长时给源端打标记源端感知到拥塞后主动降低发送速率。实际配置时要让RDMA流量走一个指定的优先队列。比如用COS3的队列专门跑RoCE然后针对这个队列开启PFC让网络拥塞时优先保障RoCE流量不被丢弃。同时在出口策略里配置ECN阈值让RDMA流量在队列超过阈值时打ECN标记网卡收到Echo后自动降速。例如# 将DSCP 26/27对应到COS 3 qos map dscp-to-cos 26 27 3 # 对COS 3队列开启PFC priority-flow-control mode on priority-flow-control cos 3 force # 启用ECN在出口策略中配置WRED ECN policy-map type qos CNP class COS3 wred random-detect ecn wred ecn threshold 200000配完PFC和ECN并不是万事大吉。要持续监控PFC反压帧的计数正常运行时这个数字应该很低如果PFC触发非常频繁说明网络存在拥塞热点需要优化拓扑或调整阈值。4.3 GPU服务器端的OS和网卡配置服务器上需要安装对应的网卡驱动Mellanox网卡需要安装MLNX_OFED并启用RoCE相关功能。操作系统层面建议关闭网卡的节能模式和LRO/GRO大包卸载因为有些设置会和RoCE冲突。给网卡配置IP后用ibv_devinfo或者rdma link show确认RDMA设备已经起来。如果网卡支持RoCEv2你还需要确认MTU设为9000巨型帧否则TCP/RDMA吞吐可能会受限。MTU设在1500也能通但跑大流量时性能明显差一截。下面是一个简化的网卡配置示例cat /etc/sysconfig/network-scripts/ifcfg-enp65s0f0 EOF DEVICEenp65s0f0 BOOTPROTOnone IPADDR10.30.0.101 PREFIX24 MTU9000 EOF # 加载内核模块并启用RoCE modprobe mlx5_ib配置完后在机器上执行ip a和ibstatus确认设备状态。这一步别偷懒每台机器都过一遍要比事后在训练日志里发现NCCL连接失败高效得多。4.4 存储集群接入别让IO拖了训练后腿存储网的设计比较简单GPU计算节点通过存储网访问并行文件系统NAS网关或存储服务器提供NFS/Lustre/GPFS等协议。存储网和计算网必须隔离否则大文件的读写会和梯度同步抢带宽。在GPU服务器上挂载共享存储时有几个参数值得注意。NFS挂载时建议带上nolock,hard,intr,rsize1048576,wsize1048576提高大块传输效率Lustre或GPFS则建议使用原生客户端性能远好于NFS over TCP。为了容错可以把存储网的bonding也做成主备模式因为存储网出错时数据停滞会造成模型训练直接卡死。5. 性能验证与调优一切配置最终要看效果5.1 物理链路和RDMA连通性测试所有设备上架并配置完成后先做单链路验证。用iperf3测TCP带宽确认链路速率符合预期再使用ib_write_bw或qperf测试RDMA带宽和时延。单条25G/100G链路如果iperf3只能跑到线速的60%左右先看窗口大小和CPU绑定。加-P 8并发流再测通常能拉满。如果并联多流后带宽还是不达标可能网络配置或光模块有问题。RDMA测试同样重要ib_write_bw -d mlx5_0 -a -F # 服务端 ib_write_bw -d mlx5_0 -a -F 10.30.0.102 # 客户端对端IP关注两个指标带宽是否接近线速时延是否在1-2微秒量级同机柜内或5微秒以内跨Spine。时延异常偏高的大概率是网络拥塞或交换机缓存配置不对。5.2 NCCL多机集合通信测试验证完单条RDMA链路还要验证GPU服务器上的NCCL多机通信。NCCL是深度学习和HPC里最常用的GPU集合通信库all_reduce性能直接决定分布式训练的上限。我一般会在每台服务器上编译NCCL Tests然后跨节点跑./build/all_reduce_perf -b 128M -e 8G -f 2 -g 8-g 8代表每台机器8个GPU-b到-e是数据量范围。跑完后看输出的“Out of bounds”和“Avg bus bandwidth”结果在多机环境下如果带宽不到理论值的70%就要重点排查网卡中断均衡、PCIe拓扑和RoCE PFC/ECN参数。多机测试时建议先在2台机器之间跑确认RoCE正常再扩展到10台、50台。因为大规模NCCL如果失败报错信息很抽象不好定位。从小到大逐级扩展能大大缩短排查时间。5.3 用真实训练任务模拟压测最后一步是用实际训练任务做一次烟囱测试。选一个中等规模的模型用DDP或DeepSpeed启动多机训练观察整体吞吐、GPU利用率、训练日志是否中断。这一步主要验证的不只是底层网络还有调度系统、存储系统、容器网络等环节的配合。我在压测时会同时监控nvidia-smi看GPU利用率、mpstat看CPU软中断、sar -n DEV看网卡流量、ibstat看RDMA设备状态。如果GPU利用率长期低于80%优先怀疑数据加载和预处理瓶颈再看网络。这个排查思路可以帮你快速区分是“算不动”还是“等不到”的问题。6. 常见问题与排查技巧实录6.1 网络能Ping通但RDMA Raw Data不通现象服务器之间ping通TCP也能传数据但运行NCCL或ib_write_bw时连接失败。原因通常有几种网卡驱动没启用RoCE功能、交换机或防火墙过滤了RoCE的UDP端口RoCEv2使用UDP端口4791、两端MTU不一致。排查时先用rdma link show确认为RTR状态再用ibv_devinfo看transport层如果port state不是Active检查网卡固件和驱动版本再确认交换机没有针对UDP 4791的默认丢弃策略。6.2 GPU利用率不高但CPU和内存也很空闲很多人遇到的“GPU卡、CPU不高但训练慢”就是网络等待问题。先用perfstat或NCCL_DEBUGINFO跑一轮短任务看集合通信是否长时间阻塞在AllReduce。如果是拿nccl-tests复测并对照理论带宽低于70%就回到底层查PFC、ECN和MTU。有一种容易忽略的情况跨CPU socket访问网卡会导致额外延迟。你最好把网卡中断绑定到和GPU所在NUMA node相关的CPU核上同时确认网卡插槽离GPU的PCIe控制器足够近。6.3 训练任务偶发中断或者NCCL超时偶发问题最难查但有两类原因很常见。一是计算网某些链路拥塞导致ECN/PFC频繁触发最终让RDMA进入退化状态二是交换机端口出现CRC错误或链路抖动的光模块这类故障通常不会直接断网但会造成零星的丢包。建议在交换机上开启端口错误计数监控在服务器端跑ethtool -S查看网卡错误计数。如果看到rx_crc_errors或者symbol_errors在持续增长直接换光模块或光纤大概率能解决。6.4 日常运维从硬件到网络的统一视图800多张卡的集群没有一个可视化的资产管理系统会非常痛苦。至少要做三件事记录每台服务器的资产编号、IP地址、机柜位置、所接交换机端口监控所有网络设备的端口流量、错误计数、光模块温度对计算网部署告警针对PFC计数、ECN标记、端口up/down设置阈值。网络告警最好和GPU监控联动。一旦GPU利用率掉点运维马上能拿到对应的网络设备日志这会极大缩短故障恢复时间。我在实际运维中一直坚持“业务指标异常时网络日志是首要证据”的思路。7. 最后分享几个实战体会这次组网我最深的感受是网络配置本身只占三成工作量剩下七成是规划、验证和排障。你在上架前多花半天把光模块、线缆标签、VLAN规划做好后面能省下一星期痛苦排障的时间。尤其是在这种100台级别的集群上任何事情只要乘以100都会变成大问题——一个网卡驱动版本不对你可能要处理100多台机器一个交换机端口被不小心划进了管理VLAN就可能导致整个计算网出现广播风暴。还有个小技巧任何变更操作前先备份配置文件哪怕只是新增一个VLAN。很多集群故障不是因为配置不先进而是因为有人改了配置没备份回滚时找不到原始版本。所有交换机、服务器的配置做到版本化保存这是底线。对于还在规划阶段的朋友别一上来就追求最贵的方案。先想清楚你的业务真的需要多少带宽、多少时延再决定是RoCE还是InfiniBand、是25G还是100G。网络升级不是一次性买卖留好扩容余量比一次买满更重要。最后把这套网络尽可能做标准化统一的VLAN分配模板、统一的端口配置模板、统一的主机命名规则后续每一个新增节点都能“照着填表”完成接入这样才真正算交付了一套能长久运转的GPU集群网络。 
