How LLMs are actually built — and why most "how it works" threads stop too early

afa-lizhao001 — Sat, 17 Oct 2026 04:25:39 +0000

Most "how LLMs work" explainers end at transformers and attention.

The parts that decide whether a model is actually good — the data pipeline, the post-training recipe, the evaluation setup, the systems work — usually get one sentence. Having watched a lot of talks on this, I wanted a version I could check rather than trust, so I turned Yann Dubois' Stanford CS229 guest lecture (Building Large Language Models, Summer 2024) into a small, timestamped reference.

It's now an installable agent skill, but the map is useful on its own. Here it is.

Five components, and who actually optimizes which

Component	What it decides	Who pushes it
Architecture	capacity and shape	academia
Training objective	what "good" means during training	academia
Data	what the model has seen	industry
Evaluation	whether you can tell it improved	industry
Systems	whether training finishes at all	industry

The uncomfortable conclusion from the lecture: architecture is where academic attention goes, and it's not where the practical leverage is.

Pretraining: compressing the internet

"Just train on the internet" hides the actual work. A real pipeline looks like this:

Crawl — Common Crawl: ~250B pages, ~1 PB.
Extract — HTML to text. Random pages are menus, footers, and truncated sentences.
Filter — NSFW, harmful content, PII. Blacklists plus small classifiers.
Dedupe — boilerplate, the same page under many URLs, paragraphs repeated thousands of times.
Heuristics — odd token distributions, strange word lengths, too short, too long.
Model-based filtering — train a classifier on sites linked from Wikipedia vs random web; prefer the former.
Mix — up-weight code and books, down-weight entertainment. More code measurably helps reasoning.
Final phase — high-quality data with a decaying learning rate; effectively overfitting on Wikipedia-grade text.

Team shape is worth noting: roughly 15 people on data in the Llama team, more people than on modelling, and more CPUs than GPUs.

On scale: loss falls as a power law in parameters, data and compute, which is why small runs can predict large ones. Chinchilla's takeaway is about 20 tokens per parameter — earlier models were typically data-starved.

Post-training: from autocomplete to assistant

SFT is next-token training on human-written ideal answers. The key insight: it teaches format and persona, not knowledge. LIMA scaled from 2,000 to 32,000 examples and quality barely moved. It also teaches the model to produce a plausible-looking answer instead of admitting ignorance — part of where hallucination comes from.

RLHF replaces demonstrations with preferences: show two answers, ask a human which is better, train a reward model (Bradley–Terry), then optimize the policy with PPO plus a penalty against over-optimizing the reward. Binary rewards are too sparse — you learn which answer won, not by how much.

DPO skips the RL loop: raise the likelihood of the preferred answer, lower the dispreferred one. Under standard assumptions the optimum matches PPO's, with a far simpler implementation, which is why it's now a default in open source.

The economics matter more than people think: humans agree with themselves only ~66% of the time on a binary preference task, human labels cost roughly $300 per 1,000 examples, and LLM labellers are about 50× cheaper with higher agreement with the human majority. The bias to watch: labellers prefer longer answers, so models trained on their preferences get verbose. That's why ChatGPT rambles.

Evaluation is where claims quietly break

Validation loss isn't comparable across PPO and DPO — different objectives.
Perplexity stops being meaningful after PPO: the model is a policy, not a distribution over text.
Chatbot Arena is the most trusted signal, and it's slow, expensive, and skewed toward technical users.
LLM-as-judge gets ~98% correlation with Arena for under $10 and under 3 minutes — with known biases toward length and its own family's style.

So before believing any benchmark number, ask three questions: which benchmark, against whom, judged by what.

Systems: the part nobody tweets about

Mixed precision (store weights in 32-bit, compute in 16-bit, update in 32-bit) and operator fusion (torch.compile gets roughly 2× faster training by moving data through GPU memory once instead of per op). Unglamorous, and often the difference between a training run finishing or not.

I packaged all of this as a skill file with a per-claim timestamp index, so you can verify instead of trusting my summary: github.com/lizhao888/llm-building-map (MIT).