invoke-ai/InvokeAI · warning · NotAMatchError

unrecognised/unsupported architecture for OMI LoRA: {archite

Error message

unrecognised/unsupported architecture for OMI LoRA: {architecture}

What it means

When InvokeAI probes an OMI-format LoRA model on disk to determine its base model, `_get_base_or_raise` only recognizes the `stable_diffusion_xl_1_lora` and `flux_dev_1_lora` OMI architecture strings. Any other architecture value means the config matcher cannot map the model to a base model type, so it raises `NotAMatchError`. This is a deliberate 'this config class does not match this model' signal used during model-format sniffing.

Source

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

            bool(metadata.get("modelspec.sai_model_spec"))
            and metadata.get("ot_branch") == "omi_format"
            and metadata.get("modelspec.architecture", "").split("/")[1].lower() == "lora"
        )

        if not metadata_looks_like_omi_lora:
            raise NotAMatchError("metadata does not look like OMI LoRA")

    @classmethod
    def _get_base_or_raise(cls, mod: ModelOnDisk) -> Literal[BaseModelType.Flux, BaseModelType.StableDiffusionXL]:
        metadata = mod.metadata()
        architecture = metadata["modelspec.architecture"]

        if architecture == stable_diffusion_xl_1_lora:
            return BaseModelType.StableDiffusionXL
        elif architecture == flux_dev_1_lora:
            return BaseModelType.Flux
        else:
            raise NotAMatchError(f"unrecognised/unsupported architecture for OMI LoRA: {architecture}")


class LoRA_OMI_SDXL_Config(LoRA_OMI_Config_Base, Config_Base):
    base: Literal[BaseModelType.StableDiffusionXL] = Field(default=BaseModelType.StableDiffusionXL)


class LoRA_OMI_FLUX_Config(LoRA_OMI_Config_Base, Config_Base):
    base: Literal[BaseModelType.Flux] = Field(default=BaseModelType.Flux)


class LoRA_LyCORIS_Config_Base(LoRA_Config_Base):
    """Model config for LoRA/Lycoris models."""

    type: Literal[ModelType.LoRA] = Field(default=ModelType.LoRA)
    format: Literal[ModelFormat.LyCORIS] = Field(default=ModelFormat.LyCORIS)

    @classmethod
    def from_model_on_disk(cls, mod: ModelOnDisk, override_fields: dict[str, Any]) -> Self:

View on GitHub (pinned to 0b6a024f2f)

Solutions

1. Convert or re-export the LoRA to a supported format (Kohya/diffusers) or to an OMI architecture `stable_diffusion_xl_1_lora`/`flux_dev_1_lora`
2. Check the `architecture` string in the model's OMI JSON for typos and correct it to a recognized value
3. Upgrade InvokeAI — new OMI architectures are added over time
4. Register the model manually with the correct base model type instead of relying on auto-detection

Example fix

// before (model.omi.json)
{"architecture": "flux_1_dev_lora"}
// after
{"architecture": "flux_dev_1_lora"}

import json
SUPPORTED = {"stable_diffusion_xl_1_lora", "flux_dev_1_lora"}
meta = json.load(open("model_dir/model.omi.json"))
if meta.get("architecture") not in SUPPORTED:
    raise ValueError(f"OMI LoRA architecture {meta.get('architecture')!r} not supported")

def is_supported_omi_lora(meta: dict) -> bool:
    return meta.get("architecture") in {"stable_diffusion_xl_1_lora", "flux_dev_1_lora"}

from invokeai.backend.model_manager.configs.lora import NotAMatchError
try:
    cfg = LoRA_OMI_Config_Base.from_model_on_disk(mod)
except NotAMatchError:
    print("OMI LoRA architecture unsupported; convert or import manually")

When it happens

Trigger: Loading or importing a model whose OMI metadata (`architecture` field in its OMI JSON) declares an architecture other than `stable_diffusion_xl_1_lora` or `flux_dev_1_lora` — e.g. a Flux SD3/Flux2, SD1.5, or SDXL-variant OMI LoRA — via `from_model_on_disk` during model scan/import.

Common situations: Dropping an OMI LoRA trained for an unsupported base (SD1.5, SD3, Flux2) into the autoimport folder; an OMI tool exporting a new architecture string not yet whitelisted in InvokeAI; OMI spec version drift where architecture names were renamed.

Related errors

• Expected ModelPatchRaw for LoRA '{lora.lora.key}', got {type
• Expected ModelPatchRaw for LoRA '{lora.lora.key}', got {type
• LoRA '{lora.lora.key}' has conflicting weights on the transf
• Expected ModelPatchRaw for LoRA '{lora.lora.key}', got {type
• model looks like Control LoRA

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