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
- Verify the file is actually a LyCORIS/LoCon file and re-export it in Kohya or diffusers LoRA format
- If it's a full checkpoint, import it as a main model, not a LoRA
- Rename/convert keys with a conversion script so they carry `lora_` prefix or `lora` suffix
- 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
- Only import LyCORIS files exported with standard key naming
- Distinguish full checkpoints from LoRA files before import
- Use standard trainers (kohya_ss) that emit recognizable keys
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
- unrecognised/unsupported architecture for OMI LoRA: {archite
- model looks like Control LoRA
- model does not look like a Qwen Image Edit LoRA
- model does not match Krea-2 LoRA heuristics (no complete lor
- model does not look like a Krea-2 LoRA
AI-assisted analysis of invoke-ai/InvokeAI@0b6a024f2f (2026-08-29).
Data as JSON: /api/errors/5a9d9b510554d3f9.
Report an issue: GitHub.