ONNX

What ONNX is

ONNX (Open Neural Network Exchange) is a shared representation for machine learning models, created so that a model can move between frameworks. Instead of converting a model from one framework's format into another incompatible one, developers can write to a single common format and read from it elsewhere ^[1]. The format defines an extensible computation graph model together with a set of built-in operators and standard data types, and a graph is structured as an acyclic list of operator nodes ^[1][4].

A computation graph is a way of writing a model down as a set of operations connected to one another: each node is a single operation, such as a matrix multiplication or an activation function, and the connections say which node's output becomes which node's input. "Acyclic" means the data flows in one direction, with no path that loops back on itself, which is what makes such a graph straightforward to execute in order. Because the graph is described abstractly — in terms of operators and data types rather than one library's internal structures — different programs can read the same file. The definition is extensible, so operators and types can be added as models need them ^[1][4].

The first version focused on the capabilities needed for inferencing ^[1]. Inference is the step in which a trained model is run to produce an output — a prediction, a label, a score — as opposed to training, in which the model's parameters are adjusted. That focus set the initial scope: what a model needs in order to be executed, rather than everything involved in building it.

Where it came from

Microsoft and Facebook announced ONNX on 7 September 2017, naming Cognitive Toolkit, Caffe2 and PyTorch as initial supporters ^[1]. The onnx/onnx repository was created on GitHub on the same day, and the project is released under the Apache-2.0 license ^[5]. Publishing both the specification and an implementation under a permissive open-source license made the format available for other organisations to adopt and to build tooling around.

Support around it

Support did not stay with the two announcing companies. In October 2017 AMD, Arm, Huawei, IBM, Intel and Qualcomm announced support for ONNX, extending the list of hardware and software vendors interested in the format ^[2]. On 8 December 2017 Facebook, AWS and Microsoft announced ONNX v1 as production-ready, with support available in Caffe2, Cognitive Toolkit, Apache MXNet, PyTorch and NVIDIA TensorRT ^[2][3]. AWS's post on ONNX 1.0 gives a concrete picture of what the format is for: building vision models in PyTorch and then running inference with Cognitive Toolkit or MXNet ^[3]. A model produced in one framework is executed in another, with the file as the point of contact between them.

What it is for

ONNX describes itself as a community project whose goal is greater interoperability, so that developers are not locked into one framework or ecosystem ^[4]. That framing explains the shape of the project. It is not a training library or a framework in its own right; it is the layer between them — a file format and a definition of what a model consists of, so that tools on either side can agree on what they are handing over. The value of such a format grows with the number of tools that read and write it, which is why the announcements of support from other vendors and from runtime libraries matter as much as the original specification.

The early scope also explains a limitation to keep in mind: the initial version addressed the capabilities needed for inference rather than the full range of operations used while training ^[1]. A format aimed at describing a model for execution does not automatically cover everything a training loop does.

Where it sits

ONNX occupies an unglamorous but load-bearing position in the tooling of machine learning: the interchange layer that lets a model trained with one set of tools be evaluated with another ^[1][3]. Its importance is not that it does something no framework can do, but that it removes a repeated, error-prone translation step and gives vendors, runtime engines and framework authors a shared target ^[1][2][4].