想象一座属于 AI 世界的超级港口。每天，来自 PyTorch 工厂的蓝色货箱、来自 TensorFlow 工厂的粉色货箱、来自 Paddle 工厂的绿色货箱堆满了码头，却谁也搬不动谁的货——每个工厂都有自己的装卸工具和包装规格。直到有一天，运输联盟发布了一本《标准集装箱手册》：无论哪家工厂的产物，统一拆散、重新装进规格一致的集装箱，贴上统一的标签。从此，任何港口、任何龙门吊，都能装卸这批货。这本手册，就是 ONNX 的算子标准（Operator Standard）。本文就带你从零看懂：什么是一个算子、算子标准怎么分版本、分几大类、带哪些约束，又如何把大模型的“散货”装进标准集装箱，在真实项目里顺利通关。

岗位关联

掌握 ONNX 算子标准，意味着你能把任何框架训练的模型稳稳搬上任意推理引擎——这是部署工程师与算法工程师之间最重要的“通用语言”。

目录
  1. 可视化演示
  2. 算子基本概念
  3. 算子集版本
  4. 算子分类清单
  5. 属性与类型约束
  6. 自定义算子
  7. 转换实践
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

三步展示ONNX算子标准：注册/解析/执行三阶段工作原理、六大类算子分类体系（张量/卷积/神经/控制流等）、以及PyTorch→ONNX→TensorRT跨框架互操作部署。

本节配有交互动效（进入视口后自动加载，约 3KB）。

算子工作原理三阶段 注册：算子注册表登记OpType/版本/Schema 解析：模型图算子按Schema解析 执行：调用对应Kernel实现 注册→解析→执行 推理引擎按阶段调度算子。

算子基本概念

老码头上的工人都懂一条规矩：不管哪家工厂运来的货，进了码头必须先拆散、装进统一的集装箱。一节标准的集装箱，就是物流世界最小、最可靠的搬运单元。AI 世界里也有这样一节“集装箱”——算子（Operator）。整个神经网络模型，本质上就是一节节标准箱按顺序连接起来的长队。

在神经网络中，算子指的就是一个标准化了的基本运算单元：把输入张量（Tensor，你可以理解为多维数组）经过某种确定的运算，得到输出张量。PyTorch 里的加法、TensorFlow 里的卷积，到了 ONNX 这儿都被编译成同一种标准箱体，贴上统一的运算名称。这样一来，模型就不再属于某个特定框架，而是一张由算子节点组成的“货物清单”。

这张清单在数学上是一张有向图：节点是算子，边是张量流动的方向，称为计算图（Computation Graph）。整个模型可以写成：

所以当你打开一个 .onnx 文件时，看到的不是某个框架的私有格式，而是一排排整齐的标准集装箱，每个箱体上清清楚楚地印着运算类型、输入输出、属性参数。理解算子，就理解了整个 ONNX 世界的核心地基。

G=(V,E)G = (V, E)
G 表示计算图，V 是所有算子节点的集合，E 是张量沿着边流动的集合。
  1. G 代表整体计算图G 是整张图的名字，相当于码头的“总装图纸”，圈定了集装箱如何拼接。
    GG
  2. V 是算子节点集合图中每个算子（如 Conv、Relu）都是 V 里的一个元素，一个节点就是一节标准集装箱。
    V={v1,v2,…,vn}V = \{v_1, v_2, \dots, v_n\}
  3. E 是张量流动边集合边表示数据从哪个算子的输出流向下一个算子的输入，是箱与箱之间的“传送带”。
    E={(vi,vj)∣vi,vj∈V}E = \{(v_i, v_j) \mid v_i, v_j \in V\}

算子集版本

集装箱标准自己也在不断修订。早年标准箱只有 20 英尺一个型号，后来推出了 40 英尺高柜、冷藏箱专用接口……每一版修订都有一个版次号。ONNX 里也有一套这样的版次体系，叫做 opset（Operator Set，算子集版本）。它规定了“这本标准手册印到了第几版”。

每个 ONNX 模型的头部都带着一行“标准版本声明”——opset_import，形如 {domain: "", version: 19}。其中空字符串的 domain 代表默认的 ai.onnx 算子域；version 告诉所有码头（推理引擎）：我这批货是按第 19 版标准装箱的。推理引擎读到这里，就知道该用哪一辈的龙门吊来理解箱子上的标签。

