onnx.onnx

A human-readable documentation for this attribute. Markdown is allowed.

Exactly ONE of the following fields must be present for this version of the IR float

list of floats

graph

list of graph

int

list of ints

The name field MUST be present for this version of the IR. namespace Attribute

if ref_attr_name is not empty, ref_attr_name is the attribute name in parent function. In this case, this AttributeProto does not contain data, and it's a reference of attribute in parent scope. NOTE: This should ONLY be used in function (sub-graph). It's invalid to be used in main graph.

UTF-8 string

sparse tensor value

list of sparse tensors

list of UTF-8 strings

tensor value

list of tensors

The type field MUST be present for this version of the IR. For 0.0.1 versions of the IR, this field was not defined, and implementations needed to use has_field heuristics to determine which value field was in use. For IR_VERSION 0.0.2 or later, this field MUST be set and match the f|i|s|t|... field in use. This change was made to accommodate proto3 implementations. discriminator that indicates which field below is in use

A human-readable documentation for this graph. Markdown is allowed.

A list of named tensor values, used to specify constant inputs of the graph. Each initializer (both TensorProto as well SparseTensorProto) MUST have a name. The name MUST be unique across both initializer and sparse_initializer, but the name MAY also appear in the input list.

The inputs and outputs of the graph.

The name of the graph. namespace Graph

The nodes in the graph, sorted topologically.

This field carries information to indicate the mapping among a tensor and its quantization parameter tensors. For example: For tensor 'a', it may have {'SCALE_TENSOR', 'a_scale'} and {'ZERO_POINT_TENSOR', 'a_zero_point'} annotated, which means, tensor 'a_scale' and tensor 'a_zero_point' are scale and zero point of tensor 'a' in the model.

Initializers (see above) stored in sparse format.

Information for the values in the graph. The ValueInfoProto.name's must be distinct. It is optional for a value to appear in value_info list.

A human-readable documentation for this model. Markdown is allowed.

Domain name of the model. We use reverse domain names as name space indicators. For example: com.facebook.fair or com.microsoft.cognitiveservices Together with model_version and GraphProto.name, this forms the unique identity of the graph.

The parameterized graph that is evaluated to execute the model.

The version of the IR this model targets. See Version enum above. This field MUST be present.

Named metadata values; keys should be distinct.

The version of the graph encoded. See Version enum below.

The OperatorSets this model relies on. All ModelProtos MUST have at least one entry that specifies which version of the ONNX OperatorSet is being imported. All nodes in the ModelProto's graph will bind against the operator with the same-domain/same-op_type operator with the HIGHEST version in the referenced operator sets.

The name of the framework or tool used to generate this model. This field SHOULD be present to indicate which implementation/tool/framework emitted the model.

The version of the framework or tool used to generate this model. This field SHOULD be present to indicate which implementation/tool/framework emitted the model.

