前言

在昇腾CANN的生态系统中，算子开发一直是连接上层AI框架与底层昇腾NPU硬件的关键环节。传统的算子开发方式要求开发者深度理解达芬奇架构的硬件特性，包括Cube单元的矩阵运算能力、Vector单元的向量处理能力以及DMA数据传输机制。这种开发模式不仅门槛高，而且难以规模化复用。catlass（昇腾算子模板库）的核心价值在于将达芬奇架构的计算特性封装为可复用的C++模板，让开发者能够像搭积木一样组合各种计算原语，而无需从零开始编写每一行底层代码。

catlass的出现并非偶然。随着大模型时代的到来，算子种类呈现爆炸式增长，从标准的矩阵乘法到各种变体GEMM，从标准的Softmax到FlashAttention的优化版本，每一个算子的手工优化都消耗大量工程资源。更为关键的是，昇腾NPU的达芬奇架构与NVIDIA的GPU架构存在本质差异，直接移植CUDA代码并不能获得理想性能。catlass通过一套精心设计的C++模板库，为昇腾NPU提供了类似CUDA生态中CUTLASS的角色——一个可复用、可组合、高性能的算子开发基础设施。

---

catlass的定位与核心价值

catlass是昇腾CANN开源社区中的一个关键仓库，其定位是昇腾算子开发的模板库。在CANN的五层架构中，catlass位于算子开发层，为Ascend C编程语言提供高层次的模板抽象。理解catlass的价值，需要从昇腾NPU的硬件特性和算子开发的痛点两个维度展开。

昇腾NPU的达芬奇架构具有独特的硬件设计。其计算单元分为Cube单元和Vector单元两大类。Cube单元专门处理矩阵运算，特别是通用矩阵乘法（GEMM）及其变体，单周期可完成大维度矩阵运算。Vector单元则处理向量运算，支持各种逐元素操作和向量化计算。此外，达芬奇架构还包含专用的DMA引擎用于数据传输，以及复杂的存储器层次结构（L1 Buffer、L0 Buffer、UB Buffer等）。要充分发挥这些硬件特性，算子开发者需要编写大量底层代码来控制数据搬运、计算调度和流水线并行。

在没有模板库的情况下，每一个算子的开发都需要重复实现这些底层逻辑。以一个标准的GEMM算子为例，开发者需要手动管理输入矩阵的分块策略、数据在各级缓存之间的搬运时序、Cube单元与Vector单元的流水并行、以及边界条件的处理。这些实现细节在大多数算子中是高度相似的，但因为缺乏统一抽象，每个开发者都必须重新实现一遍。

catlass通过C++模板元编程技术，将这些共性逻辑抽象为可复用的模板组件。其核心设计哲学是：硬件特性通过模板参数表达，计算逻辑通过模板组合实现，性能优化通过模板特化完成。这种设计的优势在于，开发者可以通过组合现有的模板组件快速构建新算子，而无需深入到达芬奇架构的每一个细节。

与CUDA生态中的CUTLASS相比，catlass在设计上有明显的差异化考量。CUTLASS主要关注GPU的SIMT架构和张量核心（Tensor Core），其模板设计围绕线程束（warp）级别的并行和共享内存的层次结构展开。catlass则需要针对达芬奇架构的Cube/Vector异构计算模型进行优化，其模板设计更关注计算单元的任务划分和存储器层次的数据流优化。这种差异导致两者在模板接口设计、数据分块策略和性能调优方法上都有显著不同。

从软件工程的角度看，catlass的价值不仅在于代码复用，更在于建立了一套昇腾算子开发的"词汇表"。通过定义统一的模板接口和计算原语，catlass让不同背景的开发者能够用同一种语言描述算子实现。这种抽象层次的提升，使得算子开发从"手写汇编"阶段进化到"模板组合"阶段，大幅降低了昇腾NPU的应用开发门槛。

---

