企业官网建设流程全解析

CANN ops-math 算子跨平台迁移实战指南：从 Atlas A2 到 Ascend 950 的架构适配与代码改造

【免费下载链接】ops-math本项目是CANN提供的数学类基础计算算子库，实现网络在NPU上加速计算。项目地址: https://gitcode.com/cann/ops-math

本文以 CANN ops-math 算子库的跨平台迁移为主题，系统对比 Atlas A2 与 Ascend 950 两代平台的硬件架构差异，梳理搬运单元、计算单元、存储单元的能力变更及其对算子实现的影响，并给出 Cube 矩阵类、Vector 向量类、Cube-Vector 融合类以及集合通信类算子的迁移样例与 FAQ 调优建议。读完本文，你将掌握按“计算单元 → 搬运通路 → 存储容量 → 同步语义”逐层对照的迁移方法论，并能在当前仓库中定位与 Ascend 950（arch35）相关的算子适配代码。

本指南核心介绍算子在多平台间迁移的适配要点与方案，以算子从 Atlas A2 系列迁移至 Ascend 950 系列为例，对比硬件架构差异项及所涉适配点，并提供相关算子适配样例。本仓库（cann/ops-math）中已能观察到面向新架构的分支组织方式，例如 math/abs/op_host 下的arch35/子目录、ascend350/与ascend950/配置目录，即按硬件代际划分 tiling 实现与算子描述配置，这与本指南的迁移思路一致。

一、硬件架构及规格参数对比

Atlas A2 系列硬件架构

Atlas A2 系列以 Cube（矩阵计算）、Vector（向量计算）、搬运算子（MTE）为核心单元，配合 L1/L0A/L0B/L0C/UB 多级片上存储构成经典的三流水架构，数据通路以 GM↔L1↔L0A/L0B、GM↔UB、L1→GM 等为主。

Ascend 950 系列硬件架构

Ascend 950 系列在保持 Cube/Vector/搬运单元体系的基础上，对数据通路做了重大调整：删除 L1→GM 直连、删除 GM→L0A/L0B 直连，同时新增 L1↔UB、L0C→UB、FIXP→UB 等 Cube-Vector 内部直连通路，并引入 SIMT 单元与集合通信加速器 CCU1.0，整体更强调片上融合与低时延协同。

代际规格参数对比

通常根据不同的应用场景、工艺或硬件配置划分为多个产品型号，各型号在性能、资源配置等方面可能存在一定差异。为便于说明与直接对比，本节选择代表性配置作为参数展示与差异解析对象，其他相关调整请以实际手册或官方发布为准。

关键解读：

• 核数与算力全面提升：Ascend 950 的 AICore 核数由 24 增至 32，Cube 支持 BF16/FP16/FP8/HIFP8/MXFP8/INT8/MXFP4 多精度，Vector FP16 算力由 23.5T 提升至 54T，为算子吞吐预留了更大空间；
• 片上缓存翻倍：Memory 容量由 64GB 提升至 128GB，配合后文提到的 L0C/UB 由 128KB/256KB 级别的调整，迁移时 tiling 策略必须重新审视；
• 带宽持平：Memory 带宽均为 1.6TB/s，说明性能提升主要来自计算单元与片上缓存重组，而非外部访存带宽扩展。

二、硬件能力变更引入适配点

下表按硬件单元汇总两代平台的关键能力差异及其典型影响范围，这是迁移时“逐项对照修改”的检查清单：

三、推荐迁移步骤

建议按下述四个步骤系统推进，每一步都聚焦“平台差异 → 代码影响点”的映射：

