Your adapter, against the reference recipe
LoRA DeskCheck a LoRA or QLoRA training config before it burns a GPU-day.
Paste the config. Free in your browser, every adapter and trainer knob is read with the line it sits on and checked against LoRA Without Regret - all-linear targets, lora_alpha = 2 x r, rank by task, LoRA learning rates, an effective batch under 32, bf16 never fp16 - along with the current TRL API and Unsloth's known traps. You also get the adapter's size and a memory floor for your GPU. A run then reviews it knob by knob, or rewrites it.
1 Your config free
2 The numbers free
Knob by knob
Paste a config above.
What the recipe flags
3 Review or rewrite metered
Pricing as soon as the session is ready...
Sign inThe reply could not be read. Here it is as it came back:
Knob by knob
Failure modes to expect
Already right
The rewritten config
What changed
Line by line
Not settled by the config
The rewrite, scanned again
The page's check of this reply
4 Saved configs
How it works
The page reads the paste as text and never runs it. It finds keyword arguments, assignments, YAML and JSON keys and command-line flags under every name a knob goes by (lora_r or r, micro_batch_size or per_device_train_batch_size, sequence_len or max_length), follows a variable back to its value, ignores commented-out lines, and notes the line and call each value sits in - so SFTTrainer(tokenizer=...) and max_seq_length on SFTConfig are caught as the old TRL API.
The rules are the source skill's: all-linear targets with the MLP layers mattering most; lora_alpha = 2 x r; rank 16-32 for general SFT, up to about 256 at scale, 1-32 for RL adapters; learning rate 2e-4 for QLoRA, 1e-4 conservative, 5e-5 very conservative, about 10x a full fine-tune; an effective batch (per-device x accumulation x GPUs) under 32; bf16 on BF16 hardware and never fp16; rsLoRA only at r of 32 and up; LoRA first, QLoRA when memory forces it.
Adapter size is r x (inputs + outputs) for every targeted projection in every layer, from the model's published shape. The memory floor adds the frozen base (2 bytes a weight in bf16, about 4.1 bits in NF4 with the embeddings left in bf16), the adapter in fp32 with its gradients and Adam state, and 1 GB of CUDA context. Activations come on top and grow with batch and sequence length, so a config at the floor will not train - the floor tells you when one certainly cannot.