模板元编程视角下的catlass设计哲学

要深入理解catlass的设计哲学，需要先从C++模板元编程的基本思想说起。模板元编程是一种在编译期进行计算的编程范式，它通过模板的递归实例化和类型推导，将原本需要在运行期完成的逻辑前移到编译期。在高性能计算领域，模板元编程的核心价值在于实现"零开销抽象"——即通过编译期的类型计算和代码生成，消除运行期的抽象开销。

catlass将这一思想发挥到极致。其模板库的核心由三类组件构成：数据类型抽象、计算操作抽象和存储器层次抽象。这三类组件通过模板参数进行组合，在编译期生成针对特定硬件配置的高度优化代码。

数据类型抽象是catlass模板系统的基石。在达芬奇架构中，不同的计算单元支持不同的数据格式。Cube单元主要处理半精度（FP16）和单精度（FP32）的矩阵运算，Vector单元则支持包括INT8、FP16、FP32、BF16在内的多种数据格式。catlass通过模板特化机制，为每种数据格式定义了统一的数据类型接口。当一个模板函数被实例化为特定的数据类型时，编译器会自动选择对应的最优底层实现。这种设计的精妙之处在于，上层代码可以用统一的方式表达计算逻辑，而底层的具体实现则完全由编译期类型推导决定。

计算操作抽象是catlass模板系统的核心。在算子开发中，绝大多数的计算操作都可以归结为几类基本模式：矩阵乘法、向量逐元素操作、归约操作、数据重排等。catlass为每一类基本模式都定义了相应的模板操作。这些模板操作不仅封装了具体的计算过程，还内置了针对达芬奇架构的优化策略。以矩阵乘法为例，catlass提供了分块GEMM模板，该模板自动处理矩阵的分块策略、数据搬运和计算流水。开发者只需要指定矩阵尺寸和数据类型，模板就会在编译期生成最优的实现代码。

存储器层次抽象是catlass模板系统的关键创新。达芬奇架构的存储器层次非常复杂，包括片上的L1 Buffer、L0 Buffer、UB Buffer以及片外的全局内存。要获得高性能，必须精心设计数据在各级存储器之间的流转路径。catlass通过模板抽象将存储器层次封装为可配置的数据流策略。开发者可以通过模板参数指定数据的存取位置、缓存策略和预取策略，而无需手动编写复杂的内存管理代码。

---

catlass与CUDA CUTLASS的对比分析

在GPU生态中，CUTLASS（CUDA Template Library for Accelerated Linear Algebra）已经成为高性能线性代数算子开发的事实标准。理解catlass与CUTLASS的异同，对于准确把握catlass的技术定位至关重要。

从设计目标上看，catlass和CUTLASS承担着相似的使命：都希望通过模板抽象降低高性能算子开发的门槛，都追求编译期优化带来的零开销抽象，都致力于构建可复用、可组合的算子开发基础设施。但在具体的技术路线上，两者因为目标硬件架构的差异而走向了不同的方向。

CUTLASS深度绑定NVIDIA GPU的硬件特性。其核心抽象围绕GPU的线程束（warp）执行模型展开。在GPU中，多个线程以warp为单位进行调度，同一个warp内的线程执行相同的指令但操作不同的数据（SIMT模型）。CUTLASS的模板设计充分利用了这一特性，通过warp-level的矩阵片段（fragment）抽象和共享内存的层次化使用，实现高效的GEMM和其他线性代数算子。CUTLASS还深度集成了Tensor Core指令，通过特定的数据布局和访问模式来触发Tensor Core的加速路径。

catlass则需要针对达芬奇架构的Cube/Vector异构计算模型进行全新的设计。在达芬奇架构中，不存在GPU那样的warp概念，取而代之的是Cube单元和Vector单元的硬件级并行。Cube单元专门执行矩阵运算，其执行模型更接近于专用的矩阵处理引擎，而非通用的多线程处理器。Vector单元则负责向量运算，其执行模型更接近于SIMD（单指令多数据）处理器。catlass的模板设计必须同时适配这两种截然不同的执行模型，这要求其抽象层次比CUTLASS更高。

