invoke-ai/InvokeAI · error · NotAMatchError

model does not look like a Wan LoRA

Error message

model does not look like a Wan LoRA

What it means

NotAMatchError raised by LoRA_LyCORIS_Wan_Config._get_base_or_raise when the state dict does not identify as a Wan-base LoRA: either no Wan kohya/peft keys are present, or has_non_wan_architecture_keys detects another architecture's signatures. Called from _validate_base during from_model_on_disk; the class raises to signal 'not a Wan LoRA' so probing continues with other configs.

Source

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

        # Reject if any non-Wan architecture signature is present. Without this
        # guard a Wan LoRA could be falsely identified by Anima (cross_attn /
        # self_attn name collision) or vice versa.
        if has_wan_keys and has_lora_suffix and not has_non_wan_architecture_keys(str_keys):
            return

        raise NotAMatchError("model does not match Wan LoRA heuristics")

    @classmethod
    def _get_base_or_raise(cls, mod: ModelOnDisk) -> BaseModelType:
        state_dict = mod.load_state_dict()
        str_keys = [k for k in state_dict.keys() if isinstance(k, str)]

        if (has_wan_kohya_keys(str_keys) or has_wan_peft_keys(str_keys)) and not has_non_wan_architecture_keys(
            str_keys
        ):
            return BaseModelType.Wan

        raise NotAMatchError("model does not look like a Wan LoRA")

    @classmethod
    def from_model_on_disk(cls, mod: ModelOnDisk, override_fields: dict[str, Any]) -> Self:
        # Run the base-class probe (file-check, lora-suffix, base detection).
        instance = super().from_model_on_disk(mod, override_fields)

        # Auto-detect the model-family variant from inner_dim in the state
        # dict. The override field skips this if the user has set it.
        #
        # Resolved *before* the expert tag because the expert is only meaningful for
        # A14B — see below.
        if instance.variant is None:
            instance.variant = detect_wan_lora_variant(mod.load_state_dict())

        # Auto-detect the expert tag from the filename if the user didn't override
        # it, using the same helper as the transformer probes so the two can't drift
        # apart. That also picks up the bare ``HIGH``/``LOW`` convention, which
        # matters here: an expert-specific LoRA left untagged is applied to *both*

View on GitHub (pinned to 0b6a024f2f)

Solutions

1. Verify the LoRA's architecture; if it is Anima/FLUX/SD, let a different config class pick it up (fix routing hints like install type or folder).
2. Dump keys via safetensors.torch.load_file and confirm Wan naming (self_attn/cross_attn/ffn.N or attn1/attn2/ffn.net) without foreign signatures.
3. Re-export the LoRA with the standard Kohya or diffusers PEFT key layout if a converter mangled the names.
4. Update InvokeAI or open an issue with the key list if your trainer emits a legitimate new Wan key pattern the detectors miss.

Example fix

// before (foreign signature present, base detection fails)
// keys: ['transformer.blocks.0.mlp.layer_0.lora_A.weight', ...]
// after (pure Wan keys)
// keys: ['lora_unet_blocks_0_self_attn.k.lora_down.weight', ...]

from safetensors.torch import load_file
keys = [k for k in load_file(path).keys() if isinstance(k, str)]
wan_ok = any(('self_attn' in k or 'cross_attn' in k or 'attn1' in k or 'ffn' in k) for k in keys)
foreign = any(('adaln_modulation' in k or 'mlp.layer_0' in k or '_proj.lora' in k) for k in keys)
if not (wan_ok and not foreign):
    raise ValueError(f'{path} is not recognized as a Wan-base LoRA')

def is_wan_base_lora(keys: list[str]) -> bool:
    has_wan_keys = any(('self_attn' in k or 'cross_attn' in k or 'attn1' in k or 'attn2' in k) for k in keys)
    no_foreign = not any(('adaln_modulation' in k or 'blocks_0_mlp' in k or '_proj.' in k) for k in keys)
    return has_wan_keys and no_foreign

try:
    base = LoRA_LyCORIS_Wan_Config._get_base_or_raise(mod)
except NotAMatchError:
    base = fallback_detect_base(mod)  # try other config classes

When it happens

Trigger: from_model_on_disk -> _validate_base -> _get_base_or_raise on a file whose str_keys lack Wan patterns (attn1/attn2/ffn.net diffusers form or self_attn/cross_attn/ffn.N native form), or which contains keys flagged as non-Wan architecture (e.g. Anima mlp/adaln_modulation/_proj names).

Common situations: Installing a non-Wan LoRA that the router offered to the Wan config; a Wan LoRA converted by a tool that renamed keys away from the expected layout; files mixing architectures after manual merging of state dicts.

Related errors

• Unknown lora: {lora.lora.key}!
• Unknown lora: {lora_key}!
• model does not look like a Qwen Image Edit LoRA
• model does not match Krea-2 LoRA heuristics (no complete lor
• Krea-2 LoRA has an incomplete lora_A/B (or lora_down/up) wei

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