1. onnx 结构分析
onnx 简介：https://github.com/onnx/onnx/blob/master/docs/Overview.md
onnx将每一个网络的每一层或者说是每一个算子当作节点Node，再由这些Node去构建一个Graph，相当于是一个网络。最后将Graph和这个onnx模型的其他信息结合在一起，生成一个model，也就是最终的.onnx的模型；
Components
ONNX is an open specification that consists of the following components:
- A definition of an extensible computation graph model.
- Definitions of standard data types.
- Definitions of built-in operators.
两类：
the main distinction between the two is found in the supported types and the default operator sets. The neural-network-only ONNX variant recognizes only tensors as input and output types, while the Classical Machine Learning extension, ONNX-ML, also recognizes sequences and maps. ONNX-ML extends the ONNX operator set with ML algorithms that are not based on neural networks.
Upto IR version 6, the ONNX specification and model format addressed only inference (also known as scoring). Starting from IR version 7, the ONNX specification and model format has been extended to support training. An ONNX training-model itself is an extension of the inference-model and allows an inference-only runtime to ignore the training-related extensions and run inference. In typical usage scenarios, however, an inference-only model may enable a more optimized model-representation (for inference purposes) than a training-model.
Runtime Agnostic
ONNX does not pre-suppose or imply any particular method of runtime implementation.
For example, an implementation may consist of a rich runtime which interprets the model; it may be a code generator that translates the model in its entirety to executable code for some target programming language; it may be a hardware implementation; it may be a combination of two or three of those.
Nothing in this specification should be construed as advocating one implementation approach over any other; any comments on the inner workings of concrete implementations are to be interpreted as examples.
Models
The top-level ONNX construct is a ‘Model.’, and is represented in protocol buffers as the type onnx.ModelProto
The main purpose of the model structure is to associate metadata with a graph, which is what contains all the executable elements. The metadata is used when first reading the model file, giving an implementation the information that it needs in order to determine whether it will be able to execute the model, generate logging messages, error reports, etc. Further, the metadata is useful to tools, such as IDEs and model galleries, which need it for informing humans about a given model’s purpose and characteristics.
Each model has the following components:
| Name | Type | Description |
|---|---|---|
| ir_version | int64 | The ONNX version assumed by the model. |
| opset_import | OperatorSetId | A collection of operator set identifiers made available to the model. An implementation must support all operators in the set or reject the model. |
| producer_name | string | The name of the tool used to generate the model. |
| producer_version | string | A string representing the version of the generating tool. |
| domain | string | A reverse-DNS name to indicate the model namespace or domain, for example, ‘org.onnx’ |
| model_version | int64 | A version of the model itself, encoded in an integer. |
| doc_string | string | A human-readable documentation for this model. Markdown is allowed. |
| graph | Graph | The parameterized graph that is evaluated to execute the model. |
| metadata_props | map<string,string> | Named metadata values; keys should be distinct. |
| training_info | TrainingInfoProto[] | An optional extension that contains information for training. |
Models MUST specify a domain and use reverse domain names based on the responsible organization’s identity, the same convention that is traditionally used for naming Java packages.
Note: Exploring an ONNX file
You can use the protoc tool that is part of the Protocol Buffers distribution to examine the contents of an ONNX file, you do so like this:
$ protoc --decode=onnx.ModelProto onnx.proto < yourfile.onnx
Where onnx.proto is the file that is part of this repository.
Alternatively, you can use a tool like Netron to explore the ONNX file.
Optional Metadata
The ‘metadata_props’ field in the model is available for any kind of optional metadata that a tool or model developer chooses to place there. The following are the defined “standard” optional metadata properties of a model.
Operator Sets
Each model MUST explicitly name the operator sets that it relies on for its functionality… All models implicitly import the default ONNX operator set.
Operators
Each operator used within a graph MUST be explicitly declared by one of the operator sets imported by the model.
The properties of an operator definition are:
| Name | Type | Description |
|---|---|---|
| op_type | string | The name of the operator, as used in graph nodes. MUST be unique within the operator set’s domain. |
| since_version | int64 | The version of the operator set when this operator was introduced. |
| status | OperatorStatus | One of ‘EXPERIMENTAL’ or ‘STABLE.’ |
| doc_string | string | A human-readable documentation string for this operator. Markdown is allowed. |
Graphs
A graph is used to describe a side-effect-free computation (function). A serialized graph is comprised of a set of metadata fields, a list of model parameters, and a list of computation nodes.
Each computation dataflow graph is structured as a topologically sorted list of nodes that form a graph, which MUST be free of cycles. Each node represents a call to an operator. Each node has zero or more inputs and one or more outputs.
Graphs have the following properties:
ValueInfo has the following properties:
Names Within a Graph
All names MUST adhere to C identifier syntax rules.
Names of nodes, inputs, outputs, initializers, and attributes are organized into several namespaces. Within a namespace, each name MUST be unique for each given graph. Please see below for further clarification in the case where a graph contains nested subgraphs (as attribute values).
The namespaces are:
| Namespace | Description |
|---|---|
| Attribute | The names of attributes of an operator. Unique for each operator. |
| Value | The names of values – node inputs & outputs, tensor values (if named), graph inputs, outputs. |
| Node | The names of graph nodes. |
| Graph | The names of graphs within a domain, unique within the model domain. |
| Operator | The names of operators within a domain. |
| Shape | The names of tensor shape variables – scoped to the value information records of a graph, which is where shape variables occur. |
Nodes
Computation nodes are comprised of a name, the name of an operator that it invokes, a list of named inputs, a list of named outputs, and a list of attributes.
Input and outputs are positionally associated with operator inputs and outputs. Attributes are associated with operator attributes by name.
They have the following properties:
Attributes
Attribute values are only found in nodes, passed to operators by name association. Attribute values are runtime constants, in that their values are determined when a model graph is constructed and therefore not computed at runtime. A common use for attributes is to represent coefficients established during model training.
Attributes have the following properties:
Standard data types
ONNX :
recognizes only tensors as input and output types, while the Classical Machine Learning extension.
ONNX-ML:
also recognizes sequences and maps.
The following data types are supported by ONNX for inputs and outputs of graphs and nodes as well as the the initializers of a graph.
Primitive numeric, string, and Boolean types MUST be used as elements of tensors.
Tensor Element Types
Input / Output Data Types
