invoke-ai/InvokeAI · error · NotAMatchError

model is not a FLUX.2 LoRA

Error message

model is not a FLUX.2 LoRA

What it means

NotAMatchError raised by LoRA_LyCORIS_Flux2_Config._get_base_or_raise when the model is not simultaneously (a) in a recognized Flux LoRA format (Kohya, Diffusers, OneTrainer, AIToolkit, XLabs, etc. per _get_flux_lora_format) and (b) detected as a FLUX.2 (Klein) LoRA by _is_flux2_lora. This config class only claims files that are definitively FLUX.2 LoRAs; anything else falls through so another config class can match.

Source

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

    """Model config for FLUX.2 (Klein) LoRA models in LyCORIS format."""

    base: Literal[BaseModelType.Flux2] = Field(default=BaseModelType.Flux2)
    variant: Flux2VariantType | None = Field(default=None)

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

    @classmethod
    def _get_base_or_raise(cls, mod: ModelOnDisk) -> BaseModelType:
        if _get_flux_lora_format(mod) and _is_flux2_lora(mod):
            return BaseModelType.Flux2
        raise NotAMatchError("model is not a FLUX.2 LoRA")


class LoRA_LyCORIS_ZImage_Config(LoRA_LyCORIS_Config_Base, Config_Base):
    """Model config for Z-Image LoRA models in LyCORIS format."""

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

    @classmethod
    def _validate_looks_like_lora(cls, mod: ModelOnDisk) -> None:
        """Z-Image LoRAs have different key patterns than SD/SDXL LoRAs.

        Z-Image LoRAs use keys like:
        - diffusion_model.layers.X.attention.to_k.lora_down.weight (DoRA format)
        - diffusion_model.layers.X.attention.to_k.lora_A.weight (PEFT format)
        - diffusion_model.layers.X.attention.to_k.dora_scale (DoRA scale)
        - lora_unet__layers_X_attention_to_k.lora_down.weight (Kohya format)
        """

View on GitHub (pinned to 0b6a024f2f)

Solutions

1. This error is often benign during a scan — InvokeAI tries multiple config classes; verify whether the model was eventually matched by another config (e.g. LoRA_LyCORIS_FLUX_Config) before treating it as a failure.
2. If it is a FLUX.1 LoRA, no fix needed — it should match the FLUX (non-.2) config; ensure InvokeAI is up to date so routing works.
3. If it is a genuine FLUX.2 LoRA, update InvokeAI — newer versions recognize more trainer formats in _get_flux_lora_format.
4. Re-export the LoRA in Kohya or diffusers PEFT format so the format detector recognizes it.
5. Specify the base model explicitly via override fields during install to bypass auto-detection.

Example fix

// before: ambiguous file left to auto-routing
cls(**override_fields)
// after: pin the base during install so the correct config claims it
from_model_on_disk(mod, {"base": BaseModelType.Flux2})

from invokeai.backend.model_manager.configs.lora import _get_flux_lora_format, _is_flux2_lora

mod = ModelOnDisk(path)
if not (_get_flux_lora_format(mod) and _is_flux2_lora(mod)):
    print("File will not match the FLUX.2 LoRA config; expect other configs to claim it")

def is_flux2_lora_file(mod) -> bool:
    return _get_flux_lora_format(mod) is not None and _is_flux2_lora(mod)

try:
    config = LoRA_LyCORIS_Flux2_Config.from_model_on_disk(mod, override_fields)
except NotAMatchError:
    # Fall back to generic FLUX / LyCORIS routing; the scan continues with other configs
    config = None

When it happens

Trigger: from_model_on_disk is called on a file that reached the Flux2 config candidate during model scanning but either _get_flux_lora_format(mod) returns None (unrecognized LoRA key format) or _is_flux2_lora(mod) returns False (keys belong to FLUX.1, not FLUX.2).

Common situations: Importing a FLUX.1 LoRA that is being probed against the newer FLUX.2 config class, a Flux LoRA saved by an unlisted trainer (format markers not recognized), or a FLUX.2 LoRA repackaged with non-standard key names so _is_flux2_lora cannot identify it.

Related errors

• LoRA "{lora_key}" already applied to transformer.
• LoRA "{lora_key}" already applied to CLIP encoder.
• LoRA "{lora_key}" already applied to T5 encoder.
• Unknown lora: {lora.lora.key}!
• LoRA '{lora.lora.key}' is for {lora.lora.base.value if lora.

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