ONNX na Ushirikiano wa Mfano

ONNX, the Open Neural Network Exchange, is a shared language for describing trained machine learning models. A model in ONNX form is a computation graph: a list of operations, such as matrix multiplication, convolution or softmax, connected by the tensors (multi-dimensional arrays of numbers) that flow between them, together with the learned weights. Because the graph uses a standard set of operators with precisely defined behavior, any software that implements those operators can run the model, regardless of which framework trained it. This separation of training from deployment is what model interoperability means in practice.

The format is defined by the ONNX intermediate representation (IR) specification and stored as a Protocol Buffers file, a compact binary encoding developed by Google. The top-level object is a model, which records the IR version, the operator sets it relies on, metadata such as the producing tool, and the graph. The graph holds nodes, each naming an operator type, its inputs, its outputs and fixed attributes such as a convolution's kernel size. Initializers store constant tensors, usually the weights. Inputs and outputs are declared with a data type and shape, and a dimension can be a symbolic name such as batch_size instead of a fixed number. The specification requires nodes to be listed in topological order, so every value is produced before it is used, with no cycles, and every output name must be unique within a graph.

Versioning is the part of ONNX that makes long-term compatibility possible. Operators are grouped into operator sets, or opsets, identified by a domain and an integer version. The default domain covers neural network operators, and ONNX-ML adds operators for classical, non-neural machine learning algorithms. Every model must declare the opsets it uses. Under the versioning rules, any change to an operator's inputs, outputs, attributes, supported types or meaning is a breaking change that must appear as a new operator version in a new opset. A runtime that supports opset 17 therefore knows exactly what every operator in an opset 17 model does. The ONNX versioning table runs from ONNX 1.0, with IR version 3 and opset 1, to ONNX 1.23.0, with IR version 14 and opset 28.

ONNX began inside Facebook's PyTorch team under the name Toffee and was renamed and announced jointly by Facebook and Microsoft in September 2017. IBM, Huawei, Intel, AMD, Arm and Qualcomm later announced support, and in October 2017 Microsoft said it would bring its Cognitive Toolkit and Project Brainwave into the effort. On November 14, 2019, the format became a graduate project of the Linux Foundation's LF AI Foundation, which TechCrunch described as a step toward vendor-neutral governance, with more than 30 companies contributing code. The license moved from MIT to Apache 2.0. Only the format joined the foundation; ONNX Runtime, the inference engine Microsoft had open-sourced about a year earlier, stayed a separate Microsoft-led project.

In a typical workflow, a developer trains a model in PyTorch and calls torch.onnx.export. Since PyTorch 2.9, the default exporter is built on torch.export, which traces the model ahead of time into a graph of basic operations, removes most Python control flow and records shape constraints. The developer marks which dimensions may vary, such as batch size or text length, chooses an opset, and can ask the exporter to verify the result with ONNX Runtime. The resulting .onnx file is then loaded by a runtime. ONNX Runtime splits the graph among execution providers, plug-ins for specific hardware: each provider in a priority list claims the nodes it can run, and the default CPU provider runs whatever is left. Higher-level tools wrap this process; Hugging Face Optimum can export a Transformers model in one command, validate the outputs against the original, and split encoder-decoder models into separate files so the encoder runs once while the decoder loops.

ONNX is not the only way to move models around. Framework-native formats, such as PyTorch's saved programs, keep every framework feature but tie deployment to that framework's runtime. Vendor formats, such as compiled TensorRT engines, are faster on one family of hardware but are not portable. ONNX sits between them: broadly supported, with a stable specification, but limited to what its operators can express. Weight-only formats, which store tensors but not the computation graph, solve a different problem: sharing parameters for use in a framework that already knows the architecture.

The limits are real. Not every framework operation has an ONNX equivalent, so custom layers may need custom operators that only some runtimes support. Dynamic behavior is hard to capture: PyTorch's documentation notes that loops are not exported directly and points to explicit control-flow operators instead. If dynamic dimensions are not declared, the exporter freezes the example input's shapes, so a text model may only accept one length. Protocol Buffers files are limited to 2 GB, so larger models store their weights as external data files beside the graph. Optimizations can reduce portability: Optimum warns that some ONNX Runtime-specific graph optimizations produce files that OpenVINO or TensorRT cannot run. Small numerical differences between runtimes are normal, which is why exporters compare outputs within a tolerance instead of expecting exact matches.

In practice ONNX costs nothing to use: the format, the onnx Python package and ONNX Runtime are open source. The real costs are engineering time to make a model export cleanly, testing on each target runtime, and keeping the opset version aligned with what the deployment engine supports. ONNX Runtime offers APIs for Python, C#, JavaScript, Java and C++, among others, and runs on Linux, Windows, macOS, iOS, Android and in web browsers.