InfiniBand 与 RoCEv2 深度对比：AI 集群网络的无损机制、拓扑收敛比与选型决策

一、把两条路线放回协议栈里看

两者都提供 RDMA 语义：数据绕过内核协议栈，从应用内存（配合 GPUDirect RDMA 时可直接到 GPU 显存）搬到远端，减少拷贝与 CPU 介入。也正因为上层语义接近，很多对比文章会直接跳到「谁快谁慢」，反而漏掉了真正决定工程体验的分野。

层次	InfiniBand	RoCEv2
链路与网络	专用链路层，LID 寻址，子网内转发	标准以太网 + IP，UDP 封装（常用目的端口 4791）
传输	IB 原生传输层，verbs 语义	把 IB 传输层封装进 UDP/IP 报文
无损能力	链路层基于信用的流控，硬件保证	需 PFC / ECN / 拥塞控制配合配置
路由与管控	子网管理器（SM）集中下发转发表	IP 路由、ECMP，沿用以太网运维体系
路由能力	以二层子网为主，跨子网需网关	可跨三层，便于跨机房扩展
故障定位工具	IB 专属工具链（如 iblinkinfo、perfquery）	交换机遥测、SNMP/gNMI、流统计等通用工具

顺带澄清两个常被混用的术语。RoCE v1 是二层以太网帧封装，只能在同一个二层域内通信，如今工程上新谈的 RoCE 基本指可路由的 RoCEv2；iWARP 同样在以太网上承载 RDMA，但基于 TCP，不依赖 PFC，代价是时延与生态适配上的取舍，在 AI 训练集群里相对少见。规范层面的原始定义，可查阅 IBTA 规范与资源库。

所以这不是「谁更快」的问题，而是确定性与成本、专用与开放、原生与可配置之间的取舍。集群整体架构如何把算力、网络、存储三层配平，可参考 企业 AI 算力集群建设指南；本篇只把网络这一层拆开讲透。

二、无损机制：信用流控 与 PFC + ECN + DCQCN

以太网默认是有损的尽力而为网络，拥塞时丢包是正常行为；RDMA 却对丢包与重传比较敏感。两家路线解决这个矛盾的方式完全不同。

2.1 InfiniBand：把无损做进链路层

InfiniBand 采用基于信用的流控：发送端只有在确认接收侧缓冲区有可用信用时才发送数据，缓冲区不会因溢出而丢包。配合交换机侧的拥塞感知与自适应路由，以及部分设备支持的在网聚合能力，长任务下的时延抖动相对可控。代价是整套网卡、交换机、线缆与管理工具自成体系，需要独立的物理网络与专门的技能栈。

2.2 RoCEv2：把无损「配置」出来

RoCEv2 常见做法是三层配合，各自承担不同职责：

机制	作用	标准 / 位置	配错的典型表现
PFC（优先级流控）	按 RDMA 优先级逐跳发 PAUSE，避免缓冲区溢出丢包	IEEE 802.1Qbb，交换机与网卡队列	队头阻塞、PAUSE 帧扩散、极端情况下死锁
ECN（显式拥塞通知）	队列越过设定门限即对报文打标，接收端回传拥塞通知	RFC 3168，交换机水线	门限过高来不及降速，过低则吞吐上不去
DCQCN 类拥塞控制	把 ECN 标记与发送端硬件限速结合，提前降速	网卡与驱动实现，需与交换机参数协同	参数不匹配时速率反复震荡，带宽跑不满

可以这样理解：PFC 是急刹车，ECN 与拥塞控制是提前减速。调优目标不是让 PFC 更灵敏，而是让它尽量少触发——触发频繁，通常说明 ECN 门限、缓冲区水线或速率控制没有配平。

2.3 配置清单与常见坑

配置项	要对齐什么	常见坑
无损优先级与 DSCP/PCP 映射	RDMA 流量在每一跳都被识别进同一无损队列	中间一跳映射丢了，该段变成有损
PFC 使能范围	只在需要的优先级与端口上开启	整端口全开，普通业务流量被连带暂停
ECN 门限（Kmin / Kmax / 标记概率）	与交换机缓冲区、链路速率、往返时延匹配	照搬别家配置，incast 下毫无效果
缓冲区水线与共享模式	预留足够 headroom 吸收 PAUSE 在途报文	headroom 不足，暂停生效前已丢包
ECMP 哈希与熵	UDP 源端口熵足够，流量能铺开到多路径	大象流撞在同一条上行，局部热点
遥测与计数器	PAUSE 帧、ECN 标记、丢包、队列深度可持续观测	没有基线数据，出问题时只能靠猜

