ONNX is an open specification that consists of the following components:
-
A definition of an extensible computation graph model
-
Definitions of built-in operators and standard data types
Notes on language in this and all related documents:
-
The use of SHOULD, MUST, MAY and so on in this document is consistent with RFC 2119.
-
The use of 'list' shall denote an ordered collection of items, 'set' shall denote an unordered collection of unique elements, and 'bag' an unordered collection of possibly non-unique elements.
ONNX specifies the portable, serialized format of the computation graph. It may not be the form a framework chooses to use and manipulate. For example, a framework may keep the graph in memory in a format that it finds more efficient to manipulate for optimization passes. We make use of protobuf2 (with oneof, added in protobuf 2.6.1) for the serialized format.
Each computation dataflow graph is structured as a list of nodes that form a graph. These nodes MUST be free of cycles. Nodes have one or more inputs and one or more outputs, and each node is a call to an operator.
The following describes the metadata properties of a model graph:
Name | Type | Format | Description |
---|---|---|---|
name | string | Valid C identifier | A name for the model. |
domain | string | Valid DNS name | A namespace for the model, following the style of package names, that is, reverse DNS domain name. |
ir_version | int64 | The version of the IR format specification. | |
doc_string | string | Free form | A human-readable documentation string intended to summarize the purpose of the model. Markdown is allowed. |
Names are organized into separate namespaces, and must be unique within a namespace. The namespaces include the following:
Node
: names that identify specific nodes in the graph, but not necessarily any particular input or output of the node.Graph
: names that identify graphs in the protobuf.Attribute
: names that identify attribute names for extra attributes that are passed to operators.Operator
: names that identify particular operators.Tensor
: names that identify intermediate tensor values flowing through the computation of a graph.
All names MUST adhere to C identifier syntax rules.
Computation nodes are comprised of a name, a list of named inputs and outputs, and a list of attributes.
Edges in the computation graph are established by outputs of one node being referenced by name in the inputs of a subsequent node.
The list of nodes defining the top-level computation graph MUST be ordered topologically – that is, if node K follows node N in the graph, none of the data inputs of N may refer to outputs of K, and no control input of N may refer to K.
See the operator documentation for details.
The following data types are supported by ONNX. Additional data types can be supported by frameworks.
Group | Name | Description |
---|---|---|
Floating Point Types | float16, float32, float64 | Values adhering to the IEEE 754-2008 standard representation of floating-point data. |
Signed Integer Types | int8, int16,int32,int64 | Signed integers are supported for 8-64 bit widths. |
Unsigned Integer Types | uint8,uint16 | Unsigned integers of 8 or 16 bits are supported. |
Complex Types | complex64,complex128 | A complex number with either 32- or 64-bit real and imaginary parts. |
Other | string | Strings represent textual data. All strings are encoded using UTF-8. |
Other | bool | Boolean value represent data with only two values, typically true and false. |
Other | handle | Handles are opaque types holding a 64-bit integer. |
Collections | sparse and dense tensor | Tensors are a generalization of vectors and matrices; whereas vectors have one dimension, and matrices two, tensors can have any number of dimensions, including zero. A zero-dimensional tensor is equivalent to a scalar. |
ONNX is expected to evolve over time and provides features that enable users to experiment and implement additions before they are added to the specifications.
A model allows named metadata strings to be added via its metadata_props
field, typically for use by tools such as converters, indexers, or documentation generators. Names are not prescribed, but some name recommendations are provided for implementations that want to record such concepts.
author
: the name of the person(s) who authored the modelcompany
: the name of the company or organization that authored the modelconverted_from
: if converted from a different format, the name of the source format or frameworklicense
: a human-readable name for a license, if applicablelicense_url
: the URL where the license text is provided
Operators may be extended via custom domain names in the opset_import
field.