Version 0.22 moves backend choice out of model types
Burn 0.22 lets model and tensor types stay independent of a concrete backend, while a Device selects CPU, GPU, remote execution, and autodiff behavior. That is the framework's clearest advantage. A team can keep one Rust model implementation from training through deployment instead of exporting a Python-trained graph into a separate runtime and hoping every operation survives the handoff.
The tensor API supports dynamic shapes and graphs, with automatic differentiation and kernel fusion available through backend decorators. Training has its own terminal dashboard, checkpointing, metrics, optimizers, and datasets. For inference, Burn can load PyTorch or Safetensors weights into Burn-defined models. ONNX import generates native Rust code, although the project explicitly warns that its ONNX operator coverage is limited.
Six accelerated targets make backend testing part of adoption
The backend table covers 6 accelerated routes: CUDA, ROCm, Metal, Vulkan, WebGPU, and the now-deprecated LibTorch path. CubeCL supplies the first-party GPU and CPU compute layer, while Flex is a pure-Rust eager CPU backend that also works in WebAssembly and no_std settings. Autodiff and fusion compose with the accelerated backends, and a remote decorator can move tensor work to another device.
This breadth changes where Burn fits. It can train on a server, run through WebGPU in a browser, or use Flex where native dependencies are unwelcome. You still choose features, drivers, device memory, and deployment artifacts for each target. The same high-level API reduces code forks; it does not prove that every backend gives identical output or comparable speed for your model.
What happened when we ran it
Our sandbox installed commit 20426b9 in 28 seconds and resolved 1,195 packages. The checkout held 2,243 files, about 439,082 lines of source, and occupied 24.3 MB before the Cargo work. We used an unprivileged container with 3 CPUs, 12 GB of RAM, the lab Rust image, and no secrets. The repository had 8 CI workflow files and no root Dockerfile.
The build ran for 900 seconds and timed out. It did not return a compiler error before the cap. The separate test command also ran for 900 seconds and timed out without reporting executed or passing tests. Its last lines still said Compiling, so we cannot claim that test cases began. A timeout is not a failed assertion, but it is a real cost for a clean full-workspace check.
The final test log names pytorch-tests, safetensors-tests, burn-rl, burn-capture, burn-rocm, burn-cpu, burn-cuda, two xtask packages, and web inference examples. That confirms the command was traversing a wide workspace when time expired. It does not identify one crate as the bottleneck. A feature-limited application should be smaller, but our lab measured the repository command, not a hand-picked minimal example.
Version 0.22 requires a deliberate migration before 1.0
Release v0.22.0 arrived on October 6, 2026 with what the maintainers call their largest API update. Backend generics were removed from models and tensors in favor of device selection. Candle support was removed from Burn itself, while NdArray and LibTorch entered deprecation. Legacy record formats now need an older compatible Burn version to load and export them through burn-store.
That checkpoint conversion transfers model parameters, not old optimizer or scheduler state. Teams resuming long training work should test the migration before deleting an earlier environment. Burn's status section is candid that the framework remains in active development and will have breaking changes with no guarantees. The migration guide is detailed, but documentation cannot turn an API break into a free upgrade.
Open backend reports justify numerical comparison tests
Issue 5962 reports wrong or saturated inference output with Burn 0.21 on WGPU over Metal while the same checkpoint and input look correct on NdArray. Issue 5257 describes deterministic divergence on WGPU over Vulkan when fusion and autotune are combined for cached incremental decoding. These are scoped user reports on v0.21 configurations, not results from our v0.22 sandbox, which never reached test execution.
They still suggest the right acceptance test. Run a fixed input and checkpoint through every backend you intend to ship, compare outputs within a stated tolerance, and keep that test in CI on representative hardware. A tensor framework can compile successfully while returning a wrong value. Burn's backend flexibility is useful only when the team budgets for that cross-device verification.
An October 8 push and v0.22.0 show fast maintenance
GitHub recorded a push on October 8, 2026, two days after v0.22.0, and listed 188 open issues and pull requests combined. The repository had more than 16,000 stars. Current reports cover zero-length tensor shapes, dtype handling, backend cache identity, graph capture, and WGPU behavior, while release work spans training, inference, model storage, and compute backends. This is active maintenance on a wide technical surface.
Burn is worth a serious trial when Rust is already a product constraint and the same model must cross 2 or more hardware classes. Start with one backend and one representative model, then add targets only after numerical and memory checks pass. Our 30 minutes of combined build and test caps show why evaluating the whole workspace is the wrong first milestone, even though that result remains an important warning for contributors.