1. 确认计算单元与数据类型差异：确认算子涉及的计算单元（Cube/Vector）和对应单元支持的数据类型是否在平台间存在差异。重点检查 int4_t 用量化、4:2 稀疏依赖、Vector 掩码与对齐假设；
2. 确认搬运通路差异：确认涉及的数据搬运单元（ND->NZ、GM<->Lx、集合通信等）是否在平台间存在差异。逐条核对上表的“搬运单元”行，替换失效通路、重构流水；
3. 按硬件能力变更点逐项修改：按硬件能力变更点逐项对照修改（Vector架构、Cube支持数据类型、L1/L0/UB大小、CCU通信等）；
4. 参考迁移样例补齐分支逻辑：参考算子迁移样例调整/补齐 Atlas A2/Ascend 950 分支逻辑。在本仓库中，这一步通常体现为按架构拆分 tiling 实现与 kernel 头文件，例如 math/abs/op_host/arch35 提供abs_tiling_arch35.cpp的 arch35 tiling 实现，math/abs/op_host/config/ascend950 提供abs_binary.json与abs_simplified_key.ini的按代际配置。

四、算子迁移样例

Cube 矩阵计算类算子

Global Memory 同地址访问冲突优化

Ascend 950 硬件新增同地址请求并行处理特性，不需要在各种分核场景额外规避同地址访问冲突。迁移时可将 Atlas A2 上为“错位规避冲突”设计的分核策略简化为更规则的滑动窗口模板（如行组窗口+列向往返扫描），减少无效偏移与冗余地址变换。实践中建议先以功能等价为目标保留原 tile 尺寸，再逐步放开分核约束，结合 profiling 数据观察 MAC 利用率、MTE2 利用率、L2 命中率等关键指标，确认模板调整是否带来稳定收益。

Tile 尺寸大小调整

Atlas A2 上 L0C 大小为 128KB，Ascend 950 提升到 256KB，意味着单次可承载更大的累加结果块。迁移时可优先增大 Tile 块切分粒度或提高 K 方向单轮处理深度，以减少切块与切 K 轮次，降低循环控制和搬运开销。同时需要重新平衡 L1/L0/UB 容量预算，避免 L0C 放大后挤压 A/B/scale 缓冲导致流水断点。

Vector 向量计算类算子

SIMT

Ascend 950 系列新增了 SIMT 单元。SIMT 在处理非规整离散访问方面相比 SIMD 有较大优势，适合地址不连续、访存跨度变化大、分支路径不一致的场景（如 scatter/gather、索引重排、稀疏更新等）。

迁移时建议优先识别“访存主导”且“向量化效率低”的算子子流程：若原有 SIMD 实现存在大量掩码分支、无效 lane 占比高、或需要复杂地址拼装，可将该部分改写为 SIMT 路径，通常可降低控制开销并提升有效访存吞吐。

实践中需重点关注以下事项：一是线程任务切分要与数据稀疏性匹配，避免线程负载极不均衡；二是减少高频随机访存导致的流水空转，尽量在上游完成索引规整与分桶；三是将边界处理与主路径解耦，避免在热点循环中引入过多分支。建议在迁移后同时对比“纯 SIMD 实现”和“SIMD+SIMT 混合实现”，按数据分布选择最优策略，而非固定单一路径。

以 gather_v2 算子为例：SIMD 与 SIMT 实现对比

gather_v2 算子根据合轴后的尾轴为单位进行 gather，因此模板选择的依据是：尾轴 ≤ 2048 时走 SIMT 模板，尾轴 > 2048 时走 SIMD 模板。因为尾轴小时，需要离散访问多个不连续的小块地址，SIMT 效率高。以下对比两种实现的核心差异：

1. 编程模型差异

SIMD 实现采用传统的向量化编程模型，需显式管理 UB 缓冲区和流水队列：

// SIMD: 使用队列机制管理数据缓冲 TQueBind<QuePosition::VECIN, QuePosition::VECOUT, BUFFER_NUM> inQueue_; TBuf<QuePosition::VECCALC> indexBuf_; // SIMD: 逐行处理，显式搬运和同步 for (int64_t j = 0; j < rows; j++) { INDICES_T index = GetIndex(yIdx, indiceEndIdx); // 标量读取索引 int64_t xIndex = index * tilingData_->innerSize; DataCopyPad(xLocal[j * colsAlign], xGm[offset], dataCopyExtParams, dataCopyPadExtParams); // 批量连续数搬入 } inQueue_.EnQue<int8_t>(xLocal); // 入队等待输出

