What Is Fine-Tuning in AI? The 2026 Field Guide

I define what is fine-tuning in AI as the controlled adaptation of a pre-trained model by updating some or all of its parameters on task-specific examples, and the sharp 2026 contradiction is that demand for custom models is rising just as one of the best-known self-serve routes is closing. OpenAI now says its fine-tuning platform is unavailable to new users and will stop accepting new jobs from active existing customers on 6 January 2027. At the same time, Google Cloud is broadening supervised and preference tuning, Crusoe has launched serverless LoRA training for open models, Microsoft is building an enterprise customisation business, and Thinking Machines has released an open-weight model designed to be fine-tuned.

That divergence matters because fine-tuning is no longer a single technical choice. It is a decision about data ownership, model access, serving economics, evaluation discipline, and the ability to move when a provider changes a lifecycle policy. A model can become more reliable at a narrow classification task, a strict JSON format, a house style, or a recurring workflow. It can also become less capable outside the training distribution, reproduce annotation mistakes, overfit superficial patterns, or lock a team into an inference endpoint whose recurring cost dwarfs the training bill.

This guide explains the mechanics, the main adaptation methods, the decision boundary between fine-tuning and retrieval-augmented generation, the full implementation workflow, current 2026 platform pricing, technical constraints, evaluation design, security obligations, and failure modes. The central argument is simple: fine-tuning is valuable when it converts a stable, measurable requirement into consistent model behaviour. It is a poor substitute for current knowledge, weak product design, missing tools, or an evaluation process that cannot tell improvement from memorisation.

What Is Fine-Tuning in AI, Technically?

A foundation model begins with parameters learned during pre-training, usually by predicting missing or next tokens across a very large corpus. Fine-tuning continues optimisation on a narrower dataset. In supervised fine-tuning, each training record pairs an input with a known good output. The optimiser calculates how far the model’s predicted token distribution is from that target, backpropagates the error, and nudges selected weights in a direction that makes the desired output more likely next time.

The key distinction is persistence. A prompt changes the context for one request. Retrieval adds external evidence at inference time. A tool call lets the model delegate an action. Fine-tuning changes the model itself, or stores a compact adapter that alters how the base model behaves whenever that adapter is loaded. This is why a successful tuned model may need shorter prompts, follow a schema more consistently, or choose domain terminology without being reminded on every call.

The process sits inside a wider machine-learning system. Data versioning, tokenisation, train and validation splits, experiment tracking, GPU scheduling, model registries, inference endpoints, observability, and rollback are all part of the outcome. Readers building a broader data-science AI stack should treat the tuned weights as one artefact in that chain, not as a self-contained product. A small improvement in model loss is irrelevant if the serving pipeline truncates inputs, the tokenizer changes, or the business metric does not move.

OpenAI’s current documentation describes four major stages: build the dataset, upload examples, create the training job, and evaluate the result. It also recommends establishing evaluations before spending on training. That order is not administrative caution. Without a frozen baseline, teams cannot distinguish learning from favourable sampling, prompt changes, or evaluator drift. In practice, the evaluation set should be created before annotators see model failures at scale, then locked so the same difficult cases test every candidate.

The Main Model Adaptation Methods

Fine-tuning is an umbrella term. The right method depends on whether the organisation needs a narrow output format, new domain language, preference alignment, verifiable reasoning, or a fully owned derivative model. Treating all methods as interchangeable hides major differences in compute, data, portability, and risk.

Method	What Changes	Best Fit	Primary Constraint
Full-parameter fine-tuning	All or most trainable weights	Deep domain shift, complex procedures, research control	Highest memory, storage, and catastrophic-forgetting risk
Supervised fine-tuning	Weights learn from input and target-output pairs	Classification, extraction, style, formatting, instruction following	Needs consistent demonstrations and strong held-out evals
LoRA or QLoRA	Small low-rank adapters, often on a quantised base	Cost-sensitive specialisation and multi-tenant adapters	Rank and target-module choices can limit expressivity
Continued pre-training	Weights learn from unlabelled domain text	Vocabulary, domain distributions, specialised language	Can absorb noise and still needs later instruction tuning
Preference tuning or DPO	Model learns preferred over rejected outputs	Tone, helpfulness, safety, response trade-offs	Preference labels may encode unstable or conflicting values
Reinforcement fine-tuning	Policy optimises against a grader or reward	Verifiable reasoning, code, maths, agent tasks	Reward hacking, grader cost, instability, and harder debugging

Supervised Fine-Tuning

