invoke-ai/InvokeAI · error · TypeError

Expected ModelPatchRaw for LoRA '{lora.lora.key}', got {type

Error message

Expected ModelPatchRaw for LoRA '{lora.lora.key}', got {type(lora_info.model).__name__}.

What it means

This TypeError is raised in _lora_iterator when a LoRA loaded via context.models.load for the Qwen3-VL text encoder resolves to a model object that is not a ModelPatchRaw. LayerPatcher.apply_smart_model_patches expects each patch spec to be a raw LoRA patch model; a different model type (e.g. a full main model or checkpoint) cannot be applied as a LoRA patch, so the code fails fast with a clear message naming the offending LoRA key.

Source

Thrown at invokeai/app/invocations/krea2_text_encoder.py:167

            # Stack the selected layers along a new layer axis: (B, seq, 12, hidden).
            stacked = torch.stack([hidden_states_tuple[i] for i in KREA2_SELECT_LAYERS], dim=2)

            # Drop the system-prompt prefix tokens.
            prompt_embeds = stacked[:, KREA2_START_IDX:]
            prompt_mask = attention_mask[:, KREA2_START_IDX:].bool()

            # Match the device-safe compute dtype used by the denoise loop (falls back from bf16 to
            # fp16/fp32 on devices without bf16 support) rather than forcing bfloat16.
            prompt_embeds = prompt_embeds.to(dtype=TorchDevice.choose_bfloat16_safe_dtype(device))

        return prompt_embeds, prompt_mask

    def _lora_iterator(self, context: InvocationContext) -> Iterator[PatchSpec]:
        """Iterate over the LoRA models to apply to the Qwen3-VL text encoder."""
        for lora in self.qwen3_vl_encoder.loras:
            lora_info = context.models.load(lora.lora)
            if not isinstance(lora_info.model, ModelPatchRaw):
                raise TypeError(
                    f"Expected ModelPatchRaw for LoRA '{lora.lora.key}', got {type(lora_info.model).__name__}."
                )
            yield (lora_info.model, lora.weight, lora_info.model_in_ram())

View on GitHub (pinned to 0b6a024f2f)

Solutions

  1. Open the Model Manager, find the LoRA with the reported key, and re-import/convert it so it is classified as a LoRA (ModelPatchRaw).
  2. Fix the model record's type/config in the model manager database or remove and rescan the models directory so the file is detected as a LoRA.
  3. Disconnect any non-LoRA model connected to the LoRA input of the Qwen3-VL encoder node and connect a valid LoRA.
  4. Verify the LoRA file format is supported (correct LoRA key layout) rather than a merged checkpoint, and update InvokeAI if the file uses a newer format.

Example fix

// before (model record classified as main model)
config = {"path": "my_lora.safetensors", "type": "main", "base": "krea-2"}
// after
config = {"path": "my_lora.safetensors", "type": "lora", "base": "krea-2"}
Defensive patterns

Strategy: type-guard

Validate before calling

# Before invoking, verify every attached LoRA loads as a patch model
for lora in self.qwen3_vl_encoder.loras:
    info = context.models.load(lora.lora)
    if not isinstance(info.model, ModelPatchRaw):
        raise ValueError(f"LoRA {lora.lora.key} is not classified as a LoRA in the model manager")

Type guard

from invokeai.backend.patches.model_patch_raw import ModelPatchRaw

def is_lora_patch(model: object) -> bool:
    return isinstance(model, ModelPatchRaw)

Try / catch

try:
    output = krea2_text_encoder.invoke(context)
except TypeError as e:
    if "Expected ModelPatchRaw" in str(e):
        bad_key = str(e).split("'")[1]
        logger.error(f"Model {bad_key} is not a LoRA; re-import it as a LoRA in the Model Manager.")
        raise
    raise

Prevention

When it happens

Trigger: A LoRA model record referenced in qwen3_vl_encoder.loras whose key points at a non-patch model type in the model manager — e.g. the file was imported/detected as a full checkpoint instead of a LoRA, a converted-format mismatch (diffusers vs checkpoint LoRA config), or a main model was accidentally connected to the LoRA input field.

Common situations: A user downloads a LoRA whose folder layout or metadata makes InvokeAI classify it as a main model; model-manager scan misclassifies a renamed .safetensors file; a stale model record from an earlier InvokeAI version has the wrong model_type; wiring a checkpoint into a LoRA socket in the workflow editor.

Related errors


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