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
- Open the Model Manager, find the LoRA with the reported key, and re-import/convert it so it is classified as a LoRA (ModelPatchRaw).
- 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.
- Disconnect any non-LoRA model connected to the LoRA input of the Qwen3-VL encoder node and connect a valid LoRA.
- 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
- Import LoRA files through the Model Manager so they are correctly classified as type 'lora'.
- Never connect main-model/checkpoint entries to LoRA input sockets in workflows.
- Rescan the models directory after manually moving or renaming LoRA files.
- After InvokeAI upgrades, verify old model records still resolve to ModelPatchRaw.
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
- Expected ModelPatchRaw for LoRA '{lora.lora.key}', got {type
- Unknown lora: {lora.lora.key}!
- Unknown lora: {lora_key}!
- Unknown lora: {lora.lora.key}!
- Expected ModelPatchRaw for LoRA '{lora.lora.key}', got {type
AI-assisted analysis of invoke-ai/InvokeAI@0b6a024f2f (2026-08-29).
Data as JSON: /api/errors/7715ee35435af27e.
Report an issue: GitHub.