去年我自己规划一个多卡训练集群的时候被网络狠狠教育了一课。算力预算花了几乎一大半显卡堆得整整齐齐结果真正跑40B参数模型的通信阶段整体吞吐直接掉了一大截。后来跟几个做数据中心网络的朋友复盘结论特别扎心不是卡不够多是网络层次太多、拥塞点太隐蔽。所以当我有段时间反复看到OpenAI 把 10 万 GPU 训练网络压到两层这类讨论时立刻来了兴趣。10万卡和两层网络放在一起听着像极简方案实际上背后是整个超大规模GPU计算基础设施里最难啃的骨头。这篇就从一个普通从业者的视角拆一拆这件事到底在解决什么问题、要满足哪些硬条件、又会踩哪些坑。我会尽量给出可计算的推演过程而不是停留在好厉害的感叹上。无论你之后是要了解千卡集群的设计思路还是自己组几十卡的小平台这里面的逻辑都是通用的。1. 两层网络不是拓扑缩写它到底压缩了什么很多人听到两层会以为就是少一层交换机像极了把三层办公室改成两层小楼。但训练网络里的层数压缩本质上是把通信路径和故障爆炸半径一起压扁。要理解这一点得先回到训练网络的流量特征。1.1 训练网络跑的流量和互联网完全不同大模型训练的网络流量主要由三类组成每种都非常考验网络设计AllReduce流量数据并行训练里每个GPU算出梯度之后需要对全局梯度做求和与广播。卡数越多AllReduce的流量越大而且它是严格同步的任何一条链路延迟变高所有卡都得等它。All-to-All流量MoE模型、序列并行、专家并行这些场景里每个节点都要和集群里所有其他节点交换数据。通信量随节点规模呈近似O(N²)增长10万GPU就意味着千万级节点对之间都有通信需求。参数与状态同步流量优化器状态、embedding表、日志和checkpoint备份虽然单次流量没那么爆炸但长时间训练里累计量非常大。最要命的是这些流量不是均匀分布在网络上的。训练过程通常被切到极细的粒度每经过一个micro-batch就产生一轮全局通信。一瞬间所有GPU同时朝不同的方向发数据这就是典型的incast拥塞在两层扁平的大局部网络里拥塞会被放大很多倍。1.2 三层胖树为什么扛不住10万卡规模传统数据中心网络为了保证带宽通常采用Fat-Tree架构也就是三层Clos核心层、汇聚层、接入层。三层结构的问题在于核心层交换机的故障影响面极大一旦核心设备抖动底下成千上万个GPU的流量全部遭殃。数据从源GPU到目标GPU最多要经过六跳每跳都有缓存和调度延迟和缓冲占用都很可观。汇聚层和核心层之间的带宽要做到1:1收敛等于光模块和线缆数量翻倍成本指数级上升。所以当集群规模到万卡甚至十万卡时设计者会想尽办法缩短路径。最好的情况是从任何一个Leaf交换机到另一个Leaf交换机只经过一跳Spine整个网络从物理上就是两层。1.3 压层的三种真实含义我观察到的行业共识里把10万GPU网络压到两层并不是单一做法而是几条技术路线合在一起拓扑扁平化去掉汇聚层直接采用Leaf-Spine两层Clos。靠交换机端口密度把规模撑上去所有跨Leaf流量只经过一个Spine。逻辑一跳化靠光交换机这类硬件把物理链路快速重连网络拓扑可以随业务动态调整GPU通信在逻辑上几乎一跳直达。计算下沉化把部分AllReduce等通信操作卸载到交换机或网卡上在网络中间就把梯度合并减少进入Spine的流量总量。这三条路线其实可以叠加。所谓压到两层最终压缩的不只是设备层数更是每条消息的跳数、等待队列数、故障排查路径数。下面我用实际的端口数学来算算10万卡塞进两层到底有多苛刻。2. 端口数学10万GPU装进两层要满足的硬条件两层能不能装下10万GPU不是拍脑袋说的完全能用交换机的端口数算出来。这一节我给你一套可复现的计算逻辑你以后规划任何规模集群都能直接用。2.1 Clos两层拓扑的容量公式假设统一采用Leaf-Spine两层结构每个Leaf交换机有若干下行端口接GPU服务器有若干上行端口接Spine。每个Spine交换机的端口用于连接全部Leaf。如果每台Leaf的上行链路都连接到不同的Spine那么可挂的Leaf数量最大值是由Spine的端口数决定的。具体说当Spine端口数为P_spine时最多支持P_spine台Leaf每个Leaf占用每个Spine的一个端口。这时总接入端口数约等于总接入服务器端口数 P_spine × D_leafD_leaf是每个Leaf的下行端口数。如果一台服务器放G张GPU那么总GPU数总GPU数 P_spine × D_leaf × G这个公式看起来简单但它隐含了一个强约束Leaf的总上行带宽要和下行带宽匹配。要1:1收敛每台Leaf的上行端口数必须不小于下行端口数。所以一台128端口的Leaf如果做64口上行、64口下行它的D_leaf就是64。2.2 算一算128端口和256端口的差别我先用几组常见端口密度做推演Spine端口数Leaf端口数单Leaf下行口单节点GPU数可容纳GPU数是否能到10万1286432832768否12812864865536临界256128648131072是2562561288262144富余这个表说明一个很直接的事实传统64端口到128端口的交换机做两层网络最多只能撑到3万到6万卡的规模距离10万有明显的缺口。只有当Spine达到256端口级别、Leaf也保持较高的下行密度时两层的物理容量才真正覆盖10万卡。这也解释了为什么大家最近都在关注800G端口和共封装光学。没有更大端口密度的交换机10万卡两层只能是画饼。你也可以用一个很短的Python脚本自己跑一遍def capacity(spine_ports, leaf_ports, uplink, gpus_per_node8): downlink leaf_ports - uplink leaf_count spine_ports gpu_total leaf_count * downlink * gpus_per_node return gpu_total print(capacity(256, 128, 64)) # 131072 print(capacity(128, 128, 64)) # 65536 print(capacity(256, 256, 128)) # 2621442.3 Multi-Rail是两层方案的实际救星上面表格里有个被忽略的细节一台8卡服务器如果只靠一根高速网线上行单卡带宽会被压得很低。真实超大规模GPU集群基本都会做Multi-Rail也就是服务器上插多张网卡分别接到不同的Leaf交换机。Multi-Rail带给两层的价值有两个把单节点的通信带宽从单卡400G撑到8卡3200G甚至更高缓解单链路压力。让流量的路径选择更多降低特定链路的热点概率。代价是交换机端口消耗成倍增加线缆和光模块数量也跟着涨。所以10万卡两层方案里真正的主力往往不是每卡一根线而是每卡一个端口、多轨并行。这又回到了光模块数量的问题后面第四章细说。2.4 收敛比选择是取舍不是玄学收敛比1:1当然是最理想的但成本也最高。实际部署里常见的是1.5:1甚至2:1上收敛。收敛比越接近1拥塞越少但交换机和光模块成本越高收敛比越高网越便宜但训练性能对流量调度策略越敏感。从公开资料看业界主流超大集群通常不会把收敛比放到超过2:1因为LLM训练的通信太密集收敛比一旦放大训练效率损失会迅速暴露。具体选择多少要看模型通信占比和单机带宽。3. 压层之后真正的战场拥塞、故障与恢复物理结构压扁只是第一步。两层网络把问题从路径多、跳数多转移到了单跳内流量巨大、控制复杂所以真正的技术含量在拥塞控制和故障恢复上。3.1 Incast流量是怎么把两层网络打死的训练场景里最常见的拥塞是incast很多GPU几乎同时向同一个GPU或同一组GPU发送数据目的端的端口缓存瞬间被击穿。如果是三层网络每一层的缓存还能分摊一点压力压到两层之后中间只有Spine一层缓存深度和调度能力就特别关键。这就像早高峰所有地铁都涌向同一个换乘站你只有两个站台那只能拼命优化进站和疏导逻辑。网络里的疏导逻辑就是ECMP、动态路由、拥塞控制协议。3.2 ECMP为什么失效Adaptive Routing为什么出现传统数据中心用ECMP把流量散到多条等价路径上但ECMP是按五元组哈希的只适合大象流数量不多的情况。训练网络里大量是短小的同步消息和持续的大规模全互联流量哈希稍不均匀某一条Spine链路就会被打满而旁边的链路闲着。应对方案是动态路由感知。业界已经在用类似自适应路由的技术交换机实时感知出端口队列长度把流量引导到更空闲的路径上而不是死板地按哈希转发。这样能在拥塞发生前就绕开而不是等拥塞发生了再丢包重传。这里要特别说一句InfiniBand和RoCEv2走的路子不太一样。InfiniBand有更严格的流控和自适应路由机制尾部延迟低RoCEv2是在以太网上跑RDMA成本低、生态通用但需要额外调PFC、ECN这些机制调不好容易出PFC风暴整个网络的优先级流全部被堵死。机制原理优点风险PFC接收端暂停帧反压上游实现简单硬件支持广可能引发死锁和风暴ECN/DCQCN交换机打标记端侧降速端到端反馈相对平滑参数多需要细调Adaptive Routing动态选路绕开拥塞路径实时性好链路利用率高对交换机芯片要求高网内聚合(SHARP-like)在交换机上直接做聚合大幅减少上送数据量需要专用硬件和编译支持3.3 网内聚合让压层从物理方案变成协议方案NVIDIA SHARP这类网内聚合技术是在交换机的转发流程里直接做梯度规约。原来8个GPU的梯度要全部上送到某个节点做AllReduce现在数据经过交换机就把能合并的梯度合并了上送的流量理论上可以减少到一条消息的量。网内聚合本质是把计算往网络里塞让网络从纯粹搬数据变成边搬边算。这对压层是极大的助攻因为即使物理拓扑还是两层真正进入Spine的有效流量也在大幅减小。等于把带宽需求从物理上降下来了。不过要泼一盆冷水网内聚合的前提是收集和交换设备支持而且对不同并行策略的适配复杂像MoE这种动态性很强的流量聚合收益并不稳定。所以它不是通用银弹而是专门优化某几类通信模式的利器。3.4 算力侧也在参与NVLink域与Scale-Up网络这两年还有一个绕不开的方向把Scale-Up域变大让GPU之间的高速互联不再完全依赖集群网络。NVLink域从单机8卡扩展到GB200 NVL72这种整机柜72卡互联配合NVLink-over-Fabric还能让跨机柜通信走更简化路径。这样一来很大一部分通信留在超高速的Scale-Up网络里流向集群网络的总流量减少两层Spine-Leaf的带宽压力就小了很多。站在更高的维度看10万卡两层方案其实是算力网络协同的产物拓扑层压层、计算层下沉、互联层扩大域几件事合在一起才让两层变得可行。4. 硬件与物理账百万光模块和多兆瓦的代价讨论架构时常有一种错觉觉得网络就是一堆黄色的线。但10万GPU规模下物理层的复杂度和成本可能超过绝大多数人的想象。4.1 光模块数量一个反直觉的统计假设10万GPU全部走两层Leaf-Spine网络每块GPU一块网卡接入Leaf上行带宽按1:1估算Leaf和Spine之间的链路数大约也是10万量级。算上Leaf到服务器的接入链路整个集群的网线/光模块端口数会超过20万如果再算上备份、测试、预留光模块数量逼近百万不是夸张说法。百万个光模块是什么概念哪怕单个模块均价几千块光是这部分就是一大笔开销。更何况每个光模块都有固定故障率百万个设备每天坏几十个都正常。这让我想起一个比喻这不是网络这是一个每隔几分钟就会亮一次故障红灯的巨型圣诞树。4.2 功耗与机房形态再算功耗。一个800G光模块功耗大概在15到20瓦百万个光模块就是15到20兆瓦。加上交换机本身的转发功耗、散热损耗、备用电力一个训练集群的网络子系统单独吃掉的电力可以养活一个小型工厂。所以真实的大规模集群里网络机柜经常和GPU机柜混合部署目的就是缩短光缆距离、减少光模块功率、降低布线复杂度。把Spine交换机放在机房中间用预缀的光纤配线架连接各个GPU机柜这是大规模集群组网的常态。4.3 故障爆炸半径是设计出来的两层拓扑有一个绕不开的短板Spine故障的影响面巨大。如果Spine数量不够多一台Spine故障直接让很多Leaf之间的跨节点通信中断正在训练的模型可能整体失败。解决思路通常有三层第一层网络层面做快速故障收敛比如BGP/Link State毫秒级重收敛或者NVIDIA UFM/Lid路由重新计算。第二层训练作业层面做故障容忍让框架能感知网络故障并自动拉起掉线的节点这在超大规模训练里已经变成标配。第三层拓扑设计时故意留冗余带宽即使部分Spine失效剩余路径的收敛比依然可以支撑训练不中断。我自己实际体会是第一层和第三层最容易被人忽略。很多团队觉得买了A级交换机就一定可靠结果机柜电源抖动一下整个训练任务就白跑了几个小时。冗余不是给硬件留的是给不确定性留的。4.4 运维监控该盯哪些指标两层网络比三层结构简单但监控指标一点都不少。我建议至少把这些数据接到统一的dashboard指标类别具体指标说明细颗粒度拥塞队列深度、ECN标记率、重传率重点看训练流量发生时段通量流完成时间FCT、P99延迟同步通信的网络健康表性能对齐GPU利用率与网络利用率叠加判断是算力瓶颈还是网络瓶颈故障面光模块丢包率、链路翻转次数、温度提前发现光模块劣化这里最值得看的是GPU利用率和网络利用率的关联曲线。很多网络问题在平均利用率上看不出来只有和训练性能叠加才能发现那一刻有一两个链路把全局拖慢了。这个对比维度比单纯看丢包率有效得多。5. 小规模集群迁移两层架构的实战心得你可能不会去搭10万卡集群但把网络层次压扁的思路放到几十卡、几百卡的规模也一样适用。这一章分享几个我在自己环境里验证过的经验踩过坑也说点掏心窝的话。5.1 第一件事不是买交换机是模拟路由和流量我自己一开始犯的错就是急着看硬件规格忽略了自己业务真实的通信模式。后来用Python把模型并行度和通信矩阵算了一遍才意识到MoE模型的流量发散性远超预期。建议你先自己写个脚本把你模型的通信模式模拟到网络拓扑上看看每条链路的预期负载。工具用common的network simulator或者简单的Python队列模型都行。这一步花半天时间可能省下后面几个月的排障时间。5.2 固件和驱动版本必须全链路对齐RoCEv2和InfiniBand对版本一致性非常敏感。我遇到过一种典型情况网卡固件新一版交换机固件低两个版本PFC协商不正常集群一个训练任务跑完重传数据量多到惊人。后来我定了一个规矩任何网络变更都先列一张完整清单交换机固件、网卡固件、驱动、OS发行版、BIOS里PCIe和中断设置全部对齐到一个经过验证的基准组合再谈性能调优。5.3 别高估单台交换机的可靠性也别低估控制面的压力两层网络里Spine设备就是核心中的核心但它仍然是电子设备。我见过一台崭新的交换机在高峰期因为固件bug直接重启导致三百多卡同时掉线。从那以后我做任何集群都会提前部署好自动重训练机制网络层和作业层双保险。另外控制面CPU在高负载翻转时很容易被忽略。训练流量大、BGP邻居多时交换机的CPU可能因为路由计算或者遥测上报过载而丢包。选型时不要只看转发容量也要看控制面规格和遥测上报频率是否可调。这个细节在厂商spec表里经常不显眼但生产环境里非常关键。5.4 如果重新做一次我会把checkpoint和恢复放在和网络同等重要的位置网络压层以后单个故障对训练的影响会更直接。真正保证训练不中断的除了好的网络设计还有快速checkpoint和快速恢复。两条腿走路才能在十万卡这种规模下保持高可用。很多网络排障的文章都只教你修链路没人提醒你提前准备好链路坏了之后的逃生通道。这可能是所有经验里最值钱的一条。回到开头那句话。10万GPU训练网络压到两层表面上看是拓扑优化实际上是一整套关于带宽、拥塞、故障、功耗、成本的计算与妥协。我自己做完一轮推演和实测之后最大的感受是网络从来不是越复杂越好而是越匹配业务越好。能够用两层解决的绝不多加一层但每一层简化都必须用更精准的监控和更健壮的训练机制去补齐稳定性缺口。
