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
- 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).
- Update InvokeAI; this defensive check depends on registry format routing that may have been fixed in newer releases.
- 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
- Always import Wan models through the model manager UI/CLI so format routing picks the right loader.
- Do not hand-edit model record format fields.
- Keep InvokeAI updated so registry config classes match loaders.
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
- Expected AutoencoderKLWan for Wan VAE, got {type(vae_info.mo
- Expected Main_GGUF_Wan_Config, got {type(config).__name__}.
- Expected Main_Checkpoint_Wan_Config, got {type(config).__nam
- Expected LlavaOnevisionForConditionalGeneration, got {type(m
- Expected Main_Diffusers_Ideogram4_Config, got {type(config).
AI-assisted analysis of invoke-ai/InvokeAI@0b6a024f2f (2026-08-29).
Data as JSON: /api/errors/1abafd4f034663bf.
Report an issue: GitHub.