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

What it means

Raised by Main_GGUF_Wan_Config when the normalized identity (lowercased alphanumerics of the filename stem plus GGUF general.name metadata) contains 'wan21'. Wan 2.1 GGUF transformers are incompatible with the Wan 2.2 loader, so they are rejected explicitly by name before deeper architectural checks.

Source

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

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

        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)

View on GitHub (pinned to 0b6a024f2f)

Solutions

1. Delete the Wan 2.1 GGUF and download the Wan 2.2 equivalents (Wan2.2-T2V-A14B / I2V-A14B / TI2V-5B GGUF builds)
2. Upgrade InvokeAI to a version whose Wan loader supports 2.1, if available
3. Renaming the file is not a fix: misnamed 2.1 files are still caught later by the architectural _find_wan_2_1_marker check

Example fix

// before
# Wan2.1-T2V-14B-Q4_K_M.gguf in autoimport/main/
// after
# rm Wan2.1-T2V-14B-Q4_K_M.gguf && add Wan2.2-T2V-A14B-high-noise-Q4_K_M.gguf

identity = ''.join(c for c in path.stem.lower() if c.isalnum())
if 'wan21' in identity:
    raise SystemExit(f'{path.name} is Wan 2.1 — the Wan 2.2 loader cannot use it; download a 2.2 build')

try:
    import_model(path)
except NotAMatchError as e:
    if 'Wan 2.1' in str(e):
        queue_download('Wan2.2-T2V-A14B-high-noise-Q4_K_M.gguf')  # replace with 2.2 equivalent
    else:
        raise

When it happens

Trigger: Importing a Wan2.1 T2V/I2V/FLF2V GGUF (e.g. Wan2.1-T2V-14B-Q4_K_M.gguf) into InvokeAI; a filename like Wan2.1... or metadata general.name like 'Wan 2.1' triggers the normalized-identity substring match.

Common situations: Following older tutorials/HF links for Wan2.1 GGUFs while running a Wan-2.2-only InvokeAI version; autoimport folders that accumulated Wan 2.1 downloads from earlier workflows.

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/0658d9f492b3072a. Report an issue: GitHub.