变更摘要

此 PR 修复了 NPU Inductor 中 GELU 分解实现与 eager 模式行为不一致的问题。核心改动是在两个 GELU 分解文件中引入兼容模式检测逻辑，根据 NPU 是否启用兼容模式（are_compatible_impl_enabled）来决定 approximate="none" 时使用 tanh 近似还是 erf 精确路径，使 Inductor 的 GELU 正向/反向计算与 eager 端的 aclnnGelu/GeluV2 选择保持一致。

主要改动

• 新增 _npu_use_compatible_gelu_v2() 辅助函数：在 torch_npu/_inductor/decomposition.py 和 torch_npu/_inductor/dvm/decomp.py 中分别添加了该函数，通过调用 torch_npu.npu.are_compatible_impl_enabled() 判断 eager 端是否使用 GeluV2（兼容模式），用于指导 Inductor 选择合适的 GELU 路径。

• gelu() 前向计算增加 erf 分支：两个文件中的 gelu() 函数从原先仅支持 tanh 近似（0.5 * x * (1 + tanh(...))）扩展为双路径：兼容模式开启且 approximate="none" 时走 erf 精确路径（x * 0.5 * (1 + erf(x / sqrt(2)))），否则走 tanh 近似路径；同时对无效的 approximate 参数值抛出 RuntimeError。

• gelu_backward() 反向计算增加 erf 分支：两个文件中的 gelu_backward() 同样新增 erf 路径的反向梯度计算，使用 cdf（累积分布函数）和 pdf（概率密度函数）组合公式 grad * (cdf + self * pdf)；同时将 tanh 路径的 tanh_derivative 表达式从 (tanh_inner * tanh_inner) * -1.0 + 1.0 简化为 1.0 - tanh_inner * tanh_inner。

• dvm/decomp.py 中 gelu() 实现重写：废弃了原先基于 a / (1.0 + exp(y)) 的近似实现及配套的 dtype 升降精度逻辑，改为与 decomposition.py 一致的 0.5 * a * (1 + torch.tanh(inner)) tanh 公式，统一两个分解文件的计算路径。

• 提取共享常量与辅助逻辑：在 dvm/decomp.py 中新增模块级常量 _M_SQRT2、_M_SQRT1_2、_M_2_SQRTPI、_GELU_KAPPA，并抽取 _gelu_use_tanh_approx() 函数封装 tanh/erf 路径选择逻辑，减少重复代码。

openLiBing可接管PR, PR详情链接:
https://www.openlibing.com/apps/transitionPrDetail?owner=Ascend&repo=pytorch&number=43650&platform=gitcode&codeHostingPlatformFlag=gitcode

代码审查

关闭总结

• P0 × 2：decomp.py 中 tanh（第 84 行）和 sigmoid（第 140 行）存在重复的空函数定义，导致模块 import 时抛出 IndentationError，阻断所有 DVM 路径。
• P3 × 2：两个文件中 _npu_use_compatible_gelu_v2() 的 except Exception 过于宽泛。

整体风险判断：高。P0 问题会导致 torch_npu._inductor.dvm.decomp 模块完全无法加载，阻断 DVM 后端的 patch_decomp() → mlir_fusion.py 调用链，需在合入前立即修复。decomposition.py 中的 GELU 分解逻辑本身正确，仅有一个低风险的异常捕获建议。

⛔ 需要修改

/approve

Pull Request 已合并或已关闭。

If you want to solve this problem, you can click here to do it in the FAQs.