invoke-ai/InvokeAI · error · NotAMatchError

{unsupported_reason}

Error message

{unsupported_reason}

What it means

Raised when _find_unsupported_wan_variant_marker(sd) returns a non-None reason string, which is re-raised verbatim as a NotAMatchError. This detects architectural markers in the GGUF state dict indicating a Wan variant the Wan 2.2 GGUF loader does not cover (gated by inspecting tensor shapes/keys, not just names).

Source

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

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

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

View on GitHub (pinned to 0b6a024f2f)

Solutions

1. Read the raised reason string to see which variant marker was detected and check InvokeAI release notes for support status
2. Update InvokeAI to the latest version, which may have added support for that Wan variant
3. Use the variant via ComfyUI or another loader that supports it until InvokeAI support lands

try:
    import_model(path)
except NotAMatchError as e:
    reason = str(e)
    if 'not supported' in reason or 'variant' in reason:
        logger.warning('Wan GGUF rejected: %s — check InvokeAI release notes for variant support', reason)
    else:
        raise

When it happens

Trigger: Importing a Wan GGUF whose state dict carries a marker for an unsupported variant (outside the T2V/I2V-A14B and TI2V-5B set the loader handles); novel or repackaged GGUF builds emitting nonstandard transformer layouts.

Common situations: Trying brand-new Wan releases right after launch, before InvokeAI adds support; community-repacked GGUFs with hybrid/modified architectures.

Related errors

• state dict does not look like a Wan transformer
• state dict has no undecorated transformer block weights — it
• 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/81d08ebe32d42cbd. Report an issue: GitHub.