invoke-ai/InvokeAI · error · NotAMatchError

state dict does not look like a Wan transformer

Error message

state dict does not look like a Wan transformer

What it means

Raised by Main_GGUF_Wan_Config.from_model_on_disk when the state dict is GGUF-quantized (has GGMLTensors) but contains no keys matching Wan transformer architecture patterns (_has_wan_keys fails). The GGUF wrapper itself matched, so the file is a quantized model of some other architecture (FLUX, Qwen, SDXL, UMT5, VAE, etc.).

Source

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

    format: Literal[ModelFormat.GGUFQuantized] = Field(default=ModelFormat.GGUFQuantized)
    variant: WanVariantType = Field()
    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:

View on GitHub (pinned to 0b6a024f2f)

Solutions

1. Verify the GGUF actually is a Wan 2.2 DiT transformer (filename/metadata like Wan2.2-I2V-A14B / TI2V-5B), not a text encoder, VAE, or another architecture
2. Move non-Wan GGUFs out of the Wan/autoimport path or import them with the correct model type (text encoder / VAE / etc.)
3. Re-download the file if it was mislabeled by the publisher

Example fix

// before
# umt5-xxl-encoder-Q8_0.gguf dropped in autoimport as a main model
// after
# place the UMT5 GGUF with the text-encoder models and import as its proper type;
# keep only Wan2.2-*.gguf DiT files for the Wan transformer loader

from invokeai.backend.model_manager.model_on_disk import ModelOnDisk
from invokeai.backend.model_manager.configs.main import _has_ggml_tensors, _has_wan_keys

sd = ModelOnDisk(path).load_state_dict()
assert _has_ggml_tensors(sd), 'not GGUF'
assert _has_wan_keys(sd), 'GGUF is not a Wan transformer — check what architecture this file actually is'

def is_wan_gguf(sd: dict) -> bool:
    return _has_ggml_tensors(sd) and _has_wan_keys(sd)

try:
    import_model(path, model_type='main')
except NotAMatchError as e:
    if 'Wan transformer' in str(e):
        print(f'{path.name} is not a Wan DiT; import it with its correct model type')
    else:
        raise

When it happens

Trigger: Importing a non-Wan GGUF (e.g. FLUX.1-dev-Q4_K_M.gguf) into a scan folder where the Wan config is tried; importing a Wan text-encoder or VAE GGUF whose keys don't match transformer patterns; a Wan LoRA/CLIP GGUF routed to the main-model configs.

Common situations: Bulk-downloading mixed GGUF repos and dropping everything into InvokeAI's autoimport directory; confusing Wan transformer GGUFs with Wan UMT5-XXL text-encoder GGUFs.

Related errors

• state dict has no undecorated transformer block weights — it
• {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/cf927adb5551ee48. Report an issue: GitHub.