THE 5-STAGE PIPELINE BEHIND EVERY LLM YOU HAVE EVER USED - Full Guide

Every time you type a message to Claude, GPT, or any other large language model, you are talking to the output of a five stage pipeline that took months, sometimes years, and tens to hundreds of millions of dollars to build.

Almost nobody outside AI labs actually understands these five stages. Most explanations either drown you in math you do not need or wave their hands at "training" like it is one single step. It is not. It is five distinct stages, each solving a different problem, each capable of failing in its own specific way, and each one explaining a different part of why the model in front of you behaves the way it does.

This is the complete breakdown. By the end you will understand exactly what happens between "a pile of internet text" and "a model that can hold a conversation," and why the stage a behavior comes from tells you exactly how to fix it if something goes wrong.

Why This Matters Even If You Never Train A Model

You do not need to understand this pipeline to use Claude or GPT well. But you do need it to understand WHY these models behave the way they do, and that understanding changes how you work with them.

When a model hallucinates a fact, that is a different failure than when it refuses a reasonable request, which is different again from when it gives a technically correct but unhelpful answer. Each of those failures traces back to a different stage in this pipeline. Knowing which stage produced a given behavior tells you whether better prompting can fix it, or whether you are running into a limitation baked in months before you ever opened a chat window.

This is also, increasingly, knowledge that pays directly. Fine-tuning open models, building evaluation systems, and designing training pipelines are among the highest paid specializations in AI engineering right now, and every single one of those jobs is built on the five stages below.

Stage 1: Data Collection and Preprocessing

Every LLM starts as a diet, and that diet determines almost everything about the model's eventual personality, knowledge, and blind spots.

The raw material is enormous. Common Crawl, a continuously updated scrape of a huge fraction of the public internet, Wikipedia, digitized books, code repositories, scientific papers, forum discussions, and increasingly, licensed data from publishers and specialized sources labs pay for directly. Frontier models today train on somewhere in the range of many trillions of tokens, a token being roughly three quarters of a word on average in English.

Collecting the data is the easy part. The actual work is in what happens next, and this is where most people's mental model of "AI training" is completely wrong. Labs do not just dump the raw internet into a model. They run it through an aggressive filtering and cleaning pipeline first.

Deduplication removes near identical content, since the same viral article copied across five hundred sites should not be counted five hundred times, both for efficiency and because oversampling duplicated content measurably degrades model quality. Quality filtering removes low value content, spam, auto-generated SEO pages, broken text, using both rule based heuristics and, increasingly, smaller classifier models trained specifically to score text quality. Toxicity and safety filtering removes the worst of the internet, extreme content that would actively harm the model's behavior if included, though a controlled amount of difficult content matters too, since a model that has never seen an argument cannot help you navigate one.

Deliberate composition mixing is the part almost nobody talks about publicly, and it is one of the most consequential decisions in the entire pipeline. Labs do not train on data in the proportions it naturally exists in on the internet. Code gets upweighted relative to its natural frequency, because code teaches structured, logical reasoning patterns that transfer to non-code tasks in ways researchers did not originally expect. High quality technical and scientific writing gets upweighted. Certain languages get upweighted or downweighted based on strategic priorities.

This stage is where a huge portion of a model's eventual character gets set before a single training step runs. A model trained disproportionately on Reddit discussions will have a different personality than one trained disproportionately on formal technical writing, even before any fine-tuning happens later.

The failure mode this stage causes. If a model consistently lacks knowledge about a specific domain, gives outdated information about something that changes, or shows a strange stylistic tic that shows up across unrelated topics, that is very often a data stage issue, not something prompting can meaningfully fix. You cannot prompt your way around information that was never in the training set.

Stage 2: Pretraining

This is the stage most people mean when they say "training an LLM," and it is the most computationally expensive part of the entire pipeline by an enormous margin, often representing the vast majority of total training cost.

