问题描述

对官方 quantize_add_layer_norm 的 Ascend950/arch35 实现，使用已有 TSE 黑盒和 STDesign 用例及冻结 Golden 回归。1218 条实际设备数值比较中，936 条通过、282 条按该参考未通过。附全部 282 条失败定义、逐例指标、原样 Golden，以及代表例原始输入和设备输出。

本 issue 汇总的是实测比较差异，不将 282 条记录等同于 282 个独立 kernel 缺陷。 用例跨集合存在重复场景；部分参考语义仍需确认。建议优先复现下述 13 条多行 Full-load 大偏差，特别是普通有限值域的 5 条黑盒用例。

分套结果

所有 TSE L1/L2 都已实际执行，包括此前未执行的 305 条。其余 host 拒绝、Golden 不适用/拒绝、资源未执行和异常用例检查不计入上述 282 条。

282 条中：262 条仅 y 失败、14 条仅 x 失败、6 条二者均失败。y 为 INT8 量化输出，x 为启用 additional_output 时的残差相加输出。

A. 多行 Full-load 大偏差：13 条，根因待定位

13 条均走 key=8012 的多行 Full-load 路径；y 最大绝对差为 128～255。以下 5 条来自普通有限值域黑盒，epsilon 均为 1e-5：

完整 ID 为 quantize_add_layer_norm_bb_l2_<后缀>。另 8 条为 QuantizeAddLayerNorm_L0_049/070、QuantizeAddLayerNorm_L1_300/404/563/567/631/661，涉及极值输入、小或负 scale、极小/极大 epsilon 等组合，完整配置见附件 CSV。

共同路径/输入条件是观察结果，尚未证明为共同根因。不能用下述四例的量化前 dtype 回转解释直接覆盖这 13 条。

B. y 相差 ±1：255 条

另有 255 条的 y 最大绝对差为 1，涉及 FP16/BF16 和部分 FP32。按原标签，黑盒 L2 的 239 条失败分为：

已对 L2_520/524（FP16）和 L2_760/764（BF16）做固定输入 CPU 诊断：保持同一 F.layer_norm 和其它计算，仅在诊断参考中省去 norm.to(input_dtype).float()，四条设备输出与诊断结果逐元素相等，原 1/3/10/19 个差异全部得到解释。这与上游 Welford 直接在 FP32 仿射结果上 Div/加 offset/量化的源码一致。

这仅解释已诊断的四条，正式验收仍使用原 Golden，四条仍记失败。诊断参考没有用于替换 Golden。

C. x 比较失败：20 条

18 条 FP32、2 条 FP16；其中 6 条同时有 y 问题，故不能与 A/B 直接相加。

• FP32 代表例 TSE L1_169、L2_289、L2_304：设备 x 逐位等于 (x2+bias)+x1，冻结 Golden 为 (x1+x2)+bias；Full-load/Welford 共用的残差加载函数采用前一种顺序。
• 参考限制：这三例保存的 Promote 虽为 float64，内部仍强制 FP32 求和，其值等于 Normal 转 float64；ThirdParty 又与 Normal 同源。原 TTK CrossCheck 失败可以精确复现，但不能据此断言所有 x 差异均为上游数学精度缺陷。需要确认接口契约及参考精度规则。
• FP16 的 STDesign L1_250/L1_404 含 65504 等极值，比较器报告 NaN/Inf mismatch，尚未做完整归因。

环境信息

