invoke-ai/InvokeAI · info · NotAMatchError

model is not a FLUX.2 Diffusers LoRA

Error message

model is not a FLUX.2 Diffusers LoRA

What it means

The FLUX.2 Diffusers LoRA config class probes the state dict with _is_flux2_lora_state_dict(); if the keys do not match a FLUX.2 LoRA, it raises NotAMatchError. This class only accepts FLUX.2 (Klein) LoRAs, so the error simply means the directory holds some other model type and the next config class in the probe chain should be tried.

Source

Thrown at invokeai/backend/model_manager/configs/lora.py:1323

    variant: Flux2VariantType | None = Field(default=None)

    @classmethod
    def from_model_on_disk(cls, mod: ModelOnDisk, override_fields: dict[str, Any]) -> Self:
        raise_if_not_dir(mod)
        raise_for_override_fields(cls, override_fields)
        cls._validate_base(mod)
        path_to_weight_file = cls._get_weight_file_or_raise(mod)
        state_dict = mod.load_state_dict(path_to_weight_file)
        override_fields.setdefault("variant", _get_flux2_lora_variant(state_dict))
        return cls(**override_fields)

    @classmethod
    def _get_base_or_raise(cls, mod: ModelOnDisk) -> BaseModelType:
        path_to_weight_file = cls._get_weight_file_or_raise(mod)
        state_dict = mod.load_state_dict(path_to_weight_file)
        if _is_flux2_lora_state_dict(state_dict):
            return BaseModelType.Flux2
        raise NotAMatchError("model is not a FLUX.2 Diffusers LoRA")


class LoRA_Diffusers_ZImage_Config(LoRA_Diffusers_Config_Base, Config_Base):
    """Model config for Z-Image LoRA models in Diffusers format."""

    base: Literal[BaseModelType.ZImage] = Field(default=BaseModelType.ZImage)
    variant: ZImageVariantType | None = Field(default=None)

View on GitHub (pinned to 0b6a024f2f)

Solutions

1. Confirm the model really is a FLUX.2 LoRA (Diffusers format); if it is FLUX.1, it belongs to a different config class and the error is expected probe noise.
2. If it is a full FLUX.2 checkpoint rather than a LoRA, import it as a main model, not a LoRA.
3. Inspect the state dict keys for FLUX.2 LoRA signatures before importing.
4. Update InvokeAI so the probe chain includes the correct config class for your model format.

def looks_like_flux2_lora(sd: dict) -> bool:
    from invokeai.backend.model_manager.configs.lora import _is_flux2_lora_state_dict
    return _is_flux2_lora_state_dict(sd)

try:
    cfg = probe_model(mod)
except NotAMatchError:
    cfg = None  # probe chain will try the next config class; treat as non-FLUX.2

When it happens

Trigger: from_model_on_disk / _validate_base on a directory that has pytorch_lora_weights.{bin,safetensors} but whose state dict fails _is_flux2_lora_state_dict — i.e. not a FLUX.2 LoRA.

Common situations: Scanning a FLUX.1 LoRA, SDXL LoRA, or a full FLUX.2 checkpoint (not a LoRA) against the FLUX.2 LoRA config during model import; mismatched format after a InvokeAI/FLUX.2 version change.

Related errors

• LoRA '{lora_config.name}' is a {lora_variant.value} LoRA and
• LoRA '{lora.lora.key}' is for {lora.lora.base.value if lora.
• Expected ModelPatchRaw for LoRA '{lora.lora.key}', got {type
• LoRA '{lora_config.name}' is a FLUX.2 [dev] LoRA and cannot
• Unknown lora: {lora_key}!

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