LLM Recipe and Cooking

There's a Stanford course, CS336, that builds a large language model from scratch — the way old operating-systems courses made you build an OS from nothing. It opens with a useful reframing. We talk about an LLM as if it's one thing, the model, when it's really five: the architecture, the training algorithm, the data, the evaluation, and the systems that run it. Five ingredients, not one. And once you separate them, you notice something the hype gets backwards.

The one ingredient everyone talks about is the architecture — the Transformer. It's also the one that matters least to how good your model turns out. The design is a published paper; every serious lab runs a near-identical version of it, and the tweaks that make headlines move the needle by single-digit percentages. If architecture were the real edge, frontier models would look wildly different from one another. They don't. The recipe is public, and everyone is cooking from the same one.

The differences live in the other four, which happen to be the four nobody puts on a slide. Data is the largest lever and the most guarded secret in the field — what you train on shapes the model more than any architectural flourish, and no lab will tell you exactly what's in the pot. The training algorithm is where a raw next-word predictor becomes something useful, through the unglamorous grind of pretraining and the post-training that teaches it to follow instructions. Evaluation sounds trivial and is brutally hard — knowing whether a change actually made the model better is where most teams quietly fool themselves. And systems — the engineering that makes a model with hundreds of billions of parameters run at all on real hardware — is the invisible work that decides whether any of the rest is even affordable.

Underneath all four runs a single theme the course keeps returning to: efficiency. Every one of these ingredients is really a question of getting more from the same budget — more capability per token of data, more learning per unit of compute, more signal per eval, more throughput per chip. The scarce thing is never the idea; it's the compute and the data, and the frontier goes to whoever squeezes the most out of a fixed amount of both. Cleverness at the architecture level is cheap. Cleverness at wringing efficiency out of the other four is the whole game.

This is also why a great model is so hard to simply copy, even though the architecture is public. You can read the paper and reproduce the shape; you cannot reproduce the years of data curation, the training recipe, the eval infrastructure, and the systems work poured in behind it. When people ask what makes a frontier LLM, they point at the model. The model is the easy part. The recipe was always public — it's the cooking that nobody can hand you.