现象

按独立安装方式部署自定义算子包（ASCEND_CUSTOM_OPP_PATH 指向 vendor 目录），用 ATK 跑该算子时：kernel .o 来自自定义包（正确），但 tiling 解析到的是 CANN 内置那一份。即实际测的是「自定义包的 kernel + 内置的 tiling」这个混合组合，全程无告警、退出码正常。

换成不链 torch_npu 的裸 aclnn C++ 程序，在完全相同的环境变量下调同一个算子，tiling 用的就是自定义包那份。

证据

tiling 函数在 DEBUG plog 里会打出所在源码的文件名与行号，两份实现行号不同：

GE 的 tiling 函数槽位是先到先得，日志措辞可区分。ATK 进程里（op type IndexFill）：

op type IndexFill tiling func has been registered   × 10
op type IndexFill tiling func registered            ×  0

自定义包那次注册全部被跳过。原因是 torch_npu 链着整套 GE（ldd libtorch_npu.so 可见 libge_runner.so / libgert.so / libregister.so），GE 会更早把内置 op host 加载进来。

影响

两份 tiling 会算出不同结果。同一条用例上，自定义包那份算出 tilingKey=1、内置那份算出 0，发射的 kernel 不同，一个 aclrtSynchronizeStream 返回 507015、一个通过。

用 ATK 验收与内置同名的自定义算子时，结论指向的不是被测代码，而使用者没有任何提示。

试过但无效

GE 算出的插件搜索路径里自定义 vendor 已排第一、built-in 排最后，但那个顺序只作用于扫描，不决定 tiling 函数槽位的归属。

期望

至少能检出并告警「本次执行采用的 tiling 不来自 ASCEND_CUSTOM_OPP_PATH 指向的算子包」。

注册顺序发生在 GE 侧，可能需与 CANN 一并确认；提给 ATK 是因为它是这一问题的可观测入口，且直接影响 ATK 的结论是否指向被测算子包。

环境

ATK 26.8.8 / CANN 9.0.0-beta.1 / torch 2.10.0 / torch_npu 2.10.0 / Ascend910_93（A3）。被测算子为 ops-nn 的 experimental/index/index_fill，op type IndexFill 与 CANN 内置同名。