训练网络调优实战：从PFC到ECN，大模型训练拥塞控制一次说清

16 节点 RoCEv2 集群训练随机 Hang，日志没有 WARN 和 ERROR，每次手动 Kill 需要 10 余秒；400G Leaf-Spine 架构下 Step Time 从 1.3 秒飙升至 3.8 秒，GPU 利用率从 90% 跌到不足 60%。这两类故障背后是同一件事：训练网络拥塞控制失效导致的少量丢包。在 RoCEv2 环境下，千分之一级别的丢包就足以让 RDMA 吞吐腰斩，时延从微秒级膨胀至毫秒甚至秒级；GPU 算力效率折损可达 30% 至 50%。本文从流量模型出发，拆解 PFC 与 ECN 的分工、陷阱与调优闭环。

一、为什么大模型训练网络会拥塞：先看清流量模型

大模型训练的通信流量不是均匀的流，而是两种形态交织：参数面 AllReduce 产生的数百 MB 大象流，需要持续打满链路带宽；流水线并行产生的 KB 级微突发，要求延迟可预测。当这两类流量同时进入交换机共享 Buffer，大象流持续占据队列资源，微突发排队等待，形成毫秒级延迟，GPU 进入空转状态。任一链路变慢，AllReduce 的同步语义都会让全集群等待，这是典型的木桶效应。

RoCEv2 把 RDMA 封装在 UDP 中，目的端口 4791，自身没有流控机制，依赖底层网络的无损保证。UDP 丢了包不会重传，RDMA 协议检测到丢包后触发 Go-Back-N 重传，等待超时通常是秒级。在这个等待窗口内，GPU 不计算，只等待。根据 fromgeek 的测试数据，RDMA 丢包触发重传后的时延恶化是微秒级到秒级的跳跃，这和 GPU 算力效率折损 30% 至 50% 的结论一致；CSDN 论坛上的实践记录同样显示，千分之一丢包率即可使 RDMA 吞吐减半。训练网络拥塞控制解决的不是“更快”，而是“用不丢包换确定性”。

二、PFC：最后一道防线，不是配了就无损

1. PFC 的定位与兜底机制

PFC 基于 IEEE 802.1Qbb，在链路层按优先级队列发送 XOFF/XON 反压帧。交换机一个端口划分 8 个优先级队列，AI 集群通常把 RDMA 流量映射到某一个优先级单独启用 PFC，TCP 流量走其他优先级，避免误伤。PFC 的工作方式是护栏：它不主动调节流量，只在极端突发时暂停上游流量，防止丢包。这个定位决定了它只能兜底，不能作为调优的全部。

2. 常见工程陷阱：反压风暴与 QP 错误

知乎上记录过一个 16 节点 RoCEv2 集群的案例：多机训练随机 Hang，日志无 WARN 无 ERROR，每次手动 Kill 要 10 余秒。根因是未配置 PFC，拥塞丢包导致 RDMA QP 进入错误态，NCCL 永久等待，整个集群死锁。全网配置 PFC Priority 3、划分独立无损队列、设置 NCCL_TIMEOUT=300 之后，AllReduce 耗时降至 185 毫秒，训练恢复稳定。

PFC 配置缺失会死锁，配置不当同样会出问题。反压风暴的成因在于 PFC PAUSE 帧传播存在时序差，多对一 Incast 场景下反压逐级放大，形成“PFC 在堵、ECN 没疏”的循环。CSDN 论坛记录过一个 100G RoCEv2 存储网络的案例：时延从微秒级飙至几百微秒，吞吐砍半，原因是 PFC 疯狂反压，ECN 没有真正从源头压住拥塞。判断信号包括：随机 Hang 无日志、Step Time 间歇性飙升、QP 错误计数上升、RNR 重试增多。PFC 反压风暴原因与排查的核心入口就是这几个指标的联动观察。

3. PFC 调优动作与验证指标

PFC 层的核心动作有四条：全网统一 PFC 优先级，不能各节点各自为政；无损队列独立，RDMA 队列与 TCP 队列分离；配置独立无损队列，避免其他流量挤占；设置 NCCL_TIMEOUT=300，防止 NCCL 永久等待放大为全局死锁。验证指标看三个：AllReduce 耗时稳定在 185 毫秒量级，QP 错误计数归零，RNR 重试不增长。

三、ECN/DCQCN：第一道防线，阈值决定是否有效

