unslothai/unsloth · error · RuntimeError

The stable-diffusion.cpp server binary was replaced by an in

Error message

The stable-diffusion.cpp server binary was replaced by an install for a different accelerator while this model was loading. Try the load again.

What it means

RuntimeError raised inside the tree claim after the asset download: the sd-server binary at the same path was replaced mid-load by an install for a DIFFERENT accelerator (e.g. an H3 load pulled in the CPU fallback). A runnable-but-different build would silently generate on the wrong device while offload policy and the arbiter still describe the committed device, so the load refuses and asks for a retry that re-resolves everything.

Source

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

                            mode, server_binary, engine = "oneshot", None, self._resolve_engine()
                            # And pin off THIS engine. The one-shot pin above was taken while the
                            # mode was still "server", i.e. off an engine of None, so leaving it
                            # would compare the sd-cli just resolved against None and refuse the
                            # documented fallback on every load that reaches it. Resolved here,
                            # inside the claim, so it is vetted at the moment it is pinned.
                            engine_accelerator = _installed_accelerator_of(
                                getattr(engine, "binary", None)
                            )
                        elif _installed_accelerator_of(server_binary) != server_accelerator:
                            # Runnable, and at the same path -- and still not the build this load
                            # resolved. An install that landed during the download (an H3 load
                            # putting the CPU fallback in, say) leaves a server that starts
                            # perfectly well on a device this load has already committed elsewhere,
                            # so it would generate on the CPU while the GPU offload policy and the
                            # arbiter's accounting both describe a GPU run. Asked here, inside the
                            # claim, where no further install can start: refusing costs a retry
                            # that re-resolves device, accelerator and install from scratch.
                            raise RuntimeError(
                                "The stable-diffusion.cpp server binary was replaced by an install "
                                "for a different accelerator while this model was loading. Try the "
                                "load again."
                            )
                        else:
                            server = SdCppServer(server_binary)
                            # Published INSIDE the claim: _tree_in_use reads _pending_server, so
                            # this is the handover from "a reader holds the tree" to "a starting
                            # server does", with no gap between them.
                            #
                            # Cancellation is re-read in the SAME block. The revalidation above
                            # can sit for 20s in _server_binary_runnable, and an unload arriving
                            # in that window finds no _pending_server to stop, so without this the
                            # load would go on to spawn the process anyway and hold the device for
                            # the whole start() timeout before the commit below noticed. Asked
                            # under the lock that publishes, so an unload either stops this server
                            # or is seen here; it cannot fall between the two.
                            with self._lock:

View on GitHub (pinned to 203007d190)

Solutions

  1. Retry the load — the retry re-resolves device, accelerator and install from scratch.
  2. Serialize loads (one begin_load at a time) so installs cannot interleave.
  3. Pin the accelerator explicitly per load so concurrent loads do not flip the install target.
Defensive patterns

Strategy: retry

Try / catch

try:
    backend.begin_load(repo_id=r, gguf_filename=f)
except RuntimeError as e:
    if 'replaced by an install for a different accelerator' in str(e):
        backend.begin_load(repo_id=r, gguf_filename=f)  # retry re-resolves device+install
    else:
        raise

Prevention

When it happens

Trigger: Two loads with different accelerator targets (one GPU, one CPU/H3) racing; an auto-install landing during a multi-minute asset download replaces sd-server in place; the check _installed_accelerator_of(server_binary) != server_accelerator fires under the reader claim.

Common situations: Multi-user or automated studios issuing concurrent model loads; a fallback-to-CPU load triggered while a GPU load is mid-download.

Related errors


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