unslothai/unsloth · error · RuntimeError

The requested LoRA adapters could not be applied: baking ada

Error message

The requested LoRA adapters could not be applied: baking adapters requires the quantized (int8/fp8) transformer build, which was declined or failed on this device (see the server log), and the GGUF fallback cannot carry them. Retry without transformer_quant adapters, free VRAM, or pick a smaller model.

What it means

Raised during model load when LoRA adapters were requested alongside a transformer_quant (int8/fp8) build, that quantized build was declined or failed on the host (typically VRAM limits), and the code fell back to the GGUF pipeline. The GGUF fallback path cannot carry (bake) LoRA adapters, so rather than silently producing images without the requested adapters, the loader fails loudly. This is a deliberate fail-closed design: the render would succeed but not with the requested LoRA effects.

Source

Thrown at studio/backend/core/inference/diffusion.py:3762

                        # Drop the exception before clearing the cache: its traceback pins the dense transformer's VRAM.
                        del exc
                        # Guarded: a sticky CUDA error can raise; the fallback must reach the GGUF build.
                        try:
                            clear_gpu_cache()
                        except Exception:  # noqa: BLE001
                            pass
                if transformer_quant_engaged is not None and quant_plan is not None:
                    # The engaged dense build uses the re-planned placement; the GGUF-size plan stays for fallback.
                    plan = quant_plan

                if (
                    pipe is None
                    and kind == "gguf"
                    and normalize_transformer_quant(transformer_quant) is not None
                    and _has_active_lora(loras)
                ):
                    # Adapters were requested BAKED but that build failed, and the GGUF fallback cannot carry them; fail loudly.
                    raise RuntimeError(
                        "The requested LoRA adapters could not be applied: baking adapters "
                        "requires the quantized (int8/fp8) transformer build, which was "
                        "declined or failed on this device (see the server log), and the "
                        "GGUF fallback cannot carry them. Retry without transformer_quant "
                        "adapters, free VRAM, or pick a smaller model."
                    )

                # Fail closed on a declined EXPLICIT precision. Loading the GGUF here produced a
                # perfectly good image at a precision the caller never asked for, and nothing in
                # the response said so, which is why a successful render could not be taken as
                # proof the requested precision ran. `auto` is untouched: falling down the ladder
                # is what it asks for.
                if (
                    pipe is None
                    and transformer_quant_pinned is not None
                    and not precision_fallback_allowed()
                ):
                    raise RuntimeError(

View on GitHub (pinned to 203007d190)

Solutions

  1. Retry the load without the transformer_quant LoRA plan: drop the transformer_quant adapters from the request or set transformer_quant to a mode the host can actually build.
  2. Free VRAM (close other models/GPU processes, unload resident pipelines) so the quantized int8/fp8 transformer build succeeds and adapters can be baked into it.
  3. Pick a smaller model checkpoint whose quantized build fits, letting the LoRA bake proceed.
  4. Run the LoRA on the native engine (sd_cpp) if keeping GGUF weights is required.

Example fix

// before
await diffusion.load(model="big-gguf-repo", transformer_quant="int8", loras=[{"id":"my-lora","scale":1.0}]);
// after: host cannot build the quantized transformer, so do not request quant+baked LoRA
await diffusion.load(model="big-gguf-repo", transformer_quant=null, loras=[{"id":"my-lora","scale":1.0}]);
Defensive patterns

Strategy: fallback

Validate before calling

# Before load: probe whether the quantized transformer build is viable on this host
 capabilities = diffusion.capabilities()  # or server status endpoint
 if loras and not capabilities.get("transformer_quant_build_ok"):
     plan = {"transformer_quant": None, "loras": loras}  # skip quant+bake
 else:
     plan = {"transformer_quant": "int8", "loras": loras}

Type guard

def wants_baked_lora(req: LoadRequest) -> bool:
    """True when the request asks for adapters that must be baked into a quant build."""
    return bool(req.loras) and any(l.scale for l in req.loras) and req.transformer_quant in ("int8", "fp8")

Try / catch

try:
    await diffusion.load(model, transformer_quant="int8", loras=loras)
except RuntimeError as e:
    if "could not be applied" in str(e) and "GGUF fallback" in str(e):
        await diffusion.load(model, transformer_quant=None, loras=loras)  # dense/GGUF without bake
    else:
        raise

Prevention

When it happens

Trigger: Calling model load with both a non-empty `loras` list (with active adapters, checked via `_has_active_lora`) and `transformer_quant` set to int8/fp8, on a host where the quantized dense transformer build fails or is declined (insufficient VRAM), while the pipeline kind resolves to "gguf". The raise fires only when `pipe is None` (quant build produced no pipeline) and the GGUF fallback is the remaining path.

Common situations: Low-VRAM GPU hosts where torchao int8/fp8 quantization of the transformer OOMs during build; users combining GGUF checkpoint repos with quantized-transformer requests and LoRA stacks; drivers/compute caps that make the quantized build unavailable so the ladder falls to GGUF.

Related errors

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