invoke-ai/InvokeAI · warning · NotAMatchError

unrecognized scheduler prediction_type {prediction_type}

Error message

unrecognized scheduler prediction_type {prediction_type}

What it means

_get_scheduler_prediction_type_or_raise reads `scheduler/scheduler_config.json` and converts its `prediction_type` into the SchedulerPredictionType enum; only "v_prediction" and "epsilon" are recognized. Anything else (e.g. "sample", "heun", or a missing/renamed key) raises NotAMatchError so the config class declines the model.

Source

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

            case 2048:
                return BaseModelType.StableDiffusionXL
            case _:
                raise NotAMatchError(f"unrecognized cross_attention_dim {cross_attention_dim}")

    @classmethod
    def _get_scheduler_prediction_type_or_raise(cls, mod: ModelOnDisk) -> SchedulerPredictionType:
        scheduler_conf = get_config_dict_or_raise(mod.path / "scheduler" / "scheduler_config.json")

        # TODO(psyche): Is epsilon the right default or should we raise if it's not present?
        prediction_type = scheduler_conf.get("prediction_type", "epsilon")

        match prediction_type:
            case "v_prediction":
                return SchedulerPredictionType.VPrediction
            case "epsilon":
                return SchedulerPredictionType.Epsilon
            case _:
                raise NotAMatchError(f"unrecognized scheduler prediction_type {prediction_type}")

    @classmethod
    def _get_variant_or_raise(cls, mod: ModelOnDisk) -> ModelVariantType:
        base = cls.model_fields["base"].default
        unet_config = get_config_dict_or_raise(mod.path / "unet" / "config.json")
        in_channels = unet_config.get("in_channels")

        match in_channels:
            case 4:
                return ModelVariantType.Normal
            case 5:
                # Only SD2 has a depth variant
                assert base is BaseModelType.StableDiffusion2, f"unexpected unet in_channels 5 for base '{base}'"
                return ModelVariantType.Depth
            case 9:
                return ModelVariantType.Inpaint
            case _:
                raise NotAMatchError(f"unrecognized unet in_channels {in_channels} for base '{base}'")

View on GitHub (pinned to 0b6a024f2f)

Solutions

  1. Edit `scheduler/scheduler_config.json` and set `"prediction_type": "epsilon"` (or "v_prediction" for SD2 v-pred models) to match the upstream repo.
  2. Re-copy the scheduler folder from the official HuggingFace repo for the model.
  3. If the model genuinely isn't an SD-family model, let a different config class claim it.

Example fix

// before
scheduler/scheduler_config.json: { "prediction_type": "sample", ... }
// after
scheduler/scheduler_config.json: { "prediction_type": "epsilon", ... }
Defensive patterns

Strategy: validation

Validate before calling

import json
from pathlib import Path

conf = json.loads((Path(model_dir) / "scheduler" / "scheduler_config.json").read_text())
pt = conf.get("prediction_type")
if pt not in ("epsilon", "v_prediction"):
    conf["prediction_type"] = "epsilon"  # or v_prediction for SD2 v-pred
    (Path(model_dir) / "scheduler" / "scheduler_config.json").write_text(json.dumps(conf, indent=2))

Type guard

def has_valid_scheduler(folder: Path) -> bool:
    p = folder / "scheduler" / "scheduler_config.json"
    return p.is_file() and json.loads(p.read_text()).get("prediction_type") in ("epsilon", "v_prediction")

Try / catch

try:
    cfg = Main_Diffusers_SD1_Config.from_model_on_disk(mod)
except NotAMatchError:
    # fix scheduler_config.json prediction_type and rescan
    cfg = None

Prevention

When it happens

Trigger: from_model_on_disk on an SD-family folder whose scheduler_config.json has a prediction_type other than v_prediction/epsilon, or where the field is absent (leading to None/other value at the match statement).

Common situations: Third-party or hand-crafted diffusers exports with nonstandard scheduler configs, newer scheduler types not supported by the SD1/SD2/XL config family, or corrupted/incomplete downloads dropping the field.

Related errors


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