在提交新问题之前，请确保您已经在社区中搜索过相关问题，并使用了社区中提供的资源/工具后，仍未找到满意的解决方式。

⚠️ 安全信息提醒：请仔细检查提供的文本内容，确保其不包含敏感数据信息，包括但不限于：

• API 令牌或密钥
• 密码或身份验证凭证
• 私有网址或接口地址
• 个人或机密数据
• ...

在分享配置信息或代码示例时，请将敏感信息脱敏处理，或使用 <TOKEN> 等占位符替代原有内容。

环境信息

- 操作系统 Ubuntu 22.04.5 LTS（aarch64）
- 昇腾硬件信息 910B2
- CANN软件版本 9.1.0.beta1
- 安装的对应软件版本 2.13（torch 2.13.0 / torch_npu 2.13.0，Inductor 后端 npu_backend=triton_experimental，triton-ascend 3.2.2）

🐛 问题描述

触发条件：torch.compile（Inductor 后端）遇到 grid>65535 的 1D pointwise 融合 kernel——当张量元素数在 UB 预算封顶的 XBLOCK 下满足 ceildiv(numel, XBLOCK) > 65535 时（例如 numel=2^28、XBLOCK=4096 → grid=65536），1D 启发式会生成携带 auto_blockify_size∈{2,4,8} 的 autotune 候选；该值被当作 kernel constexpr 传入编译常量，而 kernel 签名中没有这个参数，ast_to_ttir 解析常量键名时直接抛 ValueError。该异常不在 autotuner 的可跳过编译失败白名单内，单个坏候选即导致整个 warmup 失败、模型不可用。

最小复现：

import torch
import torch_npu  # noqa: F401

def five_load_add(a, b, c, d, e):
    return a + b + c + d + e

n = 2 ** 28  # 5 个 fp32 load，UB 预算封顶 XBLOCK=4096 → grid=65536 > 65535
xs = [torch.randn(n, dtype=torch.float32, device="npu") for _ in range(5)]
compiled = torch.compile(five_load_add, options={"npu_backend": "triton_experimental"})
out = compiled(*xs)  # warmup 即崩

模型级触发（更常见入口）：timm benchmark 的 mobilevit_s（bs=128，崩溃 kernel triton_unk_fused__native_batch_norm_legit_no_training_convolution_silu_3，size_hints x=2^28）与 mobilenetv3_large_100（bs=512，..._relu_3，x=411041792）等大 batch/大特征图模型。

实际行为（关键报错栈）：

ValueError: 'auto_blockify_size' is not in list

  File ".../torch_npu/_inductor/triton_experimental/npu_triton_heuristics.py", line 991, in _precompile_config
    binary = triton.compile(*compile_args, **compile_kwargs)
  File ".../triton/compiler/compiler.py", line 282, in compile
    module = src.make_ir(options, codegen_fns, module_map, context)
  File ".../triton/compiler/code_generator.py", line 1357, in <lambda>
    cst_key = lambda i: fn.arg_names.index(i) if isinstance(i, str) else i

期望行为：auto_blockify_size 作为 triton-ascend 编译选项（NPUOptions.auto_blockify_size，配合 TRITON_ALL_BLOCKS_PARALLEL 的 >65535 grid 折叠机制调优最左维分块粒度）应经 triton.compile 的 options 通道送达后端，kernel 正常编译并可参与 autotune 竞速，模型得到 compiled 结果。

根因分析（供维护者参考）：torch_npu 前端在 npu_triton_config 中将 auto_blockify_size 写入 Config.kwargs；_precompile_config 将全部 cfg kwargs 灌入 compile_meta["constants"] 并传入 ASTSource，而 triton-ascend 侧将其定义为编译选项（options 通道），kernel 签名不含该参数 → 常量键名经 fn.arg_names.index() 解析必失败。修复方向：值改经 Config.extra_options（上游为第三方后端预留的官方槽位，AutotuneCache 原生序列化/恢复）注入，编译时转发进 options dict。

欢迎加入社区，感谢您对社区的贡献 🎉!