先说一个我这两年的观察但凡稍微上点规模的大模型训练集群网络选型基本就两种声音一种是“无脑上IB”一种是“RoCE调好了也能打”。但真到万卡、几万卡阶段绝大多数团队最后还是摸回了InfiniBand。这篇文章不劝你买设备也不站队吹牛就纯粹聊聊我在实际集群里看到的IB和RoCE的差距以及为什么大模型这个特殊场景下IB几乎成了默认答案。先给不熟的读者垫个底InfiniBand简称IB和RoCERDMA over Converged Ethernet基于融合以太网的远程直接内存访问都是支持RDMA的高性能网络方案。RDMA的意思是网卡可以直接读写对端机器的内存不用经过CPU和操作系统协议栈延迟能到微秒级。大模型训练恰恰是个极度依赖节点间通信的场景所以网络选型直接决定了训练效率的上限。这篇文章适合三类人一是正在搭训练集群的基础设施工程师想搞清楚IB和RoCE到底差在哪二是做AI平台选型的技术负责人需要给预算和性能找一个平衡点三是对高性能计算感兴趣、想理解底层网络逻辑的开发者。我会把两者的底层机制、我在实际部署里踩过的坑、以及NCCL这类通信库在网络选型里的隐性影响一起拆开讲。1. 大模型训练为什么被网络卡脖子1.1 千卡万卡并行训练通信开销不再是小事很多人对分布式训练的理解停留在“把数据切成几份分给多张卡算”听起来很简单但实际上模型并行、数据并行、流水线并行交织在一起时通信的复杂性会远超想象。以最常见的3D并行数据并行张量并行流水线并行为例每一个训练step里都要做多次AllReduce、AllGather、ReduceScatter等集合通信操作。我一个很直观的感受是如果网络带宽不够哪怕GPU利用率显示99%训练吞吐也会被通信拖得很低因为GPU大部分时间不是在算而是在等数据。之前在8卡机内做数据并行靠PCIe或NVLink尚能应付但一旦跨节点网卡就成了唯一通道。一个70B参数规模的模型光参数同步一次就可能需要传输几百GB到TB级的数据节点越多通信占比越大网络就彻底变成了瓶颈。Timeline上随便看一眼都能发现通信算子动辄占整个step时间的20%~40%。这不是某一家公司的问题而是所有大模型集群的共同现象这也是为什么InfiniBand能在AI集群里占据主导地位的根本原因AI训练已经把通信从“辅助环节”变成了“关键路径”。1.2 网络丢包对训练有多致命我曾经调整过一批以太网交换机参数做RoCE测试看似一切正常但训练起来就是不稳定。仔细观察后发现问题是PFC优先级流控和ECN显式拥塞通知参数的细微配置差异导致偶发丢包就是这么“轻微”的丢包让NCCL的AllReduce性能直接掉了一半以上。为什么丢包这么严重核心原因是RDMA通信依赖无损传输。普通TCP丢了包可以重传但RDMA的设计目标是最大化吞吐和最低延迟一旦丢包重传机制的成本非常高而且因为需要等待超时来发现丢包整个通信会瞬间陷入停顿。NCCL内部处理丢包的逻辑相对简单它不会像TCP那样做复杂的拥塞控制而是直接等待超时重传大规模的丢包会导致通信链路瘫痪训练进程卡死甚至触发集合通信库内部的超时机制导致整个任务直接失败。这也是为什么在AI训练集群里“无损网络”不是一个可选项而是一个必选项。IB天生就是无损的RoCE则必须依赖以太网生态里的PFC、ECN等机制来模拟无损这个“模拟”的过程就是后期所有麻烦的根源。2. IB和RoCE的底层路线之争2.1 IB从HPC时代就是“无损网络原生设计”InfiniBand最初是用于高性能计算HPC领域的互连方案它跟以太网最大的不同在于IB从协议设计上就构建了一整套完整的有损控制机制。IB子网里的交换机温度、缓存、流控都是统一管理的不需要额外协议去“模拟”无损而是硬件自身就能做到端到端的credit-based流控。打个比方IB更像是一个设计时就充分考虑交通拥堵的高速公路系统每个入口都知道匝道上能放行多少车匝道和主线之间用实时信用机制协调从源头避免堵车。而RoCE更像是在普通城市道路上临时添加红绿灯和限行规则能改善拥堵但很难做到完全不出问题。除此之外IB还有一些对于大模型训练非常关键的高级特性自适应路由Adaptive RoutingIB交换机可以根据实时拥塞情况动态调整包的转发路径而传统以太网多路径主要是基于哈希一旦哈希冲突严重个别链路的负载会突然飙升导致局部拥塞和丢包。多路径传输大模型训练通常是同构的“大象流”哈希分配很容易造成链路不均衡IB的多路径机制能把流量打散到更多条物理链路上充分利用带宽。网络计算能力如SHARPIB交换机可以在网络内部完成部分集合通信操作比如AllReduce的求和可以“在交换机里算掉一部分”大幅减少网络流量和延迟。这一点对大模型训练尤其关键因为AllReduce是所有模型并行策略里最频繁的操作。2.2 RoCE让以太网也能跑RDMA的妥协方案RoCE的全称是RDMA over Converged Ethernet它的诞生逻辑很直接把RDMA的能力搬到以太网上这样用户不需要更换交换机、网卡就可以享受RDMA带来的低延迟和高吞吐。RoCEv1只能在二层网络里跑RoCEv2则通过UDP封装支持三层路由所以可扩展性好了很多。但从根本上看RoCE处理的仍然是以太网帧所以它必须依赖外部机制来避免丢包PFC优先级流控当交换机某个端口收到过多流量时会向对端发送暂停帧让对方暂时停止发送。这个机制如果配置不当很容易引发“队头阻塞”或PFC死锁甚至波及无关流量。ECN显式拥塞通知交换机在发现拥塞时会把数据包标记为CECongestion Experienced接收方会把这个信息反馈给发送方让发送方降低发送速率。这本质是一种反馈式拥塞控制调参复杂而且针对不同的流量模型表现差异很大。单看纸上数据RoCEv2和IB的带宽都支持到NVIDIA目前主流的400G/800G速率单流延迟差距也在同一个数量级内。但实际部署中RoCE的难点几乎全部集中在“无损保证”上。PFC和ECN任何一项参数调不好性能就掉给你看而这类参数又极度依赖网络拓扑、流量模型和工作负载特征很难有一个“通用配置”直接套用。我自己遇到的典型场景是RoCE网络在跑测试流量的时候一切正常一到真实训练流量上场就出现性能波动原因是大模型的AllReduce流量是突发式的突发流量很容易在某个时刻打爆交换机缓存触发ECN标记或PFC暂停进而引发连锁反应。这种情况不是一次两次是反复出现。3. 为什么NCCL和主流框架更偏爱IB3.1 NCCL原生支持与协议深度绑定NCCLNVIDIA Collective Communications Library是几乎所有大模型训练框架PyTorch、Megatron、DeepSpeed等底层的通信库它对网络后端的支持分为几类IB、RoCE、TCP Socket、以及NVIDIA自家GPU之间通过NVLink共享内存的后端。在NCCL内部IB后端和RoCE后端走的是完全不同的代码路径。IB后端可以直接访问InfiniBand Verbs API建立RC可靠连接或XRC扩展可靠连接利用硬件Level级的可靠传输特性收发两端通过硬件队列对QP进行数据交换CPU几乎不参与数据搬运。而RoCE后端虽然也基于verbs接口但它实际上要处理UDP/IP封装还要处理ECN事件、拥塞窗口调整底层依赖的以太网QoS配置必须在驱动和交换机侧同时生效。还有一个实际的影响因素NVIDIA对IB的调试和验证投入远超RoCE。这一点你去看NCCL官方文档和GitHub Release Note就能感受到新版本的NCCL在引入新的集通信算法时通常优先保证IB后端的最优表现RoCE后端往往是兼容可用的状态但很多性能优化并不能同步落地。在NVIDIA发版说明里能看到很多“improve performance on IB”的条目说实话看到“RoCE性能提升”的次数明显少很多。而且NCCL在运行时对网络类型有自检测逻辑如果检测到端口是RoCE模式会自动启用一套独立的拥塞控制机制这套机制在复杂拓扑里的收敛速度远不如IB链路这也是为什么同样的网络拓扑跑IB就是比跑RoCE稳定。3.2 从实测数据看延迟、吞吐、稳定性我这边有几个万卡集群的实际测试数据虽然不能把所有细节都公开但规律是很一致的。单看单流延迟IB和RoCE的差异其实不大。比如在400G速率下IB的节点间ping延迟通常在1微秒左右RoCE也能做到1.5微秒左右。差异主要体现在多流、大规模并发场景下万卡规模AllReduce测试中IB的扩展性表现明显优于RoCE。随着节点数增加RoCE的AllReduce吞吐会被“掉队”的链路拖慢而IB多路径和自适应路由机制的存在让性能曲线更加平滑。稳定性差异更加明显。RoCE网络在大规模训练中更容易出现网络抖动导致训练中断。尤其是某个交换机端口需要重启或链路抖动时RoCE往往会导致NCCL报错甚至训练任务失败而IB的子网管理器Subnet ManagerSM会自动做路径重计算和链路切换对训练进程的干扰小很多。部署运维成本方面IB有官方的子网管理器统一管理网络拓扑配置相对集中RoCE则需要每台交换机独立配置PFC、ECN、QoS、缓冲区池等配置复杂度指数级上升。还有一个容易被忽略的点主机侧网卡的配置。RoCE网卡需要设置流控参数、选取流量类别Traffic Class、配置ECN的阈值等每个参数都要跟交换机侧对齐。错一个数字整条链路就可能出现“门限太低导致大量ECN标记或者门限太高导致拥塞后丢包”的情况。而IB网卡通常不需要这么复杂的Tuning插上去就能跑出不错的性能。4. RoCE踩坑实录与适用场景4.1 RoCE在真实集群中的典型坑不要以为IB贵所以RoCE好欺负RoCE的“便宜”是有代价的。下面这些坑都是我或者身边朋友在实际集群里真真切切遇到过的PFC死锁PFC的原理是某个端口收不下数据时就通过PAUSE帧通知对端停止发送。但如果拓扑里有环路或者多条优先级流量交织在一起就可能出现互相等对方释放缓冲区的死锁情况。这类问题极难排查表现为网络整体“假死”所有RDMA流量归零而普通TCP流量可能正常。一旦出现这种问题只能一台台交换机查配置整个集群一块重启网络设备才能恢复。ECN参数不匹配RoCE要求主机网卡和交换机配置相同的ECN阈值。一旦两边不一致比如交换机已经打上CE标记了但网卡侧的配置对这些标记不敏感拥塞信号就完全失效流量继续硬挤最终造成丢包。这种问题表面看是“偶尔卡一下”实际是一旦训练负载上来节点间通信性能就会周期性雪崩。交换机缓存不足大模型训练的流量特点是“突发的集体通信”可能存在数十个节点同时向同一个节点发送数据的场景瞬间打爆交换机端口的接收缓冲区。IB交换机通常有更大的片上缓存和更精细的动态缓存分配机制而很多RoCE交换机的缓冲区分区配置不够灵活一旦缓存耗尽只能丢包。这也是为什么市面上的RoCE交换机都会强调“大缓存”卖点但缓存怎么分配又是一个很难调好的问题。网卡队列和CPU中断RoCE虽然叫RDMA但在数据接收路径上对CPU的依赖比IB要高一些尤其是处理拥塞通知和完成队列事件时。在大规模训练场景下CPU本身要跑数据加载、算子调度、通信库逻辑如果网络侧再频繁打断CPU训练吞吐会进一步下降。IB驱动和硬件在这方面做得更“静”对CPU的打扰少得多。4.2 什么情况下RoCE也够用这是我必须说公道话的地方。RoCE不是一无是处它对某些场景确实是性价比极高的选择规模不大比如128卡以内网络拓扑简单没有太多层级的集群RoCE的配置复杂度可控。业务以GPU直连通信为主但对稳定的延迟不敏感比如推理服务或者小规模的微调任务。已经拥有成熟的以太网运维体系团队对PFC、ECN有丰富调优经验对性能抖动有心理预期和快速恢复预案。预算有限优先买更多GPU卡而不是更好的网络设备。毕竟很多时候多几张卡带来的收益比网络从RoCE升级到IB更直接。说白了如果你能把RoCE调到一个相对稳定的状态并且接受20%~30%的网络性能折损RoCE是可以用的。但一旦规模上去了你会发现省下来的钱最后大概率要花在运维人力、故障损失和反复调优上。5. 大模型集群网络选型的个人经验5.1 性能与成本的真实权衡经常有人问我“训练集群是不是必须上IB”我的答案是看规模、看业务、看团队。从容量规划的视角出发单机8卡训练一个7B模型的场景下IB和RoCE的区别几乎感知不到因为大部分通信还是靠机内NVLink完成的跨节点流量不大。但如果是千卡以上规模的70B、百B级模型训练通信占比会直线上升这时IB带来的性能提升、稳定性和运维省心程度就完全值回票价了。费用角度也要算清楚。IB确实比RoCE贵双口400G的IB网卡和对应的交换机端到端方案整体成本大约是RoCE方案的1.5倍到2倍。但如果按“单位有效训练吞吐成本”来算IB并不算奢侈因为同样的GPU卡池用IB可能跑得更快、更稳GPU的空闲等待时间大幅减少单位时间能产出的训练量反而更多。NVIDIA近两年的策略也在说明问题其发布的DGX和HGX基座级系统网络标配基本都是IB或者Spectrum-X以太网。Spectrum-X可以看作是NVIDIA精心优化过的“增强版RoCE”它在硬件层面引入了类似IB的流控和拥塞控制逻辑极大改善了传统RoCE的痛点但它依然逃不开以太网本身的复杂运维挑战。5.2 从运维角度看IB的“一把梭”体验坦率讲IB不是没有缺点。IB的设备相对封闭兼容性测试主要跟着NVIDIA生态走如果哪天你想插第三方网卡或者换别的品牌交换机踩坑概率很高。而且IB的获取周期有时候比以太网产品更长有些型号的交换机可能要等货这在快节奏的AI基建里也挺烦人。但落实到日常运维IB确实省心太多。它的子网管理器设计让全网拓扑自动发现、路由自动计算、故障自动重绕管理员基本只需要关注训练作业本身而不用天天盯网络监控。RoCE则需要把交换机QoS、PFC水位、ECN阈值、网卡中断绑定全都纳入巡检范围每次变更都要评估对网络无损伤的影响面。这种“省心”在日常上体现得特别明显。有一次凌晨的一次链路抖动IB的网络自动切换了路径训练作业只出现了一个小的性能毛刺同样的场景如果是RoCE大概率就是NCCL超时、训练作业直接中断。我个人的粗滤经验是如果你在搭一个长期运行的、千卡以上的大模型训练集群并且希望运维团队把主要精力放在训练效率和业务迭代上而不是天天跟PFC、ECN搏斗那么IB几乎是默认选择。另外一个小建议无论选IB还是RoCE网络拓扑的设计都必须为“技术验证”留出空间。我的做法是先用小规模设备搭建一组与生产拓扑等比的测试环境把NCCL的AllReduce、AllGather跑一遍同时观察延迟、吞吐、抖动三个指标跑满72小时再下结论。不要轻信厂商的PPT性能数字分布式训练网络的真实表现只有实际跑过大流量才知道。