aclnnAddRmsNormQuantV2 在 gamma 秩为 2 且第 0 维 > 1 时必定失败，报找不到 binary：
aclnnAddRmsNormQuantV2
Execution_Error(EZ1009): Cannot find binary for op AddRmsNormQuantV2 launch failed for AddRmsNormQuantV2, errno:561000
bf16 路径表现为 device error type 3, error code is 507035——同一根因的另一种表现。
device error type 3, error code is 507035
根因在 norm/add_rms_norm_quant_v2/op_host/op_api/aclnn_add_rms_norm_quant_v2.cpp 的 SelfPreDealData()：
norm/add_rms_norm_quant_v2/op_host/op_api/aclnn_add_rms_norm_quant_v2.cpp
SelfPreDealData()
if (inputTensor.gamma->GetViewShape().GetDimNum() == DIM_TWO) { auto gammaReshape = l0op::Reshape(inputTensor.gamma, {inputTensor.gamma->GetViewShape()[1]}, executor); inputTensor.gamma = gammaReshape; // 无 CHECK_RET }
三个问题：
(7,15)
shape[0] == 1
CHECK_RET
l0op::Reshape
nullptr
gamma
betaOptional
DIM_TWO
gamma / beta 被置空后，GenSimplifiedKey 生成的 key 退化：
GenSimplifiedKey
应为: 1/1/1/0/0/3/3/ 1/2/ 实为: 1/1/0/0/0/3/3/-1/2/ ← gamma dtype 变 0、beta 变 -1「不存在」
416 条 binary 无一匹配。
触发条件：走到 aclnnAddRmsNormQuantV2 入口，且 gamma 秩恰好为 2、shape[0] != 1。判断只读 gamma，与 x1 完全无关——实测 x1 秩 2 到 6 均可复现。beta 那段是同样的错误，实践中 beta 与 gamma 同形，总是一起中招。
shape[0] != 1
从 torch_npu 调用时，op-plugin 在 950 上按 beta 是否存在分流，有 beta 才进 V2；直接调 aclnnAddRmsNormQuantV2（例如 TTK aclnn 模式）则无论有无 beta 都会命中。
Ascend950PR_9599
931af11c9
AddRmsNormQuantKernelOpApi.cpp
该缺陷由 2f541bc3e 代码同步（2025-12-21）引入，非 9.2.0 回退。
2f541bc3e 代码同步
最小复现（fp16，x1 与 gamma 同形 (8,15)）：
(8,15)
import torch, torch_npu x1 = torch.rand(8, 15, dtype=torch.float16).npu() x2 = torch.rand(8, 15, dtype=torch.float16).npu() gamma = torch.rand(8, 15, dtype=torch.float16).npu() # 秩 2，首维 8 > 1 scales1 = torch.rand(8, 15).npu() zp1 = torch.zeros(8, 15, dtype=torch.int32).npu() beta = torch.rand(8, 15, dtype=torch.float16).npu() # 有 beta -> 走 V2 torch_npu.npu_add_rms_norm_quant(x1, x2, gamma, scales1, zp1, beta, None, None, axis=-1, epsilon=1e-5, div_mode=True)
把 gamma 换成 (15,) 或 (1,15) 或 (4,7,15) 均正常，只有秩 2 且首维 > 1 会失败。
(15,)
(1,15)
(4,7,15)
变量隔离结论（每个配置独立进程，避免 device 进错误态后返回脏 buffer）：
(2,15)
(7,16)
(7,32)
(16,64)
(64,128)
(7,1)
与 dtype、末维 32B 对齐、规模均无关。
x1
x1 (7,15)
(7,7)
x1 (8,7,7)
gamma (1,N)
x1 (M,N)
ACLNN_ERR_PARAM_INVALID
失败时（fp16）：
bf16：
plog 中 SimpleKeyTemp 与「Optional input beta exist」日志缺失，可直接佐证 gamma / beta 被置空。
SimpleKeyTemp
100 条 aclnn 用例实测（Ascend950PR，CANN 9.2.0，每条独立进程）：
ops-test-kit aclnn 模式独立复现同一批用例，失败集与上述 17 条完全重合。
已提 PR：https://gitcode.com/cann/ops-nn/merge_requests/8966
改法为删除整段 reshape，并把 V1 CheckParams 一直在用的 CheckShapeGammaX 补进 CheckParamsV2——V2 原先没有任何 gamma 与 x1 的 shape 校验，不合规输入正是靠那段 reshape 掩盖着。补上后报错变为：
CheckParams
CheckShapeGammaX
CheckParamsV2
AclNN_Parameter_Error(EZ1001): The gamma tensor's shape dim 0 is 1, is not equal to x1 8.
这是本 issue 更值得跟踪的部分。三层防线同时漏：
opapi UT：add_rms_norm_quant_v2/tests/ut/op_host/op_api/ 只有 2 条用例，gamma 均为一维 {64}，且两条里唯一的断言都被注释掉：
add_rms_norm_quant_v2/tests/ut/op_host/op_api/
{64}
aclnnStatus aclRet = ut.TestGetWorkspaceSize(&workspace_size); // EXPECT_EQ(aclRet, ACLNN_ERR_PARAM_INVALID);
连返回值都不检查。
ops-test-kit 用例集：该算子共 6 份 CSV、合计 2255 条，gamma 秩全部为 1，无一条二维：
aclnn/aclnn_add_rms_norm_quant.csv
aclnn/aclnn_add_rms_norm_quant_v2.csv
kernel/add_rms_norm_quant.csv
kernel/add_rms_norm_quant_v2.csv
kernel/add_rms_norm_quant_vl_boundary.csv
kernel/add_rms_norm_quant_v2_vl_boundary.csv
以 aclnn_add_rms_norm_quant_v2.csv 为例，x1 的秩扫得很开（{1:40, 2:365, 3:95}），gamma 的秩却被固定成常量 1。而本缺陷的触发条件只由 gamma 决定、与 x1 无关，所以 500 条跑下来一片绿。
aclnn_add_rms_norm_quant_v2.csv
{1:40, 2:365, 3:95}
值得一提的是 golden 专门为多维 gamma 写过，注释里还引了文档原文：
# 归约维由 gamma 的 shape 决定，不是固定的最后一维 —— aclnnAddRmsNormQuantV2 文档里 # gamma 的约束就是「shape 与 x1 需要 norm 的维度保持一致」。 reduce_axes = tuple(range(x_fp32.ndim - gamma.ndim, x_fp32.ndim))
能力具备，但没有任何用例走进这个分支。
算子仓 ST：add_rms_norm_quant_v2/tests/ 下没有 st/ 目录，一条 ST 用例都没有（V1 有 54 条）。
add_rms_norm_quant_v2/tests/
st/
建议补齐：在 aclnn_add_rms_norm_quant_v2.csv 增加 gamma 秩 2 / 3、首维 > 1 的用例（golden 侧无需改动），并给 V2 补 opapi 参数校验 UT（含负例，断言不要注释掉）。
CheckSupportV2() 中 legacy 平台（910B / 910_93 / 310P）的 isGammaOk 仍显式白名单 gamma (1,N)，与文档约束以及 V1 在同一平台上的 CheckParams 都不一致。补上 CheckShapeGammaX 后该分支即使命中也会被参数校验拒绝，行为与走 V1 一致，不构成新的失败模式；但该路由分支的清理需要 910B 实机验证，未在 PR !8966 中一并处理。
CheckSupportV2()
isGammaOk
Describe the current behavior / 问题描述
aclnnAddRmsNormQuantV2在 gamma 秩为 2 且第 0 维 > 1 时必定失败，报找不到 binary：bf16 路径表现为
device error type 3, error code is 507035——同一根因的另一种表现。根因在
norm/add_rms_norm_quant_v2/op_host/op_api/aclnn_add_rms_norm_quant_v2.cpp的SelfPreDealData()：if (inputTensor.gamma->GetViewShape().GetDimNum() == DIM_TWO) { auto gammaReshape = l0op::Reshape(inputTensor.gamma, {inputTensor.gamma->GetViewShape()[1]}, executor); inputTensor.gamma = gammaReshape; // 无 CHECK_RET }三个问题：
(7,15)有 105 个元素，却要 reshape 成 15 个。reshape 前后元素数相等当且仅当shape[0] == 1，所以只有前导 1 的形态碰巧等价。CHECK_RET。l0op::Reshape失败返回nullptr，被直接赋回gamma/betaOptional，错误被完全吞掉。DIM_TWO。 秩 3 及以上不进此分支却一直工作正常，反证算子原生支持多维 gamma，这段 reshape 本身多余。gamma / beta 被置空后，
GenSimplifiedKey生成的 key 退化：416 条 binary 无一匹配。
触发条件：走到
aclnnAddRmsNormQuantV2入口，且 gamma 秩恰好为 2、shape[0] != 1。判断只读 gamma，与 x1 完全无关——实测 x1 秩 2 到 6 均可复现。beta 那段是同样的错误，实践中 beta 与 gamma 同形，总是一起中招。从 torch_npu 调用时，op-plugin 在 950 上按 beta 是否存在分流，有 beta 才进 V2；直接调
aclnnAddRmsNormQuantV2（例如 TTK aclnn 模式）则无论有无 beta 都会命中。Environment / 环境信息
Ascend950PR_9599，arch35 regbase）931af11c9）AddRmsNormQuantKernelOpApi.cpp），以及 ops-test-kit aclnn 模式直调该缺陷由
2f541bc3e 代码同步（2025-12-21）引入，非 9.2.0 回退。Steps to reproduce the issue / 重现步骤
最小复现（fp16，x1 与 gamma 同形
(8,15)）：import torch, torch_npu x1 = torch.rand(8, 15, dtype=torch.float16).npu() x2 = torch.rand(8, 15, dtype=torch.float16).npu() gamma = torch.rand(8, 15, dtype=torch.float16).npu() # 秩 2，首维 8 > 1 scales1 = torch.rand(8, 15).npu() zp1 = torch.zeros(8, 15, dtype=torch.int32).npu() beta = torch.rand(8, 15, dtype=torch.float16).npu() # 有 beta -> 走 V2 torch_npu.npu_add_rms_norm_quant(x1, x2, gamma, scales1, zp1, beta, None, None, axis=-1, epsilon=1e-5, div_mode=True)把
gamma换成(15,)或(1,15)或(4,7,15)均正常，只有秩 2 且首维 > 1 会失败。变量隔离结论（每个配置独立进程，避免 device 进错误态后返回脏 buffer）：
(15,)(1,15)(2,15)(7,15)(7,16)(7,32)(16,64)(64,128)(7,1)(7,15)(4,7,15)/ 秩 4 / 秩 5与 dtype、末维 32B 对齐、规模均无关。
Describe the expected behavior / 预期结果
x1需要 norm（层归一化）的维度保持一致」，(7,15)配x1 (7,15)、(7,7)配x1 (8,7,7)都是合规输入。gamma (1,N)配x1 (M,N)）应在 aclnn 参数校验层返回ACLNN_ERR_PARAM_INVALID并给出可读文案，而不是掉到 binary 匹配或 tiling 才失败。Related log / screenshot / 日志 / 截图
失败时（fp16）：
bf16：
plog 中
SimpleKeyTemp与「Optional input beta exist」日志缺失，可直接佐证 gamma / beta 被置空。100 条 aclnn 用例实测（Ascend950PR，CANN 9.2.0，每条独立进程）：
ops-test-kit aclnn 模式独立复现同一批用例，失败集与上述 17 条完全重合。
Special notes for this issue / 备注
修复
已提 PR：https://gitcode.com/cann/ops-nn/merge_requests/8966
改法为删除整段 reshape，并把 V1
CheckParams一直在用的CheckShapeGammaX补进CheckParamsV2——V2 原先没有任何 gamma 与 x1 的 shape 校验，不合规输入正是靠那段 reshape 掩盖着。补上后报错变为：为什么长期没被发现：测试资产在 gamma 秩上完全没有覆盖
这是本 issue 更值得跟踪的部分。三层防线同时漏：
opapi UT：
add_rms_norm_quant_v2/tests/ut/op_host/op_api/只有 2 条用例，gamma 均为一维{64}，且两条里唯一的断言都被注释掉：aclnnStatus aclRet = ut.TestGetWorkspaceSize(&workspace_size); // EXPECT_EQ(aclRet, ACLNN_ERR_PARAM_INVALID);连返回值都不检查。
ops-test-kit 用例集：该算子共 6 份 CSV、合计 2255 条，gamma 秩全部为 1，无一条二维：
aclnn/aclnn_add_rms_norm_quant.csvaclnn/aclnn_add_rms_norm_quant_v2.csvkernel/add_rms_norm_quant.csvkernel/add_rms_norm_quant_v2.csvkernel/add_rms_norm_quant_vl_boundary.csvkernel/add_rms_norm_quant_v2_vl_boundary.csv以
aclnn_add_rms_norm_quant_v2.csv为例，x1 的秩扫得很开（{1:40, 2:365, 3:95}），gamma 的秩却被固定成常量 1。而本缺陷的触发条件只由 gamma 决定、与 x1 无关，所以 500 条跑下来一片绿。值得一提的是 golden 专门为多维 gamma 写过，注释里还引了文档原文：
# 归约维由 gamma 的 shape 决定，不是固定的最后一维 —— aclnnAddRmsNormQuantV2 文档里 # gamma 的约束就是「shape 与 x1 需要 norm 的维度保持一致」。 reduce_axes = tuple(range(x_fp32.ndim - gamma.ndim, x_fp32.ndim))能力具备，但没有任何用例走进这个分支。
算子仓 ST：
add_rms_norm_quant_v2/tests/下没有st/目录，一条 ST 用例都没有（V1 有 54 条）。建议补齐：在
aclnn_add_rms_norm_quant_v2.csv增加 gamma 秩 2 / 3、首维 > 1 的用例（golden 侧无需改动），并给 V2 补 opapi 参数校验 UT（含负例，断言不要注释掉）。遗留观察
CheckSupportV2()中 legacy 平台（910B / 910_93 / 310P）的isGammaOk仍显式白名单gamma (1,N)，与文档约束以及 V1 在同一平台上的CheckParams都不一致。补上CheckShapeGammaX后该分支即使命中也会被参数校验拒绝，行为与走 V1 一致，不构成新的失败模式；但该路由分支的清理需要 910B 实机验证，未在 PR !8966 中一并处理。