背景概述

在使用 Atlas 900 A2 PoD 进行大规模分布式训练时，反馈在执行推理或训练作业过程中出现通信算子异常，导致作业卡死或失败。经排查，问题集中表现为 LcalAllReduce 算子报错，伴随 vector core timeout 错误信息，且 errcode 为 0，初步判断非 HCCL 通信框架直接引发。本文基于实际问题场景，系统梳理了从日志分析到根因定位的完整排查路径，并提供可落地的解决方案

问题现象

• 版本信息：HDK 24.1.0.3   CANN 8.0.RC2   pytorch2.1.0.post11
• 训练中在执行 AllReduce 通信阶段出现卡死或异常退出，日志中出现 Plog 报错 EZ9999，fault kernel_name=LcalAllReduce，errcode=0，提示通信算子异常。
• 通过日志分析定位到 LcalAllReduce 为 LCCL的通信算子，非 HCCL 算子。

根因分析

1. 算子定位：LcalAllReduce 属于 LCCL 框架下的低时延集合通信算子，用于高效完成多卡间的 AllReduce 操作。
2. 代码逻辑问题：在 AllReduce 算子实现中，存在一段额外的 flag 状态清理逻辑。该逻辑在多轮次执行过程中可能因时序控制不当，导致通信上下文状态不一致，进而引发通信卡死。
3. 状态管理机制：LCCL 通过 magic 机制保障 flag 状态的正确性与一致性，已具备足够的校验能力。额外的 flag 清理操作属于冗余逻辑，破坏了原有状态管理的稳定性。

解决措施

短期规避方案

开启确定性计算模式，可绕过问题路径，使用不同的通信实现路径，避免触发异常逻辑：

export LCCL_DETERMINISTIC=1

长期解决方案

• 升级至 CANN 8.2.RC1 或更高版本，该问题已修复并正式发布。
• 建议在新项目部署或版本升级时，优先采用 CANN 8.2 及以上版本，以获得更稳定的通信性能与可靠性保障。

总结与扩展

问题识别：当遇到 LcalAllReduce 算子报错，且日志中出现 errcode=0 与 vector core timeout 时，应优先检查当前 CANN 版本是否包含已知修复。

LCCL介绍：

LCAL：Low-latency Collective Acceleration Library，低时延集合加速库

LCCL：Low-latency Collective Communication Library，低时延集合通信库

LCAL= LCCL+ LCOC（Low-latency compute over comm lib通算融合）

相关参考： 确定性计算