unslothai/unsloth · error · RuntimeError

requested {backend_request} but the installer produced {new_

Error message

requested {backend_request} but the installer produced {new_backend or 'an unknown backend'}

What it means

The strongest backend check: for any explicit (non-'auto') backend_request, marker_backend(new_marker) — the backend the installed binary actually serves — must equal it. Unlike the previous check (recorded selection), this validates observed reality, catching an installer that accepted the request but shipped a binary compiled for a different backend.

Source

Thrown at studio/backend/utils/llama_cpp_update.py:691

                    "backend switch must preserve "
                    f"{repo}@{pin_release_tag}, but installer produced "
                    f"{new_repo or 'an unknown repository'}@{new_tag or 'an unknown release'}"
                )
        elif pin_release_tag and new_tag and new_repo == repo and new_tag != pin_release_tag:
            raise RuntimeError(f"pinned release {pin_release_tag} but installer produced {new_tag}")

        if backend_request is not None:
            if new_backend is None:
                raise RuntimeError(
                    f"requested {backend_request} but the installed backend is unknown"
                )
            if new_backend_request != backend_request:
                raise RuntimeError(
                    f"requested {backend_request} but the installer recorded "
                    f"{new_backend_request or 'an unknown selection'}"
                )
            if backend_request != "auto" and new_backend != backend_request:
                raise RuntimeError(
                    f"requested {backend_request} but the installer produced "
                    f"{new_backend or 'an unknown backend'}"
                )

        logger.info("llama update: success", to_tag = new_tag, backend = new_backend)
        reload_hint = " Reload your model to use it." if model_was_active else ""
        return {
            "to_tag": new_tag,
            "backend": new_backend,
            "reload_required": model_was_active,
            "message": (
                f"llama.cpp is now running on {new_backend or backend_request}.{reload_hint}"
                if backend_request is not None
                else f"Updated llama.cpp to {new_tag}.{reload_hint}"
            ),
        }
    except _flow.InstallerExit as exc:
        # Raw "installer exited 4: <log tail>" says nothing actionable in the UI.

View on GitHub (pinned to 203007d190)

Solutions

  1. Retry the update with force_refresh so cached release metadata and assets are re-fetched
  2. Re-run with backend_request='auto' to let the installer choose the artifact it can verify
  3. Check the upstream release page and confirm an asset for your requested backend and platform exists; if not, request a backend that is published
  4. Pin around a mis-published release: set pin_release_tag to the last known-good release

Example fix

# before
run_update(backend_request='vulkan')
# RuntimeError: requested vulkan but the installer produced cuda

# after
run_update(backend_request='vulkan', force_refresh=True)
# or fall back
run_update(backend_request='auto')
Defensive patterns

Strategy: fallback

Try / catch

try:
    result = run_update(backend_request=sel)
except RuntimeError as exc:
    if 'installer produced' in str(exc) and sel != 'auto':
        result = run_update(backend_request='auto')  # fall back to installer's choice
        warn_user(f"{sel} unavailable; using {result['backend']}")
    else:
        raise

Prevention

When it happens

Trigger: run_update(backend_request='cuda') where the downloaded prebuilt artifact turns out to be the Vulkan build (mis-published release assets, wrong asset picked per platform), or a 'vulkan' request yielding a CUDA-linked binary. 'auto' requests skip this check by design.

Common situations: Upstream release assets mislabeled or renamed so the platform/asset heuristic picks the wrong archive; CDN caching serving a stale artifact; a fork repo whose asset layout differs from ggml-org's.

Related errors

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