SFT is the most accessible method. A record can contain a user message and an assistant answer, a document and extracted fields, or a dialogue containing tools and expected tool calls. The model minimises token-level cross-entropy against the target response. This works well when a human can write or verify what good output looks like. It works poorly when the task has many equally valid answers but annotators reward only one style.

LoRA and QLoRA

Low-Rank Adaptation freezes the base model and learns compact matrix updates. The original LoRA paper reported up to 10,000 times fewer trainable parameters and about three times lower GPU memory than full fine-tuning in its GPT-3 experiments. QLoRA adds quantisation so the frozen base can fit into less memory. The same logic appears beyond language models in the open-weight image model ecosystem, where adapter-style customisation lets creators specialise a base without duplicating every parameter.

LoRA rank is not merely a cost slider. A 2026 theoretical analysis found regimes where a very small rank can improve generalisation when the downstream update is effectively low-rank. That makes rank a form of regularisation. The opposite also matters: complex multi-step procedures may require higher-rank changes that a compact adapter cannot represent. Teams should compare at least two ranks and one full or broader-update baseline instead of assuming the cheapest adapter is sufficient.

Preference and Reinforcement Methods

Direct Preference Optimisation learns from chosen and rejected responses without training a separate reward model in the classic pipeline. Reinforcement fine-tuning uses a grader or reward signal to optimise behaviours that can be scored, such as passing tests, producing valid proofs, or completing a tool workflow. These methods can shape judgement rather than imitate a single target, but they can also exploit weaknesses in the grader. A model that learns to satisfy a metric without solving the underlying task has improved the scoreboard, not the product.

When Fine-Tuning Beats Prompting, Retrieval, or Tools

The fastest way to waste a fine-tuning budget is to use training for a problem that context or software can solve more safely. Fine-tuning should enter the plan only after a strong prompt baseline, because a prompt is reversible, inspectable, and cheap to change. The threshold is repeated failure on a stable requirement, not irritation with occasional model variability.

Approach	Use It When	Do Not Use It As	Operational Test
Prompt engineering	Instructions and examples fit in context and change often	A permanent memory system	Can one reviewed prompt meet the target across the frozen eval set?
RAG	Answers depend on current, private, or citable knowledge	A way to teach stable style or decision policy	Can retrieval recall the right evidence and the model cite it correctly?
Tool calling	The system must calculate, search, transact, or query live systems	A replacement for permissions or deterministic software	Can the tool contract be validated and actions be logged or reversed?
Fine-tuning	A repeated behaviour must be consistent at scale	A database, policy engine, or source of current facts	Does the tuned model beat the baseline on quality, latency, and total cost?

Fine-tuning is strongest for stable transformations: mapping support messages to an approved taxonomy, extracting fields into a fixed schema, generating a controlled voice, translating specialised terminology, selecting the right tool from a recurring catalogue, or correcting an instruction-following failure that survives prompt optimisation. The model sees many demonstrations and compresses their pattern into parameters.

RAG is stronger when the problem is knowledge freshness. A policy manual changes, a customer balance updates, and a product catalogue grows. Encoding those facts in weights makes updates slow and provenance weak. The same distinction matters when evaluating tool claims. A sound AI tool testing methodology separates the model’s behaviour from retrieval quality, orchestration code, and vendor-managed defaults rather than crediting every system improvement to fine-tuning.

The most effective production design is often hybrid. A tuned model can learn how to ask clarifying questions, choose a retrieval filter, cite evidence, and format the final result. Retrieval supplies current facts. Tools perform deterministic actions. Guardrails block prohibited outputs. This division keeps mutable knowledge outside the weights while using fine-tuning for stable behaviour.

A practical decision rule is to require evidence across three axes. First, quality: the tuned candidate must improve task-specific success and not merely average language quality. Second, economics: shorter prompts or a smaller base model must offset training, hosting, and maintenance. Third, control: the team must be able to reproduce the training data, model version, hyperparameters, evaluator, and rollback path. If one axis is missing, the project is still an experiment.

Data Design Decides the Outcome

A fine-tuning dataset is not a pile of successful conversations. It is a specification expressed through examples. Every label teaches both the intended behaviour and the annotator’s shortcuts, inconsistencies, omissions, and hidden assumptions. Model quality therefore depends more on coverage and label discipline than on raw record count.

Build the Evaluation Set First

Start with production failures and business decisions, then build a frozen evaluation set before generating training examples. Stratify it by task type, difficulty, user segment, language, input length, safety category, and costly edge cases. Keep duplicate or near-duplicate records out of training. For temporal tasks, split by time so the model cannot learn future patterns from the training side. For customer or entity data, split by entity so repeated names do not leak across sets.

