Burn replaces the ONNX export step with one Rust codebase

One codebase instead of an ONNX export

The pitch starts from a failure anyone doing machine learning in two languages has hit. You train a model, then you need it to run somewhere else, so you export it to ONNX or hand it to vLLM, ONNX Runtime or TensorRT. That export step is described as often brittle and lossy, and the consequence is specific rather than general: complex architectures and advanced deployment use cases get ruled out, because they are exactly the ones that do not survive the crossing.

Burn's answer is to remove the crossing. Multi-platform tensor operations run through a single unified API, so the code that trains is the code that runs in production. The workloads named as beneficiaries are on-device personalization and federated learning, both cases where maintaining a second inference build is hard to justify, and the stated outcome is moving from prototype to deployment inside one codebase.

The price of that unification is committing to Rust for both halves. For a team already training in Python the question is not whether one codebase beats two. It is who maintains it, and whether the export you currently tolerate is cheaper than a Rust learning curve.

Dynamic graphs that a JIT compiler fuses

Two properties usually trade against each other in this space, and the argument here is that they need not. You keep the ergonomics of PyTorch, with dynamic shapes and dynamic graphs, and in exchange a JIT compiler processes streams of tensor operations and performs automatic kernel fusion. Nothing in the model code has to be rewritten into a static graph for the compiler to see it.

Fusion is where the substantive claim sits. A sequence of small operations on an accelerator pays launch and memory round-trip costs at every step, and fusing adjacent ones removes most of them. Getting that automatically, without writing a graph rewrite pass, is the part that changes the arithmetic of a forward pass.

What the README does not do is quantify any of it. It says you get dynamic graphs without the performance drop, and it points to `burn-bench` in the ecosystem table, described as a project to benchmark and compare backends and track performance over time. That is the place to measure rather than the place to read a number. The mechanism is documented. The result is somebody else's to produce.

The five-second claim arrives with no benchmark

The section aimed at researchers makes exactly one quantitative statement: designed around incremental compilation, modifying model code recompiles in under 5 seconds, even in release mode. The problem it attacks is stated first, that long Rust compilation times disrupted the edit-compile-run loop that draws researchers to Python.

Treat the figure as an assertion rather than a measurement, because the README states it in prose with no measurement beside it. No machine is named. No model size is named. No distinction is drawn between a warm dependency cache and a cold one. The sentence sits in prose rather than beside a table of results, and the ecosystems table points at burn-bench for measurement without printing anything from it.

This is the claim that decides whether Rust is workable for research at all, which makes its thinness more consequential than most missing numbers. If your models are large or your loop is measured in minutes, under five seconds may describe a case that resembles nothing you intend to run. The repository carries `benchmarks.toml` and a dedicated benchmarking project, so the measurement is available to make. Neither is a substitute for making it on your own code.

Fusion and remote execution stop at the backend boundary

Backend support is not a flat list, and the grouping matters more than the membership. The CubeCL backends, covering CUDA, ROCm, Metal, Vulkan, WebGPU and CPU, compose with autodiff, with fusion and with remote-execution decorators. The pure-Rust Flex CPU/`no_std` backend composes with autodiff only.

Read that as a capability gradient. Choosing the Flex CPU/`no_std` path for a constrained target buys you differentiation and nothing more: automatic kernel fusion and remote execution are not on it. That is a real reduction rather than a rounding error, and it lands hardest exactly where you can least afford it, on the smallest devices. The examples reflect that spread, carrying both `mnist-inference-web` and `remote-inference-web` beside more conventional training examples such as `mnist`, `simple-regression`, `wgan` and `modern-lstm`.

A Supported Backends section is pointed at for the full matrix, so anyone targeting a specific accelerator should confirm the combination there rather than infer it from the grouping described here.

burn-onnx and burn-store are the actual Python bridge

The Python ecosystem gets handled by two crates rather than by the core. `burn-onnx` imports ONNX models into Burn as native Rust code, so a model that already exists arrives as a Rust program instead of a serialized blob the framework has to interpret at runtime. `burn-store` saves, loads and imports weights, and its description names PyTorch and Safetensors in particular, which is the migration route in both directions: bring the numbers across, then rewrite the graph.

Around those sit the domain crates. `burn-vision` holds computer vision operators and building blocks, `burn-rl` holds reinforcement learning building blocks, and `burn-dataset` covers loading, transforms and ready-made sources. Curated pre-trained models and further examples live in a separate `models` repository.

What none of those descriptions quantify is fidelity. The README argues that exporting is lossy, then offers import tooling, so if one specific model has to come across, check how much of its graph burn-onnx supports before relying on it.

Every example is a workspace member except three

The Cargo workspace exposes the repository's testing strategy. Members are `crates/*`, `xtask`, every directory under `examples/`, and two test crates devoted to weight import:

members = [
    "crates/*",
    "crates/burn-store/pytorch-tests",
    "crates/burn-store/safetensors-tests",
    "examples/*",
    "xtask",
]

exclude = [
    "examples/notebook",
    "examples/dqn-agent",         # gym-rs
]

Two dedicated crates for PyTorch and Safetensors loading tell you that migration path is exercised rather than advertised. The exclusion list is equally informative. `examples/notebook` is held out, so the notebook example is not built by the workspace. `examples/dqn-agent` is held out with an inline comment naming gym-rs, meaning a reinforcement learning agent pinned to a crate the workspace will not take.

So the example tree is broader than the code that compiles on every commit, and knowing which two sit outside is the difference between reproducing a CI run and guessing at it.

A pre-release version and a stack you did not choose

Version is where a reader should slow down. The workspace declares `0.23.0-pre.1`, and the recent releases are v0.23.0-pre.1 on 2026-10-29, v0.22.1 on 2026-10-20 and v0.22.0 on 2026-10-06. The last push to main was 2026-11-02, so main is already on the next pre-release line. Pin the exact version and expect the API to shift within a minor release.

The licence is the easy part. Cargo.toml declares `MIT OR Apache-2.0`, and the repository root carries LICENSE-MIT, LICENSE-APACHE and NOTICES.md, so you pick either. The toolchain is edition 2024 on workspace resolver 3.

The adoption surface deserves more thought than the licence. Alongside the core sit CubeCL, burn-onnx, burn-vision, burn-rl, burn-dataset, burn-store, a models repository and burn-bench, all under one organisation. Then a community crate table naming polars, arrow-rs, image, hf-hub, tokenizers, rust-bert, ndarray and nalgebra, and those are explicitly not maintained by Tracel. You are joining a stack, and the parts you did not choose carry their own release cadences.

Editorial conclusion

Burn fits a team that wants training and serving in one Rust codebase, especially for on-device or federated work where an ONNX export step is the wrong shape, and the CubeCL backends cover the accelerators most deployments target. Be careful if you need a stable API, because main has already moved to 0.23.0-pre.1 after the 0.22.0 and 0.22.1 releases, and the Flex CPU/no_std backend gives up kernel fusion and remote execution. Before committing, measure the incremental recompile claim on your own hardware and your own model size, since the README states under five seconds without naming a machine, and check burn-onnx against the specific graph you need to import.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. tracel-ai/burn on GitHub