invoke-ai/InvokeAI · info · NotAMatchError

transformer is SDNQ-quantized; use Main_SDNQ_Diffusers_FLUX_

Error message

transformer is SDNQ-quantized; use Main_SDNQ_Diffusers_FLUX_Config

What it means

During model identification, Main_Diffusers_FLUX_Config.from_model_on_disk inspects the pipeline folder and raises NotAMatchError when the `transformer/` subfolder contains SDNQ-quantized weights. The plain diffusers FLUX config cannot load packed quantized weights correctly, so the folder must be classified by the dedicated Main_SDNQ_Diffusers_FLUX_Config instead. This is a deliberate guard that makes identification fall through to the correct config class rather than mis-registering the model.

Source

Thrown at invokeai/backend/model_manager/configs/main.py:954

    @classmethod
    def from_model_on_disk(cls, mod: ModelOnDisk, override_fields: dict[str, Any]) -> Self:
        raise_if_not_dir(mod)

        raise_for_override_fields(cls, override_fields)

        # Check for FLUX-specific pipeline or transformer class names
        raise_for_class_name(
            common_config_paths(mod.path),
            {
                "FluxPipeline",
                "FluxFillPipeline",
                "FluxTransformer2DModel",
            },
        )

        # Reject SDNQ-quantized pipelines so Main_SDNQ_Diffusers_FLUX_Config matches instead.
        if (mod.path / "transformer").is_dir() and _is_sdnq_folder(mod.path / "transformer"):
            raise NotAMatchError("transformer is SDNQ-quantized; use Main_SDNQ_Diffusers_FLUX_Config")

        variant = override_fields.pop("variant", None) or cls._get_variant_or_raise(mod)

        repo_variant = override_fields.pop("repo_variant", None) or cls._get_repo_variant_or_raise(mod)

        return cls(
            **override_fields,
            variant=variant,
            repo_variant=repo_variant,
        )

    @classmethod
    def _get_variant_or_raise(cls, mod: ModelOnDisk) -> FluxVariantType:
        """Determine the FLUX variant from the transformer config.

        FLUX variants are distinguished by:
        - in_channels: 64 for Dev/Schnell, 384 for DevFill
        - guidance_embeds: True for Dev, False for Schnell

View on GitHub (pinned to 0b6a024f2f)

Solutions

  1. Take no corrective action on your folder: this error is an internal control signal that makes the SDNQ config claim the model.
  2. If you actually wanted non-quantized FLUX, re-download the original bf16/safetensors weights without SDNQ quantization.
  3. If the model fails to register at all, verify the `transformer/` subfolder is a genuine SDNQ folder and that Main_SDNQ_Diffusers_FLUX_Config is present/registered in your InvokeAI version.
Defensive patterns

Strategy: validation

Validate before calling

from pathlib import Path

def is_sdnq_flux_pipeline(folder: Path) -> bool:
    t = folder / "transformer"
    return t.is_dir() and ((t / "quantization_config.json").exists() or any(t.glob("*.sdnq")))

if is_sdnq_flux_pipeline(Path(model_dir)):
    expect_config = "Main_SDNQ_Diffusers_FLUX_Config"  # not Main_Diffusers_FLUX_Config

Type guard

def is_sdnq_transformer(folder: Path) -> bool:
    return folder.is_dir() and (folder / "quantization_config.json").is_file()

Try / catch

from invokeai.backend.model_manager.configs.main import NotAMatchError
try:
    cfg = Main_Diffusers_FLUX_Config.from_model_on_disk(mod)
except NotAMatchError:
    cfg = Main_SDNQ_Diffusers_FLUX_Config.from_model_on_disk(mod)

Prevention

When it happens

Trigger: Registering/identifying a FLUX.1 diffusers pipeline where `mod.path/transformer` is a directory and `_is_sdnq_folder()` detects SDNQ quantization (e.g. quantization_config.json / packed uint8 weights) inside it, via ModelManager install/scan APIs that call from_model_on_disk.

Common situations: Downloading an SDNQ-quantized FLUX checkpoint from HuggingFace into a full pipeline folder and letting InvokeAI auto-identify it; the error is internal to identification, so users typically only see the model correctly classified as SDNQ afterward.

Related errors


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