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: strView on GitHub (pinned to 203007d190)
Solutions
- Set training_type to 'LoRA' or 'QLoRA' (or Continued Pretraining) if you want the variant flag to apply.
- Or remove the variant flag (set it false/omit it) if full finetuning is intended — it had no effect anyway.
- 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 switching training_type, diff the config and strip adapter-specific flags.
- Add a config schema in your repo that forbids variant flags under Full Finetuning.
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
- Only one LoRA variant may be enabled at a time; got {active}
- duplicate LoRA id '{spec.id}'; list each adapter at most onc
- GGUF LoRA adapters are not supported on the diffusers engine
- LoRA is not supported for {state.family.name} on the native
- gradient_accumulation_steps must be >= 1
AI-assisted analysis of unslothai/unsloth@203007d190 (2026-08-15).
Data as JSON: /api/errors/4ee7edd4fedf6745.
Report an issue: GitHub.