Course I — How Language Models Learn · Module 1 — From Text to a Learning Problem · Unit 1

The Model Lifecycle

Central question

What are the distinct stages that turn source material into a model that can answer a request, and what changes at each stage?

Suppose an engineer says, “We deployed the model.” This sounds precise until a failure occurs. Which model was deployed: a new architecture, a new set of learned numbers, a converted file, or the same files behind a different system prompt? Did anything learn, or did the serving configuration merely change?

This unit builds a map for answering those questions. It does not yet explain how the model learns. Instead, it tracks four properties across the whole lifecycle:

1. what enters a stage;
2. what operation takes place;
3. what the stage produces;
4. whether the learned model parameters change.

That last property is the main landmark. Training changes learned parameters. Ordinary inference uses fixed learned parameters to produce an output. Evaluation produces evidence about a candidate. Deployment makes a selected candidate available through an operational system.

The lifecycle presented here is a conceptual map assembled from publicly documented systems, not an industry standard. Real organisations rename, combine, repeat, or omit stages. The map is useful precisely because reality is messier than the phrase “train and deploy a model” suggests.

Which “model” did we deploy?

In ordinary conversation, model is an overloaded word. That compression is usually harmless. It becomes expensive when two people discuss different objects while using the same noun.

An architecture family or design defines a general pattern of computation and connections between parts. The Transformer described in Attention Is All You Need, for example, is an architectural design. A model configuration records choices that instantiate such a design. Some configuration choices, such as the number of layers, alter the concrete computation and are reasonably described as architectural changes while remaining inside the same broad family. These terms overlap in real engineering usage; neither identifies the numerical values learned from data.

Those values are the model parameters. For this unit, a parameter is simply a number that training can change and inference can use. Later units will show how parameters are organised and changed; for now, their mutability is enough.

A checkpoint is a point-in-time serialisation of defined state. A training checkpoint may contain much more than learned parameters because it must allow a run to continue. The PyTorch saving and loading guide shows this distinction concretely: parameters can be saved for inference, while a general checkpoint may also include training-resumption state, such as run progress and other state required to continue. This is one framework's documented convention, not a universal directory format.

A model artefact is the versioned material prepared for a target runtime. It commonly includes selected parameters, model configuration, text-processing assets, metadata, and compatibility information. A deployed service is broader still: it combines an artefact with an inference runtime, hardware, routing, access control, prompts or policies, and observability.

Course-authored visual 1. What should you notice? One phrase refers to six related but non-equivalent objects. These rows are not strict containment levels: a checkpoint may be converted, and a service loads or refers to an artefact rather than simply containing every earlier object unchanged.

Changes can propagate across rows: a new configuration may require new parameter shapes, checkpoints, and artefacts. The objects remain conceptually distinct even when one change forces several coordinated updates.

Pause and classify: if only the system prompt changes, which row changed? Which row did not necessarily change?

The software-build analogy helps only at the last two rows. Artefacts can be versioned, promoted, rolled back, and deployed. Training itself is not compilation: a compiler transforms source according to defined rules, whereas training searches for numerical parameter values using data and a learning procedure. The analogy provides release discipline, not semantic determinism.

The lifecycle as a sequence of state changes

The shortest lifecycle description is:

prepare data -> pre-train -> [optionally mid-train] -> post-train
             -> evaluate and select -> package -> deploy -> infer

This line is convenient but incomplete. At least three kinds of artefact move through the process:

• candidate source material is collected and transformed under explicit collection and governance decisions, then assigned different data roles;
• model state changes through successive training stages and checkpoints;
• evidence accumulates until a candidate is selected, packaged, and operated.

Prepared text becomes token sequences before it enters model training. A token is a processed unit of text; Unit 2 opens this boundary and explains how tokens are constructed. Here, the phrase exists only so that the data hand-off has a name.

Course-authored visual 2. What should you notice? Data, model state, and evidence or service artefacts follow different paths. Training changes model state. Evaluation observes candidates and creates evidence. Deployment and inference operate a selected release. Read each row from left to right before comparing the rows vertically.

Two feedback paths keep this from being a waterfall. Evaluation evidence can change the data, configuration, or plan for a later experiment. Permitted and appropriately handled production observations can inform a future evaluation, service change, or model version; they do not imply that each request immediately trains the deployed model.

This programme treats lawful sourcing, documented collection decisions, role separation, and useful provenance as responsible-engineering requirements. Their presence and public visibility vary across real model projects, so the map does not pretend that every published system exposes a complete manifest.

Pause and classify: an evaluation run receives a fixed candidate and held-out cases. What does it output, and does the measured candidate's learned state change during the measurement?

Pre-training creates a base model