Write Demonstrations That Reveal the Rule

Each example should make the desired policy clear. Include positive cases, refusals, ambiguity, missing information, boundary values, and cases where the correct action is to call a tool or ask a question. Avoid synthetic data that repeats one template with changed nouns. Template-heavy datasets can produce impressive validation loss while teaching brittle surface cues.

OpenAI documents a minimum of ten SFT examples and says it often observes improvement from 50 to 100, while warning that the right number varies by use case. That should not be read as a universal sufficiency claim. A narrow formatting task may stabilise quickly. A multilingual agent with dozens of tools and policy branches may require thousands of carefully balanced trajectories.

Data ownership and location must be resolved before upload. The AI sovereignty visibility gap is directly relevant because fine-tuning creates another copy, derivative artefact, and audit trail that may cross regions or providers. Record the legal basis, licence, retention policy, redaction method, approved regions, and whether vendor terms permit data use for service improvement. Do not rely on a dashboard toggle as the entire governance record.

Prevent Contamination and Label Drift

Deduplicate by normalised text, embeddings, identifiers, and business keys. Hash source documents and preserve lineage from raw record to final JSONL row. Use written annotation guidelines, calibration rounds, and adjudication for disputed examples. Measure inter-annotator agreement where judgement is subjective. If the policy changes, version the dataset rather than silently editing old examples. A model trained on mixed policy eras will learn an average that nobody approved.

The most valuable information gain is often a negative dataset: examples of tempting but wrong outputs. These reveal the boundary between categories, the unsupported inference the model should avoid, or the step that requires human approval. A model trained only on clean successes may learn the happy path while failing exactly where the organisation carries risk.

A Production Fine-Tuning Workflow

A reliable workflow is a sequence of gates. Each gate should create a reproducible artefact and a reason to stop if the evidence is weak. The aim is not to complete a training job. It is to decide whether a tuned model is safer, cheaper, and more useful than the baseline.

1. Define one measurable requirement, such as valid schema rate, macro F1, exact tool-selection accuracy, or successful task completion.
2. Freeze a representative evaluation set and record the current base model, prompt, retrieval configuration, tools, temperature, and decoding settings.
3. Create a small high-quality training set with explicit provenance, policy coverage, refusals, ambiguity, and edge cases.
4. Validate the file format, token lengths, role order, tool schemas, licences, redaction, class balance, and train-validation separation.
5. Run the cheapest informative experiment first, usually SFT or LoRA on a smaller model, while logging seed, epochs, learning rate, rank, target modules, and checkpoints.
6. Compare every checkpoint with the unchanged baseline using deterministic metrics, blinded human review, safety tests, and slice-level analysis.
7. Deploy as a shadow or limited canary, capture real production errors, latency, token use, refusal rate, and cost, then preserve an instant rollback.
8. Promote only when the tuned model meets predefined thresholds and the team has a retraining, deprecation, and data-deletion plan.

Infrastructure affects every gate. Training jobs compete for GPU memory, checkpoints consume storage, and deployment can require a permanently allocated accelerator. The economics described in the Microsoft Maia 200 analysis illustrate why inference hardware is a strategic layer rather than an invisible utility. Even when a vendor bills training by tokens, serving capacity, data movement, and idle endpoints can dominate lifetime cost.

For open models, a typical technical stack includes Hugging Face Datasets for loading, Transformers for the base model and tokenizer, PEFT for LoRA adapters, TRL for SFT or preference trainers, Accelerate or DeepSpeed for distributed execution, bitsandbytes or another quantisation backend for QLoRA, Weights & Biases or MLflow for experiment tracking, an object store for checkpoints, and vLLM, TensorRT-LLM, TGI, or a managed endpoint for serving. API integrations should include identity, secrets, data catalogues, model registries, evaluation services, logging, alerting, and a deployment pipeline that can pin both base and adapter versions.

Validate the actual serving combination. An adapter trained against one base snapshot may not load cleanly on a later tokenizer or architecture revision. Quantisation choices can change output quality. Merging an adapter into the base simplifies serving but creates a new full-size weight artefact. Keeping adapters separate supports multi-tenant switching but can add cache pressure and cold-start latency. The correct packaging depends on traffic shape and exit strategy.

Platforms, Features, APIs, and 2026 Pricing

Commercial pricing is difficult to compare because providers meter different units. Some charge per million training tokens, some per GPU hour, and some show model-specific examples while withholding enterprise capacity rates. Training tokens often equal dataset tokens multiplied by epochs, so a three-epoch run on ten million tokens is billed as thirty million training tokens. Inference, storage, evaluation, networking, and dedicated capacity remain separate unless the provider states otherwise.

