想象你是一家中式餐厅的主厨。行业里有一本权威的《世界名厨标准菜谱》，里面的每一道菜都被编号记录，所有厨师都会做——这就是 ONNX 的标准算子集。可你最近发明了一道“分子料理版宫保鸡丁”，这本官方菜谱里根本没有收录。难道这道菜就永远只能锁在自己厨房里吗？ ONNX 的扩展机制，就是在这本标准菜谱后面附上“私房菜”专区：你可以把自己的独门做法登记上去，写上菜名、属于哪个流派、原料和成品要求，然后任何读到这本书的厨师都能照着做。本书将带你翻开这本文书，看看“标准菜谱”如何迎接“私房菜”——从为什么要扩展、opset 版本怎么管、Schema 怎么登记、域怎么划分，到最终把菜端上餐桌（推理执行）的全流程。

岗位关联

理解 ONNX 扩展机制，你才能在自研算子、跨框架部署和推理引擎开发中游刃有余——它是让模型格式“活”起来的关键闸门。

目录
  1. 可视化演示
  2. 扩展机制概述
  3. 算子集版本管理
  4. 自定义算子注册
  5. 域与命名空间
  6. 扩展实现流程
  7. 兼容最佳实践
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

演示ONNX扩展机制：扩展流程展示定义schema→引用域→opset声明→注册实现的四步；算子类型展示自定义算子与Function算子差异；算子图展示自定义算子嵌入标准计算图实现跨框架互操作。

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

扩展四步流程 定义→引用→声明→注册 opset_import 自定义算子进入模型流转

扩展机制概述

想象你是一家餐厅的主厨，手里攥着一本《世界名厨标准菜谱》。这本书由行业联合会统一出版，里面收录了所有餐厅都会用到的标准技法——切丁、焯水、爆炒。在 AI 的世界里，ONNX 就是这本菜谱，它定义了 Conv 卷积、ReLU 激活、Gemm 全连接等一批“标准算子”。绝大多数模型都由这些标准算子拼装而成。

但研究永远不会停步。PyTorch 的团队发明了动态卷积，你的团队设计了一种高效的稀疏注意力，这些新“菜品”并没有被收录进标准菜谱。如果没有扩展机制，模型一导出就会报“不识此算子”，部署直接卡死在最后一公里。ONNX 扩展机制就像菜谱末尾新增的“私房菜”专区：允许你把独有的算子登记进去，让模型里出现“非标准”的操作也能被合法地装载和运行。

从工程视角看，扩展机制由两条核心线索构成：一条是“版本线”，用 opset 记录标准菜谱演进到第几版，保证新旧兼容；另一条是“登记线”，通过 Schema 把自定义算子的姓名、出处、原料、成品登记在册。两条线合起来，模型描述与运行时实现之间就建立了一座稳定的桥。

回到菜谱的比喻：一道菜端上桌，可能是标准技法做的，也可能是私房技法做的，但只要登记在册、写清了做法，后厨就能照着出菜。这就是扩展机制的价值——既守住了标准，又包容了创新。

ONNX Model={standard ops}∪{custom ops}\text{ONNX Model} = \{ \text{standard ops} \} \cup \{ \text{custom ops} \}
一个 ONNX 模型可以看作“标准算子集合”与“自定义算子集合”的并集。标准算子人人会做，自定义算子靠扩展机制登记挂靠。
  1. ONNX Model一个完整的 ONNX 模型，等价于一张菜谱卡片上全部做法的并集。
    ONNX Model\text{ONNX Model}
  2. standard ops标准算子集合，即官方菜谱里所有人都掌握的技法，例如 Conv、ReLU、Add。
    standard ops={Conv,ReLU,Add,…}\text{standard ops} = \{ \text{Conv}, \text{ReLU}, \text{Add}, \ldots \}
  3. custom ops自定义算子集合，即通过扩展机制登记进“私房菜”专区的新技法。
    custom ops={MyGelu,SparseAttn,…}\text{custom ops} = \{ \text{MyGelu}, \text{SparseAttn}, \ldots \}

算子集版本管理

