LLM training: the process, stages, and fine-tuning gritty details

The honest opening: most enterprise teams should not train an LLM. They should use one. Pre-training a foundation model from scratch is a $100M+ exercise reserved for OpenAI, Anthropic, Google, Meta, and a handful of state-funded labs. Even fine-tuning is the right call for fewer projects than the AI vendor narrative suggests — for most production workloads in 2026, retrieval-augmented generation reaches the same accuracy with less cost, less risk, and faster iteration.

But when training (or training-adjacent work) is the right call, knowing which stage to invest in matters. This article maps the four stages of LLM training as they actually show up in production engagements, with honest framing on which stages are worth your budget and which to skip.

What "LLM training" actually means in 2026

The phrase covers four very different activities that get conflated in vendor pitches:

1. Pre-training — the multi-month process of teaching a model language from massive corpora. Almost nobody outside the foundation-model labs does this.
2. Supervised fine-tuning (SFT) — adapting a pre-trained model to a domain or task on labeled data. Real, but increasingly replaced by RAG for most use cases.
3. Prompt tuning / parameter-efficient fine-tuning (PEFT) — lightweight techniques (LoRA, soft prompts) that update a small fraction of parameters. The practical middle ground for many enterprise needs.
4. Reinforcement learning from human feedback (RLHF) — aligning model outputs to human preferences. Mostly relevant for foundation-model providers; rarely the right investment for enterprise workloads.

The right question isn't "should we train an LLM?" — it's "which stage actually moves the metric we care about?" Below is the honest map.

Stage 1: Pre-training

Pre-training is the unsupervised (technically self-supervised) phase where a model learns language patterns, grammar, factual knowledge, and reasoning from massive text datasets — books, articles, code, web crawls. The model is taught to predict the next token across billions of examples, with internal weights adjusted via gradient descent across thousands of GPUs running for weeks.

The compute cost alone runs into eight or nine figures for frontier models. Data acquisition, cleaning, deduplication, tokenization, and safety filtering add another layer of expense. Carbon footprint is non-trivial.

Who actually pre-trains? OpenAI, Anthropic, Google DeepMind, Meta, Mistral, xAI, a handful of Chinese labs (Alibaba, DeepSeek, Baidu), national AI initiatives (UAE's Falcon, Korea's HyperCLOVA), and the open-source community (EleutherAI, Allen AI). Roughly 30 organizations worldwide have the budget and infrastructure to pre-train at frontier scale. Outside that list, pre-training from scratch is almost always the wrong investment.

When it's actually right for enterprises: continued pre-training on a private corpus that's both massive and highly differentiated (multi-billion-token domain corpora — pharmaceutical research databases, regulated financial archives, government intelligence). Even then, the right partner is usually a foundation-model lab co-investing on the project, not an attempt to build a new lab from scratch.

For everyone else, the foundation models — Claude, GPT, Llama, Mistral, Gemini — are the starting point, not the target.

Stage 2: Supervised fine-tuning (SFT)

Fine-tuning takes a pre-trained model and adapts it to a specific task or domain on a smaller labeled dataset. The model parameters get updated based on the task examples, so domain vocabulary, response style, and task-specific reasoning move into the weights.

When SFT is actually worth it:

• Latency budget is tight (~100ms p99) and you need the domain knowledge baked into the model so prompts can stay short
• The task is narrow, stable, and well-defined (sentiment scoring on a specific customer base, contract clause extraction in one jurisdiction, ticket routing for one product)
• You have 10K+ high-quality task examples — the labeled dataset that fine-tuning quality lives or dies on
• The compliance requirement is tight enough that data residency rules out hosted models, and a small fine-tuned model on customer infrastructure is the only viable path

When SFT isn't worth it (most enterprise cases now):

• The knowledge changes faster than retraining cycles
• Source documents need to be auditable / cited — fine-tuning bakes them in opaquely
• Labeled data is below 5K examples — too few to fine-tune well, better to start with retrieval and iterate
• The workload spans multiple loosely related tasks — a single fine-tuned model degrades, while RAG handles the breadth

