# Burn: a Rust tensor library and deep learning framework with one code path for training and inference

> Burn unifies training and inference in a single Rust codebase, JIT-compiling tensor operation streams with automatic kernel fusion across CUDA, ROCm, Metal, Vulkan, WebGPU and CPU backends. It is aimed at teams who want to avoid the brittle Python-to-ONNX export step, and it asks them to accept Rust's build model and a pre-1.0 API in return.

**tracel-ai/burn** — Burn is a next generation tensor library and Deep Learning Framework that doesn't compromise on flexibility, efficiency and portability.

- Repository: https://github.com/tracel-ai/burn
- Website: https://burn.dev
- Stars: 15,939 · Forks: 1,052
- Language: Rust
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/tracel-ai-burn

## What Burn solves: the export step between training and production

The README opens with a specific complaint. Training and inference usually live in separate worlds: a model is trained in Python, then exported to an open format such as ONNX or optimized for a production engine like vLLM, ONNX Runtime or TensorRT. Burn's authors call that export step "often brittle and lossy" and say it rules out complex architectures and advanced deployment use cases.

Burn's answer is to remove the step. Multi-platform tensor operations run through a single unified API, so according to the README "the exact code used for training is the exact code that runs in production." That matters most for workloads where the model has to keep adapting after deployment: on-device personalization and federated learning are the two the project names. The repository reflects that ambition in its examples directory, which includes p2p-remote-training, remote-inference-web and server alongside mnist and text-classification.

The intended audience is narrower than "anyone doing machine learning." It is engineers who are already comfortable in Rust, or who are willing to become so, and who have been burned by the gap between a Python training script and the artifact that actually serves traffic.

## How Burn works: dynamic graphs, JIT-compiled streams and kernel fusion

Burn keeps PyTorch-style ergonomics, with dynamic shapes and dynamic graphs, but does not interpret them one operation at a time. The README states that Burn JIT-compiles streams of tensor operations and performs automatic kernel fusion. The stated goal is the flexibility of a dynamic graph without the performance drop that usually comes with it.

The compute layer underneath is CubeCL, described in the README as a GPU compute language and compiler usable standalone: you write kernels once in Rust and they run on CUDA, ROCm, Metal, Vulkan and WebGPU. Burn's accelerated backends are built on it.

Not every backend gets the same treatment, and this is the part worth reading carefully. The README says CubeCL backends (CUDA, ROCm, Metal, Vulkan, WebGPU, CPU) compose with autodiff, fusion and remote-execution decorators, while external and simpler backends (LibTorch and pure-Rust CPU/no_std) compose with autodiff only. If fusion or remote execution is the reason you are evaluating Burn, the backend choice is not a deployment detail. It decides which decorators are available to you at all.

Around the core sits a set of first-party crates: burn-onnx for importing ONNX models as native Rust code, burn-store for saving, loading and importing weights including PyTorch and Safetensors, plus burn-vision, burn-rl and burn-dataset for domain work. The workspace Cargo.toml lists crates/burn-store/pytorch-tests and crates/burn-store/safetensors-tests as separate workspace members, which tells you weight interop is tested as its own concern rather than folded into the core.

## Installing Burn and running a first example

Burn is published on crates.io, and the README carries the current version badge for the burn crate. The workspace Cargo.toml sets the workspace version to 0.22.0-pre.3 and declares the workspace license as "MIT OR Apache-2.0", so a dependency entry looks like this:

```toml
[dependencies]
burn = "0.22.0-pre.3"
```

Note the pre-release suffix. Cargo will not select a pre-release version for a plain semver requirement unless you ask for it, so the exact string matters when you pin. The README also carries a Minimum Supported Rust Version badge, and the workspace sets edition = "2024", which means your toolchain has to be recent enough for that edition.

The fastest way to see the framework in motion is the examples directory, which is a workspace member. The Cargo.toml workspace members list includes the examples glob, with a few exclusions: examples/notebook, examples/raspberry-pi-pico and examples/dqn-agent (the last excluded because of gym-rs). So the MNIST example builds as part of the workspace. The repository's examples directory contains mnist and mnist-inference-web, the latter being the WebGPU-flavoured browser target, and remote-inference-web shows the remote-execution decorator at work. The repository also ships a burn-book directory alongside the code, which is where the narrative documentation lives rather than in the README.

One build-behaviour claim is worth calling out because it is unusual for Rust. The README says Burn is designed around incremental compilation and that modifying model code recompiles in under 5 seconds, even in release mode. That is a project claim, not something verified here, and it depends on your machine and on how much of the graph you touched.

## Where Burn is the wrong tool

The honest limitation is the release line. The most recent releases listed are v0.22.0-pre.3, v0.22.0-pre.2 and v0.22.0-pre.1, dated 2026-08-25, 2026-08-10 and 2026-07-29. All three are pre-releases. Anyone who needs a stable, long-supported version with a deprecation policy should treat that as the deciding fact, because a pre-release series means the API can move between the versions you upgrade across.

The second limitation is the backend matrix. The README is explicit that LibTorch and the pure-Rust CPU/no_std backends compose with autodiff only. If your plan depends on kernel fusion, and you were intending to lean on LibTorch because that is where your existing models live, the two intentions conflict. You would be choosing between fusion and the LibTorch operator coverage.