菜谱不是一成不变的。每隔一段时间，行业联合会会推出新版菜谱：第 15 版新增了低温慢煮，第 16 版新增了液氮急冻，第 17 版加入了分子料理基础技法。每个版本都在旧版基础上做加法，不会把以前的技法删掉——这正是“标准菜谱”能长久流传的原因。

在 ONNX 中，这套“版次”体系叫 opset（Operator Set，算子集合）。一个 opset 由“域 + 版本号”唯一确定，例如 (ai.onnx, 13) 表示标准域第 13 版算子集合。模型文件在头部通过 opset_imports 声明自己依赖哪个域的哪个版本；推理引擎读到这个声明后，就知道该用哪一版菜谱来解析模型中的算子。

版本管理的核心是向后兼容：一个用 opset 13 导出的旧模型，在只支持 opset 13 及以上的新运行时里应当照常运行。这要求每次版本升级只能“新增算子或扩展已有算子的能力”，不能修改或删除已有算子的语义。用菜谱的话说，第 17 版可以新增做法，但绝不能说“第 13 版的爆炒现在改成水煮”。

所以，当你给模型标定 opset 时，不要盲目追求最新。部署端的运行时版本决定你能用多新的菜谱——版本号不是炫耀的资本，而是必须对得上的接头暗号。

opsetid=(domain,version),Model(opset=n)⇒Runtime(opset=m),  m≥n\text{opset}_{id} = (\text{domain}, \text{version}), \quad \text{Model}(\text{opset}=n) \Rightarrow \text{Runtime}(\text{opset}=m),\; m \ge n
opset 由域和版本号组成；模型声明自己需要的版本 n，只要运行时的版本 m 不低于 n，就有条件兼容运行。
  1. opset_id 二元组opset 身份由“哪个域”和“第几版”共同决定，就像“商务出版社《菜谱》第 3 版”。
    opsetid=(domain,version)\text{opset}_{id} = (\text{domain}, \text{version})
  2. 模型声明模型导出时在头部写明自己基于第 n 版算子集，相当于菜谱卡片上标注“依据第 16 版做法”。
    Model(opset=n)\text{Model}(\text{opset}=n)
  3. 运行时版本约束推理引擎支持的第 m 版如果不低于 n，说明它完全理解旧版的每一种做法。
    Runtime(opset=m),  m≥n\text{Runtime}(\text{opset}=m),\; m \ge n
  4. 蕴含关系当 m ≥ n 时，新运行时“向下兼容”旧模型，就像会第 17 版的厨师必然能做第 13 版的菜。
    ⇒\Rightarrow

自定义算子注册

假定你的“分子料理宫保鸡丁”想进入菜谱的私房菜专区。光在模型里写个名字“宫保鸡丁”是没用的，厨师看到名字也做不出来。你必须提交一张登记表：菜名叫什么（name）、出自哪家餐厅（domain）、从哪个版次开始收录（since_version）、需要哪些原料（inputs）、出品是什么样（outputs）、有哪几种火候可选（attributes）。

这张登记表在 ONNX 中叫 Schema（模式声明）。它是自定义算子的“身份档案”，推理引擎靠它完成两件事：校验模型里的节点是否符合声明，以及把节点路由到真实的计算实现。Schema 不会实现计算本身，只负责把“是什么、要什么、出什么”说清楚。

注册 Schema 的典型代码类似：实例化一个 OpSchema，指定名称和域，声明类型约束 T 只能取 FLOAT 或 DOUBLE，然后调用 register_schema 提交给 ONNX 运行时。一旦注册成功，check_model 就会认可这个“编外算子”，模型才能通过合法性校验。这就像编委会审阅了你的登记表，盖章通过，你的私房菜才正式出现在菜谱附页里。

注册完成后，你的私房菜终于有了正式“户口”。但请记住：登记表只是纸上说明，后厨还得有人会做这道菜——真正执行计算的 kernel 实现，是下一节的问题。

