CANN Runtime 在 PyTorch 场景下使用 aclprofGetStepTimestamp 标记迭代时间的完整指南【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址: https://gitcode.com/cann/runtime导读aclprofGetStepTimestamp是 CANN Runtime 提供的 Profiling 迭代时间标记接口专门用于单算子模型执行以算子为粒度逐步下发的训练场景通过在每次迭代的开始与结束位置打点为 Profiling 数据解析提供清晰的迭代边界标识从而以迭代为粒度聚合和展示性能数据。读完本文你将掌握该接口的适用场景、参数约束、配套的aclprofCreateStepInfo/aclprofDestroyStepInfo生命周期管理方法以及如何在真实工程中组合 Profiling 初始化、打点与产物落盘的完整流程。本文基于开源仓库 CANN runtime 中的接口文档 docs/zh/api_ref/19-04_setting_Iteration_time_in_pytorch_scenarios.md 展开并结合 include/external/acl/acl_prof.h 头文件、src/dfx/msprof/collector/dvvp/msprofiler/prof_acl_core.cpp 底层实现以及 example/5_performance/profiling/1_msproftx/main.cpp 可运行样例进行源码级佐证。为什么需要显式标记迭代时间在大模型训练场景中训练循环通常包含数据预处理 → 前向计算 → 反向更新 → 迭代结束多个阶段。若 Profiling 工具仅以任务/算子为粒度记录耗时开发者很难直接回答一个关键问题单个训练迭代step到底花了多久瓶颈在哪一个迭代阶段PyTorch 等框架在训练时通常将模型切分为一个个算子下发执行即文档所描述的单算子模型执行场景。此时算子任务是连续、串行出现在 Stream 上的工具无法天然地识别哪几个算子属于同一个迭代。aclprofGetStepTimestamp的价值正是在于在迭代开始处打上ACL_STEP_START标记在迭代结束处打上ACL_STEP_END标记这样 Profiling 解析器就能把两次标记之间的所有算子任务聚合成一个迭代单元进而按迭代粒度计算算子耗时占比、迭代周期、前后处理开销等指标避免人工从海量任务时间线中手工切分迭代。接口原型与声明位置接口声明位于 include/external/acl/acl_prof.hMSVP_PROF_API aclError aclprofGetStepTimestamp(aclprofStepInfo* stepInfo, aclprofStepTag tag, aclrtStream stream);其中aclprofStepTag枚举定义在同文件 include/external/acl/acl_prof.htypedef enum { ACL_STEP_START 0, // step start ACL_STEP_END 1 // step end } aclprofStepTag;使用前需要在源码中包含acl/acl_prof.h头文件acl/acl.h中已间接引入并在编译时链接 Profiling 相关动态库。产品支持情况根据官方接口文档该接口在以下产品上支持产品支持情况Ascend 950PR/Ascend 950DT支持Atlas A3 训练系列产品/Atlas A3 推理系列产品支持Atlas A2 训练系列产品/Atlas A2 推理系列产品支持Atlas 200I/500 A2 推理产品支持Atlas 推理系列产品支持Atlas 训练系列产品支持IPV350不支持从仓库样例 example/5_performance/profiling/1_msproftx/README.md 来看该能力至少在 Ascend 950PR/Ascend 950DT、Atlas A3 训练/推理系列、Atlas A2 训练/推理系列上得到了样例级验证。请在部署前确认目标硬件型号IPV350 上应跳过该接口调用。参数说明参数名输入/输出说明stepinfo输入指定迭代信息。需提前调用 aclprofCreateStepInfo 接口创建 aclprofStepInfo 类型的数据。类型定义请参见 aclprofStepInfo、aclprofStepTag 和 aclrtStream。tag输入用于标记迭代开始或结束。在迭代开始时传入枚举值ACL_STEP_START迭代结束时需传入枚举值ACL_STEP_END。取值详见 aclprofStepTag。stream输入指定 Stream。取值详见 aclrtStream。返回值说明返回0ACL_SUCCESS表示成功返回其他值表示失败具体错误码请参见 aclError。从底层实现 src/dfx/msprof/collector/dvvp/msprofiler/prof_acl_core.cpp 可以看到实际的失败路径主要有两类stepInfo为空指针或同一对象重复设置同一tag如已start再次start、已end再次end返回ACL_ERROR_INVALID_PARAM底层profSetStepInfo上报失败时返回ACL_ERROR_GE_FAILURE。配套接口与生命周期管理aclprofGetStepTimestamp依赖一个描述迭代信息的aclprofStepInfo对象该对象由以下两个接口配套管理详见 docs/zh/api_ref/25-03_Operation_APIs.mdaclprofCreateStepInfo创建迭代信息对象aclprofStepInfo* aclprofCreateStepInfo();返回非空指针表示创建成功返回nullptr表示失败该对象用于描述一次迭代的开始/结束状态是实现层内部持有startFlag、endFlag与自增的indexId见 src/dfx/msprof/collector/dvvp/msprofiler/prof_acl_core.cpp从源码看每个对象创建时会从全局计数g_indexId起始为 1分配一个递增的indexId作为该迭代在 Profiling 数据中的唯一标识见 src/dfx/msprof/collector/dvvp/msprofiler/prof_acl_core.cpp。aclprofDestroyStepInfo销毁迭代信息对象void aclprofDestroyStepInfo(aclprofStepInfo* stepinfo);与aclprofCreateStepInfo配对使用先创建后销毁若不销毁会造成内存泄漏同一对象重复销毁会触发重复释放内存的报错见 docs/zh/api_ref/25-03_Operation_APIs.md。使用约束重点说明同一个aclprofStepInfo对象、同一个tag只能设置一次否则 Profiling 解析会出错。这一约束与底层实现严格对应aclprofGetStepTimestamp内部通过startFlag/endFlag两个布尔位记录状态重复设置会被判定为非法参数并返回ACL_ERROR_INVALID_PARAM见 src/dfx/msprof/collector/dvvp/msprofiler/prof_acl_core.cpp。因此一个 step 周期应使用一个新创建的aclprofStepInfo对象或在复用前完成一次完整的 start → end 生命周期。完整使用流程从初始化到迭代打点结合仓库样例 example/5_performance/profiling/1_msproftx/main.cpp一次完整的初始化 → 开启采集 → 迭代打点 → 停止采集流程如下。第一步初始化 Runtime 与 ProfilingCHECK_ERROR(aclInit(nullptr)); CHECK_ERROR(aclrtSetDevice(deviceIdList[0])); CHECK_ERROR(aclrtCreateStream(stream)); const std::string aclProfPath ./output; CHECK_ERROR(aclprofInit(aclProfPath.c_str(), aclProfPath.length())); aclprofConfig* config aclprofCreateConfig( deviceIdList, 1, ACL_AICORE_ARITHMETIC_UTILIZATION, nullptr, ACL_PROF_ACL_API | ACL_PROF_TASK_TIME | ACL_PROF_MSPROFTX); CHECK_ERROR(aclprofStart(config));要点aclprofInit指定 Profiling 产物输出目录样例中为./outputaclprofCreateConfig声明需要采集的设备、AICore 指标与数据类型其中ACL_PROF_MSPROFTX表明开启 msproftx 类打点能力要采集迭代时间维度建议同时开启ACL_PROF_ACL_APIACL API 耗时与ACL_PROF_TASK_TIME任务耗时aclprofStart后才开始正式采集迭代打点应位于 Start 与 Stop 之间。第二步训练迭代内标记开始与结束int32_t RunTraceFlow(aclrtStream stream) { aclprofStepInfo* stepInfo aclprofCreateStepInfo(); if (!CheckPtr(stepInfo, aclprofCreateStepInfo)) { return -1; } CHECK_ERROR(aclprofGetStepTimestamp(stepInfo, ACL_STEP_START, stream)); // 此处为一次训练迭代中的实际计算模型加载、前向、反向等 // ...样例中穿插 aclprofMark / aclprofPush / aclprofRangeStart 等细粒度打点 CHECK_ERROR(aclprofGetStepTimestamp(stepInfo, ACL_STEP_END, stream)); aclprofDestroyStepInfo(stepInfo); return 0; }对应到真实训练循环伪代码形态为for (int step 0; step totalSteps; step) { aclprofStepInfo* stepInfo aclprofCreateStepInfo(); aclprofGetStepTimestamp(stepInfo, ACL_STEP_START, stream); // data loading - forward - backward - optimizer LaunchForwardOps(stream); LaunchBackwardOps(stream); aclprofGetStepTimestamp(stepInfo, ACL_STEP_END, stream); aclprofDestroyStepInfo(stepInfo); }第三步停止采集并回收资源CHECK_ERROR(aclprofStop(config)); CHECK_ERROR(aclprofDestroyConfig(config)); CHECK_ERROR(aclprofFinalize()); CHECK_ERROR(aclrtDestroyStream(stream)); CHECK_ERROR(aclrtResetDeviceForce(deviceIdList[0])); CHECK_ERROR(aclFinalize());底层实现剖析aclprofGetStepTimestamp在 msprof 组件中的实现位于 src/dfx/msprof/collector/dvvp/msprofiler/prof_acl_core.cpp其执行逻辑为参数校验stepInfo为空直接返回ACL_ERROR_INVALID_PARAM状态机校验startFlag已置位时不允许再次ACL_STEP_STARTendFlag已置位时不允许再次ACL_STEP_END违反则返回ACL_ERROR_INVALID_PARAM状态更新ACL_STEP_START置startFlag否则置endFlag底层上报调用profSetStepInfo(stepInfo-indexId, tag, stream)将迭代索引 开始/结束类型 所在 Stream写入 Profiling 引擎失败返回ACL_ERROR_GE_FAILURE成功返回ACL_SUCCESS。其中indexId由aclprofCreateStepInfo创建时从全局自增计数分配src/dfx/msprof/collector/dvvp/msprofiler/prof_acl_core.cpp是 Profiling 解析时把同一迭代的 start/end 配对关联的关键字段。由此可见接口本身是同步且轻量的它只负责记录标记事件真正的耗时统计仍由 Profiling 引擎依据时间戳在解析阶段完成。单元测试 tests/ut/msprof/msprof/test/prof_acl_core_utest.cpp 验证了核心行为传入nullptr的stepInfo返回ACL_ERROR_INVALID_PARAM正常创建对象后调用返回ACL_SUCCESSaclprofDestroyStepInfo(nullptr)安全失败、正常对象可正确销毁。Python 侧的接口封装仓库的 Python 绑定 python/pyACL/prof/prof_wrap.cpp 提供了对应的WrapAclProfGetStepTimestamp、WrapAclProfCreateStepInfo、WrapAclProfDestroyStepInfo封装说明该能力同样可被 Python 调用层使用。PyTorch 场景中可通过 PyACL 的 prof 模块完成等价的迭代打点C 侧的枚举值与生命周期规则保持一致。常见问题与避坑指南问题原因与处理返回ACL_ERROR_INVALID_PARAMstepInfo为空指针或同一对象对同一tag重复设置。确保每次迭代创建新的aclprofStepInfo或完整走完 start → end 后再复用。返回ACL_ERROR_GE_FAILURE底层profSetStepInfo上报失败通常是 Profiling 未初始化或采集未开启未调用aclprofInit/aclprofStart。请检查采集流程顺序。迭代打点没有生效 / 产物中无迭代维度数据确认已开启ACL_PROF_MSPROFTX等对应采集项且打点调用位于aclprofStart与aclprofStop之间。内存泄漏每个aclprofCreateStepInfo创建的对象都需由aclprofDestroyStepInfo释放二者必须配对。重复释放崩溃同一aclprofStepInfo对象不可重复调用aclprofDestroyStepInfo。关联阅读接口总览19_profiling_data_collection.md配套接口25-03_Operation_APIs.mdaclprofStepInfo/aclprofCreateStepInfo/aclprofDestroyStepInfo枚举与错误码25-02_Enumerations.md、25-01_aclError.md可运行样例1_msproftx含编译运行步骤、0_create_config产物解读Profiling 产物解读底层实现prof_acl_core.cpp单元测试prof_acl_core_utest.cpp【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址: https://gitcode.com/cann/runtime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CANN Runtime 在 PyTorch 场景下使用 aclprofGetStepTimestamp 标记迭代时间的完整指南
CANN Runtime 在 PyTorch 场景下使用 aclprofGetStepTimestamp 标记迭代时间的完整指南【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址: https://gitcode.com/cann/runtime导读aclprofGetStepTimestamp是 CANN Runtime 提供的 Profiling 迭代时间标记接口专门用于单算子模型执行以算子为粒度逐步下发的训练场景通过在每次迭代的开始与结束位置打点为 Profiling 数据解析提供清晰的迭代边界标识从而以迭代为粒度聚合和展示性能数据。读完本文你将掌握该接口的适用场景、参数约束、配套的aclprofCreateStepInfo/aclprofDestroyStepInfo生命周期管理方法以及如何在真实工程中组合 Profiling 初始化、打点与产物落盘的完整流程。本文基于开源仓库 CANN runtime 中的接口文档 docs/zh/api_ref/19-04_setting_Iteration_time_in_pytorch_scenarios.md 展开并结合 include/external/acl/acl_prof.h 头文件、src/dfx/msprof/collector/dvvp/msprofiler/prof_acl_core.cpp 底层实现以及 example/5_performance/profiling/1_msproftx/main.cpp 可运行样例进行源码级佐证。为什么需要显式标记迭代时间在大模型训练场景中训练循环通常包含数据预处理 → 前向计算 → 反向更新 → 迭代结束多个阶段。若 Profiling 工具仅以任务/算子为粒度记录耗时开发者很难直接回答一个关键问题单个训练迭代step到底花了多久瓶颈在哪一个迭代阶段PyTorch 等框架在训练时通常将模型切分为一个个算子下发执行即文档所描述的单算子模型执行场景。此时算子任务是连续、串行出现在 Stream 上的工具无法天然地识别哪几个算子属于同一个迭代。aclprofGetStepTimestamp的价值正是在于在迭代开始处打上ACL_STEP_START标记在迭代结束处打上ACL_STEP_END标记这样 Profiling 解析器就能把两次标记之间的所有算子任务聚合成一个迭代单元进而按迭代粒度计算算子耗时占比、迭代周期、前后处理开销等指标避免人工从海量任务时间线中手工切分迭代。接口原型与声明位置接口声明位于 include/external/acl/acl_prof.hMSVP_PROF_API aclError aclprofGetStepTimestamp(aclprofStepInfo* stepInfo, aclprofStepTag tag, aclrtStream stream);其中aclprofStepTag枚举定义在同文件 include/external/acl/acl_prof.htypedef enum { ACL_STEP_START 0, // step start ACL_STEP_END 1 // step end } aclprofStepTag;使用前需要在源码中包含acl/acl_prof.h头文件acl/acl.h中已间接引入并在编译时链接 Profiling 相关动态库。产品支持情况根据官方接口文档该接口在以下产品上支持产品支持情况Ascend 950PR/Ascend 950DT支持Atlas A3 训练系列产品/Atlas A3 推理系列产品支持Atlas A2 训练系列产品/Atlas A2 推理系列产品支持Atlas 200I/500 A2 推理产品支持Atlas 推理系列产品支持Atlas 训练系列产品支持IPV350不支持从仓库样例 example/5_performance/profiling/1_msproftx/README.md 来看该能力至少在 Ascend 950PR/Ascend 950DT、Atlas A3 训练/推理系列、Atlas A2 训练/推理系列上得到了样例级验证。请在部署前确认目标硬件型号IPV350 上应跳过该接口调用。参数说明参数名输入/输出说明stepinfo输入指定迭代信息。需提前调用 aclprofCreateStepInfo 接口创建 aclprofStepInfo 类型的数据。类型定义请参见 aclprofStepInfo、aclprofStepTag 和 aclrtStream。tag输入用于标记迭代开始或结束。在迭代开始时传入枚举值ACL_STEP_START迭代结束时需传入枚举值ACL_STEP_END。取值详见 aclprofStepTag。stream输入指定 Stream。取值详见 aclrtStream。返回值说明返回0ACL_SUCCESS表示成功返回其他值表示失败具体错误码请参见 aclError。从底层实现 src/dfx/msprof/collector/dvvp/msprofiler/prof_acl_core.cpp 可以看到实际的失败路径主要有两类stepInfo为空指针或同一对象重复设置同一tag如已start再次start、已end再次end返回ACL_ERROR_INVALID_PARAM底层profSetStepInfo上报失败时返回ACL_ERROR_GE_FAILURE。配套接口与生命周期管理aclprofGetStepTimestamp依赖一个描述迭代信息的aclprofStepInfo对象该对象由以下两个接口配套管理详见 docs/zh/api_ref/25-03_Operation_APIs.mdaclprofCreateStepInfo创建迭代信息对象aclprofStepInfo* aclprofCreateStepInfo();返回非空指针表示创建成功返回nullptr表示失败该对象用于描述一次迭代的开始/结束状态是实现层内部持有startFlag、endFlag与自增的indexId见 src/dfx/msprof/collector/dvvp/msprofiler/prof_acl_core.cpp从源码看每个对象创建时会从全局计数g_indexId起始为 1分配一个递增的indexId作为该迭代在 Profiling 数据中的唯一标识见 src/dfx/msprof/collector/dvvp/msprofiler/prof_acl_core.cpp。aclprofDestroyStepInfo销毁迭代信息对象void aclprofDestroyStepInfo(aclprofStepInfo* stepinfo);与aclprofCreateStepInfo配对使用先创建后销毁若不销毁会造成内存泄漏同一对象重复销毁会触发重复释放内存的报错见 docs/zh/api_ref/25-03_Operation_APIs.md。使用约束重点说明同一个aclprofStepInfo对象、同一个tag只能设置一次否则 Profiling 解析会出错。这一约束与底层实现严格对应aclprofGetStepTimestamp内部通过startFlag/endFlag两个布尔位记录状态重复设置会被判定为非法参数并返回ACL_ERROR_INVALID_PARAM见 src/dfx/msprof/collector/dvvp/msprofiler/prof_acl_core.cpp。因此一个 step 周期应使用一个新创建的aclprofStepInfo对象或在复用前完成一次完整的 start → end 生命周期。完整使用流程从初始化到迭代打点结合仓库样例 example/5_performance/profiling/1_msproftx/main.cpp一次完整的初始化 → 开启采集 → 迭代打点 → 停止采集流程如下。第一步初始化 Runtime 与 ProfilingCHECK_ERROR(aclInit(nullptr)); CHECK_ERROR(aclrtSetDevice(deviceIdList[0])); CHECK_ERROR(aclrtCreateStream(stream)); const std::string aclProfPath ./output; CHECK_ERROR(aclprofInit(aclProfPath.c_str(), aclProfPath.length())); aclprofConfig* config aclprofCreateConfig( deviceIdList, 1, ACL_AICORE_ARITHMETIC_UTILIZATION, nullptr, ACL_PROF_ACL_API | ACL_PROF_TASK_TIME | ACL_PROF_MSPROFTX); CHECK_ERROR(aclprofStart(config));要点aclprofInit指定 Profiling 产物输出目录样例中为./outputaclprofCreateConfig声明需要采集的设备、AICore 指标与数据类型其中ACL_PROF_MSPROFTX表明开启 msproftx 类打点能力要采集迭代时间维度建议同时开启ACL_PROF_ACL_APIACL API 耗时与ACL_PROF_TASK_TIME任务耗时aclprofStart后才开始正式采集迭代打点应位于 Start 与 Stop 之间。第二步训练迭代内标记开始与结束int32_t RunTraceFlow(aclrtStream stream) { aclprofStepInfo* stepInfo aclprofCreateStepInfo(); if (!CheckPtr(stepInfo, aclprofCreateStepInfo)) { return -1; } CHECK_ERROR(aclprofGetStepTimestamp(stepInfo, ACL_STEP_START, stream)); // 此处为一次训练迭代中的实际计算模型加载、前向、反向等 // ...样例中穿插 aclprofMark / aclprofPush / aclprofRangeStart 等细粒度打点 CHECK_ERROR(aclprofGetStepTimestamp(stepInfo, ACL_STEP_END, stream)); aclprofDestroyStepInfo(stepInfo); return 0; }对应到真实训练循环伪代码形态为for (int step 0; step totalSteps; step) { aclprofStepInfo* stepInfo aclprofCreateStepInfo(); aclprofGetStepTimestamp(stepInfo, ACL_STEP_START, stream); // data loading - forward - backward - optimizer LaunchForwardOps(stream); LaunchBackwardOps(stream); aclprofGetStepTimestamp(stepInfo, ACL_STEP_END, stream); aclprofDestroyStepInfo(stepInfo); }第三步停止采集并回收资源CHECK_ERROR(aclprofStop(config)); CHECK_ERROR(aclprofDestroyConfig(config)); CHECK_ERROR(aclprofFinalize()); CHECK_ERROR(aclrtDestroyStream(stream)); CHECK_ERROR(aclrtResetDeviceForce(deviceIdList[0])); CHECK_ERROR(aclFinalize());底层实现剖析aclprofGetStepTimestamp在 msprof 组件中的实现位于 src/dfx/msprof/collector/dvvp/msprofiler/prof_acl_core.cpp其执行逻辑为参数校验stepInfo为空直接返回ACL_ERROR_INVALID_PARAM状态机校验startFlag已置位时不允许再次ACL_STEP_STARTendFlag已置位时不允许再次ACL_STEP_END违反则返回ACL_ERROR_INVALID_PARAM状态更新ACL_STEP_START置startFlag否则置endFlag底层上报调用profSetStepInfo(stepInfo-indexId, tag, stream)将迭代索引 开始/结束类型 所在 Stream写入 Profiling 引擎失败返回ACL_ERROR_GE_FAILURE成功返回ACL_SUCCESS。其中indexId由aclprofCreateStepInfo创建时从全局自增计数分配src/dfx/msprof/collector/dvvp/msprofiler/prof_acl_core.cpp是 Profiling 解析时把同一迭代的 start/end 配对关联的关键字段。由此可见接口本身是同步且轻量的它只负责记录标记事件真正的耗时统计仍由 Profiling 引擎依据时间戳在解析阶段完成。单元测试 tests/ut/msprof/msprof/test/prof_acl_core_utest.cpp 验证了核心行为传入nullptr的stepInfo返回ACL_ERROR_INVALID_PARAM正常创建对象后调用返回ACL_SUCCESSaclprofDestroyStepInfo(nullptr)安全失败、正常对象可正确销毁。Python 侧的接口封装仓库的 Python 绑定 python/pyACL/prof/prof_wrap.cpp 提供了对应的WrapAclProfGetStepTimestamp、WrapAclProfCreateStepInfo、WrapAclProfDestroyStepInfo封装说明该能力同样可被 Python 调用层使用。PyTorch 场景中可通过 PyACL 的 prof 模块完成等价的迭代打点C 侧的枚举值与生命周期规则保持一致。常见问题与避坑指南问题原因与处理返回ACL_ERROR_INVALID_PARAMstepInfo为空指针或同一对象对同一tag重复设置。确保每次迭代创建新的aclprofStepInfo或完整走完 start → end 后再复用。返回ACL_ERROR_GE_FAILURE底层profSetStepInfo上报失败通常是 Profiling 未初始化或采集未开启未调用aclprofInit/aclprofStart。请检查采集流程顺序。迭代打点没有生效 / 产物中无迭代维度数据确认已开启ACL_PROF_MSPROFTX等对应采集项且打点调用位于aclprofStart与aclprofStop之间。内存泄漏每个aclprofCreateStepInfo创建的对象都需由aclprofDestroyStepInfo释放二者必须配对。重复释放崩溃同一aclprofStepInfo对象不可重复调用aclprofDestroyStepInfo。关联阅读接口总览19_profiling_data_collection.md配套接口25-03_Operation_APIs.mdaclprofStepInfo/aclprofCreateStepInfo/aclprofDestroyStepInfo枚举与错误码25-02_Enumerations.md、25-01_aclError.md可运行样例1_msproftx含编译运行步骤、0_create_config产物解读Profiling 产物解读底层实现prof_acl_core.cpp单元测试prof_acl_core_utest.cpp【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址: https://gitcode.com/cann/runtime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考