Atlas 900 A3 AICPU占满导致AICPU算子执行卡死
发表于: 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；定位事件依赖链，确认卡点任务；分析任务类型与资源占用情况，判断是否存在死锁。
