Do You Need Fine-Tuning? Two of the Big Three Are Taking It Away

Any argument about whether fine-tuning would help you should start with a fact that may settle it without one. On 2 August 2026 we read the fine-tuning pages of the three largest model providers. Two of them are in the process of taking the feature away from developers.

Google's own page, ai.google.dev/gemini-api/docs/model-tuning, says this:

"With the deprecation of Gemini 1.5 Flash-001 in May 2025, we no longer have a model available which supports fine-tuning in the Gemini API or AI Studio"

And, in case that reads as a temporary gap:

"We don't have immediate plans to bring fine-tuning support but would love to hear from you on our developer forum if fine-tuning is important to your use case."

OpenAI's supervised fine-tuning guide, read the same day, carries a notice that also appears on its pricing page:

"OpenAI is winding down the fine-tuning platform. The platform is no longer accessible to new users, but existing users of the fine-tuning platform will be able to create training jobs for the coming months."

Neither of those is our characterisation. They are the vendors' words, on the vendors' pages, on a stated date. If you are a developer who has not already got a fine-tuning account at OpenAI, you cannot open one. If you were going to fine-tune through the Gemini API, there is no model to do it with.

Notice the shape of Google's decision rather than the fact of it. Tuning did not disappear at Google. The page that says you cannot do it any more points you at the Gemini Enterprise Agent Platform, where it is still sold. It moved out of the developer tier and behind the enterprise console. That one product decision makes most of this guide's argument for us. Fine-tuning is becoming something sold to organisations with a procurement process, not something a developer reaches for on a Tuesday.

Two things we are going to be careful about

This guide separates three kinds of claim, and it will keep saying which is which. A quotation is verbatim from a vendor's own page, with the page and the date it was read. A measurement is arithmetic or counting we did ourselves, shown so you can redo it. An open question is something we tried to establish and could not — and we say so rather than rounding it into a claim.

That third category is not decoration. You have probably heard that provider documentation says fine-tuning teaches form, not facts, and that retrieval is the real answer for knowledge. We went looking for that advice on the primary pages and could not find it. Microsoft's fine-tuning considerations page, read on 2 August 2026, goes the other way in places: it describes supervised fine-tuning as a way to "teach the base model new skills", and lists "Enhancing retrieval-based performance: Combining fine-tuning with retrieval methods improves a model's ability to integrate external knowledge". That is fine-tuning with retrieval, not instead of it. So we are not going to put the folk version in quotation marks and attribute it to anyone. If you want retrieval explained properly, our plain-English AI vocabulary does it — a librarian, not a fact-checker.

One asymmetry worth flagging, because it shapes what this guide can say about Google. Google's tuning prices are published and quotable. Google's tuning guidance we could not retrieve: the old Vertex advice URL redirects to a page that returns a navigation tree with no prose, a sibling path returns HTTP 404, and the enterprise-platform page that Google's own Gemini API notice links to behaved the same way. So below you will find Google quoted on cost and not quoted on advice. That is a limitation of what we could read, not a claim about what Google thinks.

Training is cheap. That is not the reason to avoid it.

The first case against fine-tuning is usually cost. That case is wrong, and it would not survive a reader who checks the numbers.

Together AI's fine-tuning pricing, read 2 August 2026, charges LoRA supervised fine-tuning on a model up to 16B at $0.48 per million tokens, and states: "Fine-tuning jobs have a $4.00 minimum charge." Four dollars. For a small experiment on a modest dataset, the minimum charge is the bill. Whatever is stopping you, it is not the price of the training run.

One line item in that pricing does catch people, and it is worth knowing before you budget. Together defines billable tokens as total_tokens = (n_epochs × tokens_per_training_dataset) + (n_evals × tokens_per_validation_dataset). Epochs multiply the bill. A dataset you thought of as "two million tokens" trained for five epochs is ten million tokens of billing.

The real costs come after the training run.

1. You may pay a premium on every token, forever

OpenAI publishes base and fine-tuned prices on the same page, which makes the comparison clean. Per million tokens, standard tier, read 2 August 2026 — the prices are quoted, the premium column is our division:

