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
- Ensure the data was created through the quantized API so its dtype is DType::QFloat
- If you have raw data + scheme, build the tensor with new_qtensor instead of q_from_data
- Convert/cast the payload into a QFloat dtype carrying the intended QuantScheme
- 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
- Produce tensor data only through the quantize APIs so dtype stays QFloat
- Avoid Lookup-mode schemes for tensors serialized as QFloat
- Check dtype metadata when loading quantized checkpoints before reconstructing
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
- Quantization scheme is not valid for dtype {other:?}
- Can't store native sub-byte values
- float_storage_as_f32: unsupported dtype {:?}
- Expected quantized dtype, got {:?}
- ctc_loss_backward: 2 * max_target_len + 1 = {} exceeds the k
AI-assisted analysis of tracel-ai/burn@d16f7ba2ed (2026-09-05).
Data as JSON: /api/errors/fd902ba6a1aaad8b.
Report an issue: GitHub.