1. 锯齿不是玄学AllReduce 训练曲线背后发生了什么先说你最痛的那个画面跑千卡/百卡规模的分布式训练打开看板AllReduce 阶段的吞吐曲线像心电图一样每隔几十秒到几分钟就往下掉一截然后又拉上来。Loss 曲线也跟着出现锯齿不是收敛变差是每个 step 的时间被拉长全局吞吐直接打折。很多人第一反应是“NCCL/集合通信库有问题”“网卡有问题”“调度有问题”但在我处理过的案例里至少有一半最终都指向同一个东西RoCEv2 网络的拥塞。为什么 AllReduce 对网络抖动这么敏感因为 AllReduce 本身不是一个一次性的传输它是一轮一轮的梯度同步。以最常见的 Ring AllReduce 为例每张卡既要接收上一张卡的数据又要转发给下一张卡任意一段链路的时延变长整个环都要等。这就像一条流水线每个工位做完自己的活才能传给下一个其中一个工位卡了整条线的节拍就慢下来。网络里哪怕只出现了几十毫秒的 PFC 暂停、微量丢包后的 TCP-style 重传反映到训练曲线上就是一个明显的锯齿。RoCEv2 之所以更容易翻车是因为它默认走的是无损网络交换机靠 PFC优先级流控在端口缓存不够的时候发暂停帧让对端先停一会儿。PFC 本来是保护不丢包但一旦设计不好就会出现“一个端口拥塞暂停帧沿着路径反向扩散”的连锁反应。更隐蔽的是很多问题并没有让训练直接失败而是以周期性的小抖动形式反复出现导致曲线一直锯齿。定位这类问题的正确姿势不是靠猜而是从网卡侧和交换机侧各拿一组计数器对上时间戳找到“谁在最痛”。这篇我完整过一遍用 hccn_tool 和设备侧命令行做现场排查的流程。整个过程控制在 30 分钟左右我会把每一步该看什么、哪些计数是决定性证据、哪些坑最容易误判都讲清楚。适合正在被 AllReduce 性能毛刺折磨的 AI Infra 工程师、算力平台运维以及准备从单机训练迁到 RoCEv2 集群的算法同学。2. 动手前先清点工具、权限和一条命令清单很多人在定位问题时卡在“不知道该找谁要什么”。在开始之前先把必需品列清楚避免排查到一半发现没权限节奏全乱。这里要的权限有三级训练节点上的 root 或至少能执行 hccn_tool 的账号、交换机只读账号、以及训练任务的基本信息。2.1 训练侧要准备什么首先要确认节点上装了完整的昇腾 NPU 驱动和固件hccn_tool 通常随着 driver 一起发布。可以用which hccn_tool确认。如果节点上装的是多卡还需要知道每个容器里的 device id 和物理网卡端口的对应关系。这个对应关系很容易被忽略后面定位到具体端口时会很有用。基本检查命令可以这么跑# 确认工具存在 which hccn_tool # 查看设备健康状态 npu-smi info # 看到 0 号卡当前的 RoCE 网卡链路状态 hccn_tool -i 0 -link -g在昇腾的很多版本里hccn_tool 的参数名可能有细微差异建议先跑hccn_tool -h看看当前版本支持哪些子项。我看到过不少同事直接抄网上的参数结果报错不是说参数抄错了而是 driver 版本升级后命令格式变了。先看一眼帮助菜单比什么都管用。还需要准备训练任务的拓扑信息最好有rank 表或任务启动脚本知道每个进程绑在哪台机器的哪张卡上RoCEv2 通信使用的 IP 和 UDP 端口范围一般默认是 4791物理网络规划图比如哪几个节点接到同一台交换机、有没有跨 SPC 转发。没有这张图后面看到交换机的端口计数器时很可能不知道哪个端口对应哪个 rank。我习惯先把 IP 到端口、端口到交换机端口的映射表铺在屏幕左边右边再开训练日志和计数器输出。2.2 交换机侧要准备什么交换机是定位拥塞的核心现场没有交换机权限前面做的所有网卡侧工作只能证明“有病”没法知道“病灶在哪里”。后面我会用华为 CloudEngine 系列的命令来举例但思路同样适用于其他厂商设备只是命令拼写不同。登录交换机后我一般只做只读操作避免在生产环境里误触发配置变更。可以先看设备基本状态display version display device display interface brief如果你连的是 ToRtop of rack交换机还要知道训练节点上的 RoCE NIC 插在哪个端口。这个可以从交换机上通过 MAC 地址反查端口也可以从节点上的网卡信息直接推。注意排查过程中强烈建议把训练任务保持跑着不要先停任务再排查。很多拥塞现象只在负载下出现空闲链路一切正常。停掉任务后再看计数器等于把案发现场破坏了。2.3 先定一个 30 分钟的排查框架时间有限我给自己定了一个固定节奏前 5 分钟收集训练日志里的 step 耗时曲线锁定抖动出现的节点集合第 5-15 分钟挨个登录可疑节点用 hccn_tool 拉计数器找到网卡侧异常第 15-25 分钟登录交换机对照可疑端口看队列、PFC、buffer 计数最后 5 分钟把两边证据对上确认根因能现场改的先改改完立刻复测。这个框架不是死的但可以保证不会在“猜原因”上浪费太多时间。下面我把每一站讲透。3. 第一站必看hccn_tool 里的那些计数器到底在说什么hccn_tool 是昇腾场景里和 RoCE 网卡打交道的核心工具。很多人只会在模型跑不起来的时候看一眼链路状态但其实它的价值在性能抖动场景里更大链路状态只能告诉你通不通计数器才能告诉你好不好。3.1 链路状态正常不代表网络不堵一条光链路亮着绿色误码率看起来是 0并不代表传输质量就过关。RoCEv2 无损网络里最典型的隐蔽问题就是链路在物理层是 up 的但 PFC 暂停帧已经让网卡侧的数据发送在“走走停停”。# 看链路速率和 MTU hccn_tool -i 0 -link -g这条命令能看到当前端口速率是否协商到预期值比如 100GMTU 是否一致。如果某个节点是 25G其他节点是 100GAllReduce 环里只要经过这个节点整体带宽立刻被拉到 25G 水平曲线就会周期性掉下去。这种问题不算拥塞但也需要先排除掉。3.2 盯住丢包、重传、超时三类计数真正在拥塞场景里需要抓住的是网卡侧的异常计数。我通常用 hccn_tool 或者配合cat /sys/kernel/debug/下的一些 debug 节点拿到下面几类关键指标指标含义出现增长说明什么tx_packets / rx_packets收发包总数看流量整体有没有起来rx_out_of_buffer接收侧因 buffer 不足丢包网卡收包来不及处理大概率是突发rx_roce_timeout接收侧 RoCE 超时重传端到端出现严重时延或丢包pfc_rx收到 PFC 暂停帧数量对端交换机在告诉你“先别发了”pfc_tx发出 PFC 暂停帧数量本端已经吃不下更多数据了在训练出现锯齿的那个时间窗口里我做的第一件事就是把计数器打两遍中间隔 10 秒左右算差值。比如hccn_tool -i 0 -roce -g sleep 10 hccn_tool -i 0 -roce -g两次输出的差值才是这段时间内的“增量”。只看绝对值没有意义因为从任务启动到现在计数可能已经积累了很大。更关键的是要把增量出现的时刻和训练曲线锯齿的时刻对齐。如果有人能够从监控系统里导出 step 耗时曲线那就可以在图上标出每个锯齿低谷对应的时间点再去看计数器在那个时间点附近是否同步飙升。以我实际遇到的案例来说最常见的组合是rx_pfc上涨 rx_out_of_buffer间歇性增加。这两者一旦一起出现基本可以确定网络里发生了拥塞而且是“数据涌向某个端口导致交换机发送侧 buffer 不够然后反向发 PFC 暂停帧”的典型模式。3.3 不要只看一张卡要把可疑节点全看完很多用户拿到一台机器的 hccn_tool 输出发现只有 1 号卡异常就急着下结论。实际上AllReduce 是全局通信一张卡的瓶颈会被整个环放大。我建议把所有参与训练中的节点全部拉一遍至少把可疑节点对应的网卡都看一眼脚本化处理能省很多时间for i in {0..7}; do echo device $i hccn_tool -i $i -link -g done如果所有节点的计数都正常那说明拥塞可能发生在交换机的上联口或者跨设备链路上需要在交换机侧继续看。4. 交换机侧才是半壁江山Huawei 交换机的拥塞证据怎么看如果网卡侧已经看到 PFC 或丢包增长下一步必须登录交换机。真正决定拥塞位置的不是网卡而是交换机端口上的队列、buffer 和 PFC 计数。不懂交换机命令的算法工程师会在这里断线但我可以负责任地说核心命令量并不多几分钟就能上手。4.1 先看端口和队列丢包登录华为交换机后先定位训练设备接入的端口。假设是 10GE0/0/1如下命令能给出非常关键的基础信息display interface 10GE0/0/1这里重点看 discards、errors、CRC 等字段。CRC 错误往往说明光模块/线缆质量有问题而 discards 增高则说明数据在出接口被丢弃很可能已经发生拥塞。更细的要看队列display qos queue statistics interface 10GE0/0/1华为交换机上RoCEv2 一般会被映射到指定队列通常是映射到高优先级队列。如果某个队列的 drop 包数量在锯齿时间窗内猛增而其他队列没有那就说明该队列对应的流量正在过载。这时可以进一步确认这是否就是训练节点物理端口。4.2 PFC 和 buffer拥塞扩散的核心证据无损网络的灵魂就是 PFC。华为交换机上可以用类似下面的命令看 PFC 计数display dcb pfc interface 10GE0/0/1重点看Rx Pause Frames和Tx Pause Frames两个计数。如果某个端口是“发射 PFC 暂停帧”的一方说明它的入口/出口 buffer 不够用正在要求对端停下来。如果某个端口是“接收 PFC 暂停帧”的一方说明它在被上游惩罚。实际定位时我一般不看单次绝对值而是连续两次执行取差值。而且我会把这个变化和网卡侧的计数匹配上。假设网卡 A 的pfc_rx涨了交换机上连到 A 的端口必然显示Tx Pause Frames也在涨。这样两边一对应拥塞方向就清楚了。Buffer 占用率也是重要佐证display qos buffer interface 10GE0/0/1如果端口缓存占用长时间接近满说明该端口一直是热路径如果是在锯齿出现那一刻瞬时满之后立刻回落那就是典型的微突发。4.3 别忘了查 MAC、ARP 和 IPMAC端口绑定这一条是很多人忽略的。RoCEv2 是二层IP 路由混合转发MAC 表错误、ARP 表错误、IP 跟端口绑定不一致都会导致报文被送到错误的物理端口最终在中间设备上被丢掉。华为交换机上有一个很实用的排查思路先找到训练节点网卡的 MAC再用命令反查它在交换机上学习的端口display mac-address mac-address display arp如果同一张网卡的 MAC 在某一段时间内在多个端口之间跳变大概率是网络中出现了环路或重复 IP。设备自检时会有告警但在报障时往往已经被忽略。还有一个常见的加固措施就是把 IP、MAC、端口绑定起来避免错误转发和 IP 冲突。华为交换机的典型做法有两类接口视图下的动态绑定system-view interface 10GE0/0/1 user-bind ip-address 192.168.1.2 mac-address 60f2-XXXX-XXXX或者静态 ARP 绑定arp static 192.168.1.2 60f2-XXXX-XXXX interface 10GE0/0/1在实际集群里如果配置了 DHCP 地址分配同时又有人手工配了静态 IP很可能造成同一个 IP 被两台设备使用。RoCEv2 流量一旦被错误导流表面现象就是某台卡时不时掉速。这时候交换机侧的display arp比对当下的 IP-MAC 对应关系就能一眼看出来。4.4 跨设备链路和负载分担也要瞄一眼如果问题不在接入端口而在于多个交换机之间的上联链路或者 NIC 支持多网卡组 bond就要看链路的负载分担是否均匀。华为交换机常用display eth-trunk 1 display load-balance eth-trunk 1RoCEv2 的三层报文默认用五元组做 hash很多版本的交换机对 UDP 端口号固定的流量很容易出现 hash 极化把所有流量都打在同一条物理链路上其他链路空跑。这个问题在最开始容易被忽略因为所有端口都是 up 的没有物理硬件故障但吞吐和延迟就是上不去训练锯齿会非常规律地出现。碰到这种情况交换机侧的负载均衡配置就很重要了。5. 30 分钟定位路线图一次真实锯齿案例的排查剧本理论讲完我用一个实际场景把这 30 分钟走一遍。你不需要完全复现这个案例但把这个排查链路记住下次遇到问题就能举一反三。5.1 锁定嫌疑节点某次 8 卡机器跑 AllReduce 训练监控曲线显示吞吐每 40 秒掉一次掉幅约 15%。从训练日志找出 step 耗时最大的节点发现总是同一台机器的同一张卡。登上那张卡的节点后先做一次 hccn_tool 计数采样hccn_tool -i 2 -roce -g第二次间隔 10 秒采样发现rx_pfc增量特别大rx_out_of_buffer也在涨。说明这张卡在承受上游的 PFC 暂停指令已经属于被“刹车”的一方。此时不要急因为这张卡只是受害者。PFC 暂停帧是从交换机对应端口传过来的真正的肇事者应该在这台交换机连着的另一侧或者是某个出口端口拥塞后反压过来的。5.2 交换机上逐端口追凶登录这台机器接入的 ToR 交换机找到连接该卡网卡的端口比如 25GE0/0/3。查看该端口的 PFC 计数display dcb pfc interface 25GE0/0/3结果显示这个接口的Tx Pause Frames在锯齿时间窗内一直在涨。也就是说交换机在向网卡发送暂停帧与网卡侧看到的pfc_rx完全对上。再往上游看这台交换机一共有 4 条万兆上联口连到核心交换机其中一条口连续出现 egress queue drop其他 3 条几乎没有流量。这里基本可以确认是负载分担出了问题不是物理链路故障。5.3 从哈希极化到静态绑定问题进一步检查流量特征发现训练节点的 RoCEv2 流都是同一个源目 IP 和同一个 UDP 端口号源端口变化也很有限。交换机的五元组 hash 没有足够分散于是全部命中同一条上联链路。这种场景在多数交换机上都能通过调整 hash 模式解决。但我们也遇到过更隐蔽的情况某台设备的 ARP 表里 IP 和 MAC 对应关系与其他设备冲突导致部分 RoCEv2 报文被转发到了错误的端口。这类问题在没有做 IPMAC端口绑定的集群里尤其容易出现。我后来在处理这类集群时会在交接清单里明确建议网络管理员按照前面写的user-bind或arp static方式做一次绑定梳理至少把训练网段的关键设备固定下来减少“二层转发漂移”这个变量。5.4 现场修复与复测根因锁定在哈希极化之后临时方案是把负载分担算法从五元组改成增强型 hash或者在交换机上启用 flowlet 负载分担。华为交换机大多提供了相关配置入口命令类似eth-trunk load-balance enhanced或flowlet具体以设备实际能力为准。我建议第一次修改时只改一个参数然后立刻看训练曲线。如果锯齿消失说明问题确实在这里如果没有再回退继续下一个变量。改完后训练曲线不能只看 5 分钟至少要跑 2-3 个周期。我遇到过有人在训练开始后的前 10 分钟看到曲线好看就宣布修复完成结果跑了半小时又锯齿了原因是流量模型在 warmup 阶段后发生了变化。复测期间同时再看一次 hccn_tool 的 PFC 计数应该不再有规律性的同步上涨。6. 这类问题的通用修复模板哪些配置改起来最稳定位到具体根因后修复动作一定要有梯度。不是所有问题都值得立刻动交换机配置也不是所有问题都适合只靠端侧自适应。我按“安全程度从高到低”排了一个修复顺序可以当模板用。6.1 先做软性修复确认两边配置一致性很多锯齿其实不是复杂拥塞而是配置不对称。最常见的三类MTU 不一致RoCEv2 要求端到端 MTU 一致部分交换机端口默认 MTU 和网卡不一致时大包会被分片或丢弃PFC 优先级映射不一致交换机上 RoCE 流量必须映射到同一个优先级同时网卡侧 QoS 到交换机队列的映射要完全对应buffer 模式不匹配RoCE 流量建议使用专用 buffer 模式如果交换机配置的是普通模式PFC 阈值很容易触发。这类问题不需要改拓扑也不影响其他业务优先排查。6.2 再调负载均衡和流控策略对于哈希极化优先把 RoCEv2 流量的 hash 因子加宽。避免只用五元组可考虑基于源目 IP、甚至加了随机偏移的增强 hash。如果交换机支持 flowlet可以打开它能把一条逻辑流拆成小段在不同物理链路上转发对长尾流量特别有效。PFC 侧不要乱调参数。一个常见的错误是把headroom调得过大追求完全不丢包结果导致一个端口的拥塞在交换机内部占用大量 buffer反而拖累同设备上其他端口。PFC 的设计目标不是零丢包而是在关键队列上把丢包降到可控范围。如果训练本身对丢包有一定容忍度同时有端到端重传机制PFC 阈值可以适当收紧而不是无限给 buffer。6.3 最后才考虑硬件和物理链路如果计数器显示的是大量 CRC 错误、光功率异常不要指望配置能解决。直接换线、换光模块、换端口才是正路。在 100G/200G 甚至更高速率下AOC/DAC 线缆质量参差不齐有些线缆看起来工作正常但在长时间高负载下会间歇性出现错误这类问题最坑人。交换机上display interface里如果 CRC 错误、错误计数持续增加千万不要和拥塞问题混为一谈。先把物理层问题解决再谈优化。6.4 验证闭环不要只看曲线要看队列计数是否归零修复之后验证分两层第一层看应用侧训练曲线的锯齿频率和幅度是否明显下降step 耗时是否恢复到正常水平第二层看网络侧交换机上之前的 drop 计数和 PFC 计数是否不再增长网卡侧的rx_out_of_buffer是否停止增量。只看第一层有风险因为 buffer 里的历史计数不会自动清零曲线好看可能是偶然流量低谷。我建议修改配置后在交换机上手动reset counters interface清一次历史计数如果操作权限允许的话然后重跑一小段训练确认新的统计是干净的。如果没权限清计数就记录当前值跑 15 分钟后回来对比增量效果一样。7. 从这次排查里我记下的几个教训最后聊几个真实经历里攒下来的教训不一定都在教科书里但遇到时真的能救命。第一个教训是别忽略“抽样时刻”。训练负载是动态的你和网络管理员在同一个时间点取样很可能因为差了 10 秒而看不到拥塞。我后来养成了一个习惯在训练曲线抖动周期的低谷和波峰各采样一次而不是随机取数。如果锯齿周期是 40 秒那就以 40 秒为窗口做两次采样这样更容易抓到证据。第二个教训是交换机的计数器必须“配对”看。只看接入端口会发现它的 PFC Tx 高但如果不同时看对端设备的 PFC Rx你很难判断这是不是同一对端口在互相拉扯。在跨设备故障场景下一定要把两端的交换机、两端的光模块、两端的队列都拉出来对齐。单独一个方向的证据只能证明“有异常”证明不了“谁导致异常”。第三个教训是静态绑定这类“不起眼”的配置反而值得认真对待。RoCEv2 集群通常部署在独立 VLAN 里很多团队认为业务隔离已经做得很干净不需要再做 IPMAC端口绑定。但我在排障中已经不止一次看到因为某台设备的 ARP 表冲突导致交换机把 RoCEv2 报文转发到错误端口后面所有流控和拥塞优化全部变成无用功。网络里 IP 与 MAC 的对应关系不稳定就像地基摇晃上层再好的 QoS 设计都白搭。第四个教训是排障时要把 hccn_tool 和交换机命令当成一套工具用而不是觉得“网卡看网卡、交换机看交换机”。很多看起来是交换机拥塞的问题根子在网卡侧的 MTU 和 PFC 配置不匹配很多看起来是网卡慢的问题根子在交换机负载分担不均匀。只有让两层数据互相印证才能真正做到 30 分钟定位而不是“排查两小时发现只是某根线松了”。在实践中我还保留了一个比较取巧的习惯每次跑大规模训练前先花 5 分钟做一次网络健康快检。所有网卡拉一遍链路状态交换机接入端口拉一遍丢包和 PFC 计数做一个基线快照。等真出问题时基线就是最有力的参照物。没有基线定位一个隐蔽的周期性拥塞很容易像没有锚点的船飘到哪里算哪里。