bilinear interpolation backward is not supported for ndarray

Error message

bilinear interpolation backward is not supported for ndarray backend

What it means

The burn-ndarray backend's interpolate_backward only implements backward for InterpolateMode::Nearest. When the interpolation mode is Bilinear, it panics because no gradient kernel exists for bilinear upsampling/downsampling in the ndarray backend. This is a hard panic, not a recoverable error.

Source

Thrown at crates/burn-ndarray/src/ops/module.rs:356

            }
        }
    }

    fn interpolate_backward(
        x: FloatTensor<Self>,
        grad: FloatTensor<Self>,
        output_size: [usize; 2],
        options: InterpolateOptions,
    ) -> FloatTensor<Self> {
        match options.mode {
            InterpolateMode::Nearest => module_op!(inp(x, grad), opt(), E, |x, grad| {
                nearest_interpolate_backward::<E>(x, grad, output_size).into()
            }),
            InterpolateMode::NearestExact => {
                panic!("nearest exact interpolation backward is not supported for ndarray backend")
            }
            InterpolateMode::Bilinear => {
                panic!("bilinear interpolation backward is not supported for ndarray backend")
            }
            InterpolateMode::Bicubic => {
                panic!("bicubic interpolation backward is not supported for ndarray backend")
            }
            InterpolateMode::Lanczos3 => {
                panic!("lanczos3 interpolation backward is not supported for ndarray backend")
            }
        }
    }

    fn conv3d(
        x: FloatTensor<Self>,
        weight: FloatTensor<Self>,
        bias: Option<FloatTensor<Self>>,
        options: ConvOptions<3>,
    ) -> FloatTensor<Self> {
        module_op!(inp(x, weight), opt(bias), E, |x, weight, bias| conv3d::<E>(
            x, weight, bias, options

View on GitHub (pinned to d16f7ba2ed)

Solutions

Use InterpolateMode::Nearest instead of Bilinear when training on the ndarray backend
Switch to a backend with bilinear interpolation backward support (e.g. burn-cube/cubecl GPU backends or burn-torch)
Detach the interpolate node from the autodiff graph (e.g. mark no-grad) if gradients through it are not needed
Implement/register a bilinear backward kernel for the ndarray backend and submit upstream

Example fix

// before
let x = x.interpolate([h * 2, w * 2], InterpolateMode::Bilinear);
// after (ndarray backend training)
let x = x.interpolate([h * 2, w * 2], InterpolateMode::Nearest);

Defensive patterns

Strategy: validation

Validate before calling

if mode == InterpolateMode::Bilinear && cfg!(feature = "ndarray") {
    // avoid autodiff through bilinear interpolate on ndarray
}

Type guard

fn ndarray_supports_interpolate_backward(mode: &InterpolateMode) -> bool {
    matches!(mode, InterpolateMode::Nearest)
}

Prevention

Only use InterpolateMode::Nearest in training paths when targeting burn-ndarray
Add a startup assertion/check on the model config that validates interpolate modes against the active backend
Track burn release notes for ndarray interpolation backward support

When it happens

Trigger: Calling backward through an interpolate (upsample) node created with InterpolateMode::Bilinear on the NdArray backend, e.g. training a model whose forward pass uses F.interpolate(..., mode=Bilinear) with burn-ndarray.

Common situations: Porting a PyTorch model that uses bilinear upsampling (e.g. segmentation networks like UNet, FPN decoders) to burn and trying to train it with the ndarray backend.

Related errors

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