前言一个在GPU上跑得好好的自定义算子换到昇腾NPU上为什么就跑不动了很多人下意识觉得算子移植就是对着数学公式在另一套硬件上重写一遍计算逻辑。但昇腾NPU的计算方式与GPU完全不同——它不靠逐指令发射执行而是把整个模型编译成一张计算图Graph图中的每一个节点就是一个算子Operator。这张图包含了每个算子的输入输出张量形状、数据类型、数据排布格式等元信息。CANN的Metadef元数据定义框架正是提供这些元信息的基础组件仓。它定义了昇腾NPU计算图里一块积木该长什么样、能怎么拼是所有上层算子仓库和计算引擎的公共底座。理解Metadef就理解了自定义算子进入昇腾NPU世界所跨的第一道门槛。积木说明书Metadef给昇腾NPU的算子定了什么规矩假设你面前有一堆积木。每一块积木都有标准化的尺寸长宽高、接口凸点和凹槽、颜色和材料。如果没有这套标准A工厂生产的积木永远无法和B工厂的拼在一起——因为接口对不上尺寸不自洽。CANN的Metadef就是这套积木规格标准说明书。它不像ops-nn那样直接生产某一种具体的积木比如Convolution这个算子也不像GEGraph Engine那样作为建筑师去设计和拼装整座建筑。Metadef做的事情更底层它规定了每一块积木必须用什么数据结构来描述自己必须提供哪些接口供别人查询必须遵循什么方式来注册到系统中。这种分层设计——Metadef提供规格、ops仓库生产算子、GE调度拼装——正是CANN让不同来源的算子能够统一在昇腾NPU上运行的根基所在。Metadef提供的基础数据类型包括Tensor张量容器、Shape形状描述、DataType数据类型枚举、Format数据排布格式枚举、TensorDesc张量描述信息等。它提供的注册接口包括OpRegistrationData算子注册数据结构、OpReceiver算子注册信息接收器、TensorType输入输出类型定义等。回过头看那张计算图。图中的每个算子节点都携带了一份完整的元数据——它的输入Tensor是什么形状数据类型是float32还是int8数据排布是NCHW还是NHWC输出Tensor的形状能否从输入推导出来等等。这些元数据不是在运行时动态查询的而是在构图阶段就由Metadef定义好的数据结构承载着随计算图一起传递给GE进行编译优化。所以把一个自定义算子接入昇腾NPU的过程本质上就是用Metadef提供的工具为这个算子办一张身份证把它登记到系统中告诉计算图这个算子是谁、输入输出长什么样、做什么运算。算子身份证OpRegistrationData如何标记一个自定义算子自定义算子注册的核心接口是OpRegistrationData。可以把它理解成一张算子身份证登记表——上面填写了算子的名字、它接受几个输入、产生几个输出、每个输入输出的数据类型限制等关键信息。这张表和算子的计算逻辑kernel代码本身没有关系它只负责在计算图层面知会系统有这么一个算子存在它长这样。#includeregister/register.h#includegraph/types.husingnamespacege;// 注册一个名为CustomRelu的自定义算子voidRegisterCustomRelu(){OpRegistrationDataregData(CustomRelu);// 定义输入一个Tensor名称为x// 系统要求每个输入/输出必须有名称用于在图中唯一标识regData.Input(x);// 定义输出一个Tensor名称为yregData.Output(y);// 设置输入x的允许数据类型仅支持DT_FLOATregData.SetInputDataType(x,DT_FLOAT);// 设置输出y的允许数据类型仅支持DT_FLOATregData.SetOutputDataType(y,DT_FLOAT);}这段代码注册了一个名为CustomRelu的算子它接收一个名为x的float32类型输入Tensor产生一个名为y的float32类型输出Tensor。注册入口不在算子内部而在单独的函数里通过OpRegistrationData对象来说明代办事项是因为CANN在一个编译流程中可能反复扫描算子信息多次。如果把注册逻辑写在算子构造函数里头每次加载都会被重复调用增加开销且难以统一管理。Metadef把注册和实现分离让GE在构图阶段仅通过OpRegistrationData就能获取名字、输入输出结构、类型约束无需加载算子的可执行代码这对大型模型编译的启动速度至关重要。也就是说注册CustomRelu时昇腾NPU还不关心这个算子的数学公式是什么——它只关心CustomRelu这个节点在计算图里可以连什么类型的输入、产出什么类型的输出。具体的数学公式TBE DSL或TIK代码是后面编译阶段才加载的。尺寸推算InferShapeContext如何决定输出Tensor的形状算子注册时除了告诉系统输入输出的数据类型还要告诉系统给定输入的形状Shape输出的形状应该怎么算。以ReLU为例输入是一个[N, C, H, W]的Tensor输出应该是同样形状的Tensor——因为ReLU是逐元素激活函数。但如果是矩阵乘法输入形状[N, K]和[K, M]会推导出输出形状[N, M]。这种形状推导逻辑对计算图的编译优化非常重要GE需要知道整张图中每一层的张量形状才能完成内存分配和融合优化。Metadef不限制算子开发者在哪个层面描述形状推导——可以是简单的公式可以是复杂的规则表达式甚至可以是基于输入的数值计算。这种灵活性对不同复杂度的算子都很关键。#includeregister/register.h#includegraph/infer_shape_context.hvoidSetupCustomReluShapeInfer(OpRegistrationDataregData){// 注册形状推导函数// 当GE在构图阶段遇到CustomRelu时会调用此函数来推算输出形状regData.SetInferShape([](constInferShapeContextctx)-graphStatus{// 获取第一个输入(索引0)的描述信息TensorDesc inputDescctx.GetInputTensorDesc(0);// 从描述信息中提取张量形状Shape inputShapeinputDesc.GetShape();// 获取第一个输出(索引0)的描述信息TensorDesc outputDescctx.GetOutputTensorDesc(0);// 将输出的形状设为与输入一致// 对于ReLU这一类逐元素算子输出形状完全等于输入形状outputDesc.SetShape(inputShape);// 将更新后的输出描述写回上下文ctx.SetOutputTensorDesc(0,outputDesc);returnGRAPH_SUCCESS;});}这段代码展示了CustomRelu的形状推导函数。它从InferShapeContext中取出输入Tensor的形状直接赋值给输出Tensor。InferShapeContext是一个抽象接口而非具体的Shape类原因是不同阶段的形状推导场景不同。构图阶段的形状推导是静态的通常基于输入的Shape对象就能完成。但如果算子的输出形状依赖输入Tensor的数值内容例如Reshape操作就需要更复杂的分支逻辑。Metadef的InferShapeContext允许开发者在函数体内自由组合推理逻辑而不是绑死一种简单的表达式。这意味着从最简单的复制形状到复杂的条件分支都能容纳。另外SetOutputTensorDesc的调用必须显式完成框架不会做任何默认推导——这种设计强迫开发者明确声明输出形状避免编译阶段出现未知形状的传播错误。数据类型与格式TensorDesc告诉计算图你的数据长什么样TensorDesc是Metadef提供的最常打交道的数据结构之一。它不直接存储张量的实际数据那些数据存在Device的HBM里而是存储张量的描述信息形状Shape、数据类型DataType、数据排布Format、内存对齐策略等。计算图上每一条数据流的边Edge两头都得配TensorDesc。一端的算子输出某种描述的Tensor另一端的算子输入必须能接受同类型描述的Tensor否则GE会报类型不匹配错误。#includegraph/tensor.h#includegraph/types.h// 构建一个NCHW格式的4维Tensor描述信息TensorDescBuildTensorDesc(){TensorDesc desc;// 设形状为 [batchSize, channels, height, width] [1, 3, 224, 224]Shapeshape({1,3,224,224});desc.SetShape(shape);// 设数据类型为float32desc.SetDataType(DT_FLOAT);// 设数据排布格式为NCHWdesc.SetFormat(FORMAT_NCHW);// 设置张量的名称用于在图中定位desc.SetName(input_image);// 返回构建好的TensorDescreturndesc;}这段代码构造了一个1x3x224x224、float32、NCHW格式的Tensor描述信息并赋予名称input_image。GE在构图时看到这个描述就知道要为这个Tensor预留多少内存——1x3x224x224个float32值总计约602KB。Format枚举如FORMAT_NCHW、FORMAT_NHWC、FORMAT_FRACTAL_NZ等不是可有可无的额外信息。昇腾NPU的Cube单元在矩阵计算时对数据排布有特定偏好——FRACTAL_NZ格式就是专门为NPU的矩阵乘法设计的5D分形排布格式。如果在TensorDesc中只声明Shape而不声明FormatGE在后续的格式转换优化中就需要做额外的推理工作。Metadef要求Format作为TensorDesc的一个显式字段好处是算子开发者可以明确告诉编译器我的输出就是NCHW编译器就不用猜了。相反如果算子内部已经做了格式转换输出FRACTAL_NZ格式开发者也能在TensorDesc里直接指定避免编译器做多余且可能错误的格式转换。用标准底座与徒手搭建的效率差异Metadef的作用不只是在接口层面提供便利。从工程效率看它带来的改善体现在多个维度。下面以一个自定义算子从零到注册完成的过程为例做对比。维度不使用Metadef徒手实现使用Metadef标准底座差异来源数据结构定义需手动编写Tensor、Shape、DataType等类约200行C含内存管理和拷贝构造函数直接复用Metadef提供的TensorDesc、Shape等类约5行代码基础数据结构由Metadef统一封装开发者只需调用Set/Get接口算子注册需实现一套算子注册表Registry包含名称到工厂函数的映射、线程安全的插入/查找、模块加载时的自动调用使用OpRegistrationData的链式调用3-5行完成名称、输入输出、类型约束的声明Metadef的register.h内部已封装了注册表内核和OpReceiver机制形状推导需实现Shape推导分发器根据算子名称dispatch到不同推导函数处理异常和类型校验通过SetInferShape(lambda)注册回调即可推导失败时框架统一返回GRAPH_FAILEDInferShapeContext隔离了推导逻辑与系统状态推导函数只关心输入到输出的变换多硬件适配不同代NPUAscend310、Ascend710等对Shape对齐和Format有不同限制需逐个实现分支Metadef的ComputeNodeInfo统一序列化编译信息运行时自动按硬件代际解析序列化机制将编译期与运行期解耦算子二进制包可以跨代安装上表的对比基于一个中等复杂度算子两个输入一个输出含形状推导的接入场景。不使用Metadef时开发者需要自行维护数据结构的一致性、注册表线程安全、形状推导的分发逻辑等基础设施代码——这些代码和算子的数学逻辑毫无关系但缺了任何一块自定义算子就无法在昇腾NPU的计算图里被识别和调度。Metadef把这些问题全部标准化了开发者只需要用OpRegistrationData填表用InferShapeContext写推导剩下的由Metadef和GE协同完成。一个更直观的数据在Metadef的框架之下从零新定义一个自定义算子的注册代码量大约在30-60行C含头文件包含、命名空间、注册函数和形状推导而同样的功能如果手写所有基础设施保守估计在800-1200行。这意味着接入一个新算子的时间投入从数天级别压缩到小时级别。这不只是快慢的问题——徒手实现时每增加一个算子都意味着更多的测试覆盖、更频繁的缺陷排查、更复杂的ABI兼容维护团队扩张的风险线性增长。而Metadef的标准化方案让所有算子共享一套成熟的基础设施新增算子时不会引入新的基础设施缺陷。结尾Metadef在CANN架构中的定位是基础组件仓它不直接参与算子的数学计算也不负责整张计算图的编译优化但它是两者之间的桥梁。Metadef定义了TensorDesc、Shape、DataType、Format、OpRegistrationData等基础数据结构和接口让算子和计算图能用同一种语言来描述自己。对于一个自定义算子接入昇腾NPU的过程Metadef在构图阶段做了三件事提供数据结构标准TensorDesc等让所有算子有一致的表达方式、提供注册入口OpRegistrationData让系统能发现并识别新算子、提供形状推导机制InferShapeContext让GE能推算完整图结构。这三件事做完后算子的kernel代码才能进入编译和运行时阶段。从工程视角看Metadef的存在让自定义算子接入从从零建造基础设施变成了在标准化底座上填空数据结构定义、注册表管理、形状分发这些重复工作不再需要每个算子重复做一遍。这种基础组件标准化的思路本质上是把系统复杂度集中到框架内部把接口简洁留给上层开发者。https://atomgit.com/cann/metadef
