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
- Request only SubModelType.Tokenizer or SubModelType.TextEncoder for Gemma2 encoder models
- Do not pass submodel_type=None; the loader requires an explicit Tokenizer/TextEncoder
- 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
- Only request Tokenizer/TextEncoder from Gemma2 encoder models
- Never pass submodel_type=None to this loader
- Branch on model type before requesting VAE/scheduler submodels
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
- Only Gemma2Encoder_Gemma2Encoder_Config models are supported
- Only Gemma2Encoder_GGUF_Config models are supported here.
- There are no submodels in models of type {model_class}
- The "{submodel_type}" submodel is not available for this mod
- A submodel type must be provided when loading main pipelines
AI-assisted analysis of invoke-ai/InvokeAI@0b6a024f2f (2026-08-29).
Data as JSON: /api/errors/08ef7525ed84e3ac.
Report an issue: GitHub.