invoke-ai/InvokeAI · error · TypeError

Expected Qwen3Encoder_GGUF_Config, got {type(config).__name_

Error message

Expected Qwen3Encoder_GGUF_Config, got {type(config).__name__}. Model configuration type mismatch.

What it means

_load_from_gguf independently re-checks that the config is a Qwen3Encoder_GGUF_Config and raises a TypeError that includes the actual received type name when it is not. Like its single-file counterpart (1334), this is a defense-in-depth guard meant to catch direct or refactored calls that bypass the _load_model dispatch check.

Source

Thrown at invokeai/backend/model_manager/load/model_loaders/z_image.py:1201

        Single-file / GGUF checkpoints do not ship tokenizer files. The Qwen3 BPE
        tokenizer is identical across the 0.6B / 4B / 8B variants, so we load the
        self-contained copy vendored in the package — fully offline, no HuggingFace
        download required.
        """
        return load_bundled_qwen3_tokenizer()

    def _load_from_gguf(
        self,
        config: AnyModelConfig,
    ) -> AnyModel:
        from transformers import Qwen3Config, Qwen3ForCausalLM

        from invokeai.backend.util.logging import InvokeAILogger

        logger = InvokeAILogger.get_logger(self.__class__.__name__)

        if not isinstance(config, Qwen3Encoder_GGUF_Config):
            raise TypeError(
                f"Expected Qwen3Encoder_GGUF_Config, got {type(config).__name__}. Model configuration type mismatch."
            )
        model_path = Path(config.path)

        # Determine safe dtype based on target device capabilities
        target_device = TorchDevice.choose_torch_device()
        compute_dtype = TorchDevice.choose_bfloat16_safe_dtype(target_device)

        # Load the GGUF state dict - this returns GGMLTensor wrappers (on CPU)
        # We keep them on CPU and let the model cache system handle GPU movement
        # via apply_custom_layers_to_model() and the partial loading cache
        sd = gguf_sd_loader(model_path, compute_dtype=compute_dtype)

        # Check if this is llama.cpp format (blk.X.) or PyTorch format (model.layers.X.)
        is_llamacpp_format = any(k.startswith("blk.") for k in sd.keys() if isinstance(k, str))

        if is_llamacpp_format:
            logger.info("Detected llama.cpp GGUF format, converting keys to PyTorch format")

View on GitHub (pinned to 0b6a024f2f)

Solutions

Pass a real Qwen3Encoder_GGUF_Config (the message names the type you actually passed).
Re-create the model registration so the correct GGUF config class is instantiated by the model manager.
When calling internals directly, instantiate Qwen3Encoder_GGUF_Config with the GGUF file path rather than reusing another config type.
Align InvokeAI versions across services/scripts so config classes match.

Example fix

// before
self._load_from_gguf(checkpoint_config)
// after
assert isinstance(config, Qwen3Encoder_GGUF_Config), type(config).__name__
self._load_from_gguf(config)

Defensive patterns

Strategy: type-guard

Validate before calling

if not isinstance(config, Qwen3Encoder_GGUF_Config):
    raise TypeError(f"Cannot GGUF-load with {type(config).__name__}")

Type guard

def is_qwen3_gguf(c: AnyModelConfig) -> bool:
    return isinstance(c, Qwen3Encoder_GGUF_Config)

Try / catch

try:
    model = loader._load_from_gguf(config)
except TypeError as e:
    if "Expected Qwen3Encoder_GGUF_Config" in str(e):
        config = Qwen3Encoder_GGUF_Config(path=gguf_path)
        model = loader._load_from_gguf(config)
    else:
        raise

Prevention

Prefer _load_model over calling _load_from_gguf directly.
Build GGUF configs via the model manager registry.
Re-instantiate persisted configs after upgrades instead of reusing stale objects.
Use the type name in the error message to identify the misrouted config quickly.

When it happens

Trigger: Invoking _load_from_gguf directly with a checkpoint or generic config; a wrapper/subclass passes a config that no longer passes isinstance; config objects reloaded from persistence losing their concrete GGUF config class.

Common situations: Custom scripts driving loader internals; mixed InvokeAI versions/config definitions after an upgrade; automated pipelines reusing one config object across checkpoint and GGUF loaders.

Related errors

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