The task is deceptively simple to state. Given a sequence of tokens, predict the next one. That is the entire objective. Feed the model "The capital of France is" and it should learn to predict "Paris" with high probability. Do this across trillions of tokens, adjusting billions or trillions of internal parameters with each batch, and something remarkable happens. To get good at predicting the next token across a genuinely diverse dataset, the model has to develop internal representations of grammar, facts, reasoning patterns, and even something resembling world models, because predicting the next token accurately in a huge range of contexts requires actually understanding what is being described.

The architecture underneath this is the Transformer, introduced in 2017, and its key innovation is the attention mechanism. Attention lets the model weigh the relevance of every other token in its context when processing any given token, rather than processing text strictly left to right with a fading memory the way older architectures did. This is why an LLM can correctly resolve that "it" refers to a noun mentioned several paragraphs earlier, something that was a genuinely hard problem before attention existed.

Pretraining runs on massive clusters, thousands of specialized chips, GPUs or custom silicon like Google's TPUs, running in parallel for weeks to months. The engineering challenge here is not just having enough compute, it is keeping thousands of chips synchronized, handling hardware failures gracefully across a run that might take months, and managing memory across models with more parameters than can fit on any single chip.

The result of pretraining alone is what is called a base model. It is extraordinarily knowledgeable and can complete text in remarkably sophisticated ways, but it is not yet what you would call an assistant. A raw base model, prompted with a question, is just as likely to continue your question with more questions as it is to answer it, because it was trained to predict plausible continuations of text, not to be helpful. This is the single most misunderstood fact about LLMs among people who have not built one. The thing that makes Claude or GPT feel like a helpful assistant is not pretraining. It is everything that happens after.

The failure mode this stage causes. Knowledge cutoffs come from here directly, a model only knows about the world up to whenever its pretraining data was collected. Certain reasoning weaknesses, particularly around genuinely novel problem types poorly represented in training data, also trace back to this stage, and no amount of clever prompting fully compensates for a gap in the base model's foundational capability.

Stage 3: Supervised Fine-Tuning

This is where a base model starts becoming an assistant, and the mechanism is far simpler than most people assume.

Researchers and hired annotators write out thousands of example conversations, showing exactly the kind of response a helpful, honest assistant should give to a huge variety of prompts. A question about how to fix a bug gets a clear, structured answer. A request for something harmful gets a polite decline. An ambiguous question gets a clarifying response instead of a guess. Increasingly, in modern pipelines, capable existing models are used to generate a large portion of these examples too, a technique often called distillation, with humans reviewing and curating the results rather than writing every example from scratch.

The model then gets fine-tuned on this curated dataset using the same underlying next-token-prediction mechanism as pretraining, just on a much smaller, much higher quality, much more deliberately curated set of examples. This is dramatically cheaper and faster than pretraining, sometimes taking days instead of months, because the model is not learning language and knowledge from scratch anymore. It already has all of that from pretraining. It is learning a specific behavior pattern, how to format helpful responses, on top of knowledge it already possesses.

This is the stage where a model's assistant personality actually gets built. Does it explain its reasoning step by step, or jump straight to conclusions? Does it ask clarifying questions when a request is ambiguous, or make its best guess and proceed? Does it format code with explanatory comments by default? Every one of these behavioral defaults was a deliberate decision made by the humans who curated the SFT dataset, not an emergent property of the base model.

The failure mode this stage causes. If a model consistently formats things in a way you find unhelpful, over-explains simple things, or under-explains complex ones, that behavioral default was set here. This is also, notably, a stage where good prompting genuinely can override the default, since you are asking the model to deviate from a learned pattern rather than asking it to know something it was never taught.

Stage 4: Reinforcement Learning From Human Feedback

This is the stage that took language models from "technically helpful assistant" to the genuinely useful, aligned systems people use daily, and it is also the most conceptually different from the first three stages.

