CANN竞赛仓Add算子测试报告

【免费下载链接】cann-competitions本仓库用于 CANN 开源社区各类竞赛、开源课题、社区任务等课题发布、开发者作品提交和展示。项目地址: https://gitcode.com/cann/cann-competitions 元信息请如实填写此区块将由组委会脚本自动解析请保持字段名不变team_name: 哈基米555 team_members:庞浩民-广州大学兰晨阳-广州大学罗景辉-广州大学 operator_name: Add operator_library: cann-ops-math report_date: 2026-04-25Add 算子测试报告测试环境真实 Ascend 910_93 NPU (真机)CANN 工具链版本 9.0.0-beta.2。不同型号与固件版本下的实测数值可能存在差异提交时请如实记录测试环境。一、算子理解Add 算子执行两个张量之间或张量与标量之间的逐元素加法操作。在 CANN 架构中Add 算子的数学定义不仅仅是x1 x2而是包含了一个缩放因子alpha即out[i] x1[i] alpha * x2[i]。CANN 提供了 6 个主要的 API 来覆盖不同的应用场景aclnnAdd、aclnnAdds张量加标量、aclnnInplaceAdd、aclnnInplaceAdds以及新版的aclnnAddV3和aclnnInplaceAddV3。在数据类型方面Add 算子在 AiCore 上支持极其广泛的类型包括 FP32、FP16、BF16、INT32、INT64、INT8、UINT8、BOOL甚至是混合精度如 FP16FP32。对于不在 AiCore 支持列表中的类型如 INT16 和 DOUBLE框架会通过算子选择逻辑回退Fallback到 AiCpu 执行。精度与固有特性关注点 由于 Add 属于逐元素操作不存在长序列的累加漂移问题但浮点运算的固有截断依然会深刻影响计算结果主要表现为大数吃小数Swamping当x1的量级远大于x2时如1e10 1e-5小数部分会因为超出浮点数的有效尾数位数而被彻底抛弃。灾难性相消Catastrophic Cancellation当两个大小相近但符号相反的浮点数相加时结果的有效数字会骤减导致巨大的相对误差。Alpha 缩放导致的量化误差由于算子内部执行alpha * x2如果传入的alpha例如1/3在浮点中无法精确表示会凭空引入一层量化误差。整数溢出Overflow如INT32类型极值相加2^30 2^30算子通常不做饱和截断而是按底层二进制补码直接回绕Wrap。二、测试策略与用例设计本次在test_aclnn_add.cpp中设计了极其详尽的端到端测试用例总计覆盖了 130 个测试场景TC-01 ~ TC-130核心策略分为以下五个维度第一部分是API 全矩阵覆盖。分别针对 6 大 APIAdd,Adds,InplaceAdd,InplaceAdds,AddV3,InplaceAddV3进行了基础功能测试确保核心计算逻辑在不同接口下表现一致。第二部分是Dtype 与 Tiling 路由白盒覆盖。这是算子分发逻辑的重头戏测试深入挖掘了各种条件下的 Tiling 分支常规分支构造数据触发AddWithCastCompute带类型转换、AddWithoutCastCompute、AddBoolCompute等。Axpy / AxpyV2 硬件加速路径当alpha ! 1时专门构造 FP32/FP16/BF16 数据触发Axpy路径构造 INT 类数据触发AxpyV2路径。若硬件不支持则触发MulAdd备用路径。混合精度与转换测试isKeepB16的真假分支以及AddMixDtypeComputehalf, float等不同精度张量相加。第三部分是Shape 与 Broadcasting。验证了标量与张量相加以及大尺寸张量如 64×64计算。考虑到真机运行环境的稳定性对部分极易导致系统 Hang 死的底层广播及 AiCpu 边界用例进行了[SKIP]标记屏蔽如 TC-17, TC-36, TC-37 等保证整个测试框架流程的安全与稳定。第四部分是异常路径与边界扫描Error Paths。针对 API 鲁棒性进行了大规模的GetWorkspaceSize错误探测TC-57 ~ TC-91覆盖空指针注入、超大维度dim8、Shape 不匹配、不支持的 Cast如 Float 转 Bool、不支持的 Alpha 类型如 Double 标量用于 Int32 输出。这极大拉升了 API 层面的分支覆盖率。第五部分是精度风险深度评估。通过特制的极限数据如1e10 1e-5、NaN 1.0、Inf、INT32 溢出验证算子在边界数值下的表现是否符合 C 标准或 IEEE-754 规范。为了防止 CPU 宿主精度的干扰Oracle 采用了double并实现了高保真的FloatToFP16/BF16模拟。三、覆盖率分析实机运行端到端测试用例后提取到的目标文件 P3 阶段覆盖率如下包含核心 API、分发器及 Tiling 层文件代码行数行覆盖率分支覆盖率说明op_api/aclnn_add_v3.cpp7792.21% (71 行)63.38% (270/426)API 层负责 V3 接口的 Workspace 获取、前端参数强校验及调度op_api/aclnn_add.cpp30369.31% (210 行)47.41% (733/1546)路由层负责 CheckPromoteType 判断、Dtype 提升与 API 分发op_api/add.cpp5955.93% (33 行)23.48% (62/264)平台层处理内存分配、基础 AiCore/AiCpu 执行器的兜底分发op_host/arch35/add_tiling_arch35.cpp9389.25% (83 行)57.29% (110/192)Tiling 层架构相关的底层块切分策略及硬件指令路由覆盖率分析与归因API 层行覆盖率极高92%得益于用例中设计了近 40 个专门针对异常拦截的GetWorkspaceSize用例如Err_Add_null_self、Err_V3_dim_exceed_8等成功将 API 顶层校验代码的防御分支“扫荡”完毕。算子架构分发层覆盖良好在add_tiling_arch35.cpp达到了近 90% 的行覆盖率说明代码中对Axpy、AxpyV2、MulAdd以及isKeepB16的精准数据构造成功切中了底层的不同汇编调度树。安全规避策略影响了底层分支为了防止远程真机死机用例故意[SKIP]了部分 AiCpu 强制下发测试如 Double/Int16 的Exec阶段仅调用GetWorkspaceSize作为探针以及部分极端 Broadcast。由于没有发生实际的内存下发部分异常返回处理逻辑未能被执行这也是add.cpp覆盖率偏低的直接原因。四、精度分析基于测试代码中的精度专项TC-27 ~ TC-33本文重点剖析 Add 算子在浮点与整数边缘特征下的精度表现与特性。参考基准均采用 CPU 的double运算与无符号整型回绕运算进行绝对基准对齐场景一大数吃小数吸收效应测试输入 (TC-27)FP32 下1e10 1e-5。实测输出与分析在 FP32 中1e10对应的 ULP (Unit in the Last Place) 大约是1024。因此加入1e-5就像往海里滴水结果的有效位完全无法表达这个增量。实测输出与理论真值的误差极大大于1e-4。这不是 CANN 的 Bug而是浮点精度的硬件极限表现测试给出了预期内的[PASS]判定。场景二灾难性相消Catastrophic Cancellation测试输入 (TC-28)FP32 下1.0000001 (-1.0)。实测输出与分析两个极为相近的数值相减会导致前导有效位全部抵消剩余的小数部分被放大。在此测试中计算结果完美对齐了经量化后输入的 CPUdouble参考值误差小于1e-6说明 NPU 加法在局部精度的保持上非常稳健。场景三Alpha 标量的量化折损测试输入 (TC-29)X (1/3) * Y。实测输出与分析1/3在二进制中是无限循环小数。我们将已带有浮点量化误差的float av 1.0f / 3.0f作为 alpha 传入。测试验证 NPU 计算是否引入了额外的截断。结果表明实测值与使用同等量化av运算的 CPU reference 对比满足极小容差1e-6证明了底层 Axpy 或 MulAdd 计算链路上没有额外的精度掉失。场景四Inf 上溢处理Overflow测试输入 (TC-30)FP32 下3.4e38 3.4e38。实测输出与分析两个接近 FP32 表示极限约3.4e38的数值相加其理论和远超单精度浮点的最大范围。NPU 正确触发了上溢机制将结果映射为inf正无穷。代码通过std::isinf验证通过行为严格符合 IEEE-754 标准对浮点数溢出的规范。场景五NaN 传染性传播测试输入 (TC-31)FP32 下NaN 1.0与常规数值混合计算。实测输出与分析NaNNot a Number在浮点运算中具有强传染性。测试验证了当向量的某一维度混入NaN时NPU 能够正确输出NaN且同一张量内的其他维度如1.0 2.0依然能正确输出3.0。这验证了算子对特殊浮点状态Special Floats处理的隔离性与可靠性。场景六INT32 边界上溢测试输入 (TC-32)INT32 下2^30 2^30。实测输出与分析2^30 2^30 2^{31}恰好超出了 INT32 最大正数表示范围2^{31}-1。CANN 算子对整数运算默认不做饱和钳位Clamp结果直接发生符号位溢出。底层的计算结果完全等同于 C 中无符号整型相加后再强制转换为有符号整型的“二进制补码低位截断”机制。场景七FP16 与 FP32 精度层级对比测试输入 (TC-33)相同的无限循环小数输入如1.234567等分别下发 FP16 和 FP32 计算。实测输出与分析对比两种精度的输出FP16 由于仅有 10 位尾数在对初始字面量进行FloatToFP16编码时即发生了严重的阶段损失。其实际运算误差相较于真值在1e-2量级而同等数据在 FP32 下误差保持在1e-5以内。验证了硬件不同 Dtype 执行单元的隔离性与相应的精度标称特性。五、反思与改进利用 GetWorkspaceSize 实现安全的白盒覆盖 本次测试最大的亮点是在测试框架容易因异常数据如 AiCpu 缺失、非法 Shape 等挂死崩溃的真机环境下大量运用了GetWorkspaceSize作为哨兵探针如 TC-92 到 TC-130。许多异常校验逻辑Null 检查、PromoteType 类型提升检查无需执行真实算力Exec即可遍历这是一种极高性价比的防崩溃分支提升手段。多态架构的黑盒之痛 在编写针对Axpy和AxpyV2的触发用例时发现 CANN 算子对哪些 Dtype 支持加速如ARCH_REGBASE_AXPY_DTYPE_SUPPORT_LIST存在强架构依赖。我们只能通过泛型枚举组合尽可能让黑盒编译器去走这些分支。若有明确的算子内置宏手册针对性构造数据会更加高效。平台兜底策略的取舍 对于 INT16 和 DOUBLE 类型由于当前版本的 AiCore 并不支持强行调用Exec很容易导致真机任务调度挂起。后续若平台能完善AiCpuFallback 的进程隔离机制可以解除用例中的[SKIP]标记对这部分平台短板进行更深度的功能与精度断言。【免费下载链接】cann-competitions本仓库用于 CANN 开源社区各类竞赛、开源课题、社区任务等课题发布、开发者作品提交和展示。项目地址: https://gitcode.com/cann/cann-competitions创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考