版本判断的规则也很简单：模型声明的版本号 v_model，必须不低于某个算子被引入规范时的最低版本 v_op，才能保证这个算子可以被正常搬运：

所以做模型转换时，把 opset 版本开到 19、21 不是越高越好，而是要对照目标推理引擎的“龙门吊承重上限”——选太高，箱子进不了港；选太低，新箱型又装不下。找到“算子所需最低版本”和“引擎支持最高版本”的交集，才是老练的装箱工程师。

vmodel≥vopv_{\text{model}} \ge v_{\text{op}}
向后兼容：新版本手册不会删除旧版算子的定义，模型版本越高，可用的算子越多。
  1. v_model 是模型声明版本即 opset_import 里的 version 字段，表示这箱货是按第几版标准封装的。
    vmodelv_{\text{model}}
  2. v_op 是算子最低引入版本每个算子从某个版本开始才出现在规范里，比如某个新算子在 v18 才加入，那 v_op 就是 18。
    vopv_{\text{op}}
  3. 不等式表示兼容条件只要模型版本不小于算子要求的最低版本，就能正常使用这个算子，标准永远向下兼容。
    vmodel≥vopv_{\text{model}} \ge v_{\text{op}}

算子分类清单

集装箱公司都会发一本《箱型目录》：普通干货箱、冷藏箱、开顶箱、罐式箱……分门别类，一目了然。ONNX 的算子规范同样是一本目录册，按用途和归属划成几个大区。每一个算子，都能在这本目录册里找到自己的编号和说明。

默认域 ai.onnx 收录了神经网络最常用的算子箱型：Conv（卷积）、Relu（激活函数）、MatMul（矩阵乘法）、Softmax（归一化）等，数量超过 170 个。另有 ai.onnx.ml 域存放传统机器学习算子（如 SVM、决策树相关运算），ai.onnx.training 域用于训练相关算子。此外还有大量基础数学运算与张量操作算子，构成模型的“通用工具箱”——无论哪家工厂生产的神经网络，都能拆解成这些标准件。

以最典型的卷积（Convolution）为例，它的搬运规则可以写成：

正因为这本目录册足够齐全，无论模型来自 PyTorch 还是 TensorFlow，最终都能拆成目录里的标准箱重新装运。万一模型里出现目录册外的“非标件”，就轮到我们后面要讲的自定义算子出场了。

