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

The PiD decode invocation loads the PiD decoder network via model_on_device() and asserts the returned object is an instance of PidNet. Any other type (wrong model registered under the key, wrapper, or corrupted load) raises TypeError. This guarantees the decoder exposes the PidNet API (parameters, forward) used downstream.

Source

Thrown at invokeai/app/invocations/flux_pid_decode.py:142

        # 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()

        # 2) 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.Flux,
            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

            # FLUX latent is stored in normalised form (matching FluxAutoEncoder
            # state); denormalise so PiD sees the same representation it
            # consumed during training.
            ae = get_flux_ae_params()
            denorm_latent = latents.to(device=device, dtype=dtype) / ae.scale_factor + ae.shift_factor
            caption_embs = caption_embs.to(device=device, dtype=dtype)

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

View on GitHub (pinned to 0b6a024f2f)

Solutions

  1. Select the correct PiD decoder model record for the node's pid field
  2. Reinstall/redownload the PiD decoder model if its record resolves to the wrong class
  3. Verify the model's configured model type in the Model Manager matches PidNet
  4. Print/inspect type(pid_net) to identify what object is actually being returned

Example fix

// before: standard VAE selected as decoder
pid_model=<flux_vae_autoencoderkl_key>
// after
pid_model=<pidnet_decoder_model_key>
Defensive patterns

Strategy: type-guard

Validate before calling

pid_info = context.models.load(pid_model)
# confirm the record's model type is the PiD decoder, not a standard VAE

Type guard

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

Try / catch

try:
    output = pid_decode.invoke(context)
except TypeError as e:
    if 'Expected PidNet' in str(e):
        # select the actual PiD decoder model record
        pass
    else:
        raise

Prevention

When it happens

Trigger: invoke() enters pid_info.model_on_device(working_mem_bytes=estimated_working_memory) and the yielded pid_net is not a PidNet instance — e.g., the selected VAE/decoder key resolves to a standard AutoencoderKL instead of the PiD network.

Common situations: Selecting a standard FLUX VAE where a PiD decoder model is expected; a model manager record with wrong model class; partial install of the PiD decoder model.

Related errors


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