- Foundation models are built in stages: pretraining teaches language and knowledge, instruction tuning teaches the model to follow instructions, and preference alignment (RLHF and its alternatives) shapes which of the responses it could give it actually gives.
- Each stage explains a behavior you observe at runtime: what the model knows comes from pretraining, its willingness to follow a prompt comes from instruction tuning, and its refusals and tone come from alignment, which constrains behavior without guaranteeing correctness.
- Enterprises almost never pretrain. Your leverage sits after the fact, in adaptation (fine-tuning, LoRA, distillation) and context (RAG), and those entry points are one to several orders of magnitude cheaper than the stages that came before them.
Why architects should know this
No enterprise architect I know has ever pretrained a foundation model, and almost none ever will. The budget, the data scale, and the cluster time belong to a handful of labs. So it is fair to ask why the training pipeline deserves a place in your mental model at all, when you will only ever meet the finished product through an API or a set of open weights.
The answer is that the pipeline is the cleanest available explanation of the behavior you actually deal with. Every property you care about at runtime was installed at a specific stage, and knowing which stage tells you whether you can change it. What a model knows was fixed during pretraining, which is why a knowledge cutoff exists and why retrieval, not fine-tuning, is the right fix for stale facts. Whether it follows your instructions at all was installed during instruction tuning. Why it refuses, hedges, and adopts that particular helpful register came from preference alignment. When a model does something surprising, the pipeline is your first diagnostic: which stage produced this, and can I reach that stage from where I sit?
That last question is the practical payoff. The pipeline is also a map of entry points. You cannot touch pretraining, but the later and cheaper stages are exactly where adaptation and context plug in, and the sequence tells you why a well-grounded prompt often beats a fine-tune, and why fine-tuning changes behavior far more reliably than it adds knowledge.
Pretraining: learning language
Pretraining is where a model learns language, and it is by a wide margin the most expensive thing that happens to it. The objective is deceptively simple: predict the next token. Given a span of text with the last piece hidden, the model guesses what comes next, its guess is compared to the truth, and the weights are nudged to be a little less wrong. Repeat that over a corpus measured in trillions of tokens, drawn from the open web, books, code, and reference material, and the guessing has to get good.
The reason this works is that predicting the next token well eventually requires modeling everything that shaped the text. To finish a sentence about thermodynamics, or close a bracket in a function, or continue a legal clause coherently, the model has to internalize grammar, facts, code structure, and a great deal of world knowledge, because those are what made the original next token likely. Nobody labels any of this; the supervision comes for free from the text itself, which is why the stage is called self-supervised and why it can consume corpora no human could ever annotate.
The scale is the whole story of the cost. A frontier pretraining run is commonly reported in the tens to hundreds of millions of dollars, running for weeks or months across thousands of accelerators. Those figures are illustrative and move fast, but the shape holds: this stage dwarfs everything downstream by orders of magnitude, which is precisely why the entry points that matter to you all sit after it.
BASE MODEL INSTRUCT/CHAT ALIGNED MODEL
+-----------+ +-------------+ +-------------+
| pretrain | --SFT | instruction | --RL/ | preference |
| next-tok | | following | DPO | aligned |
+-----------+ +-------------+ +-------------+
trillions of curated instr. ranked human
tokens, $$$$ response pairs comparisons
completes text follows prompts helpful+safe
| | |
most costly far cheaper cheaper still
What comes out of pretraining is a base model, and it is worth being precise about what that is. A base model is a superb text completer and a poor assistant. Ask it a question and it may continue with three more questions, because in its training data a question is often followed by more questions. It has the knowledge and the language; it has no idea it is supposed to answer you. Turning a completer into something that follows instructions is the job of the next stage.
Instruction tuning
Instruction tuning is the stage that turns a base model into something you would recognize as an assistant. Mechanically it is supervised fine-tuning: you assemble a dataset of instruction and response pairs, each a prompt paired with a high-quality answer of the kind you want the model to produce, and you continue training on them with the same next-token objective. The difference is entirely in the data. Instead of raw web text, the model now sees thousands to millions of curated examples of a request being answered well.
The effect is smaller than pretraining and more decisive than it looks. The model is not learning new facts here in any meaningful quantity; it is learning a format and a role. It learns that a question expects an answer rather than more questions, that a request for a list should yield a list, that instructions are things to be carried out rather than continued. The knowledge was already present from pretraining. Instruction tuning teaches the model how to surface that knowledge on demand, in the shape the user asked for.
This is the step that produces an instruct or chat model, the variant you almost always want when you pick a model off a menu. When a vendor lists a base model and an instruct model with the same parameter count, this stage is the difference between them, and it is why the instruct version follows a system prompt while the base version often ignores it. The data itself is the expensive part now, not the compute: high-quality instruction data is written or heavily curated by people, and its quality caps how well the resulting model behaves. Garbage demonstrations produce a fluently unhelpful assistant.
One thing instruction tuning does not settle is which of several acceptable answers the model should prefer. Shown a demonstration, the model learns to imitate it. But most real prompts admit many valid responses that differ in tone, caution, thoroughness, and honesty, and imitation alone gives you no lever over that choice. Ranking good against better, rather than right against wrong, is what the alignment stage adds.
Preference alignment
Preference alignment shapes which of the many responses a model could give it actually gives. The classic recipe is RLHF, reinforcement learning from human feedback, and it runs in two moves. First you collect comparisons: for a given prompt the model produces several candidate answers, and human raters rank them, saying this one is better than that one. Those rankings train a separate reward model whose only job is to score a response the way the raters would. Second, you optimize the assistant with a reinforcement learning algorithm to produce responses the reward model scores highly, while a penalty keeps it from drifting too far from the instruction-tuned starting point.
The subtle part is that alignment learns from preferences, not from demonstrations. Nobody has to write the ideal answer; they only have to say which of two answers is better, and comparing is far easier and more reliable than authoring. That is what lets alignment reach qualities that are hard to demonstrate directly, such as calibrated caution, a consistent tone, and a disposition to refuse genuinely harmful requests.
RLHF is powerful and fiddly, so the field has produced lighter alternatives. DPO (direct preference optimization) skips the separate reward model and the RL loop, optimizing directly on the preference pairs with a simpler objective, which many teams find more stable to run. RLAIF and constitutional approaches replace or augment the human labeler with an AI judge steered by a written set of principles, trading some human fidelity for enormous gains in scale and consistency. The details differ; the goal is shared. Every one of them is choosing among acceptable outputs, not teaching the model new facts.
This is also why two aligned models with similar raw capability can feel so different to use. They were tuned against different preference data and different principles, so they disagree about what a good answer looks like even when they agree about the facts.
Training reasoning models
Reasoning models add another training pass, and it is best understood as a distinct axis layered on top of the pipeline above rather than a replacement for any part of it. A model still gets pretrained, still gets instruction tuned, and typically still gets preference aligned. Then, on top of all that, it is trained specifically to think longer and better before it answers.
The mechanism that distinguishes this stage is reinforcement learning on verifiable rewards. Instead of a reward model standing in for human taste, the signal comes from tasks whose answers can be checked mechanically: a math problem with a known result, code that either passes a test suite or does not. The model generates a long chain of intermediate reasoning, the final answer is verified, and reward flows to the traces that reached correct answers. Over enormous numbers of attempts, whatever internal habits made verified answers more likely get reinforced, and the model learns to decompose problems, check its own work, and abandon dead ends.
The reason this needs its own stage is that ordinary alignment cannot supply the signal. Human raters can say which of two answers reads better, but they are slow and unreliable judges of whether a fifty-step derivation is actually right. A test suite is neither. Verifiable rewards give a clean, scalable, and honest training signal on exactly the tasks where longer thinking pays off, which is why reasoning training clusters around math, code, and structured logic rather than open-ended writing.
For the enterprise, the practical consequence is that reasoning is now a property you select at the model and request level rather than something you build. The economics of that choice, when the extra thinking tokens earn their cost and when they are waste, are a topic in their own right and are covered in the reasoning and test-time compute deep-dive. What matters here is simply where it sits in the pipeline: a separate optimization objective, stacked on an already-aligned model, that buys quality on checkable problems.
Where the enterprise enters
Now the payoff. Read the pipeline as a cost gradient and your options come into focus. Pretraining is closed to you, both because of its price and because the labs will not sell you a training run. Everything downstream is progressively cheaper and progressively more accessible, and that is exactly where the enterprise enters. You have two families of levers: adaptation, which changes the model's weights or a small set of them, and context, which changes what the model sees at inference time without touching weights at all.
The single most useful thing to internalize is that these entry points are cheap relative to what came before, not in absolute terms but in orders of magnitude. Fine-tuning a model is a modest engineering project; pretraining one is a moonshot. That gradient is why the default answer to almost every "can we customize this" question is yes, and it lives after pretraining.
| Pipeline stage | Enterprise entry point | What it changes | Relative cost |
|---|---|---|---|
| Pretraining | None (you consume the output) | Core knowledge and language | Prohibitive |
| Instruction / preference | Full or LoRA fine-tuning | Behavior, format, domain style | Moderate |
| Model selection | Distillation to a smaller model | Cost and latency at fixed task | Low to moderate |
| Inference time | RAG and context engineering | Facts and grounding, no weights | Low |
| Inference time | Prompting and system prompts | Behavior within existing limits | Negligible |
The ordering carries advice. Because knowledge lives in pretraining and you cannot reach it, the right tool for stale or proprietary facts is retrieval, not fine-tuning; RAG injects the facts at inference time and leaves the weights alone. Fine-tuning, covered in fine-tuning in practice, is the right tool when you need to move behavior, format, or domain register reliably, which is the thing weights are good at changing. Distillation is how you carry a capability down into a cheaper model. Reach for the cheapest layer that solves the problem, and climb only when it does not.
The architect view
Carry three things out of this. First, the pipeline is a capability map. When you evaluate a model, you are looking at the compounded result of pretraining, instruction tuning, and alignment, and you can reason about its strengths and gaps by asking which stage would have produced them. Weak on your niche domain? That is a pretraining data gap, and retrieval is your lever. Follows instructions unevenly? Instruction tuning. Too cautious or too eager to please? Alignment. Naming the stage tells you whether the fix is in your reach.
Second, the pipeline is a customization map, and it should reset where you look first. The instinct to fix everything by training the model is almost always wrong, because the stage that holds knowledge is the one stage you cannot touch. Most of what you actually need moves at the cheap end of the gradient: better prompts, retrieval that grounds the model in your data, and fine-tuning reserved for the cases where behavior genuinely has to change. Effort spent low on the ladder returns more than effort spent high.
Third, the pipeline is a risk map. Because alignment constrains behavior without guaranteeing correctness or security, you cannot outsource safety to the model's training, and none of the vendor's stages know anything about your data boundaries or your regulatory exposure. Those are yours to enforce, through evaluation, guardrails, retrieval scoping, and the privacy controls discussed in the model risk material. The model arrives helpful; it does not arrive compliant with your obligations.
The through-line is that the expensive, impressive part of making a model is the part you will never do, and that is fine, because it is also the part where you have the least to add. Your leverage sits entirely in the post-training world of adaptation and context, the last and cheapest stretch of a very long pipeline. Understanding the whole thing is what lets you spend your effort in the one place it compounds.