Provider or Model	Training Price	Inference or Hosting	Limits and Hidden Costs
OpenAI o4-mini RFT	US$100 per training hour	Standard: US$4 input, US$1 cached input, US$16 output per 1M tokens	Closed to new users; active customers lose new-job access 6 Jan 2027; grader tokens billed separately
Google Gemini 3.5 Flash	US$10 per 1M training tokens	Tuned Gemini 3 endpoints priced at 1.5 times base prediction	Dataset tokens multiplied by epochs; region and model lifecycle apply
Google Gemini 2.5 Pro	US$25 per 1M training tokens	Prediction charged separately	Up to 131,072 tokens per example; JSONL file up to 1 GB
Google Gemini 2.5 Flash	US$5 per 1M training tokens	Prediction charged separately	SFT and preference tuning; validation caps apply
Google Gemini 2.5 Flash Lite	US$1.50 per 1M training tokens	Prediction charged separately	SFT and preference tuning; base-model quotas still matter
Google open models	US$0.28 to US$8.46 per 1M training tokens across listed Llama, Gemma, MedGemma, and Qwen models	Model-specific prediction or deployment charges	Licence, region, accelerator, and endpoint availability vary
AWS Bedrock customisation	Model, region, and method specific	Provisioned throughput, storage, and inference can be separate	Public page requires provider selection; no single universal fine-tuning rate
Crusoe Serverless Fine-Tuning	Token-based per 1M tokens; exact public rate not confirmed	Self-serve deployment billed per GPU hour	Curated open models, LoRA, checkpointing; monthly and volume contracts optional
Microsoft Frontier Tuning	Public fixed price not confirmed	Tenant and deployment costs not fully public	Private-preview or engagement-based availability may apply
Thinking Machines Tinker	Public fixed price not confirmed	Serving and compute terms not fully public	Supports custom post-training and Inkling; verify access and export terms

Google currently publishes the clearest broad matrix. Its pricing page lists SFT at US$10 per million training tokens for Gemini 3.5 Flash, US$3 for Gemini 3.1 Flash Lite, US$25 for Gemini 2.5 Pro, US$5 for Gemini 2.5 Flash, and US$1.50 for Gemini 2.5 Flash Lite. Listed open-model rates range from US$0.28 for Llama 3.2 1B to US$8.46 for Qwen 3 14B. The page also states that tuned Gemini 3 endpoint prediction carries a 1.5 times base price, a recurring premium that can exceed the one-off training bill.

Google’s technical limits are equally important. Current documentation lists a 131,072-token maximum per training example, a 1 GB maximum JSONL training file, up to ten million text examples or 300,000 multimodal examples, and validation limits of 5,000 examples or a percentage-based cap in larger cases. Jobs can be created through the Cloud console, Google Gen AI SDK, Agent Platform SDK for Python, REST API, or notebooks. Text, image, document, audio, video, and function-calling datasets are supported for applicable models.

OpenAI’s remaining listed RFT route is priced by training hour rather than training tokens. Its current documentation lists o4-mini-2025-04-16 at US$100 per training hour, plus model inference charges. The access timeline makes this unsuitable as a new strategic dependency for organisations without prior activity. Existing users also need a migration plan before January 2027.

Crusoe’s July 2026 launch exposes a different product shape: a user interface, SDK, and API for LoRA fine-tuning across curated Qwen, DeepSeek, Gemma, and gpt-oss families, with checkpointing, early stopping, automatic recovery, lineage, portable safetensors weights, and OpenAI-compatible inference. Erwan Menard, Crusoe Cloud’s senior vice-president of product, said, ‘Open models have definitely crossed the quality threshold.’ The company states that pricing is token-based for training and GPU-hour based for deployment, but the announcement does not publish the actual rate. That uncertainty belongs in the procurement record, not in a guessed table.

Dr Will Leeney and Dr Hiskias Dingeto, AI researchers at StackOne, said their early experience with the same service ‘was seamless, and it worked like a charm’, while describing plans to use it to optimise agent latency and cost. This is a customer testimonial published in Crusoe’s launch announcement, not an independent benchmark, so it supports workflow usability rather than a general performance claim.

Evaluation: Proving the Model Improved

Training loss is a debugging signal, not proof of product value. It can fall while the model memorises training phrasing, loses general capability, becomes overconfident, or improves common cases at the expense of rare high-cost failures. Evaluation must therefore compare the tuned candidate with the exact production baseline across automated metrics, human judgement, operational behaviour, and safety.

