📚 课程目录第2章旭日算子基础

2. 旭日算子基础

在旭日（Sunrise）异构计算栈中，算子（Operator）是连接上层模型语义与底层硬件指令的最小可调度单元。它既不是单纯的数学函数，也不是简单的内核函数，而是一段带有形状推导、数据类型约束、内存布局声明与后端实现绑定的可执行描述。理解旭日算子的定义与运行机制，是后续兼容性排查的起点——绝大多数“算子不支持”“精度异常”“性能骤降”问题，最终都能回溯到算子的类型、布局或后端绑定上。

一、旭日算子的定义

旭日算子可以形式化描述为一个五元组：

Operator = (OpType, InputSpec, OutputSpec, Attrs, BackendImpl)

OpType      : 算子语义类型，如 Conv2D / MatMul / Softmax
InputSpec   : 输入张量的形状、dtype、layout、量化参数
OutputSpec  : 输出张量的形状、dtype、layout
Attrs       : 属性参数，如 stride、pad、axis、epsilon
BackendImpl : 绑定的后端实现，如 CPU / NPU / GPU / DSP

其中 OpType 决定语义，InputSpec/OutputSpec 决定形状与类型契约，Attrs 决定行为细节，BackendImpl 决定实际执行路径。兼容性排查的核心，就是检查这五个部分在“图编译期—运行时—硬件执行期”是否保持一致。

关键点：旭日算子不是“一个函数”，而是“语义 + 契约 + 实现”的组合体。同一个 OpType 在不同后端、不同 dtype、不同 layout 下，可能是完全不同的实现，兼容性表现也完全不同。

二、架构定位：算子在图中的位置

旭日算子位于计算图的中间层，向上承接模型 IR，向下驱动硬件内核。其架构定位可以用下面的关系图表示：

从图中可以看到，算子层是“编译期契约”与“运行期实现”的交汇点。向上，它接收 IR 的形状与类型信息；向下，它选择并驱动具体硬件内核。兼容性问题往往出现在这个交汇点上：IR 声明的 dtype 与后端内核支持的 dtype 不一致，或者 layout 在传递过程中被隐式转换，都会导致算子执行失败或结果错误。

三、运行机制：从图到指令的四个阶段

旭日算子的运行机制可以分为四个阶段，每个阶段都有明确的输入输出和检查点：

图解析与算子识别：解析模型 IR，将每个节点映射为旭日算子，确定 OpType 与 Attrs。
形状与类型推导：根据 InputSpec 推导 OutputSpec，检查形状是否合法、dtype 是否可传播。
后端绑定与内核选择：根据 BackendImpl 和硬件能力，选择具体内核实现，可能涉及 layout 转换与量化插入。
执行与回写：调用内核执行，将结果写回输出张量，并记录执行日志与性能计数。

其中第 2、3 阶段是兼容性排查的重点。形状推导失败通常表现为“shape mismatch”，后端绑定失败通常表现为“unsupported op”或“fallback to CPU”。

四、常见类型与典型应用场景

旭日算子按语义可分为以下几类，每类在兼容性排查中的关注点不同：

算子类别	典型 OpType	关键属性	常见兼容性风险
卷积类	Conv2D、DepthwiseConv	stride、pad、dilation、group	NPU 不支持 dilation>1；group 数不匹配
矩阵类	MatMul、BatchMatMul	transpose_a/b、alpha/beta	dtype 混合（fp16×fp32）导致回退
归一化类	Softmax、LayerNorm、BatchNorm	axis、epsilon、momentum	axis 非最后一维时后端不支持
激活类	ReLU、GELU、Sigmoid、Tanh	approximate、alpha	GELU 近似模式与硬件查表不一致
张量操作类	Reshape、Transpose、Concat、Slice	shape、perm、axis	layout 隐式转换引发额外拷贝
量化类	Quantize、Dequantize、QConv	scale、zero_point、bit_width	per-channel 与 per-tensor 不匹配

典型应用场景包括：移动端 NPU 推理中的卷积与激活融合、云端 GPU 上的大矩阵乘、边缘 DSP 上的量化卷积、以及 CPU 上的兜底执行。不同场景对算子的 dtype、layout、量化方式要求不同，兼容性排查必须结合具体场景。

五、案例与误区复盘

案例：某模型在 NPU 上推理时，Softmax 算子被回退到 CPU，导致整体时延增加 40%。排查发现：模型 IR 中 Softmax 的 axis=1，而 NPU 内核仅支持 axis=-1。解决方案是在图优化阶段插入 Transpose，将 axis 调整为最后一维，再执行 Softmax，最后转回原布局。

常见误区：

认为“算子支持”就是“所有属性组合都支持”——实际上后端往往只支持部分属性组合。
忽略 dtype 传播规则，导致中间张量被隐式提升为 fp32，触发回退。
只看 OpType 不看 layout，导致 Transpose 被插入到热点路径上，性能骤降。
把量化参数当作普通属性，忽略 per-channel 与 per-tensor 的差异。

复盘时建议按“OpType → Spec → Attrs → BackendImpl”的顺序逐项核对，并保留图编译期的算子绑定日志。只有把算子的五元组与后端能力表对齐，才能快速定位兼容性问题的根因。