企业官网建设流程全解析

一百多台物理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参数的模型做数据并行，梯度同步一次就要搬约350GB（FP16梯度约为参数量乘以2字节）。这个数据量如果走千兆以太网，光传一次梯度就要近一个小时；走200Gbps的IB网络，也要十几秒。所以网络带宽不是"够用就行"，而是直接决定训练效率的核心瓶颈。

1.2 集群里的流量其实是三类，不能全塞一张网

这个阶段最容易踩的坑，就是把所有流量都往一张网络里塞。一百多台GPU服务器跑起来之后，主要流量其实分三类：

1. 训练通信流量：节点间同步梯度、激活重计算等，特点是带宽需求极高、延迟敏感、流量模式为周期性的突发。
2. 存储流量：数据加载、checkpoint保存与恢复。checkpoint动辄几百GB，集中写入时会对网络产生很大的吞吐冲击。
3. 管理运维流量：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 三条路各自的优劣

在这种规模下，实际上只有三条路可选：

从这张表能看出，普通以太网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。核心理由有三个：

1. 交付确定性：RoCE在百卡级已经需要非常细致的调优，到800卡规模，PFC死锁、哈希不均等问题会被放大，排查难度指数上升。IB有硬件层兜底，主流深度学习框架对它的支持最充分，出问题时的排障链路清晰得多。
2. 生态原生性：NCCL对IB的支持最成熟，几乎不用额外配置就能自动检测并启用RDMA。RoCE还得花精力去调GID、哈希、ECN，甚至会因为某个固件版本差异导致性能不稳定。
3. 运维心智负担：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规划是整个项目里最不起眼但返工最痛苦的部分。我的原则是：分段清晰、可按机柜聚合、可自动扩容、命名能看懂。

具体规划如下：

IB训练网这个10.1.0.0/16要往下细分。我的做法是按leaf交换机编号划分子网，每台leaf对应一个/24，比如leaf-01对应10.1.1.0/24，leaf-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 Key

IB网络还有一个以太网没有的概念：Subnet Manager（SM）。IB网络里必须有一个SM来管理链路状态、分配LID、计算路由。生产环境我建议在管理节点上部署两个SM做主备，而且主备切换要提前演练。一旦SM挂了，整个IB网络的路由重新收敛，所有训练任务都会中断，这个事故在百卡集群里是不可接受的。

另外可以按业务或团队划分Partition Key（PKey），相当于以太网的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 DEVICE=ib0 TYPE=InfiniBand ONBOOT=yes BOOTPROTO=static IPADDR=10.1.1.10 NETMASK=255.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 Gbps，200G端口扣除协议开销后，这个值正常；
• 跨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 性能调优的几个开关

如果实测性能离预期有差距，优先检查这几个点：

1. NCCL环境变量：确认NCCL_IB_DISABLE=0，并用NCCL_IB_HCA=mlx5_0:1,mlx5_1:1,mlx5_2:1,mlx5_3:1显式指定要使用的HCA和端口，防止NCCL拿到错误的设备；
2. 固件与驱动版本：对照兼容矩阵，确保MLNX_OFED和交换机固件版本配对，不要各升级各的；
3. IB的服务等级SL和虚拟通道VL划分：多租户场景下可以用不同SL隔离流量，避免互相干扰。

6. 踩坑记录：从链路降速到集体卡顿的排查过程

6.1 全网链路速率悄悄降到100G，罪魁祸首是光模块

集群上线跑了一个月后，监控突然报了一堆链路降速告警，从200G降到100G。刚开始以为是交换机端口故障，排查半天发现是某一批第三方光模块在高负载下信号劣化，导致链路自动协商降速。最坑的是，IB链路降速后不会自动恢复，必须手工把端口重置，或者直接更换模块。

这个问题的教训有两条：第一，大规模IB组网，光模块和线缆尽量用原厂认证的型号，至少也要用经过大量验证的品牌，库存里备足冗余模块；第二，监控里一定要有链路速率变化的告警，不然降速可能跑好几周才发现，等发现时训练效率已经被拖低很久了。

6.2 分布式训练"资源占用不高但很卡"的排查链路

这正好对应了很多人遇到的现象：GPU利用率和CPU内存都不高，但训练就是慢得像卡住。最初我怀疑是代码问题，后来把nvidia-smi、ibstat和交换机侧监控同时打开观察，才发现网络侧有明显的周期性拥塞：每轮迭代的all-reduce阶段都会出现短时大流量，由于哈希不均，其中两条链路被打满，其余链路闲着。

排查链路供参考：

1. ibstat看端口速率和状态，先排除物理层问题；
2. 到交换机侧看端口收发计数、丢包和重传计数，定位是哪条链路拥塞；
3. 打开NCCL_DEBUG=INFO，打印每个通信阶段的耗时，把瓶颈锁定在通信环节；
4. 检查哈希策略，必要时调整流量的端口范围或哈希因子。

最终根因是应用侧同时发起的QP数量过多，建连阶段就把某些链路的哈希表打得过载，导致流量分布严重不均。调整NCCL的队列深度参数后恢复正常。这种"假卡顿"在百卡以上集群非常容易出现，建议把网络指标全部接入监控大盘，别只盯GPU利用率。

6.3 扩容和维护时的坑

维护时如果不小心误操作把某台leaf交换机的端口关掉，所有连到该端口的服务器训练链路会瞬间掉线，然后NCCL进入重连回退模式，整个训练任务性能骤降甚至超时失败。这个集群一旦跑起来，基本没有"低峰期"，每次维护都要提前跟业务方确认，操作前先确认端口影响范围，能通过管理口带外操作的尽量带外操作。

另外提一个容易被忽视的细节：IB网络的固件升级窗口一定要避开训练任务。曾经有一次我们升级leaf交换机固件，虽然做了多路径冗余，但升级过程中SM重算路由，导致实时训练任务出现分钟级中断。后来所有网络变更都走变更流程，先评估影响、再预约窗口、最后回滚预案，才把这类事故压到零。

7. 写在最后的经验

这次组网从选型到验收，我最大的体会是：在百卡以上的GPU集群里，网络不是辅助设备，而是和算力同等重要的基础设施。选型和架构阶段多花的心思，会在后面无数个训练任务里加倍回报。如果只能给一条建议，那就是提前把地址规划、监控、文档和变更流程做好，而不是等集群跑起来再补。

我还有一个实际的小技巧：给每台服务器和每个网络端口都建立一份档案，记录端口连接的交换机、模块型号、固件版本和首次连通时间。这个不起眼的习惯，在排障时能省下大量时间，上百台机器的情况下，靠人脑记忆是绝对不够用的。组网组多了就会发现，真正决定一个集群好坏的，往往不是那几次漂亮的性能测试数字，而是这些细节的严谨程度。