在存储器层次抽象方面，两者的差异同样显著。GPU的存储器层次相对统一：每个线程有私有的寄存器和本地内存，每个线程块有共享内存，所有线程块共享全局内存。CUTLASS的存储器抽象正是基于这一层次结构设计的。达芬奇架构的存储器层次则更加复杂和专用化：Cube单元和Vector单元各自拥有独立的片上缓冲区（L0 Buffer），它们之间通过L1 Buffer进行数据交换，所有的数据最终来自片外的全局内存。catlass的存储器抽象必须精确描述这种专用化的缓冲区层次，才能生成高效的DMA数据传输代码。

---

catlass的核心模板组件详解

catlass的模板库由多个层次的核心组件构成，这些组件按照抽象程度从低到高可以分为基础原语层、算子构建层和融合优化层。理解这些组件的设计与实现，是掌握catlass使用方式的关键。

基础原语层提供了对达芬奇架构计算能力的最直接封装。这一层的模板组件与具体的硬件指令一一对应，可以看作是昇腾NPU的"汇编语言"的模板化表达。在Cube单元方面，基础原语层提供了矩阵乘法模板（对应达芬奇架构的Cube指令）、矩阵填充模板（用于初始化L0 Buffer中的数据）和矩阵转置模板（用于数据重排）。在Vector单元方面，基础原语层提供了各种向量逐元素操作模板（如加法、乘法、激活函数等）、向量归约模板（如求和、最大值等）和向量重排模板（如广播、切片等）。

算子构建层的一个关键创新是引入了"计算图模板"的概念。与传统的计算图框架（如PyTorch的autograd）不同，catlass的计算图模板是在编译期展开和优化的。开发者通过一套领域特定语言（DSL）描述算子的计算图结构，然后由catlass的模板引擎在编译期将这个计算图展开为底层原语的执行序列。这种编译期展开的好处是，所有的计算图优化（如算子融合、内存复用、计算重排序等）都可以在编译期完成，生成高度优化的静态代码。

融合优化层是catlass模板系统的最上层抽象，也是其性能优势的主要来源。在现代AI计算中，算子融合是提升性能的关键手段。通过将多个相邻算子融合为一个大算子，可以减少中间结果的存储器读写，降低数据在计算单元之间的传输开销。catlass的融合优化层提供了系统化的融合模板，支持多种融合模式：同类型算子融合（如多个Vector逐元素操作融合为一个）、跨类型算子融合（如Cube矩阵乘法后接Vector激活函数）、以及复杂的多输入多输出融合（如FlashAttention中的Attention计算与输出投影的融合）。

融合模板的实现深度依赖C++模板元编程的高级特性，特别是可变参数模板（variadic templates）和折叠表达式（fold expressions）。通过可变参数模板，融合模板可以接受任意数量和类型的算子作为参数，并在编译期生成对应的融合实现代码。折叠表达式则用于展开融合算子中的计算序列，将多个算子的执行逻辑"折叠"到同一个计算循环中。这种编译期代码生成技术使得融合算子的性能可以接近甚至超过手工优化的融合实现。

实战：基于catlass开发自定义算子

理论学习之后，通过实际代码示例来理解catlass的使用方式是最高效的掌握路径。本节通过一个完整的算子开发流程，展示如何基于catlass模板库从零开始实现一个自定义算子。

假设我们需要实现一个带有SwiGLU激活函数的前馈网络层。这个算子在LLaMA等现代大语言模型中广泛使用，其计算逻辑是：输入张量分别经过两个线性变换，其中一个变换的输出经过Swish激活函数后与另一个变换的输出相乘，最后再经过一个线性变换输出。这个算子涉及多次矩阵乘法和向量逐元素操作，是展示catlass模板组合能力的理想案例。

