ONNX: Open Standard for Machine Learning Model Interchange

What Problem ONNX Solves

Machine learning frameworks each use their own internal representation for trained models. A model trained in PyTorch cannot be loaded directly by TensorFlow's inference engine, and neither can be loaded directly by a hardware vendor's accelerator SDK without custom bridging code. This fragmentation creates a practical problem: teams that want to train in one framework and deploy with another runtime must either maintain separate training and inference stacks or write custom conversion code for every framework pair.

ONNX addresses this by defining a single intermediate format. A framework that implements an ONNX exporter can write a model to an ONNX file. A runtime that implements ONNX support can read that file and execute the model. The standard defines an extensible computation graph model, a set of built-in operators, and standard data types. The README notes the current focus is on inferencing (scoring) capabilities rather than training.

The ONNX Python package provides programmatic access to the standard: creating graphs, checking model correctness, running shape and type inference, and converting between opset versions.

The Computation Graph, Operators, and Opset Versioning

An ONNX model is a protobuf file containing a graph. The graph is a directed acyclic structure of nodes (operators) connected by named tensors. Operators are the building blocks: Conv, MatMul, Relu, Reshape, and hundreds more are defined in the ONNX operator set. Each operator specifies its inputs, outputs, and attributes.

Opset versioning controls which version of each operator definition a model uses. When the ONNX spec adds or changes an operator, the opset version increments. A model file records the opset version it was created with, so a runtime can know which operator semantics to apply. The Python package includes a version converter for migrating models between opset versions.

From the pyproject.toml, the package requires numpy, protobuf 6.31.1, typing_extensions, and ml_dtypes as runtime dependencies. The build process uses scikit-build-core with CMake, because the core ONNX library includes C++ code for performance-critical validation and graph manipulation. The Python package's wheel is ABI3-compatible from Python 3.12 onward, so a single binary wheel works across multiple Python minor versions.

Installing ONNX and Using the CLI Tools

ONNX is distributed as a pip package. The standard install:

pip install onnx

For the optional reference implementation, which provides a pure-Python operator execution layer useful for testing and debugging:

pip install onnx[reference]

The reference extra adds Pillow as a dependency. Weekly snapshot packages are published to PyPI under the name onnx-weekly for testing pre-release changes.

The package installs three CLI commands. `check-model` validates an ONNX model file for spec compliance. `check-node` validates a single node definition. `backend-test-tools` runs the ONNX backend test suite against a custom runtime implementation. For a developer integrating a new runtime, `check-model` is the first tool to use after generating a model file.

For running tests during development, the project uses pytest:

pip install pytest

pytest

Shape Inference, Graph Optimization, and the Python API

The ONNX Python package provides several graph manipulation utilities. Shape inference propagates tensor shape information through the graph without executing it, which is useful for verifying that a model's dimensions are consistent before deploying. The PythonAPIOverview document in the repository describes how to use the Python API to construct graphs programmatically, add nodes, set initializers, and check a model's structure.

Graph optimization is handled by a separate project in the ONNX organization (onnx/onnx-optimizer), not by the main package. The optimizer applies standard algebraic simplifications and fusions to reduce the number of operations in a graph. This is distinct from runtime optimization, which hardware vendors implement in their own ONNX runtimes.

The opset version converter, included in the main package, takes a model and a target opset version and rewrites operators that changed between versions. This is important when a model was exported with an older opset but the target runtime only supports newer opsets.

Reproducible builds are addressed through the SOURCE_DATE_EPOCH build variable, which removes timestamp-dependent variation. The README explains that reproducibility requires identical source, dependency versions, toolchain, and platform, not just a fixed timestamp.

ONNX vs TensorFlow SavedModel: A Framework Interoperability Comparison

TensorFlow's SavedModel format is TensorFlow's own serialization format for trained models. It stores the computation graph and variable weights in a TensorFlow-specific structure that TensorFlow Serving and TensorFlow Lite can load directly. SavedModel is deeply integrated with the TensorFlow ecosystem but has limited portability outside it.

ONNX is a framework-agnostic format. A model trained in PyTorch, JAX, scikit-learn, or TensorFlow can be exported to ONNX if the framework's exporter supports the operators the model uses. The ONNX Runtime project (a separate repository from onnx/onnx) provides a production-grade execution engine that can run ONNX models on CPU, GPU, and various accelerators.

The practical trade-off is fidelity. Some framework-specific operators or control flow constructs do not map cleanly to ONNX. When an export hits an unsupported operator, the exporter either raises an error or falls back to a decomposed representation that may differ in performance from the original. The ONNX operator set is extensible, allowing custom operator definitions, but custom operators require the runtime to also implement the corresponding execution logic.

Governance, Ecosystem, and Pre-Trained Models

ONNX is a community project under the LF AI and Data Foundation, an Apache Software Foundation-style neutral home for AI and data projects. The governance model includes a Steering Committee, Special Interest Groups, and Working Groups, all described in the community/ directory of the repository. Decisions about the spec, new operators, and the release process go through this structure.

The README points to Hugging Face's onnx-community organization as the location for pre-trained ONNX models. For teams that do not want to export their own models, this provides a starting point for common tasks like image classification, text embedding, and object detection.

The project follows a yearly roadmap process. The latest release is v1.23.0, published on 2026-09-18. The repository was last pushed on 2026-09-25. The license is Apache-2.0, which permits commercial use. The sbom.cdx.json file in the root provides a software bill of materials for the release, and SLSA provenance attestations are generated for each release build.

Editorial conclusion

ONNX is the right choice when you need to decouple model training from model deployment, particularly when the training framework and the inference target differ, for example training in PyTorch and serving with ONNX Runtime on an edge device. It is not a training framework and does not run models directly; you need a separate runtime. Before exporting a model, verify that all operators your model uses are covered in the ONNX operator set for your target opset version, since unsupported operators require custom operator definitions. Use the `check-model` CLI command to validate a model file before distributing it.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes