更新说明（2026-08-20）：本 issue 初版提出时，我们环境上的 ATK 是从 master 7220f27（2026-08-07）构建的，其中还没有 kernel 后端，因此初版只能基于源码阅读提问。之后我们按 master a0dfc9a 重新构建安装了 26.8.8 并做了实测，正文已据实测结果重写。

背景

在评估使用 ATK 测试社区算子工程时，我们发现源码中存在一条 kernel 后端通路，但在《ATK 使用指南》中没有找到对应说明。我们已在 26.8.8 上实测确认这条链路可以工作，现在想确认的是它的定位与支持状态。

已验证的事实（ATK 26.8.8，源码 a0dfc9a 构建）

1. 链路可端到端跑通

用例填 kernel_name: Abs（CANN 内置算子，已注册进 OPP），节点配置 backend: kernel + backend: cpu，atk task 执行结果：2 条用例全部执行成功，精度比对通过率 100%，耗时 37s。

产物完整，逐站可验：

• kernel/Abs/0/abs.json —— atc --singleop 的输入描述（input_desc / output_desc / attr）
• kernel/Abs/0/0_Abs_0_2_7_0_2_7.om —— ATC 编译产物（12K）
• kernel/Abs/0/kernel_meta/te_abs_<hash>.json —— 从 OPP 取到实现后编出的 TBE kernel
• PROF_* —— 性能采集目录

调用链与源码一致：KernelBackend（kernel_backend.py:43-45）→ @register("kernel_function")（function_api.py:164）→ tiktools.run（tools/init.py:201，其中读取 ASCEND_OPP_PATH）→ atc.generate_om（tools/atc_om.py:40-42, 70，子进程执行 atc --singleop）→ acl.op.execute_v2。

2. 对照实验：这条链依赖 OPP 中的 op_type 注册

保持上述用例的全部内容不变，仅把 kernel_name 从 Abs 改为 GemmEx（ops-blas 中一个算子的名字，该仓不产生 GE 注册）：

我们也确认了该 SoC（ascend910_93）的 OPP 内置算子信息表共注册 1188 个 op_type，其中 blas 类为零（trsm/syrk/gemv/spmv/getrf/blas 均为 0 命中），opp/vendors/ 为空。

3. 文档中仍未见相关说明

《02 参考资料/节点配置文件说明》中 backend 取值列为 npu、cpu、gpu、aclnn，未包含 kernel；全文档未检索到 kernel_name、kernel_function、-b kernel 的说明或示例；examples/ 目录只提供了 aclnn 与 pytorch 两类样例。

问题

1. kernel 后端是否为受支持的测试场景？适用边界是什么？

从实测看，它要求算子已按 GE op_type 注册并部署进 OPP（kernel_name 填的是 op_type）。想确认这是否是设计意图，以及它面向的算子形态具体是什么——例如「有 GE 注册但没有 aclnn 层」的算子（这类在 ops-math 的 math/ 下约占三分之一）是否正是它的目标场景。

（不进 OPP 的句柄式 C API 算子库能否测试，我们另开了 #23 单独请教，此处不重复。）

2. tools/atc_om.py 的 atc --singleop → .om 路径，成熟度如何？

是实验性/内部验证用代码，还是可用于正式测试场景？后续版本是否有兼容性承诺（是否可能调整或移除）？我们需要据此决定能否把它写进对外的测试流程。

3. 执行器注册表是否为受支持的扩展点？

KernelBackend 通过 ApiExecuteFactory 按 kernel_api_type 取执行器，看起来是可插拔的。如果我们为句柄式 C API 自行实现一个执行器并注册进去，这是否是官方推荐/支持的扩展方式？有没有需要遵守的约定？

4. 若该场景受支持，能否补充文档与最小可运行示例？

主要是 YAML 中 kernel_name、api_type 的写法，-b kernel 与 nodes.yaml 的用法，以及对算子前置条件（须在 OPP 中注册）的说明。

5. （相关）另一条 kernel 执行分支的定位

atk/tasks/backends/tools/acl_execute.py 中还有一条基于 kernel_meta/*.o 与 acl.op.register_compile_func / create_kernel 的执行分支，它与上述 kernel 后端标准链路是什么关系？在什么条件下会被使用？

附带发现（两个小问题）

1. pytz 未在 requirements.txt 中声明：atk/db/dao/case_result_dao.py 直接 import pytz，但依赖清单中没有它。全新环境安装后 pip show atk 正常、atk case --help 也正常，一执行 atk task 才报 ModuleNotFoundError: No module named 'pytz'。

2. 版本号在一段时间内未随功能更新：atk/__init__.py 的 PACKAGE_VERSION 在 7220f27（2026-08-07）时仍为 26.5.14，直到 b3e4691（2026-08-11，"新功能同步"）才更新为 26.8.8。因此从 8 月初 master 构建出的包会自称 26.5.14，容易被误认为是 5 月的版本。

环境信息

- 操作系统: aarch64 Linux（容器内）
- 昇腾硬件: Ascend910_93
- CANN 软件版本: 9.0.1
- ATK 版本: 26.8.8（由 master a0dfc9a 源码构建）