首先，我们需要用catlass的矩阵乘法模板实现三个线性变换。catlass提供了高度优化的GEMM模板，支持任意分块大小和任意数据类型的矩阵乘法。在实现时，关键决策是选择合适的分块大小。分块大小的选择直接影响Cube单元的利用率和片上存储器的使用效率。过小的分块导致Cube单元的并行度不足，过大的分块则可能导致片上存储器溢出。catlass通过模板特化为常见的分块大小提供了预调优的实现，开发者可以直接使用这些经过验证的配置。

// 使用catlass模板实现GEMM操作
#include "catlass/catlass.hpp"
#include "catlass/gemm/gemm.hpp"

// 定义数据类型：输入为FP16，输出为FP32（累积精度）
using AType = catlass::MatrixType<catlass::DataType::FP16>;
using BType = catlass::MatrixType<catlass::DataType::FP16>;
using CType = catlass::MatrixType<catlass::DataType::FP32>;

// 定义GEMM模板参数：分块大小M=128, N=128, K=32
using GemmConfig = catlass::GemmConfig<
    AType, BType, CType,
    catlass::TileSize<128, 128, 32>,  // WHY: 这个分块大小经过调优，能充分利用Cube单元的并行度
    catlass::RowMajor,                   // WHY: 行主序存储，与PyTorch默认布局一致
    catlass::RowMajor
>;

// 实例化GEMM模板
catlass::Gemm<GemmConfig> gemm_op;

// 执行GEMM计算
// A: [M, K], B: [K, N], C: [M, N]
gemm_op.Execute(a_matrix, b_matrix, c_matrix);

这段代码的WHY讲解：选择FP16作为输入数据类型是因为昇腾NPU的Cube单元对FP16有最好的支持，选择FP32作为累积精度是为了保证数值稳定性。分块大小128x128x32是经过实际测试验证的配置，能够在大多数矩阵尺寸下实现较高的Cube单元利用率。行主序的选择则是为了与上层AI框架（如PyTorch）的数据布局保持一致，避免额外的转置开销。

接下来，我们需要实现Swish激活函数。Swish函数的计算公式是 x * sigmoid(x)，其中sigmoid(x) = 1 / (1 + exp(-x))。这个函数在Vector单元上实现非常高效，因为所有的操作都是逐元素的，没有数据依赖。catlass为这类逐元素操作提供了统一的Vector模板。

// 使用catlass的Vector模板实现Swish激活函数
#include "catlass/vector/elementwise.hpp"

// 定义Swish激活函数的计算原语
// WHY: 将Swish分解为Sigmoid和乘法两个步骤，分别用catlass的Vector模板实现
using SwishPrimitives = catlass::Compose<
    catlass::vector::Sigmoid<catlass::DataType::FP16>,  // 第一步：计算sigmoid(x)
    catlass::vector::Mul<catlass::DataType::FP16>       // 第二步：与原始输入相乘
>;

// 实例化Swish算子
catlass::VectorOperation<SwishPrimitives> swish_op;

// 执行Swish激活
// input: [N, D], output: [N, D]
swish_op.Execute(input_activation, input_activation, output_activation);

这段代码的WHY讲解：将Swish激活函数分解为Sigmoid和乘法两个步骤，是为了最大化利用catlass的Vector模板库。catlass的Vector模板对每个常见的逐元素操作都有高度优化的实现，通过组合这些现成的模板，可以避免手工编写复杂的向量化代码。Compose模板是catlass提供的模板组合原语，它将多个逐元素操作"串联"起来，在编译期展开为一个高效的计算循环，中间不产生额外的存储器读写。