Schema(op)=(name,domain,since_version,inputs,outputs)\text{Schema}(\text{op}) = ( \text{name}, \text{domain}, \text{since\_version}, \text{inputs}, \text{outputs} )
Schema 是一个五元组：名字、所属域、起始版本、输入描述、输出描述。它告诉 ONNX：我的算子是谁、归属哪里、从哪个版本起存在、吃什么、吐什么。
  1. name算子的名字，字符串，如 “MyGelu“。注意名字本身不要求全局唯一，唯一性要靠”域 + 名字”。
    name="MyGelu"\text{name} = \text{"MyGelu"}
  2. domain算子所属的域，表明自己是官方算子还是某框架的扩展算子。
    domain="com.example.custom"\text{domain} = \text{"com.example.custom"}
  3. since_version从 opset 的哪个版本起，这个算子被收录。新注册的算子通常设为当前 opset 版本。
    since_version=1\text{since\_version} = 1
  4. inputs输入张量的序列定义，每个输入可有名称、类型约束。例如 X : T。
    inputs=(X:T)\text{inputs} = ( \text{X}: T )
  5. outputs输出张量的序列定义，描述了算子产出的数据。
    outputs=(Y:T)\text{outputs} = ( \text{Y}: T )

域与命名空间

世界上不止一家餐厅会做私房菜。如果每家都把自己的独创菜叫“秘制酱料”，那整本菜谱就会陷入混乱：读到“秘制酱料”时，到底是王师傅的配方，还是李师傅的配方？所以 ONNX 引入了域（domain）的概念，类似编程语言里的命名空间（namespace）——给每个“流派”划一块独立的地盘。

默认域是 ai.onnx，所有官方标准算子都住在这里。各家扩展算子则放进自己的自定义域，通常用公司域名或项目名，如 com.example.custom。一个算子的全局完整名是“域 + 算子名”，例如 com.example.custom:MyGelu。域标识在模型文件的 opset_imports 里声明，每个被使用的域都要列出对应的版本号。

域的隔离作用很直观：A 家的 MyGelu 和 B 家的 MyGelu 虽然同名，但域不同，二者井水不犯河水，推理引擎不会混淆。更妙的是，同一个模型里可以同时引入多个域，模型就像一桌“融合菜”——官方菜和两家私房菜同台上桌，互不干扰。

下次你在 make_node 里写 domain="com.example.custom" 时，心里要知道：这是在告诉所有读者，“这道菜出自我的私房菜单，别去官方菜谱里找”。

full_name=domain⊕op_name,默认域=ai.onnx\text{full\_name} = \text{domain} \oplus \text{op\_name}, \qquad \text{默认域} = \text{ai.onnx}
算子的完整身份是“域 + 算子名”拼接；官方标准算子默认住在 ai.onnx 域。域就是菜谱里的出版商标识，避免各家“秘制酱料”打架。
  1. full_name算子的全局唯一身份，如 com.example.custom:MyGelu，中间用冒号连接域与算子名。
    full_name=domain⊕op_name\text{full\_name} = \text{domain} \oplus \text{op\_name}
  2. op_name算子自己的短名，如 MyGelu。短名可以重复，就像不同餐厅都可以有“秘制酱料”这道菜。
    op_name=MyGelu\text{op\_name} = \text{MyGelu}
  3. 默认域ai.onnx，官方标准算子的专属地盘。看到这个域，谁都不用额外注册，直接做。
    默认域=ai.onnx\text{默认域} = \text{ai.onnx}

扩展实现流程

一道私房菜从发明到端上餐桌，要经过完整的四步流程。第一步是定义算子：在 Python 或 C++ 里实现算子的计算逻辑，也就是写清楚“这步操作怎样把输入变成输出”；第二步是注册 Schema：把上一节那张登记表提交给 ONNX，让模型格式层认识这个算子；第三步是导出模型：在 PyTorch 等框架中把自定义算子挂到指定域，然后导出成 ONNX 图；第四步是执行推理：推理引擎在模型图中遇到自定义算子时，依据 Schema 找到注册的计算实现并执行。

四步缺一不可。不实现逻辑，算子跑不出数值；不注册 Schema，模型校验直接报错；不指定 domain，导出的算子会被当成标准算子而找不到实现；推理引擎若不支持你的域，模型加载也会失败。每一步都像餐厅开新菜：研发配方（定义）、报备食材与做法（注册 Schema）、印入菜单（导出）、下发后厨照做（执行）。

