Is Fine-Tuning LLMs Worth It in 2026? Prices, LoRA, RFT and OpenAI's Exit

I get asked about fine-tuning roughly once a week, usually by someone who has a prompt that is 4,000 tokens long and growing, and a vague feeling that training a model is what serious teams do. Most of the time my answer is "not yet". This year the question got more interesting, because OpenAI announced it is closing its self-serve fine-tuning platform, while Google and AWS went the other way and added reinforcement fine-tuning to their managed services, and the open-weight tooling got good enough that a LoRA run on a single rented GPU is an afternoon's work. This post explains when fine-tuning an LLM actually beats prompting and RAG in 2026, what LoRA, QLoRA and reinforcement fine-tuning (RFT) are and what the research says about them, what each provider charges, and how to evaluate a fine-tune before it goes anywhere near production.

What changed for fine-tuning in 2026?

The biggest change is a withdrawal. OpenAI's deprecations page lists a staged wind-down of self-serve fine-tuning: from 7 May 2026, organisations that had never run a fine-tuning job could no longer start one; from 2 July 2026, organisations that had not run inference on a fine-tuned model in the previous 60 days lost the ability to create jobs; and on 6 January 2027, active existing customers lose it too. Fine-tuned models keep serving "until the base models are deprecated", and the same page puts o4-mini-2025-04-16, the only model OpenAI offered for reinforcement fine-tuning, and gpt-4.1-nano at a shutdown date of 23 October 2026, three days after this post. gpt-4.1, gpt-4.1-mini and gpt-4o-mini follow on 14 January 2027. The pricing page now opens its fine-tuning section with "OpenAI is winding down the fine-tuning platform."

Anthropic's only public fine-tuning path was Claude 3 Haiku on Amazon Bedrock. AWS's own walkthrough now carries the note that Claude 3 Haiku reached end of life on 10 September 2026. I could not find an announced successor for newer Claude models.

Meanwhile the clouds expanded. AWS launched reinforcement fine-tuning in Bedrock on 3 December 2025 for Nova 2 Lite, claiming "66% accuracy gains on average over base models" without saying on which tasks, then extended it in February 2026 to open-weight gpt-oss-20b and qwen3-32b behind OpenAI-compatible APIs. Google's Vertex AI pricing page lists supervised tuning for Gemini 2.5 Pro, 2.5 Flash, 2.5 Flash-Lite, 3.1 Flash Lite and 3.5 Flash Lite, and both supervised and reinforcement learning tuning for Gemini 3.5 Flash. Thinking Machines' Tinker sells LoRA training on open-weight models as a metered API.

The lesson I take from OpenAI's exit is operational rather than technical. A fine-tune on a closed model is a dependency on two things you do not control: the tuning service and the base model's lifetime. When either goes, your weights go with it.

When does fine-tuning beat prompting and RAG?

The short version: fine-tuning changes behaviour, retrieval supplies facts. If the model does not know something, put it in the context. If the model knows enough but does the job inconsistently, too verbosely, in the wrong format, or needs a 4,000-token prompt to get it right, that is where training starts to pay.

The best-known evidence on the knowledge side is Ovadia et al., Fine-Tuning or Retrieval?, which compared unsupervised fine-tuning with RAG for injecting knowledge and found RAG did better on both previously seen and entirely new facts, and that models struggle to learn new facts through fine-tuning unless they see many paraphrases of the same fact. That matches what most teams discover the expensive way. If your problem is "the model doesn't know our product catalogue", train nothing and read the sibling comparison in RAG vs long context vs fine-tuning.

On the behaviour side, the evidence is strong for narrow tasks. Predibase's LoRA Land trained 310 adapters (10 base models across 31 tasks) and reported that 4-bit LoRA fine-tunes beat their base models by 34 points on average and GPT-4 by 10 points. Those were classification, extraction and similar structured tasks, and GPT-4 was prompted, not tuned, so read it as "a small specialised model can beat a big generalist on a narrow job", not as a general ranking.

Here is the checklist I use before agreeing to a fine-tuning project:

Signal	Points to	Why
Model lacks facts, or facts change weekly	RAG	Fine-tuning learns new facts poorly (Ovadia et al.)
Output format or tone is inconsistent despite examples in the prompt	Fine-tune (SFT)	Behaviour is what supervised training changes best
Prompt is thousands of tokens of instructions repeated on every call	Fine-tune	Google lists "lower inference latency and cost due to shorter prompts" as a tuning benefit (Vertex pricing)
Narrow, high-volume task (classify, extract, route)	Fine-tune a small model	4-bit LoRA beat base models by 34 points on 31 tasks (LoRA Land)
Answers can be checked by a program (tests pass, JSON validates, maths is right)	RFT	Graders replace labelled examples (AWS)
Fewer than a few hundred good examples and no eval set	Prompting	You cannot tell whether training helped

The last row is the one people skip. If you cannot measure the prompt-only baseline, you cannot know whether the fine-tune beat it.

LoRA vs QLoRA vs full fine-tuning: what does the research say?