1. ECN 与 DCQCN 的协同逻辑

ECN 在 IP 头标记 CE 位，接收端收到标记后生成 CNP 拥塞通知包，反馈给源端，源端据此降速。DCQCN 是 ECN 的执行主体，负责端到端的速率控制，核心逻辑是“疏”。如果把 PFC 比作护栏，ECN 是交警：在拥塞形成之前主动干预，用降速换不丢包。分工逻辑很清楚：ECN 是第一道防线，PFC 是兜底护栏。只开 PFC 会反压风暴，只开 ECN 在极端微突发下仍会丢包，二者必须同时配置并协同工作。

2. ECN 阈值调优：30% 与 70% 两个水位

ECN 阈值怎么设置是实践中最常见的问题。fromgeek 的 RoCEv2 指南给出的基准是交换机 Buffer 的 30% 与 70% 两个水位：低水位提前预警，高水位保留突发吸收空间。阈值设高了，ECN 不触发，拥塞全部交给 PFC 兜底，最终走向反压风暴；阈值设低了，源端频繁降速，有效带宽受损。还有一个容易被忽略的点：400G 端口和微突发场景下 Buffer 深度差异很大，阈值区间需要结合单端口缓存（建议大于 16MB）和 cell 长度（建议不超过 256B）综合评估，不能照搬 25G 时代的经验值。

3. ECN 调优动作与验证指标

ECN 层的动作包括：确认交换机支持线速 ECN 标记与 DSCP 信任；对齐 ECN 阈值与 PFC Xon/Xoff 水位，防止两者打架；结合 DCQCN 动态调优参数。验证指标看 GPU 利用率是否回稳、Step Time 波动是否收窄、CNP 生成速率与源端降速响应是否匹配。

四、Incast 场景下的协同：PFC 和 ECN 如何分工

1. 400G Leaf-Spine 案例拆解：从拥塞到恢复

案例 2 的场景是 AllReduce 同步通信中的多对一 Incast：多个 Leaf 同时向一个 Spine 发送数据，击穿交换机共享 Buffer。PFC 反压时序差引发微突发丢包，QP 进入错误态，RNR 重试增加，PFC 反压进一步加剧，形成风暴。现象是 Step Time 从 1.3 秒飙至 3.8 秒，训练效率下降超过 30%。修复路径三层展开：重规划交换机 Shared Buffer，给无损队列分配足够的水位空间；优化 PFC Xon/Xoff 阈值，缩短反压传播链；结合 DCQCN 动态调优，让 ECN 在源头压降速率。闭环完成后，线性加速比恢复。

2. 正常拥塞与极端突发的两条处理路径

Incast 拥塞下 PFC 与 ECN 如何协同，关键在分层处理：轻度拥塞由 ECN 提前降速，PFC 不触发；极端突发由 PFC 兜底防丢包，ECN 同步从源头压降。只留 PFC 的代价是“堵而不疏”，只留 ECN 的风险是微突发下仍会丢包导致 QP 错误。两者不是替代关系，而是前后两道防线。

五、可复用的训练网络拥塞控制排查 Checklist

大模型训练丢包 GPU 利用率下降和 RoCEv2 多机训练无日志 Hang 这两个问题的排查入口，可以归为四层。

优先级取值不是固定值，Priority 3 和 Priority 5 都有实践记录，关键在现网规划统一，不要出现部分节点走 3、部分走 5 的情况。

六、从 RoCEv2 到 UET：拥塞控制演进与规划启发

超以太网 UET 1. 规范已经发布，面向 AI 与 HPC 场景，支持硬件加速多路径传输，将乱序视为预期并增强拥塞控制。这是一个信号：RoCEv2 单路径、强有序的假设在规模化 AI 集群中正在被重新审视，多路径传输可能成为下一阶段的主流方向。

推理负载的增长也在推动 AI 基础设施分布式化，计算、数据、内存、推理引擎可能跨设施分布，网络边界的要求更高，拥塞控制仍然是一个持续演进的命题。PFC 与 ECN 作为当前 RoCEv2 无损网络的基础能力，理解二者的分工与陷阱，是评估后续多路径协议演进的前提。

数据来源：fromgeek RoCEv2 指南、CSDN 论坛 RoCEv2 实践记录、知乎 RoCEv2 集群案例、36kr 超以太网 UET 1. 报道。

本文由犀思云技术团队撰写，含相关产品服务信息，仅供技术交流。