invoke-ai/InvokeAI · error · ValueError

Only Gemma2Encoder_GGUF_Config models are supported here.

Error message

Only Gemma2Encoder_GGUF_Config models are supported here.

What it means

Gemma2EncoderGGUFLoader._load_model requires the config to be exactly Gemma2Encoder_GGUF_Config; any other config class reaching this loader raises this ValueError. It is the GGUF-side analogue of the non-GGUF loader's type check.

Source

Thrown at invokeai/backend/model_manager/load/model_loaders/gemma2_encoder.py:132

@ModelLoaderRegistry.register(base=BaseModelType.Any, type=ModelType.Gemma2Encoder, format=ModelFormat.GGUFQuantized)
class Gemma2EncoderGGUFLoader(ModelLoader):
    """Loads a single-file GGUF Gemma-2-2b encoder and exposes its decoder + tokenizer.

    Unlike a naive `from_pretrained(gguf_file=...)` (which dequantizes every weight into RAM/VRAM at load,
    giving no memory saving over the unquantized model), this keeps the large 2D projection weights as
    InvokeAI ``GGMLTensor`` — the model cache's custom linear handling dequantizes them on demand. Only the
    embedding and the RMSNorm weights are materialized eagerly. The tokenizer is still read from the GGUF
    metadata. Mirrors the Qwen3 GGUF encoder loader in ``z_image.py``.
    """

    def _load_model(
        self,
        config: AnyModelConfig,
        submodel_type: Optional[SubModelType] = None,
    ) -> AnyModel:
        if not isinstance(config, Gemma2Encoder_GGUF_Config):
            raise ValueError("Only Gemma2Encoder_GGUF_Config models are supported here.")

        gguf_path = Path(config.path)

        match submodel_type:
            case SubModelType.Tokenizer:
                # The tokenizer is parsed from the GGUF metadata; no model tensors are loaded here.
                return AutoTokenizer.from_pretrained(gguf_path.parent, gguf_file=gguf_path.name, local_files_only=True)
            case SubModelType.TextEncoder:
                compute_dtype = TorchDevice.choose_bfloat16_safe_dtype(TorchDevice.choose_torch_device())
                return load_gemma2_model_from_gguf(gguf_path, compute_dtype)

        raise ValueError(
            f"Unsupported submodel type for Gemma2 encoder: {submodel_type!r}. Expected Tokenizer or TextEncoder."
        )


def load_gemma2_model_from_gguf(gguf_path: Path, compute_dtype: "torch.dtype") -> AnyModel:
    """Build a Gemma2Model from a single-file llama.cpp GGUF, keeping the 2D projection weights quantized.

View on GitHub (pinned to 0b6a024f2f)

Solutions

  1. Re-register/re-convert the model so its config class is Gemma2Encoder_GGUF_Config with format GGUFQuantized
  2. Point the model record at the loader matching its actual format (Gemma2Encoder format for the HF-style loader)
  3. Fix any code constructing configs that mislabels GGUF models

Example fix

# before
config = Gemma2Encoder_Gemma2Encoder_Config(path=x.gguf, format=ModelFormat.GGUFQuantized)
# after
config = Gemma2Encoder_GGUF_Config(path=x.gguf, format=ModelFormat.GGUFQuantized)
Defensive patterns

Strategy: type-guard

Validate before calling

from invokeai.backend.model_manager.config import Gemma2Encoder_GGUF_Config
def can_load_with_gemma2_gguf_loader(config):
    return isinstance(config, Gemma2Encoder_GGUF_Config)

Type guard

def is_gemma2_gguf_config(config) -> bool:
    return isinstance(config, Gemma2Encoder_GGUF_Config)

Try / catch

try:
    model = gguf_loader._load_model(config, submodel_type)
except ValueError as e:
    if "Only Gemma2Encoder_GGUF_Config" in str(e):
        print(f"Config {type(config).__name__} is not a GGUF Gemma2 config; fix the model record")
    else:
        raise

Prevention

When it happens

Trigger: A model stored with format GGUFQuantized but a config object of another class (e.g. Gemma2Encoder_Gemma2Encoder_Config or a generic Diffusers config) dispatched to the GGUF loader; direct calls to _load_model with a mismatched config; corrupt or hand-edited model records.

Common situations: Models converted in-place between safetensors and GGUF without updating their stored config/format; manual DB/models.yaml edits; tests passing synthetic configs to the loader.

Related errors


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