HCCL 任务下发执行阶段故障诊断实战：从集群心跳机制到算子执行超时定位-酒店常州论坛

HCCL 任务下发执行阶段故障诊断实战：从集群心跳机制到算子执行超时定位

【免费下载链接】hccl集合通信库（Huawei Collective Communication Library，简称HCCL）是基于昇腾AI处理器的高性能集合通信库，为计算集群提供高性能、高可靠的通信方案项目地址: https://gitcode.com/cann/hccl

本篇技术指南聚焦 CANN/HCCL（华为集合通信库）中通信算子任务下发执行阶段的故障定位方法。当通信域初始化与参数面建链完成后，HCCL 会在算子编排与下发过程中依赖 notify 同步机制保证对端就绪，一旦出现进程卡死/退出、网络异常或算子下发不一致，就会触发大范围的执行等待超时。读完本文，你将掌握 HCCL 的两大 DFX 定位机制（集群心跳机制、task exception 机制）的日志解读方法，以及 EI0002 算子执行超时、EI0012 SDMA ERROR、EI0013 ERROR CQE 三类典型故障的完整排查步骤和关键命令。

一、任务下发执行阶段为什么容易"卡死"：同步机制与超时本质

HCCL 一次集合通信算子的完整生命周期可以划分为三个阶段：通信域初始化、参数面建链、任务下发执行。前两个阶段完成后，HCCL 会进行通信算子的任务编排并下发到 Device 侧异步执行。

在算子执行阶段，数据通信前会有一套notify 同步机制来确保对端已准备好接收本端数据。以一次卡间数据搬运（SDMA 为例）为例，整个过程包含三个阶段：

前同步（Post / Wait Ack）：Rank0 读取 Rank1 数据前，需要等待 Rank1 发送 Ack，表示数据已准备完成；
数据传输：Rank0 开始读取 Rank1 数据；
尾同步（Post / Wait DataSignal）：Rank1 等待 Rank0 发送 DataSignal，表示数据已读取完成。

如果 Rank1 未执行 Post Ack，Rank0 的 Wait Ack 任务将一直等待直到超时。因此，算子执行超时的本质是通信双方同步关系失配（参见 notify_wait_timeout_EI0002.md）。

执行超时的常见触发原因包括：

某个 Rank 未下发通信算子；
各 Rank 下发的通信算子不一致；
数据量（count）、数据类型（dataType）、reduce 类型（reduceType）、算法选择等参数不一致；
某个 Rank 由于异常导致进程卡死或退出、网络故障。

正因为同步关系牵一发动全身，任何一个 Rank 的异常都可能导致大部分 Rank 出现执行等待超时。所以任务下发执行阶段故障定位的首要条件，是找到故障点（根节点）的位置，再对症下药。HCCL 为此提供了"集群心跳机制"与"task exception 机制"两套 DFX 手段，下文依次展开。

二、总览定位思路：先定位故障点，再分机制深入

任务下发执行阶段的整体定位思路（原图见 task_exec_stage_troubleshooting.md 中的figures/task_exec_error_debug.png）可以概括为两条递进的排查路径：

优先检索集群心跳异常事件：HCCL 存在集群心跳机制，当某个 rank 节点发现异常时，会通过心跳机制把信息扩散到集群的每个节点。因此可以先在**集群中任意节点的 CANN 日志（run/plog）**中检索是否有心跳异常事件信息打印。如果命中，即可直接锁定故障根节点，相关机制说明与日志格式见集群心跳机制。
其次排查 task exception 报错：若未检索到心跳异常事件日志，则通过 task exception 报错信息排查是否有集群行为不一致问题（如算子下发不一致、参数不一致），排查方法见 task exception 机制。

下面的章节分别深入这两套机制，以及由此引出的 EI0002 / EI0012 / EI0013 三类典型错误码排查实战。

三、DFX 机制一：集群心跳机制——单点故障广播扩散

3.1 机制原理

HCCL 会基于已有的通信域信息，与邻近的 rank 建立起独立的维测链路，以此提供集群的单点故障广播扩散能力。任意 rank 的 plog 日志中都会包含故障根节点信息，从而实现"任意节点日志可定位全局故障"的效果。

