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

  1. Verify the LoRA file is a valid Z-Image-compatible LoRA and re-download if corrupted
  2. Re-scan/re-import the LoRA in the model manager so it is registered with the correct model type
  3. Remove the incompatible LoRA from the transformer's loras list
  4. 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

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


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