现象

PyAclnnBackend.set_input_dataset（pyaclnn_backend.py:280）每条用例都调 input_dataset.clone_data()，经 dataset_config.py:227 落到 copy.deepcopy。对已经在 NPU 上的 torch 张量做深拷贝走 device-to-device，由 aclnnInplaceCopy 派发一个 TensorMove AI Core kernel；被测算子随后拿到的是一块刚被别的 kernel 写过的显存。

这个前置条件既不在算子仓官方 example 的调用路径上，也不在 torch_npu/testing/common_utils.py:69 的用例构造路径上（torch.from_numpy(x).to(device)，不产生任何 kernel）。

影响

这不是说 ATK 算错了——被测算子本身确有缺陷。问题是这次额外的 kernel 改变了被测算子的执行前置条件，使同一批用例在 ATK 下必现、在不经过这一步的调用路径下完全不复现。

把「被测算子之前有没有多跑一次 AI Core kernel」单独作为变量，两种执行器各跑有/无两档。同一张卡、5 轮交错、每轮 4 条用例（Ascend910_93 / CANN 9.0.0-beta.1 / ATK 26.8.8）：

20/20 逐轮完全一致，两条执行器各自翻面。ATK 那一档靠临时改 _safe_deepcopy 直接返回原对象来切换（实验用，非 ATK 现有开关）；C++ 那一档无额外 kernel 时用 aclrtMemcpy 搬输入（DMA 不发 kernel），有额外 kernel 时先 H2D 到 staging 再 aclnnInplaceCopy 交进去。失败现场两侧逐位相同，含硬件错误寄存器。

建议

ATK 自身已有这个开关，只是这一处没走它。Backend.__init__ 里 use_clone = False（注释「确定性计算时开启」），其余后端都是 clone_data() if self.use_clone else self.input_data：

同一个文件的 515 行已经按 use_clone 判了，280 这处漏了，于是默认路径（use_clone=False）上仍然照拷。

建议让 280 也遵守 use_clone；若该深拷贝是为了保护原始输入不被就地改写，可改为不触发 kernel 的方式（host 侧拷完再上卡）。