Evaluation Layer	Example Metrics	Failure It Detects	Release Gate
Task quality	Macro F1, exact match, schema validity, pass rate, task success	Average gains hiding class or workflow failures	Predefined improvement on frozen set and critical slices
Human review	Blind pairwise preference, rubric score, escalation correctness	Metric gaming, poor tone, unsupported judgement	Reviewer agreement and no critical-policy regression
Reliability	Variance across seeds, retries, temperatures, and paraphrases	Brittleness and prompt sensitivity	Stable output within approved operating range
Safety and privacy	Refusal precision, harmful-completion rate, PII leakage, memorisation probes	Policy erosion and training-data exposure	No severe finding and documented residual risk
Operations	P50/P95 latency, tokens, throughput, GPU memory, cold start, error rate	A better model that cannot meet service constraints	SLO and budget met under representative load
Economics	Cost per successful task, annotation cost, hosting utilisation, migration cost	Cheap training masking expensive inference	Positive total-cost case at expected traffic

Accuracy needs a denominator and a consequence. The broader question of how accurate AI is shows why a headline percentage is not enough. A 95 per cent extractor can be unusable if the missing 5 per cent contains high-value invoices, minority languages, or legally sensitive fields. Report confidence intervals, class balance, slice performance, abstention behaviour, and the cost of false positives versus false negatives.

Hallucination evaluation also needs task-specific definitions. A tuned model may reduce formatting errors while increasing unsupported claims because examples reward fluent completion. Use the hallucination benchmark gap as a reminder that benchmark conditions and production conditions can diverge. For grounded tasks, verify every claim against supplied evidence. For closed-book tasks, separate factual accuracy from instruction compliance. For agents, score the entire trajectory, including tool choice, arguments, permission boundaries, and final answer.

Run ablations. Compare the full tuned system with the same model and prompt, the same prompt plus retrieval, a smaller tuned model, and a larger untuned model. Remove suspicious training subsets to see whether gains depend on duplicates or synthetic templates. Test multiple checkpoints because the final epoch is not automatically best. A model that peaks early and degrades later is signalling overfitting or excessive learning rate.

Human review should be blinded and rubric-based. Reviewers should not know which output came from the tuned model, and the rubric should describe observable criteria rather than asking which answer feels better. Adjudicate disagreements and inspect error clusters. Fine-tuning decisions become defensible when the team can show not only that the average score moved, but which behaviours changed and why those changes matter.

Performance Bottlenecks and Failure Modes

Most failed projects do not collapse because the optimiser is mathematically wrong. They fail because the dataset encodes an unclear policy, the model cannot represent the required change efficiently, the training job is under-instrumented, or the deployment environment differs from the evaluation environment.

Overfitting, Forgetting, and Rank Limits

Overfitting appears when the model learns training wording rather than the underlying rule. Symptoms include sharp training-loss improvement with flat validation performance, brittle responses to paraphrases, and high confidence on familiar templates. Catastrophic forgetting is the loss of useful base capability after aggressive updates. A narrow customer-service tune can make general reasoning, multilingual behaviour, or safety responses worse. Mix in representative general examples only when justified, lower the learning rate, reduce epochs, or use adapters to limit the update.

LoRA adds its own bottlenecks. Rank that is too low may not express a complex policy; rank that is too high increases memory and can lose regularisation benefits. Targeting only attention projections may miss feed-forward changes needed for the task. Quantisation saves memory but can introduce optimisation noise. Adapter fusion and multi-adapter serving can create cache pressure. The 2026 evidence suggests there is no universal best rank, which is why rank, target modules, alpha, dropout, and quantisation must be treated as measured hyperparameters.

Sequence Length and Data Pipeline Pressure

Memory use grows rapidly with sequence length because activations and attention states expand. Packing short examples improves utilisation, but careless packing can leak context across records or change loss weighting. Truncation can silently remove the label-bearing part of an example. Tokeniser mismatches can corrupt special tokens, tool-call syntax, or multilingual text. Validate token counts and inspect decoded samples before launching a long run.

Deployment Drift and Hidden Serving Costs

A model can pass offline tests and fail in production because the serving stack uses different quantisation, a revised system prompt, a new retrieval index, dynamic batching, or an updated base snapshot. Pin every component. Shadow production traffic and compare responses before switching. Monitor distribution drift in inputs, tool availability, refusal rates, and token length. Schedule re-evaluation when the source policy or base model changes, not only when users complain.

