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

LoRAs applied to the Krea-2 transformer must be loaded as ModelPatchRaw patch objects. `_lora_iterator` loads each LoRA model from the model manager and raises a TypeError if the loaded model instance is not a ModelPatchRaw, indicating the model record resolved to an unexpected type (wrong model type/format for a LoRA slot).

Source

Thrown at invokeai/app/invocations/krea2_denoise.py:588

            # Conditional/unconditional passes are sequential, but the larger combined sequence and extra
            # transient buffers warrant a modest bump.
            estimated = int(estimated * 1.1)
        estimated += regional_attention_mask_bytes
        if num_loras > 0:
            estimated += int(0.5 * num_loras * GB)
        return estimated

    def _build_step_callback(self, context: InvocationContext) -> Callable[[PipelineIntermediateState], None]:
        def step_callback(state: PipelineIntermediateState) -> None:
            context.util.sd_step_callback(state, BaseModelType.Krea2)

        return step_callback

    def _lora_iterator(self, context: InvocationContext) -> Iterator[PatchSpec]:
        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__}."
                )
            yield (lora_info.model, lora.weight, lora_info.model_in_ram())

View on GitHub (pinned to 0b6a024f2f)

Solutions

Re-select the LoRA in the workflow so the ModelField key points to the correct LoRA model record.
Re-import/re-convert the LoRA so the model manager registers it as a patch (ModelPatchRaw) rather than another model type.
Check the model's recorded type/format in the model manager UI and fix or delete stale records before retrying.

Example fix

// before: key resolves to a full checkpoint model
lora_field = ModelField(key="<checkpoint-model-key>")
// after: key of a registered Krea-2 LoRA patch
lora_field = ModelField(key="<krea2-lora-model-key>")

Defensive patterns

Strategy: type-guard

Validate before calling

lora_info = context.models.load(lora.lora)
if not isinstance(lora_info.model, ModelPatchRaw):
    raise TypeError(f"Model {lora.lora.key} is {type(lora_info.model).__name__}, not a LoRA patch; re-import as LoRA.")

Type guard

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

Try / catch

try:
    out = invoke_krea2_denoise(transformer=..., loras=loras)
except TypeError as e:
    if "Expected ModelPatchRaw" in str(e):
        loras = [reselect_valid_lora(l) for l in loras]
        out = invoke_krea2_denoise(transformer=..., loras=loras)
    else:
        raise

Prevention

Verify each LoRA's model type in the model manager before adding it to the graph.
Re-import LoRAs after InvokeAI version migrations and delete stale records.
Never point LoRA ModelFields at full checkpoints or VAE models.

When it happens

Trigger: A transformer.loras entry whose ModelField key points to a model record that loads as a regular transformer/VAE/main model instead of a LoRA patch — e.g. a stale model key after re-install, or a non-Krea-2 LoRA converted/registered with the wrong model type.

Common situations: Model manager records migrated from an older InvokeAI version with changed model types; users pointing the LoRA field at a checkpoint rather than a LoRA; corrupted model-install records where the LoRA was imported without patch conversion.

Related errors

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