在实际工程中，PyTorch 导出通常借助 torch.onnx.register_custom_op_symbolic 把自定义 torch 算子映射到 ONNX 算子，而 ONNX Runtime 等推理引擎则通过 CustomOp 接口注册 kernel。所以“扩展”从来不是一锤子买卖，而是一条从训练框架到推理引擎的全链路协作。

至此，你的私房菜正式上了菜单。但从开胃菜到主菜再到甜品，整本菜单的稳定运转还需要最后一节讲的那些“经营智慧”。

Extend:Define→Register→Export→Execute\text{Extend}: \text{Define} \to \text{Register} \to \text{Export} \to \text{Execute}
扩展一个算子的完整链路是“定义 → 注册 → 导出 → 执行”。顺序不能颠倒，链条不能断裂。
  1. Define实现算子计算逻辑——最基础的一步，用目标语言写出输入到输出的数值计算过程。
    Define:实现 y=fθ(x)\text{Define}: \text{实现 } y = f_{\theta}(x)
  2. Register注册 Schema，让 ONNX 格式层认可这个算子，相当于给新菜建立身份档案。
    Register:提交 Schema 到 ONNX Registry\text{Register}: \text{提交 Schema 到 ONNX Registry}
  3. Export导出模型时把节点写入自定义域，模型图里就会包含这个扩展算子。
    Export:节点写入 domain 为自定义域\text{Export}: \text{节点写入 domain 为自定义域}
  4. Execute推理引擎根据 Schema 路由到已注册的 kernel 并执行，完成前向计算。
    Execute:Runtime 调用 Custom Kernel\text{Execute}: \text{Runtime 调用 Custom Kernel}

兼容最佳实践

一家成熟的餐厅不会为了创新砸了自己的招牌。推出第 17 版菜谱时，行业联合会有一条铁律：只许新增，不许删改。映射到自定义算子上，就是向后兼容策略：增加新属性时必须提供默认值，保证旧模型不填新属性也能跑；已有属性的语义不得改变；一个算子一旦发布，就不能随意修改它的输入输出契约。

版本迁移时最常见的三个坑是：第一，Schema 忘记带 domain，被误判为标准算子；第二，Schema 与 kernel 实现不一致，比如声明 2 个输入但实现只收 1 个；第三，opset 声明得过高，部署端运行时不认识。对应最佳实践是：所有自定义算子统一放一个专属域；修改算子时 bump since_version 而不是覆盖旧版本；能用标准算子组合出效果的，绝不额外发明自定义算子——“先标准、后扩展”。

为什么这些实践如此重要？因为模型文件的生命周期远超你的想象。你今天导出的模型，可能在三年后的某个生产环境里运行。那时你的团队散了、框架迭代了好几轮，唯一能救场的，就是当初那份足够规范、向后兼容的 Schema 和实现。

菜谱的魔力在于：只要约定被执行，每一代厨师都能复现百年前的经典菜。ONNX 扩展机制也是如此——它给了创新一个合法的入口，也让旧模型在老引擎上永远有一席之地。现在，你可以自信地打开 ONNX 的后厨门，写下属于你自己的“私房菜”了。

∀ op∈Model,  since_version(op)≤runtime_opset⇒compatible\forall\, op \in \text{Model}, \; \text{since\_version}(op) \le \text{runtime\_opset} \Rightarrow \text{compatible}
兼容性判据：模型里每个算子被收录的版本号都不超过运行时的 opset 版本时，模型才能稳定运行。就像旧菜谱的每道菜都被新厨师掌握，点单才不会出问题。
  1. 全称量词“对于所有”——模型里任何一个算子都不能是运行时不识别的“生面孔”。
    ∀ op∈Model\forall\, op \in \text{Model}
  2. 版本比较算子被收录的 since_version 必须不高于运行时支持的 opset 版本，这说明运行时会做这道菜。
    since_version(op)≤runtime_opset\text{since\_version}(op) \le \text{runtime\_opset}
  3. 兼容结论当上面两个条件同时成立时，整个模型与运行时兼容，可以放心部署。
    ⇒compatible\Rightarrow \text{compatible}

