随便找个做分布式训练的朋友聊聊就知道，GPU到位之后，瓶颈大概率不在算力上。千卡万卡集群跑大模型，每一轮梯度同步都要在全网广播数据，通信效率直接决定 GPU 的闲忙比。轮次之间多等一秒，一天下来就是大几百张卡的算力在空转。前几年大家还能靠 TCP 把训练网络对付着用，到了现在的集群规模，TCP 栈的 CPU 开销、时延抖动、重传风暴，任何一条都足够让训练曲线直接掉下去。这也就是为什么 RoCEv2 在大模型训练网络里已经成为实际上的基础设施选项——准确说，它已经不是"选不选"的问题，而是"怎么配才能不翻车"的问题。
这篇文章我想从实际部署者的角度，把 RoCEv2 为什么能扛起大模型训练网络这件事拆开讲清楚，包括它的通信模型、技术基座、落地配置，以及我在真实集群里踩过的一些坑。适合正在搭训练集群的网络工程师、准备自建 GPU 集群的算法团队负责人，以及做推理平台但总被"多机卡间通信性能上不去"折磨的 MLOps 同学。
1. 大模型训练的通信模型：先搞懂流量从哪里来
1.1 分布式训练里的分层通信结构
大模型训练并行策略里，通信是分层的。节点内部一般用 NVLink 互联，负责同一台机器上 8 张 GPU 之间的高速数据交换，双向带宽能到 600GB/s 以上。但跨节点的时候，NVLink 就够不到了，必须借助外部网络把多台机器的 GPU 连成一个整体，这部分就是 RoCEv2 要扛的流量。
搞清楚这个分层，才能理解为什么大模型训练网络对时延和带宽的要求如此极端。节点内的 NVLink 延迟在微秒级，如果跨节点的网络延迟比节点内高出一个数量级以上，混合并行的同步效率就会大打折扣。RoCEv2 在普通以太网上能把端到端延迟压到 1~2 微秒级别，加上交换机转发也就几微秒，这是 TCP 完全做不到的。
1.2 不同的并行策略，通信模式完全不同
数据并行是最常见的模式，每张卡持有完整模型副本，训练时各自处理不同 batch。每轮迭代结束，所有 GPU 的梯度需要做一次全局 AllReduce，把梯度平均后再更新参数。这个操作对时延极其敏感——整个训练过程是同步阻塞的，任何一张卡的通信慢下来，全集群都得等它。
张量并行是把一个 Transformer 层的权重矩阵切到多张卡上计算，每层内部就要做多次 AllReduce。这个通信频率比数据并行高得多，但主要发生在节点内，靠 NVLink 扛。流水线并行是把不同层放在不同 GPU 上，通信模式变成点对点传输，更看重带宽而非时延。MoE 模型里还有个 All-to-All，每个 token 可能要跑到其他节点上的专家去计算，这种通信是跨节点的密集广播，流量模型最复杂，带宽和拥塞控制都压力很大。
实际训练时，常用的混合并行会同时使用多种策略，于是网络里同时存在大量 AllReduce、点对点通信和 All-to-All 流量。RoCEv2 面对的不是某一种静态流量，而是多种通信模式叠加后的随机冲击。这决定了它对网络无损、低时延、高吞吐的要求是同时的，缺一个都会让训练性能雪崩。
1.3 大模型训练网络需求画像：三高两低
结合并行策略，大模型训练网络的核心需求可以总结成"三高两低"：
- 高带宽：跨节点通信量动辄几百 GB 到 TB 级别，千卡集群一轮同步就要传几十 GB 的梯度数据。
- 高消息频率：每个 iteration 都有通信，小消息甚至只有几十 KB，网络要能扛海量小包的 PPS 冲击。
- 高稳定性：网络抖动一次可能只有几毫秒，但同步训练下所有 GPU 都会被这次抖动拖住，整体吞吐下降。
- 低时延：尤其对时延敏感的小消息 AllReduce，几十微秒的延迟差异就能拉开明显的训练效率差距。
- 低 CPU 开销：通信全部走内核协议栈会抢占大量 CPU 资源，导致 GPU 侧数据准备好之后无法及时发出，进一步放大同步等待。
TCP/IP 栈在这五个维度上表现都不行，于是 RDMA 技术被搬上了大模型训练网络的舞台。而 RoCEv2 作为在以太网上跑 RDMA 的标准方案，就是目前综合成本、性能、生态之后的最优解。
2. RoCEv2 的技术基座：RDMA 为什么能在以太网上跑得又快又稳
2.1 RDMA 的核心思想：绕过内核，直接读写远端内存
传统 TCP 通信路径是：应用数据 → 内核 socket → TCP/IP 协议栈 → 网卡 → 网络 → 对端内核 → 对端应用。数据每经过一层都要拷贝，CPU 参与度极高，延迟在几十微秒甚至毫秒级。
RDMA（Remote Direct Memory Access）把这条路径精简到极致：网卡直接从应用内存（或者 GPU 显存）读出数据，封装后通过网络发到对端网卡，对端网卡直接把数据写入目标内存，全程不经过 CPU，也不需要内核参与。
这就好比传统快递每到一个分拣中心都要卸货、扫码、重新装车，而 RDMA 是"整车直发、末端直投"。对延迟和吞吐的提升是数量级的差异。大模型训练里，GPU 要同步的就是显存里的梯度数据，RDMA 恰好支持直接从显存取数，省掉了"显存→内存→内核→网卡"这条漫长路径。
2.2 RoCEv1 与 RoCEv2 的区别：从二层到三层的进化
RoCE 全称 RDMA over Converged Ethernet，分两个版本。RoCEv1 工作在二层，只能在同一个广播域内通信，靠 MAC 地址寻址，组网受限很大，无法跨 VLAN、跨子网，这对大规模训练集群来说是致命的。RoCEv2 把报文封装改为 IP 头 + UDP 头 + RDMA 载荷，相当于给 RDMA 流量穿上了 IP 和 UDP 的外衣，可以在三层网络里路由，也可以利用 ECMP 做负载均衡。
RoCEv2 的报文结构大致可以理解为：
| Ethernet Header | IP Header | UDP Header | RDMA Payload（包含IB BTH等） |这次演进对大规模组网意义重大。训练集群动辄上百台交换机，必须是多层 Leaf-Spine 架构，RoCEv2 能跑在普通以太网交换机上，并且能跨三层路由，这意味着它可以复用现有的数据中心网络体系，不需要单独搭一套 InfiniBand 物理网络。
2.3 无损网络：RoCEv2 正常工作的前提条件
RDMA 和 TCP 最大的不同是，TCP 有丢包重传机制，而 RoCEv2 早期的流控机制很弱，丢包直接导致 QP（Queue Pair）队列错误，通信中断，训练直接失败。就算不走极端丢包，哪怕只有 0.1% 的丢包率，RoCEv2 的吞吐也可能掉一半以上。
为了让 RoCEv2 在以太网上跑得稳，需要把网络配置成无损网络（Lossless Network），核心是两项技术：
PFC（Priority Flow Control，基于优先级的流控）：在以太网链路上按优先级做暂停/恢复。RoCE 流量放在最高优先级队列，当接收端 buffer 快满时，向上游发 PAUSE 帧，让上游暂时停止发送这个优先级的流量。这相当于把丢包问题转化为"压住上游"的背压机制。
ECN（Explicit Congestion Notification，显式拥塞通知）：交换机检测到队列超过阈值后，在报文上打 ECN 标记，接收端收到后通知发送端降低发送速率。这比 PFC 更"智能"，是前导性的拥塞控制，配合 DCQCN 等算法可以让 RoCEv2 在拥塞时主动降速而不是粗暴暂停。
2.4 RoCEv2 与 InfiniBand 的关系：以太网上的"IB 平替"
InfiniBand 本来就是为 RDMA 设计的，天生带有无损转发、拥塞控制、自适应路由等能力，性能和稳定性都是最优的。但代价是网络硬件成本高、生态封闭、要建独立网络。RoCEv2 的思路是"把 IB 的语义搬到以太网上跑"，网络设备可以继续用开放的以太网生态，成本低得多。
实际训练集群里，两条路线都有部署。但这些年英伟达在自家软件栈里对 RoCEv2 支持力度持续增强，云厂商也大量采用 RoCEv2 做 GPU 实例的底层网络，RoCEv2 在性价比和灵活性上确实占据了优势。它不是 InfiniBand 的完美替代品，但在大模型训练这个具体场景里，它用更低的成本做到了"够用且好用"。
3. RoCEv2 训练网络落地实操：从拓扑规划到参数调优
3.1 物理拓扑与带宽规划
大模型训练网络的物理拓扑，主流还是 Spine-Leaf 两层架构。Leaf 层接服务器，Spine 层负责横向汇聚。规模大一点会扩展为三层，但基本原理一致：任何两台服务器之间的通信，跳数尽量少，路径唯一或做等价多路径。
规划带宽时，有一个重要的收敛比概念。收敛比 = 上联带宽 / 下联带宽。传统数据中心网络收敛比做到 3:1 甚至 4:1 都很常见，因为东西向流量没那么大。但训练集群不行，梯度同步是全网广播，流量大量存在于 Leaf 和 Spine 之间。为了不让上行链路成为瓶颈，建议收敛比做到 1:1，也就是 Leaf 的下联总带宽和上联总带宽相等。
举个例子，一台 Leaf 接 48 台 100G 服务器，下联总带宽 4.8T，那它的上联带宽至少也要 4.8T。如果接 8 台 Spine 交换机，每台 Spine 上需要从该 Leaf 接入 600G，一般用 4 条 100G 或 2 条 400G 链路做捆绑。很多训练性能上不去，根子不是 RoCEv2 配置不对，而是收敛比算错了，出口带宽天然不够。
3.2 无损网络的配置细节：PFC 与 buffer 规划
把网络切成无损域之前，先想清楚一个原则：不是所有流量都需要无损。PFC 只对 RoCE 流量生效，普通 TCP、管理流量走其他优先级，避免被误伤。通常把 RoCE 流量放在 802.1p priority 3，保留 priority 6/7 给网络控制协议，其余给数据类流量。
交换机上配置 PFC 时要特别注意 buffer 规划。PFC 生效的原理是接收端 buffer 将满时发 PAUSE 帧，上游收到后需要把正在路上传输的数据继续接收完。这部分"在途数据"所占用的空间叫 headroom buffer。链路带宽越高、跨设备距离越长，需要预留的 headroom 就越大。我见过有人在 100G 链路上只留了默认的 headroom，结果流量一大就丢包，查了半天才发现是这个原因。
buffer 规划里还有个容易忽略的细节：每个有损队列和无损队列的资源划分。把 PFC 队列的 buffer 设得过大，普通队列的 buffer 就会不足，TCP 流量性能下降是小事，严重时连管理面都会出问题。一般建议按交换机型号查官方推荐的 RoCE 配置模板，不做过度自定义。
ECN 配置方面，关键参数是队列深度阈值。交换机厂商会把阈值表示成 buffer 利用率百分比或具体 KB 数。通常把 ECN 的 mark threshold 设在队列 buffer 深度的 60%~80% 之间。设太低，正常流量也会被打标导致无谓降速；设太高，真正拥塞时标记不及时，退化为 PFC 兜底，会有死锁风险。
3.3 网卡侧配置：从 GID 到 MTU 的细节清单
服务器端网卡配置是 RoCEv2 落地的另一块。以常见的 Mellanox ConnectX 系列为例，需要关注几个点：
GID 索引设置：网卡要创建 RoCEv2 模式下的 GID，并把它设为 active index。过时的 gid 配置会导致 node 之间无法建立 QP，表现就是通信直接超时。一般通过rdma link show命令确认。
MTU 调整：RoCEv2 推荐使用巨大帧 MTU=9000，减少小包数量和头开销。交换机端口和服务器网卡都要配置一致，两端不匹配会直接导致链路无法正常通信，或者产生诡异的性能下降。
流控设置：网卡的 PFC 必须和交换机对齐。用ethtool -a eth0可以看到当前网卡的流控设置，通常是 auto 协商模式，训练场景建议显式配置为rx on tx on。
关闭不必要的卸载功能：RoCEv2 本身要做 kernel bypass，不需要 TCP offload。但有些网卡默认开启的软件卸载功能可能会干扰 RDMA 路径，遇到性能异常时可以尝试关闭这些卸载再看效果。
QP 数量规划：每个节点上跑的通信线程越多，需要的 QP 就越多。QP 数量不够时，训练框架会排队等待建连，表现就是通信初始化阶段偏慢。一般把网卡配置到最大支持 QP 数即可，现在的主流网卡在几万 QP 量级，足够的。
3.4 拥塞控制算法：DCQCN 的参数与调优方向
RoCEv2 社区用得最多的拥塞控制算法是 DCQCN，它基于 ECN 反馈做发送速率调整。核心参数包括 \(\alpha\)（拥塞程度估计的增长率）、g（用于更新 \(\alpha\) 的平滑因子）、RPG 的增减速率步长等。这些参数的默认值通常来自 Mellanox 的推荐配置，但在不同拓扑和流量模型下效果差异很大。
我的经验是，初期直接用厂商推荐参数跑通，然后观察 ECN 标记率。如果 ECN 标记率很低但性能上不去，说明拥塞控制太保守，发送端没有及时降速或恢复太慢；如果标记率很高且吞吐波动大，说明阈值太敏感，需要提高 ECN 阈值或调低 \(\alpha\) 的增长率。
DCQCN 调参核心思路是让发送端在拥塞发生时快速降速，拥塞缓解后恢复也要快。CNP（拥塞通知报文）必须在接收端正确生成并发回发送端，两台服务器的pkey和gid配置不一致，都会导致 CNP 无法识别，拥塞控制完全失效。遇到莫名其妙的重灾区性能问题，先查 CNP。
3.5 一个最小可复用的 RoCEv2 配置清单
用一段简化但不失真的模板，把前面讲的核心内容串起来：
交换机侧（以某主流厂商为例，具体关键字以设备文档为准）：
# 将 RoCE 流量映射到优先级 3 priority-flow-control on priority-flow-control priority 3 on # 为 RoCE 队列配置 headroom buffer buffer headroom size 100000 # 开启 ECN ecn on # 为 RoCE 队列设置 ECN 标记阈值 ecn mark queue 3 threshold 70% # 配置等价路径 load-balance ecmp router-id enable服务器网卡侧：
# 确认 RDMA 设备与 mode rdma link show # 设置 MTU 为 9000 ip link set eth0 mtu 9000 # 开启流控 ethtool -A eth0 rx on tx on # 确认 RoCEv2 GID 可用（假设 wlan 具体网络接口为 eth0） rdma link add rxe0 type roce version 2 network eth0这份配置只是骨架，不同厂商和型号的差异非常大。但核心逻辑一致：打开 PFC → 配置 buffer/headroom → 打开 ECN → 设置标记阈值 → 确认 GID/MTU/流控对齐。这条链路上一处不对，RoCE 的整体表现都会出问题。
4. 训练场景中 RoCEv2 的常见问题与排查实录
4.1 PFC 风暴：短时间吞吐归零的元凶
PFC 本身是保护机制，但用法不当会变成灾难。一个常见场景是：多条 RoCE 流在交换机上竞争同一出端口 buffer，其中一个优先级触发了 PAUSE，而 PAUSE 又连锁触发上游交换机暂停。如果存在环路（哪怕逻辑上的流量环），PAUSE 帧可能在环里无限传递，形成 PFC 风暴。表现为所有 RoCE 流量吞吐瞬间归零，交换机 CPU 被打满。
排查思路：在交换机上开show priority-flow-control counters，看各端口的 PFC 暂停帧收发计数。暂停帧数量只增不减，就说明有持续的 backpressure。再结合流量路径分析，找出发送 PAUSE 最频繁的端口，重点看是不是 downlink 拥塞导致的 head-of-line blocking。解决方向是：调大出端口 buffer，或者利用 ECN 提前干预，让发送端在 buffer 满之前降速，减少 PFC 触发的频率。
4.2 ECN 阈值设错：从 8 Gbps 掉到 2 Gbps 的排查现场
有个集群的性能问题让我印象很深：同样的模型、同样的卡数，换了一个机房后训练吞吐掉了 70%。本以为是链路质量，用 ib_write_bw 测单流是 200Gbps 满速，但只要多流并发，吞吐直接掉到个位数 Gbps。
排查到最后发现，新机房的交换机 ECN 阈值配的是 2%（厂商推荐值的 1/30）。每条流稍微一波动就打标记，发送端收到 CNP 就降速，所有流都在来回震荡，整体吞吐反而不如彻底无损时的表现。把阈值调回正常区间后问题立刻消失。
这个案例的教训是：RoCEv2 不是配置越激进越好，拥塞控制必须在"反应过快"和"反应过慢"之间找到平衡点。不同设备厂商的 buffer 结构差异很大，不要盲目沿用别处的模板，要按设备实际 buffer 深度重新计算阈值。
4.3 哈希不均：ECMP 把流量全分到同一条路径
Spine-Leaf 架构下，Leaf 和 Spine 之间会有多条等价路径。RoCEv2 是 UDP 报文，交换机做 ECMP 哈希时通常用五元组。UDP 五元组里，源目端口经常是固定的（比如 RoCE 的 UDP 端口号固定），于是哈希结果很容易集中在一两条链路上，其他链路闲置。
解决方向是开启交换机的增强型哈希或对称哈希，把更多字段纳入哈希计算。部分平台支持基于 RoCE 报文内部字段做哈希，分发效果会好很多。配置后要观察各条链路利用率是否均衡。我用过一个土办法：用多个 QP 跑不同流，同时看各 Spine 端口计数器，如果某个端口利用率长期超 80% 而另一个不到 30%，大概率就是哈希问题。
4.4 网卡降速与信号质量问题
训练任务跑着跑着突然掉性能，看网卡统计发现速率从 100G 降到 40G。这种情况通常是光模块信号劣化导致的自动降速。RoCEv2 对丢包很敏感，链路一旦降速，训练性能直接塌方。
光模块问题容易被忽略，因为链路掉几次又恢复，看着像"偶发抖动"。建议在训练前做一轮完整的链路检测，重点看 FCS 错误、CRC 错误和链路重训练次数。我遇到过一根光纤跳线在机房随手一踩后开始间歇性丢包的问题，换线后一切正常。这类问题日志里往往不留明显错误，非常坑人。
4.5 多租户混部时 RoCEv2 被 TCP 流量干扰
训练集群如果同时跑着日志采集、监控等 TCP 流量，它们和 RoCEv2 共享链路时，一旦 PFC 的优先级划分做得不彻底，TCP 流量会抢占 buffer，RoCEv2 的时延就开始抖动。
解决方法是严格控制 RoCEv2 的 QoS 映射，把 RoCE 流量放在独立优先级队列，并限制其他优先级的 buffer 上限。另外，训练任务最好跑在独立的网络命名空间或 VLAN 里，和业务流量逻辑隔离。混部场景下，给 RoCEv2 做带宽预留是值得的，哪怕只是预留 90%，也比完全自由竞争时的实际吞吐稳定得多。
4.6 常用排查命令速查表
| 现象 | 排查命令 | 关注点 |
|---|---|---|
| 建连失败 | rdma link show | GID 配置、mode 是否为 roce |
| 吞吐低 | ib_write_bw/ib_read_bw | 单流 vs 多流，判断是否哈希不均 |
| 延迟高 | ib_write_lat/ib_read_lat | 对比小消息延迟是否在合理范围 |
| 丢包 | ethtool -S eth0 | rx_errors、fcs_errors、rx_pause 计数 |
| ECN 异常 | 交换机show ecn counters | 标记速率是否过高或异常 |
| PFC 风暴 | 交换机show priority-flow-control counters | 暂停帧数量是否持续增长 |
| 链路不稳 | 光模块诊断信息 | 温度、电压、光功率是否在合规范围 |
排查问题是靠数据说话的。拿到计数器数据后，先在"有损 vs 无损、单流 vs 多流、近端 vs 远端"三个维度做矩阵对比，能快速定位问题层。
5. 训练网络选型思考：RoCEv2、InfiniBand 与未来的方向
5.1 RoCEv2 与 InfiniBand 的核心差异对比
RoCEv2 与 InfiniBand 在训练网络里的竞争关系，本质上不是性能之争，而是生态和场景之争。
| 维度 | RoCEv2 | InfiniBand |
|---|---|---|
| 物理层 | 普通以太网，开放标准 | 专用 IB 网络，封闭标准 |
| 无损实现 | 需要额外配置 PFC/ECN | 原生支持 |
| 拥塞控制 | 依赖 DCQCN 等算法 | 原生自适应路由+拥塞控制 |
| 成本 | 相对低，网络设备选择多 | 相对高，硬件绑定深 |
| 生态 | 与以太网、云环境兼容好 | 英伟达生态深度集成 |
| 部署复杂度 | 调参项多，对运维要求高 | 相对即插即用 |
InfiniBand 在时延和稳定性上仍然有优势，尤其是大规模场景下不需要花大量精力在调参数上。但 RoCEv2 的开放性和低成本让它成为更多团队的务实选择。如果你的团队有资深网络工程师，RoCEv2 的性价比很高；如果运维资源很紧张，InfiniBand 的省心价值可能更值钱。
5.2 NVLink + RoCEv2：当前 GPU 集群的主流混合组网
现在主流的 8 卡 GPU 服务器内部用 NVLink 做高速互联，跨节点走 RoCEv2 或 InfiniBand，形成"NVLink 负责节点内，RoCEv2 负责节点间"的分层结构。这种混合组网的合理性在于：大多数并行策略中，通信主要发生在节点内部，跨节点通信占比相对低。用更便宜的 RoCEv2 承载跨节点流量，总成本更低。
NVLink 的双向带宽到 900GB/s 级别，而跨节点的 RoCEv2 每张卡最多 100G/200G，差距很大。所以训练框架在分配并行策略时，会尽量把通信量大的并行维度放在节点内部，跨节点只传必要的梯度数据。混合并行的设计好，RoCEv2 的压力可控；设计不好，跨节点流量爆炸，再好的网络也会被打穿。
5.3 下一代方向：UEC 与超以太网
RoCEv2 的拥塞控制依赖外部配置的 PFC/ECN，这始终是它被诟病的地方。业界也在推动新的方案，最具代表性的是超以太网联盟（UEC，Ultra Ethernet Consortium），目标是把无损网络、拥塞控制、多路径等能力做成以太网原生特性，降低对人工配置的依赖，同时避免 PFC 风暴这类问题。
UEC 还处于标准制定阶段，短期内大规模落地还不现实。现阶段 RoCEv2 仍然是大模型训练网络最现实的方案，但部署时要有"后续能平滑演进"的意识——选硬件时优先支持 UEC 相关特性的产品，网络架构上不要做死绑定单一厂商的封闭方案，留出升级空间。
5.4 什么样的团队适合自建 RoCEv2 网络
自建 RoCEv2 训练网络对运维能力是有门槛的。这个门槛不在于"跑通"，跑通很容易；而在于"出了问题能在几小时内定位"。PFC、ECN、DCQCN 这些机制平时隐藏在网络底层，一旦出问题都是系统性问题，没有排查经验的人面对的都是玄学。
如果团队规模小，建议优先考虑云上 GPU 实例。云厂商已经把 RoCEv2 的底层配置和故障处理封装好了，你只需要关注训练框架层的通信效率。如果是自建机房或者已经有成熟的网络运维团队，自建 RoCEv2 网络可以把单卡通信成本压到很低，并且可以针对具体训练流量做定制调优，收益也很明显。
