PyPTO-Gym 性能调优实战基于 CANN msprof 的七指标采集、逐核分析与主 Bound 判定指南【免费下载链接】pypto-gymPyPTO-Gym 是基于 PyPTO 编程框架构建的算子与模型样例仓库项目地址: https://gitcode.com/cann/pypto-gym本文是 CANN/PyPTO-Gym 仓库中pypto-pro-op-perf-tune技能链的性能采集与分析实战指南面向使用 PyPTO 编程框架开发 NPU 算子并需要量化、定位、优化性能的开发者。文章以 msprof 采集与分析指南 为主线结合仓库内一键采集脚本、归档统计脚本与字段参考文档完整讲解如何使用 CANN 自带msprof采集 7 组--aic-metrics与 sample-based 逐核数据如何通过msprof_perf_summary.py归档出可分析的op_summary_*、per_core_cycles.csv与summary.txt并给出从主 Bound 判定到逐核负载均衡再到通用分析纪律的一整套可落地的性能诊断方法论。读完本文你将掌握在 PyPTO 多 case 测试脚本中精确定位目标 kernel、规避 msprof 聚合指标陷阱、以及用数据驱动优化项立项的完整实操能力。适用场景msprof是 CANN 官方性能剖析工具PyPTO-Gym 的性能调优技能链以它为默认采集手段。根据任务形态不同仓库提供了四种运行模式对应命令与产出如下场景推荐命令说明PyPTO 算子性能采集msprof_profile_run.shmsprof_perf_summary.py标准采集 7 组 aic-metrics 深度瓶颈分析PyPTO 算子 vs golden 标杆对比msprof_profile_run.sh --compareGolden 报告 target-kernel Task Duration 得到参考比值优化前后回归msprof_profile_run.shmsprof_perf_summary.py对比独立归档 round快速候选筛选msprof_profile_run.sh --quick只采 Task Duration不替代最终正式采集批量性能测试msprof_profile_run.sh --batch多 NPU 并行批量测试其中脚本入口统一为 msprof_profile_run.sh脚本头注释中明确定义了四种模式的职责标准模式对单个可执行文件 / PyPTO-Pro Python runner 采集 7 组 aic-metrics sample-based--compare模式从GOLDEN_PERF_REPORT.md读 golden 数据并与 msprof 采集的 PyPTO 算子时间对比--quick模式每次 repeat 只采集 kernel 时间--batch模式批量扫描多个算子子目录并行执行。使用各 CANN 自带的msprof多组--aic-metrics sample-basedaicore.db得到可分析的op_summary_*、per_core_cycles.csv与summary.txt。下文命令中的PERF_SKILL_ROOT指本 skill 实际目录的绝对路径执行前按安装位置设置算子目录可替换为项目实际路径。脚本运行模式本节介绍不传--case-manifest时的既有兼容模式及命令语义。本 skill 性能调优使用的 compare、quick 和 batch 必须改按 证据协议 执行两种模式的 Golden、seed、逐 case 选择和输出文件不同不能混用。1. 标准采集模式深度瓶颈分析按下文 Step 2 与 Step 3 采集七指标与 sample-based 证据把采集命令中的 demo 替换为python3 test_{op}.py并用精确--op-name解析目标 kernel。该模式下 msprof_profile_run.sh 依次执行warm-up 若干次规避 DVFS → 按METRICS(PipeUtilization ArithmeticUtilization Memory MemoryL0 MemoryUB L2Cache ResourceConflictRatio)顺序逐组运行msprof --ai-coreon --aic-metrics$M --task-timeon --ascendclon→ 追加一次--aic-modesample-based --aic-freq100采集用于逐核负载均衡分析。2. 对比测试模式跨口径参考比值从GOLDEN_PERF_REPORT.md读取 Golden 非噪声 device-kernel E2E 总时长用 msprof 采集 PyPTO target-kernel Task Duration计算Golden E2E / PyPTO target-kernel参考比值。两端计时范围不同该值不是同口径 optimization speedup也不能作为正式性能对比formal compare。为兼容既有产物脚本仍使用speedup、*_speedup和加速比等旧字段名解释时必须遵循本段语义。行为说明--warm-upN会在正式采集前真实执行 N 次默认为 3。--repeatsN在对比和快速模式中都生效默认为 1。N 大于等于 3 时去掉最大值和最小值后取平均N 小于 3 时取中位数。--seedN通过PYPTO_PERF_SEED传入测试脚本同时设置PYTHONHASHSEED。测试脚本应读取PYPTO_PERF_SEED来固定随机输入。msprof 临时数据写入算子目录下的.msprof/并使用 PID 和时间戳隔离并发任务。bash $PERF_SKILL_ROOT/scripts/msprof_profile_run.sh --compare \ --output-dir./custom/{op} --warm-up3 \ --device0 --op-nameOp Name --repeats3 --seed0前置条件兼容--compare、--quick均需要custom/{op}/GOLDEN_PERF_REPORT.md兼容--batch的每个算子目录也需要该报告。正确性 Golden 不代表已采集性能报告只有用户明确要求 golden 性能采集或 golden 基线对比时才先以collect_golden_perftrue调用pypto-pro-golden-generate生成报告。若用户只要求 PyPTO kernel 自身的性能采集或瓶颈分析使用标准模式不要为了它自动采集 golden。必须指定--op-name与标准采集模式同理PyPTO 测试脚本含多个 case torch.randn不指定会选到非目标 op。Op Name 获取方法见 Step 3。逐 case 限制该既有兼容模式没有标准的逐 case 选择协议。如果GOLDEN_PERF_REPORT.md包含多个 case工具会明确报错不会把一次聚合耗时复用到所有 case。请按 case 分别产出报告后再对比。输出performance.json、performance.log、perf_report.md。从 msprof_profile_run.sh 的run_compare实现可以看到该模式实际是转发调用python3 msprof_perf_summary.py --compare --output-dir dir --warmup N并透传--device、--op-name、--repeats、--seed、--retry、--keep-prof等参数--keep-prof可保留 msprof 原始 PROF 目录用于深度分析。3. 快速模式不采集 aic-metrics只采集 kernel Task Duration不采集 7 个 aic-metrics适合快速验证优化效果。--warm-up、--repeats、--seed和逐 case 限制与对比模式一致。bash $PERF_SKILL_ROOT/scripts/msprof_profile_run.sh --quick \ --output-dir./custom/{op} --warm-up3 \ --device0 --op-nameOp Name --repeats3 --seed0输出performance.json、performance.log、perf_report.md。从源码看快速模式绕过脚本自身的 7 组采集循环直接由 msprof_perf_summary.py 中的_run_msprof_quick以msprof --task-timeon --ascendclon完成单次采集再优先从task_time_*.csv解析 kernel 耗时缺失时回退到api_statistic_*.csv的 launch 行_select_kernel_times同样遵循N≥3 去极值取平均、否则取中位数的聚合规则。快速模式定位为候选筛选不能充当正式交付证据。4. 批量并行模式多 NPU扫描目录下所有算子子目录多 NPU 并行执行对比测试bash $PERF_SKILL_ROOT/scripts/msprof_profile_run.sh --batch --base-dir./custom --max-jobs7 --device-start1输出各子目录performance.jsonbatch_performance.logbatch_report.mdbatch_summary.json使用边界该兼容 batch 不传逐目录--op-name仅适用于每个 runner 的目标 kernel 可唯一归属的目录含多个 AI_CORE op 时使用 manifest batch并传入精确的--op-name或--op-name-map。源码层面既有 batchrun_batch_legacy通过/tmp/ascend_locks_$$/device_id.lock的 flock 锁 ASCEND_RT_VISIBLE_DEVICES轮转实现设备互斥而 manifest 证据批run_batch_manifest会先做完整预检校验--max-jobs1..8、--device-start0..7、--op-name与--op-name-map二选一、每个算子目录必须有PERFORMANCE_CASES.json全部通过后才启动任何 msprof失败批次不会覆盖上次成功汇总每轮日志/报告带 collection id。PyPTO-Pro 输入与输出采集脚本执行算子目录中已有、已按算子合同通过全量正确性测试的 runner优化前后必须保留 wrapper 边界、Golden 语义与精度门槛。独立输入的要求见主 Skill若项目使用 Develop Skill也须保留其测试合同。逐 case 输入、Golden 机器合同和输出证据以证据协议为准。不传 manifest 的兼容 compare/quick 输出仍按上面的模式说明生成。需要特别强调的是完整test_{op}.py的 profile 会混入输入生成、Golden 和精度检查不能把其中的aclnn*直接归因给 wrapper也不能据此计算 wrapper 占比。PyPTO-Pro wrapper 合规由 wrapper 边界合同 裁决profile 只提供性能证据不能授权越界。性能结论只使用可唯一归属到目标 kernel 或冻结 case 的字段和计时口径。平台与工具选择在加载任何平台专属模型前先运行 get_npu_arch.py 或读取构建配置记录设备型号、NpuArch、CANN/PyPTO 版本和pypto_pro.__file__。该脚本通过ctypes调用libascend_hal.so查询芯片信息例如Ascend950映射为原始NpuArch3510见脚本内SOC_TO_NPUARCH映射表默认输出形如dav-3510--raw输出原始数字python3 cannbot-skills/ops/pypto-pro-environment-check/scripts/get_npu_arch.py # 例如 dav-3510 python3 cannbot-skills/ops/pypto-pro-environment-check/scripts/get_npu_arch.py --raw # 例如 3510判定规则仅当结果确认 raw 输出3510NpuArch值、helper 输出dav-3510、runtime 输出DAV_3510或构建目标dav-c310时加载 A5 roofline 与杠杆对未知平台或非 A5 平台不应用 A5 核数、容量、带宽、频率或经验结论直接使用该平台的官方资料与本次 profiler 数据平台探测失败时将平台模型标记为不可用但仍可继续做不依赖硬编码常量的实测瓶颈分析。工具选择顺序用户指定msprof op/ msopprof 时走 msprof op 指南指定msprof时走本文。用户未指定时探测环境仅msopprof可用则走 msprof op仅msprof可用则走本文两者皆可用时向用户确认或遵循项目约定两者皆不可用时报错并检查 CANN /ASCEND_HOME。脚本层面msprof_profile_run.sh 在启动时会先检查command -v msprof找不到即提示 请先 source CANN set_env.sh / setenv.bash 并退出。Step 1构建算子如果有指定的调用方式这一步可跳过直调算子cd ops/{operator_name} mkdir -p build cd build cmake .. make -jaclnn 算子bash build.sh --pkg --socascend910b --ops{operator_name} --vendor_namecustom -j16 ./build_out/*.run --install-path$CANN bash build.sh --run_example {operator_name} eager cust --vendor_namecustom注意PyPTO-Pro 的已核实官方入口是msprof python3 test_kernel.py只有msprof op/msopprof明确支持 Python runner 时才套用 AscendC 可执行文件构建流程见证据协议。环境不支持时回到本文流程。Step 2采集原生msprof每次运行只支持一个--aic-metrics组且op_summary_*.csv是 per-op 聚合值而非逐核。流程在正式采集前 warm-up N 次规避 DVFS按顺序分别采集 7 组--aic-metricsPipeUtilization、ArithmeticUtilization、Memory、MemoryL0、MemoryUB、L2Cache、ResourceConflictRatio额外跑一次--aic-modesample-based从device_0/sqlite/aicore.dbAICoreOriginalData.task_cyc拿到逐核 cycle以 aicore_time / max_cycles 反推主频把逐核 cycle 折算成 per-core 时长一键脚本bash $PERF_SKILL_ROOT/scripts/msprof_profile_run.sh \ --warm-up3 \ --output./msprof_output \ -- ./demo arg1 arg2 ...关键点msprof 的op_summary.csv没有Current Freq/Rated Freq和逐核time(us)字段逐核分析必须依赖PROF_Sample下的aicore.db。采集落盘目录树见文末数据目录结构 → 临时输出根路径为--output下的PROF_GROUP_*。从 msprof_profile_run.sh 的run_standard实现可见7 组指标的 msprof 命令形如msprof --outputSUB --ai-coreon --aic-metricsM --task-timeon --ascendclon -- app而 sample-based 组额外加上--aic-modesample-based --aic-freq100若 sample 采集失败只告警WARN不中断逐核分析会被跳过。Step 3归档 统计摘要GROUP_DIR$(ls -td output_dir/PROF_GROUP_* | head -1) # 获取目标 kernel 的 Op NamePyPTO 多 case 场景必须指定 --op-name CSV$(ls $GROUP_DIR/PROF_PipeUtilization/*/mindstudio_profiler_output/op_summary_*.csv | head -1) grep -i {kernel_func} $CSV # {kernel_func} pl.jit 装饰的函数名 python3 $PERF_SKILL_ROOT/scripts/msprof_perf_summary.py $GROUP_DIR ops/{operator_name} --op-nameOp Name重要PyPTO 测试脚本test_{op}.py通常包含多个 case torch.randnop_summary中会有大量非目标 op如StatelessNormal噪声注入。必须指定--op-name选中目标 kernel否则会选到非目标 op 导致结果完全错误。--op-name取同名 kernel 中 Task Duration 最大的行即最大 workload 的 case。更严谨的做法正式 baseline 前先做一次 discovery profile 并列出完整 lowering 名称。证据协议给出的命令是先用msprof_profile_run.sh采集runner 已有 selector 时用--case-id id只选一个已知 case 并只 launch 一次 target kernel然后用python3 msprof_perf_summary.py $GROUP_DIR --list-op-names列出精确 Op Name结合pl.jit函数名、Task Type 与 discovery 中唯一的 target launch 确认完整 mangled Op Name再传给正式 compare。若仍有多个候选或同名多次 launch先修正 discovery 入口不能选择最长 Task Duration详见证据协议。脚本会在ops/{operator_name}/docs/perf/round_NNN/创建归档目录轮次自动递增按目标Op Name在 7 份op_summary.csv里合并列复制为op_summary_Metric.csv读PROF_Sample/.../aicore.db的task_cyc根据aicore_time(us)反推主频换算每核耗时输出summary.txt在全局统计之外附加「逐核负载均衡」段例如--- 逐核负载均衡 (sample-based aicore.db) --- 有效核数: 32 | 主频推算: 1.651 GHz (0.6058 ns/cycle) min185.93us avg193.13us max199.27us (max-min)/max 6.69% - 达标 (10%) Top-3 慢核: Core3199.27us, ... Top-3 快核: Core21185.93us, ... [提示] 前半段 core 均值 198.17us vs 后半段 188.10us差距 5.99% 疑似两簇 (NUMA / L2 slice) 负载偏斜建议尝试 block swat / 尾轮均衡策略。同步把per_core_cycles.csv归档到同目录方便二次分析归档完成后即结束本 Step 的职责。下游从summary.txt含逐核负载均衡段、op_summary_*.csv、per_core_cycles.csv读取指标后按下文主 Bound 判定推导主 bound 档位。源码级实现细节见 msprof_perf_summary.py逐核数据读取load_per_core_cycles用 sqlite3 打开PROF_Sample/PROF_*/device_0/sqlite/aicore.db执行SELECT coreid, SUM(task_cyc) FROM AICoreOriginalData WHERE task_cyc0 GROUP BY coreid ORDER BY coreid主频反推ns_per_cyc aicore_time(us) * 1000 / max_cycfreq_ghz 1.0 / ns_per_cyc再将每核 cycle 折算为时长负载均衡三档判定(max-min)/max 10%判PASS (10%)10~30% 判Warning30% 判Critical issue前后半簇检测按 coreid 排序后对半分两半均值差距 ≥2% 时提示疑似 NUMA / L2 slice 负载偏斜archive_deep_profile还会把采集命令写入collection.log、生成evidence_status.json含seven_metric_status、per_core_status、bound_diagnosis。主 Bound 判定msprof 归档本节适用于msprof经 Step 23 得到的归档目录round_NNN/。输入与输出项目说明输入从归档中的op_summary_*.csv、summary.txt等抽取的单核侧各流水线busy 占 case或 task总时长的百分比不适用msprof 聚合指标无可对照流水图的气泡时间报告中气泡列标注「不适用」不得填写气泡数值输出主 bound 档位MTE2 BOUND/CUBE BOUND/VEC BOUND/FIXP BOUND/MTE3 BOUND/SCALAR BOUND/无 bound各流水线 busy 占比的抽取与列映射以本文 Step 3 产物及 csv_fields_reference.md 为准若归档 CSV 表头与文档示例不一致以实际表头为准。判定规则在已得到各流水线 busy 占比后从上到下匹配第一条成立优先级Bound 类型判断规则1MTE2 BOUNDMTE2 busy 占 case 80%或MTE2 在 8 条中占比最大且 70%2CUBE BOUNDCUBE busy 占 case 80%或CUBE 在 8 条中占比最大且 70%3VEC BOUNDPUSHQ busy 占 case 80%4FIXP BOUNDFIXP busy 占 case 80%5MTE3 BOUNDMTE3 busy 占 case 80%6SCALAR BOUNDSCALAR busy 占 case 80%或 SCALARLDST busy 占 case 80%—无 bound以上条件均不满足「占比最大」比较对象为上述单元对应的统计。实现对照代码中的双阈值即BOUND_ROUTE_HIGH_THRESHOLD 0.80与BOUND_ROUTE_MAX_THRESHOLD 0.70见 msprof_perf_summary.py 顶部常量与上表 80% / 70% 规则一一对应。实际路由在 evidence_cli.py 的diagnose_bound_route中实现先按aicore_time与aiv_time取主导核max(aicore_time, aiv_time)再按字段家族收集 ratiocompute/data_movement/scalar命中条件为value 0.80或(value max value 0.70)输出routing_label为compute_candidate/data_movement_candidate/scalar_candidate/mixed/no_dominant_pipe。注意summary.txt中会明确标注 Bound routing (ratio-derived; NOT terminal Roofline proof)即 op_summary 聚合 ratio 只负责给下一项实验指路不含事件排序不能证明 DMA/计算重叠也不能单独宣告 Roofline 终态pipeline_overlapunverified。数据目录结构临时输出msprof_profile_run.sh的--output目录下output_dir/PROF_GROUP_YYYYMMDD_HHMMSS/ ├── PROF_PipeUtilization/PROF_*/mindstudio_profiler_output/op_summary_*.csv ├── PROF_ArithmeticUtilization/... ├── PROF_Memory/... ├── PROF_MemoryL0/... ├── PROF_MemoryUB/... ├── PROF_L2Cache/... ├── PROF_ResourceConflictRatio/... └── PROF_Sample/PROF_*/device_0/sqlite/aicore.db ← 逐核 task_cyc持久归档ops/{算子名}/docs/perf/ ├── round_001/ │ ├── op_summary_PipeUtilization.csv │ ├── op_summary_ArithmeticUtilization.csv │ ├── op_summary_Memory.csv │ ├── op_summary_MemoryL0.csv │ ├── op_summary_MemoryUB.csv │ ├── op_summary_L2Cache.csv │ ├── op_summary_ResourceConflictRatio.csv │ ├── op_statistic_Metric.csv │ ├── task_time_Metric.csv │ ├── per_core_cycles.csv │ └── summary.txt └── ...字段含义详见 csv_fields_reference.md按op_summary_*列名对齐同类指标。若使用 manifest 证据协议持久归档为逐 case、逐 repeat 结构docs/perf/round_NNN/case_case-id_hash/repeat_NNN/并包含collection.json、measurement.json、evidence_status.json、process_scope_core_cycles.csv与instruction_timeline/详见证据协议不传 manifest 的标准模式保持本文的单层结构不变。关键字段速查来自 csv_fields_reference.mdop_summary各 CSV 的核心字段及其瓶颈判定阈值如下供下游分析角色引用指标族关键字段判定语义OpBasicInfoTask Duration(us)、Block Dim、Current Freq、Rated FreqTask 总耗时是核心指标Current Rated说明 DVFS 降频PipeUtilizationai*_mte2_ratio、aic_cube_ratio、ai*_vec_ratio、ai*_scalar_ratio、aic_fixpipe_ratioMTE2 50%、SCALAR 30%、FIXP 15% 需关注最重要文件ArithmeticUtilizationaic_cube_fops、aic_cube_fp16_ratio、aiv_vec_fops计算量、浮点运算总数用于理论利用率Memoryai*_main_mem_read/write_bw(GB/s)、GM_to_UB_bw_usage_rate(%)带宽利用率 60% 良好A5/CANN 9.2 上*_datas(KB)字节字段不存在MemoryL0aic_l0a/l0b/l0c_*_bw(GB/s)L0A/L0B/L0C 读写带宽主要关注 Cube 场景MemoryUBaiv_ub_read/write_bw_vector/scalar(GB/s)Vector/Scalar 对 UB 读写带宽L2Cacheai*_read_hit_rate(%)、ai*_total_hit_rate(%)80% 良好50% 需优化ResourceConflictRatioaiv_vec_bankgroup_cflt_ratio、aiv_vec_bank_cflt_ratio、aiv_vec_resc_cflt_ratiobankgroup/bank 3%resc 5% 良好上板独有数据关于 Memory 字节字段csv_fields_reference.md 有明确的一手告警在 CANN 9.2.0 / A5Ascend950PR上read_main_memory_datas、write_main_memory_datas、GM_to_L1_datas、L2_to_L1_datas等字节字段在ai_core_op_summary.db中ABSENT实际存在的是带宽字段GB/s且不要把main_mem_*_bw积分当作 DRAM 流量一个权重流式 attention 类算子上积分结果比 cold 字节下限低约一个量级。在 A5 上做搬运量闭合可按文档建议用aic_l1_write_bw × 28 × aic_total_time闭合 requested 侧字节且定价系数必须在自己算子的当前配置上重新标定不能沿用别处的数。通用分析纪律本节只提供分析证据调优项的来源、建项时机和登记要求以主 Skill 及 优化项实验闭环 为准不能仅凭本节文字建立优化项。kernel 总耗时不是 DMA floor。要估计纯搬运下界单独运行只含合同 loadstore 的 sweep完整 kernel 时间同时包含计算、依赖和固定开销不能反过来当搬运下界。按与参照或下界的差距排诊断优先级。SOL 或某一 pipe ratio 无法区分并行度不足与单元素效率低应把每个 case 与同一目标、工具链、shape/tiling 下可复核的 sibling reference 或 floor probe 比较。说清证据类型。sibling reference 是更简单算子的同条件实测只用于估算量级和排序不同算子的启动、融合、访存、同步和必需指令可能不同不能据此界定任意实现或证明目标可达或不可达。floor probe 只界定必要数据搬运不给语义必需计算或跨 lane 原语定价当前想到的杠杆求和也只描述该清单。认定硬边界还须证明哪些工作不可省略以及比较方向。单个 kernel 不能代表框架 roofline。某 kernel 的带宽、拐点或利用率只描述当时的访问形态推断平台或框架限制必须有独立 probe、平台资料和其它实现的可复核证据。串行依赖、历史估算和旧二进制都需排除。依赖链要用生成物/trace/受控 A-B 证明结构改变后重新推导估计body 修改后验证生成物身份。实验细则见 优化项实验闭环。更完整的 sibling/floor/证伪纪律见 KB investigation discipline。注意事项必须 warm-up脚本默认--warm-up3可调避免 DVFS 影响首次运行无频率字段op_summary没有Current Freq/Rated Freq脚本通过aicore_time / max_cycles反推主频MTE2/MTE3 带宽共享同时读写 GM 时总带宽共享评估搬运段负载时宜按 MTE2、MTE3 合并字节量与平台带宽对照小数据量场景数据量很小时头开销占比会很高这不一定是算子问题多核同地址访问多核同时读同一 512B 地址范围会被串行化导致 MTE2 耗时异常补充两条来自证据协议的纪律与 msprof 采集直接相关逐核证据作用域sample-based 的aicore.db是进程级逐核 cycle不一定能按精确Op Name关联目标 kernel无法归属时必须记录per_core_status并归档process_scope_core_cycles.csv不得拿目标aicore_time换算后冒充目标逐核证据。DVFS 归因Current Rated只生成 DVFS 假设需重复采样或受控频率 A/B 才能归因当前 case 须先确认稳态再冻结 baseline/final 相同的 warm-up 与 repeat不能把某个默认值当跨平台常数。相关资源文件内容csv_fields_reference.md字段定义和阈值按op_summary_*列名对齐供下游分析角色参考msprof_profile_run.sh一键采集脚本Step 2 调用四种模式统一入口msprof_perf_summary.py归档 摘要 逐核负载均衡Step 3 调用evidence-protocol.md逐 case manifest、seed、Golden、归档与时间线证据协议evidence_cli.pybound 路由判定、--list-op-names、timeline 等 CLI 实现optimization-playbook.md五类优化项的登记、实验、重开与关闭闭环msprof-op-guide.mdmsprof op/ msopprof 补充诊断流程主 Skill性能调优的优化来源、执行顺序与交付边界get_npu_arch.py平台架构探测dav-3510/ raw3510【免费下载链接】pypto-gymPyPTO-Gym 是基于 PyPTO 编程框架构建的算子与模型样例仓库项目地址: https://gitcode.com/cann/pypto-gym创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考