AI 应用场景

场景一：研究团队部署自研激活函数

阶段：模型导出与部署

解决的问题：研究团队在 PyTorch 中设计了新的激活函数（如动态 ReLU），导出 ONNX 时该算子不在标准算子集中，直接导出失败。传统做法是强行把新函数拆成标准算子组合，数学上等价但图结构臃肿，推理效率还打折。

具体案例：某视觉团队为轻量分类网络设计了“通道自适应激活”算子。他们按扩展四步走：先用 PyTorch 实现算子逻辑，再在 Python 侧用 OpSchema 注册到 com.example.vision 域，导出时用 register_custom_op_symbolic 完成映射，最后在 ONNX Runtime 里注册同名 kernel。模型成功部署到手机端，推理延迟比拆算子方案降低 23%。

场景二：芯片厂商为自家 NPU 定制融合算子

阶段：推理引擎适配与算子优化

解决的问题：NPU 的矩阵计算单元对某些"Conv + BatchNorm + ReLU"融合算子执行效率远高于拆开执行。芯片厂商通过 ONNX 扩展机制把融合算子注册为自定义算子，避开框架通用实现，直接调度到硬件加速单元。

具体案例：一家 AI 芯片公司在 com.npu.fusion 域注册了 ConvBNReLU 算子，并在自家推理引擎中实现高效 kernel。算法团队在训练侧导出时仅需替换三个标准算子的组合为这一个自定义算子，即可获得 3.2 倍的端到端性能提升，模型格式完全符合 ONNX 规范。

场景三：跨框架互操作时的算子桥接

阶段：模型格式转换与互操作

解决的问题：模型从 PyTorch 转到 TensorRT 或 OpenVINO 时，遇到两边都识别不了的新算子。扩展机制允许把算子“原样”带进模型，由目标推理引擎重新注册 kernel 适配，避免转换中断。

具体案例：某公司核心算法使用了自家 Transformer 变体中的 GatedAttentionUnit，导出 ONNX 后交给部署团队。部署工程师在 ONNX Runtime 里注册了同名算子 kernel，模型五分钟后即可加载推理，不需要等上游框架版本更新。

Python 演示

python52 行
# -*- coding: utf-8 -*-"""演示 ONNX 扩展机制：注册自定义算子 Schema 并构造含该算子的模型。"""import onnxfrom onnx import helper, TensorProtofrom onnx import defsfrom onnx.defs import OpSchema # 1. 构建自定义算子的 Schema 登记表custom_schema = OpSchema(    name="MyGelu",    domain="com.example.custom",    since_version=1,    attribute_schemas={},    type_constraint_schemas={        "T": OpSchema.TypeConstraintParam(            "T",            [TensorProto.FLOAT, TensorProto.DOUBLE],            "浮点张量"        )    }) # 2. 提交登记表并确认注册成功defs.register_schema(custom_schema)assert defs.has_schema("MyGelu", "com.example.custom", 1)print("Schema 注册成功: com.example.custom:MyGelu") # 3. 构造模型：声明自定义域 opset，创建自定义算子节点opset_imports = [    helper.make_opsetid("", 15),    helper.make_opsetid("com.example.custom", 1)]node = helper.make_node(    "MyGelu",    inputs=["X"],    outputs=["Y"],    domain="com.example.custom") # 4. 组装计算图graph = helper.make_graph(    [node],    "custom_model",    [helper.make_tensor_value_info("X", TensorProto.FLOAT, None)],    [helper.make_tensor_value_info("Y", TensorProto.FLOAT, None)])model = helper.make_model(graph, opset_imports=opset_imports)model.ir_version = onnx.IR_VERSION # 5. 校验模型：注册过的自定义算子可以通过检查onnx.checker.check_model(model)print("模型校验通过，包含自定义算子 MyGelu 的 ONNX 模型已生成")
目的：演示如何为自定义算子注册 Schema，并构造一个含非标算子的合法 ONNX 模型，跑通“注册 → 导出 → 校验”流程。
  1. custom_schema = OpSchema(...)填写登记表：算子名 MyGelu、域 com.example.custom、版本 1，并声明类型约束 T 只接受浮点张量。
  2. type_constraint_schemas={"T": ...}规定这道菜只收“浮点食材”，拒绝整数或字符串张量。
  3. defs.register_schema(custom_schema)把登记表提交给 ONNX 编委会，注册后全局可见。
  4. assert defs.has_schema(...)复查登记表是否入库，防止写错域名或版本。
  5. helper.make_opsetid("com.example.custom", 1)声明模型依赖“自定义域第 1 版菜谱”。
  6. helper.make_node("MyGelu", ..., domain="com.example.custom")在模型图里放入自定义算子节点，并注明出处。
  7. onnx.checker.check_model(model)最终质检：因为 Schema 已注册，带自定义算子的模型顺利通过校验。