[!NOTE] 性能说明 HCCL 会控制维测链路数量和通信数据量，用户不用担心其对通信链路造成性能损失（参见 cluster_heartbeat_mechanism_troubleshooting.md）。

3.2 三类故障探测能力

当前支持的故障探测能力如下表所示：

优先级	异常类型	status（运行日志-run/plog）	ExceptionType（调试日志-debug/plog）	判断标准
1	网络问题	ERROR CQE	Error cqe Occurred	定期轮询 ROCE 驱动重传超次事件，通过 QPN 映射远端 IP
2	进程卡死	STUCK	Stuck Occurred	每隔 1/3 的 HCCL_EXEC_TIMEOUT 时间轮询所有算子的入/出次数，分析是否卡住
3	进程退出	LOST	Heartbeat Lost Occurred	30s 时间内未收到远端的心跳报文

为控制打印数量，当前 Cluster Exception ERROR 日志只打印有效事件的前三个，且优先级为ERROR CQE > STUCK > LOST。如需确认全量的心跳事件，可在 run 目录日志中检索。

3.3 异常事件扩散日志解读：`[HeartbeatAbnormal]`

HCCL 检测到异常事件后，会在集群中进行信息的扩散转发，并将收到的异常事件打印到 run 日志。日志格式为：

[HeartbeatAbnormal]local rank[IP/ID]：crimer rank[IP/ID] status[4异常事件类型]by informer rank[IP/ID]

各字段含义：

HeartbeatAbnormal：代表心跳异常事件；
local rank：当前节点的信息；
crimer rank：根节点（故障源）信息；
status：异常事件类型（ERROR CQE / STUCK / LOST）；
by informer rank：集群故障上报者信息。

可结合关键字HeartbeatAbnormal与 status 状态进行检索，日志示例如下：

[INFO] HCCL(686,python):2025-10-23-07:52:59.191.363 [heartbeat.cc:951] [8970][TaskExecStage][HeartbeatAbnormal]local rank [127.10.0.1/1]: crimer rank [127.10.0.2/2] status[LOST] by informer rank [127.10.0.3/3]

3.4 集群异常汇总日志解读：`Cluster Exception Location`

如果后续出现算子执行报错，并且调用了 task exception 回调函数通知 HCCL，HCCL 会根据已经收到的异常事件，结合HCCL_EXEC_TIMEOUT等超时事件配置，推测出最可能的单点故障原因，打印在 ERROR 日志中。

日志格式为：

[TaskExecStage][HeartbeatAbnormal]Cluster Exception Location[IP/ID], Arrival Time:[星期 月 日 时:分:秒 年], Discoverer:[IP/ID], ExceptionType:[异常类型], Possible Reason:可能原因

各字段含义：

[TaskExecStage][HeartbeatAbnormal]：代表集群故障发生在算子执行阶段，为心跳异常事件；
Cluster Exception Location：集群故障发生位置（根节点）；
Arrival Time：集群故障发生时间（广播到本端的时间）；
Discoverer：集群故障发现节点；
ExceptionType：集群故障的异常类型；
Possible Reason：集群故障发生的可能原因。

检索关键字HeartbeatAbnormal即可定位，日志示例如下：

[ERROR]HCCL(835695,all_reduce_test):2025-10-23-17:28:06.049.385[task_exception_handler.cc:610][835695][TaskExecStage][HeartbeatAbnormal]Cluster Exception Location[IP/ID]:[127.10.0.1/1], Arrival Time:[Thu Oct 23 17:25:58 2025], Discoverer:[127.10.0.1/2], ExceptionType:[Heartbeat Lost Occurred], Possible Reason:1. Process has exited, 2. Network Disconnected

3.5 实战案例：进程卡死或对端心跳丢失

当 CANN 日志中出现关键字Cluster Exception Location时（详见 process_hang_or_peer_heartbeat_loss_example.md），可从报错日志中识别异常类型及异常所在节点信息，按 Possible Reason 给出的方向继续排查：

对端心跳丢失（Heartbeat Lost Occurred）：

