前言任何一个深度学习框架要将计算图映射到昇腾 NPU 上执行中间都必须经历一个从高层语义到低层执行的翻译过程。昇腾 昇腾NPU上的CANN 的 Graph EngineGE承担了这个翻译角色而 MetaDef 正是 GE 赖以运转的元定义基础设施。如果把 GE 想象成一条编译流水线那么 MetaDef 就是这条流水线上的零件目录——它告诉编译器每个算子长什么样、需要什么样的输入输出格式、在图优化阶段可以施加哪些变换。没有 MetaDefGE 就无从知道一个 Add 算子的输入张量支持哪些 Format也无法在编译期决定是否将相邻的 MatMul 和 Add 融合为单个算子。MetaDef 这个名字本身揭示了它的职责边界Meta 代表元信息定义Def 代表 Definition。它并不直接执行计算而是为计算执行提供结构化描述。在 CANN 全面开源之后MetaDef 的内部实现变得可追溯可审计这对于需要深度定制算子库或自行编写图优化 Pass 的工程师而言是一个关键的研究入口。本文将以深度实践的视角从算子注册、图定义、格式推导、Pass 注册与执行四个维度剖析 MetaDef 的架构设计及其在昇腾 NPU 计算流水线中的实际作用。所有代码段均来源于社区开源仓库的真实结构经过精简以便聚焦核心逻辑。MetaDef 在 CANN 编译层的位置CANN 的计算编译层由 Graph CompilerGE、BiSheng 编译器和 ATC 编译器共同组成。其中 GE 是前端图编译的核心引擎负责接收来自 PyTorch、TensorFlow 等训练框架的计算图经过一系列优化 Pass 后交给 BiSheng 或 ATC 进行后端代码生成。MetaDef 在这套流程中扮演信息中枢的角色——GE 的每一个优化决策都建立在 MetaDef 提供的元信息之上。从依赖关系看GE 直接依赖 MetaDef而算子仓库ops-math、ops-nn、ops-tensor 等通过 opbase 间接依赖 MetaDef 的注册接口。Runtime 在执行阶段也会查询 MetaDef 中记录的算子原型信息用于校验输入输出的合法性。这种三方共同依赖的设计使得 MetaDef 成为编译层和算子层之间的唯一契约点。值得强调的是MetaDef 并不是一个独立运行的进程或服务。它以静态库和头文件的形式被 GE、算子库和运行时链接在编译期和加载期分别提供元信息查询能力。这种静态链接的设计避免了运行时的额外进程间通信开销对于需要频繁查询算子属性的编译流水线来说至关重要。算子原型注册Operator 的结构化描述MetaDef 最基础的能力是算子原型注册。每一个算子在进入 CANN 计算流水线之前必须先在 MetaDef 中注册其原型信息——包括算子名称、输入输出张量的数量与类型、支持的数据格式Format以及属性参数列表。注册过程通常发生在算子库初始化阶段。以 ops-math 仓库中的加法算子为例其注册逻辑会通过 MetaDef 提供的宏接口完成声明。注册信息的核心数据结构是 OperatorProto它描述了算子的接口签名。// 算子原型注册示例简化后的核心结构IMPLEMENT_OPERATOR(Add).Input(x1,Tensor,第一个输入张量).Input(x2,Tensor,第二个输入张量).Output(y,Tensor,输出张量).Attr(dtype,DataType,计算时的数据类型).SetTypeInfer(AddInferShape)// WHY: 形状推导函数让 GE 在编译期推断输出维度避免运行时才发现维度不匹配.SetFormatInfer(AddInferFormat)// WHY: 格式推导函数决定输出使用 ND 或 NC1HWC0直接影响后续算子能否融合.SetSupportFormat({FORMAT_ND,FORMAT_NC1HWC0,FORMAT_NCHW});这段代码展示了一个典型算子注册的骨架。Input 和 Output 宏声明了算子的张量端口Attr 定义了可配置的属性参数。SetTypeInfer 和 SetFormatInfer 分别绑定了形状推导和格式推导函数——这两个函数是 GE 在图优化阶段最频繁调用的元信息接口。形状推导函数的逻辑相对直观根据输入张量的 shape 和属性参数计算出输出张量的 shape。而格式推导函数的设计则要复杂得多因为它需要考虑昇腾达芬奇架构中不同计算单元对数据排布的要求。Cube 单元偏好 NC1HWC0 五维格式Vector 单元偏好 ND 四维格式同一个算子在不同执行路径上可能需要不同的格式输出。MetaDef 通过 AllowExplicitFormat 机制允许算子开发者标注本算子支持哪些格式转换从而让 GE 的格式推导 Pass 有足够的信息做出决策。在实际工程中算子注册的完整性直接影响 GE 的编译成功率。如果某个自定义算子遗漏了格式推导函数的注册GE 在遇到该算子时就无法自动选择合适的格式转换策略最终导致编译失败或运行时格式不匹配错误。这是自定义算子开发中最常见的踩坑点之一。图定义与中间表示Graph、Tensor 和 Format 的协同算子注册完成后MetaDef 提供的另一组核心能力是图定义与中间表示。在 GE 的编译流水线中计算图由 Graph 对象表示图中的节点是 Operator边是 Tensor。这三者构成了 MetaDef IR中间表示的基本三角关系。Graph 对象本身并不存储具体的张量数据它存储的是计算拓扑和类型信息。当 GE 从训练框架接收到一张计算图时首先会将其转换为一个 MetaDef 格式的 Graph 对象。转换过程中GE 会查询 MetaDef 中已注册的算子原型校验每个节点的输入输出是否与原型定义一致。Tensor 在 MetaDef IR 中是一个轻量级的描述对象包含 shape、dtype、format 和 origin_format 四个关键字段。其中 shape 描述张量的维度信息dtype 描述数据类型format 描述当前的数据排布格式origin_format 记录原始的框架侧格式。这种四字段设计的原因在于训练框架通常使用 NCHW 或 NHWC 等通用格式而昇腾 NPU 内部为了适配达芬奇架构的 Cube 和 Vector 单元会使用 NC1HWC0 等硬件友好格式。origin_format 字段确保在需要将张量数据回传给框架侧时能够正确还原格式。// TensorDesc 的核心字段简化描述structTensorDesc{Shape shape;// 张量形状如 [1, 3, 224, 224]DataType dtype;// 数据类型如 DT_FLOAT16Format format;// 当前数据排布如 FORMAT_NC1HWC0Format origin_format;// 原始框架侧格式如 FORMAT_NCHW};// WHY: 保存 origin_format 是因为昇腾 NPU 内部会将 NCHW 自动拆分重排为 NC1HWC0// 但当 GE 需要将部分结果反馈给 PyTorch 时必须知道原始格式才能正确还原// 如果丢失这个信息就会出现推理结果维度正确但数值完全错乱的隐蔽 bugFormat 转换在 MetaDef 中不是自动发生的而是由 GE 的 FormatTransfer 机制驱动的。FormatTransfer 注册了一系列格式转换规则每条规则描述了从格式 A 到格式 B 的转换条件和转换算法。GE 在图优化阶段遍历 Graph 中的每条边检查上下游算子的格式要求是否匹配。如果不匹配就在两个算子之间插入一个 TransData 节点执行格式转换。但频繁插入 TransData 节点会带来性能问题——每次格式转换都需要显存读写在数据量大的场景下会成为瓶颈。因此 MetaDef 的格式推导设计强调格式传播而非格式转换尽可能让算子直接支持上下游的格式减少 TransData 节点的插入。这就是前面提到的 SetSupportFormat 和 SetFormatInfer 的工程价值所在。图优化 Pass 注册与执行引擎MetaDef 的第三大能力模块是图优化 Pass 的注册与执行框架。GE 的图编译过程本质上是多轮 Pass 依次作用于计算图的过程——每一轮 Pass 对图施加某种优化变换最终生成适合后端执行的优化图。MetaDef 将每个 Pass 抽象为一个独立对象通过注册机制让 GE 的 PassManager 统一调度。一个 Pass 的注册信息包含名称、执行阶段、依赖关系和作用范围。执行阶段决定了该 Pass 在编译流水线中的位置依赖关系决定了 Pass 之间的执行顺序作用范围决定了该 Pass 是全局作用还是仅作用于特定子图。Pass 的执行遵循注册-匹配-应用三段式流程。注册阶段Pass 向 MetaDef 声明自己的触发条件。匹配阶段PassManager 在当前图上搜索满足触发条件的子图模式。应用阶段匹配成功后 Pass 对子图执行变换操作并更新 Graph 对象。以常量折叠 Pass 为例该 Pass 在图的初始构建阶段执行用于将编译期可确定的常量表达式提前计算。当一个 Add 节点的两个输入都是常量节点时常量折叠 Pass 就会将其替换为一个单常量节点消除运行时的无效计算。// Pass 注册与匹配的核心逻辑简化classConstantFoldPass:publicPassBase{public:StatusRun(NodePtrnode)override{// 检查当前节点是否为可折叠的运算if(!IsFoldable(node)){returnSUCCESS;// WHY: 逐节点遍历图中所有节点不可折叠的直接跳过// 而非一次性收集所有可折叠节点再处理// 这样可以尽早释放不需要继续处理的节点引用}// 提取常量输入并执行计算TensorPtr resultComputeConstFold(node);// 用常量节点替换原来的运算节点ReplaceNodeWithConst(node,result);// WHY: 直接在原 Graph 上执行节点替换而非构建新图// 因为常量折叠是高频 Pass每张图可能触发数十次// 构建-拷贝-替换的开销远大于原地修改returnSUCCESS;}};REGISTER_PASS(ConstantFoldPass).SetStage(PASS_STAGE_BEFORE_OPTIMIZE).SetDepends({});// WHY: 空依赖意味着该 Pass 可以在流水线最早阶段执行// 常量折叠的结果可能触发后续更多优化机会// 放在越前面后续 Pass 的优化空间越大Pass 之间的执行顺序并不是完全由开发者手动指定的。MetaDef 的 PassManager 实现了一套基于依赖拓扑排序的调度算法。每个 Pass 声明自己的前置依赖 PassPassManager 构建依赖图后进行拓扑排序自动确定执行顺序。这种设计的优势在于新增一个 Pass 时只需声明它依赖哪些已有 Pass无需手动修改全局执行序列降低了多 Pass 协作开发的复杂度。在昇腾 NPU 的实际推理场景中Pass 的作用效果非常显著。一个未经优化的计算图可能包含数百个 TransData 节点、冗余的形状计算节点和不必要的内存拷贝操作。经过格式对齐、算子融合、内存优化等多轮 Pass 之后最终图的结构会大幅精简可执行的算子数量通常能减少一个数量级。这种编译期优化将运行时的计算和内存压力大幅前移是昇腾 NPU 能够保持高推理吞吐量的关键因素之一。格式推导的工程实践格式推导是 MetaDef 框架中最具工程复杂度的模块。它需要同时满足三个约束上游算子的输出格式与下游算子的输入格式兼容、格式转换的代价最小化、以及最终的格式选择对后续算子融合不会造成阻碍。GE 在格式推导阶段会为每个算子维护一个候选格式集合。这个集合来源于算子注册时声明的 SupportFormat。推导算法从图的输出节点开始逆向遍历到输入节点在每条边上尝试寻找上下游格式的交集。如果交集为空则需要引入 FormatTransfer 进行格式转换如果交集包含多个格式则需要通过代价模型选择最优格式。代价模型的输入参数包括格式转换的计算开销读取和重排数据的操作数、格式转换的显存占用中间缓冲区大小、以及该格式对后续算子融合的影响。综合这三个维度打分后代价模型选择得分最低的格式组合作为最终方案。// 格式推导的核心判断逻辑简化StatusInferFormatForEdge(EdgePtr edge){TensorDesc src_descedge-GetSrcTensorDesc();TensorDesc dst_descedge-GetDstTensorDesc();// 尝试寻找上下游都支持的格式交集std::vectorFormatintersectionFindFormatIntersection(src_desc.supported_formats,dst_desc.supported_formats);if(intersection.empty()){// WHY: 当格式完全不兼容时必须插入 TransData 节点// 但记录这条边的转换代价供全局优化参考InsertTransDataNode(edge,src_desc.format,dst_desc.format);returnSUCCESS;}// 交集存在时选择对后续融合最有利的格式Format optimalSelectOptimalFormat(intersection,edge);// WHY: 不直接选第一个交集格式而是通过代价模型评估// 因为 NC1HWC0 虽然对 Cube 算子友好但可能导致相邻的// Vector 算子需要额外的格式回退开销// 全局最优不一定等于局部格式兼容src_desc.formatoptimal;dst_desc.formatoptimal;edge-UpdateTensorDesc(src_desc,dst_desc);returnSUCCESS;}格式推导的一个典型踩坑场景是格式死锁当算子 A 只输出 NC1HWC0算子 B 只接受 ND而算子 C 只接受 NC1HWC0且 B 位于 A 和 C 之间时无论 B 选择哪种中间格式都会导致至少一次格式转换。在这种情况下MetaDef 的代价模型需要权衡在 A-B 之间转换还是在 B-C 之间转换哪个代价更低而不是简单地报错终止编译。对于需要自行开发图优化 Pass 的工程师来说理解格式推导的机制尤为重要。自定义 Pass 在修改图结构时必须确保修改后的格式约束仍然可满足。否则即使图拓扑正确也会在后续的格式推导阶段失败。MetaDef 与算子库的协同工作机制MetaDef 和各算子仓库之间的协同关系可以概括为注册-查询-执行三个阶段。注册阶段发生在算子库加载时每个算子通过 opbase 提供的注册接口向 MetaDef 注册原型信息。查询阶段发生在 GE 编译期GE 通过 MetaDef 的查询接口获取算子属性、格式支持和推导规则。执行阶段发生在运行时Runtime 根据 MetaDef 中记录的算子原型校验实际输入的合法性。opbase 作为所有算子仓库的基础依赖封装了 MetaDef 的注册接口。算子开发者通常不需要直接调用 MetaDef 的底层 API而是通过 opbase 提供的宏和辅助函数完成注册。这种分层设计的目的是降低算子开发者的心智负担——他们只需要关注算子的计算逻辑和接口声明而不需要理解 MetaDef 内部的注册数据结构。在 CANN 全面开源的背景下MetaDef 的内部实现已经可以在社区仓库中直接查阅。这意味着工程师不仅可以了解算子的注册方式还可以深入理解 GE 的 Pass 调度机制和格式推导算法的实现细节为深度定制编译流水线提供了完整的参考路径。效率对比基于 MetaDef 的图优化效果为了直观展示 MetaDef 驱动的图优化对昇腾 NPU 推理效率的影响下面对比了启用与未启用 MetaDef 图优化 Pass 时的典型推理表现。测试场景为包含 MatMul、Add、ReLU、LayerNorm 等多个算子的 Transformer 编码器模块在 Ascend 910 上执行推理任务。数据为概括性描述反映典型场景下的量级差异。指标使用前禁用图优化使用后启用图优化可执行算子数量数百个含大量 TransData 和冗余节点数十个经融合和消除后精简格式转换节点数量占总节点数约三成以上通常可完全消除或仅保留极少数必要转换编译耗时较短跳过大部分优化适中多轮 Pass 处理带来额外编译开销推理延迟较高运行时承担大量格式转换和冗余计算显著降低编译期优化消除了运行时瓶颈显存占用较高中间结果全部保留有效降低算子融合减少了中间缓冲区需求算子融合覆盖度无融合多组算子融合如 MatMulAddReLU从表格可以看出图优化的核心收益并非来自单个算子的计算加速而是来自图结构层面的精简。减少 TransData 节点消除了昂贵的显存重排操作算子融合减少了中间结果的读写次数这两者共同将推理延迟和显存占用压缩到接近理论下限。MetaDef 与 GE 的协作机制MetaDef 作为 GE 和算子库之间的中间层其协作机制值得深入理解。当用户通过 MindSpore 或 PyTorch 构建一个计算图时整个流程是这样的前端框架将用户代码转换为计算图 IR这个 IR 中的每个节点都是一个算子调用。MetaDef 接收这个 IR并为每个算子节点查找注册表中的原型信息。原型信息包括算子的输入输出描述、属性定义、支持的 Format 和 DataType 等。GE 从 MetaDef 获取原型信息后开始执行图优化 Pass。每个 Pass 都在 MetaDef 注册过GE 按照注册的优先级依次调用。优化完成后GE 根据最终的计算图调用算子库中的实现。这个流程中 MetaDef 扮演的是信息中介的角色。它不执行任何计算也不做优化决策只提供算子元信息供 GE 查询。这种设计的好处是解耦——算子库可以独立更新只要通过 MetaDef 注册的信息不变GE 的优化逻辑就不需要修改。仓库地址https://atomgit.com/cann/metadef