SIMT 采用线程级并行模型，每个线程独立处理元素：

// SIMT: 使用线程级并行，无需显式buffer管理 __simt_vf__ LAUNCH_BOUND(2048) void GatherSimt(...) { for (INDEX_SIZE_T index = Simt::GetThreadIdx(); index < currentCoreElements; index += Simt::GetThreadNum()) { // 线程跳跃式并行 // 每个线程独立计算单点索引并访问 INDEX_SIZE_T gatherI = Simt::UintDiv(yIndex, m0, shift0); INDICES_T indicesValue = indices[gatherI]; // 根据单点索引gatherI直接访问GM y[yIndex] = idxOutOfBound ? 0 : x[xIndex]; // 直接写回GM } }

2. 访存模式差异

3. 适用场景差异

SIMD 适合连续访问大块地址的场景，通过向量化指令高效处理连续数据；SIMT 适合离散访存，线程并行处理。

Regbase

Ascend 950 系列引入了 Regbase 编程范式，相比传统的 Membase（Vector API）编程，Regbase 更接近底层硬件的寄存器操作，提供更精细的向量化控制能力。

特点

• 使用AscendC::MicroAPI命名空间下的底层 API
• 直接操作寄存器RegTensor<T>而非显式管理 UB 缓冲队列
• 通过MaskReg实现灵活的元素级掩码控制

与 Membase 编程模型对比

代码示例