[ERROR]HCCL(835695,all_reduce_test):2025-10-23-17:28:06.049.385[task_exception_handler.cc:610][835695][TaskExecStage][HeartbeatAbnormal]Cluster Exception Location[IP/ID]:[127.10.0.1/1], Arrival Time:[Thu Oct 23 17:25:58 2025], Discoverer:[127.10.0.1/2], ExceptionType:[Heartbeat Lost Occurred], Possible Reason:1. Process has exited, 2. Network Disconnected

排查思路：确认异常节点在 Arrival Time 之前是否已提前退出，或节点间网络异常无法连接。

进程卡死（Stuck Occurred）：

[ERROR]HCCL(1219039,all_reduce_test):2025-10-23-21:05:09.859.568[task_exception_handler.cc:610] [1219039][TaskExecStage][HeartbeatAbnormal]Cluster Exception Location[IP/ID]:[127.10.0.1/1], Arrival Time:[Thu Oct 23 21:03:19 2025], ExceptionType:[Stuck Occurred], Possible Reason:1.Host process is stuck, 2.Device task is stuck

排查思路：确认异常节点的业务进程是否卡死或发生了死锁。

网络丢包（Error CQE Occurred）：排查异常节点是否发生了 cqe error（详见第七章 EI0013）。

3.6 故障甄别注意事项

如果训练/推理任务在 notify 超时前被提前杀掉，或 task exception 机制因某种原因未及时调用 callback 通知 HCCL，HCCL 可能没有打印异常信息。此时依然可以通过 run 日志中系统运行过程中的异常事件进行根节点定位，但需要对异常事件进行甄别：
- 一般认为，系统卡住时间附近的LOST / ERROR CQE事件即为导致系统停止的原因；
- 而STUCK 检测时间为（1/3~2/3）× HCCL_EXEC_TIMEOUT，需要注意甄别；
网络异常和进程退出均有可能同时导致 LOST 和 ERROR CQE 事件，需结合心跳事件具体情况来看，例如：两端 rank 互报对端 LOST。

四、DFX 机制二：task exception 机制——算子级失败上报

4.1 机制原理

HCCL 通信算子的任务编排完成后会下发到 Device 侧异步执行。若下发的任务执行失败，会通过回调函数通知 HCCL 异常 task 信息（stream 和 taskId），HCCL 以此检索下发时的 task 信息，打印失败 task 的详细信息及其所在的算子信息（参见 task_exception_mechanism_troubleshooting.md）。

4.2 开启条件

针对以下产品，如果要跟踪 task 级信息，需要通过环境变量 HCCL_DIAGNOSE_ENABLE 手动开启：

Atlas A3 训练系列产品 / Atlas A3 推理系列产品；
Atlas A2 训练系列产品 / Atlas A2 推理系列产品。

4.3 关键日志解读：`Task run failed`/`TaskExecStage`

task exception 的关键日志关键字为"Task run failed" 或 "TaskExecStage"，示例如下：

[ERROR] HCCL(2111667,all_reduce_test):2025-10-24-11:18:29.597.044 [task_exception_handler.cc:908] [2111667][TaskExecStage][Timeout][Host]Task run failed, base information is streamID:[2], taskID[21], tag[AllReduce_127.10.0.1%enp_60000_0_1761275812718970], AlgType(level 0-1-2):[fullmesh-ring-NHR]. [ERROR] HCCL(2111667,all_reduce_test):2025-10-24-11:18:29.597.054 [task_exception_handler.cc:771] [2111667][TaskExecStage][Timeout][Host]Task run failed, groupRank information is group:[127.10.0.1%enp_60000_0_1761275812718970], user define information[], rankSize[4], rankId[2]. [ERROR] HCCL(2111667,all_reduce_test):2025-10-24-11:18:29.597.083 [task_exception_handler.cc:704] [2111667][TaskExecStage][Timeout][Host]Task run failed, opData information is timeStamp:[2025-10-24-11:16:55.490.253], deviceId[2], index[21], count[256], reduceType[sum], src[0x12c0c0013000], dst[0x12c0c0014000], dataType[float32].

三段信息可分别识别出通信算子的关键信息：

