CANNAscend人工智能任务调度【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址https://gitcode.com/cann/runtime点击查看免费下载本篇技术指南围绕 CANN Runtime 的异常处理机制展开系统讲解 Runtime 接口错误码的分类与含义、异步接口与同步接口在错误捕获方式上的本质差异、线程级错误状态变量aclrtPeekAtLastError/aclrtGetLastError的用法以及aclGetRecentErrMsg获取详细错误消息的底层原理。读完本文你将掌握一套可复用的 Runtime 错误处理范式能够在同步点准确捕获 Device 侧异步错误并快速定位问题。一、Runtime 错误码的产生与分类在 CANN Runtime 中绝大多数接口调用都会返回一个aclError类型的错误码。根据接口类型的不同返回码的含义和错误获取方式也不同异步接口在 Device 任务完成之前就返回例如aclrtMemcpyAsync、内核启动等返回码仅表示 Host 侧任务下发是否成功无法反映 Device 上的实际执行错误。关于异步任务执行的完整模型可参见 异步任务执行。同步接口返回码直接反映本次执行结果。典型场景包括传递了无效的参数如空指针、越界大小、请求了不支持的硬件功能、内存分配失败。从源码结构看这一分类是 Runtime 接口设计的固有属性。以接口声明为例同步的aclrtMemcpy与异步的aclrtMemcpyAsync在 acl_rt.h 中分别声明前者要求参数完整传入并直接执行拷贝后者需要额外携带aclrtStream参数、由 Stream 调度执行。因此错误处理策略必须区分接口类型否则容易漏掉真正发生在 Device 上的执行错误。二、异步接口错误处理流同步是捕获异步错误的唯一通道2.1 核心机制Host 线程错误状态变量Runtime 会为每个 Host 线程维护一个错误状态变量。该变量初始化为ACL_RT_SUCCESS并在每次发生错误无论是参数校验错误还是异步错误时被错误码覆盖。两个用于读取该变量的接口语义不同aclrtPeekAtLastError仅返回该变量的当前值不改变其状态aclrtGetLastError返回该变量的值同时将其重置为ACL_RT_SUCCESS。在 acl_rt.h 中aclrtLastErrLevel枚举定义了错误级别typedef enum aclrtLastErrLevel { ACL_RT_THREAD_LEVEL 0, } aclrtLastErrLevel;也就是说当前 Runtime 将错误状态限定在线程级别ACL_RT_THREAD_LEVEL。在 context.cpp 的aclrtPeekAtLastErrorImpl与aclrtGetLastErrorImpl实现中可以看到这两个接口都通过ACL_REQUIRES_PARAM_EQUAL_REPORT(level, ACL_RT_THREAD_LEVEL)对传入级别做了严格校验随后透传给底层rtPeekAtLastError/rtGetLastError由 Runtime 核心层完成错误变量的读取与重置。需要特别注意的是aclrtPeekAtLastError/aclrtGetLastError只能感知到已经反映到 Host 线程错误变量中的错误。对于异步接口任务尚未在 Device 上执行完毕时真正的执行错误还没有发生此时读取错误变量往往仍是ACL_RT_SUCCESS。因此若要检查某个异步函数调用后的异步错误唯一的方式是显式调用同步接口如aclrtSynchronizeDevice阻塞主机线程等待 Device 上的任务执行结束再检查同步接口返回的错误码。有关显式同步的更多说明可参见 Stream 管理。2.2 完整的异步错误处理代码示例下面的示例展示了标准流程指定 Device、创建 Stream、设置遇错即停模式、下发异步任务、通过线程错误变量感知 Host 侧错误、最后通过同步接口捕获 Device 侧异步错误// 指定Device aclError error aclrtSetDevice(0); // 创建Stream aclrtStream stream; error aclrtCreateStream(stream); // 设置遇错即停模式 error aclrtSetStreamFailureMode(stream, ACL_STOP_ON_FAILURE); // 在Stream上下发任务返回码仅表示下发是否成功通常是Host上参数校验错误无法表示Device上的实际执行错误 error aclrtMemcpyAsync(devPtr, devSize, hostPtr, hostSize, ACL_MEMCPY_HOST_TO_DEVICE, stream); // 内核调用方式无返回值若只需感知Host侧错误可通过aclrtPeekAtLastError/aclrtGetLastError获取 myKernel8, nullptr, stream(); // 获取当前线程最近发生的错误 error aclrtPeekAtLastError(ACL_RT_THREAD_LEVEL); ...... // 获取当前线程最近的错误并将状态重置为ACL_RT_SUCCESS error aclrtGetLastError(ACL_RT_THREAD_LEVEL); ...... error aclrtMemcpyAsync(hostPtr, hostSize, devPtr, devSize, ACL_MEMCPY_DEVICE_TO_HOST, stream); // 【关键差异】异步接口必须调用同步接口才能获取Device上的异步错误 error aclrtSynchronizeDevice(); if (error ! ACL_RT_SUCCESS) { // 获取ErrorMsg char *errMsg aclGetRecentErrMsg(); // 输出到日志 printf(Error: %s\n, errMsg); ...... } // 资源销毁 error aclrtDestroyStream(stream); error aclrtResetDevice(0);关于aclrtSynchronizeDevice的实现在 device.cpp 中可以看到aclrtSynchronizeDeviceImpl它作为同步点接口其返回值汇总了 Device 上已执行任务的错误状态是异步错误捕获的关键一环。注意在遇错继续模式下如果一条 Stream 上的任务执行出现异常该 Stream 上的其他未执行任务仍可继续执行同时也不会阻止向该 Stream 或同一 Context 下的其他 Stream 下发新任务。此时aclrtPeekAtLastError和aclrtGetLastError返回的可能不是首次错误的信息。三、同步接口错误处理直接校验返回值同步接口的执行结果在返回时已经确定无需调用流同步接口直接校验返回值即可// 指定Device aclError error aclrtSetDevice(0); // 【关键差异】无需调用流同步等接口直接校验返回值 error aclrtMemcpy(devPtr, devSize, hostPtr, hostSize, ACL_MEMCPY_HOST_TO_DEVICE); if (error ! ACL_RT_SUCCESS) { // 获取ErrorMsg char *errMsg aclGetRecentErrMsg(); // 输出到日志 printf(Error: %s\n, errMsg); ...... } // 资源销毁 error aclrtResetDevice(0);四、异步与同步错误处理差别对比项异步接口同步接口返回码含义仅表示Host侧下发是否成功直接反映本次执行结果是否需要流同步需要通过aclrtSynchronizeDevice等同步接口捕获异步错误不需要返回码已包含执行结果错误获取时机流同步之后接口返回时五、深入 aclGetRecentErrMsg错误消息的组装原理当同步点接口如aclrtSynchronizeDevice返回错误码后仅仅知道错误码往往不足以定位问题此时需要调用aclGetRecentErrMsg获取人类可读的错误消息。该接口在 acl_rt.h 中声明其实现aclGetRecentErrMsgImpl位于 acl.cpp从源码可以看出错误消息由三部分组装而成Device 侧错误消息通过rtGetDevMsg(RT_GET_DEV_ERROR_MSG, acl::aclGetMsgCallback)从 Runtime 底层获取 Device 上的错误消息。若获取失败仅记录 DEBUG 日志而不会中断流程故障诊断信息GetFaultEventInfo()会进一步汇总故障事件Fault Event并以[0x事件ID]事件名称;的格式追加诊断分析文本形如Fault diagnosis analysis: ...Host 侧错误消息通过error_message::GetErrMgrErrorMessage()获取错误管理模块维护的 Host 侧错误描述。最终这三部分按「Host 错误消息 Device 错误消息 故障诊断信息」的顺序拼接返回若各部分均为空则返回nullptr。理解这一组装逻辑的意义在于aclGetRecentErrMsg返回的字符串不只是错误码的翻译而是涵盖了 Host 参数校验、Device 执行失败与硬件故障事件的多维度信息是异步错误定位时最有价值的调试入口。六、遇错即停模式与 Stream 失败行为控制异步错误捕获策略与 Stream 的失败模式密切相关。Runtime 提供aclrtSetStreamFailureMode接口控制 Stream 在遇到任务执行失败时的行为其模式宏定义在 acl_rt.h#define ACL_CONTINUE_ON_FAILURE 0x00000000U // 遇错继续默认 #define ACL_STOP_ON_FAILURE 0x00000001U // 遇错即停在 stream.cpp 的aclrtSetStreamFailureModeImpl实现中该接口经过参数记录与 Profiling 埋点后透传调用rtStreamSetMode将模式下发到 Runtime 核心层由 Stream 调度机制据此决定失败后的行为ACL_STOP_ON_FAILURE遇错即停Stream 上出现任务执行失败后该 Stream 上尚未执行的任务将不再执行错误状态会稳定地体现在后续同步接口与线程错误变量中便于在同步点捕获到确定的错误码。前述异步示例代码中的aclrtSetStreamFailureMode(stream, ACL_STOP_ON_FAILURE)即属此类用法。ACL_CONTINUE_ON_FAILURE遇错继续默认一条 Stream 上的任务执行出现异常时其他未执行任务仍可继续执行也不会阻止向该 Stream 或同一 Context 下的其他 Stream 下发新任务。此时线程错误变量保存的不一定是首次错误依赖aclrtPeekAtLastError/aclrtGetLastError判断首个错误原因时需要谨慎。需要明确的是遇错即停模式控制的是已下发的后续任务是否继续执行它并不能替代同步接口。无论哪种模式异步任务的 Device 侧执行错误都必须在同步点如aclrtSynchronizeDevice处通过返回码捕获。七、使用建议统一检查返回值对于任何 Runtime 接口调用都应该检查其返回值这样可以尽早发现同步错误参数校验失败、内存分配失败、硬件能力不支持等。在关键同步点再次检查对于异步操作必须在关键同步点如aclrtSynchronizeDevice、aclrtSynchronizeStream再次检查错误以确保能捕获到执行时的错误。区分两种错误变量接口只查询不消耗用aclrtPeekAtLastError查询并重置状态用aclrtGetLastError按业务需要选择避免误重置导致丢失错误状态。结合错误消息定位同步点返回非ACL_RT_SUCCESS后及时调用aclGetRecentErrMsg获取包含 Host/Device/故障诊断的多维错误描述再结合 plog 日志进一步确认问题根因。按场景选择失败模式需要确定性失败语义的推理、调试场景推荐ACL_STOP_ON_FAILURE对吞吐敏感、允许跳过失败任务的场景可使用默认的ACL_CONTINUE_ON_FAILURE但要注意线程错误变量可能不是首次错误信息。关于接口选型与典型场景的更多建议可进一步阅读 推荐接口与典型场景在实际问题排查中也可结合 运行时故障排查 章节的整体框架进行系统性定位。赞分享CANNAscend人工智能任务调度【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址https://gitcode.com/cann/runtime点击查看免费下载相关推荐CANN Runtime 异常回调实战基于 aclrtSubscribeReport 与 aclrtExceptionInfo 的错误处理链CANN Runtime 异常回调实战基于 aclrtSubscribeReport 与 aclrtExceptionInfo 的错误处理链 导读 本文基于CANNAscend人工智能任务调度CANN Runtime 异常处理接口深度指南错误获取、异常回调、UCE 修复与任务中止CANN Runtime 异常处理接口深度指南错误获取、异常回调、UCE 修复与任务中止 CANN Runtime 在异步执行模型推理或算子任务时设备侧如CANNAscend人工智能任务调度CANN Runtime 错误回调与异常诊断实战基于 2_callback_exception 样例构建完整错误处理链CANN Runtime 错误回调与异常诊断实战基于 2_callback_exception 样例构建完整错误处理链 本文以 CANN / runtimeCANNAscend人工智能任务调度创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考