1. GPU集群网络的大账与小账：端口配比和收敛比才是瓶颈
1.1 为什么GPU训练流量比普通业务流量“横”得多
接手奇点算力云网络架构那段时间，最让我头疼的就是选型表上的一个数字：收敛比。销售说2:1最合理，运维说3:1省钱，算法团队张口就要1:1。我花了两周时间把GPU集群的通信流量模型和交换机端口关系彻底理了一遍，才算搞明白大家争的其实不是同一个东西。
传统数据中心的业务流量是稀疏、异步的，网页请求、视频点播、数据库查询这些流量，长时间平均带宽利用率很低，峰值也是零散的。很多传统网络敢用10:1甚至更高的收敛比，因为绝大多数时候链路根本占不满，超卖一点不影响体验。但GPU集群完全不是这个套路，训练任务跑起来之后，每个迭代周期都会产生一轮集合通信，比如数据并行训练里最常见的AllReduce，所有计算节点在算完梯度后需要把结果汇总分发。这个操作的特点是“周期短、强度大、多对一并发”，几十个节点同时往同一目标节点灌数据，交换机的瞬时压力远高于平均流量。
这个现象有个专门的词叫Incast，它才是GPU集群网络真正的敌人。如果TOR到Spine的上联带宽不够，交换机队列会在一瞬间被打满，接着丢包、重传、流控风暴接踵而至。RoCEv2网络里一旦触发PFC暂停帧，影响面会顺着链路扩散，整个训练迭代可能从2秒被拖成10秒。这就是为什么GPU集群的收敛比设计不能拍脑袋，必须从流量模型出发，把钱花在最容易拥塞的那段路上。
1.2 端口配比、收敛比到底怎么算
先明确两个基础概念。端口配比指的是交换设备上不同方向端口数量的分配关系，比如一台TOR有多少口接服务器，多少口上联到Spine。收敛比则是带宽层面的比例，计算方式是接入侧总带宽除以上联侧总带宽。
可以拿高速公路来类比：每个GPU服务器网卡相当于上了匝道的车流，TOR的下行口是匝道口，TOR到Spine的上联口是主路入口。如果三条匝道汇入一条主路，那收敛比就是3:1。这个比例越低，意味着主路越宽、越不容易堵车，但成本也越高。
有一点必须提醒：口数比例不等于带宽比例。现在400G端口常常会被拆成2×200G使用，如果服务器侧用的是200G光模块，一台64口的交换机上拆成80个200G端口用，那收敛比的计算就不能直接数口数，而是要把带宽统一折算后再算。奇点算力云内部做方案时，有一个强制性要求：所有端口配比表必须先折算成带宽，再谈收敛比，否则后续很容易出现“口数看着对，跑起来就堵”的问题。
2. 从一台8卡服务器出发：单TOR端口占用推演
2.1 典型8卡服务器的网络出口结构
要算端口配比，得从单台服务器开始。现在主流的8卡GPU服务器，网络出口普遍配置是3个400G端口，跑RoCEv2无损网络。为什么是3个而不是4个？因为服务器内部8张卡已经通过NVSwitch组成NVLink全互联域，卡与卡之间的通信不需要走外部网络，外部网络只需要承载跨机通信流量。一张PCIe 5.0加速卡能提供的通道数量有限，插4张400G网卡会出现PCIe带宽争抢，实际收益很小；3×400G能让跨机带宽达到1.2Tbps，在绝大多数训练任务里已经能覆盖跨机通信需求。我实测过4×400G的配置，训练吞吐提升不到10%，网络成本却增加了三分之一，不值当。
这个3口配置直接决定了TOR下行的端口消耗模型：每接入一台GPU服务器，就要吃掉3个下行口。很多人设计网络时习惯按“一台服务器一个口”的传统思路去算，放到GPU集群里会差出三倍，这是端口配比最容易算错的地方。
2.2 TOR端口的“收支平衡”：下行、上联与预留
以一台64口×400G的TOR为例，所有口都是数据口，但我们不能把所有口都拿去接服务器。因为TOR的职责不只是接入，它还要把流量汇聚后送往上层的Spine交换机。假设单台TOR接入N台服务器，每台服务器占3个下行口，上联口数设为S，再预留M个口做管理、堆叠或监控，就有一个基本的约束关系：
3N + S + M ≤ 64
收敛比C = 3N / S
这就是整个端口配比计算的核心公式。看起来很简单，但真正做方案时你会发现，这个公式和交换机端口数量、Spine规模、训练任务类型搅在一起，会演化出很多值得推敲的组合。比如常见的64口TOR，如果M取1口管理、上联16口，那么可用的下行口是64-16-1=47口，47口最多能接15台服务器，占45口，还剩2口空着。这2个空口看似浪费，实际是给堆叠、突发流量和未来扩容留的缓冲。
很多人第一次看到TOR有空口却不接服务器会不理解，为什么要让端口闲着？答案在于全网视角。TOR的下行口接得越满，上联压力就越大，如果上联口数不变，收敛比会被拉高，拥塞风险就上去了。端口配比必须站在整网角度看，单看一台TOR的空闲口没有意义。
3. 三种收敛配比的完整推演与选型判断
3.1 3:1近似方案：上联16口、下行45口
把上面的公式代进实际方案。第一种是3:1近似方案，上联口S=16，管理/预留口M取3，剩下45口全部作为下行口，接入15台服务器。15台服务器×8卡=120卡，这就是一个TOR能承载的GPU卡数。
实际收敛比是多少？45口下行带宽除以上联16口带宽，得到2.8125:1。严格说不是3.000:1，但工程上已经足够接近。为什么不直接把上联取15口来凑更整齐的数字？因为15是奇数，TOR的16个上联口需要平均分配到两台Spine交换机上，每台分11口是不对称的，奇数上联口在冗余设计里非常难受。这是端口配比设计里一个很容易被忽略的细节：上联口必须优先考虑偶数。
这个方案的优点是单TOR承载卡数最多、Spine端口利用率高，适合中小规模训练集群和研发测试环境。它的短板也明显，一旦出现强Incast流量，2.81:1的收敛比会让TOR到Spine之间成为瓶颈。
3.2 2:1近似方案：上联22口、下行39口
第二种是2:1近似方案，上联口S=22，管理/预留口M=2，剩余39口做下行，可接13台服务器，单TOR承载104卡。实际收敛比39/22≈1.77:1，比标称的2:1略好一些，多出来的一点带宽相当于给突发流量留了裕量。
这个方案是我在奇点算力云常规训练集群里用最多的。它的好处在于：对于数据并行训练为主的任务，1.77:1的收敛比已经能覆盖绝大多数AllReduce通信窗口的峰值压力；同时单TOR承载104卡，比1:1方案高出30%，网络成本可控。
3.3 1:1方案：上联30口、下行30口
第三种是严格1:1方案，上联口S=30，管理/预留口M=4，剩余30口做下行，只能接入10台服务器，单TOR承载80卡。TOR一半的端口要拿去上联，端口利用率低得让人心疼。
从性能角度看，1:1确实能最大程度降低跨机通信瓶颈。但从成本角度看，它是三种方案里最贵的。很多用户迷信“1:1无阻塞”，实际上所谓1:1只是接入层与核心层的上下行带宽相等，并不表示整网在任何时刻都没有拥塞。多对一的Incast流量照样会在某些端口上瞬时拥塞，只是拥塞概率和持续时间会明显降低。如果业务对通信时延极其敏感，比如大模型训练里的AlltoAll通信占比很高，1:1才有它的价值。
3.4 三种配比对比表
我把三种方案的完整推演结果整理成一张表，方便直接对照：
| 方案 | TOR上联口数 | TOR下行口数 | 可接服务器数 | 单TOR承载GPU卡数 | 实际收敛比 | 单对Spine可挂TOR数 | 单对Spine总容量 | 每卡占用Spine端口数 |
|---|---|---|---|---|---|---|---|---|
| 3:1近似 | 16 | 45 | 15 | 120 | 2.8:1 | 8 | 960卡 | 0.13 |
| 2:1近似 | 22 | 39 | 13 | 104 | 1.8:1 | 5 | 520卡 | 0.21 |
| 1:1 | 30 | 30 | 10 | 80 | 1:1 | 4 | 320卡 | 0.38 |
注意看最后一列，每卡占用的Spine端口数，1:1方案是3:1方案的近3倍。这意味着同样承载1000卡的集群，3:1方案可能只需要一对Spine，1:1方案需要三对以上，光模块和线缆成本同步翻倍。这就是收敛优化真正的经济账：低收敛比是用更高的网络成本换来的，不是白送的。
4. Spine层端口规划：从TOR上联到整个Pod规模的完整计算
4.1 一对Spine能带多少TOR
TOR层的端口分配算清楚之后，还要往上一层看Spine。假设同样使用64口×400G的交换机作为Spine，两台组成一个Spine对做冗余。TOR的S个上联口会平均分配给两台Spine，每台Spine被占用S/2个口。那么一对Spine能挂的TOR数量P为：
P = 64 / (S/2)
拿前面三种方案代入：
- 3:1近似方案，S=16，每台Spine被占用8口，P=8，一对Spine带8台TOR，总共960卡
- 2:1近似方案，S=22，每台Spine被占用11口，P=5（余9口），带5台TOR，总共520卡
- 1:1方案，S=30，每台Spine被占用15口，P=4（余4口），带4台TOR，总共320卡
这个计算结果很反直觉：收敛比越高的一侧，反而能让Spine带更多TOR，从而支撑更大的Pod规模。原因很简单，TOR上联口少，对Spine端口消耗就少。这也是为什么很多大规模训练集群宁可使用3:1或2.5:1的收敛比也不做1:1，因为1:1会让Spine层的端口消耗急剧膨胀，整网规模做不上去。
4.2 每卡Spine端口成本：1:1贵在什么地方
上面表格里的“每卡占用Spine端口数”已经直观展示了成本差异，这里再拆开讲一下。3:1方案里，一对Spine提供128个端口，能服务960卡，摊到每卡只有0.13个Spine端口；1:1方案里，一对Spine服务320卡，摊到每卡0.38个端口。换句话说，1:1网络下每块GPU需要多占用0.25个Spine端口，按1000卡集群算，多出250个Spine端口，对应的就是多台Spine交换机、数百个光模块和大量布线。
400G光模块的价格不便宜，一个端口的成本往往包含交换机端口、光模块、线缆、运维多个维度。设备采购时交换机端口单价看着不高，但乘以300个端口，差距立刻就是几百万预算。奇点算力云在做成本测算时，从来不只看交换机台数，而是把“每卡网络端口成本”作为核心指标，因为这才是真正反映收敛设计经济性的数字。
4.3 大集群扩容：上联口怎么散布到多个Spine对
当集群规模超过单对Spine的容量时，就需要增加Spine对数。这里有一个设计自由度：同一台TOR的16个上联口，可以全部连到一对Spine，也可以拆开连到两对甚至四对Spine。后者能有效降低单台Spine上的并发压力，给每个训练任务提供更宽的上行通道。
实际操作中，我们会按训练任务做分区隔离。比如两对Spine分别承载不同的业务区域，让一个大模型训练任务尽量落在同一个Spine区域下，减少跨区流量。跨区流量一旦出现，会走Spine之间的链路，这部分带宽非常昂贵。端口配比设计不只是静态计算，还要结合任务调度逻辑来考虑，这也是“收敛优化”里偏运维层面的内容。
5. 收敛优化的关键不在口数，而在流控和路由
5.1 RoCEv2无损网络：PFC和ECN各司其职
收敛比算得再漂亮，如果无损网络配置不到位，GPU集群照样跑不出性能。RoCEv2网络里有两个必须同时关注的机制：PFC和ECN。
PFC是链路级的优先级流控，它通过暂停帧防止交换机缓冲溢出丢包。问题是PFC一旦触发，可能引发队头阻塞，一个队列被暂停，同一个端口上其他队列的数据也会被堵住。ECN则是端到端的拥塞反馈机制，交换机的队列深度超过阈值时，会在报文上打ECN标记，网卡收到标记后自动降速，从源头上减少流量注入。打个比方，PFC像是高速公路入口的临时封闭，ECN则是在入口就提示司机减速，前者是被动应急，后者是主动预防。
奇点算力云的配置经验是：ECN的阈值必须根据实际队列深度反复调，阈值设得太低，网卡频繁降速，吞吐反而下降；设得太高，ECN还没来得及介入，PFC已经触发了。这两者必须协同工作，再加上网卡侧的DCQCN拥塞控制算法，整条链路才算真正“无损”。
5.2 哈希不均和自适应路由：收敛比之外的隐性瓶颈
很多性能问题的根因不是收敛比不够，而是哈希不均。传统ECMP按五元组哈希做负载均衡，对RDMA流的效果很一般。因为RDMA流的数量和持续时间与TCP完全不同，哈希因子设置不当，会出现大量流被塞到同一条链路，其他链路却空着的情况。我在实际项目里见过一个典型案例：训练跨机带宽只有理论值的60%，查了一圈，发现两台TOR的上行流量被ECMP哈希到了同一个Spine端口，形成单点瓶颈，其他端口利用率不到20%。
解决这类问题，最有效的手段是开启交换机的动态负载均衡或自适应路由，不同厂商叫法不一样，但原理类似：交换机能感知队列延迟和链路负载，动态把流量分摊到更优的路径上。如果你的交换机不支持这类功能，就需要花很多精力去调哈希因子，但效果终究有限。所以选型时，支持DLB或自适应路由的交换机，对GPU集群的价值远高于单纯的口数规格。
5.3 用监控数据定位真正的拥塞点
网络调优不能靠感觉，必须有数据支撑。我们部署了一套基于交换机telemetry的监控体系，重点盯几个指标：ECN标记包比例、PFC暂停帧计数、端口利用率与理论吞吐的比值。
ECN标记包比例升高，说明队列已经接近拥塞边缘，是带宽吃紧的早期信号；PFC暂停帧持续增加，说明缓存已经填满，链路正在过载；端口利用率很高但实际吞吐很低，则多半是哈希不均导致的问题。这几个指标组合起来看，基本能定位到拥塞点到底是在TOR下行、TOR上联，还是Spine之间的链路上。我建议所有做GPU集群运维的团队都建这么一套监控看板，它比任何静态的计算表格都更能反映真实运行状态。
6. 奇点算力云的实践方法：不做极端，做贴合场景的收敛设计
6.1 不同规模集群的端口配比参考表
考虑到不同规模、不同业务的集群对收敛比的需求差异很大，我把奇点算力云在多个项目里沉淀出来的参考配置整理成一个速查表，方便直接抄作业：
| 集群规模 | 推荐收敛比 | TOR上联口数 | 单TOR承载卡数 | 适用场景 |
|---|---|---|---|---|
| 16~32卡研发测试 | 直连或3:1 | 8~16 | 80~120 | 单机多卡调试、小模型训练 |
| 128~256卡 | 3:1或2.8:1 | 16 | 120 | 常规模型训练、微调 |
| 512~960卡 | 2:1左右 | 22 | 104 | 大规模训练、多任务共享 |
| 1000卡以上 | 热点区1:1，普通区2:1 | 按分区定制 | 按分区定制 | 大模型预训练、MoE模型 |
第4行是我们的核心思路：不做全网1:1，而是把集群分成“热点区”和“普通区”。热点区给MoE、大模型预训练这类高通信压力任务，配置1:1；普通区给微调、推理等对带宽没那么敏感的任务，配置2:1。这样既保证了关键任务的性能，又不至于让整网成本失控。
6.2 部署时容易忽略的几件事
再分享几个部署阶段特别容易踩坑的点。
第一，光模块和Breakout模式。400G端口拆成2×200G使用时，交换机的端口密度会按拆分后计算，原本64口变成128个200G口，但带宽总量不变。这种模式下，端口配比公式里的“口数”必须用200G逻辑口重新数，否则算出来的收敛比是虚的。
第二，管理网和存储网一定要跟RDMA数据网分离。如果把日志、监控、存储备份流量混进RDMA网络，它们会抢占队列和缓冲，干扰无损网络的流控机制。轻则性能波动，重则PFC风暴。
第三，网卡固件和交换机参数必须配套验证。不同厂商网卡的DCQCN默认参数差异很大，直接套用同一套交换机配置，很可能出现网卡不降速或者降速过猛的情况。我们每次上线新集群都会做一轮全链路流控测试，用打流工具灌满带宽，观察ECN标记和PFC暂停帧是否符合预期。
6.3 我们的最终方案与长期取舍
经历过几次集群交付和问题排查之后，奇点算力云最终采用的是“基础2:1 + 热点任务1:1分区 + 自适应路由兜底”的混合架构。从运营数据看，训练任务普遍能达到理论带宽的85%以上，网络成本比全网1:1方案节省了四成左右。省下来的钱投到更多的GPU卡上，对客户来说算力供给更充足，对平台来说整体吞吐更高，这才是收敛优化的真正意义。
最后再分享一个我自己的实操经验：做新集群方案时，别急着选交换机型号和端口数，先拿一张纸把服务器型号、单机网卡数和训练任务类型列清楚，用前面那套公式把端口配比和收敛比推演一遍，确认成本与性能的平衡点，再去看硬件参数。网络这东西，数字算明白了，后面能省掉大量排障时间。