• 仓库与测试提交：cann/ops-nn@1c3b061e2380c3eb73e7c6e601c4d17317fc6de0
• 算子：norm/quantize_add_layer_norm/op_kernel/arch35
• 硬件：Ascend950PR；编译 SoC：Ascend950PR_9599。
• CANN：9.2.0；Python：3.12.9；Torch：2.7.1+cpu；NumPy：1.26.4；ml_dtypes：0.5.4。
• 实际路径：本轮从该提交新编译的真实 host + FP16/BF16/FP32 × 有/无 zero_points 六组 ELF，经 TTK 公共 RTSInterface 直载。使用真实 host 返回的 tiling/key/block/workspace，regbase tiling ABI 88B。
• 上游源码、原用例、Golden、容差全程冻结；1218 条设备结果的来源、输入/参考/输出哈希和缓冲区尾部哨兵均已核验，未观测到设备崩溃或哨兵破坏。
• 原生整包流程在第三方 protobuf 下载时中断，因此本轮没有验收完整 OPP 安装链路、TTK bin/dyn/cst 三阶段和 ACLNN 错误码。37 条超大用例受执行容器 32GiB RAM 硬限未上板，不据此判定产品不支持。

重现步骤

1. 检出上述固定提交，准备 Ascend950PR/CANN 9.2.0，并编译 quantize_add_layer_norm 的 arch35 host/kernel。
2. 下载附件主包与代表数据包并解压，先按包内 README 校验 SHA256。主包包含四套失败 CSV 的原始字段、282 条结果摘要和原样 golden.py。
3. 优先使用代表数据包的 TSE L2_903、L2_941 固定输入复现 Full-load 大偏差；使用 L2_520、L2_760 检查量化前 dtype 差异；使用 L1_169 检查 x 求和顺序。固定输入应直接读取，不能以重新采样替代同一输入的复现。
4. 输入顺序为 x1、x2、gamma、beta、bias、scales、zero_points（可缺省）；输出为 y、x。按每例 metadata/CSV 的 dtype、shape、属性调用该提交实现。
5. y 按 INT8 逐元素严格相等比较；additional_output=true 时，x 使用现行 TTK CrossCheck L1。包内 CPU 工具/说明用于核对保存输出和冻结参考，不宣称其执行了 NPU。
6. 比较输出与附件保存的结果。仅有 CSV 的其它失败例可按原值域生成后回归；历史固定输入与新采样输入的结果不能混为同一次复现。

预期结果与请求确认

• 请优先复现/定位 13 条 Full-load 多行大偏差，尤其普通有限输入的 L2_903/918/919/941/944。
• 请确认量化前是否应回转 FP16/BF16，以及残差加法顺序的兼容性要求；依明确契约确定实现修复和参考修正边界。
• 请核对 Promote/ThirdParty 的适用性；当前报告保留原标准结果，不放宽容差、不把未定位案例自动归因或改判通过。

日志、结果与附件

1. 282 条失败用例、逐例结果、当前 Golden 与诊断报告（ZIP），127,821 字节。
   SHA256：d3f75f0f0ed00fdc5d1e76297aaa9db9f98ac82321cc0261561fa4aa3d5cf802
2. 5 条代表用例的原始输入、设备输出、冻结参考与 CPU 复核脚本（ZIP），13,393,844 字节（约 12.77 MiB）。
   SHA256：b0dac4781e7a7fb6b27094c9590f8eb4f93005d314fe170d0bb783550fe16e2d

两个包都包含原样 golden.py。代表包中运行 python3 verify_saved_outputs.py 可核对保存证据；加 --recompute-golden 可用冻结 Golden 重算。我们已在 Torch 2.7.1+cpu 下确认五例重算 Normal 与保存参考逐位一致；这不改变原精度失败判定，也不表示重放了正式 x CrossCheck。

当前 Golden：附件中的 golden.py 是本轮原样冻结文件，SHA256：

9d7307dd73553798c05e88eff96f9263820f8c2b7d0765c462a6edf627ddd592

其计算使用 Torch F.layer_norm，残差为 (x1.float()+x2.float())+bias.float()；FP16/BF16 量化前回转原 dtype，再除 scale、加 zero_points、最近偶数舍入并 clamp 到 INT8。主包 README 和两份诊断报告说明其适用范围与 Promote 内部 FP32 的限制。

相关需求：quantize_add_layer_norm 增加 Ascend 950 支持 #4496。本 issue 针对上述固定提交的实际回归结果。