The pattern is the finding, not the prices. The premium is 1.5× on the full-size models and 2× on the cheap ones — so fine-tuning costs proportionally most in exactly the place people reach for it to save money, which is the "tune a small model instead of prompting a big one" move.

We are not going to oversell that. Our own arithmetic: at ten million output tokens a month on gpt-4o-mini, the premium is the difference between $6.00 and $12.00. That is not a reason to do anything. It becomes real money at volume and nowhere else, and a guide implying otherwise is scaremongering. If you want to know what your own volume does to it, our monthly LLM spend projector and price comparison take the arithmetic off your hands, and what an LLM actually costs you builds the whole cost model.

Google's Vertex pricing shows the same premium arriving unevenly, which is worth a sentence because nothing warns you. The footnote in the Gemini 2.0 and 2.5 sections reads "Tuned model endpoint has the same prediction price as the base model." The footnote in the Gemini 3 section reads "Tuned model endpoint will be 1.5 times of the base model." Serving a tuned Gemini 2.5 costs what the base costs; serving a tuned Gemini 3 costs half as much again. Anyone who budgeted on the first footnote and then upgraded family would be wrong. (An open question, recorded honestly: the page lists training prices for the Gemini 2.0 family only. We could not obtain them for 2.5 or 3, and we are not going to extrapolate.)

2. On AWS, serving it may cost more than everything else combined

Amazon's Bedrock user guide, on the Provisioned Throughput page, states this flatly:

"If you customized a model, you must purchase Provisioned Throughput to be able to use it."

Provisioned Throughput is dedicated capacity billed by the hour whether or not anything is asking it questions. For Llama 2 70B, AWS publishes $23.50 per hour with no commitment, $21.18 on a one-month commitment and $13.08 on six months. Our arithmetic, for a 30-day month: $16,920, $15,249.60 and $9,417.60 respectively — before the fine-tuned model has answered a single useful question. Training the same model costs $7.99 per million tokens and storing it costs $1.95 a month.

We checked that "must" rather than repeating it. It is not the whole story. A different page of the same user guide — Set up inference for a custom model — offers two options, not one. The second is on-demand deployment, where "you only pay for what you use and you don't need to set up provisioned compute resources." Both pages were read on 2 August 2026. AWS's own documentation contradicts itself.

The resolution matters more than the contradiction. On-demand deployment of a custom model is real but narrow: it requires the US East (N. Virginia) or US West (Oregon) region, the model must have been customised on or after 16 July 2025, and only five base models qualify — Amazon Nova Lite, Nova 2 Lite, Nova Micro, Nova Pro, and Meta Llama 3.3 70B Instruct. Llama 2 70B, the model whose hourly rate is published above, is not among them.

So: the five-figure monthly bill is a ceiling, not a universal floor, and we would have published it as a floor if we had trusted the first page we read. For anything outside those five models it is what you pay. Our Bedrock directory entry lists both customisation and provisioned-throughput options; it is right to list them separately, and now you know why the distinction is load-bearing.

3. The maintenance treadmill, which is the honest core of this

Microsoft's fine-tuning considerations page has a "Challenges and limitations" section, which is the vendor arguing against its own feature. The line that matters:

"Fine-tuning may need to be repeated whenever the data is updated, or when an updated base model is released. This involves monitoring and updating regularly."

Read that against how often base models ship now. Every release restarts the work. The same page notes that fine-tuning brings "extra costs associated with training and hosting the custom model", that it is "a repetitive task (trial and error)", and that poor or unrepresentative data produces over-fitting and bias. None of that is a cost you can put in a spreadsheet, and all of it recurs.

What the vendors say it is actually for

Microsoft's own list of what fine-tuning is good at is striking for what is not on it. "Modifying style and tone: Fine-tuning helps align model outputs with a desired style or tone." "Generating outputs in specific formats or schemas." "Reducing prompt engineering overhead: Many users begin with few-shot learning … Over time, this process can lead to increasingly long prompts."

