tracel-ai/burn · error

Invalid dtype (expected DType::QFloat, got {:?})

Error message

Invalid dtype (expected DType::QFloat, got {:?})

What it means

q_from_data constructs a quantized tensor from raw data and expects the data's dtype to be DType::QFloat, which carries the quantization scheme. Any other dtype means the data is not a self-describing quantized payload, so the library panics. Lookup-mode quantization is additionally unimplemented for QFloat transport.

Source

Thrown at crates/burn-cubecl/src/ops/qtensor.rs:245

                        | QuantValue::Q4F
                        | QuantValue::Q4S
                        | QuantValue::Q2F
                        | QuantValue::Q2S
                        | QuantValue::E4M3
                        | QuantValue::E5M2
                        | QuantValue::E2M1,
                    ..
                } => {
                    // TensorData quantized representation is the same, with multiple quantized values
                    // packed into u32 and quantization parameters appended to the bytes
                    new_qtensor_optimized(data.bytes, data.shape.clone(), scheme, device)
                }
                QuantScheme {
                    mode: QuantMode::Lookup,
                    ..
                } => unimplemented!("lookup quantization does not travel as a QFloat tensor"),
            },
            _ => panic!(
                "Invalid dtype (expected DType::QFloat, got {:?})",
                data.dtype
            ),
        }
    }

    // TODO: quantize_dynamic (we can compute min-max on the fly and scale, especially when not per-tensor)

    fn quantize(
        tensor: FloatTensor<Self>,
        scheme: &QuantScheme,
        qparams: QuantizationParametersPrimitive<Self>,
    ) -> QuantizedTensor<Self> {
        // The kernel reads this at the scheme's scale dtype, not the tensor's actual dtype.
        if let Some(global) = &qparams.global {
            assert_eq!(
                global.dtype,
                DType::F32,

View on GitHub (pinned to d16f7ba2ed)

Solutions

  1. Ensure the data was created through the quantized API so its dtype is DType::QFloat
  2. If you have raw data + scheme, build the tensor with new_qtensor instead of q_from_data
  3. Convert/cast the payload into a QFloat dtype carrying the intended QuantScheme
  4. Avoid Lookup-mode schemes for tensors that must travel as QFloat; use a different QuantMode

Example fix

// before: plain f32 data
q_from_data(TensorData::from(vec![0.1f32, 0.2]), device); // panics
// after: quantize into QFloat data first
let qt = Tensor::from_data(data, &device).quantize(&scheme);
q_from_data(qt.into_data(), &device);
Defensive patterns

Strategy: type-guard

Validate before calling

assert_eq!(data.dtype, DType::QFloat, "q_from_data requires QFloat data");

Type guard

fn is_qfloat(data: &TensorData) -> bool { data.dtype == DType::QFloat }

Prevention

When it happens

Trigger: Calling q_from_data with QuantTensorData whose dtype is a plain F32/F16/I8 etc. instead of QFloat; or with a Lookup-mode quant scheme, which hits an unimplemented! path.

Common situations: Loading quantized weights from a file that saved the scales/vals separately as regular tensors and re-wrapping them incorrectly, or version mismatches where the serializer dropped the QFloat dtype metadata.

Related errors


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