The core problem RLHF solves is this. SFT teaches a model to imitate example responses, but imitation has a ceiling. A model trained purely on imitation can only get as good as its examples, and there is no mechanism for it to improve beyond that or to learn subtle preferences that are hard to demonstrate through examples but easy to recognize when you see two options side by side.

RLHF flips the approach from imitation to preference. Human raters, or increasingly an AI system trained specifically to model human preferences, get shown two or more responses to the same prompt and simply state which one is better. This is a much easier task than writing a perfect example from scratch, and it scales to a much larger volume of feedback as a result.

These preference judgments train a separate model called a reward model, whose entire job is learning to predict which of two responses a human would prefer. Once that reward model is good enough, the actual language model gets fine-tuned again, this time using reinforcement learning, generating responses, getting scored by the reward model, and adjusting to produce higher scoring responses over many iterations. The model is, in effect, practicing against a simulated human evaluator millions of times, something that would be completely impractical to do with actual humans at that scale.

Anthropic specifically pioneered a variant called Constitutional AI, where a written set of principles guides an AI system in critiquing and revising its own outputs, reducing the sheer volume of human labeling required while still producing an alignment signal that reflects a chosen, examinable set of values rather than an opaque aggregate of anonymous rater preferences.

This is also the stage most responsible for a model's safety behavior, its tendency to decline harmful requests, hedge on genuinely uncertain claims, and avoid confidently stating things it does not actually know. It is also, notably, the stage most likely to produce the specific failure researchers call sycophancy, a model learning that raters tend to prefer agreeable, validating responses, and over-optimizing toward telling people what they want to hear rather than what is accurate. Getting this stage right, avoiding both an overly restrictive model and an overly agreeable one, is one of the hardest open problems in the entire field right now.

The failure mode this stage causes. Overly cautious refusals of reasonable requests, a tendency to hedge excessively on things the model actually does know well, and sycophantic agreement with an incorrect premise the user stated confidently, all trace back to this stage, specifically to how the reward model was trained and what it learned to reward.

Stage 5: Deployment and Inference Optimization

The model exists now. This final stage is the one almost nobody outside infrastructure teams thinks about, and it is the difference between a model that works in a research paper and one that can serve millions of people at once, in a response that arrives in seconds rather than minutes.

A frontier model in its raw trained form can be enormous, sometimes hundreds of gigabytes of parameters. Running it as-is for every single request would be prohibitively slow and expensive at any real scale. This stage exists to solve that problem without meaningfully sacrificing the quality achieved in the previous four stages.

Quantization reduces the numerical precision used to store the model's parameters, from a high precision format down to a lower precision one, dramatically shrinking the model's memory footprint and speeding up computation, with a carefully managed, usually small, quality tradeoff. Distillation, in this context meaning something slightly different from the SFT usage above, involves training a smaller, faster model to mimic a larger one's behavior, producing models like Haiku that trade some raw capability for dramatically lower cost and latency, useful for the large fraction of real world tasks that do not need frontier-level reasoning. Caching stores and reuses computation across requests that share common prefixes, which is exactly the mechanism behind the steep prompt caching discounts you see in current API pricing. Batching processes multiple requests together on the same hardware simultaneously, dramatically improving the number of requests a given cluster of chips can serve per second.

This stage is also where the actual product experience gets built. Streaming responses token by token as they generate, rather than making you wait for the entire response to finish, is an inference-stage engineering decision, not a training decision. Tool use, the ability to call external functions, search the web, or execute code, gets wired in at this stage too, as does retrieval augmented generation, where relevant documents get fetched and inserted into the model's context before it generates a response, extending its effective knowledge beyond whatever was frozen into it during pretraining.

The failure mode this stage causes. Latency, cost, and availability issues live entirely here. A model giving a noticeably worse answer under a "fast" or "lite" designation compared to its full version is very often a deliberate distillation tradeoff, not a different training pipeline entirely. And when a model with a knowledge cutoff correctly answers a question about very recent events, that is this stage's retrieval mechanism doing the work, not the base model somehow knowing something from after its training data ended.

