CANN Runtime 核资源控制实战Device 与 Stream 粒度的 AI Core / Vector Core 资源限制配置【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址: https://gitcode.com/cann/runtimeCANN RuntimeAscendCL 运行时提供了一套进程级与流级的核资源控制能力允许开发者显式限制算子运行时可使用的 AI CoreCube Core与 Vector Core 数量从而提升多任务场景下 Device 核资源的利用率与隔离性。本文基于本仓库的官方开发指南、公开头文件、实现与单元测试系统讲解 Device 粒度与 Stream 粒度两种核资源限制的使用方法、接口语义、优先级规则并结合完整可编译的样例与测试用例给出实战指引。核资源控制的背景与目标在多进程、多 Stream 并发的昇腾 AI 处理器使用场景中不同业务往往共享同一块 Device。如果不对核资源做任何约束算子会默认使用 AI 处理器硬件提供的全部可用核资源可能出现以下问题高优先级任务的算子在排队等待低优先级任务释放全部核资源影响任务时延多个业务彼此抢占核资源导致整体吞吐下降、互相干扰难以精确控制单条 Stream 上算子的并发核数不利于性能调优与资源规划。Runtime 的核资源控制功能正是为了解决上述问题而设计它允许以Device 粒度作用于整个进程在当前 Device 上的所有任务和Stream 粒度仅作用于指定 Stream 上提交的任务配置核资源上限核资源包括AI CoreCube Core数量与Vector Core 数量最终提高 Device 核资源的使用率以及隔离性。两种典型场景与对应的编程路径是否由用户显式指定numBlocks用于指定算子的核函数将在几个核上执行直接决定了应调用哪一组运行时核资源控制接口。仓库文档中明确划分了两种场景无 numBlocks 场景隐式查询资源典型代表是调用aclnn 算子接口如aclnnAdd。此时算子框架在内部进行 tiling 计算时会隐式调用aclrtGetResInCurrentThread查询当前线程可用的核资源并自动按照该资源上限进行切分用户无需也无法直接传入numBlocks。该场景下使用 Stream 粒度的核资源限制时需要调用aclrtUseStreamResInCurrentThread将带资源限制的 Stream 绑定到当前线程算子任务内部如aclnnAddGetWorkspaceSize中会隐式调用aclrtGetResInCurrentThread获取当前线程可使用的核资源进行 tiling不再需要该限制时调用aclrtUnuseStreamResInCurrentThread解除绑定。关键优先级规则通过aclrtGetResInCurrentThread获取核资源限制的优先级为Stream 粒度的核资源限制 Device 粒度的核资源限制 AI 处理器硬件的默认核资源限制举例说明假设 Device 总共包含 32 个 Vector CoreDevice 粒度限制使用 16 个 Vector Core而 Stream 粒度的核资源限制设置为 20 个 Vector Core那么 ac lnn 算子在该 Stream 上执行时以 20 个 Vector Core 运行——Stream 粒度限制优先于 Device 粒度限制生效。需 numBlocks 场景显式配置核数典型代表是LaunchKernel 方式执行算子如rtKernelLaunch/aclrtLaunchKernel及配套的 Print Kernel 下发。此时用户需要自行查询不同粒度的核资源限制并将查询结果作为numBlocksblockDim配置给算子调用aclrtGetDeviceResLimit获取 Device 粒度的核资源限制或调用aclrtGetStreamResLimit获取 Stream 粒度的核资源限制将获取到的值作为numBlocks传入核函数启动参数。核资源类型与接口总览核资源限制类型由头文件 include/external/acl/acl_rt.h 中的枚举aclrtDevResLimitType定义typedef enum { ACL_RT_DEV_RES_CUBE_CORE 0, // AI CoreCube Core数量 ACL_RT_DEV_RES_VECTOR_CORE, // Vector Core 数量 } aclrtDevResLimitType;仓库公开头文件 include/external/acl/acl_rt.h 中声明了整套核资源控制接口整理如下接口入参说明aclrtSetDeviceResLimitdeviceId、type、value设置当前进程在指定 Device 上的资源限制aclrtGetDeviceResLimitdeviceId、type、value出参获取指定 Device 的资源限制值aclrtResetDeviceResLimitdeviceId重置指定 Device 的资源限制aclrtSetStreamResLimitstream、type、value设置指定 Stream 的资源限制aclrtGetStreamResLimitstream、type、value出参获取指定 Stream 的资源限制值aclrtResetStreamResLimitstream重置指定 Stream 的资源限制aclrtUseStreamResInCurrentThreadstream将指定 Stream 的资源限制绑定到当前线程aclrtUnuseStreamResInCurrentThreadstream解除当前线程与指定 Stream 的资源限制绑定aclrtGetResInCurrentThreadtype、value出参获取当前线程可使用的核资源限制这些接口在 Runtime 侧的声明、分发表与实现位于src/runtime/api目录如 api_impl_rt_config.cc 对应的运行时配置实现以及runtime_api_stub_catalog.def分发表底层通过rtsSetDeviceResLimit等 RTS 接口与驱动层交互将限制下发到 Device 侧的任务调度。Device 粒度的核资源限制Device 粒度的核资源限制作用于整个进程在指定 Device 上的全部任务配置一次后对该 Device 上的所有算子生效适合单业务独占或按进程做资源配额划分的场景。以下是仓库开发指南中的关键步骤代码示例不可直接拷贝编译运行仅供参考...... int32_t deviceId 0; uint32_t numBlocks 8; uint32_t coreDim 0; // 指定计算设备 aclrtSetDevice(deviceId); // 设置核资源限制 aclrtSetDeviceResLimit(deviceId, ACL_RT_DEV_RES_CUBE_CORE, numBlocks); // 下发算子执行任务 // 以aclnnAdd算子为例 // aclnnAddGetWorkspaceSize中会隐式调用aclrtGetResInCurrentThread查询核资源进行tiling // aclnnAdd() ...... // 获取核资源限制 aclrtGetDeviceResLimit(deviceId, ACL_RT_DEV_RES_CUBE_CORE, coreDim);要点说明aclrtSetDeviceResLimit需要在aclrtSetDevice之后调用且通常在进程初始化阶段完成配置无 numBlocks 场景下aclnn 算子内部的 tiling 流程会自动感知该限制需 numBlocks 场景下通过aclrtGetDeviceResLimit查询到的coreDim可直接作为算子的numBlocks接口的底层实现会校验资源值合法性例如单元测试 rt_utest_api_device_limit.cc 验证了设置 Cube Core、Vector Core 为合法值返回ACL_RT_SUCCESS而设置 Vector Core 为2048超出实际核数时返回ACL_ERROR_RT_PARAM_INVALID。Stream 粒度的核资源限制Stream 粒度比 Device 粒度更精细可以实现同进程内不同 Stream 之间的资源隔离是核资源控制的核心使用形态。以下为仓库开发指南中的完整流程示例#include acl/acl.h ...... int32_t deviceId 0; uint32_t numBlocks 8; // 指定运算的Device aclrtSetDevice(deviceId); // 显式创建一个Stream aclrtStream stream; aclrtCreateStream(stream); // 设置Stream粒度的Cube Core、Vector Core的数量 aclrtSetStreamResLimit(stream, ACL_RT_DEV_RES_CUBE_CORE, numBlocks); aclrtSetStreamResLimit(stream, ACL_RT_DEV_RES_VECTOR_CORE, numBlocks * 2); // 绑定到当前线程 aclrtUseStreamResInCurrentThread(stream); // 算子的任务中需要调用aclrtGetResInCurrentThread查询当前线程的资源限制然后指定运行算子的资源数量 // 以aclnnAdd算子为例 // aclnnAddGetWorkspaceSize中会隐式调用aclrtGetResInCurrentThread查询核资源进行tiling // aclnnAdd() ...... aclrtUnuseStreamResInCurrentThread(stream); aclrtResetStreamResLimit(stream); // 资源销毁 aclrtDestroyStream(stream); aclrtResetDevice(deviceId);线程绑定机制的理解Stream 粒度的核资源限制并不直接作用于算子而是通过线程绑定这一中间层生效aclrtSetStreamResLimit为 Stream 记录资源上限可同时设置 Cube Core 与 Vector Core互不影响如示例中 Vector Core 设置为numBlocks * 2aclrtUseStreamResInCurrentThread将 Stream 的核资源限制注册到当前线程的线程局部上下文中算子在当前线程上下发执行时通过aclrtGetResInCurrentThread查询到该限制并据此确定实际使用的核数aclnn 算子的GetWorkspaceSize阶段即隐式完成此查询aclrtUnuseStreamResInCurrentThread解除绑定后线程恢复到无 Stream 限制状态。因此在使用 ac lnn 接口时务必确保算子下发线程与aclrtUseStreamResInCurrentThread所在线程一致否则无法生效。资源清理顺序示例末尾展示了完整的清理顺序先解除线程绑定aclrtUnuseStreamResInCurrentThread再重置 Stream 资源限制aclrtResetStreamResLimit最后销毁 Stream、复位 Device。按此顺序可避免残留绑定导致的意外资源限制。完整样例LaunchKernel 方式下的资源限制执行对于需 numBlocks 的 LaunchKernel 场景仓库提供了可直接编译运行的完整样例 1_launch_kernel_with_reslimit该样例设置 Cube Core 资源限制后执行打印 Kernel验证资源限制实际生效。其核心流程在 main.cpp 中int32_t main() { const int32_t deviceId 0; const aclrtDevResLimitType resLimitType ACL_RT_DEV_RES_CUBE_CORE; const uint32_t blockDim 8; aclrtStream stream nullptr; // 1. 初始化 ACL CHECK_ERROR(aclInit(nullptr)); // 2. 指定 Device CHECK_ERROR(aclrtSetDevice(deviceId)); // 3. 创建 Stream CHECK_ERROR(aclrtCreateStream(stream)); // 4. 设置进程级 Device 资源限制 CHECK_ERROR(aclrtSetDeviceResLimit(deviceId, resLimitType, blockDim)); // 5. 查询资源限制并作为 Print Kernel 的 blockDim 下发 LaunchPrintKernelWithCurrentResLimit(deviceId, resLimitType, stream); // 6. 清理 ... }其中查询限制并下发 Kernel 的关键函数main.cppint32_t LaunchPrintKernelWithCurrentResLimit(int32_t deviceId, aclrtDevResLimitType type, aclrtStream stream) { // Query the resource limit and use it as the print kernel block dimension. uint32_t coreDim 0; CHECK_ERROR(aclrtGetDeviceResLimit(deviceId, type, coreDim)); INFO_LOG(Current device resource limit type %d is %u., static_castint32_t(type), coreDim); PrintDo(coreDim, stream); // 以 coreDim 作为 numBlocks 下发打印 Kernel CHECK_ERROR(aclrtSynchronizeStream(stream)); return 0; }PrintDo的 Kernel 封装定义于 example/kernel_func/kernel_ops.h该样例的运行结果可在 README.md 中查看设置资源限制为 8 后日志输出 8 次Hello World与限制的 Cube Core 数量一一对应直观验证了资源限制对核数下发的约束作用。编译与运行下载样例代码至安装 CANN 软件的环境切换到样例目录cd ${git_clone_path}/example/2_advanced_features/kernel/1_launch_kernel_with_reslimit设置环境变量# ${install_root} 替换为 CANN 安装根目录默认安装在 /usr/local/Ascend 目录 source ${install_root}/cann/set_env.sh # 自动识别 SOC_VERSION 和 ASCENDC_CMAKE_DIR source ${git_clone_path}/example/set_sample_env.sh执行以下命令运行样例bash run.sh预期输出片段完整输出见样例 README[INFO] ACL initialized. [INFO] Device 0 selected. [INFO] Stream created. [INFO] Device resource limit type 0 set to 8. [INFO] Current device resource limit type 0 is 8. Hello World ...共 8 次 [INFO] Run the launch_kernel_with_reslimit sample successfully. [SUCCESS]: Launch kernels under resource limits successfully.产品支持情况根据样例 README.md该核资源限制功能当前支持以下产品产品是否支持Ascend 950PR / Ascend 950DT√Atlas A3 训练系列产品 / Atlas A3 推理系列产品√Atlas A2 训练系列产品 / Atlas A2 推理系列产品√底层实现与测试验证从源码结构看核资源控制功能的实现链路为AscendCL 公共头文件声明acl_rt.h→ Runtime API 实现层src/runtime/api/impl→ RTS 接口rtsSetDeviceResLimit 等→ 驱动层npu_driver / ascend_hal→ Device 侧任务调度。单元测试侧仓库提供了专门的验证用例rt_utest_api_device_limit.cc验证 Device 粒度资源限制的设置成功路径与非法值校验ACL_ERROR_RT_PARAM_INVALIDrt_utest_api_stream_limit.cc验证 Stream 粒度的资源限制接口rt_utest_api.cc 与 rt_utest_api_rt_config.cc 中对核资源相关 API 的补充测试。这些测试通过 mock 驱动层接口driver/ascend_hal.h在无真实硬件环境下模拟 Device 交互覆盖了参数校验、成功路径与错误码语义可作为二次开发与自测的参考。使用建议与注意事项场景选择使用 aclnn 等无 numBlocks 的接口时优先使用 Stream 粒度 线程绑定方案使用 LaunchKernel 方式时先通过aclrtGetDeviceResLimit/aclrtGetStreamResLimit查询限制值并显式配置numBlocks避免算子使用超出限制的核数。优先级意识同一线程上 Stream 粒度限制优先于 Device 粒度限制未设置任何限制时回落到 AI 处理器硬件默认值。设计多级配额时需明确这一覆盖关系。线程一致性aclrtUseStreamResInCurrentThread绑定的是线程局部上下文算子下发线程与绑定线程必须一致多线程场景下每个线程需要单独绑定。参数合法性核资源数值必须小于等于硬件实际可用核数非法取值将返回ACL_ERROR_RT_PARAM_INVALID。资源清理解绑、重置、销毁按顺序执行避免残留限制影响后续任务多业务共享 Device 时建议统一资源配额规范以维持整体隔离性。通过 Device 与 Stream 两级核资源控制开发者可以在保持易用性的前提下将 AI Core 与 Vector Core 的分配纳入精细管理兼顾资源利用率与任务隔离性。【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址: https://gitcode.com/cann/runtime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考