unslothai/unsloth · error · ValueError

LoRA is not supported for {state.family.name} on the native

Error message

LoRA is not supported for {state.family.name} on the native sd.cpp engine.

What it means

ValueError: LoRA conditioning was requested (after weight-0 rows were dropped, so at least one active LoRA remains) but diffusion_lora.supports_lora reports no LoRA support for this family on the sd_cpp engine with gguf model kind. Zero-weight LoRAs are deliberately ignored before this gate so disable-only requests stay no-ops.

Source

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

                # Publish an active (step 0) state before the slow pre-generate setup so a reload probe does not read idle while this holds _generate_lock.
                self._gen = _SdGen(total_steps = int(steps))
            try:
                if seed is None:
                    seed = int.from_bytes(os.urandom(6), "big") & ((1 << 53) - 1)
                else:
                    seed = int(seed)
                cfg_scale, flux_guidance = _map_guidance(state.family, guidance)
                # Resolve selected LoRAs up front (a bad id gives a clear 400). Drop weight-0 rows BEFORE the support gate so an only-disabled request stays a no-op.
                lora_resolved: list = []
                active_loras = [(i, w) for (i, w) in (loras or []) if w != 0]
                if active_loras:
                    if not diffusion_lora.supports_lora(
                        engine = "sd_cpp",
                        family = state.family.name,
                        model_kind = "gguf",
                        transformer_quant = None,
                    ):
                        raise ValueError(
                            f"LoRA is not supported for {state.family.name} on the native "
                            "sd.cpp engine."
                        )
                    lora_resolved = diffusion_lora.resolve_specs(
                        active_loras,
                        family = state.family.name,
                        hf_token = state.hf_token,
                        cancel_event = cancel,
                    )
                if state.mode == "server" and state.server is not None:
                    images, seeds = self._generate_server(
                        state,
                        prompt = prompt,
                        negative_prompt = negative_prompt,
                        width = width,
                        height = height,
                        steps = steps,
                        seed = seed,

View on GitHub (pinned to 203007d190)

Solutions

Remove the LoRAs (or set all weights to 0) for native generation on that family.
Run LoRA workflows on the diffusers engine/GPU where the family is supported.
Check the family's LoRA support matrix before building UI options for the native engine.

Example fix

# before
backend.generate(prompt='a cat', loras=[('my-lora-id', 0.7)])

# after
backend.generate(prompt='a cat', loras=[('my-lora-id', 0)])  # disabled; or use diffusers engine

Defensive patterns

Strategy: validation

Validate before calling

from core.inference import diffusion_lora

active = [(i, w) for i, w in (loras or []) if w != 0]
if active and not diffusion_lora.supports_lora(engine='sd_cpp', family=family_name, model_kind='gguf', transformer_quant=None):
    loras = []  # drop unsupported LoRAs, or switch engine

Prevention

Query supports_lora before exposing LoRA controls for a family on the native engine.
Strip zero-weight LoRA rows client-side; the engine ignores them but explicit is clearer.

When it happens

Trigger: generate() with loras=[(id, weight)] where weight != 0, on a family without sd.cpp LoRA support.

Common situations: Recipes recorded on a diffusers host (with LoRAs) replayed on a native sd.cpp host; UI carrying over a default LoRA selection when the engine switches.

Related errors

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