invoke-ai/InvokeAI · error · ValueError

Unsupported submodel type for Gemma2 encoder: {submodel_type

Error message

Unsupported submodel type for Gemma2 encoder: {submodel_type!r}. Expected Tokenizer or TextEncoder.

What it means

Gemma2EncoderLoader only supports loading SubModelType.Tokenizer (via AutoTokenizer) and SubModelType.TextEncoder (the causal LM's decoder). Any other submodel request — or the whole-model path when the match falls through — raises this ValueError.

Source

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

                target_device = TorchDevice.choose_torch_device()
                model_dtype = TorchDevice.choose_bfloat16_safe_dtype(target_device)
                causal_lm = AutoModelForCausalLM.from_pretrained(
                    model_path,
                    torch_dtype=model_dtype,
                    low_cpu_mem_usage=True,
                    local_files_only=True,
                )
                # PiD only ever uses the decoder block — the transformer stack
                # without the LM head. Upstream calls `.get_decoder()`, but
                # transformers 4.56 returns None for Gemma2, so we reach for
                # `.model` (the underlying Gemma2Model) directly and let the
                # rest of `causal_lm` (lm_head etc.) be garbage-collected.
                inner = getattr(causal_lm, "get_decoder", lambda: None)() or causal_lm.model
                inner.eval()
                inner.requires_grad_(False)
                return inner

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


@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,

View on GitHub (pinned to 0b6a024f2f)

Solutions

  1. Request only SubModelType.Tokenizer or SubModelType.TextEncoder for Gemma2 encoder models
  2. Do not pass submodel_type=None; the loader requires an explicit Tokenizer/TextEncoder
  3. Fix the calling code so Gemma2 models are not asked for VAE/scheduler submodels

Example fix

# before
model = loader._load_model(config, submodel_type=None)
# after
model = loader._load_model(config, submodel_type=SubModelType.TextEncoder)
Defensive patterns

Strategy: validation

Validate before calling

SUPPORTED = {SubModelType.Tokenizer, SubModelType.TextEncoder}
def gemma2_submodel_supported(submodel_type):
    return submodel_type in SUPPORTED

Type guard

def is_gemma2_submodel(st: SubModelType | None) -> bool:
    return st in (SubModelType.Tokenizer, SubModelType.TextEncoder)

Try / catch

try:
    model = loader._load_model(config, submodel_type)
except ValueError as e:
    if "Unsupported submodel type for Gemma2 encoder" in str(e):
        print(f"{submodel_type} not provided by Gemma2 encoder; use Tokenizer or TextEncoder")
    else:
        raise

Prevention

When it happens

Trigger: Requesting submodel_type=None, SubModelType.Vae, Scheduler, Main, or any value other than Tokenizer/TextEncoder from a Gemma2Encoder-format model; passing None because the caller treats it as a single-file model rather than a submodel container.

Common situations: Generic code paths that always pass submodel_type=None; pipeline assembly code requesting a Vae/Scheduler from a text-encoder-only model; tests or scripts probing unsupported submodel types.

Related errors


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