Every item is about form — how the answer looks, not what it knows — although the page never says so in those words, and we are not going to pretend it does.

OpenAI's model-optimization guide gives an ordering rather than an adjective, which is more useful. Write evals, prompt the model, then — "For some use cases, it may be desirable to fine-tune a model for a specific task" — then run evals, then tweak. Fine-tuning is step three of five, and "for some use cases, it may be desirable" is about as unenthusiastic as product documentation gets about its own product. The same guide is blunter elsewhere: "Only invest in fine-tuning after setting up evals. You need a reliable way to determine whether your fine-tuned model is performing better than a base model."

AWS frames it differently again, and the framing is worth borrowing. Bedrock lists three customisation methods: supervised fine-tuning, reinforcement fine-tuning, and distillation — which it describes as transferring knowledge "from a larger more intelligent model … to a smaller, faster, and cost-efficient model". That is a cost-engineering move, not a quality move. It reframes the question from "will this make the model smarter?" to "am I trying to serve a large volume more cheaply?" If you are not operating at that volume, you have your answer.

The one case that ought to be the exception

If fine-tuning wins anywhere, it should win here. The models are trained overwhelmingly on English; South-East Asian languages are under-represented in the vocabulary itself — our companion guide on using AI in your own language measured that more than a quarter of our Hong Kong copy reaches the model as byte fragments rather than characters. Surely, if anything justifies training your own, it is Malay or Thai or Vietnamese.

This is the part of the guide where we expected the title to be wrong. It was not.

The SEA-HELM leaderboard scores models on South-East Asian language tasks. Reading the board dated 10 July 2026 on 2 August 2026, filtered to all 44 models at or below 200B parameters, the top of the overall SEA average is:

The best model on a South-East Asian benchmark is a general-purpose Google model that nobody tuned for the region, ahead of the region's own national-programme fine-tune by 2.47 points on a board whose confidence intervals run to hundredths. SEA-LION does take Thai (72.34 against Gemma 4 31B's 71.04) — one language of seven, and a clean sweep would have been the suspicious result.

The leaderboard names each SEA-LION's base family, so a tuned model can be read against a comparable base. The deltas below are our subtraction:

This is our whole argument in miniature, measured in the one domain where fine-tuning was supposed to be the strongest case. On a weak base, regional tuning buys a great deal. On Gemma 3 27B — a good base — the tuned model is indistinguishable from, and fractionally behind, the model it was built from. And the entire exercise is then leapfrogged by Gemma 4, which arrived later and was never tuned for the region at all. That is Microsoft's maintenance treadmill with numbers on it.

Four limits on that table, all of which belong in it rather than in a footnote. The base pairings are our inference from model names, not vendor statements — only the Gemma 3 27B pairing is confirmed by the model card, which describes "a decoder model using the Gemma 3 architecture". SEA-LION v4.5 (Qwen) 27B is deliberately absent because we could not determine which Qwen version it was built from; both candidates are on the board, so its delta is somewhere between +1.90 and +5.44, and we would rather leave it out than pick the flattering end. The board evaluates open-weight models here — the closed frontier models are counted in its own description but were not in any view we could retrieve, so this says nothing about how GPT, Claude or Gemini handle these languages. And the SEA-LION paper itself makes no claim that regional tuning beats prompting a larger general model; all its comparisons are against open models in the same size class.

The regional conclusion is not that fine-tuning fails for Malay or Thai. It plainly works. It is that someone has already done it, at a scale you cannot match — continued pre-training on 200 billion tokens, millions of instruction pairs, a national research programme — and the result is still being outrun by the next general-purpose release. Your move is to pick a regionally tuned open model, not to train one. SEA-LION, Typhoon and Sarvam AI are three, and our self-hosting roundup covers how to choose between open models generally — a debt that roundup explicitly left open, since it said licences interact with derivative models in ways it only gestured at.

What fine-tuning looks like in a price list — we counted

