unslothai/unsloth · error · ValueError

{active[0]} requires an adapter method (LoRA/QLoRA or Contin

Error message

{active[0]} requires an adapter method (LoRA/QLoRA or Continued Pretraining); it has no effect under Full Finetuning.

What it means

Pydantic model validator that rejects LoRA variant flags when training_type is 'Full Finetuning'. Flags like use_rslora/use_loftq/use_dora only modify adapter training (LoRA/QLoRA or Continued Pretraining); under full finetuning there is no adapter, so the flag would be silently ignored — the model raises instead so the caller knows their config is contradictory. Note it reads training_type via getattr because model_construct() partial instances (used by single-field tests) still run this mode='after' validator.

Source

Thrown at studio/backend/models/training.py:628

        # clear error instead of a silently-ignored flag.
        active = [
            name
            for name, enabled in (
                ("use_rslora", self.use_rslora),
                ("use_loftq", self.use_loftq),
                ("use_dora", self.use_dora),
            )
            if enabled
        ]
        if len(active) > 1:
            raise ValueError(
                f"Only one LoRA variant may be enabled at a time; got {active}. "
                "use_rslora, use_loftq, and use_dora are mutually exclusive."
            )
        # getattr, not self.training_type: model_construct() (used by single-field tests) leaves
        # required fields unset, and this mode="after" validator still runs on that partial instance.
        if getattr(self, "training_type", None) == "Full Finetuning" and active:
            raise ValueError(
                f"{active[0]} requires an adapter method (LoRA/QLoRA or "
                "Continued Pretraining); it has no effect under Full Finetuning."
            )
        return self


class TrainingJobResponse(BaseModel):
    """Immediate response when training is initiated"""

    job_id: str = Field(..., description = "Unique training job identifier")
    status: Literal["pending", "queued", "error"] = Field(..., description = "Initial job status")
    message: str = Field(..., description = "Human-readable status message")
    error: Optional[str] = Field(None, description = "Error details if status is 'error'")
    error_code: Optional[str] = Field(None, description = "Stable error code if status is 'error'")


class TrainingStartRequestStatus(BaseModel):
    start_request_id: str

View on GitHub (pinned to 203007d190)

Solutions

  1. Set training_type to 'LoRA' or 'QLoRA' (or Continued Pretraining) if you want the variant flag to apply.
  2. Or remove the variant flag (set it false/omit it) if full finetuning is intended — it had no effect anyway.
  3. Sweep your config for leftover adapter flags whenever you switch training_type.

Example fix

# before
req = TrainingStartRequest(training_type="Full Finetuning", use_dora=True, ...)

# after
req = TrainingStartRequest(training_type="LoRA", use_dora=True, ...)
Defensive patterns

Strategy: validation

Validate before calling

LORA_VARIANT_FLAGS = ("use_rslora", "use_loftq", "use_dora")

def variant_flags_consistent(payload: dict) -> bool:
    if payload.get("training_type") == "Full Finetuning":
        return not any(payload.get(f) for f in LORA_VARIANT_FLAGS)
    return True

Prevention

When it happens

Trigger: POSTing a TrainingStartRequest with training_type='Full Finetuning' and any of use_rslora/use_loftq/use_dora true; e.g. a config flipped from LoRA to full finetuning without removing adapter flags.

Common situations: Reusing a LoRA recipe config but changing only training_type; YAML defaults that set a variant flag globally; experimenting with DoRA then switching to full finetuning for comparison.

Related errors


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