Burn: one Rust codebase for training and inference, with CubeCL kernels underneath
Burn is a next generation tensor library and Deep Learning Framework that doesn't compromise on flexibility, efficiency and portability.
At a glance
- What is it?
- Burn is a Rust tensor library and deep learning framework whose stated goal is to remove the Python-to-ONNX export step by running the same code in training and production. This covers the backend matrix, the kernel fusion mechanism, the current pre-release state, and where the approach runs into trouble.
- Who is it for?
- Adopt Burn if your deployment target is Rust, your model uses operations the framework already implements, and you can pin to a released version rather than the 0.22.0 pre-releases. Do not adopt it if you depend on a Python research stack, on pretrained model availability, or on architectures whose operators have not been ported.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The export step Burn is built to remove
The README opens with a diagnosis: training and inference usually live in separate worlds. A model is written in Python, then exported to ONNX or handed to a production engine such as vLLM, ONNX Runtime or TensorRT. Burn's claim is that this export step is often brittle and lossy, and that it rules out complex architectures and advanced deployment cases. The framework's answer is to keep one codebase: the code used for training is the code that runs in production, executing multi-platform tensor operations through a single API.
That framing tells you who the project is for. It is not aimed at researchers who need a Python REPL and a week of GPU time. It is aimed at teams that already intend to ship in Rust and would otherwise maintain two artifacts, a Python training script and an exported graph, plus the glue that keeps them consistent. The README names on-device personalization and federated learning as the workloads that become straightforward under this model, since both require training to happen wherever the model already runs.
Backends, decorators and the composition matrix
Burn's architecture is a set of backends plus a set of decorators that wrap them. The README splits the backends into two groups. The CubeCL backends are CUDA, ROCm, Metal, Vulkan, WebGPU and CPU, and these compose with autodiff, fusion and remote-execution decorators. The external and simpler backends are LibTorch and a pure-Rust CPU backend that supports no_std, and these compose with autodiff only.
That asymmetry is the single most important constraint in the project, and it is easy to skim past. If you pick LibTorch as your backend, you get gradients but not kernel fusion and not remote execution. If you pick a CubeCL backend, you get the full decorator stack. The README points to a Supported Backends table for the complete matrix, and that table is where you should make the decision, not the feature list at the top of the page.
CubeCL is a separate project and is described as a GPU compute language and compiler: you write kernels once in Rust and they run on CUDA, ROCm, Metal, Vulkan and WebGPU. It is usable standalone, which matters if you later want to write custom kernels without leaving the ecosystem. The rest of the ecosystem is laid out the same way: burn-onnx for importing ONNX models as native Rust code, burn-store for saving, loading and importing weights including PyTorch and Safetensors, burn-vision, burn-rl and burn-dataset for domain work, a separate models repository for pretrained checkpoints, and burn-bench for comparing backends over time.
Dynamic graphs with JIT-compiled operation streams
The mechanism the README describes is a hybrid. Burn keeps PyTorch-style ergonomics: dynamic shapes and dynamic graphs. On top of that, it JIT-compiles streams of tensor operations and performs automatic kernel fusion. The stated purpose is to get the flexibility of a dynamic graph without the performance drop that usually accompanies it.
The practical consequence is that a fused stream is a compilation unit. Operations recorded into a stream are compiled together rather than dispatched one at a time, which is where the fusion opportunity comes from. It also means the first execution of a new shape or a new operation sequence pays a compilation cost that a purely eager framework would not charge. The README does not quantify that cost, and I cannot verify it from the material supplied, so treat warmup behaviour as something to measure on your own model rather than assume.
The second mechanism is compilation speed. The README states that Burn is designed around incremental compilation and that modifying model code recompiles in under 5 seconds, even in release mode. That number is a project claim, not an independent measurement. It is also the claim that matters most for the research objection, because the standard argument against Rust for research is that the edit-compile-run loop is too slow to be usable.
Getting a project running
Burn is distributed as a crate named burn on crates.io, and the README links the published documentation at burn.dev/docs/burn. The repository carries a Minimum Supported Rust Version badge, so the MSRV is published per release and should be checked before you upgrade a toolchain. The README does not include a full getting-started command sequence in the material available here, so the install path is the standard Cargo one: add burn to your Cargo.toml dependencies and select a backend feature.
The backend choice is the configuration decision that shapes everything else. Selecting a CubeCL backend such as CUDA, ROCm, Metal, Vulkan, WebGPU or CPU puts you in the group that composes with autodiff, fusion and remote execution. Selecting LibTorch or the no_std pure-Rust CPU backend puts you in the group that composes with autodiff only. If you plan to use fusion, the backend selection is not a performance preference, it is a functional requirement.
For existing models, two crates do the interop work. burn-onnx imports ONNX models into Burn as native Rust code, and burn-store handles weights, including PyTorch and Safetensors formats. The import produces Rust, which means the converted model is source you compile and can edit, not an opaque graph you load at runtime. That is a different trade-off from a runtime that parses ONNX at startup.
The pre-release problem and what it implies for adoption
The three most recent releases listed are v0.22.0-pre.1, v0.22.0-pre.2 and v0.22.0-pre.3, dated 2026-07-29, 2026-08-10 and 2026-08-25. All three are pre-releases. The last push to main is 2026-09-10, which is after the most recent pre-release tag.
What this tells you is that the project is moving quickly and that the 0.22 line is not yet declared stable. For a library you build on, that has a concrete cost: pre-release versions can change API between pre.2 and pre.3, and pinning a pre-release means you own the upgrade work when the stable version lands. The README does not state a stability policy or a release cadence, so the upgrade cost cannot be estimated from the material here. Check the release notes for the specific version you pin before you ship anything.
The version number itself is informative. A 0.x series with active pre-releases is a project where the maintainers still reserve the right to change things. That is not a criticism, but it does mean the migration burden falls on adopters rather than being absorbed by a long-term support commitment.
Where the unified-codebase argument breaks down
The strongest case against Burn is the one the README implicitly concedes: it argues against the export step, not against Python. If your training already happens in PyTorch and your deployment target accepts ONNX Runtime or TensorRT, the export step is a known quantity with tooling around it, and Burn asks you to replace a working pipeline with a Rust rewrite. The gain is real only if the export step is actually costing you something, either because your architecture does not survive it or because you need to train where you deploy.
The second limitation is operator coverage. The README lists burn-vision, burn-rl and burn-dataset as domain toolkits, which implies that operators outside those domains may not be implemented. A model that uses an unusual activation, a custom attention variant or a rarely used normalization will need a kernel written against CubeCL or against the backend's lower-level API. That is a real cost, and it is the point where the "exact same code in training and production" promise stops being free.
The third limitation is the backend matrix itself. LibTorch gives you a mature, externally maintained compute stack but no fusion and no remote execution. A CubeCL backend gives you the full decorator set but depends on CubeCL's compiler and its coverage of your target hardware. Neither column is strictly better, and the README's own split makes that explicit.
As an alternative, ONNX Runtime takes the opposite approach: it consumes an exported graph and executes it with a runtime that is independent of the training language. The difference is where the boundary sits. Burn removes the boundary by making training and inference the same compiled Rust program. ONNX Runtime keeps the boundary and makes it a stable interface, so you can train in any framework and deploy in any language that has bindings. If your team is polyglot, or if your training stack is not going to become Rust, the boundary is the feature, not the problem.
Licence and the cost of staying current
Burn is Apache-2.0 according to the repository metadata, and the README's licence badge reads MIT/Apache-2.0. The two do not match, and that discrepancy is worth resolving against the LICENSE files in the repository before you rely on either. Apache-2.0 and MIT are both permissive and carry no copyleft obligation, but Apache-2.0 includes an express patent grant and MIT does not, which matters if your organisation has a patent review process. This is a description of the licences, not legal advice; route the question to whoever handles open source compliance.
The maintenance cost is dominated by two things. First, the pre-release cadence: three pre-releases inside a month, with the stable 0.22 release not yet tagged, means you should expect to re-test after each upgrade. Second, the backend surface: every backend in the matrix is a separate code path, and a bug that appears on Vulkan may not appear on CUDA. Testing across more than one backend multiplies your CI work, and burn-bench exists precisely because comparing backends over time is a task the project considers worth tooling. Budget for that if you intend to ship on more than one target.
Editorial conclusion
Adopt Burn if your deployment target is Rust, your model uses operations the framework already implements, and you can pin to a released version rather than the 0.22.0 pre-releases. Do not adopt it if you depend on a Python research stack, on pretrained model availability, or on architectures whose operators have not been ported. Before committing, check the supported backend table for the decorators your target backend accepts, confirm burn-onnx can convert your specific model graph, and read the release notes for the version you pin.
Community notes