invoke-ai/InvokeAI · error · TypeError

Expected Main_GGUF_Wan_Config, got {type(config).__name__}.

Error message

Expected Main_GGUF_Wan_Config, got {type(config).__name__}.

What it means

The Wan GGUF single-file loader asserts its input config type: only Main_GGUF_Wan_Config is valid here. Any other config (including the non-GGUF Main_Checkpoint_Wan_Config) indicates the registry dispatched the model to the wrong loader, so a TypeError naming the actual config type is raised.

Source

Thrown at invokeai/backend/model_manager/load/model_loaders/wan.py:407

    The community typically distributes Wan A14B as two files (one per expert
    — high-noise + low-noise). Each file is loaded independently here; the
    pairing happens at the WanModelLoaderInvocation layer. TI2V-5B ships as a
    single file.

    Mirrors the QwenImage GGUF loader pattern: ``gguf_sd_loader`` -> strip the
    ComfyUI ``model.diffusion_model.`` / ``diffusion_model.`` prefix if present
    -> auto-detect arch from state-dict shapes -> ``init_empty_weights`` +
    ``load_state_dict(strict=False, assign=True)``.
    """

    def _load_model(
        self,
        config: AnyModelConfig,
        submodel_type: Optional[SubModelType] = None,
    ) -> AnyModel:
        if not isinstance(config, Main_GGUF_Wan_Config):
            raise TypeError(f"Expected Main_GGUF_Wan_Config, got {type(config).__name__}.")

        if submodel_type != SubModelType.Transformer:
            raise ValueError(
                "Only the Transformer submodel is available from a GGUF Wan checkpoint. "
                "Pair with a standalone Wan VAE and Wan T5 encoder for the other components."
            )

        return self._load_from_singlefile(config)

    def _load_from_singlefile(self, config: Main_GGUF_Wan_Config) -> AnyModel:
        import accelerate
        from diffusers import WanTransformer3DModel

        from invokeai.backend.util.logging import InvokeAILogger

        model_path = Path(config.path)
        target_device = TorchDevice.choose_torch_device()
        compute_dtype = TorchDevice.choose_bfloat16_safe_dtype(target_device)

View on GitHub (pinned to 0b6a024f2f)

Solutions

1. Re-import the model selecting the correct format: GGUF quantized Wan → GGUF config; regular safetensors → checkpoint config.
2. If the file is not GGUF-quantized, let it load through Main_Checkpoint_Wan_Config's loader instead.
3. Upgrade InvokeAI if the registry routing appears inconsistent for your model type.

Example fix

// before
config = Main_Checkpoint_Wan_Config(...)  # routed to GGUF loader

// after
config = Main_GGUF_Wan_Config(...)  # or use checkpoint loader for non-GGUF file

def is_gguf_wan(config) -> bool:
    return type(config).__name__ == 'Main_GGUF_Wan_Config'

from invokeai.backend.model_manager.config import Main_GGUF_Wan_Config

def is_gguf_wan_config(config) -> bool:
    return isinstance(config, Main_GGUF_Wan_Config)

try:
    model = wan_gguf_loader.load_model(config, SubModelType.Transformer)
except TypeError as e:
    if 'Expected Main_GGUF_Wan_Config' in str(e):
        model = wan_checkpoint_loader.load_model(config, SubModelType.Transformer)
    else:
        raise

When it happens

Trigger: A Wan GGUF loader receives a non-GGUF config — e.g., a normal checkpoint or diffusers Wan config was registered with a GGUF format, or the registry's format→loader mapping is out of sync after an upgrade.

Common situations: Model imported choosing the wrong format (GGUF vs regular checkpoint); editing model records by hand; mixing InvokeAI versions where config class names changed.

Related errors

• Expected AutoencoderKLWan for Wan VAE, got {type(vae_info.mo
• {type(config).__name__} is a single-file config; it does not
• Only the Transformer submodel is available from a GGUF Wan c
• Expected Main_Checkpoint_Wan_Config, got {type(config).__nam
• Expected Main_GGUF_ZImage_Config, got {type(config).__name__

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