base information：HCCL 算子所在的 stream、taskid，以及算子的tag（可根据 tag 识别当前报错的 HCCL 算子，tag 中含通信域名称与算子类型）；
groupRank information：通信域名（group）、通信域的大小（rankSize）以及当前卡在通信域内的 rankId；
opData information：当前算子的入参信息——所在 deviceId、该通信域下的第几个算子（index）、数据量（count）、reduce 类型（reduceType）以及输入（src）和输出（dst）的地址。

报错日志中的group字段为通信域名称（即127.10.0.1%enp_60000_0_1761275812718970），该参数将作用于后续所有排查步骤。

4.4 失败 task 的两类典型

一般情况下，当前只有两种 task 可能会出现失败：

Notify：常见于算子执行阶段等待远端超时（对应 EI0002）；
SDMA：一般在 HCCS 链路异常、多 bit ecc 等场景出现，也有较低概率在远端 core dump 时被触发（对应 EI0012）。

五、EI0002 算子执行超时：从同步失配到根因定位

5.1 问题现象

当发生算子执行超时时，CANN 日志中通常会出现Task run failed和task_exception_handler.cc等关键字（完整排查步骤见 notify_wait_timeout_EI0002.md）：

[ERROR] HCCL(2111665,all_reduce_test):2025-10-24-11:18:29.499.235 [task_exception_handler.cc:908] [2111665][TaskExecStage][Timeout][Host]Task run failed, base information is streamID:[2], taskID[21], tag[AllReduce_127.10.0.1%enp_60000_0_1761275812718970], AlgType(level 0-1-2):[fullmesh-ring-NHR]. [ERROR] HCCL(2111665,all_reduce_test):2025-10-24-11:18:29.499.247 [task_exception_handler.cc:771] [2111665][TaskExecStage][Timeout][Host]Task run failed, groupRank information is group:[127.10.0.1%enp_60000_0_1761275812718970], user define information[], rankSize[4], rankId[0]. [ERROR] HCCL(2111665,all_reduce_test):2025-10-24-11:18:29.499.283 [task_exception_handler.cc:704] [2111665][TaskExecStage][Timeout][Host]Task run failed, opData information is timeStamp:[2025-10-24-11:16:55.493.816], deviceId[0], index[21], count[256], reduceType[sum], src[0x12c0c0013000], dst[0x12c0c0014000], dataType[float32].

5.2 排查步骤

步骤 1：获取通信域内所有 Rank 位置

根据通信域名称检索所有参与 Rank，可执行命令：

grep -rn "Entry-HcclCommInit" run/plog | grep "<通信域名称>"

以通信域127.10.0.1%enp_60000_0_1761275812718970为例，示例中展示了通信域大小为ranks[4]以及 rank0~3 的 run 日志位置，再根据 run 日志找到对应的 debug 日志位置：

run/plog/plog-2111667_20251024111652406.log:[INFO] HCCL(2111667,all_reduce_test):2025-10-24-11:16:52.725.226 [op_base.cc:1292] [2111668]Entry-HcclCommInitRootInfoInner:ranks[4], rank[3], rootinfo: host ip[127.10.0.1] port[60000] nicDeploy[1] identifier[127.10.0.1%enp_60000_0_1761275812718970], deviceLogicId[3] run/plog/plog-2111665_20251024111652405.log:[INFO] HCCL(2111665,all_reduce_test):2025-10-24-11:16:52.724.374 [op_base.cc:1292] [2111667]Entry-HcclCommInitRootInfoInner:ranks[4], rank[2], rootinfo: host ip[127.10.0.1] port[60000] nicDeploy[1] identifier[127.10.0.1%enp_60000_0_1761275812718970], deviceLogicId[2] run/plog/plog-2111668_20251024111652406.log:[INFO] HCCL(2111668,all_reduce_test):2025-10-24-11:16:52.719.213 [op_base.cc:1292] [2111665]Entry-HcclCommInitRootInfoInner:ranks[4], rank[0], rootinfo: host ip[127.10.0.1] port[60000] nicDeploy[1] identifier[127.10.0.1%enp_60000_0_1761275812718970], deviceLogicId[0] run/plog/plog-2111666_20251024111652405.log:[INFO] HCCL(2111666,all_reduce_test):2025-10-24-11:16:52.719.502 [op_base.cc:1292] [2111666]Entry-HcclCommInitRootInfoInner:ranks[4], rank[1], rootinfo: host ip[127.10.0.1] port[60000] nicDeploy[1] identifier[127.10.0.1%enp_60000_0_1761275812718970], deviceLogicId[1]

