By ByteBot
Burn 0.22.0 ships with the framework’s biggest API change yet: B: Backend generics are gone from models and tensors entirely. In their place, runtime device selection determines where and how your code executes. The practical payoff is immediate — CNN rebuild times drop from 28 seconds to under 5, transformer rebuilds from 15 seconds to 1. For a Rust framework that has long struggled with compile-time friction, 0.22 is a meaningful shift. If you’re on 0.21 or earlier, migration is required and your saved checkpoints are incompatible.
The Generic Removal Explained
Every prior version of Burn required threading a backend type parameter through your entire model hierarchy. In 0.22, models are plain Rust types:
// Burn 0.21: generics everywhere
struct Model<B: Backend> {
linear: Linear<B>,
}
// Burn 0.22: no generics, runtime device selection
struct Model {
linear: Linear,
}
let device = Device::cuda(0);
device.autodiff(); // enables gradient trackingThe rebuild speedup comes from breaking the compiler’s dependency chain. Previously, a change to any layer type forced Rust to recompile the entire graph of generic instantiations. Now model code is decoupled from backend specifics, so edits only recompile what actually changed. Autodiff, previously a compile-time type parameter (Autodiff<B>), is now configured at runtime via device.autodiff().
The Numbers
Tracel AI’s benchmarks from the official release post put it plainly:
- CNN rebuild: 28.42s → 4.57s (6.2x faster)
- Transformer rebuild: 14.73s → 1.00s (14.7x faster)
- CNN peak VRAM: 956 MiB → 486 MiB (−49%)
- CNN training throughput: +80%
The VRAM reduction is a side effect of adaptive memory pools in the updated CubeCL backend — pools that adjust allocation sizes dynamically based on workload patterns. No model code changes required to get it.
LoRA and QLoRA, Now Native
Parameter-efficient fine-tuning arrives in 0.22. LoRA keeps base weights frozen and trains low-rank adapters, significantly reducing the number of parameters that need gradients and optimizer state. You get per-parameter-group learning rate scheduling, multiple independent optimizers, and new choices including LAMB, Adafactor, and Lion alongside the existing Adam family.
QLoRA extends LoRA by quantizing the frozen weights to reduce storage. One counterintuitive caveat from the migration guide: QLoRA reduces frozen weight storage but generates dense effective weights during the forward pass, so peak training memory is higher than plain LoRA, not lower. If you’re memory-constrained at training time, test the actual delta before assuming QLoRA saves you anything.
Backend Consolidation: Candle Is Gone
The Candle backend is removed entirely. NdArray and LibTorch are deprecated. CubeCL is now the unified path, covering CUDA, ROCm, Metal, Vulkan, WebGPU, and CPU under one consistent backend. The GPU compiler stack has also been rewritten: MLIR — a C++ dependency — is replaced by Pliron, a pure-Rust intermediate representation that compiles through LLVM for most targets and SPIR-V for Vulkan.
The consolidation is a deliberate bet: one well-maintained backend with consistent feature coverage beats multiple backends maintained inconsistently. For anyone who chose Burn specifically because of the Candle or LibTorch compatibility layer, this is a forced migration with no workaround.
Checkpoint Incompatibility: Upgrade Carefully
This is the part most upgraders will hit unexpectedly. Old checkpoint formats — MessagePack (.mpk), binary (.bin), and JSON — are incompatible with 0.22’s new burnpack format (.bpk). You cannot rename the files. The migration path requires loading your model in Burn 0.21 with its original recorder and precision settings, exporting to SafeTensors via burn-store, then loading into your 0.22 model.
Two other behavioral changes worth checking in existing code: the direction of a positive shift in roll has been reversed to match PyTorch’s convention (the opposite of 0.21 behavior), and argmax/argmin now returns the index of the first NaN when NaN values are present.
Where Burn 0.22 Stands
The backend generic removal is the kind of breaking change you make once — it fundamentally shapes how Burn code is written, and reversing it would be a significant regression. Combined with ONNX export (previously only import was supported), native LoRA/QLoRA, and a pure-Rust GPU stack, 0.22 closes several gaps that previously pushed users toward Python toolchains for fine-tuning and deployment workflows.
The ecosystem gap remains real. Burn can now export to ONNX and train LoRA adapters, but the pre-trained model libraries and weight hubs that make fine-tuning practical in Python are still largely Python-first. Are We Learning Yet? tracks the Rust ML ecosystem — Burn leads that landscape, but the gap to close is large. Burn-LM (currently in alpha) is the team’s answer. Whether it gets there will determine how much of the fine-tuning conversation moves to Rust over the next 12 months.
