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-25"

Add 算子测试报告

测试环境：真实 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，甚至是混合精度（如 FP16+FP32）。对于不在 AiCore 支持列表中的类型（如 INT16 和 DOUBLE），框架会通过算子选择逻辑回退（Fallback）到 AiCpu 执行。

精度与固有特性关注点： 由于 Add 属于逐元素操作，不存在长序列的累加漂移问题，但浮点运算的固有截断依然会深刻影响计算结果，主要表现为：

1. 大数吃小数（Swamping）：当x1的量级远大于x2时（如1e10 + 1e-5），小数部分会因为超出浮点数的有效尾数位数而被彻底抛弃。
2. 灾难性相消（Catastrophic Cancellation）：当两个大小相近但符号相反的浮点数相加时，结果的有效数字会骤减，导致巨大的相对误差。
3. Alpha 缩放导致的量化误差：由于算子内部执行alpha * x2，如果传入的alpha（例如1/3）在浮点中无法精确表示，会凭空引入一层量化误差。
4. 整数溢出（Overflow）：如INT32类型极值相加（2^30 + 2^30），算子通常不做饱和截断，而是按底层二进制补码直接回绕（Wrap）。

二、测试策略与用例设计

本次在test_aclnn_add.cpp中设计了极其详尽的端到端测试用例，总计覆盖了 130 个测试场景（TC-01 ~ TC-130），核心策略分为以下五个维度：

第一部分是API 全矩阵覆盖。分别针对 6 大 API（Add,Adds,InplaceAdd,InplaceAdds,AddV3,InplaceAddV3）进行了基础功能测试，确保核心计算逻辑在不同接口下表现一致。

第二部分是Dtype 与 Tiling 路由白盒覆盖。这是算子分发逻辑的重头戏，测试深入挖掘了各种条件下的 Tiling 分支：

• 常规分支：构造数据触发AddWithCastCompute（带类型转换）、AddWithoutCastCompute、AddBoolCompute等。
• Axpy / AxpyV2 硬件加速路径：当alpha != 1时，专门构造 FP32/FP16/BF16 数据触发Axpy路径，构造 INT 类数据触发AxpyV2路径。若硬件不支持，则触发Mul+Add备用路径。
• 混合精度与转换：测试isKeepB16的真假分支，以及AddMixDtypeCompute<half, float>等不同精度张量相加。

第三部分是Shape 与 Broadcasting。验证了标量与张量相加，以及大尺寸张量（如 64×64）计算。考虑到真机运行环境的稳定性，对部分极易导致系统 Hang 死的底层广播及 AiCpu 边界用例进行了[SKIP]标记屏蔽（如 TC-17, TC-36, TC-37 等），保证整个测试框架流程的安全与稳定。

第四部分是异常路径与边界扫描（Error Paths）。针对 API 鲁棒性进行了大规模的GetWorkspaceSize错误探测（TC-57 ~ TC-91），覆盖：空指针注入、超大维度（dim>8）、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 层）：

覆盖率分析与归因：

1. API 层行覆盖率极高（>92%）：得益于用例中设计了近 40 个专门针对异常拦截的GetWorkspaceSize用例（如Err_Add_null_self、Err_V3_dim_exceed_8等），成功将 API 顶层校验代码的防御分支“扫荡”完毕。
2. 算子架构分发层覆盖良好：在add_tiling_arch35.cpp达到了近 90% 的行覆盖率，说明代码中对Axpy、AxpyV2、MulAdd以及isKeepB16的精准数据构造成功切中了底层的不同汇编调度树。
3. 安全规避策略影响了底层分支：为了防止远程真机死机，用例故意[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 或 Mul+Add 计算链路上没有额外的精度掉失。

场景四：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与常规数值混合计算。
• 实测输出与分析：NaN（Not 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 执行单元的隔离性与相应的精度标称特性。

五、反思与改进

1. 利用 GetWorkspaceSize 实现安全的白盒覆盖： 本次测试最大的亮点是：在测试框架容易因异常数据（如 AiCpu 缺失、非法 Shape 等）挂死崩溃的真机环境下，大量运用了GetWorkspaceSize作为哨兵探针（如 TC-92 到 TC-130）。许多异常校验逻辑（Null 检查、PromoteType 类型提升检查）无需执行真实算力（Exec）即可遍历，这是一种极高性价比的防崩溃分支提升手段。
2. 多态架构的黑盒之痛： 在编写针对Axpy和AxpyV2的触发用例时，发现 CANN 算子对哪些 Dtype 支持加速（如ARCH_REGBASE_AXPY_DTYPE_SUPPORT_LIST）存在强架构依赖。我们只能通过泛型枚举组合，尽可能让黑盒编译器去走这些分支。若有明确的算子内置宏手册，针对性构造数据会更加高效。
3. 平台兜底策略的取舍： 对于 INT16 和 DOUBLE 类型，由于当前版本的 AiCore 并不支持，强行调用Exec很容易导致真机任务调度挂起。后续若平台能完善AiCpuFallback 的进程隔离机制，可以解除用例中的[SKIP]标记，对这部分平台短板进行更深度的功能与精度断言。

【免费下载链接】cann-competitions本仓库用于 CANN 开源社区各类竞赛、开源课题、社区任务等课题发布、开发者作品提交和展示。项目地址: https://gitcode.com/cann/cann-competitions