两个需要澄清的误区：无损不等于无拥塞，队列依然会排长、时延依然会抬升；PFC 触发也不等于故障，但持续、频繁的触发值得当作调优信号来跟踪。

三、决定训练效率的是尾时延，不是标称带宽

分布式训练每个反向传播之后要同步梯度，All-Reduce 这类集合通信要求所有 rank 等齐慢节点。于是决定迭代时间的往往不是平均时延，而是 P99 / P999 尾时延与抖动。MoE 类模型的 All-to-All 通信还会制造大量多对一 incast，对拥塞更敏感。

维度	InfiniBand	RoCEv2
多路径利用	交换机可基于链路负载做自适应路由	多依赖五元组 ECMP 哈希，部分设备支持动态负载均衡或包级喷洒
拥塞应对	信用流控 + 自适应选路，行为较可预期	取决于 ECN/DCQCN 与 PFC 参数是否调平
在网聚合	部分设备支持交换机内归约，减少上送流量	依赖具体方案与集合通信库支持，需逐项确认
典型风险	生态相对集中，扩容与备件受供应约束	路径哈希不均、PAUSE 扩散、QoS 错配

因此「同样 400G 端口」并不等于同样的训练性能。评估时应拿 NVIDIA NCCL Tests 跑集合通信基准，观察总线带宽随 rank 数增长的曲线、长稳运行下的尾时延，以及真实模型的任务完成时间与算力利用率；NCCL 用户指南 对相关环境变量与拓扑发现机制有说明。把带宽数字换成业务指标，才是可比较的结论。

四、拓扑与收敛比：图纸阶段就定下来的上限

网络设备买回来之前，拓扑与收敛比已经决定了这套集群在通信密集负载下的天花板。这里没有太多可后期补救的空间。

设计项	要点	选型含义
胖树 / Spine-Leaf	Leaf 接服务器，Spine 负责横向汇聚，路径等长	两种路线都可构建，端口规划逻辑一致
收敛比	下行服务器带宽与上行带宽之比；1:1 为无收敛	长周期预训练通信密集，收敛比放宽会放大 incast；微调与推理可适度放宽
Rail 优化拓扑	同编号 GPU 归到同一组 Leaf，与机内高速互联域配合	让大部分集合通信留在本地 rail，减少跨组流量
故障域隔离	计算面、存储面、管理面是否共用物理网络	RoCEv2 可融合但要靠 QoS 与队列隔离；IB 通常物理独立
光模块与线缆	端口数 = 节点数 × 每节点上行口，再加 Spine 侧与备品	AOC/DAC 长度、走线距离与备件常被漏算

一个常被忽略的现实：RoCEv2 允许把算力流量与普通业务放在同一张物理网上，架构看起来更简洁，但故障域也随之合并。若决定融合，务必在验收阶段验证普通业务突发流量不会挤占 RDMA 无损队列。网络与服务器配置是一体两面，采购口径可对照 AI 服务器选型清单 里的网卡与配置单部分。

五、成本与供应链：别只比交换机报价

把两条路线的成本放在同一张三年周期的表里，结论往往会和「谁硬件便宜」不一样。

成本项	InfiniBand 倾向	RoCEv2 倾向
网卡与交换机	专用设备，单端口投入较高	以太网产业链成熟，选择多、单价相对友好
光模块与线缆	专用线缆与光模块，采购面较窄	通用光模块与光纤，备件容易获取
调优与压测人力	参数面较小，交付后调优负担轻	需要持续调参、基准测试与版本验证，人力投入明显
运维技能	需掌握 IB 专属工具链与子网管理	可复用现有以太网团队技能，培训成本较低
故障与重跑损失	确定性较强，长任务中断风险相对低	调优不到位时，任务失败与重跑会吞掉硬件差价
供应与扩展	生态相对集中，扩容周期需早规划	多厂商可选，供应链弹性更好

常见误判是「硬件省下的钱就是净收益」。实际上算力利用率下降几个百分点、或一次数十小时训练任务中断重跑，都可能覆盖硬件差额。建议沿用三年 TCO 框架，把调优人力、压测周期与重跑风险一并货币化，再与自建或租用算力的整体决策对齐。

六、选型决策路径：先答四个问题

把技术讨论收敛成可执行的判断，其实只需要四个问题：集群规模与负载类型是什么？单次任务多长、中断重跑能否承受？团队是否具备持续调优与故障定位能力？现有机房、网络与供应条件有哪些硬约束？四问之后，路线通常自然清晰。

