invoke-ai/InvokeAI · info · NotAMatchError

state dict does not look like a FLUX checkpoint

Error message

state dict does not look like a FLUX checkpoint

What it means

The FLUX.1 main-model config validates the state dict contains known FLUX signature keys (double_blocks img_attn norm scales, with or without the model.diffusion_model prefix). If neither is present, the checkpoint is not FLUX.1 and NotAMatchError is raised. This is probe-chain behavior directing the model to another config class.

Source

Thrown at invokeai/backend/model_manager/configs/main.py:654

        cls._validate_does_not_look_like_bnb_quantized(mod)

        cls._validate_does_not_look_like_gguf_quantized(mod)

        variant = override_fields.pop("variant", None) or cls._get_variant_or_raise(mod)

        return cls(**override_fields, variant=variant)

    @classmethod
    def _validate_is_flux(cls, mod: ModelOnDisk) -> None:
        state_dict = mod.load_state_dict()
        if not state_dict_has_any_keys_exact(
            state_dict,
            {
                "double_blocks.0.img_attn.norm.key_norm.scale",
                "model.diffusion_model.double_blocks.0.img_attn.norm.key_norm.scale",
            },
        ):
            raise NotAMatchError("state dict does not look like a FLUX checkpoint")

        # Exclude FLUX.2 models - they have their own config class
        if _is_flux2_model(state_dict):
            raise NotAMatchError("model is a FLUX.2 model, not FLUX.1")

    @classmethod
    def _get_variant_or_raise(cls, mod: ModelOnDisk) -> FluxVariantType:
        # FLUX Model variant types are distinguished by input channels and the presence of certain keys.
        state_dict = mod.load_state_dict()
        variant = _get_flux_variant(state_dict)

        if variant is None:
            # TODO(psyche): Should we have a graceful fallback here? Previously we fell back to the "normal" variant,
            # but this variant is no longer used for FLUX models. If we get here, but the model is definitely a FLUX
            # model, we should figure out a good fallback value.
            raise NotAMatchError("unable to determine model variant from state dict")

        return variant

View on GitHub (pinned to 0b6a024f2f)

Solutions

1. If the model is FLUX.2, this error is expected — it is routed to the FLUX.2 config; ensure your InvokeAI version supports FLUX.2.
2. If the model is FLUX.1 in a repacked/quantized format, convert it to standard FLUX.1 checkpoint layout or use a loader that understands the format.
3. Verify the file is actually a FLUX.1 checkpoint by grepping for 'double_blocks' keys in the state dict.
4. Re-download the checkpoint if keys look truncated.

Example fix

// key check before import
sd = load_file('flux.safetensors')
assert any('double_blocks.0.img_attn.norm.key_norm.scale' in k for k in sd), 'not standard FLUX.1 layout'

def is_flux1_checkpoint(sd: dict) -> bool:
    sigs = {'double_blocks.0.img_attn.norm.key_norm.scale',
            'model.diffusion_model.double_blocks.0.img_attn.norm.key_norm.scale'}
    return bool(sigs & set(sd.keys()))

try:
    cfg = probe_model(path)
except NotAMatchError:
    pass  # expected during probe chain; next config class may match

When it happens

Trigger: from_model_on_disk → _validate_is_flux on a state dict missing both 'double_blocks.0.img_attn.norm.key_norm.scale' and its model.diffusion_model-prefixed variant.

Common situations: Importing a non-FLUX checkpoint (SD/SDXL/SD3) while expecting FLUX handling; loading a FLUX.2 model (handled by the subsequent check); quantized/repacked FLUX files with transformed key layouts (e.g. GGUF/comfy rewraps).

Related errors

• base is {recognized_base}, not {expected_base}
• Control LoRAs cannot be used with FLUX Schnell
• fill_conditioning was provided, but the model is not a FLUX
• A VAE (e.g., controlnet_vae) must be provided to use Kontext
• Unsupported model format: {config.format}

AI-assisted analysis of invoke-ai/InvokeAI@0b6a024f2f (2026-08-29). Data as JSON: /api/errors/39731950e9c1e9c3. Report an issue: GitHub.