invoke-ai/InvokeAI · error · NotAMatchError

state dict has no undecorated transformer block weights — it

Error message

state dict has no undecorated transformer block weights — it looks like a Wan LoRA or adapter rather than a full transformer

What it means

Raised by Main_GGUF_Wan_Config.from_model_on_disk when the state dict has GGML tensors and Wan-like keys but lacks undecorated transformer block weights (_has_wan_transformer_block_weights fails). The message says the file looks like a Wan LoRA or adapter: its keys are decorated with LoRA/adapter prefixes (lora_A/lora_B, delta-style naming) rather than the plain block weight keys a full DiT carries.

Source

Thrown at invokeai/backend/model_manager/configs/main.py:2205

    expert: Literal["high", "low", "none"] = Field(
        default="none",
        description="For Wan 2.2 A14B's dual-expert MoE: 'high' for the high-noise expert, "
        "'low' for the low-noise expert. 'none' for single-transformer models (TI2V-5B).",
    )

    @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)

        sd = mod.load_state_dict()

        if not _has_ggml_tensors(sd):
            raise NotAMatchError("state dict does not look like GGUF quantized")
        if not _has_wan_keys(sd):
            raise NotAMatchError("state dict does not look like a Wan transformer")
        if not _has_wan_transformer_block_weights(sd):
            raise NotAMatchError(
                "state dict has no undecorated transformer block weights — it looks like a Wan LoRA "
                "or adapter rather than a full transformer"
            )
        unsupported_reason = _find_unsupported_wan_variant_marker(sd)
        if unsupported_reason is not None:
            raise NotAMatchError(unsupported_reason)
        gguf_name = mod.metadata().get("general.name", "")
        normalized_identity = "".join(
            character for character in f"{mod.path.stem} {gguf_name}".lower() if character.isalnum()
        )
        if "wan21" in normalized_identity:
            raise NotAMatchError("Wan 2.1 GGUF models are not supported by the Wan 2.2 loader")
        # A misnamed Wan 2.1 GGUF slips past the name check above; the architectural
        # markers don't care what the file is called.
        wan_2_1_reason = _find_wan_2_1_marker(sd)
        if wan_2_1_reason is not None:
            raise NotAMatchError(f"Wan 2.1 GGUF models are not supported by the Wan 2.2 loader: {wan_2_1_reason}")

View on GitHub (pinned to 0b6a024f2f)

Solutions

1. Move the file to the LoRA models folder / import it as a LoRA model type instead of a Main model
2. Download the actual full Wan 2.2 transformer GGUF (e.g. Wan2.2-T2V-A14B-high-noise-*.gguf) if you intended to install the base model
3. Check key names in the file (look for lora_A/lora_B prefixes) to confirm it is an adapter before importing

Example fix

// before
# wan2.2_lightx2v_T2V_14B_high_noise_lora.gguf placed in autoimport/ as a main model
// after
# copy it to autoimport/lora/ (or choose Model Type = LoRA during manual import)

sd = ModelOnDisk(path).load_state_dict()
keys = [k for k in sd if isinstance(k, str)]
if any('.lora_' in k or 'lora_A' in k for k in keys):
    print(f'{path.name} looks like a LoRA; import it as a LoRA, not a main model')

def is_full_wan_transformer(sd: dict) -> bool:
    return _has_wan_keys(sd) and _has_wan_transformer_block_weights(sd)

try:
    import_model(path, model_type='main')
except NotAMatchError as e:
    if 'LoRA' in str(e):
        import_model(path, model_type='lora')
    else:
        raise

When it happens

Trigger: Importing a Wan LoRA shipped as GGUF/quantized instead of a full transformer checkpoint; importing a Wan speed-up adapter (lightx2v/ACC-style) GGUF; converting a Wan LoRA to GGUF and placing it in main-model autoimport.

Common situations: Downloading Wan 2.2 LoRAs (low-noise/high-noise distill adapters) alongside main model GGUFs and mixing them in one folder; CivitAI Wan LoRA files mislabeled as models.

Related errors

• state dict does not look like a Wan transformer
• {unsupported_reason}
• Wan 2.1 GGUF models are not supported by the Wan 2.2 loader
• Wan 2.1 GGUF models are not supported by the Wan 2.2 loader:
• could not determine Wan variant from state dict

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