什么是开放神经网络交换格式（Open Neural Network Exchange）？

开放神经网络交换格式（Open Neural Network Exchange，缩写 ONNX）是一套面向人工智能模型的开源格式，它定义了一个可扩展的计算图模型（computation graph model），以及内置算子（operator）与标准数据类型的定义。按照 ONNX 官方文档与代码仓库的表述，它是一个开放生态，目的是让 AI 开发者在项目演进过程中能够选择合用的工具，并在不同框架、工具与硬件之间实现互操作，从而简化从研究走向生产的路径。

它要解决的问题是模型表示的分裂：同一个模型在不同训练框架、推理引擎与硬件后端之间往往各有各的格式，迁移一次就要重写或重新导出一次。ONNX 通过给出一个中间表示（intermediate representation）规范，让模型可以以一种与具体框架解耦的形式被描述、校验、转换与执行。

为什么重要

在 ONNX 出现之前，模型的可移植性主要靠各框架自带的导出与转换工具来维持。训练侧与推理侧常常属于不同的技术栈：研究阶段使用的框架未必是部署阶段使用的运行时，而部署目标又可能是多种硬件。每增加一个组合，就多出一条需要单独维护的转换路径，成本随组合数量增长。

ONNX 官方文档在介绍这套概念时，明确把「迁移到 ONNX 用于生产时会遇到的若干挑战」列为文档要说明的内容之一，这说明互操作本身并不是零成本的，而是需要一套规范化的概念体系来支撑。ONNX 仓库的说明则把价值落在两点上：一是让不同框架、工具与硬件之间具备互操作性，二是让从研究到生产的路径更顺畅，并称这有助于提升 AI 社区的创新速度。

需要说明的是，上述关于价值的表述来自 ONNX 官方文档与官方代码仓库的自述，属于该项目的定位主张，而不是对任何具体部署效果的量化结论。

工作机制

ONNX 的核心是一套围绕计算图展开的规范。官方文档列出的概念包括以下几个层面。

图的基本构成：输入（Input）、输出（Output）、节点（Node）、初始化器（Initializer）与属性（Attributes）。节点表示计算，输入输出描述数据流向，初始化器承载权重等常量，属性则描述节点的静态配置。
序列化：模型以 protobuf 进行序列化（Serialization with protobuf），因此模型文件是一种结构化的二进制表示，而不是某框架私有的存档格式。
元数据：模型可以携带元数据（Metadata），用于记录与模型相关的附加信息。
算子与域：规范维护一份可用算子与算子域（operators and domains）的清单。域的概念使得算子集合可以扩展，而不必把所有能力都塞进核心规范。
支持的数据类型：规范定义了标准数据类型（Supported Types），模型中的张量必须落在这些类型之内。
opset 版本：官方文档专门解释了「什么是 opset 版本」（What is an opset version）。opset 是算子集合的版本标识，模型与运行时需要就 opset 达成一致，才能正确解释图中的算子语义。
子图、测试与循环：规范支持子图（Subgraphs），并覆盖条件分支与循环这类控制流结构。
可扩展性与函数：规范提供扩展机制（Extensibility）与函数（Functions），允许在既有算子基础上组合出新的算子定义。
形状与类型推断：形状（与类型）推断（Shape and Type Inference）是规范与工具链中的一项能力，用于在不执行模型的前提下推导中间张量的形状与类型。

围绕这套规范，官方文档还描述了配套的工具与流程：用 Python 操作 ONNX 模型（ONNX with Python），包括一个线性回归的简单示例、序列化、初始化器与默认值、属性、opset 与元数据、子图示例、函数、解析（Parsing）、检查器与形状推断（Checker and Shape Inference）、求值与运行时（Evaluation and Runtime）、实现细节，以及转换器（Converters）——文档解释了什么是转换库（converting library），并讨论了替代方案（Alternatives）、opset 相关问题（Opsets）以及其他 API 技巧。

官方仓库一侧列出的能力包括：ONNX 中间表示规范（intermediate representation spec）、规范的版本管理原则、算子文档、Python API 概览、用于处理 ONNX 图的编程工具、形状与类型推断、图优化（Graph Optimization）以及 opset 版本转换（Opset Version Conversion）。这些条目说明，规范之外还有一层围绕图操作的编程接口。

从流程上看，一个模型进入 ONNX 体系通常要经过：由转换库从源框架导出为 ONNX 图；用检查器与形状推断校验图的合法性；必要时做图优化或 opset 版本转换；最后交给某个运行时执行。官方文档把「求值与运行时」与「实现细节」分开描述，意味着规范本身与具体实现是两件事。

典型例子

官方文档给出的入门示例是一个线性回归（a linear regression）模型，用来演示如何用 Python 构造、序列化并检查一个 ONNX 模型。这个例子覆盖了初始化器与默认值、属性、opset 与元数据等概念，是理解模型文件结构的最小样本。

文档还以子图为例说明测试与循环（Subgraph: test and loops）的写法，用于展示控制流在计算图中的表达方式。此外，文档在讨论转换时提到转换库（converting library）这一角色，并列出替代方案，说明从其他框架进入 ONNX 的路径不止一条。

在仓库层面，ONNX 项目公开了预训练 ONNX 模型（Pre-trained ONNX models）与创建 ONNX 模型的教程，作为可直接使用的素材。项目采用开放治理模型，设有特别兴趣小组（Special Interest Group，SIG）与工作组（Working Group），并至少每年举办一次社区聚会（Community Meetup），历史场次的记录可以追溯到 2020 年至 2023 年间的多次线上活动。仓库还包含贡献指南、行为准则、安全策略、路线图与发布管理文档，以及面向算子新增的专门说明文档。

边界与常见误解

第一，ONNX 当前的侧重点是推理（inferencing，也称 scoring）所需的能力。仓库说明中明确写道「Currently we focus on the capabilities needed for inferencing (scoring)」，因此不应把它理解为覆盖训练全流程的通用表示。把训练期的全部语义寄望于 ONNX，超出了官方自述的范围。

第二，ONNX 是规范加生态，不是某一个运行时。规范定义了计算图模型、算子与数据类型，但「求值与运行时」在文档中是单独一节，具体执行由实现方提供。把 ONNX 等同于某个推理引擎，会混淆规范与实现的分工。

第三，opset 版本是一致性约束而非细节。模型与运行时必须在 opset 上对齐，否则算子语义可能无法正确解释；官方文档因此把 opset 版本转换列为一项独立能力。跨版本迁移并非总是无损，这也是文档把「迁移到生产时的挑战」单独提出的原因之一。

第四，互操作性不等于零成本。官方文档在介绍概念的同时专门讨论生产迁移中的挑战，说明从研究模型到可部署模型之间仍存在需要处理的环节，例如图优化、形状推断与版本对齐。

第五，规范的可扩展性有边界。算子与域、函数与扩展机制提供了扩展途径，但新增算子需要遵循项目定义的流程，仓库中为此提供了专门的说明文档。

全部分类