--- title: Atlas 900 A3 AICPU占满导致AICPU算子执行卡死-官方技术文章-Atlas Community description: 在大规模分布式深度学习训练场景中，通信效率是影响整体训练性能的关键因素之一。Atlas 900 A3 SuperPod 作为高性能AI训练集群，广泛应用于大模型训练任务。在实际使用过程中，当模型训练采用多通信域并发策略并开启算子重执行功能时，偶发出现 HCCL 通信 notify/wait 超时问题，导致训练任务卡死或异常退出。该问题在特定算法编排下具有稳定复现性，严重影响训练稳定性与效率。 本 keywords: Atlas,AICPU,占满导致,算子执行卡死,官方技术文章,Community,背景概述,问题现象 url: https://www.hiascend.com/developer/techArticles/20260603-10?envFlag=1 section: (其他) --- # Atlas 900 A3 AICPU占满导致AICPU算子执行卡死-官方技术文章-Atlas Community URL: https://www.hiascend.com/developer/techArticles/20260603-10?envFlag=1 描述: 在大规模分布式深度学习训练场景中，通信效率是影响整体训练性能的关键因素之一。Atlas 900 A3 SuperPod 作为高性能AI训练集群，广泛应用于大模型训练任务。在实际使用过程中，当模型训练采用多通信域并发策略并开启算子重执行功能时，偶发出现 HCCL 通信 notify/wait 超时问题，导致训练任务卡死或异常退出。该问题在特定算法编排下具有稳定复现性，严重影响训练稳定性与效率。 本 关键词: Atlas,AICPU,占满导致,算子执行卡死,官方技术文章,Community,背景概述,问题现象 官方技术文章 [了解详情](https://www.hiascend.com/zh/developer/techArticles) Atlas 900 A3 AICPU占满导致AICPU算子执行卡死 Atlas 900 A3 AICPU占满导致AICPU算子执行卡死 模型训练 Released: 2026/06/03 ## 背景概述 在大规模分布式深度学习训练场景中，通信效率是影响整体训练性能的关键因素之一。Atlas 900 A3 SuperPod 作为高性能AI训练集群，广泛应用于大模型训练任务。在实际使用过程中，当模型训练采用多通信域并发策略并开启算子重执行功能时，偶发出现 HCCL 通信`notify/wait`超时问题，导致训练任务卡死或异常退出。该问题在特定算法编排下具有稳定复现性，严重影响训练稳定性与效率。 本文基于实际故障排查过程，从问题现象、根因分析到解决方案进行系统性梳理，旨在为开发者提供可复用的诊断思路与优化建议。 ## 问题现象 在模型训练过程中，当切换为新的算子切分策略后，系统在多通信域并发场景下稳定复现 HCCL 通信`notify/wait`超时问题。具体表现为： 1、主节点日志中出现`HCCL notify wait timeout`错误； 2、通信流 ID 为`568`的通信任务在`stream_id=568`的`pos=1049`处卡住，任务类型为`Notify wait`，`notify_id=1442`； 3、对端节点日志显示通信本端为`local`，表明为主从流同步异常； 4、该问题在开启`HCCL_OP_RETRY_ENABLE`算子重执行特性后尤为明显。 ## 根因分析 通过多维度日志分析，定位问题根源如下： 1、通信流依赖链路异常在 stream_id=568 的 pos=1049 处，任务为 Notify wait，等待 notify_id=1442 的事件完成。进一步定位该 notify_id，发现其对应的是一个通信任务流，其 head=461 处卡在 Event wait 上，event_id=6。 2、事件依赖任务卡死搜索 event_id=6，发现其位于 stream_id=2 的 pos=461 处，任务为 AICPU 算子。该算子未执行至 pos=487 的 event_record，表明其处于阻塞状态。 3、AICPU 资源竞争与依赖死锁该 AICPU 算子执行耗时正常，但其执行被持续阻塞；深入分析发现，当前模型共启用 14 个通信域，且开启了 HCCL_OP_RETRY_ENABLE；在该模式下，AICPU kernel 需持续确认通信状态并为重执行状态机信号，导致其在通信算子完成前持续占用资源；而通信算子在算法编排中依赖 AICPU 算子的执行结果，形成“通信等 AICPU 执行，AICPU 等通信完成”的循环依赖，最终导致死锁。 4、验证与确认通过替换 AICPU 算子或算子重执行功能后，问题消失，进一步验证了该根因。 ## 问题根因 多个通信域并发展开，且开启算子重执行功能，导致 AICPU kernel 被持续占用。而通信算子在算法编排中依赖 AICPU 算子的执行完成，形成资源竞争与逻辑死锁，最终引发`notify/wait`超时。 ## 解决措施 针对上述问题，提出以下可落地的解决方案： 1、算子重执行功能若业务对通信容错要求不高，建议`HCCL_OP_RETRY_ENABLE`，避免 AICPU 持续保持通信状态，释放资源占用。 2、替换或优化 AICPU 算子将原依赖 AICPU 执行的算子替换为可在 AI Core 上高效执行的算子，减少对 AICPU 资源的依赖。 3、调整算法编排逻辑重构通信算子与 AICPU 算子的执行顺序，避免通信任务对 AICPU 算子的直接依赖，实现异步执行。 ## 建议与总结 1、AICPU 资源有限，需合理控制并发Atlas 900 A3 SuperPod 的 AICPU 资源有限，通信算子默认使用 AI_CPU 模式展开。建议在开启算子重执行特性时，同时下发的通信算子数量不超过 6 个，以避免资源争用。 2、合理使用算子重执行特性HCCL_OP_RETRY_ENABLE 虽能提升通信容错能力，但会增加 AICPU 负载。在高并发通信场景下，应权衡容错需求与性能开销。 3、参考官方约束说明请参考 CANN 官方文档 - HCCL 通信约束与限制，了解 AICPU 使用场景与并发限制，合理设计训练任务。 4、日志分析建议遇到类似 notify/wait 超时问题时，建议按以下顺序排查：查看 plog 日志定位首报错节点与通信流 ID；在 device 日志中搜索对应 stream_id 与 notify_id；定位事件依赖链，确认卡点任务；分析任务类型与资源占用情况，判断是否存在死锁。 ## 附录 HCCL_OP_RETRY_PARAMS - CANN 文档 [了解详情](https://www.hiascend.com/document/detail/zh/CANNCommunityEdition/900/maintenref/envvar/envref_07_0085.html) 通信算子重执行对整网性能说明 - CANN 文档 [了解详情](https://www.hiascend.com/document/detail/zh/CANNCommunityEdition/900/maintenref/envvar/envref_07_0159.html) AICPU 资源使用与优化建议 [了解详情](https://www.hiascend.com/document/detail/zh/canncommercial/900/API/hcclug/hcclug_000126.html) This Page