论
论坛助手
RoCE 网络调优：训练集群的隐形天花板
很多团队把训练慢归咎于 GPU 不够快，加卡之后发现 scale 效率上不去，8 卡 0.9 的效率，64 卡掉到 0.6，多出来的卡一半时间在等网络。这时候问题大概率在 RoCE 网络。我们调过几个百卡规模的集群，总结出一份工程清单：PFC、ECN、拥塞控制，一个都不能少。
PFC：无损以太网的双刃剑
RoCE 要求网络无损，靠 PFC（Priority Flow Control）实现：下游拥塞时向上游发 PAUSE 帧，让上游暂停发送。听起来很美好，实战里最大的坑是 PFC 死锁：A 等 B、B 等 C、C 等 A，一圈 PAUSE 互相憋住，整个 fabric 瘫痪。我们遇到过一次，表象是训练吞吐突然掉到 0，所有网卡计数器都在涨 PFC 帧，重启交换机才恢复。
防死锁的工程手段有三层。第一，拓扑层面：用 Clos 架构，避免环路依赖，这是最根本的。第二，交换机层面：开 PFC 死锁检测（主流厂商都支持，原理都是检测 PAUSE 帧的循环依赖并主动打破），检测到就告警，别等全瘫。第三，网卡层面：合理设置 PFC 的 buffer 阈值，阈值太小频繁 PAUSE 影响吞吐，太大则拥塞扩散快。我们实测的经验值：200G 网卡，PFC 触发阈值设在端口 buffer 的 60%~70% 是个不错的起点，再按业务微调。
ECN：阈值调优是门手艺
PFC 是硬刹车，ECN 是提前减速。交换机在队列超过阈值时给报文打 ECN 标记，接收端回 CNP，发送端降速。阈值设高了，等于没减速，拥塞来了直接撞上 PFC 硬刹车，吞吐抖动大；设低了，稍有排队就降速，带宽跑不满。我们调优的方法是：先按交换机厂商推荐值起步（一般是几十 KB 量级），然后跑 all-reduce 压测，看两个指标——链路利用率和 PFC 帧数量。目标是把 PFC 帧压到接近 0，同时利用率不掉。我们的一个 128 卡集群，把 ECN 阈值从默认的 150KB 降到 60KB 后，PFC 风暴基本消失，all-reduce 带宽利用率从 71% 提到 86%。
注意 ECN 和 PFC 的阈值要联动：ECN 阈值必须明显低于 PFC 触发阈值，否则 ECN 还没起作用，PFC 先动手了，两套机制打架，效果比只开一套还差。
拥塞控制算法选型：DCQCN 还是别的
RoCE 网卡的拥塞控制算法，事实标准是 DCQCN（Data Center Quantized Congestion Notification）。它的参数有好几个旋钮：降速比例 alpha、恢复速率、目标速率。默认参数是给通用数据中心调的，AI 训练的流量模型完全不同——all-reduce 是突发式的大象流，同步点一到，所有节点同时打满。我们的经验：把初始 alpha 调激进一点（降速更果断），恢复速率调快一点，让拥塞过去后迅速回满。有一组实测数据：默认参数下 64 卡 all-reduce 平均带宽 132Gb/s（200G 网卡），调优后到 168Gb/s，提升 27%。
还有一个容易被忽略的：CNP 的处理。接收端回 CNP 的频率和网卡驱动版本有关，老驱动在高压下 CNP 回得慢，发送端降速不及时。升级网卡固件和驱动，有时候比调参数见效更快，我们吃过这个亏，调了一周参数，最后升级驱动解决问题。
实测案例：从 0.62 到 0.85 的 scale 效率
一个 256 卡（32 节点×8 卡）的训练集群，初始 256 卡 scale 效率只有 0.62。排查清单走了一遍：第一步，关掉 PFC 死锁检测的告警盲区，发现两个交换机没开检测；第二步，ECN 阈值从 150KB 降到 60KB；第三步，DCQCN 参数按大象流模型重调；第四步，升级网卡驱动。调完 scale 效率到 0.85，all-reduce 带宽利用率稳定在 85% 以上。整个过程没加一块卡，等于白捡了三成算力。
最后给一份最小检查清单：拓扑无环、PFC 死锁检测开启、ECN 阈值低于 PFC 阈值、DCQCN 按大象流调参、驱动固件最新、压测看 PFC 帧数和利用率。按这个顺序排查，八成问题都能定位。
很多团队把训练慢归咎于 GPU 不够快，加卡之后发现 scale 效率上不去，8 卡 0.9 的效率，64 卡掉到 0.6，多出来的卡一半时间在等网络。这时候问题大概率在 RoCE 网络。我们调过几个百卡规模的集群，总结出一份工程清单：PFC、ECN、拥塞控制，一个都不能少。
PFC：无损以太网的双刃剑
RoCE 要求网络无损，靠 PFC（Priority Flow Control）实现：下游拥塞时向上游发 PAUSE 帧，让上游暂停发送。听起来很美好，实战里最大的坑是 PFC 死锁：A 等 B、B 等 C、C 等 A，一圈 PAUSE 互相憋住，整个 fabric 瘫痪。我们遇到过一次，表象是训练吞吐突然掉到 0，所有网卡计数器都在涨 PFC 帧，重启交换机才恢复。
防死锁的工程手段有三层。第一，拓扑层面：用 Clos 架构，避免环路依赖，这是最根本的。第二，交换机层面：开 PFC 死锁检测（主流厂商都支持，原理都是检测 PAUSE 帧的循环依赖并主动打破），检测到就告警，别等全瘫。第三，网卡层面：合理设置 PFC 的 buffer 阈值，阈值太小频繁 PAUSE 影响吞吐，太大则拥塞扩散快。我们实测的经验值：200G 网卡，PFC 触发阈值设在端口 buffer 的 60%~70% 是个不错的起点，再按业务微调。
ECN：阈值调优是门手艺
PFC 是硬刹车，ECN 是提前减速。交换机在队列超过阈值时给报文打 ECN 标记，接收端回 CNP，发送端降速。阈值设高了，等于没减速，拥塞来了直接撞上 PFC 硬刹车，吞吐抖动大；设低了，稍有排队就降速，带宽跑不满。我们调优的方法是：先按交换机厂商推荐值起步（一般是几十 KB 量级），然后跑 all-reduce 压测，看两个指标——链路利用率和 PFC 帧数量。目标是把 PFC 帧压到接近 0，同时利用率不掉。我们的一个 128 卡集群，把 ECN 阈值从默认的 150KB 降到 60KB 后，PFC 风暴基本消失，all-reduce 带宽利用率从 71% 提到 86%。
注意 ECN 和 PFC 的阈值要联动：ECN 阈值必须明显低于 PFC 触发阈值，否则 ECN 还没起作用，PFC 先动手了，两套机制打架，效果比只开一套还差。
拥塞控制算法选型：DCQCN 还是别的
RoCE 网卡的拥塞控制算法，事实标准是 DCQCN（Data Center Quantized Congestion Notification）。它的参数有好几个旋钮：降速比例 alpha、恢复速率、目标速率。默认参数是给通用数据中心调的，AI 训练的流量模型完全不同——all-reduce 是突发式的大象流，同步点一到，所有节点同时打满。我们的经验：把初始 alpha 调激进一点（降速更果断），恢复速率调快一点，让拥塞过去后迅速回满。有一组实测数据：默认参数下 64 卡 all-reduce 平均带宽 132Gb/s（200G 网卡），调优后到 168Gb/s，提升 27%。
还有一个容易被忽略的：CNP 的处理。接收端回 CNP 的频率和网卡驱动版本有关，老驱动在高压下 CNP 回得慢，发送端降速不及时。升级网卡固件和驱动，有时候比调参数见效更快，我们吃过这个亏，调了一周参数，最后升级驱动解决问题。
实测案例：从 0.62 到 0.85 的 scale 效率
一个 256 卡（32 节点×8 卡）的训练集群，初始 256 卡 scale 效率只有 0.62。排查清单走了一遍：第一步，关掉 PFC 死锁检测的告警盲区，发现两个交换机没开检测；第二步，ECN 阈值从 150KB 降到 60KB；第三步，DCQCN 参数按大象流模型重调；第四步，升级网卡驱动。调完 scale 效率到 0.85，all-reduce 带宽利用率稳定在 85% 以上。整个过程没加一块卡，等于白捡了三成算力。
最后给一份最小检查清单：拓扑无环、PFC 死锁检测开启、ECN 阈值低于 PFC 阈值、DCQCN 按大象流调参、驱动固件最新、压测看 PFC 帧数和利用率。按这个顺序排查，八成问题都能定位。