在 RoCEv2 智算网络中，PFC 通过 XOFF/XON 做链路级反压，ECN 通过 IP 头 CE 标记触发 DCQCN 源端降速。本文用 CLOS 组网和 All2All incast 场景，拆清楚 PFC 与 ECN 的分工。
关键词：RoCEv2 / PFC / ECN / AllReduce / incast / 无损网络
全文约 6000 字，阅读需 15 分钟，建议收藏后细读。
一、从 AI DC 训练业务丢包引发的血案说起
1、真实案例说明
从两个真实的 AI 训练案例说起：
案例 1：16 节点 GPU 服务器，采用 RoCEv2 以太网，因拥塞丢包导致 AI 训练任务挂死
集群环境：16 节点 GPU 服务器，采用 RoCEv2 以太网，100GbE 网络。
故障现象：多机分布式训练任务随机卡死（Hang），且日志末尾无任何 WARN 或 ERROR 提示。由于未设置 NCCL_TIMEOUT，进程卡住后必须手动 Kill，每次终止需耗费 10 余秒。
排查与根因：经排查发现，该 RoCEv2 网络未配置 PFC（优先级流控制）。在网络发生拥塞时，交换机直接产生丢包。由于 RoCEv2 的传输层具有"Go-Back-N"特性，丢包会导致 RDMA 队列对（QP）直接陷入错误状态，进而使得 NCCL 通信层永久等待对端回复，最终引发整个训练任务的全局死锁。
修复动作：在全网交换机及网卡端统一配置 PFC 优先级 3（Priority 3），并为 RDMA 流量划分独立的无损队列，同时显式设置 NCCL_TIMEOUT=300。修复后，AllReduce 耗时降至 185ms，训练任务恢复稳定运行。
案例 2：某智算中心 400G RoCEv2 Leaf-Spine Fabric 架构，因 Incast 流量拥塞导致训练效率下降 30%
集群环境：某智算中心 400G RoCEv2 Leaf-Spine Fabric 架构，承载大规模 LLM 大模型训练。
故障现象：训练初期 Step Time 约为 1.3 秒，GPU 利用率维持在 90% 左右。但在训练过程中会间歇性出现性能骤降------Step Time 突然飙升至 3.8 秒，GPU 利用率同步大幅下滑。此时 NCCL 通信时间（Communication Time）在 Profiling 中呈指数级暴涨，导致整个训练效率下降超 30%。
排查与根因 ：定位发现故障由 Incast 流量引发的交换机 Buffer 溢出与 PFC 风暴导致。在 AllReduce 的同步通信模式下，多对一的高强度 Incast 流量瞬间击垮了交换机的共享缓冲区。尽管 PFC 触发了反压暂停帧，但由于 PAUSE 帧传播存在时序差，上游设备仍在持续注入流量，最终引发微突发丢包。丢包导致 QP 进入错误状态并触发 RNR 重试，大量 QP 同时报错叠加正常的训练流量，形成了恶性循环的"PFC 反压风暴"，严重拖慢了全局梯度同步。
修复动作：针对 Incast 场景重新规划了交换机共享缓冲区（Shared Buffer），优化了 PFC Xon/Xoff 的水位阈值，并结合 DCQCN（Data Center Quantized Congestion Notification）进行了动态调优，最终消除了偶发丢包与 PFC 死锁，恢复了线性加速比。
二、AI 训练为什么会丢包
2.1、AI 训练业务流量特征必然导致拥塞丢包
AI 训练业务 Many-TO-One 和 ALL-TO-ALL 流量特征看，incast 流导致拥塞不可避免
AI 训练中 Tree 算法做 Reduce 时，叶子向根逐层汇总，根节点或某中间节点在同一时刻收到 N-1 路满速流出现多打一导致拥塞丢包：
Tree 算法把 GPU 组织成一棵归约树：叶子节点向上逐层 Reduce，所有卡的数据归约（如求和）到一张卡，根节点拿到完整归约结果后再 Broadcast 下发。
另外，AllGather 的接收汇聚点 TP（张量并行）里 AllGather 拼激活值同 chunk 的多个 sender 同时打给同一 receiver 的阶段仍存在局部 incast 导致拥塞丢包。
还有 MoE 的热点专家 All-to-All 通信模式容易出现多打一导致交换机拥塞丢包。
2.2、丢包原因分析和影响
1）为什么交换机出现多打一就会导致丢包？
以太端口流量微突发：多张 GPU 在同一微秒级窗口内同时向同一上行口注入数据，交换机共享缓冲区瞬间被填满，触发丢包。即便链路平均带宽利用率不是 100%，但是因为以太端口都是按照最大端口速率向下游端口进行突发，微秒级峰值流量也是 100%。比如两个 NPU 卡向同一个交换机端口发送流量，带宽都只有 40Gbps（端口速率 400Gbps），交换机端口收到的瞬时流量是 400Gbps+400Gbps=800Gbps，但是交换机的出口只有 400Gbps，智算交换机共享缓存一般都不超过 50MB，那么只能兜住（50MB/400Gbps=1ms）流量，交换机的共享缓存就瞬时被冲爆导致队列报文尾丢弃。
2）丢包能否通过重传来解决？
TCP 流量的重传是选择性重传，丢了哪个报文传哪个，比如总共要传 100 个报文，由于瞬时拥塞导致第 90 个报文丢包，第 91 个报文到第 100 个报文正常传输，那么 TCP 会把第 91 个报文重新传输。
AI 训练流量 GPU 卡都是跑的 RoCEv2 流量，RoCEv2 报文的重传机制是 GOGoGO BACK N 重传。如果 RoCEv2 流量第 90 个报文丢了，那么会把第 1 到第 90 报文都重传。
RoCEv2 底层是 RDMA 协议，重传逻辑必须全在 GPU 硬件里以线速跑，不能劳烦 CPU，考虑到成本问题，不会采用耗费大量内存容量的选择性重传机制。
2.3、RoCEv2报文格式和 Go Back N 重传机制
那么我们来看一下 RoCEv2 报文格式：
RoCEv2 本质上还是以太报文，具有标准 ETH 头和 IP 头，与不同 ETH 报文主要差别在于 UDP 头和 IB BTH 头。
· 在 UDP 头中，UDP 的目的端口是固定的 4791 标识 RoCEv2 报文。
UDP 头后面的 IB BTH+头中是对消息的传输层描述，包括 OpCode, Destination QPN, 发送方 PSN 等字段。
看具体报文：
BTH+头的 opcode 字段表示该 RDMA 报文的类型，6 标识 RDMA WRITE First。当报文超过 RDMA 的 MTU 时，RDMA 传输层会做拆包，分为 1 个 RDMA WRITE First（6），多个 RDMA WRITE Middle（7），1 个 RDMA WRITE Last。
Destination Queue Pair 字段表示目的 QP 号，接收端 NIC 拿它做 QP 查找，定位到本端哪个 QP 的 RQ/CQ。
Packet Sequence Number，每个 QP 独立编号，建链时协商 Start PSN，RC 模式逐包 +1，它的作用主要用于去重、保序和丢包重传指示。丢一个 PSN=N，接收端回 NAK 或 ACK 停在 N-1，发送端从 N 起重传全部后续。上面提到的 Go BACK N 丢包重传机制就是通过该字段指示重传报文位置。
三、AI 训练通过 PFC 解决拥塞丢包问题
3.1、PFC 背景
在智算中心 RoCE 网络中，当接收端处理能力跟不上发送速率时，交换机端口缓冲区会被填满，导致尾丢弃（Tail Drop）。对 RDMA 业务来说，哪怕万分之一的丢包率也会引发重传风暴，训练吞吐急剧下降。
PFC（Priority-based Flow Control，基于优先级的流量控制，IEEE 802.1Qbb）的核心思想：当下游队列快满时，向上游发送 PAUSE 帧「叫停」，等缓冲释放后再发「恢复」信号，实现零丢包。
3.2、CLOS 组网下 PFC 反压实现无损过程
在 CLOS 组网中，spine2 同时收到 leaf1 和 leaf3 的流量，出现入口 2*400GE 流量往出口 1*400GE 打的情况，spine2 出口拥塞队列被打满导致丢包。
· PFC 是逐跳（hop-by-hop）、链路级的反压，每一跳独立判断是否需要向上游发 PAUSE
· 它是**基于优先级（Priority）**的，一个优先级队列被暂停，不影响同一链路上其他优先级的流量（这是相比老式 802.3x 全链路暂停的巨大改进）
· 反压是临时刹车，目的是给上游缓冲时间，而非永久断流
PFC 反压上游停流过程如上图，spine2 出口拥塞超过 PFC XOFF 水线，那么 spine2 产生 PFC XOFF 反压报文，向上游 leaf1 和 leaf3 发送反压信号，告知上游本端交换机缓存顶不住了，停流。
Leaf1 和 leaf3 收到 PFC XOFF 反压报文后，停止向下游发送发流，但是源端业务流量并未停止，一定时间后 leaf1 和 leaf3 缓存也超过 XOFF 水线，向上游 NPU1 和 NPU6 发送 PFC XOFF 报文通知源端 NPU 停流。
同理，PFC XON 通知上游开始发流过程也是逐跳通知。
3.3、PFC 报文格式
PFC 是基于优先级队列的反压，该图中虚拟通道六的流量将被暂停，而其它通道的服务不会受到影响。
PFC 反压报文格式如下：
|------------------------|----------------------------------------------------------------------------------------|
| 项目 | 描述 |
| Destination address | 目的MAC地址，取值固定为01-80-c2-00-00-01。 |
| Source address | 源MAC地址。 |
| Ethertype | 以太网帧类型，取值为88-08。 |
| Control opcode | 控制码，取值为01-01。 |
| Priority enable vector | 反压使能向量，其中E(n)和优先级队列n对应，表示优先级队列n是否需要反压。 当E(n)=1时，表示优先级队列n需要反压。 当E(n)=0时，则表示该优先级队列不需要反压。 |
| Time(0)～Time(7) | 反压定时器，单位为接口发送512bits的时间。当Time(n)=0时表示取消反压。 |
| Pad(transmit as zero) | 保留字段。PFC反压帧传输时为0。 |
| CRC | 循环冗余校验。 |
3.4、PFC 的 XON/XOFF 机制
1）PFC 本质是"上游收到 PAUSE 帧后，在一个优先级队列上完全停发一段时间"。XOFF 是"停"，XON 是"恢复"，两者通过同一个 PAUSE 帧的不同字段表达。
· XOFF：接收端发送一个 PAUSE 帧，pause_time > 0（例如 0xFFFF），告诉上游"在这个优先级上停发 pause_time × quanta 时间"。
· XON：接收端发送一个 PAUSE 帧，pause_time = 0，告诉上游"立刻恢复发送"。
2）触发时机
· XOFF 触发 ：接收端某优先级队列的占用深度超过 XOFF 阈值
· XON 触发 ：该队列的占用深度回落到 XON 阈值 以下
3.5、PFC 所需缓存大小
1）PFC 需要的缓存分为两部分：XOFF 触发前的常规缓存 + XOFF 生效期间的headroom 缓存。
Total_Buffer = XOFF_Threshold + Headroom
XOFF_Threshold：触发 XOFF 时的队列深度
Headroom：从 XOFF 触发到上游完全停发期间，继续涌入的数据量
2）Headroom 的大小取决于从 XOFF 触发到上游停发的延迟链
Headroom = (Link_Delay + Processing_Delay + PFC_Frame_Transmit_Time) × Line_Rate × Number_of_Input_Ports
|-------------------------|----------------------------------|--------------------|
| 分量 | 含义 | 400G 下的典型值 |
| Link_Delay | 信号在链路上传播的时间（~5 ns/m，假设 100m 线缆） | 500 ns |
| Processing_Delay | 接收端检测到阈值 → 生成 PAUSE 帧的处理时间 | ~200 ns |
| PFC_Frame_Transmit_Time | PAUSE 帧本身的发送时间（64B @ 400G） | ~1.28 ns |
| 总延迟 | 三者之和 | ~701 ns |
| Line_Rate | 单端口线速 | 400 Gbps = 50 GB/s |
| Number_of_Input_Ports | 可能同时向该端口灌流的源端口数（incast 倍数） | 2（2:1 incast） |
那么Headroom = 701 ns × 50 GB/s × 2 = 70,100 bytes ≈ 68.5 KB
3.6、实际部署门限配置
- XOFF 阈值设太高（>90%）
· 优点：更多缓存可用于吸收突发，减少 PFC 触发的频率
· 缺点：headroom 空间被压缩，一旦触发 PFC，更容易丢包
- XOFF 阈值设太低（<70%）
· 优点：headroom 充足，几乎不会因 PFC 丢包
· 缺点：PFC 频繁触发，容易引发 PFC 风暴（反压扩散到整个网络）
3.7、PFC 的缺陷和限制
1）头阻问题
PFC 的流控粒度是端口+队列优先级，基于源端口号+出端口队列进行流控，一个被阻塞的数据包阻止了该队列中后续所有数据包，容易导致误伤。
如下图，port2 下游交换机拥塞，给 port2 发送 PFC 反压，那么 port1->port2 业务停流，同时 port1->port3 也停流，但是 port3 下游并未拥塞，无需停流，被误伤。
2）死锁问题
PFC 死锁（PFC DeadLock），是指当多个交换机之间因为环路等原因同时出现拥塞，各自端口缓存消耗超过阈值，而又相互等待对方释放资源，从而导致所有交换机上的数据流都永久阻塞的一种网络状态。
如图所示，当 4 台交换机都达到 PFC 门限，都将同时向对端发送 PFC 反压帧，这个时候该拓扑中所有交换机都处于停流状态。当死锁发生时，循环中的任何切换都无法继续。此外，由于 PFC 暂停的反压效应，整个网络或部分网络的吞吐量将变为零。
四、ECN 拥塞控制
4.1、ECN 相对于 PFC 的优点
PFC 是"堵满了别发了"（硬停发），ECN 是"快满了你慢点发"（软降速）。ECN 相对 PFC 反压的本质改进，是从「链路级逐跳刹车」变成「网络层端到端预警 + 源端调速」。ECN 无头阻和死锁问题。
4.2、ECN 的原理
ECN 是 TCP/IP 协议的扩展机制，用于减少网络拥塞导致的数据包丢失。当网络设备检测到拥塞时，会在 IP 数据包头部设置 ECN 标志，而不是直接丢弃。接收端收到标记后，会通知发送端降低传输速率，从而缓解网络拥塞。接收端收到 RoCEv2 报文 IP ECN 标记为"11"，接收端口生成 RoCEv2 CNP ，发给流量发送端。对指定 QP 可选择单个或者多个 CNP 来对 ECN 标记报文的响应。
ECN 机制不仅提高了网络的利用率，还显著降低了丢包率。同时在拥塞缓解后，发送端又可以逐步提高发送速率，恢复正常的传输效率，实现了网络传输速率的动态调整与优化。
4.3、ECN 与 PFC 的差别
|-----|----------------|------------------|
| 维度 | PFC | ECN（+DCQCN） |
| 层级 | L2 链路层 | L3 IP 层（端到端） |
| 动作 | 发 PAUSE，上游停发 | 打 CE 标记，源端降速 |
| 作用域 | 某链路某优先级（粗） | 拥塞点→接收端→发送端（流感知） |
| 速度 | 微秒级，但代价大 | 约 1 RTT，但更平滑 |
| 目标 | 防丢包（最后兜底） | 防拥塞恶化（主力控制） |
| 副作用 | HOL、风暴、死锁、停车问题 | 反应有延迟、依赖 CNP 回传 |
4.4、CLOS 组网下 PFC 和 ECN 配合实现无损过程
设备通过缓存门限来度量队列的缓存使用情况。为了实现对无损队列的流量控制，减缓无损队列的缓存拥塞，可以为无损队列设置两种缓存门限------ECN 门限和 PFC 门限。PFC 门限是入方向的队列缓存阈值，ECN 门限是出方向的队列缓存阈值。
-
当 Device 的无损队列出现拥塞，队列已使用的缓存超过 ECN 门限时，Device 在转发报文中打上 ECN 拥塞标记（将 ECN 字段置为 11）。
-
Server 收到携带 ECN 拥塞标记的报文后，向 Client 发送 CNP 拥塞通知报文。Client 收到 CNP 拥塞通知报文后，降低发包速率。
-
当 Device 的无损队列拥塞加剧，队列已使用的缓存超过 PFC 反压帧触发门限时，Device 向 Client 发送 PFC 反压通知报文。Client 收到 PFC 反压通知报文后，停止发送对应优先级队列的报文。
-
当 Device 的无损队列拥塞缓解，队列已使用的缓存低于 PFC 反压帧停止门限时，Device 向 Client 发送 PFC 反压停止报文。Client 收到 PFC 反压停止报文后，继续发送对应优先级队列的报文。
4.5、结语：从 PFC/ECN 到下一代拥塞控制
PFC 用"停"换"不丢"，ECN 用"标记"换"源端早降速"，两者在 RoCEv2 的无损网络中构成了"ECN 为主力、PFC 做兜底"的经典架构。但这个架构远非完美------静态 ECN 阈值难以适配多样化的 AI 流量，亚 RTT 的微突发依然可能触发 PFC，而 PFC 自身的 HOL、风暴和死锁风险从未真正消失。
这正是业界在积极探索的方向。UEC 联盟的 LLR 和 HPCC 试图从传输层和带内遥测入手，把拥塞控制的精度推到微秒级；华为的 AI-ECN 则尝试让交换机学会动态调整阈值，告别一刀切的静态配置。这些方案各有什么优劣？它们能在多大程度上弥补 RoCEv2 的先天不足？离大规模落地还有多远？
**我会在接下来的几篇文章里逐一拆解。** 为了确保选题贴合大家的需求，我想先听听你的声音------
📊 **投票：你最想先看哪个方案的深度拆解？**
A. UEC LLR（新型链路级重传）
B. AI-ECN（动态阈值调整）
C. HPCC（高精度拥塞控制）
D. 其他（欢迎留言补充）