invoke-ai/InvokeAI · error · TypeError

{type(config).__name__} is a single-file config; it does not

Error message

{type(config).__name__} is a single-file config; it does not belong to this loader.

What it means

The Wan (diffusers-style) loader refuses single-file checkpoint configs (Checkpoint_Config_Base subclasses). The model registry keys on format, so single-file Wan checkpoints should be routed to WanCheckpointModel or WanGGUFCheckpointModel instead of this loader; hitting this means routing/registry metadata is wrong.

Source

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

@ModelLoaderRegistry.register(base=BaseModelType.Wan, type=ModelType.Main, format=ModelFormat.Diffusers)
class WanDiffusersModel(GenericDiffusersLoader):
    """Loader for Wan 2.2 diffusers-format models (T2V-A14B and TI2V-5B).

    Forces bfloat16 for the transformer and VAE — fp16 is unstable on Wan VAE
    (same issue affects the Flux VAE). Resolves the appropriate Hugging Face
    class for each submodel via the parent loader's ``get_hf_load_class``.
    """

    def _load_model(
        self,
        config: AnyModelConfig,
        submodel_type: Optional[SubModelType] = None,
    ) -> AnyModel:
        if isinstance(config, Checkpoint_Config_Base):
            # Defensive: the registry keys on format, so single-file configs are
            # routed to WanGGUFCheckpointModel / WanCheckpointModel, not here.
            raise TypeError(f"{type(config).__name__} is a single-file config; it does not belong to this loader.")

        if submodel_type is None:
            raise Exception("A submodel type must be provided when loading Wan main pipelines.")

        if submodel_type is SubModelType.VAE:
            from invokeai.backend.wan.rocm_causal_conv3d import patch_wan_causal_conv3d_for_rocm

            patch_wan_causal_conv3d_for_rocm()

        model_path = Path(config.path)
        load_class = self.get_hf_load_class(model_path, submodel_type)
        repo_variant = config.repo_variant if isinstance(config, Diffusers_Config_Base) else None
        variant = repo_variant.value if repo_variant else None
        model_path = model_path / submodel_type.value

        def _load_with_variant_fallback(dtype_kwarg: dict[str, torch.dtype]) -> AnyModel:
            # Some Wan repos ship without a fp16 variant suffix on every submodel.
            # If the requested variant isn't on disk, fall back to the default weights.

View on GitHub (pinned to 0b6a024f2f)

Solutions

  1. Re-import or edit the model so its format/type match reality (single-file Wan checkpoint should use the checkpoint or GGUF Wan config, not the diffusers-pipeline config).
  2. Update InvokeAI; this defensive check depends on registry format routing that may have been fixed in newer releases.
  3. If calling the loader directly in code, pass a diffusers-style Wan pipeline config or use WanCheckpointModel/WanGGUFCheckpointModel instead.

Example fix

// before
loader = WanModel(...)  # given Main_Checkpoint_Wan_Config

// after
if isinstance(config, Checkpoint_Config_Base):
    loader = WanCheckpointModel(...)  # or WanGGUFCheckpointModel for GGUF
Defensive patterns

Strategy: type-guard

Validate before calling

from invokeai.backend.model_manager.config import Checkpoint_Config_Base
def pick_wan_loader(config):
    return ('checkpoint', config) if isinstance(config, Checkpoint_Config_Base) else ('diffusers', config)

Type guard

def is_single_file_wan_config(config) -> bool:
    return isinstance(config, Checkpoint_Config_Base)

Try / catch

try:
    model = wan_loader.load_model(config, submodel_type)
except TypeError as e:
    if 'single-file config' in str(e):
        model = wan_checkpoint_loader.load_model(config, submodel_type)
    else:
        raise

Prevention

When it happens

Trigger: A Wan model registered with format=diffusers (folder) whose config object is actually a Checkpoint_Config_Base subclass reaches WanModel._load_model; custom code instantiates the loader directly with a checkpoint config.

Common situations: Model imported with the wrong format/type so the registry dispatches to the wrong loader; stale model record after InvokeAI version upgrade changed loader routing; hand-edited model config.

Related errors


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