__simd_vf__ __aicore__ void GenIndexBuf(ubuf int32_t* helpAddr, int32_t colFactor) { // 声明寄存器张量 AscendC::MicroAPI::RegTensor<int32_t> v0; AscendC::MicroAPI::RegTensor<int32_t> v1; AscendC::MicroAPI::RegTensor<int32_t> vd1; AscendC::MicroAPI::RegTensor<int32_t> vd2; AscendC::MicroAPI::RegTensor<int32_t> vd3; // 创建全量掩码 AscendC::MicroAPI::MaskReg preg = AscendC::MicroAPI::CreateMask<int32_t, AscendC::MicroAPI::MaskPattern::ALL>(); // 标量复制到寄存器 AscendC::MicroAPI::Duplicate(v1, colFactor, preg); // 生成序列 [0, 1, 2, ...] AscendC::MicroAPI::Arange(v0, 0); // 向量运算 AscendC::MicroAPI::Div(vd1, v0, v1, preg); AscendC::MicroAPI::Mul(vd2, vd1, v1, preg); AscendC::MicroAPI::Sub(vd3, v0, vd2, preg); // 寄存器数据写回UB AscendC::MicroAPI::DataCopy(helpAddr, vd3, preg); }

// 动态掩码：处理尾部不完整数据 __simd_vf__ __aicore__ void GatherProcess(ubuf int8_t* curYAddr, uint16_t repeatTimes, uint16_t computeSize) { MicroAPI::RegTensor<int8_t> vregTemp; MicroAPI::MaskReg preg; for (uint16_t r = 0; r < repeatTimes; r++) { // 根据剩余元素数更新掩码 preg = MicroAPI::UpdateMask<int8_t>(sreg); // 创建地址偏移寄存器 MicroAPI::AddrReg offset = MicroAPI::CreateAddrReg<int8_t>(r, computeSize); MicroAPI::DataCopy(vregTemp, curXAddr, offset); // 带掩码的数据存储 MicroAPI::DataCopy(curYAddr, vregTemp, offset, preg); } }

// 数据聚合。各地址、循环次数和输出块步长由调用者根据实际切分及UB布局传入。 __simd_vf__ __aicore__ void GatherData( ubuf int32_t* curYAddr, ubuf int32_t* curXAddr, ubuf uint32_t* indicesAddr, uint16_t indicesLoopNum, uint16_t blockStride) { __VEC_SCOPE__ { MicroAPI::RegTensor<uint32_t> indicesReg; MicroAPI::RegTensor<int32_t> vd0; MicroAPI::MaskReg preg = MicroAPI::CreateMask<int32_t, MicroAPI::MaskPattern::ALL>(); for (uint16_t indices = 0; indices < indicesLoopNum; indices++) { // 加载索引（E2B分发模式：将标量广播到向量） MicroAPI::DataCopy<uint32_t, MicroAPI::LoadDist::DIST_E2B_B32>(indicesReg, indicesAddr); // 根据索引进行Gather数据聚合 MicroAPI::DataCopyGather(vd0, curXAddr, indicesReg, preg); // blockStride表示相邻输出数据块在UB中的步长，由调用者按输出布局传入 MicroAPI::StoreAlign<int32_t, MicroAPI::DataCopyMode::DATA_BLOCK_COPY>( curYAddr, vd0, blockStride, preg); } } }

关键 Regbase API 说明

分发模式（LoadDist）说明

迁移建议

1. 适合 Regbase 的场景：需要精细控制寄存器分配、复杂掩码逻辑、Gather/Scatter 访存模式；
2. 保留 Membase 的场景：简单的连续数据搬运和计算、双缓冲流水线；
3. 混合使用：可在同一算子中结合两种范式，用 Regbase 处理核心计算逻辑，用 Membase 管理数据搬运。

Cube-Vector 融合类算子

MTE 数据搬运路径变化

Ascend 950 新架构引入 UB2L1 与 L0C2UB 间的直连通路，实现矩阵计算数据的快速搬移，旨在简化 CV 融合算子开发并提升性能。

矩阵搬入

启用 UB 至 L1（UB2L1）直连通路，通过 DataCopy 接口，支持融合算子的向量计算结果直接搬入 L1。

矩阵搬出

启用 L0C 至 UB（L0C2UB）直连通路，通过 DataCopy 接口，支持融合算子的矩阵计算结果直接搬入 UB 进行后续向量计算。

对于切 K 或多阶段融合场景，可将“L0C 搬回 GM 再读回 UB”改为“L0C 直达 UB 累加/后处理”，降低 GM 往返带宽压力和时延。迁移时建议把中间结果归并、激活/量化前处理放到 UB 侧完成，并显式梳理 MTE1/MTE2/MTE3 与计算单元的事件同步顺序，确保跨单元流水连续，避免由于新增通路引入数据可见性或同步时序问题。关键接口定义可参考：

// 1.新增: 搬入接口增加UB2L1的Nd2Nz搬入，支持Src&Dst都是LocalTensor的形式 template <typename T> __aicore__ inline void DataCopy(const LocalTensor<T>& dst, const LocalTensor<T>& src, const Nd2NzParams& intriParams); // 2.新增: 搬出接口增加L0C2UB的搬出，支持直接从L0C搬出到UB，支持Src&Dst都是LocalTensor的形式 template <typename T, typename U, const FixpipeConfig& config = CFG_ROW_MAJOR> __aicore__ inline void Fixpipe(const LocalTensor<T>& dst, const LocalTensor<U>& src, const FixpipeParamsC310<config.format>& intriParams); template <CO2Layout format = CO2Layout::ROW_MAJOR> struct FixpipeParamsC310 { // ... uint8_t dualDstCtl = 0; }; // 3.能力增强: 核间同步接口新增模式3 template <uint8_t modeId, pipe_t pipe> __aicore__ inline void CrossCoreSetFlag(uint16_t flagId) template <uint8_t modeId = 0, pipe_t pipe = PIPE_S> __aicore__ inline void CrossCoreWaitFlag(uint16_t flagId)

核间同步信号量匹配

CrossCoreSetFlag和CrossCoreWaitFlag是核间同步信号量接口，广泛用于多核间的数据依赖与协同控制。本质上以“信号量”的方式实现不同 AICore 之间的数据处理阶段解耦与有序推进，常用于流水线控制、双缓冲切换、跨核协作等场景。

• CrossCoreSetFlag：当前核（或线程）在完成某个阶段的数据处理后，主动设置指定的 flag 信号，告知依赖方（一般是其它核或下游流水线阶段）本阶段已完成，可以继续执行后续流程。
• CrossCoreWaitFlag：当前核（或线程）需等待某个 flag 信号被设置（即依赖的数据或事件完成），检测 flag 后才会继续向下执行。

这套信号量的本质是保证多线程/多流水阶段间一致的同步序列，防止因资源未就绪或依赖没完成而发生数据竞争或死锁等硬件异常。

在 Ascend 950 上CrossCoreWaitFlag和CrossCoreSetFlag数量必须严格匹配，且建议在同一同步语义域内按“先生产后消费”的顺序成对设计。Atlas A2 上算子与算子间若存在多余CrossCoreSetFlag信号量，HWTS 会进行特殊处理清零计数器；Ascend 950 系列为减少硬件开销，不再依赖该类兜底机制，要求单算子内核间同步信号量一一匹配，否则会出现必现卡死。

迁移时请重点排查以下问题：其一，异常分支提前返回导致只执行Set未执行对应Wait（或反之）；其二，多 stage 流水复用同一flagId但生命周期重叠，造成“跨阶段串扰”；其三，循环内条件触发同步但循环边界未对齐，导致迭代次数不一致。以上问题在 Atlas A2 上可能被掩盖，在 Ascend 950 上会直接暴露为阻塞超时或死锁。对跨核流水较复杂的算子，可先构建最小数据集进行单 stage 验证，再逐步叠加双缓冲和多 stage，以降低定位同步问题的复杂度。

集合通信类算子

Ascend 950 引入集合通信加速器 CCU1.0，降低了访存需求，减少了调度时延。为有效利用该特性，将算子跨片通信方式由 A2 的 AICPU 改为 CCU 通信。

Eager 模式

在 aclnn 两段式接口中的第二段接口中，为算子执行器 aclOpExecutor 指定集合通信类型。

以 MatmulAllReduce 算子迁移适配为例：设置NnopbaseSetHcclServerType枚举值，A2 为NNOPBASE_HCCL_SERVER_AICPU，950 为NNOPBASE_HCCL_SERVER_TYPE_CCU。

// ... aclnnStatus aclnnMatmulAllReduce( void* workspace, uint64_t workspaceSize, aclOpExecutor* executor, const aclrtStream stream) { // ... if (NnopbaseSetHcclServerType) { if (op::GetCurrentPlatformInfo().GetCurNpuArch() == NpuArch::DAV_3510) { NnopbaseSetHcclServerType(executor, NnopbaseHcclServerType::NNOPBASE_HCCL_SERVER_TYPE_CCU); } } // ... return ACLNN_SUCCESS; }

需要说明的是，GetCurrentPlatformInfo().GetCurNpuArch()这类按当前 NPU 架构分发逻辑的写法在本仓库的算子宿主侧同样可见，例如 common/inc/op_api/level2_base.h 与 common/inc/op_api/aclnn_check.h 中均涉及平台架构相关的判断与检查，可作为 Eager 模式下平台分支编程的参考。

Graph 模式

1. 用于资源计算与申请，涉及附属流相关信息的 CalcParamFunc 回调接口中，为 GE 的上下文 context 区分附属流的集合通信类型。
2. 用于设置主流/附属流上自定义任务、参数定制的 GenerateTask 回调接口中，区分两套 GE 的 KernelLaunch 接口，分别调用 AICPU 通信或 CCU 通信的创建及定制流程。

静态图 GE 侧创建通信 task 的任务类型，A2 为 aicpu kfc server + kfc_stream；950 为 ccu server + ccu_stream。涉及代码文件：matmul_all_reduce_gen_task.cpp（注：该文件属于 ops-transformer 仓库的 mc2 算子目录，本仓库conversion/下可观察到同类op_graph/算子图侧目录组织方式，可对照阅读）。

// ... ge::Status MatmulAllReduceCalcParamFunc(gert::ExeResGenerationContext *context) { if (Mc2GenTaskOpsUtils::IsTargetPlatformNpuArch(context->GetNodeName(), NPUARCH_A5)) { // 950 return Mc2GenTaskOpsUtils::CommonKFCMc2CalcParamFunc(context, "ccu server", "ccu_stream"); } // A2 return Mc2GenTaskOpsUtils::CommonKFCMc2CalcParamFunc(context, "aicpu kfc server", "kfc_stream"); } // ...

静态图 GenTask 调用接口有区别，流程有差异：

// ... // A2 ge::Status MatmulAllReduceGenTaskOpsUtils::MatmulAllReduceGenTaskCallback( const gert::ExeResGenerationContext *context, std::vector<std::vector<uint8_t>>& tasks) { // ... // aicpu task ge::KernelLaunchInfo aicpu_task = ge::KernelLaunchInfo::CreateAicpuKfcTask(context, SO_NAME.c_str(), KERNEL_NAME_V1.c_str()); // ... } // 950 ge::Status Mc2Arch35GenTaskOpsUtils::Mc2Arch35GenTaskCallBack(const gert::ExeResGenerationContext *context, std::vector<std::vector<uint8_t>> &tasks) { // ... // ccu task ge::KernelLaunchInfo ccuTask = ge::KernelLaunchInfo::CreateCcuTask(context, ccuGroups); // ... } ge::Status MatmulAllReduceGenTaskFunc(const gert::ExeResGenerationContext *context, std::vector<std::vector<uint8_t>> &tasks) { if (Mc2GenTaskOpsUtils::IsTargetPlatformNpuArch(context->GetNodeName(), NPUARCH_A5)) { // 950 return Mc2Arch35GenTaskOpsUtils::Mc2Arch35GenTaskCallBack(context, tasks); } // A2 return MatmulAllReduceGenTaskOpsUtils::MatmulAllReduceGenTaskCallback(context, tasks); } // ...

五、常见问题与性能调优建议（FAQ/性能小贴士）

若算子在 Ascend 950 上性能不升反降时，可优先排查：

1. 是否仍然使用 Atlas A2 的错位分核模板：Ascend 950 已支持同地址并行处理，继续使用错位规避会引入无效偏移与冗余地址变换，应切换到更规则的滑动窗口模板；
2. 是否未开启 CCU 通信仍走 AICPU：950 的集合通信能力依赖 CCU1.0，Eager/Graph 两侧均需显式切换到 CCU 任务类型，否则无法获得调度时延与访存收益；
3. tiling 是否沿用了 Atlas A2 的 L1/L0/UB 切分策略：Ascend 950 更大的片上缓存（L0C 256KB、UB 256KB）未被充分利用，应重新评估基本块大小、双缓冲容量与切 K/切块轮次，结合 profiling 的 MAC 利用率、MTE2 利用率与 L2 命中率迭代验证。

附：仓库内可对照阅读的迁移佐证

• math/abs/op_host/arch35/abs_tiling_arch35.cpp 与 math/abs/op_host/arch35/abs_tiling_arch35.h：arch35（Ascend 950 对应代际）专属 tiling 实现；
• math/abs/op_host/config/ascend950/abs_binary.json 与 math/abs/op_host/config/ascend350/abs_binary.json：按代际维护的算子描述配置；
• common/inc/op_api/level2_base.h 与 common/inc/op_api/aclnn_check.h：aclnn 宿主侧平台架构相关判断的通用封装；
• 本指南配套的硬件架构与通路图示均位于 docs/zh/figures 目录，包括atlas_a2_hardware_arch.png、ascend950_hardware_arch.png、swat_sliding_window_template.png、ascend950_cv_direct_channel.png，可直接配合阅读。

【免费下载链接】ops-math本项目是CANN提供的数学类基础计算算子库，实现网络在NPU上加速计算。项目地址: https://gitcode.com/cann/ops-math