invoke-ai/InvokeAI · error · NotAMatchError

model does not look like a Z-Image LoRA

Error message

model does not look like a Z-Image LoRA

What it means

NotAMatchError raised by LoRA_LyCORIS_ZImage_Config._get_base_or_raise when the state dict passes the LoRA-ness check but contains none of the Z-Image transformer-layer key prefixes (diffusion_model.layers., diffusion_model.context_refiner., diffusion_model.noise_refiner., transformer.layers., base_model.model.transformer.layers.) and is not a Kohya-format Z-Image LoRA. Base-model inference cannot conclude the model targets Z-Image's S3-DiT architecture.

Source

Thrown at invokeai/backend/model_manager/configs/lora.py:801

        # Check for Z-Image transformer layer patterns (dot-notation formats)
        # Z-Image uses diffusion_model.layers.X structure (unlike Flux which uses double_blocks/single_blocks)
        has_z_image_keys = state_dict_has_any_keys_starting_with(
            state_dict,
            {
                "diffusion_model.layers.",  # Z-Image S3-DiT layer pattern
                "diffusion_model.context_refiner.",
                "diffusion_model.noise_refiner.",
                "transformer.layers.",  # OneTrainer/diffusers prefix variant
                "base_model.model.transformer.layers.",  # PEFT-wrapped variant
            },
        )

        # If it looks like a Z-Image LoRA, return ZImage base
        if has_z_image_keys:
            return BaseModelType.ZImage

        raise NotAMatchError("model does not look like a Z-Image LoRA")


class LoRA_LyCORIS_QwenImage_Config(LoRA_LyCORIS_Config_Base, Config_Base):
    """Model config for Qwen Image Edit LoRA models in LyCORIS format."""

    base: Literal[BaseModelType.QwenImage] = Field(default=BaseModelType.QwenImage)

    @classmethod
    def _validate_looks_like_lora(cls, mod: ModelOnDisk) -> None:
        """Qwen Image Edit LoRAs have keys like transformer_blocks.X.attn.to_k.lora_down.weight."""
        state_dict = mod.load_state_dict()

        has_qwen_ie_keys = state_dict_has_any_keys_starting_with(
            state_dict,
            {
                "transformer_blocks.",
                "transformer.transformer_blocks.",
                "lora_unet_transformer_blocks_",  # Kohya format

View on GitHub (pinned to 0b6a024f2f)

Solutions

1. Check whether the model was successfully matched by another config class afterwards — this error frequently occurs during normal multi-config probing and is not fatal.
2. Verify the download is actually a Z-Image LoRA (mislabeled files on model sites are common); compare keys against Z-Image S3-DiT naming.
3. Update InvokeAI for broader trainer-format recognition.
4. Re-export the LoRA with standard Kohya or PEFT Z-Image key naming.
5. Install with an explicit base override (base=ZImage) to skip detection.

Example fix

// before: relying on auto-detection of a mislabeled file
# NotAMatchError: model does not look like a Z-Image LoRA
// after: confirm keys then install with explicit base
assert any(k.startswith("diffusion_model.layers.") for k in sd)
installer.install(path, config={"base": BaseModelType.ZImage})

sd = load_file("model.safetensors")
prefixes = ("diffusion_model.layers.", "diffusion_model.context_refiner.",
            "diffusion_model.noise_refiner.", "transformer.layers.",
            "base_model.model.transformer.layers.")
if not any(k.startswith(prefixes) for k in sd):
    print("No Z-Image S3-DiT keys; this file cannot match LoRA_LyCORIS_ZImage_Config")

def has_z_image_base_keys(state_dict: dict) -> bool:
    prefixes = ("diffusion_model.layers.", "diffusion_model.context_refiner.",
                "diffusion_model.noise_refiner.", "transformer.layers.",
                "base_model.model.transformer.layers.")
    return any(isinstance(k, str) and k.startswith(prefixes) for k in state_dict)

try:
    base = LoRA_LyCORIS_ZImage_Config._get_base_or_raise(mod)
except NotAMatchError:
    base = None  # let the model-probe service continue matching other config classes

When it happens

Trigger: _validate_base -> _get_base_or_raise runs after _validate_looks_like_lora passes; the file is a LoRA but for a different architecture (its keys don't start with any Z-Image prefix), so the Z-Image config refuses to claim it.

Common situations: A Flux or Qwen-Image LoRA being probed against the Z-Image config (failed candidate match — usually benign if another config later claims it), a Z-Image LoRA using an unlisted trainer's naming scheme, or a file mislabeled as Z-Image on a model-sharing site.

Related errors

• unrecognized token vector length {token_vector_length}
• model does not match Z-Image LoRA heuristics
• LoRA "{lora_key}" already applied to transformer.
• LoRA "{lora_key}" already applied to Qwen3 encoder.
• Unknown lora: {lora.lora.key}!

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