ONNX

ONNX describes a model as a graph: nodes are operators, edges are tensors, and the graph carries an explicit opset version that pins which specification every operator in it follows. Tensormorph's importer reads that graph directly into the Semantic Model Graph - this page covers what an ONNX file contains and how Tensormorph maps it in.

Inputs, initializers, and nodes

An ONNX graph has three kinds of named values:

• Inputs - values supplied at inference time (the model's actual runtime inputs).
• Initializers - constants baked into the graph, most commonly the model's learned weights. Tensormorph's ModelAdapter for ONNX maps initializers to weight tensors in the address space; it does not treat them as ordinary inputs, since they never vary at runtime.
• Nodes - the operators themselves (MatMul, Add, Conv, Softmax, and so on), each with typed inputs, outputs, and fixed attributes (parameters set once when the graph was built, not runtime values).

This input/initializer split is the first thing Tensormorph's importer resolves: it determines which nodes in the Architecture view represent structure versus which tensors get exposed as inspectable, potentially-editable weights.

Serialization

ONNX graphs serialize to a single protobuf block. Unlike safetensors' fixed header-then-data-section layout, an ONNX file requires parsing the protobuf structure itself to enumerate tensors - there's no equivalent to a header-only range fetch. Large weights can be externalized into separate data files referenced from the main graph file (keeping the graph-definition file itself small and fast to parse); when Tensormorph encounters an ONNX model that externalizes its weights this way, it applies the same lazy, on-demand loading it uses for any other format, deferring the referenced weight files until something actually needs their bytes.

Dense tensors only - no stride

This matters when comparing an ONNX-imported model against a PyTorch checkpoint of the "same" architecture in Tensormorph's Comparison Editor: every ONNX tensor is, by construction, its own contiguous copy, so the view-vs-copy distinction Tensormorph surfaces for native tensors simply doesn't arise for anything sourced from an ONNX graph.

Opset version and shape inference

Every operator in a graph resolves to a specific version of its specification based on the graph's declared opset - Add behaves differently under opset 7 than under opset 14, for instance. Tensormorph's importer reads the opset alongside the graph so that node behavior (and therefore anything the Runtime Flow view shows about a node) is interpreted against the correct operator version, not just the latest one.

ONNX also supports static shape inference - propagating tensor shapes through the graph from the known input shapes, before execution. Where present, Tensormorph uses this to populate shape labels on every graph edge immediately on import, the same way it would from a torch.export-style graph, rather than waiting for a first run to discover shapes empirically.

Metadata

ONNX models carry a small set of always-available, unstructured metadata fields at the model level - doc_string, producer_name, model_version, model_author, and a free-form metadata_props string map. Tensormorph reads these into a model's provenance fields as a minimal layer, distinct from (and much sparser than) the structured card metadata available for models sourced from a Hub-style repository; see Model Cards.

Related resources

• Model, Architecture, Layer and Module - how an imported graph populates the Semantic Model Graph.
• Safetensors - contrast with a format that externalizes weights outside any graph structure at all.