步骤 2：判断是否为全量超时

检查通信域内所有 rank 的 debug 日志：所有 rank 都报通信算子执行超时为全量超时，仅部分 rank 报超时为非全量超时（流程原图见 notify_wait_timeout_EI0002.md 中的figures/op_execute_timeout_debug.png）。

非全量超时的两种情形：

部分 rank 无异常日志：如果通信域内某个 rank 不存在 debug 日志或 debug 日志中没有 ERROR 信息，说明该 rank未下发通信算子。该场景非 HCCL 问题，需要业务侧排查没有下发通信算子的原因。
部分 rank 存在其他报错：如果某个 rank 的 debug 日志有 ERROR 报错，但不是算子执行超时报错，应优先分析该 rank 的首报错——通常首报错为根因，其余 rank 的超时属于连带现象。该场景非 HCCL 问题。

全量超时则需进一步分析：

检查通信参数是否一致：检查所有 rank 报错日志中的算子参数是否一致——通信算子、count、dataType、reduceType、通信域名称是否完全一致。如果不一致，该场景非 HCCL 问题，需要业务侧进一步分析算子下发不一致的原因。如下案例中，同一个通信域下 rank0 报错在 AllReduce 算子，而 rank1 报错在 AllGather 算子，则需要从业务上进一步排查根因：

# rank0报错日志: tag[AllReduce_127.10.0.1%enp_60000_0_1761275812718970], AlgType(level 0-1-2):[fullmesh-ring-NHR]. [ERROR] HCCL(2111665,all_reduce_test):2025-10-24-11:18:29.499.247 [task_exception_handler.cc:771] [2111665][TaskExecStage][Timeout][Host]Task run failed, groupRank information is group:[127.10.0.1%enp_60000_0_1761275812718970], user define information[], rankSize[4], rankId[0]. [ERROR] HCCL(2111665,all_reduce_test):2025-10-24-11:18:29.499.283 [task_exception_handler.cc:704] [2111665][TaskExecStage][Timeout][Host]Task run failed, opData information is timeStamp:[2025-10-24-11:16:55.493.816], deviceId[0], index[21], count[256], reduceType[sum], src[0x12c0c0013000], dst[0x12c0c0014000], dataType[float32]. # rank1报错日志: tag[AllGather_127.10.0.1%enp_60000_0_1761275812718970], AlgType(level 0-1-2):[fullmesh-ring-NHR]. [ERROR] HCCL(2111666,all_reduce_test):2025-10-24-11:18:29.513.764 [task_exception_handler.cc:771] [2111666][TaskExecStage][Timeout][Host]Task run failed, groupRank information is group:[127.10.0.1%enp_60000_0_1761275812718970], user define information[], rankSize[4], rankId[1]. [ERROR] HCCL(2111666,all_reduce_test):2025-10-24-11:18:29.513.787 [task_exception_handler.cc:704] [2111666][TaskExecStage][Timeout][Host]Task run failed, opData information is timeStamp:[2025-10-24-11:16:55.489.331], deviceId[1], index[21], count[256], src[0x12c0c0013000], dst[0x12c0c0014000], dataType[float32].

检查算子下发时间：如果所有 rank 的算子参数一致，可排查通信域内 rank 之间算子的下发时间差，即比较各 rank 报错日志中的timeStamp。若不同 rank 的算子下发时间间隔超过HCCL_EXEC_TIMEOUT（默认 1836 秒），所有 rank 都会等待超时，此时需从业务上排查该时间间隔是否符合预期；若符合预期，可通过HCCL_EXEC_TIMEOUT环境变量指定合适的超时时间。可在日志中检索当前配置的超时时间：
```
grep -r "HCCL_EXEC_TIMEOUT" run/plog
```

5.3 疑难场景：开启算子级行为跟踪

若上述排查均符合预期但仍难以定位，可开启HCCL_ENTRY_LOG_ENABLE环境变量后复现一次用例。该环境变量会在每次通信算子下发后，在 log/run/plog 目录下打印一次日志，记录通信算子下发的入参信息，从而排查每个 rank 上下发的通信算子是否存在异常：