Pre-training is the broad, high-compute stage in which a model acquires general language-prediction capability from a large corpus. Its output is usually called a base model. A base model can generate text, but it has not necessarily received the complete behaviour-shaping process expected of an assistant product.

Public model reports make the distinction observable. The OLMo 2 report releases trained weights, training data, code, logs, and intermediate checkpoints, while the Llama 3 report distinguishes pre-trained and post-trained releases. These are documented examples, not proof that every laboratory uses identical stages or artefacts.

Mid-training is optional vocabulary

Some projects identify an intermediate phase called mid-training. It begins from a broadly pre-trained checkpoint and changes the curriculum, capability emphasis, or supported context regime before behaviour-focused post-training. OLMo 2 uses the term for a specialised late-stage data mixture. The MAI-Thinking-1 report uses it for reweighted technical data and longer-context phases.

The term is neither mandatory nor universally defined. Another report may call a similar operation continued pre-training, late-stage curriculum, or annealing, or may divide the phases differently. In this programme, mid-training is useful as an optional position on the map, not as a law of nature handed down on a stone accelerator.

Post-training shapes behaviour

Post-training is an umbrella for further parameter-changing procedures starting from a base model. Depending on the project, it can use demonstrations, preference comparisons, reward signals, specialist tasks, or several of these in sequence. It is not synonymous with one algorithm, and it does not merely append a table of correct answers.

The historical InstructGPT report documents one concrete sequence: supervised fine-tuning—further parameter-changing training from an existing model—training a reward model from human preferences, and reinforcement learning. OLMo 2 and Llama 3 document different recipes. The general conclusion is therefore modest: post-training can itself contain multiple datasets, candidate models, and evaluations. The precise recipe is system-specific.

Evaluation is not one terminal stage

An evaluation applies a defined protocol to a particular candidate and produces evidence. That evidence can guide data choices, compare experiments, select checkpoints, or support a release decision. The candidate being measured normally remains fixed during that evaluation; acting on the result may later initiate another training run.

Evaluation is conditional. A result belongs to a model version, a set of scenarios, a way of presenting inputs, a method for producing outputs, and one or more metrics. The Holistic Evaluation of Language Models project made this explicit by evaluating many scenarios with multiple metrics, including accuracy, robustness, fairness, toxicity, and efficiency. Its larger lesson is not that these are the only valid metrics. It is that a single score cannot stand in for every capability, limitation, or risk.

The test-suite analogy helps with repeatability and regression detection. It fails as a proof metaphor. Software tests are incomplete too, but a model's possible inputs and acceptable behaviours are especially difficult to specify exhaustively. A benchmark score is evidence under a protocol, not a certificate of semantic correctness.

Trace one capability: the duplicated order

Consider the question:

Why can automatically retrying a non-idempotent HTTP POST create duplicate orders?

Following the semantics of RFC 9110, Section 9.2.2, an operation is idempotent when multiple identical requests have the same intended effect on the server as one such request. Incidental effects and responses can still differ. An order-creation request is often non-idempotent: if the first request succeeds but its response is lost, a blind retry may create a second order unless the system has a deduplication mechanism.

The following trace is invented teaching material. It is not a claim about the training data of OLMo, Llama, MAI, GPT-3, InstructGPT, or any other named model. It follows one subject through the lifecycle while deliberately using different records at different stages.

Course-authored visual 3. What should you notice? Related concepts can appear in source material, post-training tasks, held-out evaluations, and user requests without one literal record travelling through every stage. The final column remains the quickest way to distinguish training from everything around it.

The separation between records matters. If the evaluation case is copied from training data, a strong result may reflect exposure rather than the capability the test was intended to measure. A held-out case is kept outside the relevant training data to reduce this problem. The GPT-3 report's contamination analysis documents why overlap is a material evaluation concern while also showing that public web-scale data makes perfect separation difficult to guarantee.

The example also blocks the database analogy. The capability does not require one labelled answer to be stored at a known address. Training changes many parameters across many examples; later units will explain the numerical mechanism. This unit makes only the lifecycle claim: the source data, learned state, evaluation evidence, release artefact, and production response are different things.

Suppose the production response is poor. The immediate fix might be a clearer system prompt, a retrieval source, a routing change, or a rollback. None of those operations necessarily changes learned parameters. Alternatively, the failure might become a new evaluation case or motivate responsibly curated data for a future training run. The later run would produce a new model version; the original request did not silently rewrite the deployed one.

Training and inference are different systems

Training and inference execute related model computation, and they may share libraries, kernels, hardware types, or even code. They nevertheless have different jobs.

A training system is driven by datasets and a run plan. It maintains mutable model state and other training-resumption state, measures numerical progress, and emits checkpoints and metrics. A failure-recovery strategy must restore enough state for the run to continue coherently.

