invoke-ai/InvokeAI · error · TypeError

Expected PidNet for PiD decoder, got {type(pid_net).__name__

Error message

Expected PidNet for PiD decoder, got {type(pid_net).__name__}.

What it means

After loading the PiD (decode) network onto the device with a working-memory budget, the code asserts the loaded object is actually a PidNet instance before decoding SDXL latents. Any other type means the wrong model was wired into the decoder field or the model record is misregistered.

Source

Thrown at invokeai/app/invocations/sdxl_pid_decode.py:184

        # Gemma is only needed for the one-shot caption encode above. Offload it from VRAM (keeping it in the RAM
        # cache) so its ~5GB is freed before the PiD decoder loads. The cache offloads anything else it needs to
        # fit the decode on its own, so we deliberately do NOT evict every other model here.
        context.models.offload_from_vram(self.gemma2_encoder.text_encoder)
        TorchDevice.empty_cache()

        # 3) Run PiD decode (the loader already returns a live PidNet).
        pid_info = context.models.load(self.pid_decoder.decoder)
        # Read once: the estimate and the decode must agree, or the cache reserves headroom for a
        # peak that will not happen (or too little for one that will).
        pid_memory_optimization = context.config.get().pid_memory_optimization
        estimated_working_memory = estimate_pid_decode_working_memory(
            latents,
            BaseModelType.StableDiffusionXL,
            pid_memory_optimization,
        )
        with pid_info.model_on_device(working_mem_bytes=estimated_working_memory) as (_, pid_net):
            if not isinstance(pid_net, PidNet):
                raise TypeError(f"Expected PidNet for PiD decoder, got {type(pid_net).__name__}.")
            device = TorchDevice.choose_torch_device()
            dtype = next(iter(pid_net.parameters())).dtype

            # SDXL latents come out of the LDM in the VAE-normalized space; denormalise so PiD sees the raw latent.
            denorm_latent = latents.to(device=device, dtype=dtype) / scaling_factor + shift_factor
            caption_embs = caption_embs.to(device=device, dtype=dtype)

            context.util.signal_progress("Running PiD decoder")
            decoder = PiDDecoder(pid_net, backbone=BaseModelType.StableDiffusionXL)
            x0 = decoder.decode(
                latent=denorm_latent,
                caption_embs=caption_embs,
                caption_mask=caption_mask,
                config=PiDDecodeConfig(
                    num_inference_steps=self.num_inference_steps,
                    seed=self.seed,
                    pid_memory_optimization=pid_memory_optimization,
                ),

View on GitHub (pinned to 0b6a024f2f)

Solutions

  1. Connect a genuine PiD model record to the PiD decode node and re-run.
  2. Re-register/re-import the PiD model so its record is typed correctly.
  3. Check that the model's loader/class config maps to the PidNet class.
  4. If memory pressure caused a fallback loader path, raise working memory or move the model to CPU.

Example fix

// before
with pid_info.model_on_device(working_mem_bytes=estimated_working_memory) as (_, pid_net):
    if not isinstance(pid_net, PidNet):
        raise TypeError(...)
// after
with pid_info.model_on_device(working_mem_bytes=estimated_working_memory) as (_, pid_net):
    if not isinstance(pid_net, PidNet):
        raise TypeError(f"Expected PidNet, got {type(pid_net).__name__}; check the model wired to the decoder.")
Defensive patterns

Strategy: type-guard

Validate before calling

if node.pid_model.base_model != BaseModelType.StableDiffusionXL:
    raise ValueError("PiD decoder requires an SDXL PiD model")

Type guard

def is_pid_net(obj) -> bool:
    return isinstance(obj, PidNet)

Try / catch

try:
    result = invoke(context)
except TypeError as e:
    if "PidNet" in str(e):
        fix_pid_model_binding(graph)
        retry(context)
    else:
        raise

Prevention

When it happens

Trigger: model_on_device(working_mem_bytes=estimated_working_memory) for the PiD model returns a non-PidNet object — wrong model record connected to the PiD decode node, wrong submodel_type on the record, or a loader class mismatch.

Common situations: Connecting a VAE or other checkpoint into the PiD decoder input; a model record imported with an incorrect type tag; custom third-party model registered under the wrong loader class.

Related errors

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