invoke-ai/InvokeAI · warning · NotAMatchError

model does not match LyCORIS LoRA heuristics

Error message

model does not match LyCORIS LoRA heuristics

What it means

The LyCORIS config class uses heuristics: it expects at least one state-dict key with a LoRA prefix (e.g. `lora_`) or LoRA suffix (e.g. `.lora_down/.lora_up`) and LyCORIS-specific keys like `hada_w1_a`/`hada_w2_a`. If the file has neither prefix-style nor suffix-style LoRA keys, it cannot be a LyCORIS LoRA and `NotAMatchError` is raised so other config classes can be tried.

Source

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

        has_key_with_lora_suffix = state_dict_has_any_keys_ending_with(
            mod.load_state_dict(),
            {
                "to_k_lora.up.weight",
                "to_q_lora.down.weight",
                "lora_A.weight",
                "lora_B.weight",
                # LyCORIS LoKR suffixes
                "lokr_w1",
                "lokr_w2",
                # LyCORIS LoHA suffixes
                "hada_w1_a",
                "hada_w2_a",
            },
        )

        if not has_key_with_lora_prefix and not has_key_with_lora_suffix:
            raise NotAMatchError("model does not match LyCORIS LoRA heuristics")

    @classmethod
    def _get_base_or_raise(cls, mod: ModelOnDisk) -> BaseModelType:
        if _get_flux_lora_format(mod):
            if _is_flux2_lora(mod):
                return BaseModelType.Flux2
            return BaseModelType.Flux

        state_dict = mod.load_state_dict()
        str_keys = [k for k in state_dict.keys() if isinstance(k, str)]

        # Rule out Anima LoRAs — their lora_te_ keys have shapes that
        # lora_token_vector_length() misidentifies as SD2/SDXL.
        if has_cosmos_dit_kohya_keys(str_keys) or has_cosmos_dit_peft_keys(str_keys):
            raise NotAMatchError("model looks like an Anima LoRA, not a Stable Diffusion LoRA")

        # If we've gotten here, we assume that the model is a Stable Diffusion model
        token_vector_length = lora_token_vector_length(state_dict)

View on GitHub (pinned to 0b6a024f2f)

Solutions

  1. Verify the file is actually a LyCORIS/LoCon file and re-export it in Kohya or diffusers LoRA format
  2. If it's a full checkpoint, import it as a main model, not a LoRA
  3. Rename/convert keys with a conversion script so they carry `lora_` prefix or `lora` suffix
  4. Upgrade InvokeAI if the format is a newly supported LyCORIS variant

Example fix

// before: checkpoint keys
{"transformer.blocks.0.attn.qkv.weight": ...}
// after: convert to LyCORIS keys
{"lora_unet_blocks_0_attn_qkv.hada_w1_a": ..., "lora_unet_blocks_0_attn_qkv.hada_w2_b": ...}
Defensive patterns

Strategy: validation

Validate before calling

from safetensors import safe_open
with safe_open(file, framework="pt") as f:
    keys = list(f.keys())
if not any(k.startswith("lora_") for k in keys) and not any(k.endswith(".lora_down.weight") for k in keys):
    print("not a LyCORIS/LoRA state dict — full checkpoint or unknown format")

Type guard

def looks_like_lycoris(keys: list[str]) -> bool:
    return any(k.startswith("lora_") for k in keys) or any("lora" in k and ("down" in k or "up" in k) for k in keys)

Try / catch

try:
    cfg = LoRALyCORISConfig.from_model_on_disk(mod)
except NotAMatchError:
    if looks_like_full_checkpoint(mod):
        import_as_main_model(mod)

Prevention

When it happens

Trigger: `from_model_on_disk` probing a checkpoint that lacks both `lora_`-prefixed keys and `lora`-suffixed keys — e.g. a full checkpoint, a text-encoder-only patch, or a LoCON/other format with unrecognized key naming.

Common situations: Trying to load a full fine-tuned checkpoint as a LyCORIS; a LoRA saved with nonstandard key names (custom trainer); files that are DoRA/other experimental formats not matching LyCORIS heuristics.

Related errors


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