Model-internal diagnostics can reveal problems that output scoring misses. The Gaussian probing model audit provides an adjacent example of examining internal representations rather than relying only on surface behaviour. Production teams may not reproduce research-grade probing, but they can still use canary prompts, activation or embedding drift where supported, memorisation tests, and adversarial slices to detect changes before they become incidents.

The largest hidden cost is maintenance. A training run may last hours, but data adjudication, red-team review, endpoint capacity, incident response, model deprecation, and repeated regression testing continue for the life of the system. Budget by cost per successful task over a year, including people and infrastructure. A tuned model that saves two hundred prompt tokens but requires a dedicated under-utilised GPU can be economically worse than a larger API model.

Security, Privacy, and Model Governance

Fine-tuning expands the attack surface because training data can contain secrets, personal data, copyrighted material, prompt injections, backdoors, or malicious examples designed to trigger hidden behaviour. The resulting weights or adapters can themselves be sensitive intellectual property. Security must cover the dataset, training environment, artefact store, deployment endpoint, and the model’s behaviour.

• Data controls: Classify records, remove unnecessary personal data, scan secrets, verify licences, document consent or legal basis, and preserve deletion mappings.
• Access controls: Use least-privilege identities, private networking where required, encrypted storage, short-lived credentials, audit logs, and separation between annotators and production deployers.
• Supply-chain controls: Pin model revisions, tokenisers, libraries, containers, and custom code; verify hashes and licences; restrict remote-code execution.
• Behavioural controls: Test jailbreaks, prompt injection, data extraction, backdoor triggers, unsafe tool use, refusal erosion, and memorisation before release.
• Lifecycle controls: Maintain model cards, dataset cards, change logs, owners, expiry dates, rollback artefacts, deletion procedures, and provider migration plans.

Membership-inference and extraction tests should target the real data risk. Ask whether the model reproduces rare strings, account numbers, internal phrases, or long training passages under adversarial prompting. Canary secrets inserted into a controlled dataset can measure memorisation, but never use real credentials. For highly sensitive data, consider local or tenant-isolated training, differential privacy where appropriate, or abandoning fine-tuning in favour of retrieval with access controls.

Backdoors deserve explicit testing. An apparently clean adapter can learn a trigger that changes classification or tool behaviour. Scan training sources, compare gradients or performance across suspicious subsets, test rare tokens and formatting patterns, and require provenance for third-party adapters. Open weights improve inspectability and portability, but they do not make a model safe by default.

Governance should also recognise provider risk. OpenAI’s 2026 wind-down shows that a technically sound workflow can become unavailable through a lifecycle decision. Contracts should address exportability, retention, regional processing, model retirement, notice periods, and support for reproducing a tune elsewhere. Adapter portability, standard weight formats, and an independent evaluation harness reduce exit cost.

The 2026 Strategic Shift: From One Model to Learning Loops

The most important 2026 change is not a new fine-tuning algorithm. It is the shift from choosing one frontier model to operating a learning loop that can move across models. Microsoft, Crusoe, Google, AWS, and Thinking Machines are each packaging customisation differently, but the common enterprise demand is control over data, behaviour, deployment, and replacement.

Reuters reported that Microsoft launched Microsoft Frontier Company with US$2.5 billion to help businesses select and customise models. Judson Althoff, chief executive of Microsoft’s commercial business, said the company had made a mistake by ‘binding it to OpenAI models only’. The lesson is broader than Microsoft: a system tied to one model family cannot easily exploit new quality, cost, or sovereignty options.

Microsoft AI chief Mustafa Suleyman framed the pressure in cost terms during Microsoft Build 2026. In a Bloomberg interview reported by TNW, he said, ‘We pay a lot of money to Anthropic, so our goal is to reduce and ultimately eliminate that cost.’ The statement is strategic positioning rather than proof that an in-house or fine-tuned model is always cheaper, but it shows why customisation is increasingly judged against recurring token spend and margin.

Thinking Machines makes the opposite strategic bet. Its July 2026 Inkling release says the 975-billion-parameter mixture-of-experts model is not the strongest overall model, but is designed as a multimodal base for customisation through Tinker. Only 41 billion parameters are active per token according to its model information, and the weights are available for external use. This is a candid trade-off: customisability and ownership can be more valuable than topping every general benchmark.

Crusoe similarly emphasises portable LoRA weights, checkpoints, lineage, and OpenAI-compatible inference. Those details reduce switching cost because the organisation retains an artefact it can inspect and potentially serve elsewhere. The commercial weakness is price opacity at launch. A procurement team should request the actual token rate, minimums, GPU-hour prices, egress, support, and deletion terms before comparing it with a managed cloud or self-hosted cluster.

