Comparing two model files

Load two files of the same format to create a path-by-path comparison. The report marks common values, changed values, and entries found in only one file.

Fields common to both formats

Every comparison includes the file name and size, format, default context setting, estimated weight RAM, estimated KV-cache RAM, estimated total RAM, header values, and displayed metadata. Values are converted to their displayed text before comparison. Arrays are serialized by the same formatter used in the metadata view.

File names are therefore expected to differ and do not indicate a structural change. Estimated totals can differ because file size or parsed model information differs.

GGUF comparison

For GGUF, the report also compares every tensor descriptor under a path based on its tensor name. It checks dimensions, numeric GGML type, and tensor offset. This is useful for comparing quantized variants, checking whether metadata changed during conversion, and spotting added or removed tensor descriptors.

A different GGML type or file size can be consistent with a different quantization. The comparison does not decode tensor data, so it cannot show how individual weight values changed or prove that two tensors contain equivalent values.

ONNX comparison

For ONNX, the report compares the graph name; each declared input and output type; and each top-level node's operator type, domain, input names, and output names. Node paths use the saved node name, or their one-based position when no name exists.

This can reveal changed interfaces, operators, graph wiring, model properties, and initializer-related metadata counts. Initializer shapes and types influence memory estimates but are not individually added to the comparison table. Node attribute contents and tensor values are not parsed, so changes there may be invisible.

Practical uses

Compare two GGUF quantizations and check whether tensor shapes stayed the same while storage types and size changed.
Compare converted variants to find architecture, context, tokenizer, or provenance metadata differences.
Check whether an ONNX export changed input shapes, output names, operator types, or tensor connections.
Compare default memory estimates using the same estimator rules.

What comparison cannot establish

A “Common” row means only that the formatted values at that path match. It is not a byte-for-byte comparison, a correctness test, or proof that two models produce the same outputs. The tool does not hash automatically; SHA-256 is available on demand for a single selected file and is calculated locally.

Two models must both be GGUF or both be ONNX. Cross-format comparison is rejected. The report does not align renamed tensors or nodes semantically, inspect GGUF payloads, read ONNX tensor values, or run inference.

Open the inspector, choose two files together or add a second file, and review the summary counts before opening individual values.