训练营简介 2025年昇腾CANN训练营第二季，基于CANN开源开放全场景，推出0基础入门系列、码力全开特辑、开发者案例等专题课程，助力不同阶段开发者快速提升算子开发技能。获得Ascend C算子中级认证，即可领取精美证书，完成社区任务更有机会赢取华为手机，平板、开发板等大奖。
报名链接：https://www.hiascend.com/developer/activities/cann20252#cann-camp-2502-intro
前言
“写代码只占开发的 20%，剩下的 80% 都在做维护。”
对于 Ascend C 算子开发者来说，维护成本主要来自两个维度：
硬件碎片化：你的算子在 910B 上跑得飞快，在 910A 上可能编译报错，在 310P 上可能精度不对。
软件迭代快：CANN 的版本更新很快，API 经常变动（比如
DataCopy的参数签名）。如何保证半年前写的代码在今天的环境还能跑？
本期文章，我们将引入工程化思维，手把手搭建一套自动化的算子交付系统。
一、 核心图解：从“手工作坊”到“智能工厂”
如果我们把写算子比作“打铁”，那么 CI/CD 就是一条全自动化的流水线。
二、 痛点一：多芯片编译 (Multi-SoC Build)
Ascend C 的算子二进制是与芯片架构强绑定的。910B 的指令集（UB 大小、Vector 宽度）与 910A 不同。 我们不能指望用户自己去编译，必须发布Fat Binary（胖二进制）或者提供自适应编译脚本。
2.1 CMake 矩阵构建
在op_kernel/CMakeLists.txt中，我们需要遍历所有支持的架构。
# 定义目标芯片列表 set(SOC_VERSIONS "Ascend910A" "Ascend910B1" "Ascend310P3") foreach(SOC ${SOC_VERSIONS}) # 为每个 SOC 创建一个独立的 Target set(TARGET_NAME "custom_ops_${SOC}") add_ops_compile_options( ALL_OPS OP_TYPE AddCustom SRCS ${KERNEL_FILES} ) # 关键：通过参数指定当前编译的 SOC # 这里的 -soc_version 参数会传递给 ccec 编译器 # 编译器会自动宏定义 __ASCEND_SOC_VERSION__ 等，供代码里做 #ifdef add_ops_kernel( TARGET ${TARGET_NAME} OPS_INFO ${CMAKE_CURRENT_SOURCE_DIR}/op_info.json SOC_VERSION ${SOC} ) endforeach()2.2 代码中的宏隔离
在 Kernel 代码中，不同芯片的 UB 大小不同，Tiling 策略也不同。
#if defined(__ASCEND_910__) constexpr int32_t UB_SIZE = 256 * 1024; #elif defined(__ASCEND_910B__) constexpr int32_t UB_SIZE = 192 * 1024; // 假设值 #endif // 或者使用 Ascend C 提供的获取硬件信息的 API (推荐) // GetCoreMemSize(...)三、 痛点二：版本兼容性 (Version Compatibility)
CANN SDK 升级时，可能会废弃旧 API。为了让代码同时兼容新旧版本，我们需要Feature Detection（特性检测）。
3.1 编译期检测
在 CMake 中检测 CANN 版本：
# 获取 CANN 版本号 file(READ "${ASCEND_CANN_PACKAGE_PATH}/ascend_cann_package_info.json" PACKAGE_INFO) # 解析 JSON 得到版本 (伪代码) string(REGEX MATCH "..." CANN_VERSION ${PACKAGE_INFO}) if (CANN_VERSION VERSION_GREATER "7.0") add_definitions(-DCANN_V7_OR_LATER) endif()3.2 源码级适配
__aicore__ inline void Compute() { #ifdef CANN_V7_OR_LATER // 新版 API 可能支持更高级的 Mask 模式 Add(zLoc, xLoc, yLoc, len, mask); #else // 旧版 API SetVectorMask(mask); Add(zLoc, xLoc, yLoc, len); #endif }四、 自动化流水线：GitLab CI / Jenkins
一个标准的算子库 CI 流程应该包含：
Static Check:
clang-format检查代码风格，cppcheck检查内存泄漏风险。Host Build: 编译 Host 侧代码 (Tiling/Shape)，确保 C++ 语法正确。
Device Build: 调用
ccec编译 Kernel，检查是否使用了非法指令。Simulation Test: 使用 CPU 孪生调试模式（第 17 期）运行 UT，验证逻辑正确性（无需 NPU 硬件）。
On-Device Test(可选): 如果有物理机 Runner，提交任务到 NPU 上跑 ST 测试，验证精度。
Dockerfile 最佳实践： 构建一个包含特定版本 CANN Toolkit 的 Docker 镜像作为 CI Runner 环境，确保编译环境的一致性，避免“我本地能跑”的玄学问题。
五、 交付：构建 .run 安装包
用户不想关心源码，他们只想要一个安装包。 CANN 提供了打包脚本模板。
编译产物：收集所有生成的
.o,.json,.so。目录组织：
run_package/ ├── op_impl/ # Kernel 二进制 ├── op_proto/ # 原型定义 ├── framework/ # 框架适配插件 └── scripts/ # 安装/卸载脚本打包：使用
makeself工具制作自解压的.run文件。
用户拿到后，只需一行命令：./custom_ops_v1.0.run --install系统会自动将算子注册到昇腾的opp库中，PyTorch 和 MindSpore 就能直接识别了。
六、 总结
工程化是算子开发的护城河。
矩阵编译：通过 CMake 管理多芯片版本。
宏隔离：通过预编译宏解决 API 兼容性。
自动化：把重复的测试交给 CI，把精力留给算法创新。
当你建立起这套体系，你就不再是一个人在战斗，而是在运营一个产品。
