tracel-ai/burn · error

no fusion optimization named `{}` is registered; register it

Error message

no fusion optimization named `{}` is registered; register its provider before restoring serialized execution plans

What it means

When deserializing a `CubeOptimizationState` (e.g. from a saved model/execution plan), the fusion registry looks up the optimization provider by name. If no provider with that name was registered (providers self-register at startup), restoring fails with this panic.

Source

Thrown at crates/burn-cubecl/src/fusion/registry.rs:223

/// valid when a built-in is renamed or retired.
///
/// # Errors
///
/// Fails with [`RegistryError::ServiceRunning`] once the fusion backend
/// service has started; call this at the start of the program.
pub fn remove(name: &str) -> Result<(), RegistryError> {
    registry().lock().unwrap().remove(name)
}

/// Restore the optimization described by `state` through its provider's
/// [`restore`](OptimizationProvider::restore).
pub(crate) fn restore(device: &CubeDevice, state: CubeOptimizationState) -> CubeOptimization {
    let registry = registry().lock().unwrap();
    registry
        .provider(&state.name)
        .map(|slot| downcast(slot).restore(device, &state))
        .unwrap_or_else(|| {
            panic!(
                "no fusion optimization named `{}` is registered; register its \
                 provider before restoring serialized execution plans",
                state.name,
            )
        })
}

/// The fusers for a new execution stream: one per registered provider — the
/// built-ins minus the [`remove`]d ones, plus the user-registered ones. Seals
/// the registry — streams only exist once the fusion service runs, and later
/// registrations could not apply to the streams already built.
pub(crate) fn fusers(device: &CubeDevice) -> Vec<Box<dyn OperationFuser<CubeOptimization>>> {
    let mut registry = registry().lock().unwrap();
    registry
        .start()
        .providers
        .iter()
        .map(|(_, slot)| downcast(slot).fuser(device).fuser)

View on GitHub (pinned to d16f7ba2ed)

Solutions

  1. Ensure the crate/feature that registers the named fusion provider is enabled (check burn feature flags)
  2. Force provider registration before loading state (touch the relevant module, e.g. a use/registration call at startup)
  3. Re-save the model/plan with the same burn version that will load it

Example fix

// before
let state = load_state(); // provider never registered
let opt = restore(&device, state);
// after
burn_cubecl::fusion::registry_init(); // ensure providers register
let opt = restore(&device, load_state());
Defensive patterns

Strategy: try-catch

Validate before calling

let registered = burn_cubecl::fusion::registry()
    .lock().unwrap()
    .provider(&state.name).is_some();
if !registered { /* enable feature or skip restore */ }

Try / catch

// panic-based API; pre-check instead, or isolate the call:
let result = std::panic::catch_unwind(|| restore(&device, state.clone()));
match result {
    Ok(opt) => { /* use opt */ },
    Err(_) => { /* rebuild optimization from scratch instead of restoring */ }
}

Prevention

When it happens

Trigger: Calling `restore` (loading serialized fusion state) for an optimization whose provider was never registered in the current process — e.g. the feature providing it isn't enabled, or load happens before registration.

Common situations: Loading a checkpoint/model saved with extra burn fusion features into a binary without them; reordering static initialization so deserialization runs before provider registration; version mismatch changing optimization names.

Related errors


AI-assisted analysis of tracel-ai/burn@d16f7ba2ed (2026-09-05). Data as JSON: /api/errors/ec7c1487298986cf. Report an issue: GitHub.