Choosing Between Fine-Tuning Approaches: LoRA, QLoRA, and Full

If You Remember Nothing Else

For roughly 95% of production fine-tuning projects, the right approach is LoRA. It costs about 1% of what full fine-tuning costs, runs in hours instead of days, and produces models with comparable quality on real production tasks. QLoRA is the same idea plus a memory trick for fitting large models on a single GPU. Full fine-tuning is the exception that needs documented evidence, not the default.

If you're approving a budget request and the proposal calls for full fine-tuning, your first question is "what specific quality limit did LoRA hit?" If your team can't answer that with a benchmark number, the proposal isn't ready to approve.

Recommendations by Situation

What's right for your project depends on your specific shape. Find the row that matches you.

Worked Examples

Example 1: Customer support copilot for a fintech (5,000 labeled tickets)

A mid-stage fintech wants to build an internal copilot for their support team. They have 5,000 historical tickets with high-quality agent responses. Privacy rules mean the model has to run on their infrastructure.

The right approach: LoRA on Llama 3.1 8B. Total project budget: about $300 in compute (running 30 experiments at $5 to $15 each). Timeline: 3 weeks from dataset preparation to first production-quality model.

What they nearly got wrong: their first proposal called for full fine-tuning on a 70B model "for the best possible quality." That would have been $25,000 in compute, a multi-GPU cluster they didn't have, and a model too large for their inference setup. The smaller 8B model was sufficient because the task is narrow (support ticket responses, not open-ended writing).

What to remember: when the task is narrow and the dataset is moderate, the smaller model with LoRA is almost always the right call.

Example 2: Domain expert assistant for a legal team (15,000 examples)

An enterprise legal team wants an AI assistant that handles 12 distinct practice areas (contract review, IP, employment, and so on). Each area has different terminology and rules.

The right approach: LoRA on Llama 3.1 70B (with QLoRA so it fits on a single H100), with separate LoRA adapters for each practice area. Inference uses the same base model but loads the appropriate adapter per query. Total budget: about $1,200 in compute. Timeline: 6 weeks.

Why QLoRA: the base model needs to be 70B because legal reasoning is harder than support replies. QLoRA lets the team fit it on a single GPU instead of needing a multi-GPU cluster, which their cloud budget didn't support.

Why separate adapters: 12 fully fine-tuned 70B models would have been 12x the storage and 12x the GPU memory at inference. Separate LoRA adapters are tiny (about 50MB each) and swap in milliseconds. The architectural savings are larger than the training savings.

What to remember: when you have multiple variants of the same task, LoRA's small adapter files unlock multi-tenant economics that full fine-tuning can't match.

Example 3: Internal copilot replacement for a proprietary system (50,000 examples, multi-language)

A logistics company has been using a frontier API for an internal copilot. Costs hit $80,000 per month at scale. They have 50,000 high-quality examples of past usage and want to bring this in-house.

The right approach: QLoRA on Qwen 2.5 32B (the workload is multilingual, including Mandarin). Total fine-tuning budget: about $4,000 in compute. Timeline: 8 weeks including evaluation and rollout. Self-hosted inference on a 2x A100 instance: about $4,500 per month. Net savings: about $75,000 per month.

Why this is more involved: a real production migration from a frontier API to a self-hosted model has to validate quality at parity, build the inference and serving infrastructure, plan rollback, and run a phased rollout. The fine-tuning is maybe 30% of the project.

What to remember: at scale, fine-tuning + self-hosting beats frontier APIs decisively on cost. The fine-tuning approach itself (LoRA, QLoRA) is rarely the hard part; the operational work around it is.

Anti-Patterns to Watch For

When you're reviewing a fine-tuning proposal, these are the specific patterns that should make you push back.

"We'll do full fine-tuning to get the best quality"

What it looks like: a proposal that defaults to full fine-tuning without comparing against LoRA. Often paired with high compute budgets and multi-GPU cluster requirements.

Why it's wrong: 95% of production tasks see no measurable quality difference between LoRA and full fine-tuning. The team is guessing, not measuring.

How to redirect: ask for a 1-day comparison. Run a small LoRA fine-tune on a sample of the data, evaluate against the same target. If LoRA hits the quality bar, the project ships at 1% of the cost. If it doesn't, the team has the evidence they need.

