The short answer, for a 7B-class model at today's rental rates: a LoRA (or QLoRA) run costs on the order of tens of dollars — one GPU, one to six hours — while full fine-tuning costs hundreds to low thousands — a small multi-GPU cluster running for a day or more. That's one to two orders of magnitude, and on most tasks the two produce quality that ties.

That's the decision for almost everyone: start with LoRA. The rest of this piece is why the numbers look like that, so you can size your own run instead of trusting a vendor's table — and know the one case where the expensive option earns its price.

Where the cost actually comes from#

Fine-tuning cost is a memory story wearing a dollar sign. Full fine-tuning updates every weight, and with mixed precision and the Adam optimizer each parameter drags along roughly 16 bytes: a 2-byte weight, a 2-byte gradient, and about 12 bytes of FP32 optimizer state. For a 7B model that's ~100GB+ before activations — past any single GPU, so you rent a cluster and pay for the interconnect and the idle time too.

LoRA changes the bill by freezing the base model and training only a small low-rank adapter beside it. You still hold the frozen weights in memory, but there are no gradients and no optimizer state for them — only for the tiny adapter. A 7B lands around 16–23GB (one card); QLoRA quantizes the frozen base to 4-bit and drops it to ~6–12GB. A peer-reviewed survey of LoRA methods measured exactly this shape: about 23GB vs 60GB for a 7B on a single 24GB GPU, and LoRA training roughly 1.9x faster. Fewer GPUs, smaller GPUs, fewer hours — that is the whole saving, and it compounds.

You are not paying for a better algorithm. You are paying to avoid storing a gradient and an optimizer state for seven billion frozen weights.

It compounds upward with model size. For a 70B model, a LoRA at rank 64 fits in roughly 159GB (two H100s), while full fine-tuning with FSDP/ZeRO-3 is estimated near 860GB — eight to sixteen H100s. The bigger the model, the more absurd the full-fine-tuning premium becomes. (For the full memory math, including the exact bytes-per-parameter breakdown, see our companion piece on LoRA vs QLoRA vs full fine-tuning.)

Putting a real price on it#

Translate memory into money at November 2026 GPU rental rates, where a reliable on-demand H100 runs about $2/GPU-hour and an A100 about $1–1.50.

The ratio — roughly 100x at the low end — is the number to carry into a budget meeting. And note what's not on either line: if your duty cycle is low, you may not want to rent a GPU at all; we work that break-even in rent a GPU or call an API.

The one time to pay for full fine-tuning#

Cheaper is the default, not a law. LoRA can genuinely underperform full fine-tuning on hard target domains — the Biderman et al. result, LoRA Learns Less and Forgets Less, found the gap opens on demanding code and math, where full fine-tuning learns higher-rank weight changes than a small adapter can represent. So pay the premium when a well-tuned LoRA still isn't good enough on exactly that kind of task, when you're reshaping the model's behavior broadly rather than bolting on a narrow skill, or when you'll serve one dedicated model at enough volume to want the change baked into the base weights.

The word doing the work is well-tuned. Before you authorize a four-figure run, exhaust the cheap levers: raise the LoRA rank, tune the learning rate, and target all modules, not just attention. Those moves close most of the quality gap for a few more dollars — and they're the reason most teams who think they need full fine-tuning don't.

And the cheapest fine-tune is the one you don't run: if what you actually need is for the model to know something rather than behave a certain way, retrieval beats fine-tuning on cost, freshness, and accuracy. Spend the training budget only after you've confirmed training is the right tool.