问题描述

index 目录下两个 aclnn 接口中，仍存在与「SocVersion 判断重构为 NpuArch 判断」整改不一致的实现：同一文件内 dtype 支持列表的选择已改用 IsRegbase()/NpuArch 写法，而另一个平台判断仍在用旧的 SocVersion 区间写法，两者在 regbase 平台（NpuArch DAV_3510，覆盖 Ascend950 与 Ascend350）上的结论会相反。

缺陷代码（master，逐字引用）

1）index/scatter/op_api/aclnn_scatter_update.cpp:61-65

static inline bool CheckSocVersionIsSupportBf16(void)
{
return GetCurrentPlatformInfo().GetSocVersion() >= SocVersion::ASCEND910B &&
GetCurrentPlatformInfo().GetSocVersion() <= SocVersion::ASCEND910E;
}

同一文件 52-58 行已是 NpuArch 写法：

static inline const std::initializer_listop::DataType& GetDtypeSupportListBySocVersion()
{
if (Ops::NN::AclnnUtil::IsRegbase()) {
return ASCEND950_DTYPE_SUPPORT_LIST_DATA; // 含 DT_BF16
} else {
return DTYPE_SUPPORT_LIST_DATA;
}
}

调用点 82-88 行又用该返回值拒绝 BF16：

bool bf16flag = CheckSocVersionIsSupportBf16();
if (!bf16flag && data->GetDataType() == op::DataType::DT_BF16) { OP_LOGE(...); return false; }

即 dtype 列表按 regbase 放行 BF16，紧接着的 SOC 版本判断又可能把它拒掉。

2）index/inplace_scatter_add/op_host/op_api/aclnn_index_add.cpp:108-112

bool isAscend910BSocVersion = (GetCurrentPlatformInfo().GetSocVersion() >= SocVersion::ASCEND910B &&
GetCurrentPlatformInfo().GetSocVersion() <= SocVersion::ASCEND910E);
const std::initializer_listop::DataType dtypeSupportList = isAscend910BSocVersion ?
ASCEND910B_DTYPE_SUPPORT_LIST :
ASCEND910_DTYPE_SUPPORT_LIST;

该文件 50-53 行的 ASCEND910_DTYPE_SUPPORT_LIST 不含 DT_BF16，55-58 行的 ASCEND910B_DTYPE_SUPPORT_LIST 含 DT_BF16；而同一文件 78-79 行的 IsAICoreSupport 已用 IsRegbase() + ASCEND950_AICORE_DTYPE_SUPPORT_LIST（含 DT_BF16）。同一入口内两处判断结论相反。

仓库内整改先例

89ccabcb1（2026-09-23 合入，关联 issue #6165）「整改：CheckSocVersionIsSupportBf16Activation 由 SocVersion 判断改为 NpuArch 判断」改的正是同名函数（common/inc/op_api/level2_base_caculation_nn.h）：

• return GetCurrentPlatformInfo().GetSocVersion() >= SocVersion::ASCEND910B &&

•       GetCurrentPlatformInfo().GetSocVersion() <= SocVersion::ASCEND910E;
  

• return GetCurrentPlatformInfo().GetCurNpuArch() == NpuArch::DAV_2201 || Ops::NN::AclnnUtil::IsRegbase();

a84fd19a6「增加 ascend350 平台支持（25 个激活/量化算子）并重构 SocVersion 判断为 NpuArch」也说明该重构是系统性整改。上述两处属同一整改的漏改。

影响

ScatterUpdate/Scatter/InplaceIndexAdd 的二进制配置均已含 ascend350（scripts/kernel/binary_config/ascendc_config.json），index/scatter/op_host/config/ 下也已有 ascend350 目录；但这两个 aclnn 入口的 dtype 校验仍受旧区间判断支配——在区间判断不成立的平台上，regbase 分支声明支持的 BF16 会在入口被拒，同一次调用出现两种结论。

补充：UT 无法暴露该问题——tests/ut/op_api/stub/opdev/platform.h:19-33 中 ASCEND350 被插入在 ASCEND950 与 ASCEND910E 之间（520dad45e 引入），使旧区间判断在 UT 中恰好成立；真实平台的枚举顺序请以平台头文件为准。

建议修复

按 89ccabcb1 的改法统一：

1）aclnn_scatter_update.cpp:61-65

• return GetCurrentPlatformInfo().GetSocVersion() >= SocVersion::ASCEND910B &&

•       GetCurrentPlatformInfo().GetSocVersion() <= SocVersion::ASCEND910E;
  

• return GetCurrentPlatformInfo().GetCurNpuArch() == NpuArch::DAV_2201 || Ops::NN::AclnnUtil::IsRegbase();

2）aclnn_index_add.cpp:108-112：改为按 IsRegbase() 选择含 BF16 的 regbase dtype 表，或与同文件 78-79 行的 IsAICoreSupport 判断合一，避免同文件内两处结论不一致。