export HCCL_ENTRY_LOG_ENABLE=1

开启后，每次通信算子下发都会打印详细入参：

[INFO] HCCL(3015875,python):2025-03-07-11:43:32.305.623 [hccl_opbase_atrace_info.cc:56][3017221]Entry-HcclAllReduce: tag[AllReduce_127.10.0.1%eth_60000_0_1741318944927847], sendBuf[0x1241d3dcdc00], recvBuf[0x124702f40200], count[10746295], dataType[float32], op[sum], localRank[0], streamId[7],comm[0xfffe380078d0], deviceLogicId[0] [INFO] HCCL(3015875,python):2025-03-07-11:43:32.306.413 [hccl_opbase_atrace_info.cc:56][3017183]Entry-HcclAllReduce: tag[AllReduce_127.10.0.1%eth_60000_0_1741318944927847], sendBuf[0x1244bfffe000], recvBuf[0x1244bfffb400], count[1024], dataType[float32], op[sum], localRank[0], streamId[2],comm[0xfffe380078d0], deviceLogicId[0]

可据此检查：

所有 Rank 是否均已下发通信算子；
算子顺序是否一致；
count、dataType、reduceType 是否一致；
是否存在异常 Stream。

典型案例：多流并发导致的 notify 资源错耗。如上日志表明业务在同一通信域127.10.0.1%eth_60000_0_1741318944927847中下发了两个 AllReduce 算子，但下发在两条不同的 stream（streamId[7] 与 streamId[2]）上。NPU 上多流并发执行，若业务没有正确实现流执行的同步机制，这两个处于同一通信域下的 AllReduce 算子会并发执行。由于 HCCL 在同一个通信域下的通信算子资源复用，并发执行会导致 notify 等资源被错误消耗，从而产生无法预期的报错（如执行超时报错或精度异常等）。

六、EI0012 SDMA ERROR：内存拷贝任务异常

6.1 问题现象

打屏日志中出现 EI0012 错误码，关键字为Execution_Error_SDMA：

[PID: 3480365] 2025-12-24-14:10:31.094.189 Execution_Error_SDMA(EI0012): SDMA memory copy task exception occurred. Remote rank: [4800]. Base information: [streamID:[351], taskID[5], taskType[Memcpy], tag[], AlgType(level 0-1-2):[null-null-null].]. Task information: [src:[0x12c180000000], dst:[0x12c041800000], size:[0x80], notify id:[0xffffffffffffffff], link type:[HCCS], remote rank:[0]]. Communicator information: [group:[], user define information[], rankSize[0], rankId[0]].

CANN 日志中同时存在关键字"fftsplus sdma error"（完整说明见 sdma_error_EI0012.md）：

[ERROR] RUNTIME(57096,python3.10):2025-05-12-20:55:44.705.025 [task_info.cc:1170]57288 PrintSdmaErrorInfoForFftsPlusTask:fftsplus task execute failed, dev_id=0, stream_id=50, task_id=21, context_id=18, thread_id=0, err_type=4[fftsplus sdma error] [ERROR] RUNTIME(57096,python3.10):2025-05-12-20:55:44.705.031 [task_info.cc:1270]57288 TaskFailCallBackForFftsPlusTask:fftsplus streamId=50, taskId=21, context_id=18, expandtype=1, rtCode=0x715006c,[fftsplus task exception], psStart=0x0, kernel_name=not found kernel name, binHandle=(nil), binSize=0. [ERROR] HCCL(57096,python3.10):2025-05-12-20:55:44.706.132 [task_exception_handler.cc:947] [57288][TaskExecStage][Timeout][Host]Task run failed, base information is streamID:[32], taskID[21], tag[AllGather_group_name_0], AlgType(level 0-1-2):[fullmesh-ring-H-D].

6.2 可能原因

SDMA ERROR 的本质是在执行 SDMA 内存拷贝任务时发生了页表转换失败，即内存拷贝的输入或输出地址未分配内存、分配的内存小于拷贝大小，或分配的内存已被释放。常见根因场景：