常见误区

误区我觉得只要把 PyTorch 的新算子换个名字，ONNX 导出就能通过，毕竟名字没人用。

正解名字只是代号。ONNX 校验器（checker）会拿着模型里的每个节点去查注册表：该域、该名字下有没有对应 Schema。没有 Schema，直接抛异常。这就像你往菜谱里写了一行“宫保鸡丁”，但没附原料和做法，厨师拿到菜单也做不出来。必须先注册 Schema，算子才能获得正式身份。

为何常见：初学者容易把“命名”当成“定义”，忽略了 ONNX 对算子存在性的强制校验。

误区导出模型时我直接把 opset 拉到最新版本，这样功能最全、最先进。

正解opset 是模型与运行时之间的“接头暗号”。模型声明 17，运行时只支持到 15，加载就会失败或报版本不兼容。正确的做法是先确认部署端运行时的版本上限，再选定一个不高于它的 opset。用最新版菜谱当然好，但你家后厨的厨师还没学过第 17 版的技法，点了也白点。

为何常见：人们习惯性追求“最新最好”，但部署是约束下的工程决策，版本对齐比版本前沿更重要。

误区我自己的模型自己用，domain 写个 "test" 甚至不写，反正名字不重复。

正解domain 是全局命名空间，负责防止不同来源的算子“同名打架”。不写 domain 的节点会落入默认域 ai.onnx，与官方算子同名时会被当成标准算子解析；写 "test" 这种过短的泛化词，未来很容易与社区已有算子冲突。规范做法是用反向域名，如 com.example.custom，像商标一样保持全球唯一。

为何常见：单机自用时感受不到命名冲突，但模型一旦流转到团队或社区，短域名立刻变成风险源。

误区我注册完 Schema，模型也校验通过了，部署时总该没问题了吧？

正解Schema 只是“纸上登记”，真正计算靠的是推理引擎里注册的 kernel 实现。ONNX Runtime 加载模型时会把自定义算子路由到具体 kernel，找不到 kernel 照样报错。类比：菜谱上描述了“分子料理”的做法，但如果餐厅没有会做这道菜的厨师和真空低温机，顾客点了依然上不了桌。Schema 负责“合法”，kernel 负责“能跑”，两者缺一不可。

为何常见：校验通过带来的安全感让人误以为部署链路已经打通，忘了格式层与执行层是两回事。

面试题

Q1. ONNX 扩展机制主要解决什么问题？

单选题 · easy

  • A.让模型训练速度更快
  • B.让新算子进入模型并部署← 正确答案
  • C.替代 GPU 获得更快推理
  • D.减小模型的存储大小

答案：B。扩展机制让标准算子集之外的新算子也能被 ONNX 模型承载，通过注册 Schema 等步骤部署到推理引擎。训练加速、GPU 加速、模型压缩都不是扩展机制的目标。

Q2. 自定义算子在 ONNX 中靠什么标识唯一的完整名字？

单选题 · easy

  • A.算子名称本身
  • B.模型的文件名
  • C.域与算子名的组合← 正确答案
  • D.模型的版本号

答案：C。仅靠算子名会与来源不同的实现冲突，模型文件名和版本号与算子身份无关。只有“域 + 算子名”才能全球唯一地标识一个自定义算子，就像“出版社名 + 书名”才唯一。

Q3. 下面哪一个是 ONNX 标准算子的默认域？

