说句实话刚听到“OpenAI 把 10 万 GPU 训练网络压到两层”这个消息时我的第一反应是不信。十万卡规模意味着聚合带宽轻松到 PB 级甚至几十 PB/s传统做法都是接入层、汇聚层、核心层一层一层往上搭结果你现在告诉我只留两层后来仔细算了一笔账又翻了近两年大型集群的公开网络架构资料发现这事儿不仅可行而且几乎是十万卡规模下唯一能落地的方案。这篇文章我想从一个做分布式训练基础设施的工程师视角把这里的“两层”到底是什么、为什么能行、怎么算端口和带宽、运维时又会踩哪些坑完整拆开讲清楚。这套东西适合谁看如果你在搞大规模 GPU 集群、做训练网络选型或者你只是跑几十卡的小集群但想提前理解“大厂怎么规划网络”这篇文章都能给你一个从原理到实操的完整参考。我不打算堆概念所有结论都会给出计算逻辑和实测经验争取让你看完后能直接拿去跟团队讨论方案。1. 十万卡集群的真实挑战算力越强网络越容易拖后腿1.1 为什么 10 万卡不是“把机器堆一起”就行先聊一个很反直觉的事实在大规模同步训练里GPU 算得再快也没用因为每一轮迭代结束都要做一次全局梯度同步。以最常见的 AllReduce 为例每张卡算完梯度后要把自己的梯度切块发给其他卡同时收别人的梯度最后在本地归约出完整梯度。这个过程的通信量跟模型参数量成正比跟你集群多大没有关系——但通信次数会随着集群规模变大而变多。举个例子一个 1750 亿参数的模型如果只用 1 张卡训练梯度数据量大约是 700GB 量级按 FP16 算175B × 2 字节 × 2 份一份用于发送、一份用于接收。这数据量当然不可能一次性全发出去NCCL 内部会切块、做流水线把通信和计算重叠起来。但问题是当集群扩展到 10 万卡每一次集合通信都要跨过整个集群的所有交换机链路中间任何一条路径的拥塞、抖动、丢包都会让所有 GPU 停下来等最慢的那一跳。所以在大规模训练里网络不是“辅助设施”它跟 GPU 本身一样是算力的一部分。你网络设计得不好哪怕 10 万张 H100 摆在机房里有效算力利用率可能连 50% 都到不了。OpenAI 把网络压到两层本质上是把“通信路径变短、行为变可预期”让每一轮同步的成本可控。1.2 传统三层架构在十万卡规模下会怎样传统数据中心常用三层架构接入层ToR接服务器汇聚层Aggregation收敛流量核心层Core负责跨区域流量。三层的好处是层次清晰适合南北向流量为主的传统业务但到了十万卡训练集群里问题非常明显。第一是延迟。每多一层交换机GPU 之间的通信就多一跳。别小看这一跳在集合通信中数据要经过“网卡 → Leaf → Spine → Leaf → 对端网卡”的路径。如果是三层就多一次“汇聚层”的转发端到端延迟至少增加 1~2 微秒。在千卡级别这可能无所谓但在十万卡级别同步次数极其频繁哪怕每次只多 1 微秒累积起来就是可观的效率损失。第二是收敛比。三层架构里汇聚层和核心层通常会做收敛比如接入层 1:1 上联汇聚层 3:1 收敛。这在传统互联网业务中没问题因为流量模型是“多数时间不需要全速互相通信”。但训练集群是 ALL-to-ALL 流量每张卡同时向成百上千张卡发数据几乎不存在空闲窗口。一旦做了收敛拥塞就是必然事件GPU 就会开始等待。第三是故障域。三层架构的故障路径更长从 GPU 到 GPU 要经过 7~9 台设备任何一台交换机掉线、任何一根光纤抖动都可能导致大范围通信异常。在大规模集群里每天物理链路出点问题几乎是常态架构层数越多排查链路就越费劲。1.3 “压到两层”到底是什么所谓两层就是 Leaf-Spine 架构也叫 Clos 网络。它只有两层交换机Leaf 层负责接入 GPU 服务器Spine 层负责把所有 Leaf 互联起来。任何两台 Leaf 下的 GPU 通信路径都只有 4 跳GPU → Leaf → Spine → Leaf → GPU。严格来说这是“二跳网络”因为 Leaf 交换机是网络边缘GPU 到对端 GPU 只经过两跳交换。关键点在于Spine 层是“横向扩展”的。三层架构里核心层往往要承担总流量汇聚的角色规模大了之后单个核心设备很难扛住但 Spine 层不用每一台 Spine 交换机只需要连接一部分 Leaf所有 Spine 并行工作整体带宽可以随着 Spine 数量的增加线性扩展。这就是为什么十万卡可以压到两层——不是靠某一台超级交换机撑起全场而是靠大量中档交换机横向铺开。我用一个生活化的类比帮新手理解传统三层网络像一座购物中心所有人要先坐扶梯到中间大平台再分流到各个店铺两层网络更像城市地铁网每个站点直接把客流送到目的地中间换乘的次数最少。训练场景下GPU 之间的通信就是“客流”你要做的就是让客流尽可能少换乘。2. 两层网络的架构设计端口、带宽、收敛比怎么算2.1 先算一笔带宽账要设计两层网络第一件事是确定“不收敛”需要多少带宽。训练网络跟传统网络最大的区别是我们要求任意两个 GPU 之间的通信带宽基本等价不能有热点。假设每个 GPU 配一块 400Gbps 的网卡这是当前训练集群非常常见的配置NVIDIA H100/H200 节点一般就是 8 卡 × 400G 网卡10 万 GPU 的总接入带宽就是10 万 × 400Gbps 40,000Tbps 40Pbps这是一个非常大的数。Leaf 交换机怎么选假设我们选一台 128 端口的交换机其中下行接 GPU上行接 Spine。为了做到 1:1 无收敛下行口和上行口数量要相等也就是 64 个下行口 64 个上行口。如果每个 GPU 占一个下行口一台 Leaf 可以接 64 个 GPU。10 万 GPU 需要约 1563 台 Leaf 交换机。Spine 层怎么算每台 Leaf 有 64 个上行口所有 Leaf 的上行口总数是1563 × 64 100,032 个 400G 上行端口如果 Spine 交换机同样是 128 端口那这些端口全部要用在 Leaf 互联上也就是说 Spine 端口总数至少要 10 万多个折合约 782 台 128 端口 Spine 交换机。这个规模确实夸张但在机房分散到多个建筑、多个楼层的前提下并非不可实现。而且实际工程里不一定会每个 GPU 都配一块 400G 网卡也可能会用 2×200G 聚合或者部分节点用更高密度交换机端口数量可以进一步压缩。我在实际做 2 千卡规模集群规划时基本也是按这套逻辑倒推的先定单卡带宽再定交换机端口密度最后算 Leaf 和 Spine 的数量。千万别跳步很多小集群网络跑不满原因就是上行端口数不够收敛比一算就不合格。2.2 收敛比为什么必须接近 1:1很多人问过我校验网络的时候要不要追求 1:1 不收敛我的回答是训练网络必须最少最少也要做到接近 1:1。原因很简单集合通信的场景里网络负载是持续全速的。以 AllReduce 为例数据是被切块的每个节点同时在给其他节点发送数据也同时在接收数据。如果任何一个上行端口出现拥塞NCCL 的进度就会卡在那个端口上整个簇的训练速度立刻被拖慢。传统网络可以做 3:1 甚至 5:1 收敛因为业务流量的峰值往往低于理论值但训练流量不是“打的满不满”的问题它天生就是“必须打满”的流量。还有一点很多人容易忽略NCCL 本身有“拓扑感知”。它启动时会在集群内部探测网络结构如果发现某些路径带宽不足它会自动调整通信顺序和切块大小。但这个过程是“被动适应”不会让网络变快只会让你的训练更慢。与其让 NCCL 去绕路不如从设计上把网络做成“处处等效”这样无论它怎么调度结果都稳定。所以我的建议是端口预算先按 1:1 算如果实在做不了再看具体流量模型能不能把某些跨 Spine 的流量绕开。但在十万卡这种规模没有绕的空间所有流量都是东西向收敛比做低了等于白买 GPU。2.3 网络层次变小代价转移到了哪里层数从三层变两层看起来是“简化”其实只是把复杂度转移了。第一Spine 交换机数量暴增。前面算了十万卡可能需要几百台 Spine 交换机这些交换机之间的连接不是点对点直连而是通过 Leaf 间接连接。每一台 Spine 都要跟每一台 Leaf 相连于是光纤数量会爆炸。假设 1563 台 Leaf 和 782 台 Spine 按 1:1 互联需要的光纤跳线数量是1563 × 64 100,032 根这还没算 Leaf 下行到 GPU 服务器、服务器内部网卡到交换机端口的跳线。十万卡集群的光纤总量是百万根级别的。OpenAI 在相关分享里也提到大量时间其实花在光纤部署、理线、打标签这些“脏活”上。所以两层网络省的是设备跳数增加的是物理布线的精细度。第二控制面配置简化物理面检查繁琐。两层网络的协议配置比三层简单很多一般就是 BGP 跑 underlay、ECMP 做等价多路径或者用动态路由协议做自动收敛没有太多分层路由策略。但网络越简单问题越容易出现在物理层。光模块脏了、光纤弯曲半径不够、光衰偏大、FEC 错包这些在层数多的时候可能被高一层掩盖但两层网络下任何物理问题都会直接反馈到 GPU 训练速度上。我在维护训练集群时有一条心得网络层数越少越要重视物理层监控。每根光纤、每个光模块都要有在线监测和告警不然排查链路比治协议故障痛苦得多。3. 协议与控制面稳定压过 10 万卡的关键细节3.1 RoCE 还是 InfiniBand训练网络的路线之争聊到训练网络绕不开一个经典问题用 RoCERDMA over Converged Ethernet还是 InfiniBand从 OpenAI 公开一些演讲和招聘信息来看它的集群逐步转到 RoCE/以太网阵营的概率很大而且整个行业也有明显从 InfiniBand 迁移到 RoCE 的趋势。InfiniBand 的好处是历史包袱少天然支持 RDMA、可靠传输、无损网络部署完基本不用额外调优。但它的劣势是生态封闭、价格贵、供应商绑定而且尤其在高密度大规模场景下IB 交换机上的自适应路由Adaptive Routing和显式拥塞通知功能虽然强但运维门槛高。RoCE 则是在标准以太网上跑 RDMA生态成熟、成本低而且随着 400G/800G 以太网和智能网卡的发展RoCE 在大规模集群里的表现已经越来越接近 IB。代价是它对网络质量要求极高必须在无损或半无损网络上工作需要把 PFC、ECN、ETS 这些机制配好否则一有丢包性能直接断崖式下跌。我的经验是RoCE 方案在大集群中完全可行前提是你愿意投入时间去调拥塞控制参数。十万卡级别的网络里我不推荐“跑起来就行”的心态必须有一套完善的流控矩阵配置甚至要在智能网卡上做 QoS 队列隔离让集合通信流量和控制流量互相不干扰。3.2 负载均衡从 ECMP 到多路径演进传统以太网最常用的负载均衡是 ECMP把流量按照五元组哈希到多条等价路径上。问题出在两条一是哈希“碰运气”两个大流如果哈希到同一路径一条路径拥塞另一条空闲训练性能就会受影响二是大流比如 AllReduce 中的大象流很难靠五元组散开因为同一个通信流的五元组是固定的。在大规模 RoCE 网络里为了缓解这个问题业界普遍在做两个方向的演进。一个方向是动态负载均衡DLB一些新交换芯片支持按报文或按流粒度动态调整路径感知拥塞后把流量从拥塞路径迁移到空闲路径另一个方向是端网协同由智能网卡根据实时拥塞信息选择合适的路径相当于把“路由决策”从交换机搬到网卡侧。GPU 直连网卡场景下这个趋势非常明显。还有一个常被忽略的技术是 Packet Spraying就是把一个流的数据包打散到所有等价路径上。它的好处是路径利用率极高几乎不可能出现“一条路堵死、另一条路闲置”的情况但对交换机的能力要求很高需要芯片支持乱序重排或者接收端能处理乱序。RoCE 是保序的要做到逐包喷洒就必须在交换机侧完成排序逻辑目前只有部分高端芯片支持。我在规模不大几百卡的环境下实测过开启 DLB 后 AllReduce 的吞吐能提升 10%~20%这种收益在训练场景里非常可观。3.3 NCCL 视角集合通信是怎么“压榨”网络的NCCL 是 NVIDIA 的集合通信库大规模 GPU 训练几乎都跑在它上面。很多人把它当作黑盒其实它对网络拓扑的感知非常强。启动时会做一次拓扑探测识别 GPU 之间的 NVLink 连接方式和跨节点网卡所在 PCIe 端口然后自动选择一个通信方案。在两层 Leaf-Spine 拓扑下NCCL 看到的跨节点路径是很规整的GPU 通过本地网卡 → Leaf → Spine → 对端 Leaf → 对端网卡。链路等价性高NCCL 就能高效地把通信切块、打散到所有可用网卡上。反过来如果路径不对等比如有的 GPU 多一跳、有的少一跳NCCL 会“迁就”慢路径把通信速度拖下来。实际操作中我建议跑大任务之前先看 NCCL 日志里的拓扑信息确认它识别到了预期的拓扑结构# 运行前打开 NCCL 调试观察拓扑探测结果 NCCL_DEBUGINFO NCCL_DEBUG_SUBSYSGRAPHE /your_app/run_training.sh如果发现 NCCL 把跨节点的通信路径识别成了“非最优”优先检查网卡的 PCIe 分配拓扑以及是否有网卡被 CPU 的 NUMA hop 干扰。很多时候性能瓶颈根本不在交换机而在服务器的 PCIe Switch 和 NUMA 拓扑上。还有一个小技巧NCCL 支持通过NCCL_P2P_LEVEL和NCCL_NET_GDR_LEVEL调整不同通信层级的行为。在两层网络里通常希望跨节点通信都走 RDMA 网卡并且尽量用 GPU Direct RDMAGDR避免数据从 GPU 拷贝到 CPU 内存再发出。开启 GDR 后延迟能降低 2~3 微秒吞吐提升也很明显。4. 十万卡规模的运维实录常见问题与排查路径4.1 光模块和光纤问题最容易被忽视的“隐形杀手”十万卡集群跟小集群最大的区别在于物理层故障的频率被放大了上千倍。早期做小规模集群时一个光模块坏了也就是一块 GPU 训练慢不影响全局但十万卡场景里任何一条链路出问题都可能导致大范围 AllReduce 卡顿整个训练任务被迫暂停。最常见的光纤问题有这么几类光模块收发功率异常通常由于光口污染或光纤弯曲半径过小引起收发波长或速率不匹配例如交换机模块是 400G SR8网卡模块是 400G AOC两端协商失败尾纤跳线松动轻载时没问题一旦流量上来就丢包FEC 错误数持续增长链路虽然没断但纠错开销越来越大有效带宽下降。排查时先用 ethtool 看端口状态和丢包计数再量光模块收发光功率# 查看物理链路状态和错误计数 ethtool -S enp175s0f0np0 | grep -E rx_errors|tx_errors|fec_corrected|fec_uncorrectable # 查看光模块信息速率、温度、电压、收发光功率 ethtool -m enp175s0f0np0如果光模块收光功率在接收灵敏度附近比如 400G SR8 模块典型接收功率在 -7dBm 到 2dBm 之间如果掉到 -9dBm 以下你就该考虑清端口或换跳线了。光模块温升也很重要交换机高密度部署下散热不好的端口会出现热漂移表现为白天训练慢、晚上恢复这种情况我看过不少。4.2 PFC 死锁与拥塞风暴RoCE 网络的“头号杀手”RoCE 做无损依赖 PFC 暂停帧。每条队列水压达到阈值后交换机反向发送暂停帧让上游发送方停止发送。这在理论上很完美但实际运行中会出现 PFC 死锁排队链路的背压沿着链路逐级传播最后形成拥塞树所有流量都卡在树的根部表现为集群通信整体瘫痪。这个现象在跨 Leaf-Spine 的 RoCE 网络中尤其常见。当多个 Leaf 同时向同一台 Spine 发送大量流量时这台 Spine 的入方向队列爆满触发 PFC 反压反压传回 LeafLeaf 又把暂停帧上送给所有 GPU 网卡结果是所有 GPU 同时进入“暂停”状态网络吞吐直接从 400G 掉到几百 Mbps。排查 PFC 死锁要分几步。先在交换机上抓队列统计和暂停帧计数# 以 Mellanox 交换机为例查看端口 PFC 计数 show interface pause counter # 查看交换机上每个优先级队列的缓存占用 show buffer queue statistics如果发现某个队列的 PFC Transmit 计数在训练高压时段猛涨说明该队列对端的设备一直在发暂停帧这基本就是拥塞风暴的起点。解决方案除了调整 PFC 阈值和加权调度外还可以从应用侧入手给 NCCL 流量设置更小的 PFC 队列或者用 ECN 标记替代暂停帧提前让端侧降速而不是等交换机缓存满了再一刀切暂停。4.3 我总结的十万卡网络避坑清单基于我自己运维训练集群的经验这里列几个通用性比较强的避坑点字字都是“花钱买来的教训”。不要盲目开启“全速率自协商”。RoCE 场景下网卡和交换机模块如果速率协商不稳定会出现周期性的链路闪断。大集群里最好把速率、FEC 模式都固定配置例如 400G 固定用 RS-FEC两端一定要一致。FEC 计数要监控不是只看丢包。FEC 纠错本身是透明的但如果 uncorrectable FEC 持续出现说明链路质量差到纠错都救不了这会直接导致重传和训练卡顿。对 uncorrectable 计数建议做成告警阈值超过 1 就盯紧。别把所有光模块当“免维护”。高密度槽位里积灰、氧化、接头松动几乎是必然事件。新买的吹灰工具和光纤清洁笔可能比换机还重要。变更要克制。大规模集群里最怕的不是硬件坏而是人类变更。每次升级交换机固件、调整 PFC 参数、替换光模块都要有完整方案和回滚预案。曾经一次调整 ECN 阈值的变更导致整个集群性能波动了一整天最后靠回滚才恢复。日志一定要集中化。十万卡集群里手动登录每台交换机查日志根本不现实。所有交换机的表项、日志、端口计数必须采集到统一平台否则出问题你连“从哪查起”都不知道。4.4 一张问题速查表直接贴在工位上我自己把平时遇到的高频问题整理成了一张表遇到问题先对着表定位效率能提升几倍。现象可能原因排查路径解决办法单 GPU 训练奇慢其他正常光模块脏或者光纤弯曲过大ethtool -m 查看光功率和模块温度清洁光口、换线、调整布线半径所有 GPU 同时卡顿吞吐趋近于零PFC 死锁或队列缓存打满交换机上查 pause counter、queue statistics调整阈值、限制突发流量、重分布流量训练开始时快运行几小时后变慢光模块热漂移或交换机散热问题对比不同时段温度数据和 tc 丢包计数清理通风道、降低供电温度、换备用模块AllReduce 带宽远低于理论值网卡队列或 PCIe 拓扑不对NCCL 未走最优路径NCCL_DEBUGINFO 观察路径查 lspci 拓扑调网卡队列数量、调整进程绑定启用 GDR偶发重传时好时坏设备端口缓存不足或 FEC 失效长时间抓 ethtool -S 的 rx_crc_errors更换故障模块、确保同一速率和 FEC 模式这张表未必覆盖所有场景但训练网络的问题多数绕不开这五类。熟练之后你甚至会从“查网络”变成“查物理”省下的精力用来研究模型调优不香吗5. 两层架构的价值与借鉴不只是超大厂能这么干5.1 中小集群也要有“两层思维”有人可能会说10 万卡才需要两层我只有 200 卡跟我有什么关系我觉得恰恰相反。两层的核心不是“规模大”而是“路径短且可预期”。哪怕只有几十张卡如果你沿用三层的思路虽然也许不会立刻出事故但你在设计阶段就埋下了“路径长短不一”“核心瓶颈难拆”的隐患。小集群更现实的做法是提前按照 Leaf-Spine 的框架去做机柜规划和网络划分。比如 32 台 GPU 服务器分在 4 个机柜里每个机柜放一台 Leaf两台 Spine 做互联保证任意两台服务器之间的网络路径一致。等将来扩容到几百卡时你要做的只是加 Leaf、加 Spine而不是推翻重来。另一方面小集群也是验证新技术的最佳场地。像前面提到的 DLB、ECNPFC 参数、NCCL 调优技巧都可以先在小规模上做对照实验一点点把参数调明白等集群大了直接照搬成熟配置。我见过太多团队小集群将就着跑到大集群时发现一堆历史遗留问题最后全部重排。5.2 下一步演进多路径、远端内存和光交换OpenAI 把十万卡压到两层不代表这就是终点。在我看来训练网络下一步会往三个方向走。第一是真正的多路径和智能网卡联动。随着网卡侧可编程能力增强负载均衡会从交换机逐渐上移到端侧。GPU 网卡可以选择“主动测量哪条链路空闲”然后把数据发到更优路径上。两层网络高度等价的拓扑恰好是最适合这类端网协同方案的土壤。第二是远端内存池化。训练过程里经常出现显存不够用把部分状态卸载到远端内存。如果网络能提供更低的延迟和更大的带宽远端内存就能更“透明”地参与训练相当于把 GPU 的可利用显存扩大了。两层架构的短路径在这里价值巨大。第三是光交换的引入。目前 Leaf-Spine 之间还是电交换芯片做包转发未来可能引入光电路交换OCS让某两个 Leaf 之间的连接按需物理层直连。这样一来“网络压到两层”甚至“压到几乎零层”也未必不可能GPU 之间直接走光通路速度和延迟都会有质变。从行业趋势看训练网络越来越像是“算力的一部分”而不是独立的支撑系统。谁说网络工程师不是训练团队的一员呢至少在十万卡集群里网络掉链子的时候训练主管第一个找的就是你。最后再分享一个小经验别被“压到两层”这种说法唬住。它不是一个魔术而是把规模、成本、延迟、运维全部权衡之后的结果。你不需要真的拥有十万卡才能借鉴这一点——只要在设计网络的任何阶段优先让路径变短、让行为变可预期、让排查变简单你的集群就已经在“正确的方向”上了。 十万卡GPU集群网络压到两层：Leaf-Spine架构深度解析与实战
说句实话刚听到“OpenAI 把 10 万 GPU 训练网络压到两层”这个消息时我的第一反应是不信。十万卡规模意味着聚合带宽轻松到 PB 级甚至几十 PB/s传统做法都是接入层、汇聚层、核心层一层一层往上搭结果你现在告诉我只留两层后来仔细算了一笔账又翻了近两年大型集群的公开网络架构资料发现这事儿不仅可行而且几乎是十万卡规模下唯一能落地的方案。这篇文章我想从一个做分布式训练基础设施的工程师视角把这里的“两层”到底是什么、为什么能行、怎么算端口和带宽、运维时又会踩哪些坑完整拆开讲清楚。这套东西适合谁看如果你在搞大规模 GPU 集群、做训练网络选型或者你只是跑几十卡的小集群但想提前理解“大厂怎么规划网络”这篇文章都能给你一个从原理到实操的完整参考。我不打算堆概念所有结论都会给出计算逻辑和实测经验争取让你看完后能直接拿去跟团队讨论方案。1. 十万卡集群的真实挑战算力越强网络越容易拖后腿1.1 为什么 10 万卡不是“把机器堆一起”就行先聊一个很反直觉的事实在大规模同步训练里GPU 算得再快也没用因为每一轮迭代结束都要做一次全局梯度同步。以最常见的 AllReduce 为例每张卡算完梯度后要把自己的梯度切块发给其他卡同时收别人的梯度最后在本地归约出完整梯度。这个过程的通信量跟模型参数量成正比跟你集群多大没有关系——但通信次数会随着集群规模变大而变多。举个例子一个 1750 亿参数的模型如果只用 1 张卡训练梯度数据量大约是 700GB 量级按 FP16 算175B × 2 字节 × 2 份一份用于发送、一份用于接收。这数据量当然不可能一次性全发出去NCCL 内部会切块、做流水线把通信和计算重叠起来。但问题是当集群扩展到 10 万卡每一次集合通信都要跨过整个集群的所有交换机链路中间任何一条路径的拥塞、抖动、丢包都会让所有 GPU 停下来等最慢的那一跳。所以在大规模训练里网络不是“辅助设施”它跟 GPU 本身一样是算力的一部分。你网络设计得不好哪怕 10 万张 H100 摆在机房里有效算力利用率可能连 50% 都到不了。OpenAI 把网络压到两层本质上是把“通信路径变短、行为变可预期”让每一轮同步的成本可控。1.2 传统三层架构在十万卡规模下会怎样传统数据中心常用三层架构接入层ToR接服务器汇聚层Aggregation收敛流量核心层Core负责跨区域流量。三层的好处是层次清晰适合南北向流量为主的传统业务但到了十万卡训练集群里问题非常明显。第一是延迟。每多一层交换机GPU 之间的通信就多一跳。别小看这一跳在集合通信中数据要经过“网卡 → Leaf → Spine → Leaf → 对端网卡”的路径。如果是三层就多一次“汇聚层”的转发端到端延迟至少增加 1~2 微秒。在千卡级别这可能无所谓但在十万卡级别同步次数极其频繁哪怕每次只多 1 微秒累积起来就是可观的效率损失。第二是收敛比。三层架构里汇聚层和核心层通常会做收敛比如接入层 1:1 上联汇聚层 3:1 收敛。这在传统互联网业务中没问题因为流量模型是“多数时间不需要全速互相通信”。但训练集群是 ALL-to-ALL 流量每张卡同时向成百上千张卡发数据几乎不存在空闲窗口。一旦做了收敛拥塞就是必然事件GPU 就会开始等待。第三是故障域。三层架构的故障路径更长从 GPU 到 GPU 要经过 7~9 台设备任何一台交换机掉线、任何一根光纤抖动都可能导致大范围通信异常。在大规模集群里每天物理链路出点问题几乎是常态架构层数越多排查链路就越费劲。1.3 “压到两层”到底是什么所谓两层就是 Leaf-Spine 架构也叫 Clos 网络。它只有两层交换机Leaf 层负责接入 GPU 服务器Spine 层负责把所有 Leaf 互联起来。任何两台 Leaf 下的 GPU 通信路径都只有 4 跳GPU → Leaf → Spine → Leaf → GPU。严格来说这是“二跳网络”因为 Leaf 交换机是网络边缘GPU 到对端 GPU 只经过两跳交换。关键点在于Spine 层是“横向扩展”的。三层架构里核心层往往要承担总流量汇聚的角色规模大了之后单个核心设备很难扛住但 Spine 层不用每一台 Spine 交换机只需要连接一部分 Leaf所有 Spine 并行工作整体带宽可以随着 Spine 数量的增加线性扩展。这就是为什么十万卡可以压到两层——不是靠某一台超级交换机撑起全场而是靠大量中档交换机横向铺开。我用一个生活化的类比帮新手理解传统三层网络像一座购物中心所有人要先坐扶梯到中间大平台再分流到各个店铺两层网络更像城市地铁网每个站点直接把客流送到目的地中间换乘的次数最少。训练场景下GPU 之间的通信就是“客流”你要做的就是让客流尽可能少换乘。2. 两层网络的架构设计端口、带宽、收敛比怎么算2.1 先算一笔带宽账要设计两层网络第一件事是确定“不收敛”需要多少带宽。训练网络跟传统网络最大的区别是我们要求任意两个 GPU 之间的通信带宽基本等价不能有热点。假设每个 GPU 配一块 400Gbps 的网卡这是当前训练集群非常常见的配置NVIDIA H100/H200 节点一般就是 8 卡 × 400G 网卡10 万 GPU 的总接入带宽就是10 万 × 400Gbps 40,000Tbps 40Pbps这是一个非常大的数。Leaf 交换机怎么选假设我们选一台 128 端口的交换机其中下行接 GPU上行接 Spine。为了做到 1:1 无收敛下行口和上行口数量要相等也就是 64 个下行口 64 个上行口。如果每个 GPU 占一个下行口一台 Leaf 可以接 64 个 GPU。10 万 GPU 需要约 1563 台 Leaf 交换机。Spine 层怎么算每台 Leaf 有 64 个上行口所有 Leaf 的上行口总数是1563 × 64 100,032 个 400G 上行端口如果 Spine 交换机同样是 128 端口那这些端口全部要用在 Leaf 互联上也就是说 Spine 端口总数至少要 10 万多个折合约 782 台 128 端口 Spine 交换机。这个规模确实夸张但在机房分散到多个建筑、多个楼层的前提下并非不可实现。而且实际工程里不一定会每个 GPU 都配一块 400G 网卡也可能会用 2×200G 聚合或者部分节点用更高密度交换机端口数量可以进一步压缩。我在实际做 2 千卡规模集群规划时基本也是按这套逻辑倒推的先定单卡带宽再定交换机端口密度最后算 Leaf 和 Spine 的数量。千万别跳步很多小集群网络跑不满原因就是上行端口数不够收敛比一算就不合格。2.2 收敛比为什么必须接近 1:1很多人问过我校验网络的时候要不要追求 1:1 不收敛我的回答是训练网络必须最少最少也要做到接近 1:1。原因很简单集合通信的场景里网络负载是持续全速的。以 AllReduce 为例数据是被切块的每个节点同时在给其他节点发送数据也同时在接收数据。如果任何一个上行端口出现拥塞NCCL 的进度就会卡在那个端口上整个簇的训练速度立刻被拖慢。传统网络可以做 3:1 甚至 5:1 收敛因为业务流量的峰值往往低于理论值但训练流量不是“打的满不满”的问题它天生就是“必须打满”的流量。还有一点很多人容易忽略NCCL 本身有“拓扑感知”。它启动时会在集群内部探测网络结构如果发现某些路径带宽不足它会自动调整通信顺序和切块大小。但这个过程是“被动适应”不会让网络变快只会让你的训练更慢。与其让 NCCL 去绕路不如从设计上把网络做成“处处等效”这样无论它怎么调度结果都稳定。所以我的建议是端口预算先按 1:1 算如果实在做不了再看具体流量模型能不能把某些跨 Spine 的流量绕开。但在十万卡这种规模没有绕的空间所有流量都是东西向收敛比做低了等于白买 GPU。2.3 网络层次变小代价转移到了哪里层数从三层变两层看起来是“简化”其实只是把复杂度转移了。第一Spine 交换机数量暴增。前面算了十万卡可能需要几百台 Spine 交换机这些交换机之间的连接不是点对点直连而是通过 Leaf 间接连接。每一台 Spine 都要跟每一台 Leaf 相连于是光纤数量会爆炸。假设 1563 台 Leaf 和 782 台 Spine 按 1:1 互联需要的光纤跳线数量是1563 × 64 100,032 根这还没算 Leaf 下行到 GPU 服务器、服务器内部网卡到交换机端口的跳线。十万卡集群的光纤总量是百万根级别的。OpenAI 在相关分享里也提到大量时间其实花在光纤部署、理线、打标签这些“脏活”上。所以两层网络省的是设备跳数增加的是物理布线的精细度。第二控制面配置简化物理面检查繁琐。两层网络的协议配置比三层简单很多一般就是 BGP 跑 underlay、ECMP 做等价多路径或者用动态路由协议做自动收敛没有太多分层路由策略。但网络越简单问题越容易出现在物理层。光模块脏了、光纤弯曲半径不够、光衰偏大、FEC 错包这些在层数多的时候可能被高一层掩盖但两层网络下任何物理问题都会直接反馈到 GPU 训练速度上。我在维护训练集群时有一条心得网络层数越少越要重视物理层监控。每根光纤、每个光模块都要有在线监测和告警不然排查链路比治协议故障痛苦得多。3. 协议与控制面稳定压过 10 万卡的关键细节3.1 RoCE 还是 InfiniBand训练网络的路线之争聊到训练网络绕不开一个经典问题用 RoCERDMA over Converged Ethernet还是 InfiniBand从 OpenAI 公开一些演讲和招聘信息来看它的集群逐步转到 RoCE/以太网阵营的概率很大而且整个行业也有明显从 InfiniBand 迁移到 RoCE 的趋势。InfiniBand 的好处是历史包袱少天然支持 RDMA、可靠传输、无损网络部署完基本不用额外调优。但它的劣势是生态封闭、价格贵、供应商绑定而且尤其在高密度大规模场景下IB 交换机上的自适应路由Adaptive Routing和显式拥塞通知功能虽然强但运维门槛高。RoCE 则是在标准以太网上跑 RDMA生态成熟、成本低而且随着 400G/800G 以太网和智能网卡的发展RoCE 在大规模集群里的表现已经越来越接近 IB。代价是它对网络质量要求极高必须在无损或半无损网络上工作需要把 PFC、ECN、ETS 这些机制配好否则一有丢包性能直接断崖式下跌。我的经验是RoCE 方案在大集群中完全可行前提是你愿意投入时间去调拥塞控制参数。十万卡级别的网络里我不推荐“跑起来就行”的心态必须有一套完善的流控矩阵配置甚至要在智能网卡上做 QoS 队列隔离让集合通信流量和控制流量互相不干扰。3.2 负载均衡从 ECMP 到多路径演进传统以太网最常用的负载均衡是 ECMP把流量按照五元组哈希到多条等价路径上。问题出在两条一是哈希“碰运气”两个大流如果哈希到同一路径一条路径拥塞另一条空闲训练性能就会受影响二是大流比如 AllReduce 中的大象流很难靠五元组散开因为同一个通信流的五元组是固定的。在大规模 RoCE 网络里为了缓解这个问题业界普遍在做两个方向的演进。一个方向是动态负载均衡DLB一些新交换芯片支持按报文或按流粒度动态调整路径感知拥塞后把流量从拥塞路径迁移到空闲路径另一个方向是端网协同由智能网卡根据实时拥塞信息选择合适的路径相当于把“路由决策”从交换机搬到网卡侧。GPU 直连网卡场景下这个趋势非常明显。还有一个常被忽略的技术是 Packet Spraying就是把一个流的数据包打散到所有等价路径上。它的好处是路径利用率极高几乎不可能出现“一条路堵死、另一条路闲置”的情况但对交换机的能力要求很高需要芯片支持乱序重排或者接收端能处理乱序。RoCE 是保序的要做到逐包喷洒就必须在交换机侧完成排序逻辑目前只有部分高端芯片支持。我在规模不大几百卡的环境下实测过开启 DLB 后 AllReduce 的吞吐能提升 10%~20%这种收益在训练场景里非常可观。3.3 NCCL 视角集合通信是怎么“压榨”网络的NCCL 是 NVIDIA 的集合通信库大规模 GPU 训练几乎都跑在它上面。很多人把它当作黑盒其实它对网络拓扑的感知非常强。启动时会做一次拓扑探测识别 GPU 之间的 NVLink 连接方式和跨节点网卡所在 PCIe 端口然后自动选择一个通信方案。在两层 Leaf-Spine 拓扑下NCCL 看到的跨节点路径是很规整的GPU 通过本地网卡 → Leaf → Spine → 对端 Leaf → 对端网卡。链路等价性高NCCL 就能高效地把通信切块、打散到所有可用网卡上。反过来如果路径不对等比如有的 GPU 多一跳、有的少一跳NCCL 会“迁就”慢路径把通信速度拖下来。实际操作中我建议跑大任务之前先看 NCCL 日志里的拓扑信息确认它识别到了预期的拓扑结构# 运行前打开 NCCL 调试观察拓扑探测结果 NCCL_DEBUGINFO NCCL_DEBUG_SUBSYSGRAPHE /your_app/run_training.sh如果发现 NCCL 把跨节点的通信路径识别成了“非最优”优先检查网卡的 PCIe 分配拓扑以及是否有网卡被 CPU 的 NUMA hop 干扰。很多时候性能瓶颈根本不在交换机而在服务器的 PCIe Switch 和 NUMA 拓扑上。还有一个小技巧NCCL 支持通过NCCL_P2P_LEVEL和NCCL_NET_GDR_LEVEL调整不同通信层级的行为。在两层网络里通常希望跨节点通信都走 RDMA 网卡并且尽量用 GPU Direct RDMAGDR避免数据从 GPU 拷贝到 CPU 内存再发出。开启 GDR 后延迟能降低 2~3 微秒吞吐提升也很明显。4. 十万卡规模的运维实录常见问题与排查路径4.1 光模块和光纤问题最容易被忽视的“隐形杀手”十万卡集群跟小集群最大的区别在于物理层故障的频率被放大了上千倍。早期做小规模集群时一个光模块坏了也就是一块 GPU 训练慢不影响全局但十万卡场景里任何一条链路出问题都可能导致大范围 AllReduce 卡顿整个训练任务被迫暂停。最常见的光纤问题有这么几类光模块收发功率异常通常由于光口污染或光纤弯曲半径过小引起收发波长或速率不匹配例如交换机模块是 400G SR8网卡模块是 400G AOC两端协商失败尾纤跳线松动轻载时没问题一旦流量上来就丢包FEC 错误数持续增长链路虽然没断但纠错开销越来越大有效带宽下降。排查时先用 ethtool 看端口状态和丢包计数再量光模块收发光功率# 查看物理链路状态和错误计数 ethtool -S enp175s0f0np0 | grep -E rx_errors|tx_errors|fec_corrected|fec_uncorrectable # 查看光模块信息速率、温度、电压、收发光功率 ethtool -m enp175s0f0np0如果光模块收光功率在接收灵敏度附近比如 400G SR8 模块典型接收功率在 -7dBm 到 2dBm 之间如果掉到 -9dBm 以下你就该考虑清端口或换跳线了。光模块温升也很重要交换机高密度部署下散热不好的端口会出现热漂移表现为白天训练慢、晚上恢复这种情况我看过不少。4.2 PFC 死锁与拥塞风暴RoCE 网络的“头号杀手”RoCE 做无损依赖 PFC 暂停帧。每条队列水压达到阈值后交换机反向发送暂停帧让上游发送方停止发送。这在理论上很完美但实际运行中会出现 PFC 死锁排队链路的背压沿着链路逐级传播最后形成拥塞树所有流量都卡在树的根部表现为集群通信整体瘫痪。这个现象在跨 Leaf-Spine 的 RoCE 网络中尤其常见。当多个 Leaf 同时向同一台 Spine 发送大量流量时这台 Spine 的入方向队列爆满触发 PFC 反压反压传回 LeafLeaf 又把暂停帧上送给所有 GPU 网卡结果是所有 GPU 同时进入“暂停”状态网络吞吐直接从 400G 掉到几百 Mbps。排查 PFC 死锁要分几步。先在交换机上抓队列统计和暂停帧计数# 以 Mellanox 交换机为例查看端口 PFC 计数 show interface pause counter # 查看交换机上每个优先级队列的缓存占用 show buffer queue statistics如果发现某个队列的 PFC Transmit 计数在训练高压时段猛涨说明该队列对端的设备一直在发暂停帧这基本就是拥塞风暴的起点。解决方案除了调整 PFC 阈值和加权调度外还可以从应用侧入手给 NCCL 流量设置更小的 PFC 队列或者用 ECN 标记替代暂停帧提前让端侧降速而不是等交换机缓存满了再一刀切暂停。4.3 我总结的十万卡网络避坑清单基于我自己运维训练集群的经验这里列几个通用性比较强的避坑点字字都是“花钱买来的教训”。不要盲目开启“全速率自协商”。RoCE 场景下网卡和交换机模块如果速率协商不稳定会出现周期性的链路闪断。大集群里最好把速率、FEC 模式都固定配置例如 400G 固定用 RS-FEC两端一定要一致。FEC 计数要监控不是只看丢包。FEC 纠错本身是透明的但如果 uncorrectable FEC 持续出现说明链路质量差到纠错都救不了这会直接导致重传和训练卡顿。对 uncorrectable 计数建议做成告警阈值超过 1 就盯紧。别把所有光模块当“免维护”。高密度槽位里积灰、氧化、接头松动几乎是必然事件。新买的吹灰工具和光纤清洁笔可能比换机还重要。变更要克制。大规模集群里最怕的不是硬件坏而是人类变更。每次升级交换机固件、调整 PFC 参数、替换光模块都要有完整方案和回滚预案。曾经一次调整 ECN 阈值的变更导致整个集群性能波动了一整天最后靠回滚才恢复。日志一定要集中化。十万卡集群里手动登录每台交换机查日志根本不现实。所有交换机的表项、日志、端口计数必须采集到统一平台否则出问题你连“从哪查起”都不知道。4.4 一张问题速查表直接贴在工位上我自己把平时遇到的高频问题整理成了一张表遇到问题先对着表定位效率能提升几倍。现象可能原因排查路径解决办法单 GPU 训练奇慢其他正常光模块脏或者光纤弯曲过大ethtool -m 查看光功率和模块温度清洁光口、换线、调整布线半径所有 GPU 同时卡顿吞吐趋近于零PFC 死锁或队列缓存打满交换机上查 pause counter、queue statistics调整阈值、限制突发流量、重分布流量训练开始时快运行几小时后变慢光模块热漂移或交换机散热问题对比不同时段温度数据和 tc 丢包计数清理通风道、降低供电温度、换备用模块AllReduce 带宽远低于理论值网卡队列或 PCIe 拓扑不对NCCL 未走最优路径NCCL_DEBUGINFO 观察路径查 lspci 拓扑调网卡队列数量、调整进程绑定启用 GDR偶发重传时好时坏设备端口缓存不足或 FEC 失效长时间抓 ethtool -S 的 rx_crc_errors更换故障模块、确保同一速率和 FEC 模式这张表未必覆盖所有场景但训练网络的问题多数绕不开这五类。熟练之后你甚至会从“查网络”变成“查物理”省下的精力用来研究模型调优不香吗5. 两层架构的价值与借鉴不只是超大厂能这么干5.1 中小集群也要有“两层思维”有人可能会说10 万卡才需要两层我只有 200 卡跟我有什么关系我觉得恰恰相反。两层的核心不是“规模大”而是“路径短且可预期”。哪怕只有几十张卡如果你沿用三层的思路虽然也许不会立刻出事故但你在设计阶段就埋下了“路径长短不一”“核心瓶颈难拆”的隐患。小集群更现实的做法是提前按照 Leaf-Spine 的框架去做机柜规划和网络划分。比如 32 台 GPU 服务器分在 4 个机柜里每个机柜放一台 Leaf两台 Spine 做互联保证任意两台服务器之间的网络路径一致。等将来扩容到几百卡时你要做的只是加 Leaf、加 Spine而不是推翻重来。另一方面小集群也是验证新技术的最佳场地。像前面提到的 DLB、ECNPFC 参数、NCCL 调优技巧都可以先在小规模上做对照实验一点点把参数调明白等集群大了直接照搬成熟配置。我见过太多团队小集群将就着跑到大集群时发现一堆历史遗留问题最后全部重排。5.2 下一步演进多路径、远端内存和光交换OpenAI 把十万卡压到两层不代表这就是终点。在我看来训练网络下一步会往三个方向走。第一是真正的多路径和智能网卡联动。随着网卡侧可编程能力增强负载均衡会从交换机逐渐上移到端侧。GPU 网卡可以选择“主动测量哪条链路空闲”然后把数据发到更优路径上。两层网络高度等价的拓扑恰好是最适合这类端网协同方案的土壤。第二是远端内存池化。训练过程里经常出现显存不够用把部分状态卸载到远端内存。如果网络能提供更低的延迟和更大的带宽远端内存就能更“透明”地参与训练相当于把 GPU 的可利用显存扩大了。两层架构的短路径在这里价值巨大。第三是光交换的引入。目前 Leaf-Spine 之间还是电交换芯片做包转发未来可能引入光电路交换OCS让某两个 Leaf 之间的连接按需物理层直连。这样一来“网络压到两层”甚至“压到几乎零层”也未必不可能GPU 之间直接走光通路速度和延迟都会有质变。从行业趋势看训练网络越来越像是“算力的一部分”而不是独立的支撑系统。谁说网络工程师不是训练团队的一员呢至少在十万卡集群里网络掉链子的时候训练主管第一个找的就是你。最后再分享一个小经验别被“压到两层”这种说法唬住。它不是一个魔术而是把规模、成本、延迟、运维全部权衡之后的结果。你不需要真的拥有十万卡才能借鉴这一点——只要在设计网络的任何阶段优先让路径变短、让行为变可预期、让排查变简单你的集群就已经在“正确的方向”上了。