下发通信算子后，未执行流同步确认算子执行完成就析构通信域：通信域析构时会释放集合通信的 HCCL Buffer 地址，导致 SDMA 内存拷贝时页表转换失败。可在 CANN 日志的 run 目录下检索通信域销毁时间：
```
grep -r "Entry-HcclCommDestroy" log/run/plog
```
网络链路故障（Atlas A3 训练/推理系列产品）：需要检查两端之间的链路状态。
传入的输入或输出地址实际分配的内存大小小于传入的数据量 count。

七、EI0013 ERROR CQE：RoCE 报文重传超时

7.1 问题现象

ERROR CQE 在 HCCL 中代表RoCE 报文的重传超时，出现后必然伴随集群卡死导致超时。HCCL 会定期轮询 RoCE 驱动获取其事件，用户可以通过接口HcclGetCommAsyncError查询是否发生 ERROR CQE 报错（完整说明见 error_cqe_report_EI0013.md）。

打屏日志中的 EI0013 错误码，关键字为Error ROCE CQE：

[PID: 3448331] 2025-12-04-21:59:08.232.310 Execution Error ROCE CQE(EI0013): An error CQE occurred during operator execution. Local information: server 127.0.0.1, device ID 0, device IP 127.10.0.1. Peer information: server 127.0.0.2, device ID 1, device IP 127.10.0.2. Possible Cause: 1. The network between two devices is abnormal. For example, the network port is intermittently disconnected.2. The peer process exits abnormally in advance. As a result, the local end cannot receive the response from the peer end. Solution: 1. Check whether the network devices between the two ends are abnormal.2. Check whether the peer process exits first. If yes, check the cause of the process exit.

CANN 日志中同时存在关键字error cqe status：

[ERROR] ROCE(2040034,alltoall_test):2025-09-15-08:38:12.776.612 [hns_roce_lite.c:630]hns_roce_lite_handle_error_cqe(630) : error cqe status: 0x15 ... [ERROR] HCCL(2040034,alltoall_test):2025-09-15-08:38:13.607.432 [heartbeat.cc:1229] [2040666][TaskExecStage][HeartbeatAbnormal][ROCE CQE ERROR]cqe error status[12], time:[2025-09-15 08:38:12.776654],localInfo{server[127.10.0.1],deviceId[127.10.0.1],deviceIp[127.11.0.1]}, remoteIP{server[127.10.0.2],deviceId[127.10.0.2],deviceIp[127.11.0.2]}

7.2 可能原因与解决方法

本端给对端发包后在指定时间内未收到确认回复，即触发 ERROR CQE，表明两端之间的网络通道异常、对端断开连接或连接状态差；除网络因素外，对端进程异常退出也会导致本端收不到回复。

首先根据报错信息确认 ERROR CQE 远端（上述日志中localInfo与remoteIP分别代表本端和远端的 device ip），再基于硬件资源信息找到对应 rank 所在计算节点或日志，按以下顺序排查：

排查网络问题：通过hccn_tool工具查询是否有网口闪断记录，如下结果表示网口在 10:13:50 2025 时发生了端口断链，此时若有集合通信算子执行则会产生 ERROR CQE，需要进一步排查网口闪断原因：

$ hccn_tool -i 0 -link_stat -g [devid 0]current time : Tue Oct 28 21:46:46 2025 [devid 0]link up count : 2 [devid 0]link down count : 1 [devid 0]link change records : [devid 0] Sun Oct 5 10:13:51 2025 LINK UP [devid 0] Sun Oct 5 10:13:50 2025 LINK DOWN [devid 0] Sun Oct 5 10:13:35 2025 LINK UP

排查对端进程：确认对端业务进程在本端发生 ERROR CQE 时是否先异常退出或已进入资源销毁流程，可通过对端业务日志或 plog 日志确认对端进程的异常退出时间是否早于本端 ERROR CQE 时间。
调整重传参数：若环境变量配置的 HCCL_RDMA_TIMEOUT（重传超时时间）及 HCCL_RDMA_RETRY_CNT（重传次数）较小，链路状态不佳时容易触发 ERROR CQE，可将环境变量调大。

其中status[12]代表 RoCE 报文重传超时，其他状态码极为少见，遇到后请联系技术支持。

八、HCCL_EXEC_TIMEOUT：执行同步等待时间配置