We run an AI directory. Measured on production on 2 August 2026: 1,370 entries, 1,347 active, 1,291 indexed. Of those, 166 — 12.1% — mention fine-tuning somewhere in their description, review, verdict, use cases, FAQ, pricing detail or tags. They cluster where you would expect: 72 in LLMs & Chat, 27 in Code & Dev Tools, 26 in Image Generation, 18 in Video & Audio.

We went looking for entries that mislead — one implying fine-tuning teaches a model your facts, or that it substitutes for retrieval. There are none. Where an entry names both, it names them correctly and separately. These audits usually end with a list of offenders. We do not have one — and inventing one would be worse than not having one.

There is a milder pattern, and it is a thing you can learn to notice. Twelve pricing tiers across the directory name fine-tuning. Five of them are "Custom"-priced tiers where it is a bullet with no number attached — mendable, chat2db, rodin-3d, volcengine-ark and alibaba-bailian-model-studio. Two of those five are not model vendors at all: mendable sells documentation-search components and chat2db is a database client. Both list custom model fine-tuning as an Enterprise upsell.

So fine-tuning's most common appearance in a price list is as an unpriced enterprise ornament — a bullet that signals seriousness and commits the vendor to nothing. That is not a lie and we are not calling it one. The other seven tiers are mostly open-weight or GPU-rental entries where "fine-tunable" is a genuine licence fact, and it would be sloppy to sweep them in. But when you see fine-tuning on a Custom-priced tier, you have learned nothing about what it costs or whether it works.

When it genuinely is the answer

Four cases survive the arguments above. Check whether you are in one before ruling fine-tuning out.

• You need output in a rigid format, every time. This is the case the vendors put first, and it is real. If you are fighting a schema with ever-longer prompts, that is the documented symptom.
• You need a specific house voice that a style guide in the prompt has not managed to produce.
• You have abundant labelled examples already — hundreds to thousands, per Microsoft's stated figure — as a by-product of work you were doing anyway. If you would have to create the dataset, price that first; it is almost always the largest line item and it appears on nobody's pricing page.
• You are distilling for cost at volume — making a cheap model imitate an expensive one on one narrow task. AWS's framing, and the honest mainstream use in 2026.

One number to keep next to those. OpenAI's guide sets a minimum of 10 examples, suggests starting with 50, and says improvements typically appear on 50–100. Microsoft says teams generally use "hundreds to a few thousand". AI Singapore's SEA-LION model card describes post-training on roughly 10 million QA samples. The spread between 10 and 10 million examples is the lesson. A vendor's stated minimum is a technical floor, not a realistic estimate for getting good results. Ten examples will produce a model. It will not produce a better one.

What to do instead, in order

This is OpenAI's documented ordering, not ours, and it is good.

1. Write evals first. Not optional and not last. Without a way to tell whether a change helped, every subsequent step is decoration — and OpenAI says explicitly not to invest in fine-tuning until this exists.
2. Prompt properly. Most of what people want from fine-tuning is a formatting instruction and three examples in the prompt.
3. Retrieve, if the problem is knowledge. If the model does not know your product catalogue, no amount of tuning reliably installs it. Our vocabulary guide explains retrieval properly; the glossary is the longer reference.
4. Change model. Cheaper than a training run and instant. The price comparison and token counter make the swap measurable.
5. Then, and only then, consider fine-tuning — with your evals already in place, so you can tell whether it worked.

Most readers will stop at step two or three, which is the honest answer to the title. If you get to step five and the case still holds, you were never the person this guide was written for, and you will have the eval scores to prove it.

The argument that will still be true after every price on this page has changed is this one. A fine-tune is a snapshot of a model that is about to be superseded. The discipline that survives — clean data, real evals, a prompt you understand — is worth more than the snapshot, and it transfers to whatever ships next. We made that claim in an earlier guide without evidence. The table above is the evidence.

Disclosure. This guide discusses products from Anthropic, OpenAI, Google, Amazon and others, and was drafted with the assistance of an Anthropic model. Every vendor claim above is quoted from that vendor's own documentation with the date it was read; every calculation is shown so you can redo it; and where we could not establish something, we said so instead.