Training-specific information. Sequentially executing all stored TrainingInfoProto.algorithms and assigning their outputs following the corresponding TrainingInfoProto.update_bindings is one training iteration. Similarly, to initialize the model (as if training hasn't happened), the user should sequentially execute all stored TrainingInfoProto.initializations and assigns their outputs using TrainingInfoProto.initialization_bindings. If this field is empty, the training behavior of the model is undefined.

Additional named attributes.

A human-readable documentation for this node. Markdown is allowed.

The domain of the OperatorSet that specifies the operator named by op_type. namespace Domain

namespace Value

An optional identifier for this node in a graph. This field MAY be absent in ths version of the IR. namespace Node

The symbolic identifier of the Operator to execute. namespace Operator

namespace Value

The domain of the operator set being identified. The empty string ("") or absence of this field implies the operator set that is defined as part of the ONNX specification. This field MUST be present in this version of the IR when referring to any other operator set.

The version of the operator set being identified. This field MUST be present in this version of the IR.

The shape of the underlying dense-tensor: [dim_1, dim_2, ... dim_rank]

The indices of the non-default values, which may be stored in one of two formats. (a) Indices can be a tensor of shape [NNZ, rank] with the [i,j]-th value corresponding to the j-th index of the i-th value (in the values tensor). (b) Indices can be a tensor of shape [NNZ], in which case the i-th value must be the linearized-index of the i-th value (in the values tensor). The linearized-index can be converted into an index tuple (k_1,...,k_rank) using the shape provided below. The indices must appear in ascending order without duplication. In the first format, the ordering is lexicographic-ordering: e.g., index-value [1,4] must appear before [2,1]

The sequence of non-default values are encoded as a tensor of shape [NNZ]. The default-value is zero for numeric tensors, and empty-string for string tensors. values must have a non-empty name present which serves as a name for SparseTensorProto when used in sparse_initializer list.

<key, value> pairs to annotate tensor specified by <tensor_name> above. The keys used in the mapping below must be pre-defined in ONNX spec. For example, for 8-bit linear quantization case, 'SCALE_TENSOR', 'ZERO_POINT_TENSOR' will be pre-defined as quantization parameter keys.

If value not set, data is stored in raw_data (if set) otherwise in type-specified field.

The data type of the tensor. This field MUST have a valid TensorProto.DataType value

The shape of the tensor.

A human-readable documentation for this tensor. Markdown is allowed.

For double Complex128 tensors are encoded as a single array of doubles, with the real components appearing in odd numbered positions, and the corresponding imaginary component appearing in the subsequent even numbered position. (e.g., [1.0 + 2.0i, 3.0 + 4.0i] is encoded as [1.0, 2.0 ,3.0 ,4.0] When this field is present, the data_type field MUST be DOUBLE or COMPLEX128

Data can be stored inside the protobuf file using type-specific fields or raw_data. Alternatively, raw bytes data can be stored in an external file, using the external_data field. external_data stores key-value pairs describing data location. Recognized keys are:

• "location" (required) - POSIX filesystem path relative to the directory where the ONNX protobuf model was stored
• "offset" (optional) - position of byte at which stored data begins. Integer stored as string. Offset values SHOULD be multiples 4096 (page size) to enable mmap support.
• "length" (optional) - number of bytes containing data. Integer stored as string.
• "checksum" (optional) - SHA1 digest of file specified in under 'location' key.

For float and complex64 values Complex64 tensors are encoded as a single array of floats, with the real components appearing in odd numbered positions, and the corresponding imaginary component appearing in the subsequent even numbered position. (e.g., [1.0 + 2.0i, 3.0 + 4.0i] is encoded as [1.0, 2.0 ,3.0 ,4.0] When this field is present, the data_type field MUST be FLOAT or COMPLEX64.

For int32, uint8, int8, uint16, int16, bool, and float16 values float16 values must be bit-wise converted to an uint16_t prior to writing to the buffer. When this field is present, the data_type field MUST be INT32, INT16, INT8, UINT16, UINT8, BOOL, or FLOAT16

For int64. When this field is present, the data_type field MUST be INT64

Optionally, a name for the tensor. namespace Value

Serializations can either use one of the fields above, or use this raw bytes field. The only exception is the string case, where one is required to store the content in the repeated bytes string_data field. When this raw_data field is used to store tensor value, elements MUST be stored in as fixed-width, little-endian order. Floating-point data types MUST be stored in IEEE 754 format. Complex64 elements must be written as two consecutive FLOAT values, real component first. Complex128 elements must be written as two consecutive DOUBLE values, real component first. Boolean type MUST be written one byte per tensor element (00000001 for true, 00000000 for false). Note: the advantage of specific field rather than the raw_data field is that in some cases (e.g. int data), protobuf does a better packing via variable length storage, and may lead to smaller binary footprint. When this field is present, the data_type field MUST NOT be STRING or UNDEFINED

For strings. Each element of string_data is a UTF-8 encoded Unicode string. No trailing null, no leading BOM. The protobuf "string" scalar type is not used to match ML community conventions. When this field is present, the data_type field MUST be STRING

For uint64 and uint32 values When this field is present, the data_type field MUST be UINT32 or UINT64

This field represents a training algorithm step. Given required inputs, it computes outputs to update initializers in its own or inference graph's initializer lists. In general, this field contains loss node, gradient node, optimizer node, increment of iteration count. An execution of the training algorithm step is performed by executing the graph obtained by combining the inference graph (namely "ModelProto.graph") and the "algorithm" graph. That is, the actual the actual input/initializer/output/node/value_info/sparse_initializer list of the training graph is the concatenation of "ModelProto.graph.input/initializer/output/node/value_info/sparse_initializer" and "algorithm.input/initializer/output/node/value_info/sparse_initializer" in that order. This combined graph must satisfy the normal ONNX conditions. Now, let's provide a visualization of graph combination for clarity. Let the inference graph (i.e., "ModelProto.graph") be tensor_a, tensor_b -> MatMul -> tensor_c -> Sigmoid -> tensor_d and the "algorithm" graph be tensor_d -> Add -> tensor_e The combination process results tensor_a, tensor_b -> MatMul -> tensor_c -> Sigmoid -> tensor_d -> Add -> tensor_e Notice that an input of a node in the "algorithm" graph may reference the output of a node in the inference graph (but not the other way round). Also, inference node cannot reference inputs of "algorithm". With these restrictions, inference graph can always be run independently without training information. By default, this field is an empty graph and its evaluation does not produce any output. Evaluating the default training step never update any initializers.

This field describes a graph to compute the initial tensors upon starting the training process. Initialization graph has no input and can have multiple outputs. Usually, trainable tensors in neural networks are randomly initialized. To achieve that, for each tensor, the user can put a random number operator such as RandomNormal or RandomUniform in TrainingInfoProto.initialization.node and assign its random output to the specific tensor using "initialization_binding". This graph can also set the initializers in "algorithm" in the same TrainingInfoProto; a use case is resetting the number of training iteration to zero. By default, this field is an empty graph and its evaluation does not produce any output. Thus, no initializer would be changed by default.

This field specifies the bindings from the outputs of "initialization" to some initializers in "ModelProto.graph.initializer" and the "algorithm.initializer" in the same TrainingInfoProto. See "update_binding" below for details. By default, this field is empty and no initializer would be changed by the execution of "initialization".

Gradient-based training is usually an iterative procedure. In one gradient descent iteration, we apply x = x - r * g where "x" is the optimized tensor, "r" stands for learning rate, and "g" is gradient of "x" with respect to a chosen loss. To avoid adding assignments into the training graph, we split the update equation into y = x - r * g x = y The user needs to save "y = x - r * g" into TrainingInfoProto.algorithm. To tell that "y" should be assigned to "x", the field "update_binding" may contain a key-value pair of strings, "x" (key of StringStringEntryProto) and "y" (value of StringStringEntryProto). For a neural network with multiple trainable (mutable) tensors, there can be multiple key-value pairs in "update_binding". The initializers appears as keys in "update_binding" are considered mutable variables. This implies some behaviors as described below.

1. We have only unique keys in all "update_binding"s so that two variables may not have the same name. This ensures that one variable is assigned up to once.
2. The keys must appear in names of "ModelProto.graph.initializer" or "TrainingInfoProto.algorithm.initializer".
3. The values must be output names of "algorithm" or "ModelProto.graph.output".
4. Mutable variables are initialized to the value specified by the corresponding initializer, and then potentially updated by "initializer_binding"s and "update_binding"s in "TrainingInfoProto"s. This field usually contains names of trainable tensors (in ModelProto.graph), optimizer states such as momentums in advanced stochastic gradient methods (in TrainingInfoProto.graph), and number of training iterations (in TrainingInfoProto.graph). By default, this field is empty and no initializer would be changed by the execution of "algorithm".

An optional denotation can be used to denote the whole type with a standard semantic description as to what is stored inside. Refer to https://github.com/onnx/onnx/blob/master/docs/TypeDenotation.md#type-denotation-definition for pre-defined type denotations.

A human-readable documentation for this value. Markdown is allowed.

This field MUST be present in this version of the IR. namespace Value

This field MUST be present in this version of the IR for inputs and outputs of the top-level graph.