Choosing an adaptation method by the constraint you face

“Should I use SFT or LoRA?” combines two different decisions. One describes what training rewards; the other describes which updates can be learned. Separate these axes before comparing methods.

Before you begin: You understand full fine-tuning, LoRA, QLoRA, and the role of training examples.

Those are separate decisions. Supervised fine-tuning describes a training objective and data format. LoRA describes a parameterization of updates. QLoRA adds a way to store the frozen base compactly. You can combine a supervised objective with LoRA or QLoRA.

Compare methods on the right axis

Continuous prompt tuning learns vectors; it is not the same as editing a text prompt. Prefix-tuning variants inject learned representations into the model in specific ways. They can have deployment implications that differ from an adapter that can be merged into a linear weight.

Preference methods such as DPO are not interchangeable alternatives to LoRA on a single axis. A preference objective can train a full model or an adapter. Record both the objective and the trainable parameter set.

Build a two-axis experiment table

Draw rows for a supervised objective and a preference objective. Draw columns for full parameter updates and LoRA updates. Each cell describes a possible combination, provided the trainer supports it. QLoRA adds another storage choice for the frozen base; it does not replace the need to choose an objective.

Suppose supervised LoRA improves extraction, while preference optimization on a full model improves writing style. Can you attribute the difference to LoRA versus full fine-tuning?

Add a column for the observed limiting resource: reviewed examples, weight memory, activation memory, training time, or serving complexity. The table should make your next experiment easier to justify, not merely list every available method.

Start with the limiting resource

If optimizer state dominates memory, training fewer parameters may help substantially. If frozen weights dominate, compact storage or a smaller model may be necessary. If long sequences dominate, activation checkpointing or sequence handling may matter more than adapter rank.

If the bottleneck is reviewed data, a more complex optimizer will not manufacture trustworthy targets. A small clean dataset with representative hard cases may teach the intended behavior more reliably than a much larger set of unverified outputs.

Serving constraints also count. Many small task adapters may be easier to store than many full model copies. Switching adapters can complicate batching and cache handling. Merged adapters can simplify some serving paths but lose the same convenient switching behavior.

Design a fair comparison

Hold the base revision, training data, evaluation cases, and deployment prompt constant where possible. Allocate a reasonable tuning budget to each method. Record peak memory, training time, task quality, and regressions.

A comparison where one method receives much more tuning is still an experiment, but it does not isolate the method alone. Report the difference rather than presenting the winner as universal.

Make an experiment table before launching runs. Include the hypothesis for each change. For example: “Broader adapter targets may improve field extraction because attention-only updates plateaued on the same validation cases.” This is more informative than trying ranks at random and selecting the nicest chart.

Choose for a concrete task

Exercise: you need ten writing-style variants of one model. Each uses a small reviewed dataset, and the base weights already fit in serving memory. What is a sensible first comparison?

The next lesson focuses on the demonstrations themselves, which often matter more than the method label.

Sources

See LoRA, QLoRA, and Prefix-Tuning for distinct mechanisms. The PEFT documentation describes supported implementations.

Continue: Instruction Tuning.