y[n,c,h,w]=∑c′∑kh∑kwx[n,c′,h+kh,w+kw]⋅k[c,c′,kh,kw]+b[c]y[n, c, h, w] = \displaystyle\sum_{c'} \displaystyle\sum_{kh} \displaystyle\sum_{kw} x[n, c', h + kh, w + kw] \cdot k[c, c', kh, kw] + b[c]
卷积算子是视觉模型的“重箱搬运工”：用一个小窗口扫过大张量，逐位相乘并累加，提取局部特征。
  1. y 是输出张量y 表示卷积运算的结果，索引为 n（样本）、c（通道）、h 和 w（高宽坐标）。
    y[n,c,h,w]y[n, c, h, w]
  2. 对输入通道求和把输入的所有通道 c' 累加混合，相当于把各层货箱里的同类货物合并。
    ∑c′\displaystyle\sum_{c'}
  3. 滑窗相乘累加卷积核 k 在输入张量上滑动，对应位置相乘后累加，是“逐位搬运验货”的过程。
    x[n,c′,h+kh,w+kw]⋅k[c,c′,kh,kw]x[n, c', h + kh, w + kw] \cdot k[c, c', kh, kw]
  4. 加上偏置项最后为每个输出通道加上一个偏置 b，相当于给每箱货贴一个固定附加费。
    +  b[c]+ \; b[c]

属性与类型约束

集装箱可不只是一个空铁壳。每个箱子上都印着长、宽、高、限重，以及“允许装什么类型的货物”。ONNX 算子的“箱体说明”同样由两部分组成：属性（attributes）和类型约束（type constraints）。两者共同决定了这个算子到底能怎么用。

属性是算子运算时需要的附加参数，例如卷积的 kernel_shape（卷积核尺寸）、strides（步长）、dilations（膨胀系数）。它们属于编译期的“箱体规格”，在模型转换时被直接写进节点里，不会随输入数据变化。ONNX 为属性规定了明确的数据类型清单：FLOAT、INT、STRING、TENSOR、GRAPH，以及对应的复数形式——属性类型是写死在规范里的，不允许随意发明。

类型约束则限定了算子的输入、输出张量允许的数据类型。例如 Conv 算子只接受浮点系列，这个约束用集合可以表示为：

这一条约束正是很多转换失败的根源——你的模型里喂了一个 int8 的输入，可标准箱上明明白白写着“仅限浮点”，龙门吊自然拒绝搬运。同时，类型约束还会参与形状推断（Shape Inference）：推理引擎根据输入的形状和类型，自动推断输出张量的形状，减少调试成本。

T∈{float16,float,double}T \in \{\text{float16}, \text{float}, \text{double}\}
类型约束给算子装上“限装货物类型”的闸门，防止喂入不兼容的数据类型导致运算失控。
  1. T 代表张量数据类型T 是一个类型变量，实际会被具体的数据类型（如 float32）代入。
    TT
  2. ∈ 表示归属关系读作“属于”，表示 T 必须落在右边集合的范围内，否则不予通过。
    ∈\in
  3. 集合列出允许的类型float16、float、double 是三种浮点精度，共同构成 Conv 算子的白名单。
    {float16,float,double}\{\text{float16}, \text{float}, \text{double}\}

自定义算子

标准集装箱虽然齐全，但总有些特殊货物，比如需要全程冷链的疫苗，普通干货箱根本装不了。这时候就得动用特种箱，并且要额外备案审批。ONNX 同样允许用户定义标准目录外的算子，这就是自定义算子（Custom Operator）。

自定义算子必须挂在一个独立的自定义域（domain）下，常见格式如 com.example。它与 ONNX 默认域 ai.onnx 平级，等于给特种箱盖了一个“特殊箱型备案章”。在代码里，一个自定义算子节点通常写成：

导出时同样需要“亮明身份”：在 torch.onnx.export 里通过 custom_opsets={"com.example": 1} 声明自定义域的版本号，否则导出器无法识别这个陌生符号的来路。到了推理端，运行环境必须注册对应的自定义算子实现（通常以共享库形式加载），否则整个模型都会在载入时报错。特种集装箱虽好，代价是只有“认得出特种箱”的码头才能装卸。

y=MyCustomOp(x;α)y = \text{MyCustomOp}(x; \alpha)
自定义算子的输出 y、输入 x 与属性 α 共同构成一个完整算子，domain 和 op_type 联合标识它的唯一身份。
  1. y 是输出张量自定义算子执行后产出的结果，格式必须符合模型的类型定义。
    yy
  2. x 是输入张量喂给自定义算子的数据，可以是一个或多个输入。
    xx
  3. α 是算子属性在构造节点时传入的附加参数，例如阈值、缩放系数等。
    α\alpha

转换实践

现实中，把模型转成 ONNX 就像一条集装箱流水线。PyTorch 模型用 torch.onnx.export 导出，TensorFlow 模型用 tf2onnx 导出；导出完成后，先用 onnx-simplifier 简化多余的节点（相当于把散货压实、缠膜），再交给 onnx.checker 和 ONNX Runtime 做精度对齐验证——每一道工序都在确保箱子经得起远程运输。

精度验证的核心指标是最大绝对误差（MAE），它衡量“原厂货”和“转箱后”的最大差距不能超过可接受范围：

实战中常见的卡关有三种：某个算子要新版目录才支持（opset 太低）、动态维度没有在导出时显式声明（箱子尺寸含糊）、自定义前向逻辑无法映射为标准算子（非标件超目录）。逐个排查就好比查货单——对不上就换箱型，或者改走自定义域。整个流程走通后，模型就真正成了标准集装箱：从 CPU、GPU 到 NPU，任何认标准的码头都能顺利装卸。

MAE=max⁡i∣yonnx[i]−yorig[i]∣\text{MAE} = \max_i |y_{\text{onnx}}[i] - y_{\text{orig}}[i]|
MAE 对比 ONNX 输出与原始框架输出，逐元素取差的绝对值后找最大值，是部署前的“过磅检查”。
  1. y_onnx 是 ONNX 引擎输出同一批输入喂给 ONNX Runtime 后得到的推理结果数组。
    yonnx[i]y_{\text{onnx}}[i]
  2. y_orig 是原始框架输出原始 PyTorch 或 TensorFlow 模型跑出的结果，作为参考基准。
    yorig[i]y_{\text{orig}}[i]
  3. 取最大偏差对每个位置的差值取绝对值后取最大值，确保没有任何一个位置“跑偏”得离谱。
    max⁡i∣⋅∣\max_i |\cdot|

AI 应用场景

跨框架模型部署

阶段：模型部署与推理

解决的问题：传统方式下，PyTorch 训练出的模型只能依赖 LibTorch 推理，TensorRT、OpenVINO 等高性能引擎一概不认；重新训练又代价高昂。利用 ONNX 算子标准，把模型完整翻译成标准算子图后，就能一次转换、多处部署。

具体案例：某自动驾驶公司训练好语义分割模型后，先通过 torch.onnx.export 导出为 ONNX，再用 TensorRT 加载并做算子融合优化，推理延迟从 25ms 降到 8ms。整个过程中没有改动一行训练代码，只依赖算子标准的通用性。

模型算子兼容性审计

阶段：模型转换与调试

解决的问题：模型导出 ONNX 后，部分算子被目标引擎拒绝，报错信息难以定位。通过 ONNX 算子清单逐一审计，可以快速找出“哪个箱子不属于目标港口”。

具体案例：平台工程师用 Netron 打开导出的 model.onnx，逐个核对算子类型，发现 Shape 算子输出了动态维度导致 TensorRT 拒绝编译。通过固定输入尺寸并对导出的动态轴做显式声明，问题顺利解决。

端侧推理算子融合优化

阶段：推理性能优化

解决的问题：移动端 CPU 推理速度慢，瓶颈往往在于细碎算子频繁调度。ONNX Runtime 的对图优化会在标准算子图上自动融合相邻算子的计算，比如把 Conv、BatchNorm、Relu 合成一个融合算子，大幅减少调度开销。

具体案例：某 App 的图像分类模型在手机上 CPU 推理耗时 120ms，开启图优化并配合 INT8 量化后降至 35ms，精度损失控制在 1% 以内，成功达到产品上线指标。

Python 演示

python37 行
import onnxfrom onnx import helper, TensorProtofrom collections import Counter  def build_simple_model():    # 定义一个计算图: X -> Add(B) -> Relu -> Y    x_info = helper.make_tensor_value_info('X', TensorProto.FLOAT, [None, 4])    y_info = helper.make_tensor_value_info('Y', TensorProto.FLOAT, [None, 4])    bias = helper.make_tensor('B', TensorProto.FLOAT, [4], [1.0, 2.0, 3.0, 4.0])    add_node = helper.make_node('Add', ['X', 'B'], ['sum'], name='add_op')    relu_node = helper.make_node('Relu', ['sum'], ['Y'], name='relu_op')    graph = helper.make_graph(        [add_node, relu_node], 'tiny_model', [x_info], [y_info], initializer=[bias]    )    model = helper.make_model(        graph, opset_imports=[helper.make_opsetid('', 19)]    )    return model  def main():    model = build_simple_model()    onnx.checker.check_model(model)    print('opset:', [(o.domain, o.version) for o in model.opset_import])     ops_count = Counter(n.op_type for n in model.graph.node)    print('算子清单:', dict(ops_count))     onnx.save(model, 'tiny_model.onnx')    loaded = onnx.load('tiny_model.onnx')    for node in loaded.graph.node:        print(node.op_type, '->', list(node.output))  if __name__ == '__main__':    main()
目的：演示如何用 onnx 官方 Python API 手工搭建一个包含 Add 与 Relu 两个算子的标准计算图，并完成规范校验、算子审计与模型保存。
  1. helper.make_tensor_value_info('X', TensorProto.FLOAT, [None, 4])声明输入张量 X 的名称、类型和形状，None 表示动态维度。
  2. helper.make_tensor('B', TensorProto.FLOAT, [4], [1.0, 2.0, 3.0, 4.0])创建常量张量 B，作为 Add 算子的第二个输入（权重偏置）。
  3. helper.make_node('Add', ['X', 'B'], ['sum'], name='add_op')创建 Add 算子节点，输入是 X 和 B，输出是中间张量 sum。
  4. helper.make_node('Relu', ['sum'], ['Y'], name='relu_op')创建 Relu 算子节点，把 sum 逐元素取正后输出到 Y。
  5. helper.make_graph([...], 'tiny_model', [x_info], [y_info], initializer=[bias])把节点列表、输入输出信息组装成计算图，bias 作为图的初始权重。
  6. helper.make_model(graph, opset_imports=[helper.make_opsetid('', 19)])用空字符串 domain 声明默认算子域，并声明 opset 版本为 19。
  7. onnx.checker.check_model(model)按照 ONNX 规范校验模型结构，相当于集装箱出港前的安检。
  8. Counter(n.op_type for n in model.graph.node)遍历图中所有算子节点，统计每个 op_type 出现的次数。

常见误区

误区我以为 ONNX 就是一种 `.onnx` 文件后缀的存储格式，跟 JSON 一样只是序列化容器，和算子标准没关系。

正解ONNX（Open Neural Network Exchange）本质是一套规范，包含 IR 中间表示、算子标准、类型系统等；.onnx 文件只是这套规范的序列化产物。就像集装箱既定义了箱体尺寸标准，也对应码头上的实体箱子，两者不可混为一谈。真正让模型互通的是“算子长什么样”的那套标准。

为何常见：日常接触最多的是 .onnx 文件，很容易把它单纯理解成一种文件格式，忽略了文件背后定义算子行为的规范层。

误区导出模型时把 opset 开到最高版本，比如 21，这样新算子都能用，部署肯定也没问题。

正解opset 越高，模型要求的标准越新，但目标推理引擎未必跟得上。就像港口龙门吊是按老版标准设计的，新版高柜反而卸不了。正确做法是找到“算子所需最低版本”与“引擎支持最高版本”的交集，而不是一味追新。

为何常见：现代深度学习框架导出时默认推荐较新的 opset，让人产生“版本越新越先进”的直觉，忽略了部署环节的兼容性才是关键。

误区模型转成 ONNX 格式，就等于拿到了万能通行证，任何设备、任何框架都能直接加载运行。

正解ONNX 是“交换标准”，不是“万能执行层”。TensorRT、OpenVINO、MNN 等目标引擎只实现了算子集合的子集，且各有优化取舍。包含自定义算子或某些高阶算子时，仍需做适配甚至改写。标准集装箱可以全球转运，但前提是目的港得配了对应的龙门吊。

为何常见：被“一次转换、到处推理”的宣传语误导，忽略了“算子标准”和“算子实现”是完全不同的两件事。

误区PyTorch 导出 ONNX 时报 Unsupported operator，第一反应就是自己模型写错了，于是疯狂改网络结构。

正解导出失败大多源于“标准不匹配”：算子未收录进当前 opset、动态控制流未被静态化、自定义前向逻辑不被跟踪器支持。这些不是逻辑错误，而是货型不属于标准箱目录。正确做法是检查 opset 版本、算子支持和导出参数，而不是盲目改模型。

为何常见：报错集中在导出器里，容易让人以为是代码问题；实际上导出是“语义翻译”而非“代码执行”，很多报错发生在翻译边界。

面试题

Q1. 以下对 ONNX 算子最准确的理解是？

单选题 · easy

  • A.算子就是神经网络层
  • B.算子是一个程序文件
  • C.算子是标准化运算单元← 正确答案
  • D.算子是模型训练数据集

答案：C。算子是 ONNX 标准中定义的基本运算单元，如 Conv、Relu、MatMul，相当于物流中标准化的集装箱搬运单元。它既不是抽象的“神经网络层”概念，也不是文件或数据集，而是有明确输入输出和属性定义的最小运算单位。

Q2. opset_import 中的空字符串 domain 代表什么？

单选题 · easy

  • A.自定义扩展算子域
  • B.默认 ONNX 算子域← 正确答案
  • C.废弃的历史算子域
  • D.推理引擎私有算子域

答案：B。空字符串 domain 表示 ONNX 默认的 ai.onnx 算子域，官方维护的绝大部分神经网络算子都在这个域下。自定义算子则需要用带公司名或项目名前缀的 domain 字符串来区分，不能占用默认域。

Q3. Conv 算子中的 bias 参数在 ONNX 节点里扮演什么角色？

单选题 · mid

  • A.算子的属性 attribute
  • B.算子的输入 input← 正确答案
  • C.算子的类型名称
  • D.算子的文档说明

答案：B。在 ONNX 规范中，卷积核、偏置这类可训练参数以 initializer 形式存在于图中，作为算子的输入张量（input）传入，而不是写进 attributes。attributes 只保存 kernel_shape、strides 这类编译期固定的配置。不要被“参数”两个字迷惑，它是数据输入而不是属性。

Q4. 自定义算子注册时必须声明的是？

单选题 · mid

  • A.自定义的域名和算子名← 正确答案
  • B.模型的训练集大小
  • C.目标硬件的运行频率
  • D.数据增强策略类型

答案：A。自定义算子必须挂在自定义 domain 下，通过 domain + op_type 双重标识唯一定位，例如 com.example.MyOp。推理引擎需要根据这个标识加载对应的共享库实现。训练集大小、硬件频率和数据增强都属于模型训练侧问题，与算子标准无关。

Q5. 下列哪个不是 ONNX 定义的算子属性类型？

单选题 · easy

  • A.STRING 字符串类型
  • B.POINTER 指针类型← 正确答案
  • C.FLOAT 浮点类型
  • D.TENSOR 张量类型

答案：B。ONNX 规范的属性类型只有 FLOAT、INT、STRING、TENSOR、GRAPH 以及对应的数组形式，不存在 POINTER 指针类型。原因在于 ONNX 是一种跨语言、跨平台的序列化协议，不暴露任何内存指针。见到指针类属性，可以直接判定不符合规范。

Q6. 模型 opset 声明版本为 13，目标引擎只支持到 11，结果是？

单选题 · mid

  • A.模型自动降级至旧版本
  • B.引擎自动升级到新标准
  • C.可能因版本不支持报错← 正确答案
  • D.算子标准将不再生效

答案：C。opset 版本声明决定模型使用了哪个版本的算子定义。目标引擎只支持到 v11，而模型按 v13 标准封装，就像把新式高柜运到老式码头，很可能因核心算子定义不识别而报错。模型不会自动降级，引擎也不会自动升级，只能重新导出匹配版本。

Q7. 一个模型导出时报 Unsupported operator，最稳妥的排查起点是？

单选题 · hard

  • A.更换新训练数据集重新训练
  • B.检查算子版本支持范围← 正确答案
  • C.提升显卡的显存频率
  • D.删除模型里所有归一化层

答案：B。Unsupported operator 提示当前 opset 或工具链不识别某个算子，应优先核对 opset_import 版本号、算子是否在目标 domain 的目录中、目标推理引擎是否实现了该算子。更换数据、提升显存或删除网络层都属于治标不治本，甚至破坏模型结构。

Q8. ONNX 官方维护的算子域包含哪些？

多选题 · mid

  • A.ai.onnx 默认神经网络域← 正确答案
  • B.ai.onnx.ml 传统机器学习域← 正确答案
  • C.ai.onnx.training 训练相关域← 正确答案
  • D.ai.onnx.gpu 硬件加速域

答案：ABC。官方维护的域包括 ai.onnx（神经网络算子）、ai.onnx.ml（传统机器学习算法）、ai.onnx.training（训练相关算子）。GPU 加速不属于算子域，而是运行时推理引擎在标准算子图之上做的底层优化行为，不存在 ai.onnx.gpu 这个官方域。

Q9. 下面哪些情况会导致 ONNX 转换或加载失败？

多选题 · hard

  • A.模型中包含未注册的自定义算子← 正确答案
  • B.算子输入数据类型违反类型约束← 正确答案
  • C.动态维度未在导出时显式声明← 正确答案
  • D.训练时的 batch size 设置过大

答案：ABC。未注册的自定义算子会让引擎找不到实现；输入类型违反类型约束（如 Conv 收到 int8）会被标准拒收；动态维度未声明则形状推断失败。而训练时 batch size 过大只影响显存占用，不会影响转换或加载，属于模型训练资源问题。

Q10. 关于 ONNX 算子的类型约束，正确的说法有？

多选题 · extreme

  • A.限定输入输出数据类型集合← 正确答案
  • B.参与形状推断和类型推断← 正确答案
  • C.决定算子的具体运算方式
  • D.规定算子在图中的执行顺序

答案：AB。类型约束通过类型变量 T 限定算子输入输出允许的数据类型范围，并在类型推断（Type Inference）和形状推断（Shape Inference）时参与匹配，使得推理引擎能推导出张量的形状。算子的具体运算方式由算子实现逻辑决定，执行顺序由图拓扑决定，都与类型约束无关。