unslothai/unsloth · error · RuntimeError

The stable-diffusion.cpp binary was replaced by an install f

Error message

The stable-diffusion.cpp binary was replaced by an install for a different accelerator while this model was loaded. Load the model again.

What it means

The backend re-resolves the sd-cli engine before each CLI generate and compares the accelerator flavour of the currently installed binary against the accelerator the loaded model state was built for. If an install for a different accelerator (e.g. a CPU fallback replacing a CUDA build) replaced the binary since load, it refuses to run: device/offload accounting for the loaded state would be wrong (unaccounted VRAM use, or work silently dropping to CPU). The server path rejects the same mismatch before starting.

Source

Thrown at studio/backend/core/inference/sd_cpp_backend.py:2462

                with _tree_reader(getattr(engine, "binary", None), cancel):
                    # Re-resolve INSIDE the claim. An install that finished while this image was
                    # waiting can have put its sd-cli somewhere else and swept the copy resolved
                    # above, so the cached path would launch a file that is no longer there. Also
                    # covers a batch, which releases the claim between images. Cheap when nothing
                    # moved: _resolve_engine returns the cached engine whose binary still exists.
                    engine = self._resolve_engine()
                    # Existence is not identity here either. The install that moved the CLI may
                    # have been for a different accelerator (an H3 load putting the CPU fallback
                    # in, say), and this state's device and offload policy were chosen for the
                    # other one, so running it would either spend unaccounted VRAM or drop the
                    # whole generation onto the CPU while the arbiter's accounting says otherwise.
                    # The server path refuses exactly this mismatch before it starts; refusing here
                    # costs a reload, which re-resolves device, accelerator and install together.
                    if (
                        _installed_accelerator_of(getattr(engine, "binary", None))
                        != state.sd_accelerator
                    ):
                        raise RuntimeError(
                            "The stable-diffusion.cpp binary was replaced by an install for a "
                            "different accelerator while this model was loaded. Load the model "
                            "again."
                        )
                    engine.generate(
                        state.files,
                        params,
                        output_path = out_path,
                        offload = list(state.offload_flags) or None,
                        native_speed = state.native_speed,
                        threads = state.threads,
                        extra_args = extra_args or None,
                        on_log = self._on_log,
                        cancel_event = cancel,
                    )
                with Image.open(out_path) as im:
                    images.append(im.copy())
                seeds.append(seed_i)

View on GitHub (pinned to 203007d190)

Solutions

  1. Load the model again — reload re-resolves device, accelerator and install together.
  2. Avoid installing or switching accelerator builds while models are loaded; finish or unload generations first.
  3. Pin the backend/accelerator consistently so the resolver picks the same install at load and generate time.
Defensive patterns

Strategy: try-catch

Try / catch

try:
    backend.generate_cli(state, ...)
except RuntimeError as e:
    if "Load the model again" in str(e):
        state = backend.load(...)  # reload re-resolves accelerator
        backend.generate_cli(state, ...)
    raise

Prevention

When it happens

Trigger: Loading a model under one accelerator, then installing/updating stable-diffusion.cpp for a different accelerator (or letting an update swap the binary) before generating via the CLI path.

Common situations: Running `unsloth studio update` or a backend-pin change while a model is loaded; switching --backend pins (e.g. an H3 load installing the CPU fallback) between load and generate.

Related errors


AI-assisted analysis of unslothai/unsloth@203007d190 (2026-08-15). Data as JSON: /api/errors/189bb8a2f5f2d418. Report an issue: GitHub.