"We need GPUs because we're doing fine-tuning"

What it looks like: requests for multi-GPU clusters or H100 instances for projects on small models with small datasets.

Why it's wrong: most fine-tuning workloads at LoRA economics fit on a single A100 or even a consumer GPU. The team is sizing infrastructure for full fine-tuning when LoRA is the actual approach.

How to redirect: ask "what's the actual GPU memory needed for a LoRA run on this model?" The answer for a 7B model is usually 24GB or less. A 70B model with QLoRA fits on a single 80GB GPU. Multi-GPU is rarely necessary below 70B.

"We'll experiment with hyperparameters"

What it looks like: vague iteration plans with no defined experiment count or per-experiment cost.

Why it's wrong: hyperparameter tuning is a real activity but it should be bounded. Without a budget, "experimenting" can consume 100+ runs without converging.

How to redirect: ask the team to commit to a number of experiments (typically 10 to 30) and a per-experiment cost. This forces explicit thinking about which hyperparameters matter and which don't.

"Let's start with full fine-tuning, fall back to LoRA if it's too expensive"

What it looks like: ambitious-sounding plans that frame full fine-tuning as the primary path.

Why it's wrong: the order is backwards. LoRA should be the primary path; full fine-tuning is the fallback if LoRA's quality is genuinely insufficient (which is rare).

How to redirect: invert the framing. "Let's start with LoRA. We'll only consider full fine-tuning if a measured benchmark on the test set shows LoRA falls short by more than X points."

"We'll skip the validation set"

What it looks like: project plans that don't carve out a clear test set, or plans that retrain on the test set after results come in.

Why it's wrong: without a held-out test set the team can never tell if the model actually improved. Reported quality numbers will mislead you.

How to redirect: insist on a locked test set carved out before training starts. The test set never moves; the team can never train on it. Reported quality always comes from this locked set.

When NOT to Fine-Tune at All

A meaningful fraction of "we should fine-tune" proposals are wrong. The honest answer for some workloads is don't fine-tune. Specific situations:

• Your data updates frequently and the model needs current knowledge. Fine-tuning bakes in training-time facts. Use RAG (retrieval) instead so the model can reference current data.
• You have under 500 high-quality examples. Fine-tuning needs more than this; the model overfits or fails to generalize. Stronger prompts on a frontier API typically beat a weak fine-tune.
• The task is open-ended generation (long-form writing, creative tasks). Fine-tuning works less well here than on narrow tasks.
• The team doesn't have evaluation infrastructure in place. Fine-tuning without measurement is wishful thinking; build the eval first.
• Your unit economics depend on the cost-per-token of frontier APIs being too high. Fine-tuning + self-hosting only pays back at sustained high volume; below 10M tokens per day, the savings rarely justify the engineering investment.

If any of these apply, the right move is RAG, prompt engineering, a stronger base model, or simply not building this feature yet. A "no, fine-tuning isn't the right tool here" answer can save a project from a costly detour.

What to Ask Your Engineering Team

The short list of questions for the architecture review:

1. Why are you proposing full fine-tuning instead of LoRA? If the answer is "it's the standard approach" or "for best quality," push back; both are weak answers.
2. What's our model size and dataset size? Below 30B parameters and below 500K examples, LoRA is almost certainly the right call.
3. How many training experiments do you expect to run? Multiply by per-experiment cost to get the real project budget.
4. How will we validate that the chosen approach is good enough before scaling? A small benchmark in week 1 saves weeks of misdirection.
5. What's the deployment story? If multi-tenant or multiple variants, keeping LoRA adapters separate dramatically simplifies the architecture.
6. What's the fallback plan if quality is weaker than expected? "More compute" is rarely the answer; usually the dataset needs work.
7. Have we built the evaluation harness yet? If not, fine-tuning is premature.

Cost & Timeline Quick Reference

Realistic ranges for the most common project shapes:

The Bottom Line

LoRA is the right call for the large majority of production fine-tuning projects. QLoRA when memory is the binding constraint. Full fine-tuning only when there's documented benchmark evidence that the additional cost earns its keep, which is rare.

If your team's proposal calls for anything other than this, the burden is on them to explain why. "Best quality" and "industry standard" aren't reasons; they're hand-waves. Specific benchmark gaps, measured on a representative test set, are the only justification that should clear the budget.