无论是心跳机制的 STUCK 检测窗口（每 1/3 个 HCCL_EXEC_TIMEOUT 轮询），还是 EI0002 超时判定，都围绕HCCL_EXEC_TIMEOUT展开。该环境变量用于控制设备间执行时同步等待的时间：不同设备进程在分布式训练或推理过程中存在卡间执行任务不一致的场景（如仅特定进程会保存 checkpoint 数据），在该配置时间内各设备进程等待其他设备执行通信同步（完整参数说明见 HCCL_EXEC_TIMEOUT.md）。

Atlas A2 训练/推理系列产品（HOST 与 HOST_TS 模式）：单位为 s，取值范围 [0, 2147483647]，默认 1836，支持整数秒配置；配置为 0 时代表永不超时。
Atlas A3 训练/推理系列产品（AI_CPU 与 AICPU_CacheDisable 模式）：单位为 s，取值范围 [0, 2147483647]，默认 1836，配置为 0 时代表永不超时。
AIV 模式：单位为 s，取值范围 [0, 1091]，默认 1091，支持十毫秒级精度配置（如配置 0.05 表示 50 毫秒）；若设置为 0 或超出最大值 1091，将按照 1091 处理。实际生效超时时间为interval*N*10⁻³毫秒（interval 为硬件支持的算子超时最短时间间隔，可通过 aclrtGetOpTimeoutInterval 接口获取，N 取 [1, 254] 内整数，不匹配时向上对齐）。
Atlas 训练/推理系列产品：单位为 s，取值范围 (0, 17340]，默认 1836；系统实际设置的超时时间 = 环境变量取值先整除 68 再乘以 68（取值小于 68 时按 68s 处理），例如 HCCL_EXEC_TIMEOUT=600 时实际生效为 8×68=544s。

配置示例：

export HCCL_EXEC_TIMEOUT=1800

从源码结构看，该环境变量的解析与执行超时管理在 src/common/alg_env_config.cc 与 src/ops/op_common/exec_timeout_manager.h 中实现，属于 HCCL 执行阶段超时控制的核心配置。
使用约束：若通过HcclCommConfig的hcclExecTimeOut参数配置了通信域粒度的同步等待时间，则以通信域粒度的配置为准，环境变量不再生效。

九、总结：任务下发执行阶段故障排查速查

步骤	动作	关键命令/日志关键字	结论指向
1	任意节点检索心跳异常	`grep "HeartbeatAbnormal"`run/plog	命中则按`Cluster Exception Location`定位根节点
2	未命中则查 task exception	`Task run failed`/`TaskExecStage`	判断失败 task 类型（Notify/SDMA）
3	定位通信域所有 rank	`grep -rn "Entry-HcclCommInit" run/plog \\| grep "<通信域名称>"`	获取各 rank 日志位置
4	判断是否全量超时	比对各 rank debug 日志	非全量→查首报错/未下发算子；全量→查参数一致性
5	检查参数一致性	比对 tag/count/dataType/reduceType	不一致→业务侧算子下发问题
6	检查下发时间差	比对 timeStamp 与 HCCL_EXEC_TIMEOUT	超差→调整超时或业务节奏
7	疑难场景开启算子级跟踪	`export HCCL_ENTRY_LOG_ENABLE=1`	排查算子下发顺序、Stream 并发
8	SDMA ERROR	`Execution_Error_SDMA`/`fftsplus sdma error`	查通信域析构时机、Buffer 内存大小
9	ERROR CQE	`Error ROCE CQE`/`error cqe status`	查网口闪断（hccn_tool）、对端进程退出

故障定位的两条主线始终是：先通过集群心跳机制找到故障根节点，再通过 task exception 机制确认算子级行为是否一致。当心跳机制因任务被提前杀掉等原因未能打印异常时，依然可通过 run 日志中的 LOST / ERROR CQE / STUCK 事件结合时间窗口甄别根因。更多入口可参考故障诊断索引，以及心跳机制说明 cluster_heartbeat_mechanism_troubleshooting.md、task exception 定位思路 task_exception_mechanism_troubleshooting.md 与任务执行阶段定位思路 task_exec_stage_troubleshooting.md。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析