Three information-gain conclusions follow. First, access continuity is now a model-selection metric: an API can disappear even when the tune works. Second, adapter portability changes exit economics: safetensors, open base weights, and multi-adapter serving can prevent a custom behaviour from being trapped in one endpoint. Third, rank and model size are not purely quality knobs. A smaller tuned model may beat a larger general model on a stable task, while an excessively constrained adapter may fail a branching procedure that full tuning can learn.

The emerging architecture is therefore a portfolio. Use prompts for changeable instructions, retrieval for current facts, tools for deterministic actions, adapters for stable behaviours, and full tuning only when the task demands deeper weight changes. Keep an evaluation harness independent of every provider. That harness, not a vendor dashboard, becomes the organisation’s durable asset.

Choosing a Fine-Tuning Route

A final selection should start with the operating constraint rather than the brand. A regulated organisation may prioritise tenant isolation and regional processing. A start-up may need the lowest cost per successful task. A research team may need gradient access and custom algorithms. A product team may value a simple API and managed rollback. No route wins every dimension.

Choose a Managed Proprietary Service When

The organisation needs minimal infrastructure, the supported model already meets the base capability requirement, the data terms are acceptable, and the platform exposes enough evaluation, security, and lifecycle control. The main risks are access policy, model deprecation, limited weight export, and recurring inference premiums. OpenAI’s current wind-down makes new adoption impossible for many organisations, while Google offers a broader published training matrix and multimodal dataset support.

Choose Managed Open-Model Training When

The team wants open weights or portable adapters but does not want to operate GPUs. Crusoe, cloud marketplaces, and specialist platforms can remove cluster management while preserving more exit flexibility. Verify whether the adapter is exportable, whether the base licence permits commercial use, how checkpoints are retained, and whether inference can run outside the provider.

Choose Self-Hosted Training When

The organisation requires full control, has sustained GPU capability, or needs custom optimisers, losses, data pipelines, and model surgery. Self-hosting exposes every operational burden: drivers, kernels, distributed failures, checkpoint recovery, capacity planning, security patching, and serving optimisation. It is justified when control or utilisation offsets those costs, not because open-source software appears free.

Use a weighted scorecard across quality, data control, portability, model choice, time to first experiment, recurring inference cost, observability, regional availability, support, and deprecation risk. Require a proof with representative data and realistic traffic. A vendor demonstration using generic examples cannot establish whether the route fits the organisation’s hardest slice.

The balanced recommendation is to start small and preserve optionality. Fine-tune the smallest model that plausibly meets the requirement, keep the dataset and evals provider-neutral, store training manifests and hashes, and avoid product logic that depends on one provider-specific response format. The best fine-tuning programme is one that can stop, roll back, or migrate without losing the evidence behind its decisions.

Our Editorial Verification Process

This explainer was verified against current vendor documentation and primary announcements available on 29 July 2026. OpenAI’s supervised fine-tuning guide, pricing page, and deprecation timeline were cross-checked for access dates, supported examples, workflow stages, and o4-mini reinforcement fine-tuning rates. Google Cloud’s supervised tuning documentation and pricing matrix were used for token accounting, dataset limits, API routes, supported modalities, model prices, and the tuned-endpoint premium. AWS documentation was used to confirm that model customisation pricing varies by provider, model, region, and capacity rather than presenting one universal rate.

Technical explanations were cross-referenced with the original LoRA paper, Hugging Face PEFT and TRL documentation, and 2026 research comparing LoRA with full fine-tuning. Industry direction and named statements were checked against Reuters, Microsoft, Crusoe, and Thinking Machines sources. Internal links were selected from live, accessible Perplexity AI Magazine pages that are contextually relevant to data-science tooling, evaluation, hallucination, model auditing, sovereignty, infrastructure, and open-weight customisation.

No live fine-tuning job was run for this article, so the performance observations are not presented as an original benchmark. Vendor-reported claims are labelled as such, prices without a public numeric rate are marked unconfirmed, and platform details may change after publication. Editors should re-check pricing, access, and model lifecycle pages on the publication date.

This article was researched and drafted with AI assistance. The Sami Ullah Khan editorial desk at Perplexity AI Magazine must review it before publication; all data, citations, pricing figures, and named quotes were checked against primary sources during drafting.

Conclusion

Fine-tuning in AI is best understood as a way to make a stable behaviour persistent. It can turn demonstrations into reliable formatting, classification, domain language, tool selection, or task policy. It can also freeze mistakes into weights, weaken general capability, expose sensitive data, and create a dependency whose serving and migration costs outlive the training run.

