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__}. The LoRA model may be corrupted or incompatible. What it means
Z-Image LoRAs must load as ModelPatchRaw — a raw patch applied to the transformer. If context.models.load returns some other model type for a LoRA entry, _lora_iterator raises TypeError, indicating the stored model is corrupted, misclassified, or incompatible with the Z-Image pipeline.
Source
Thrown at invokeai/app/invocations/z_image_denoise.py:808
height=self.height,
width=self.width,
dtype=inference_dtype,
device=device,
seed=self.seed,
)
def _build_step_callback(self, context: InvocationContext) -> Callable[[PipelineIntermediateState], None]:
def step_callback(state: PipelineIntermediateState) -> None:
context.util.sd_step_callback(state, BaseModelType.ZImage)
return step_callback
def _lora_iterator(self, context: InvocationContext) -> Iterator[PatchSpec]:
"""Iterate over LoRA models to apply to the transformer."""
for lora in self.transformer.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__}. "
"The LoRA model may be corrupted or incompatible."
)
yield (lora_info.model, lora.weight, lora_info.model_in_ram())
View on GitHub (pinned to 0b6a024f2f)
Solutions
- Verify the LoRA file is a valid Z-Image-compatible LoRA and re-download if corrupted
- Re-scan/re-import the LoRA in the model manager so it is registered with the correct model type
- Remove the incompatible LoRA from the transformer's loras list
- Update InvokeAI in case LoRA format support was extended
Example fix
// before loras=[LoRAModelField(lora=sd_lora_key, weight=0.8)] # SD LoRA // after loras=[LoRAModelField(lora=z_image_lora_key, weight=0.8)] # compatible Z-Image LoRA
Defensive patterns
Strategy: type-guard
Validate before calling
for lora in denoise.transformer.loras:
info = context.models.load(lora.lora)
if not isinstance(info.model, ModelPatchRaw):
raise TypeError(f"LoRA {lora.lora.key} is not ModelPatchRaw ({type(info.model).__name__})") Type guard
def is_valid_lora(context, lora_field) -> bool:
from invokeai.backend.model_manager.load.model_cache.model_cache import ModelPatchRaw # adjust import path
info = context.models.load(lora_field.lora)
return isinstance(info.model, ModelPatchRaw) Try / catch
try:
output = denoise.invoke(context)
except TypeError as e:
if "Expected ModelPatchRaw for LoRA" in str(e):
drop_incompatible_lora(extract_lora_key(str(e)))
else:
raise Prevention
- Use only LoRAs trained/tested for Z-Image
- Re-scan misclassified LoRAs in the model manager
- Hash-verify downloaded LoRA files
When it happens
Trigger: A LoRA in self.transformer.loras whose loaded model is not ModelPatchRaw — e.g. the model manager registered the file under a wrong model type/format, so it loads as a different class.
Common situations: Using a LoRA trained for a different architecture (SD/Flux) with Z-Image; a model-manager scan misclassifying the LoRA file; a corrupted or partially downloaded LoRA file; quantized LoRA formats lacking a patch path.
Related errors
- Expected ModelPatchRaw for LoRA '{lora.lora.key}', got {type
- LoRA '{lora.lora.key}' is for {lora.lora.base.value if lora.
- LoRA '{lora.lora.key}' is for {lora.lora.base.value if lora.
- Expected ModelPatchRaw for LoRA '{lora.lora.key}', got {type
- LoRA '{lora_key}' is for {stored_config.base.value if stored
AI-assisted analysis of invoke-ai/InvokeAI@0b6a024f2f (2026-08-29).
Data as JSON: /api/errors/1102abe18274a6b5.
Report an issue: GitHub.