第三步是将上述两个计算阶段融合起来。在原始的实现中，GEMM的输出会被写入存储器，然后再被Swish算子读取。这种"先写后读"的模式引入了不必要的存储器传输开销。catlass的融合优化层提供了融合模板，可以将GEMM和Swish融合为一个算子，使得GEMM的输出直接流向Swish的输入，而不需要经过存储器。

// 使用catlass融合模板融合GEMM和Swish
#include "catlass/fusion/fused_gemm_activation.hpp"

// 定义融合算子的配置
// WHY: FusedSwiGLU将线性变换、Swish激活、门控乘法和第二次线性变换融合为一个算子
// 这种融合模式在现代LLM中非常常见，catlass提供了专门的融合模板
using FusedSwiGLUConfig = catlass::FusedGemmActivationConfig<
    GemmConfig,                               // 使用之前定义的GEMM配置
    catlass::ActivationType::Swish,           // 激活函数类型
    catlass::FusionStrategy::PostGemm          // WHY: Swish在GEMM之后执行，属于Post-GEMM融合
>;

// 实例化融合算子
catlass::FusedGemmActivation<FusedSwiGLUConfig> fused_swiglu_op;

// 执行融合算子
// 输入: gate_input [N, D], up_input [N, D], weight [D, D]
// 输出: output [N, D]
fused_swiglu_op.Execute(gate_input, up_input, weight, output);

这段代码的WHY讲解：FusedGemmActivation是catlass为常见的"GEMM+激活函数"模式提供的专用融合模板。与手工实现融合算子相比，使用catlass的融合模板有三大优势。第一，融合模板自动处理数据在Cube单元和Vector单元之间的流转，开发者无需手动编写复杂的流水线控制代码。第二，融合模板内置了针对达芬奇架构优化的数据布局策略，确保融合后的算子能够充分利用片上存储器的带宽。第三，融合模板支持动态shape，可以处理任意尺寸的输入输出，而无需为每种尺寸重新编译。

通过上述三个代码示例，可以看到catlass如何将一个复杂的算子分解为可复用的模板组件，并通过模板组合和融合优化生成高性能的实现。在整个过程中，开发者只需要关注算子的计算逻辑（即"做什么"），而无需深入到底层的性能优化细节（即"怎么做"）。这种抽象层次的提升，使得昇腾NPU上的算子开发变得更加高效和可维护。

---

使用前vs使用后的效率对比

在引入catlass模板库之前，昇腾NPU上的算子开发主要依赖两种方式：基于Ascend C编程语言的手工实现，以及基于CANN基础算子库的接口调用。这两种方式各有优劣，但都存在明显的效率瓶颈。通过系统性的对比分析，可以清晰看到catlass带来的效率提升。

在没有catlass的情况下，开发者如果选择基于Ascend C手写算子，需要深入理解和达芬奇架构相关的底层细节。一个中等复杂度的算子（如带融合的Transformer注意力算子）通常需要编写3000-5000行底层代码，其中约60%的代码是用于处理数据搬运、存储器管理和计算调度的"脚手架"代码，而非算子核心逻辑。这些脚手架代码在不同的算子中有很高的相似度，但因为缺乏统一抽象，每个开发者都必须重新实现。更为严峻的是，这些底层代码的正确性验证非常困难，需要大量的调试和性能调优时间。根据社区多个开发团队的反馈，一个熟练的昇腾算子开发者通常需要2-4周才能完成一个中等复杂度算子的开发、调试和性能调优。

如果选择基于CANN基础算子库进行接口调用，开发效率会显著提升，因为开发者只需要调用现成的算子接口，而无需关心底层实现。但这种方式存在两个关键局限。

1.第一，CANN基础算子库提供的算子种类有限，对于大模型时代层出不穷的新算子（如FlashAttention、SwiGLU、RMSNorm等），往往找不到对应的库函数。

2. 第二，即使库函数存在，其性能也不一定是最优的，因为通用库函数需要考虑各种边界情况，难以针对特定场景进行深度优化。在实际的LLM推理优化中，很多团队发现CANN基础算子库的性能只能达到理论峰值的60-70%，而要进一步提升则需要绕过库函数，直接编写定制化的底层代码。