Putting All Five Stages Together

Here is the full pipeline in sequence, and why the order matters.

Data collection and preprocessing determines what the model could possibly know or reflect, before a single training step runs. Pretraining turns that raw material into a knowledgeable but undirected base model through next token prediction at enormous scale. Supervised fine-tuning teaches that base model the specific shape of helpful assistant behavior through curated examples. Reinforcement learning from human feedback refines that behavior further using preference signals at a scale imitation learning alone cannot reach, and is largely responsible for a model's safety and alignment characteristics. Deployment and inference optimization takes the finished model and makes it fast, affordable, and extensible enough to actually serve as a real product.

Each stage can only fix what the previous stage made possible. No amount of RLHF can teach a model a fact it never encountered in pretraining. No amount of clever fine-tuning can make a poorly quantized deployment fast. No amount of infrastructure optimization can fix a model whose base training data was thin in a domain you care about. Understanding which stage a given behavior traces back to is what separates someone who can diagnose why a model is behaving a certain way from someone who is just guessing at better prompts and hoping.

Why Understanding This Changes How You Use These Models

Once you actually see the five stages clearly, several things about using LLMs day to day stop being mysterious.

Why does asking the same question slightly differently sometimes produce a dramatically different answer? Because you are interacting with the SFT and RLHF layers, which learned patterns from specific phrasings of similar requests, and small wording changes can shift which learned pattern gets activated.

Why do models sometimes confidently state something false? Because pretraining optimizes for plausible continuation of text, not verified truth, and while RLHF pushes hard against confident falsehoods, it cannot fully eliminate a tendency baked in at the most fundamental training objective.

Why does a model sometimes refuse something completely reasonable? Because the RLHF stage trained a reward model to prefer caution on certain categories of request, and reward models, like any model, occasionally misclassify a genuinely benign request as belonging to a category it learned to be cautious around.

Why is a "smaller" or "faster" version of a model noticeably worse at hard reasoning tasks but nearly as good at simple ones? Because that model went through a distillation process at the deployment stage specifically designed to preserve the most commonly needed capabilities while shedding the more expensive, less frequently needed reasoning depth.

None of this is a criticism of the models. It is simply what building intelligence out of these five distinct, imperfect stages actually produces, and knowing this pipeline turns every one of these behaviors from a confusing quirk into an explainable, predictable pattern.

How Different Labs Actually Diverge

The five stages above are a shared skeleton, but the specific choices each lab makes inside that skeleton are where real competitive differences show up, and understanding those differences explains a lot about why different models genuinely feel different to use, beyond just raw benchmark scores.

Some labs invest disproportionately in the data stage, building larger and more aggressively curated proprietary datasets, licensing content directly from publishers rather than relying purely on open web scrapes, betting that data quality compounds more than any other single lever in the pipeline. Others invest disproportionately in scale, building larger models and bigger training clusters on the bet that raw parameter count and compute, applied to a good-enough dataset, wins out.

The RLHF stage is where philosophical differences between labs become the most visible in actual product behavior. A lab that weights safety and caution heavily in its reward model produces a noticeably more conservative assistant, more likely to decline ambiguous requests, more likely to hedge on uncertain claims. A lab that weights raw helpfulness and directness more heavily produces a model that takes more initiative and hedges less, at some cost to caution on edge cases. Neither approach is objectively correct, they represent different bets about what failure mode is worse, an assistant that is occasionally too cautious, or one that is occasionally too permissive, and reasonable people at different labs land in different places on that tradeoff.

The deployment stage is where the most product-visible differences show up day to day. The size and composition of a context window, how aggressively a lab distills its smaller models, how tool use and retrieval get integrated, all of these are deployment stage decisions that shape what a model feels like to actually build with, independent of the underlying model's raw pretrained capability.