Full fine-tuning updates every weight. LoRA (Hu et al., 2021) freezes the base model and trains small low-rank matrices beside chosen layers; on GPT-3 175B it cut trainable parameters by 10,000 times and GPU memory by 3 times, with no added inference latency once merged. QLoRA (Dettmers et al., 2023) does the same over a base model quantised to 4-bit NF4, which let the authors fine-tune a 65B model on a single 48GB GPU.

The honest research picture has two halves. Biderman et al., LoRA Learns Less and Forgets Less, found that in standard low-rank settings LoRA "substantially underperforms" full fine-tuning on code and maths with large datasets (around 100K instruction pairs, or 20B tokens of continued pretraining), but forgets less of what the base model could do outside the target domain. Then in September 2025 John Schulman and colleagues at Thinking Machines published LoRA Without Regret, which found that LoRA matches full fine-tuning's sample efficiency and final performance on small-to-medium instruction and reasoning datasets, provided you apply it to all layers (the MLP layers matter most; attention-only LoRA learns more slowly) and the dataset does not exceed the adapter's capacity. They also found the optimal LoRA learning rate is about 10 times the full fine-tuning rate, and that LoRA is less tolerant of very large batch sizes.

Read together, they say: for the typical product fine-tune (thousands to tens of thousands of examples teaching a behaviour), LoRA on all linear layers is the right default, and full fine-tuning is for when you are effectively teaching a new domain at scale. QLoRA is the memory trick that makes it fit. Unsloth's requirements page lists minimums of 6 GB of VRAM for an 8B model with QLoRA versus 22 GB with 16-bit LoRA, and 41 GB versus 164 GB at 70B. The step-by-step version is in my LoRA fine-tuning guide with Unsloth and TRL.

What is reinforcement fine-tuning (RFT), and who still offers it?

Supervised fine-tuning (SFT) shows the model correct answers and minimises the difference. Reinforcement fine-tuning lets the model generate several candidate answers, scores them with a grader, and pushes the weights toward the higher-scoring ones. AWS describes its graders as "verifiable rule-based graders or AI-based judges"; in practice the useful ones are programs: does the code pass the tests, does the SQL return the right rows, does the extracted JSON match the schema.

Two properties make RFT attractive. You need prompts and a grader rather than thousands of hand-written ideal answers, and it can improve reasoning on tasks where you can check the result but struggle to write the perfect demonstration. The Thinking Machines post adds a useful engineering detail: for policy-gradient RL, LoRA matched full fine-tuning even at rank 1, because each episode carries very little information. RL fine-tuning needs little adapter capacity, but a lot of sampling compute.

The managed options in October 2026 are Bedrock (Nova 2 Lite, gpt-oss-20b, qwen3-32b), Vertex AI (Gemini 3.5 Flash) and Tinker. OpenAI's RFT, billed at $100 an hour of training time on o4-mini, is effectively finished with that base model's shutdown. For open weights you can run GRPO yourself with Hugging Face TRL or Unsloth. The catch is the grader: a sloppy reward function gets optimised as faithfully as a good one, and models are very good at finding the gap between what you measured and what you meant.

How much does fine-tuning cost in 2026?

Every provider below bills training as dataset tokens multiplied by epochs, so cost is easy to estimate before you start. List prices per million training tokens, as published on 20 October 2026:

Provider and model	Training price per 1M tokens	Notes	Source
Vertex AI, Gemini 2.5 Pro	$25.00	SFT	Google
OpenAI, GPT-4.1	$25.00	Existing customers only, ends 6 Jan 2027	OpenAI
Vertex AI, Gemini 3.5 Flash	$10.00	SFT and RL; tuned endpoints from Gemini 3 bill at 1.5x base inference	Google
Vertex AI, Gemini 2.5 Flash	$5.00	SFT and preference tuning	Google
OpenAI, GPT-4.1 mini	$5.00	Existing customers only	OpenAI
Vertex AI, Gemini 3.5 Flash Lite	$3.00	SFT	Google
Together AI, Llama 3.3 70B	$2.03	SFT, $4 job minimum	Together
Together AI, gpt-oss-20B	$0.40	SFT, $4 job minimum	Together
Tinker, gpt-oss-20B	$0.396	LoRA train meter; sampling billed separately	Tinker
OpenAI, o4-mini RFT	$100 per hour	Base model shuts down 23 Oct 2026	OpenAI

Together publishes two rate tables per model without labelling them in a way I could map with certainty to LoRA and full fine-tuning; the figures above are the lower of the two.

Training is usually the small number. This is the estimator I run before any project, with the rates above:

# cost.py: back-of-envelope training cost for one SFT run (Python 3.9+).
# Rates are list prices per 1M training tokens, read from vendor pages on 2026-10-20.
# Billable training tokens = dataset tokens x epochs on every provider below.
RATES_PER_M = {
    "vertex/gemini-2.5-pro":        25.00,
    "openai/gpt-4.1 (closing)":     25.00,
    "vertex/gemini-3.5-flash":      10.00,
    "vertex/gemini-2.5-flash":       5.00,
    "together/llama-3.3-70b":        2.03,
    "together/gpt-oss-20b":          0.40,
    "tinker/gpt-oss-20b":            0.396,
}