In our engagements over the last two years, the SFT-vs-RAG decision has shifted decisively toward RAG. The pattern that wins on most regulated workloads: fine-tune the embedding model for domain vocabulary (high leverage, low cost), then layer RAG on top. Fine-tuning the generation model is reserved for the narrow cases where it's genuinely the right tool.

What fine-tuning actually delivers, when it's right

When SFT is the correct choice and executed well, four real outcomes:

1. Domain-accurate outputs. A general model gives vague answers to domain queries; a fine-tuned model uses the right terminology and respects domain conventions. Critical for legal, medical, technical writing.
2. Reduced prompt overhead. Fine-tuned knowledge lives in the weights, so prompts stay short. At high query volumes, that translates to real cost savings.
3. Compliance-ready behavior. Fine-tuning on policy-aligned outputs (HIPAA-conformant phrasing, refusal patterns, regulatory disclaimers) bakes safety into the model rather than relying on prompt patches.
4. Operational efficiency. Tighter outputs, fewer retries, less post-processing. Cumulative effect on production cost and quality at scale.

Cost framing for honest planning: fine-tuning a 7B–13B small language model for a narrow workload typically runs $20K–$80K including data prep, infrastructure, and evaluation. Fine-tuning a frontier-class model (70B+) runs $100K–$500K+ depending on data volume and compliance load.

Stage 3: Prompt tuning and parameter-efficient fine-tuning

Between full fine-tuning and prompt engineering sits a family of lightweight adaptation techniques: prompt tuning (soft prompts), LoRA (low-rank adaptation), prefix tuning, and the broader PEFT family. These update only a tiny fraction of model parameters — typically <1% — and produce adapter weights that can be swapped at inference time.

Why this matters in production:

• Cost. PEFT runs at a small fraction of full fine-tuning cost — typically thousands rather than tens or hundreds of thousands.
• Iteration speed. Adapters train in hours or days, not weeks.
• Multi-task reuse. A single base model can serve multiple PEFT adapters, swapping them per task. Memory footprint stays manageable.
• Non-destructive. The base model stays unchanged. If an adapter doesn't pan out, you discard it without affecting other tasks.

For most enterprise workloads where some weight-level adaptation is genuinely needed but full SFT is overkill, LoRA on a 7B–13B SLM is the practical choice. It's also the technique that pairs cleanly with RAG — the SLM provides the reasoning layer, LoRA adapters carry domain vocabulary, and RAG provides current factual grounding.

Stage 4: Reinforcement learning from human feedback (RLHF)

RLHF is the alignment phase. After pre-training and supervised fine-tuning, the model still produces outputs that are technically valid but unhelpful, factually wrong, or unsafe. RLHF adjusts the model based on graded human preferences — humans rank multiple outputs for the same prompt by helpfulness, truthfulness, and harmlessness; a reward model learns the ranking; the LLM gets fine-tuned against the reward model's signal.

This is how foundation-model providers turn raw GPT, Claude, or Llama into the assistants enterprises actually use. The capability difference between "GPT-4 base" and "GPT-4 with RLHF" is enormous — RLHF is the polish that makes a model usable.

Should an enterprise do its own RLHF? Almost never. The data labeling alone (tens of thousands of ranked output pairs, graded by trained labelers) costs as much as a full fine-tuning project. The foundation-model providers have already done the heavy lift. Constitutional AI methods, automated reward modeling, and direct preference optimization (DPO) are reducing the cost, but they're still substantially expensive and operationally complex.

When it's the right call: when your workload requires alignment that the foundation model's RLHF doesn't cover — highly regulated content categories, very specific tone requirements, or domain-specific helpfulness that crosses into safety territory (medical advice, financial recommendations, legal phrasing). In those cases, expect to budget $100K+ for the RLHF stage alone, and treat it as a long-running iterative project, not a one-shot.

A real engagement: GenAI sales training platform

A US-based startup partnered with us to build an AI-driven onboarding platform for sales representatives. The conventional approach — senior managers spending months mentoring each new hire — didn't scale and burned senior bandwidth. The target was a platform that could turn static documentation into dynamic personalized training, assess each hire's baseline, and deliver real-time interactive support.

The architecture combined several training-stage techniques:

