标题：【26.2.0众测】Inductor默认后端（Triton）编译resnet18推理比Eager慢25~79倍：bf16/reduce-overhead/dynamic=False均无法规避

建议标签：性能 / inductor / triton

环境信息

问题描述

使用默认后端 torch.compile(model, backend="inductor")（Triton）编译 TorchBench 清单中的
resnet18 做推理，性能不仅没有提升，反而大幅倒退，且 batch 越大退化越严重：

计时方式：torch.npu.synchronize() 后对 20 次推理取均值（另附任务书要求的
单次 time.time() 计时：Eager 0.0051s vs Compiled 0.0064s，因首次下发含同步
开销，稳态均值更能反映真实性能）。

复现步骤

import torch
import torch_npu

model = resnet18().npu().eval()      # TorchBench 清单模型
x = torch.randn(8, 3, 224, 224, device="npu")

compiled = torch.compile(model, backend="inductor")   # 默认 Triton
with torch.no_grad():
    compiled(x)   # 触发编译

# 稳态性能
torch.npu.synchronize()
start = time.time()
for _ in range(20):
    with torch.no_grad():
        compiled(x)
torch.npu.synchronize()
print((time.time() - start) / 20)   # ~0.090s，对比 Eager 的 ~0.0036s

已排除的因素

• 正确性正常：eager vs compiled max diff = 4.47e-08（PASS），非错误结果导致的伪对比
• 无图断裂：TORCH_LOGS=graph_breaks 下无任何 graph break
• 首次编译开销：预热充分后再计时（20 次均值）
• 非首次下发同步：稳态均值已含同步

对照组（同模型同环境）

DVM/NPUGraphs/TorchAir 均有收益，唯独默认的 Triton 模式严重倒退，
问题可定位到 Triton-Ascend 生成的 kernel 实现。

已尝试的规避手段（均无效，用户侧无可规避）

版本无关性：在环境预装的官方配套组合 PyTorch 2.7.1 + torch_npu 2.7.1.post8
上复现同样倒退（bs=8 稳态 0.07x），排除 2.9.0 特有回归；两版本线数据见
材料 PR #38 的 补充-测试报告与原始日志/原始日志/（2.7.1）与
torch2.9.0_补充环境/（2.9.0）对照。

结论：慢在 Triton 生成的 kernel 的设备执行时间本身（90ms 随 batch 线性增长，
为真实计算耗时），常规用户侧手段（精度、模式、动态 shape）均无法规避，
必须从 Triton-Ascend 的 kernel 代码生成层解决。

影响

官方文档《Inductor》将 Triton 定位为"默认选择，适用于大多数场景，不确定时首选"，
但实测其为所有后端中性能最差（比 Eager 还慢 25~79 倍），新手按文档默认用法
将直接获得负优化，容易对 torch.compile 产生"不仅不加速还变慢"的整体印象。

期望

1. 排查 Triton-Ascend 3.2.2 在 910B3 上 conv/bn 类算子的代码生成路径
   （疑似生成了未充分优化的通用 kernel，未利用 NPU 高性能实现）
2. 文档更新：在性能数据出来之前，补充已知性能限制说明，或调整"默认首选"的表述

证明材料

运行结果截图（下图为 PR #38 配套材料中的运行终端输出，可直接点击查看）：

提交 issue 时请将上图作为附件上传（截图中含 eager vs compiled 最大差异: 4.470e-08、
稳态均值(20次): Eager: 0.0037s, Compiled: 0.0903s、加速比: 0.04x 完整终端输出）。

完整终端日志：补充-测试报告与原始日志/原始日志/07_Inductor-Triton.log