Burn ONNX 0.21.0 Release<br>nav]:order-last default:sections:max-w-[1500px] bg-[#0D1117]"> home · blog · release-burn-onnx-0.21.0

Burn ONNX 0.21.0 Release

Thu, May 14, 2026<br>Dilshod Tadjibaev

This is the first release of burn-onnx from its own repository. The crate that<br>used to live inside tracel-ai/burn as burn-import now ships as tracel-ai/burn-onnx [1] and tracks Burn 0.21.0, with a dedicated CI<br>gate, a new test infrastructure, and 300 commits worth of operator coverage, opset cleanup,<br>and real-world model verification on top of Burn 0.20.0.

For users, the practical result is broader model coverage, smaller generated code, and a<br>regression suite that now tracks upstream ONNX behavior instead of only local fixtures.

Table Of Contents<br>1.What is Burn ONNX?<br>2.Headline Numbers<br>3.The Big Change: a Dedicated Repository<br>4.The New ONNX Official-Test Gate<br>5.Graph Simplification in onnx-ir<br>6.Architecture Upgrades 6.1.ScalarTensor and ScalarNative<br>6.2.Submodule Partitioning for Large Models<br>6.3.Memory-Mapped Loading and Burnpack Weights<br>6.4.External Data for Large Models<br>6.5.Backend Swap: ndarray to flex<br>6.6.The New LoadStrategy Enum

7.New and Expanded Operator Coverage<br>8.Opset Coverage, 1 through 24<br>9.Real-World Model Verification<br>10.Breaking Changes and Migration<br>11.What's Next

What is Burn ONNX?<br>burn-onnx imports ONNX models into the Burn<br>[2] deep learning framework. Unlike runtime-based importers,<br>it works at build time:

You point burn-onnx at an .onnx file from your build.rs.

It reads the model and emits a model.rs source file plus a model.bpk weight file.

You include the generated Rust as a normal module and call Model::from_file(bpk_path, &device) from your code.

The output is plain Burn Rust. No graph runtime, no protobuf at runtime. The forward pass<br>is something you can read, step through in a debugger, and modify by hand if you need to.<br>Because the result is just Burn code, imported models can target Burn backends such as CPU<br>via Flex or NdArray, GPU via WGPU or CUDA, and WebAssembly or no_std embedded builds<br>when the generated ops and load strategy fit that target.

If you just want to inspect the generated code without wiring up build.rs,<br>the onnx2burn CLI ships with the crate:

cargo run -p burn-onnx --bin onnx2burn -- model.onnx ./out<br># writes ./out/model.rs and ./out/model.bpk<br>The project is split into two layers:<br>onnx-ir parses the ONNX protobuf wire format into a clean intermediate<br>representation. It hides the protobuf complexity (versioned attributes, opset rules, external<br>data, type inference, optional inputs) behind a typed Node enum and a NodeProcessor trait. It also performs graph-level normalization such as shape propagation, constant folding,<br>common subexpression elimination, and dead-node elimination.

burn-onnx consumes that IR and generates Burn Rust. It owns<br>the Burn-specific lowering: how to map IR nodes onto Burn tensor and module APIs, how to choose<br>Burn layouts such as LinearLayout, and how to collect parameters into the Burnpack [3] weight file.

The aim is full ONNX compliance . We track our progress against the<br>upstream ONNX backend test suite[4]<br>(1,615 tests at v1.19.0) and a growing set of real-world exported models, and 0.21.0 is the<br>release where that goal became a measurable target with a CI gate behind it.

Headline Numbers<br>160 supported ONNX operators out of the 201 canonical operators catalogued<br>in the support matrix, with dimension-specific Burn rows collapsed and Linear excluded.

174 node-type processors registered in onnx-ir.<br>1,615 upstream ONNX backend tests vendored at ONNX v1.19.0.<br>896 are in the pass + fail-compare set, meaning<br>generated Rust gets past the skip buckets and is tracked by the compile/compare gate.

717 are classified as pass (80% of that set, 44% of the full<br>vendored suite).

27 model-check crates covering more than two dozen real-world models and<br>variants, including Stable Diffusion XL, Qwen, Kokoro TTS, Depth-Pro, ModernBERT, RF-DETR,<br>YOLO 12x, ResNet-50, CLIP ViT-B/32, and Silero VAD.

Opset coverage gate : 472 of 472 generated operator/spec-version checks<br>green across ONNX opsets 1 through 24.

300 commits and 21 contributors since Burn 0.20.0.

The Big Change: a Dedicated Repository

ONNX import has a different release cadence, contributor base, and surface area than the<br>rest of Burn. Inside the monorepo it was held to Burn's release schedule even when an<br>ONNX-only fix was ready to ship. The Burn repo split it out, and on January 27, 2026,<br>tracel-ai/burn-onnx [1] went live with its own CI, its own issue tracker,<br>and its own daily workflow that follows Burn's main branch and opens automated<br>bump-burn PRs.

The legacy burn-import crate is still published as a thin re-export shim around<br>burn-onnx, so existing users get a one-line migration path:

# Before<br>[build-dependencies]<br>burn-import = "0.20"

# After<br>[build-dependencies]<br>burn-onnx = "0.21"<br>The New ONNX Official-Test Gate

The new crates/onnx-official-tests crate vendors the upstream ONNX...