This is worth internalizing because it means comparing models purely on a single benchmark number misses most of the actual story. Two models can score similarly on a standard evaluation while behaving completely differently in practice, because the benchmark measures capability from stages one through three well, but says almost nothing about the RLHF-driven behavioral tendencies or deployment-stage engineering that most affect how a model feels to use every single day.

What Is Changing In This Pipeline Right Now

The five-stage model above describes how frontier models have been built for the past several years, but the pipeline itself is actively evolving, and it is worth knowing where the current pressure points are.

Synthetic data is playing an increasingly large role at every stage, not just SFT. As the highest quality portions of the public internet get more thoroughly mined, labs increasingly generate training data using existing capable models, then filter and curate that synthetic output rather than relying purely on human-created content. This raises real, actively debated questions about a ceiling effect, whether a model trained heavily on another model's output can meaningfully exceed the teacher model's own capability, or whether this approach mostly transfers and compresses existing capability rather than creating genuinely new capability.

The line between stages three and four is blurring. Newer techniques like Direct Preference Optimization simplify the RLHF pipeline considerably, allowing a model to learn directly from preference pairs without training and maintaining a fully separate reward model, collapsing what used to be a more complex two-stage process into something closer to a single training run. This has made RLHF-style alignment meaningfully more accessible to teams without the resources of a frontier lab.

Test-time compute, the idea that a model can be given more computation at the moment it answers a question, thinking longer and more carefully before responding rather than only getting smarter through additional training beforehand, has emerged as a genuinely new lever that sits partly inside stage five and partly as something new entirely. This is the mechanism behind extended reasoning and effort-level settings in current frontier models, and it represents a real shift in where labs are investing marginal research effort, from purely making pretraining bigger toward making inference itself smarter and more deliberate.

Agentic capability, models that plan, use tools, and execute multi-step tasks autonomously, is increasingly trained as its own consideration threaded through every stage, rather than treated purely as a deployment-stage integration bolted onto an already-finished model. Data curation now specifically includes agentic trajectories and tool-use examples. RLHF increasingly rewards good process, not just good final answers, since a model that reaches the right answer through unreliable or ungrounded reasoning is a liability in an agentic context even when the final output happens to be correct.

None of this changes the fundamental five-stage skeleton described above. It changes how each stage gets executed, and understanding the skeleton is precisely what lets you follow these changes as they happen, rather than experiencing each new technique as an unexplained black box on top of an already-unexplained pipeline.

The Actual Skill This Unlocks

If any of the five stages above sound interesting enough to specialize in, here is the honest map of where the real, hireable skill lives in each one.

Data engineering for LLMs means building and running the filtering, deduplication, and quality classification pipelines that turn raw scraped data into training-ready datasets, a discipline that sits at the intersection of large scale data engineering and machine learning judgment.

Pretraining engineering is the most specialized and smallest job market of the five, requiring deep distributed systems expertise, and is concentrated almost entirely inside the handful of labs actually training frontier scale models from scratch.

Fine-tuning and RLHF is currently one of the most in demand and most accessible specializations for someone coming from a strong software engineering background without a research PhD, since it is where a huge amount of practical, applied work happens, adapting existing base models to specific domains and use cases.

Evaluation and alignment work, building the test suites and reward models that measure whether a model is actually behaving as intended, is an increasingly critical and increasingly well compensated specialization, since a model that has not been rigorously evaluated is a genuine liability at production scale.

Inference and deployment engineering is where classic infrastructure and systems engineering skill meets machine learning, optimizing serving costs, latency, and reliability at scale, and it is a discipline that transfers directly from general high performance systems engineering experience.

Pick the stage that matches what you already find interesting, and go build something in it. A small project that fine-tunes an open model on a specific domain, or builds a genuine evaluation harness for a task you care about, demonstrates real understanding of this pipeline in a way that reading about it never will.

The five stages are not five separate mysteries. They are one coherent pipeline, and once you can see all five clearly, every model you interact with stops being a black box and starts being a system you can actually reason about.

Follow @cyrilXBT for more deep technical breakdowns like this one.