• Custom ingestion pipeline. Bespoke Python tooling to convert PDFs, slide decks, spreadsheets, audio files, and meeting transcripts into structured documents.
• RAG for current grounding. Embeddings + vector store over the ingested corpus, retrieved at query time. Knowledge updates required no retraining.
• Fine-tuned generation models. GPT-4 and Mistral 7B fine-tuned on domain-specific sales content for tone, accuracy, and pedagogical structure.
• RLHF for output quality. Lesson outputs ranked by quality and pedagogical value, with the reward signal feeding back into the generation model.
• Personalization layer. Resume parsing for baseline assessment, individualized learning paths, multi-format quizzes, and live AI-powered sales-scenario simulations.

Outcomes: onboarding timeline reduced from six months to two weeks. Senior managers no longer carrying repetitive training load. Each new hire on a personalized data-driven learning path. The platform improves over time as the feedback loop refines the models.

The architectural pattern — RAG + LoRA fine-tuning + targeted RLHF on a narrow output dimension — is the playbook we use most often when training-adjacent work is genuinely required. Pure RAG handles the broader knowledge surface; fine-tuning handles tone and domain accuracy; RLHF handles output quality on the specific dimension that matters (in this case, pedagogical effectiveness).

How to decide what your project actually needs

A practical decision tree we run on engagements:

• Knowledge-grounded Q&A on a corpus that changes regularly? RAG. Skip training entirely.
• Narrow stable task, latency-critical, 10K+ labeled examples? Fine-tune a small language model.
• Need domain vocabulary or tone, but not new factual knowledge? Fine-tune the embedding model and/or apply LoRA on a small base.
• Output quality on a specific dimension matters more than the model can deliver? Targeted RLHF or DPO on the relevant dimension only.
• Need alignment that foundation models don't provide? Custom RLHF — long, expensive, treat as multi-quarter project.
• Want a brand-new foundation model? Almost always wrong. Partner with an existing lab or use open-source bases.

For deeper treatment of the cost economics of these decisions, see calculating the cost of generative AI and our fintech RAG architecture reference for how this plays out specifically in regulated finance.

FAQ

Why is large data volume important for LLM training? Volume captures language variety (vocabulary, styles, contexts), enables generalization across tasks the model wasn't explicitly shown, prevents memorization of training examples, surfaces rare patterns and idioms, and helps disambiguate meanings via varied context. The trade-off is cost — more data means longer training runs and higher compute spend. The right volume depends on the stage: foundation pre-training needs trillions of tokens; supervised fine-tuning typically needs 10K–100K high-quality examples; PEFT can work with 1K–5K.

What are the main challenges in training LLMs on proprietary data? Catastrophic forgetting (model loses pre-trained knowledge when fine-tuned narrowly — mitigated by LoRA and regularization); overfitting on small datasets (memorization vs generalization — mitigated by careful eval set design); data quality and bias (fine-tuning amplifies what's in the training set, including its flaws); resource intensity (even PEFT needs GPU time); and reproducibility (small data or code changes produce divergent outcomes — mitigated by experiment tracking, versioned datasets, and deterministic training pipelines).

Should our enterprise build its own foundation model? Almost certainly not. Pre-training a frontier-class model is a $100M+ exercise with years-long timelines and ongoing maintenance cost. The foundation models that already exist — Claude, GPT, Llama, Mistral, Gemini — provide a starting point that's economically inaccessible to replicate. The right enterprise investment is at the fine-tuning, PEFT, or RAG layer on top of an existing foundation model.

RAG or fine-tuning — which should we do first? Almost always RAG first. It ships faster, costs less, and produces a working system you can iterate on. Fine-tune only when RAG hits a specific limit you can name — latency, prompt-length cost at scale, or domain vocabulary that retrieval alone doesn't fix. The decision is workload-specific, not philosophical. For deep treatment, see our RAG vs fine-tuning analysis.

---

Ready to scope an LLM training or fine-tuning project? Run the Project Estimator for a deterministic ballpark, or book a 45-minute Discovery with our GenAI engineers — we'll help you decide whether your project actually needs training, RAG, or a hybrid.