企业官网建设流程全解析

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同时连接到所有Spine，Leaf下面挂服务器。

为什么不用传统的三层汇聚架构？因为在三层架构里，一旦汇聚层出现故障，它下面挂的所有服务器都会失联，而且汇聚层上往往会有多台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私有地址段，并预留足够余量。举例来说：

同时给每台服务器定好命名规范，比如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流量走一个指定的优先队列。比如用COS=3的队列专门跑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 DEVICE=enp65s0f0 BOOTPROTO=none IPADDR=10.30.0.101 PREFIX=24 MTU=9000 EOF # 加载内核模块并启用RoCE modprobe mlx5_ib

配置完后，在机器上执行ip a和ibstatus，确认设备状态。这一步别偷懒，每台机器都过一遍，要比事后在训练日志里发现NCCL连接失败高效得多。

4.4 存储集群接入：别让IO拖了训练后腿

存储网的设计比较简单：GPU计算节点通过存储网访问并行文件系统，NAS网关或存储服务器提供NFS/Lustre/GPFS等协议。存储网和计算网必须隔离，否则大文件的读写会和梯度同步抢带宽。

在GPU服务器上挂载共享存储时，有几个参数值得注意。NFS挂载时建议带上nolock,hard,intr,rsize=1048576,wsize=1048576，提高大块传输效率；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_DEBUG=INFO跑一轮短任务，看集合通信是否长时间阻塞在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集群网络。