典型场景	倾向路线	主要理由	需要补的前提
数百卡以内，微调 / 推理 / 短周期训练，已有以太网团队	RoCEv2	投入门槛低、技能可复用、可与业务网融合	完成 PFC/ECN 调平与全量压测
千卡以上、连续数周预训练，MoE 或通信占比高	InfiniBand	原生确定性与自适应路由，重跑代价可控	提前锁定供应与扩容周期
跨机房、跨三层、需与业务网协同	RoCEv2	IP 路由与以太网生态更适配	单独核算跨机房时延与丢包预算
预算受限但缺高性能网络人力	小范围 RoCEv2 POC 或混合组网	先用可控规模验证，再决定扩路线	把调优服务与验收标准写进采购要求
既要长稳训练又要控制成本	混合组网	计算面 IB 保性能，存储 / 管理 / 推理面走以太	画清流量平面，规划跨平面网关

无论倾向哪条路线，都建议把 POC 写进采购流程：用真实模型、真实 rank 数、真实数据集，跑满一轮完整训练或微调，记录集合通信带宽、尾时延与任务完成时间。纸面参数是起点，跑出来的有效算力才是评判标准。具体产品线与端口规格可参考 NVIDIA Mellanox 高性能网络互联方案 与 HPC / 超融合平台。

七、上线前八步网络压测清单

网络交付不等于可用。下面这份清单按依赖顺序排列，任一步异常都应在验收期内闭环。

1. 物理层基线：核对端口速率、FEC 模式、光功率与误码计数，确认无告警、无降速链路。
2. 单流带宽与时延：用 perftest 一类 RDMA 基准工具测双向带宽与时延，与设备规格对比，偏差明显需排查。
3. incast 与多对多：构造多打一与多对多流量，观察 PFC PAUSE 帧计数、ECN 标记率与队列深度，确认拥塞控制真的在生效。
4. 集合通信基准：用 nccl-tests 的 all_reduce_perf 等用例，记录总线带宽随 rank 数变化的曲线，看扩展效率是否平滑。
5. 长时间满载：连续高负载运行数十小时，观察尾时延、速率震荡、端口温度与计数器增长，避免只测几分钟就签收。
6. 故障注入：断开一条上行链路或单个 Spine，验证路由收敛时间、任务是否中断、恢复后性能是否回到基线。
7. QoS 隔离验证：在无损队列承载 RDMA 的同时制造普通业务突发，确认没有出现跨优先级暂停或缺速。
8. 业务回归：用真实模型跑完整训练或微调流程，记录算力利用率与任务完成时间，作为后续扩容的对比基线。

把每一步的计数器与曲线留档，日后扩容或调整参数时才有可比基线。这一步省不得：网络问题通常在训练跑到一半时才暴露。

八、行业动向：Ultra Ethernet 与混合组网

以太网阵营正在从「在标准以太网上打补丁」走向「为 AI/HPC 重做传输层」。Ultra Ethernet Consortium（UEC） 作为 Linux Foundation 下的产业组织，于 2025 年发布 UEC 1.0 规范，并在 2026 年持续修订，目标是在开放以太网生态上定义面向 AI 与 HPC 的传输、拥塞控制、多路径与集合通信能力，缓解对 PFC 式逐跳暂停的依赖。

需要冷静看待的是：规范发布不等于现成可采购、可互通的产品。真正落地取决于网卡、交换机芯片、驱动、集合通信库与管理平台的实际支持，以及多厂商互操作测试结果。对当下做采购决策的企业，更务实的做法是把 UEC 纳入「可升级性」考量——设备是否具备后续固件与协议演进空间、拓扑与光模块是否为更高端口速率预留余量——而不是把尚未规模验证的能力写进当前方案的性能承诺。

混合组网则是眼下更可落地的折中：计算面用 InfiniBand 承载参数同步，存储、带外管理、业务接入与推理流量走以太网。它同时带来两套监控与故障定位体系，因此流量平面图与跨平面网关带宽必须在设计阶段就画清楚。

常见问题

总结：先问确定性值多少钱，再谈端口单价

InfiniBand 与 RoCEv2 都能承载大规模 AI 训练，区别在代价结构：前者用专用硬件换原生确定性与较低调优负担，后者用开放生态换成本弹性，同时把调优与验证的责任交给团队。选型顺序建议是负载与规模 → 任务中断代价 → 团队能力 → 三年 TCO → POC 实测，而不是从设备报价单倒推。

VISBAT 维思贝特提供从网络方案设计、拓扑与收敛比规划、光模块线缆清单核算，到 NCCL 集合通信压测与长时间稳定性验证的支持，并可与 智算服务器、AI 算力一体机、并行存储方案 一起做整体规划。具体配置与报价需结合业务场景确定，正式采购请以厂商当时发布的产品资料与兼容性说明为准。