An inference system is driven by requests. It loads selected parameters, produces responses, and manages service concerns such as latency, throughput, availability, and per-request state. The vLLM serving paper focuses on request batching and memory management precisely because high-throughput inference is an engineering problem in its own right. Those internals belong later in the programme; their presence here establishes the system boundary.

Ordinary inference does not update learned parameters. A prompt changes the input context and therefore may change the response, but it does not normally teach the model permanently. The GPT-3 report states this boundary unusually clearly: its few-shot tasks supplied examples through text interaction without changing learned parameters or running an additional training stage. A product may separately store user memory, retrieve documents, or implement an explicit learning pipeline, but those are additional system behaviours—not evidence that every request retrains the model.

Deployment is different again. It is the process that places or updates a model artefact within the operational inference system. A service can be deployed and idle; one deployment can serve many inference requests. Changing only routing or a system prompt may require a deployment while leaving the learned parameters untouched.

This distinction explains why “the model behaved differently” is not yet a diagnosis. The cause could be different parameters, a different model configuration, a converted artefact, a changed prompt, a retrieval result, a tool, a safety policy, a router, or the inference runtime. A reproducible behavioural comparison therefore needs both the identity of the model artefact or model release and the relevant service version or deployment configuration. Model version should not silently absorb every operational choice.

From the source video to the programme

The source video and the MAI-Thinking-1 report begin deep inside this map. The report publicly documents one particular system with pre-training, two mid-training phases, several reinforcement- learning climbs, evaluation suites, checkpoint and recovery machinery, and separate training and inference infrastructure. It does not establish a universal lifecycle, and it does not reveal every organisational hand-off, staffing decision, approval gate, or private operating procedure.

For now, the video's advanced terms only need addresses:

Course I explains how learning can change numerical parameters. Course II examines data, experimental decisions, post-training, and evaluation. Course III examines the hardware and distributed systems that make the stages operate at scale. The map comes first so that later detail has somewhere to attach.

What this model leaves out

The lifecycle map is intentionally cleaner than the work.

First, development is not a waterfall. Teams run smaller experiments, compare branches, reject candidates, resume checkpoints, and revise data. Evaluation feeds back into those decisions. Production observations can also inform a future evaluation set, service change, or model version.

Second, stage boundaries are porous. Reinforcement-learning post-training, for example, can alternate response generation, scoring, and parameter updates. That does not invalidate the distinction between inference and training; it means an inference-like operation can appear inside a larger training system. Ask whether the encompassing procedure eventually updates learned parameters.

Third, terminology varies. Mid-training is optional and non-universal. Fine-tuning is also broad, and different organisations apply the term to different phases. Name the data and operation when precision matters.

Fourth, the model service is not just learned parameters. Prompts, retrieval, tools, filters, routing, conversion, and runtime behaviour can all affect what the user observes. Conversely, a training checkpoint can contain state that a service never needs.

Finally, public reports have a hard evidence boundary. They can document architectures, datasets, training phases, evaluation protocols, software, and hardware. Unless disclosed, they cannot tell us exact team sizes, internal ownership, release deliberations, complete data lineage, or private production topology. “Unknown from public evidence” is part of an accurate technical map, not an invitation to manufacture a suspiciously exact answer.

Recap

Source material does not become a chatbot in one operation. Data preparation turns candidate sources into prepared datasets with assigned roles and whatever provenance is available. Pre-training changes parameters and produces a base model. Optional mid-training continues that process with a changed emphasis. Post-training further changes parameters to shape behaviour. Evaluation produces conditional evidence and influences decisions throughout development. A selected checkpoint is packaged as an artefact, deployment makes it an operational service, and inference uses its normally fixed parameters to answer requests.

Whenever the model becomes ambiguous, ask: architecture, configuration, parameters, checkpoint, artefact, or service? Whenever a lifecycle stage is ambiguous, ask: what entered, what happened, what came out, and did the learned parameters change?

Check for understanding

1. A training checkpoint contains learned parameters and state required to resume a run. A production package contains selected parameters and runtime assets. Why are both sometimes called the model, and why is that dangerous during incident analysis?
2. A team changes only the system prompt and redeploys its service. Which lifecycle objects changed, and which did not necessarily change?
3. An evaluation result causes a team to add data and begin another training run. At which point were the measured candidate's parameters fixed, and at which point did parameters begin changing again?
4. A benchmark improves substantially, but user complaints do not. Give two possible explanations, naming the affected lifecycle object or evidence boundary in each.
5. In the duplicated-order example, why should the post-training demonstration, held-out evaluation case, and production request be related but distinct records?

Estimated study time: 75 minutes