1. 背景概述在基于 Atlas 900 A2 分布式训练时，当代码逻辑存在异常-，可能导致不同设备下发的通信算子序列或参数不一致。这种不一致性在首次HCCL建链时可能通过校验，但在后续执行阶段会引发算子执行失败或通信超时，最终导致训练作业异常终止。 2. 问题现象在进行 8 节点分布式训练作业时，作业在运行一段时间后异常终止，系统提示昇腾报错。具体表现为作业在运行约 7200 秒后，多个节点同时上报超时错误，导致任务失败。 3. 原因分析 3.1 初步日志定位首先检查 Worker-0 节点的 plog 日志，发现首个报错为 EI9999，具体信息为 hccl fftsplus task timeout。报错时间为 11-04 07:47，超时阈值为 7200s。随后作业整体失败。进一步排查发现，该超时报错在所有节点上均存在（全量报错）。然而，回溯 Worker-0 在报错前 7200 秒内的日志，仅发现代码中关于“丢弃不合规数据”的打印信息，并未发现任何与通信超时或算子执行失败相关的异常日志。这表明问题并非由单纯的通信链路中断或网络抖动引起，而是更深层的逻辑或算子执行问题。 3.2 深入分析算子下发一致性重新深入分析 plog 日志，重点关注报错数量较多的节点。发现 Worker-4 节点的报错信息数量显著多于其他节点，且其报错日志中均包含 task_exception_handler.cc 的打印，这通常指示算子执行阶段发生了失败。进一步分析 Worker-4 的 plog 日志，发现存在卡间算子下发不一致的现象。通过对比各节点下发算子的时间戳，发现异常发生在 11-04 05:47 左右，这与 7200 秒的超时时间窗口相吻合。为了快速判断各节点算子下发的一致性，可以使用以下命令进入问题节点的 debug/plog 目录进行查询：# 查询具体 HCCL 相关信息 for i in ">i"; grep -ran "HCCL" $i ;done 通过查询所有节点的 taskID 下发情况：# 查询所有节点下发算子信息 for i in ">i"; grep -ran "taskID" $i ;done 此外，可以使用以下命令快速统计并判断算子是否一致：grep "run failed, base info" -r |awk '{print $(NF-2)}'|sort|uniq -c 3.3 根因确认经确认，该报错并非昇腾底层硬件或驱动缺陷，而是由于代码逻辑导致不同节点或不同卡下发的通信算子不一致。在分布式训练中，所有参与通信的设备必须执行完全相同的算子序列。如果业务代码中存在条件分支（如 if-else 判断数据有效性），且不同设备进入分支的逻辑不一致，就会导致部分设备下发了某些通信算子，而其他设备没有下发。HCCL 在首次建链时可能通过校验，但在后续执行阶段，未下发算子的设备会一直等待，直到触发超时机制，从而引发 EI9999 超时错误。 4. 解决方案针对此类由算子下发不一致导致的故障，建议从以下角度进行排查和优化： 1.检查业务代码逻辑： ○重点排查数据加载、预处理以及模型前向传播过程中的条件分支逻辑。确保所有 Rank 和设备在相同输入条件下执行完全相同的代码路径。 ○特别关注涉及“丢弃数据”、“动态形状”或“条件跳过”的逻辑，确保这些操作在所有设备上同步进行。 2.排查不一致节点的打屏日志： ○针对算子下发不一致的节点（如本例中的 Worker-4），检查其打屏日志中是否有 Python 异常或业务逻辑报错。这些日志往往能提供代码执行路径偏离的线索。 3.调整任务分配或数据策略： ○如果业务逻辑确实存在非对称性（如某些节点负责特殊任务），需确保这些特殊任务不影响全局通信算子的同步下发，或调整数据分配策略以保证通信一致性。 4.通用排查命令参考： ○当遇到全量 TaskExceptionHandler 报错时，可通过搜索 count 或 dataType 观察每个 Device 的下发情况。 ○若发现某些 Device 的 report timeout 搜索结果明显少于其他 Device，说明该 Device 与其他 Device 不同步，应优先分析该 Device 的日志。 5. 总结与扩展 5.1 排查算子下发一致性的方法 ●方法一：在全量 TaskExceptionHandler 报错情况下，通过全量搜索 count 或 dataType 内容观察每个 Device 的下发情况。例如，若 16 个 Device 报错，但搜索 count[1] 仅找到 15 个结果，则说明有一个 Device 的下发算子与其他不同。可通过搜索特定 tag[xxx] 进一步定位差异。 ●方法二：全量搜索 report timeout。若某个 Worker 或 Device 的搜索结果明显少于其他节点，说明该设备与其他设备不同步，应优先分析该设备的日志。 5.2 关于 EI0005 与 EI9999 的关联说明 HCCL 通信算子在首次建链时会进行严格的入参校验。如果存在入参不一致的情况，会上报 EI0005（卡间集合通信参数不一致）。然而，在某些场景下，首次建链时算子入参校验通过，但后续重新下发算子时，由于业务逻辑变化导致入参不一致，HCCL 为了节省资源会直接复用之前的通信资源，而不会重新进行建链校验。因此，后续调用时不会再次触发 EI0005，而是直接导致算子执行阶段失败，最终表现为 EI9999 超时错误。建议：在开发过程中，务必保证所有 Rank 和设备在每一个训练步（Step）中执行的算子序列和参数完全一致，避免使用可能导致非对称执行的动态逻辑。