What causes "There are no submodels in a LoRA model." in invoke-ai/InvokeAI?

Load the LoRA with submodel_type=None and apply it via its ModelKey through the LoRA patching/apply API instead.

invoke-ai/InvokeAI · error · ValueError

There are no submodels in a LoRA model.

Error message

There are no submodels in a LoRA model.

What it means

This ValueError is raised by the LoRA loader when _load_model is called with a non-None submodel_type. LoRAs are single weight files with no submodel structure (no tokenizer, VAE, etc.), so the API contract is to load them whole; requesting a submodel of a LoRA is always a caller mistake.

Source

Thrown at invokeai/backend/model_manager/load/model_loaders/lora.py:99

    # We cheat a little bit to get access to the model base
    def __init__(
        self,
        app_config: InvokeAIAppConfig,
        logger: Logger,
        ram_cache: ModelCache,
    ):
        """Initialize the loader."""
        super().__init__(app_config, logger, ram_cache)
        self._model_base: Optional[BaseModelType] = None

    def _load_model(
        self,
        config: AnyModelConfig,
        submodel_type: Optional[SubModelType] = None,
    ) -> AnyModel:
        if submodel_type is not None:
            raise ValueError("There are no submodels in a LoRA model.")
        model_path = Path(config.path)
        assert self._model_base is not None

        # Load the state dict from the model file.
        if model_path.suffix == ".safetensors":
            state_dict = load_file(model_path.absolute().as_posix(), device="cpu")
        else:
            state_dict = torch.load(model_path, map_location="cpu")

        # Strip 'bundle_emb' keys - these are unused and currently cause downstream errors.
        # To revisit later to determine if they're needed/useful.
        state_dict = {k: v for k, v in state_dict.items() if not k.startswith("bundle_emb")}

        # Normalize PEFT named-adapter keys (e.g. `lora_A.default.weight` → `lora_A.weight`)
        # so the downstream format detectors and converters see canonical PEFT keys.
        state_dict = normalize_peft_adapter_names(state_dict)

        # At the time of writing, we support the OMI standard for base models Flux and SDXL

View on GitHub (pinned to 0b6a024f2f)

Solutions

Load the LoRA with submodel_type=None and apply it via its ModelKey through the LoRA patching/apply API instead.
Do not request submodels for LoRA models; merge/patch behavior is handled at inference time (e.g. via the lora Patcher classes).
Verify the model key being loaded is the LoRA record, not the base checkpoint that has submodels.
Update InvokeAI if following an outdated tutorial that predates the current LoRA loading API.

Example fix

// before
lora = loader._load_model(lora_config, SubModelType.TextEncoder)  # raises
// after
lora_model = loader._load_model(lora_config, submodel_type=None)  # LoRAs load whole
# then apply at inference, e.g. with LoRAPatcher using the lora model key

Defensive patterns

Strategy: validation

Validate before calling

if submodel_type is not None:
    raise ValueError("LoRA models have no submodels; pass submodel_type=None")

Type guard

def is_lora(config: AnyModelConfig) -> bool:
    return getattr(config, 'format', None) in (ModelFormat.Lora, ModelFormat.LyCORIS)

# for LoRA configs, always load with submodel_type=None

Try / catch

try:
    model = loader._load_model(config, submodel_type)
except ValueError as e:
    if 'no submodels in a LoRA' in str(e):
        model = loader._load_model(config, submodel_type=None)
    else:
        raise

Prevention

Load LoRAs whole (submodel_type=None) and apply them at inference via the LoRA patcher.
Never treat LoRA entries as base models when enumerating submodels.
Use ModelManager.load_model with the LoRA's ModelKey instead of calling the loader directly.
Validate model type before writing generic submodel loops.

When it happens

Trigger: Calling ModelManager/load with a LoRA model key and any SubModelType (e.g. Tokenizer, TextEncoder, Vae); generic loops that pass a submodel_type for every model regardless of family.

Common situations: Writing pipeline-assembly code that treats LoRAs like base models; UI code enumerating submodels of a checkpoint and accidentally including attached LoRA entries; loading a LoRA key obtained from a config that lists it as if it had submodels.

Related errors

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