Model converter

The form onnx.parser.parse_graph / parse_model accept. It is parsed into a model by the WebAssembly module (a bare graph is wrapped into a model with a default-domain opset import) and shown in the Before Netron pane. Local function definitions (<domain: "..."> name (...) => (...) {...} blocks after the graph) are parsed too, and the wrapped model gains an opset import for each function's domain so it validates. With convert after parsing on, it is also run straight through the currently selected convert mode below (Simplify / Optimize / Inline functions, or a single debug pass). Extract from loaded model runs this in reverse: it reads back whatever model is currently shown in the Before Netron pane below and fills this box with its textual representation, so it can be inspected and -- after editing -- reparsed.

Quantizes a model with onnxsim's WebAssembly module, entirely in your browser -- nothing is uploaded. Its result is kept independent of the plain Convert section above (it never overwrites the "after" Netron pane or converted inference source) so you can inspect all three stages side by side: original -- onnxsim-simplified (Convert section, optional) -- quantized (its own "Quantized" Netron pane and quantized inference source below).

Check whether INT8 (Dynamic / Static / QOperator's scheme) looks numerically safe for this model -- a static analysis of its own weights and shapes, no execution or calibration data needed, so it runs instantly.

• Dynamic -- MatMul/Gemm weights are quantized to INT8 ahead of time; the activation is quantized at inference time via DynamicQuantizeLinear. No calibration needed.
• Ternary -- like Dynamic, but for weights whose values are already (approximately) ternary ({-1, 0, 1} × scale), e.g. BitNet-style models. No calibration needed.
• Weight-only / Weight-only INT4 -- only the weight is quantized (INT8 / block-wise INT4); the activation is never touched. No calibration needed, smallest download, but needs a runtime that supports on-the-fly dequantization.
• Static (QDQ) -- MatMul/Gemm/Conv are wrapped in QuantizeLinear/DequantizeLinear pairs using a calibrated activation range; the graph still computes in float32, and a QDQ-aware runtime fuses the pattern into an integer kernel. Needs calibration (below).
• QOperator -- MatMul/Gemm are replaced outright with QLinearMatMul, computing directly in int8; also needs a calibrated output range, not just the activation. Needs calibration (below).
• Float16 / BFloat16 / Float8 -- a different kind of "quantization": every weight (and, by default, every internal activation -- a boundary Cast keeps the model's own external input/output types float32) is simply rounded to a narrower floating-point format, not an integer scheme, so no calibration data is needed at all. Float16/BFloat16 halve storage; Float8 (E4M3 or E5M2, below) quarters it, at the cost of the least precision of any format here.

Calibration (Static/QOperator only) runs the model over a few batches of synthetic random input through onnxruntime-web (downloaded on demand, same as the "Run inference" panel below) to observe each quantizable tensor's actual value range -- the same approach onnxsim.calibrate() uses in Python, just run here in the browser instead. Random data is a reasonable stand-in when representative data isn't at hand, but real calibration data (e.g. via the Python API) usually gives tighter, more accurate ranges.

The float model is the teacher, the quantized one is the student, and each block's weights are optimized by Adam so the student reproduces the teacher's own activations at that block's output. The WebAssembly module emits one optimizer step as a plain ONNX inference graph (a hand-derived backward pass is just dataflow -- no autograd, no training runtime) and onnxruntime-web runs that graph in a loop, so the whole training step reaches WebGPU (and WebNN) through the same execution providers the inference panel uses.

What it can and cannot do. The objective is "reproduce what the teacher produced", so it cannot exceed the float model and it is not a way to train on new data or a new task -- it fixes a model something else made worse. With fine-tune only below, the quantizer comes out of the middle and the student's own float weights are trained instead (apply_block_finetune), which is for a pruned or otherwise altered model; the two models have to differ, or there is nothing to learn. Training runs on a handful of calibration rows, so treat the result as a demonstration of the machinery rather than a production tuning run.

By measuring, on synthetic calibration data run through onnxruntime-web, a systematic shift between the float model and the modified one, and adding a constant to cancel it. No training, no gradients -- only ordinary forward passes, so it is much cheaper than fine-tuning, and much more limited.

Per-channel vs per-position. Per-channel (the default) fits a single number per output channel and suits quantization rounding and similar shifts. A Resize mode/ coordinate-transformation swap's error is instead spatially-varying, so tick per-position (spatial) below for that case -- it only helps when the calibration images share real spatial structure (a fixed-mount camera, a consistent framing), and is verified against held-out calibration data before being applied at all: on generic, independent images it correctly does nothing rather than risk making things worse.

Reachable without Python: the WebAssembly module performs the injection and emits one optimizer step as a plain ONNX inference graph, and onnxruntime-web runs that graph in a loop, exactly as the QAT panel above does for its own step graph.

What it can and cannot do. The adapter is trained to reproduce a reference model's own output on the same inputs, so the two models have to differ or there is nothing to learn -- a natural pairing is base = onnxsim-simplified against reference = the original upload, patching back whatever simplification changed with a small trainable branch instead of a full re-tune. It trains on a handful of calibration rows, so treat the result as a demonstration of the machinery rather than a production adapter. QLoRA (composing this with an NF4-quantized base) and caller-supplied training targets (rather than a reference model) are not wired into this panel yet -- see lora_finetune.mjs's own top comment. Exporting to ONNX Runtime's native .onnx_adapter format (export_lora_adapter) needs its Python onnxruntime.AdapterFormat API, which has no C++ counterpart to reach from wasm, so this panel exports the trained full model only.

A tiny two-layer network, onnxsim.graph_grad/qat_graph's own gradient/Adam step graph, trained on real data fetched live from Hugging Face -- this fails loudly on a browser without WebGPU, rather than silently training somewhere else. See webgpu_hf_demo.mjs and test/make_step_graph_fixtures.py for exactly what each demo trains and why.