invoke-ai/InvokeAI · error · NotAMatchError

Wan 2.1 GGUF models are not supported by the Wan 2.2 loader:

Error message

Wan 2.1 GGUF models are not supported by the Wan 2.2 loader: {wan_2_1_reason}

What it means

Same family as the name-based Wan 2.1 rejection, but this fires on architecture instead of naming: _find_wan_2_1_marker inspects the state dict for architectural markers unique to Wan 2.1 transformers, and any returned reason is appended to the error. It exists so misnamed 2.1 GGUFs (a Wan 2.1 model renamed to 'wan22...') are still rejected.

Source

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

        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}")

        explicit_variant = override_fields.pop("variant", None)
        variant = explicit_variant or _detect_wan_variant_from_state_dict(sd)
        if variant is None:
            raise NotAMatchError("could not determine Wan variant from state dict")
        if variant in (WanVariantType.T2V_A14B, WanVariantType.I2V_A14B) and "wan22" not in normalized_identity:
            raise NotAMatchError("Wan A14B GGUF filename or metadata must identify the model as Wan 2.2")

        expert = _resolve_wan_expert(mod, override_fields, variant)

        return cls(**override_fields, variant=variant, expert=expert)


class Main_Checkpoint_Wan_Config(Checkpoint_Config_Base, Main_Config_Base, Config_Base):
    """Model config for single-file Wan 2.2 transformer checkpoints (safetensors).

    This is the format the community ships on CivitAI and in ComfyUI-oriented
    Hugging Face repos: one ``.safetensors`` per transformer, in either the native

View on GitHub (pinned to 0b6a024f2f)

Solutions

1. Replace the file with a true Wan 2.2 GGUF from an official/community-trusted repo (Kijai, QuantStack, Comfy-Org)
2. Stop renaming GGUFs hoping to change variant — detection is architectural and will still reject
3. If you specifically need Wan 2.1, use a loader/version that supports it

Example fix

// before
# wan22_t2v.gguf  (actually a renamed Wan 2.1 Q4_K_M file)
// after
# download the real Wan2.2-T2V-A14B gguf; do not rename 2.1 files

from invokeai.backend.model_manager.model_on_disk import ModelOnDisk
from invokeai.backend.model_manager.configs.main import _find_wan_2_1_marker

reason = _find_wan_2_1_marker(ModelOnDisk(path).load_state_dict())
if reason is not None:
    print(f'{path.name} is a Wan 2.1 model despite its name: {reason}')

try:
    import_model(path)
except NotAMatchError as e:
    if str(e).startswith('Wan 2.1 GGUF models are not supported'):
        print('Renaming cannot fix this — the file is architecturally Wan 2.1. Get a 2.2 build.')
    else:
        raise

When it happens

Trigger: Importing a Wan 2.1 GGUF whose filename/metadata lacks 'wan21' (renamed accidentally or by a mirror), so the earlier name check passes but state-dict markers betray the 2.1 architecture; corrupted or hybrid conversions embedding 2.1 block layouts.

Common situations: Renamed downloads from torrent/mirror sites losing the original name; publishers repackaging 2.1 weights under 2.2 names.

Related errors

• Wan 2.1 GGUF models are not supported by the Wan 2.2 loader
• state dict does not look like a Wan transformer
• state dict has no undecorated transformer block weights — it
• {unsupported_reason}
• could not determine Wan variant from state dict

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