背景概述 Atlas 800T A3服务器进行大规模分布式训练时，其中，错误码 80CB800A（算子超时）是较为常见的报错之一。算子超时并非由算子本身的计算逻辑错误直接导致，而是由于自定义算子执行异常后未能正确释放硬件资源，进而引发NPU状态异常，最终导致后续作业在基础算子执行时出现超时。问题现象在32节点集群进行训练任务时，作业异常中断。日志显示单个节点发生故障，错误码为 80CB800A，提示算子执行超时。进一步排查发现，同一时间段内，另有5个节点也出现了类似的 80CB800A 报错，并导致作业中断。这些节点此前运行正常，但在特定时间点集中出现异常。根因分析 1、首先检查首报错节点的plog日志，发现首条错误信息指向 aivec error，具体表现为 OnesLike 算子执行超时。 OnesLike 属于基础算子，通常稳定性较高。为了排除算子实现问题，对故障节点的NPU进行了AICore压测，结果显示压测超时，表明NPU硬件或驱动状态存在异常。 2、考虑到多个节点在同一时间段出现类似故障，推测可能存在历史作业残留影响。通过查询故障节点的历史作业执行记录，发现22日7点左右有一笔作业调度到了这5个故障节点。从节点的device日志中也可以确认，首次ERROR记录出现在22日7点。由此推断，该历史作业导致了多个节点的NPU状态异常。 3、进一步分析该历史作业的plog日志，发现首报错并非基础算子，而是自定义算子 tilefwk_0_mix_aic 在执行时发生了越界错误。 tilefwk_0_mix_aic 属于PyPto框架下的自定义算子。经查证，PyPto算子运行支持的HDK版本为25.5.0，而当前集群使用的HDK版本为25.2.1。问题根因（1）资源未释放：历史作业调用的自定义算子在执行过程中发生越界异常中断，但未能正确释放AICORE资源，导致NPU处于异常锁定状态。（2）版本兼容性不足：低版本驱动（HDK 25.2.1）对新特性或特定错误场景下的防护机制不完善，未能有效拦截或清理异常状态，导致后续作业在调用基础算子时因NPU状态异常而超时。解决措施（1）对6个问题节点进行热恢复以解除npu异常状态。（2）整理问题作业涉及到的所有节点，排除掉22日之后成功执行过作业的，其余节点全部隔离压测。