Who Does What: Labs, Platforms, Builders
Lesson 2 of 3 in The LLM Lifecycle Map.
The four stages are not staffed by the same people. In practice the industry has sorted itself into three broad groups, and knowing which group you are in tells you which parts of this site are your job and which are context.
Labs train. Pre-training a frontier model takes a purpose-built data pipeline, thousands of accelerators running for months, and a team that has done it before — so only a small number of organizations in the world do it. The same organizations usually run post-training too, because shaping behavior requires access to the base model and to evaluation infrastructure built alongside it. Labs that publish Open weights checkpoints hand the later stages to anyone; labs behind Closed weights APIs keep serving in-house or delegate it to partner platforms.
Platforms serve. Cloud providers and inference companies run the trained model as a service: GPUs, batching, scaling, uptime, metering. They rarely change what the model is — they decide how fast, how reliably, and at what price it runs.
Builders adapt. Application teams take a served model and make it useful for one job: prompts, retrieval over their own data, occasionally a fine-tune, and the evaluation that proves it works. No frontier-scale capital required — which is exactly why this group is thousands of times larger than the other two, and why most readers of this site live here.
The borders blur — big clouds also train models, some labs run their own serving, and a builder who fine-tunes an open-weights model is doing a little of everything. But as a first map of the industry, the three groups hold up remarkably well.
| Stage | Who typically does it | Artifact produced | Cost shape |
|---|---|---|---|
Pre-training | Labs — a small number of organizations worldwide | A base model: a checkpoint of weights that continues text | Capital. One enormous up-front compute bill per model, amortized over its lifetime |
Post-training | Labs, plus teams who tune open-weights checkpoints | An instruction-tuned model — the assistant behind the API | Far less compute than pre-training, but heavy in human feedback data and specialist expertise |
Inference | Platforms — clouds and inference providers; or you, if you self-host | Tokens: every response every user ever sees | Opex, forever. Scales with every request and grows with success — the meter never stops |
Adaptation | Builders — application teams; most readers of this site | Your product: prompts, RAG pipelines, fine-tunes, and the glue around them | Mostly engineering time — plus the inference bill your design choices drive |
Evaluation & security | Everyone, at their own stage | Trust: evidence that the system works and resists abuse | Continuous — a practice you keep running, not a purchase you make once |
Read the cost column again, because it decides careers and budgets. Pre-training is capital: one giant bill, paid before anyone knows exactly how good the model will be — which is why so few organizations can afford the bet. Inference is opex forever: it starts small and grows with adoption, so a successful product’s serving bill eventually dwarfs almost everything else. This asymmetry explains an enormous amount of the field’s engineering energy — a single-digit efficiency gain in serving compounds across every future request, which is why the inference domain of this site exists at all.
For builders there is a subtler consequence: you inherit everything upstream. The Tokenizer and its quirks, the training data and its gaps, the Knowledge cutoff, the model’s Hallucination tendencies, the refusal behavior post-training installed — all of it was decided before you arrived. Adaptation can steer around these inheritances but cannot remove them. Knowing which stage a problem was born in tells you immediately whether you can fix it, work around it, or must switch models.
Interactive sorting exercise: Whose job is it? Sort each activity onto the group that typically does it.
In production
On the clouds, the lifecycle map turns into a responsibility boundary: how you consume a model decides which stages you merely use and which you now operate.
AWS
Consume a model through Amazon Bedrock’s managed API and the stages split cleanly: pre-training and post-training belong to the model provider, serving belongs to AWS, and your team owns adaptation and the evaluation of your own use case. Pull open weights onto your own infrastructure instead — Amazon SageMaker or self-managed GPU instances — and you inherit the inference stage whole: capacity, scaling, patching, and the security surface of the serving stack are now yours.
Azure
Azure AI Foundry makes the same boundary visible as a deployment choice in its model catalog: serverless, pay-per-token endpoints keep serving on Microsoft’s side of the line, while deploying a model onto your own managed compute moves the entire inference stage into your operational scope. Either way the training stages remain upstream — your levers are adaptation, evaluation, and the guardrails you configure around the endpoint.
Google Cloud
Vertex AI splits along the identical seam: call Google-hosted or partner models through managed endpoints and you operate only the adaptation layer, or take open weights from the model garden onto your own accelerators or GKE clusters and become your own serving platform. The rule generalizes across all three clouds: the further left on the map you reach, the more of the map you must staff.
Key terms: Base model, Instruction-tuned model, Checkpoint, Open weights, Closed weights
Interactive checkpoint quiz (1 questions) — open this page in a browser to take it.