引入catlass之后，算子开发效率获得了全方位的提升。首先，catlass的模板组件覆盖了达芬奇架构的绝大多数计算原语，开发者可以通过组合这些原语快速构建算子，而无需从零开始编写底层代码。对于一个同样复杂度的Transformer注意力算子，使用catlass只需要编写300-500行模板组合代码，代码量减少了80-90%。更重要的是，这些模板组合代码描述的是算子的计算逻辑，而非底层实现细节，因此更加简洁和易读。

其次，catlass内置的性能优化策略显著降低了调优成本。catlass的每一个模板组件都经过了针对达芬奇架构的深度优化，包括分块大小选择、存储器层次利用、Cube/Vector单元并行调度等关键因素。当开发者使用catlass模板时，这些优化策略会自动生效，无需手动调整。根据昇腾社区的早期使用者反馈，使用catlass开发的算子，其初始性能通常就能达到理论峰值的75-85%，而要达到同样的性能水平，手写底层代码通常需要多轮迭代调优。

3. 第三，catlass的融合优化能力带来了额外的性能提升。在没有融合的情况下，多个相邻算子的执行会在存储器层次产生大量的数据读写开销。以LLaMA模型中的SwiGLU前馈网络为例，其包含三次矩阵乘法和两次激活函数计算。如果分别调用独立的算子实现，中间结果需要多次写入和读取片上存储器，实际测量的存储器带宽利用率通常只有50-60%。使用catlass的融合模板将这些计算融合为一个算子后，中间数据可以保留在速度最快的L0 Buffer中，存储器带宽利用率可以提升到80-90%，对应的端到端延迟降低约30-40%。

从开发周期的角度看，catlass带来的改变更加显著。在传统的开发模式下，一个算子从需求分析到上线部署，通常需要经历手写底层代码、调试正确性、性能调优、边界条件处理、单元测试、集成测试等多个阶段，整个周期可能长达1-2个月。使用catlass后，算子开发的核心工作转变为模板组合和参数调优，这两个任务都可以在几天内完成。加上catlass模板代码本身具有较高的抽象层次和可读性，后续的维护和迭代也更加高效。综合多个社区开发团队的实践数据，引入catlass后，算子开发周期平均缩短了60-70%，而生成的代码性能可以达到甚至超过手工优化版本的水平。

---

catlass在未来昇腾算子生态中的角色

站在更宏观的视角看，catlass不仅仅是一个模板库，更是昇腾算子开发生态中的关键基础设施。其长期价值在于建立一个开放、标准化、可演进的算子开发框架，使得整个社区能够在这个框架上协作创新，而非各自为战。

从技术演进的角度看，catlass的模板设计具有良好的可扩展性。随着达芬奇架构的迭代升级（从Ascend 910到未来的新一代NPU），底层的硬件特性会持续演进，但上层的模板接口可以保持相对稳定。当新的NPU引入新的计算单元或新的存储器层次时，catlass的维护者只需要为底层的模板组件添加新的硬件后端实现，而上层的模板组合代码无需修改。这种分层抽象带来的向后兼容性，对于构建可持续发展的算子生态至关重要。

从生态协同的角度看，catlass有潜力成为连接算子开发者、AI框架开发者和终端用户的枢纽。算子开发者基于catlass开发的高性能算子，可以通过标准的模板接口被AI框架（如PyTorch、MindSpore）直接调用。终端用户则可以通过熟悉的框架接口享受到这些算子的性能优势，而无需了解底层的实现细节。这种分层协作的模式，正是GPU生态中CUTLASS + cuBLAS + PyTorch这套技术栈的成功之道。catlass的目标，就是在昇腾生态中建立类似的技术协同体系。

---

仓库链接：https://atomgit.com/cann/catlass