单选题 · easy

  • A.通用社区域 com.example.custom
  • B.官方默认域 ai.onnx← 正确答案
  • C.官方扩展域 org.onnx.base
  • D.官方标准域 onnx.standard

答案：B。ONNX 官方标准算子统一放在 ai.onnx 域；com.example.custom 是自定义域的典型写法；org.onnx.base 和 onnx.standard 是干扰项，ONNX 中不存在这样的默认域。

Q4. opset 版本号在 ONNX 中的作用是什么？

单选题 · mid

  • A.代表模型文件的编码格式
  • B.代表模型文件的大小信息
  • C.标识标准算子集的演进版本← 正确答案
  • D.标识自定义算子的注册时间

答案：C。opset 即 Operator Set，用来标识算子集合演进到第几版，规则是只增不删。它不编码模型内容，也不携带文件大小或注册时间信息。模型头部的 opset 声明是运行时选择解析规则的关键依据。

Q5. 注册自定义算子 Schema 时，必须显式声明下列哪一项？

单选题 · mid

  • A.算子的名称信息
  • B.算子所属的域标识← 正确答案
  • C.输入张量的数量
  • D.输出张量的个数

答案：B。Schema 必须声明 domain，否则自定义算子会被归入默认域 ai.onnx，失去命名空间隔离。名称、输入、输出虽然也需要，但“必须有 domain”是自定义算子与标准算子的根本区别。

Q6. 一个有效的自定义算子 Schema 通常包含哪些信息？

多选题 · mid

  • A.算子的名称信息← 正确答案
  • B.算子所属的域标识← 正确答案
  • C.输入输出的类型约束← 正确答案
  • D.训练轮次的迭代信息

答案：ABC。Schema 是算子的“身份登记表”，包含 name、domain、since_version、inputs、outputs 等。训练轮次属于训练流程的元数据，与算子格式声明无关，不会出现在 Schema 中。

Q7. 模型声明 opset 16，而推理运行时只支持 opset 15，下列说法正确的是？

单选题 · mid

  • A.模型一定可以正常运行
  • B.模型必定会加载失败
  • C.未用到 16 新增算子时可运行← 正确答案
  • D.运行时自动降级到更低版本

答案：C。opset 只增不删，opset 16 的新增算子旧运行时不认识，但旧算子语义完全保留。所以只要模型实际未使用 opset 16 新增的算子，用 opset 15 的运行时依然能加载执行；否则就会失败，且不会自动降级。

Q8. 下列哪些做法有助于自定义算子的长期兼容？

多选题 · hard

  • A.增加新属性时提供默认值← 正确答案
  • B.允许后注册覆盖前次的 Schema
  • C.保持域名称的唯一且稳定← 正确答案
  • D.优先复用标准算子再扩展← 正确答案

答案：ACD。新属性给默认值，旧模型不填也能跑；域名稳定唯一，避免与其他实现冲突；能先标准组合就少造自定义算子，降低维护成本。覆盖 Schema 会破坏历史模型的解析契约，是典型的兼容性反面教材。

Q9. 导出包含自定义算子的 ONNX 模型之前，第一步必须做什么？

单选题 · hard

  • A.注册自定义算子的 Schema 声明← 正确答案
  • B.将模型转换为 TensorRT 的格式
  • C.降低模型中权重参数的精度
  • D.完全关闭框架的梯度计算

答案：A。扩展流程是“定义 → 注册 → 导出 → 执行”。不先注册 Schema，导出后 checker 会因找不到算子身份而报错。TensorRT 转换、精度降低、关梯度都是可选的部署优化动作，不是扩展的前提条件。

Q10. 模型中若有 ONNX 校验器不认识的自定义算子，check_model 会怎样？

单选题 · easy

  • A.自动忽略该算子继续校验
  • B.抛出错误并拒绝通过校验← 正确答案
  • C.将自定义算子改写为注释
  • D.自动删除该节点给出警告

答案：B。check_model 会严格核对模型里每个节点是否能在注册表中找到对应 Schema，找不到就抛异常、拒绝通过。它不会忽略、改写或删除节点，这种严格性正是 ONNX 模型可靠流转的保障。