The 2026 market makes those trade-offs unusually visible. OpenAI is winding down self-serve fine-tuning, Google publishes an expanding token-priced matrix, AWS retains model-specific customisation, Microsoft is investing in enterprise learning loops, and open-weight providers are competing on portability. The technical choice between SFT, LoRA, preference tuning, reinforcement methods, and full updates is therefore inseparable from provider lifecycle and data control.

The strongest operating principle is evaluation before optimisation. Build the frozen test set, exhaust prompt, retrieval, and tool-based baselines, then train the smallest informative candidate. Measure task success, safety, latency, cost, and slice-level regressions under production conditions. Preserve the dataset, manifests, checkpoints, and rollback route. Open questions remain around long-term adapter portability, reliable procedural learning at low rank, and how providers will price customised inference as models and accelerators change. Those uncertainties are reasons for optionality, not reasons to avoid fine-tuning altogether.

Frequently Asked Questions

What Is Fine-Tuning in AI in Simple Terms?

Fine-tuning teaches a pre-trained AI model a narrower behaviour by training it on examples of the inputs and outputs you want. Unlike prompting, the change is stored in model weights or an adapter and applies whenever that tuned version runs.

Is Fine-Tuning the Same as Training an AI Model?

No. Pre-training builds broad capability from very large datasets and compute. Fine-tuning starts from an existing model and adapts it with a smaller, targeted dataset. Full fine-tuning can still be expensive, while LoRA and QLoRA update a much smaller set of parameters.

How Much Data Is Needed for Fine-Tuning?

There is no universal number. OpenAI documents a minimum of ten examples and notes that some use cases improve with 50 to 100, but complex, multilingual, safety-sensitive, or tool-rich workflows may require thousands. Coverage, consistency, and held-out evaluation matter more than raw count.

When Should I Use RAG Instead of Fine-Tuning?

Use RAG when answers depend on current, private, changing, or citable knowledge. Fine-tuning is better for stable behaviour such as format, classification, style, or workflow policy. Many production systems combine a tuned model for behaviour with RAG for facts.

Does Fine-Tuning Stop AI Hallucinations?

Not by itself. Fine-tuning can reduce specific recurring errors if the dataset and evaluation target them, but it can also increase confident unsupported output. Grounding, retrieval, abstention rules, citations, tool checks, and task-specific hallucination tests are still required.

What Is LoRA Fine-Tuning?

LoRA freezes the base model and trains compact low-rank matrices that modify selected layers. It usually needs far less trainable memory and storage than full fine-tuning. Its main trade-off is that a low-rank update may not represent every complex behaviour.

How Much Does AI Fine-Tuning Cost in 2026?

Costs vary by provider and unit. Google lists roughly US$0.28 to US$25 per one million training tokens across selected open and Gemini models. OpenAI lists o4-mini reinforcement fine-tuning at US$100 per training hour for eligible existing users. Inference, evaluation, storage, and hosting are additional.

Can a Fine-Tuned Model Be Moved to Another Provider?

Sometimes. Open-weight models and exportable LoRA adapters can be portable, subject to licence and architecture compatibility. Proprietary managed fine-tunes may remain tied to one provider endpoint. Confirm weight export, adapter format, base-model access, and serving rights before training.

References

OpenAI. (2026). Supervised fine-tuning. OpenAI API documentation.

OpenAI. (2026). Deprecations: Update to self-serve fine-tuning. OpenAI API documentation.

Google Cloud. (2026). About supervised fine-tuning for Gemini models. Gemini Enterprise Agent Platform documentation.

Google Cloud. (2026). Generative AI pricing: Fine-tuning. Gemini Enterprise Agent Platform.

Hu, E. J., Shen, Y., Wallis, P., Allen-Zhu, Z., Li, Y., Wang, S., Wang, L., & Chen, W. (2022). LoRA: Low-rank adaptation of large language models. International Conference on Learning Representations.

Zindari, A., Mulayoff, R., & Stich, S. U. (2026). LoRA vs. full fine-tuning: A theoretical perspective. arXiv.

Nellis, S. (2026, July 2). Microsoft launches firm to help companies adopt AI with US$2.5 billion. Reuters.

Crusoe. (2026, July 7). Crusoe launches serverless fine-tuning and self-serve inference deployments. Crusoe Newsroom.

Wilson, C. (2026, June 4). Microsoft’s AI chief says the company wants to eliminate what it pays Anthropic. TNW.