The third is ecosystem gravity. Burn preserves PyTorch-like ergonomics, but it is not PyTorch. Models, tutorials and third-party libraries written against PyTorch's Python API do not transfer. burn-onnx exists precisely because importing models from elsewhere is a real need, and an import path is not the same thing as running the original code unchanged.

Finally, the README's own framing of Rust for research concedes the historical objection: long compilation times disrupted the edit-compile-run loop that draws researchers to Python. Burn's answer is incremental compilation, not the absence of a compile step. If your workflow is exploratory and you rewrite model code dozens of times an hour, you are still paying for a compiler.

## Burn compared with PyTorch plus an export path

The real alternative is not another Rust framework. It is the arrangement the README describes at the top: train in PyTorch, export to ONNX or a production engine, serve with ONNX Runtime or TensorRT.

The difference is where the risk sits. In the PyTorch-plus-export arrangement, you get the largest operator ecosystem and the largest body of shared knowledge, and you accept a boundary in the middle of your pipeline. Burn removes that boundary and moves the cost to the other end: you write the whole thing in Rust, you accept the pre-1.0 API, and you accept the backend composition rules. Neither arrangement is free. The PyTorch path pays at export time, when a complex architecture turns out not to survive the conversion. The Burn path pays up front, in language and toolchain adoption.

There is a middle option inside Burn's own ecosystem, and it is worth naming because it is easy to miss. burn-store imports PyTorch and Safetensors weights, and burn-onnx imports ONNX models as native Rust code. That means you can keep training where you train today and move only inference into Burn, which is a smaller commitment than rewriting the training loop. The README does not describe this as a supported migration path, but the crates exist and the workspace tests them separately.

## Maintenance, licensing and what an upgrade costs

The repository is not archived, and the last push was on 2026-09-10, one week before this article. The three most recent releases are pre-releases spaced roughly two to three weeks apart through July and August 2026, which is a fast cadence for a project at this stage.

Licensing is dual: the workspace Cargo.toml declares license = "MIT OR Apache-2.0", and the repository root carries both LICENSE-MIT and LICENSE-APACHE files. The README's badge says the same. Dual MIT/Apache-2.0 is the conventional Rust arrangement and is generally permissive, but the choice between the two is yours to make and depends on your own terms; this is not legal advice, and the LICENSE files are the authority rather than any summary.

Upgrade cost is where the pre-release cadence bites. Three pre-releases of 0.22.0 landed inside a month. If you pin to 0.22.0-pre.3 and upgrade, you are reading changelogs for API movement, not just bug fixes. The workspace also pins edition = "2024" and a resolver = "3", so a toolchain bump is part of the upgrade conversation, not separate from it. The project publishes a contributor-book and a burn-book in the repository, which is where migration guidance would live if the README does not carry it.

## Conclusion

Burn fits teams already writing Rust who need to ship a model to the same codebase that trained it, and who can live with a pre-1.0 API and a backend matrix that changes what composes with what. It is the wrong tool if your team is committed to Python, if you depend on the PyTorch operator surface, or if you need a stable release line today. Before adopting, verify two things in your own environment: that the backend you intend to ship on is one of the CubeCL backends if you need fusion or remote execution, and which of the three 0.22.0 pre-releases your dependency resolution actually selects.

## FAQ

### What is Burn in Rust?

Burn is a tensor library and deep learning framework written in Rust, optimized for numerical computing, training and inference. Its distinguishing claim is that the same code used for training runs in production, removing the export step to ONNX or a production engine.

### Which backends does Burn support?

The README lists CUDA, ROCm, Metal, Vulkan, WebGPU and CPU as CubeCL backends, plus LibTorch and pure-Rust CPU/no_std as external or simpler backends. The CubeCL backends compose with autodiff, fusion and remote-execution decorators; LibTorch and the pure-Rust CPU/no_std backends compose with autodiff only.

### How do I install Burn in a Rust project?

Burn is published on crates.io as the burn crate. The workspace version in the repository is 0.22.0-pre.3, so a dependency entry naming that exact pre-release string is what the current release line corresponds to.

### Is Burn a stable release?

The most recent releases are v0.22.0-pre.3, v0.22.0-pre.2 and v0.22.0-pre.1, so the current line is pre-release. The repository is not archived and the last push was on 2026-09-10.

### Can Burn import existing PyTorch or ONNX models?

The README lists burn-store for saving, loading and importing model weights including PyTorch and Safetensors, and burn-onnx for importing ONNX models into Burn as native Rust code. The workspace Cargo.toml includes crates/burn-store/pytorch-tests and crates/burn-store/safetensors-tests as separate members.

## Sources

- [License: Apache-2.0](https://github.com/tracel-ai/burn/blob/main/LICENSE)
- [Project website](https://burn.dev)
- [README](https://github.com/tracel-ai/burn/blob/main/README.md)
- [Releases](https://github.com/tracel-ai/burn/releases)
- [tracel-ai/burn on GitHub](https://github.com/tracel-ai/burn)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tracel-ai-burn