examples = 5_000          # curated prompt/response pairs
tokens_per_example = 800  # prompt + response, measured with the target tokenizer
epochs = 3

train_tokens = examples * tokens_per_example * epochs
print(f"billable training tokens: {train_tokens:,}")
for name, rate in RATES_PER_M.items():
    print(f"{name:30s} ${train_tokens / 1e6 * rate:8.2f}")

# Output:
# billable training tokens: 12,000,000
# vertex/gemini-2.5-pro          $  300.00
# openai/gpt-4.1 (closing)       $  300.00
# vertex/gemini-3.5-flash        $  120.00
# vertex/gemini-2.5-flash        $   60.00
# together/llama-3.3-70b         $   24.36
# together/gpt-oss-20b           $    4.80
# tinker/gpt-oss-20b             $    4.75

The bills that hurt come later. Vertex charges 1.5 times base inference for tuned Gemini 3 endpoints; OpenAI lists tuned GPT-4.1 inference at $3.00 per million input tokens and $12.00 per million output; an open-weight fine-tune means you run the GPUs yourself or pay someone per token. The self-hosting vs API costs arithmetic applies in full, plus the people-cost of rebuilding the dataset every time the base model moves.

How do you evaluate a fine-tuned model before shipping it?

This is where most fine-tunes fail, and it is the same discipline as any other release. Training loss going down tells you the model memorised your training set. It does not tell you the model got better at the job.

The minimum I want before a fine-tune ships:

1. A frozen holdout set drawn from real traffic, never seen in training, with expected outputs or a programmatic check.
2. The prompt-only baseline scored on the same set: the best prompt you can write against the strongest model you would otherwise use. If the fine-tune does not beat it on quality, cost or latency, stop.
3. A regression suite for general ability. Biderman et al. showed full fine-tuning forgets more than LoRA, and both forget something. Keep a few hundred general prompts (safety refusals, instruction following, the formats other features depend on) and run them against every checkpoint.
4. The eval in CI, so a retrain on new data cannot ship a worse model quietly. I covered the mechanics in MLOps in 2026: evals are the new unit tests and in the LLM evals in GitHub Actions guide.
5. A rollback path: the previous adapter or the prompt-only configuration behind a flag. A LoRA adapter is a small fraction of the base model's size, so keeping several versions is cheap.

Then there is the platform question that OpenAI just made concrete. Store your training data, eval set and grader as versioned artefacts, because you will rerun them on the next base model whether you planned to or not. With open weights you also keep the weights, and the licence terms travel with them.

FAQ

Is fine-tuning better than RAG?

They solve different problems. RAG is better for adding or updating knowledge; Ovadia et al. found it beat fine-tuning on both seen and new facts. Fine-tuning is better for changing behaviour: format, tone, task consistency, and shortening long prompts. Many production systems use both, a fine-tuned small model that reads retrieved context.

Can I still fine-tune GPT models in 2026?

Only if your organisation is an active existing OpenAI fine-tuning customer, and only until 6 January 2027, after which no new jobs can be created. Existing fine-tuned models keep working until their base model is deprecated; gpt-4.1-nano and o4-mini shut down on 23 October 2026 and gpt-4.1 and gpt-4.1-mini on 14 January 2027.

Is LoRA as good as full fine-tuning?

For most product fine-tunes, yes, if it is configured properly. Thinking Machines found LoRA matches full fine-tuning on small-to-medium datasets when applied to all layers with roughly a 10 times higher learning rate. On very large datasets in a new domain, such as 20B tokens of code, full fine-tuning still wins, though LoRA forgets less.

How many examples do I need to fine-tune an LLM?

There is no universal number, and anyone who quotes one without asking about your task is guessing. Start with a few hundred high-quality examples and a separate holdout set, train, and compare against the prompt-only baseline. If quality climbs as you add data, collect more; if it plateaus, the problem is your data quality or your task definition, not the volume.

This quarter I would do three things. If anything I own depends on an OpenAI fine-tune, I would export the training set, rerun it on an open-weight model with LoRA, and have the comparison on the holdout set before January. For any new request I would make the team show the prompt-only baseline and an eval set first, which ends a fair number of fine-tuning projects in a good way. And where a task can be graded by a program, I would try RFT on a small open model before reaching for a bigger closed one, because that is where 2026's tooling improved most.

Related: MLOps in 2026: Evals Are the New Unit Tests, Judges Agree With Experts 66% of the Time, and OpenAI's Evals API Shuts Down on 30 November, Open Weights in 2026: Chinese Labs Ship the Frontier, the Licenses Grew Clauses, and Brussels Started Enforcing and GPU Clouds in 2026: H100s at $2.59 an Hour, $104B of CoreWeave Backlog on $35B of Debt, and a Six-Year Bet on Silicon.