Open the black boxO0/>0/>p{1+{1+e<}:<}:n/>0/>0 t}:<}:<h>0/>0/e+{1+{1b:<}:<}l0/>0/>a{1+{1+c<}:<}:k/>0/>0 b}:<}:<o>0/>0/x+{1+{1

Why tokenize at all?

A model doesn't read letters, and it can't keep a slot for every possible word, since real languages have millions, and people invent new ones constantly. So instead of words, the tokenizer works from a fixed vocabulary of subword chunks. Vocabulary sizes vary by model. Common words get their own token; anything rarer is stitched together from smaller known pieces. That way even a word the model has never seen, or one you just made up, can still be built out of chunks it already knows.

Why counting letters is hard for LLMs

Try it above: “strawberry” splits into st + raw + berry. The model never sees the individual letters; it sees those three whole chunks, so the count of r's isn't something its input directly exposes. Modern models often do get this right, by reasoning through it step-by-step or from spelling patterns they've memorized. It's not impossible, just not automatic, the way it would be if the model read raw letters. That difficulty is a direct consequence of tokenization.

Why token count matters in practice

A context window limits the tokens available to a model at once. Instructions, conversation history, retrieved text, and generated output all use token space. Many language-model APIs charge for input and output tokens, so token counts also help estimate cost. The tokenizer count here covers the text you enter; a chat application can add role markers and other framing tokens.

Same idea, different price

Here is one short sentence written five ways, each counted live with the same tokenizer. The bars show tokens, and the character count sits beside each one so you can see the contrast.

Compare the actual counts for these examples. Language, script, spacing, and formatting affect which chunks exist in this vocabulary. Some Unicode characters span several byte tokens, while some tokens contain multiple characters. These examples do not establish a universal ranking of languages: the text and the tokenizer both matter.

Good to know: tokenizers differ by model

The splitter above uses one specific GPT-family encoding. Different models can use different tokenizers. The exact same text can come out to a different number of tokens depending on which model processes it, so a token count is always relative to a particular model family.

Why embeddings?

A token id is arbitrary. “cat” might be 9707 and “dog” 3899, but those numbers are just slots in a vocabulary, being close in id says nothing about being close in meaning. An embedding replaces that arbitrary label with a learned position in space, fitted during training so that words used in similar ways land near each other. Now distance and direction carry meaning: “cat” sits beside “dog”, both far from “Tuesday”, and the model has something it can actually compute with.

What do the numbers actually mean?

It's tempting to imagine each dimension stands for one human idea, an “animal-ness” axis, a “royalty” axis. It almost never works that way. Individual dimensions rarely line up with a single concept we'd name. Meaning lives in the combination of many dimensions at once: it's the overall pattern of the vector, and its position relative to every other vector, that encodes what a word is like, not any one number on its own. That's also why the interesting structure shows up as directions and clusters rather than as readable coordinates.

Similar usage does not mean identical meaning

Try comparing happy with sad. They describe opposite feelings, but both appear in similar sentences about emotions. Their vectors can therefore be close. An embedding captures patterns of use, not a dictionary definition or a guarantee that two words are interchangeable.

Cosine similarity measures the angle between the full vectors. A score of +1 means the same direction, 0 means perpendicular directions, and −1 means opposite directions. It is a geometric score, not a percentage of shared meaning.

Embeddings are everywhere, not just in LLMs

The same idea, turning something into a vector whose position encodes meaning, powers a huge amount of modern software. Semantic search finds documents whose embeddings sit near your query's. Recommendation systems place songs, products, or videos in a space and suggest nearby neighbors. Retrieval-augmented generation (RAG) can use a dedicated embedding model to compare a query with passages, then supply selected text to a language model. Document embeddings are trained for a different use from token input embeddings. Similarity helps find candidates; it does not guarantee that a passage answers the question. The Assistants lesson follows that process further.

Why attention?

Without it, bank would carry the exact same vector in “river bank” and “savings bank”, since the embedding table has only one entry for the word. Attention is what lets the surrounding context influence the representation: “river” and “savings” supply different information. More precisely, attention mixes learned value vectors, then projects and adds the result to the representation. The rest of the block transforms that result further.

One catch: this model looks both ways

Notice that it can attend forward to tired, a word that comes later in the sentence. That's because the demo runs a bidirectional model (DistilBERT), which sees the whole sentence at once, handy for showing the mechanism clearly. GPT-2 and other autoregressive decoder models use causal attention: each position is masked from future positions, so it can only look back at itself and the words before it, never ahead. Attention there flows in one direction only.

Many heads, many kinds of looking

A model doesn't run just one of these attention passes; it runs several in parallel, called heads. Each head has its own learned projections and can emphasize different patterns, such as nearby positions or particular relationships. Heads do not have fixed human-assigned jobs, and their behavior depends on the model, layer, and input. The demo averages them together, which can hide differences between individual heads.

And it happens layer after layer

One round of attention isn't the whole story either. The model stacks the same mechanism in layers (DistilBERT has six), and each layer refines the token representations before passing them up. Each block also contains a feed-forward network, residual connections, and normalization. Patterns across layers can differ; a later layer is not guaranteed to reveal a clearer grammatical relationship. Flip open step through the layers to watch the same sentence's attention shift as it moves up the stack.

Why backpropagation?

A real model can have billions of weights. You could imagine testing each one: nudge it, run the whole network again, see if the error went down, but that means billions of full forward passes per step, which is hopeless. Backprop gets the answer for every weight in a single backward pass. It uses the chain rule from calculus to share work across the network: it figures out how wrong the output was, then hands each layer its share of the blame, reusing the layer above instead of recomputing from scratch. That efficiency is the whole reason training large networks is even possible.

Gradient descent: many small nudges

A gradient is a local rate of change of loss with respect to a weight. Plain gradient descent subtracts learning rate × gradient from each weight. With a sufficiently small step this moves downhill; a large step can overshoot. A single step doesn't fix the network; it just moves every weight a little bit downhill. Do that over and over and the errors shrink, which is exactly what the falling loss curve is showing you: not one clever fix, but thousands of tiny, honest corrections adding up.

The same thing, at unimaginable scale

Every weight, in every layer, gets its own gradient and its own nudge, all at once, every single training step. The toy above has around a dozen weights, so you can watch each one move. A transformer has parameters in embedding tables, attention projections, feed-forward networks, and normalization operations. The chain rule applies across those operations too. The XOR network illustrates differentiation and updates; it is a different architecture from an LLM.

One honest caveat: the backward pass computes gradients by the chain rule. The operations being differentiated depend on the architecture. The update rule is where real training differs. Instead of the plain fixed-size step the toy above takes, LLMs use smarter optimizers like Adam (and AdamW), which add momentum and give each weight its own adaptive step size. The gradients come from backprop; Adam just decides how to spend them.

What does an LLM train on?

A common pretraining objective for causal language models is predict the next token. Show the model a stretch of text with the next piece hidden, let it predict a distribution, and score the probability assigned to the observed next token. Training text can include books, code, and web pages. Many useful patterns develop through prediction, while post-training can further teach instruction following and task-specific behavior. Other model families can use different objectives, such as masking tokens.

Epochs, batches, learning rate, in plain words

Each step above doesn't look at the whole text at once; it grabs a small random batch of examples, because averaging the error over a handful is far cheaper than over everything and works nearly as well. One full pass over all the training text is an epoch. Recipes can use one pass or reuse data; the random sampling here does not visit examples in a fixed epoch order. The learning rate is how big each update is. As the advanced control in the demo shows, too small can learn slowly, while too large can make the updates diverge.

This is only pretraining: chatbots need more

What you trained here is a raw next-token predictor: it continues text, but it doesn't know it's supposed to be helpful, follow instructions, or answer a question rather than ramble on. That first stage is called pretraining. Turning a pretrained model into an assistant takes further stages: fine-tuning on curated examples of good responses, and learning from human and AI feedback about which answers people prefer. The model you meet in a chat window often uses some combination of these stages; the demo illustrates pretraining. The final Assistants lesson explains the stages and the chat system that uses the trained model.

The gap to a frontier model

The demo model has a few thousand parameters and learns from a few kilobytes of text. Larger language models use much larger datasets and computation budgets, often with transformer architectures, subword vocabularies, adaptive optimizers, and distributed training. They share the predict, measure, backprop, update loop, but the architecture and training recipe differ substantially from this three-character MLP.

Why scale works: scaling laws

Researchers have found approximate power-law relationships between prediction loss and model size, data, or compute within studied regimes. After accounting for a loss floor, a power law appears straight on logarithmic axes for both variables. Those empirical fits can help forecast loss within their assumptions; they do not guarantee every downstream skill. The Chinchilla study examined how to allocate a fixed training-compute budget between model parameters and data. It found that training a smaller model on more tokens could outperform a larger, less-trained model.

One variable at a time: read this carefully

This experiment deliberately changes only the embedding and hidden widths, holding the data, context length, batch size, learning rate, and number of steps fixed. Wider models generally require more arithmetic per step, so this is not an equal-compute comparison. Each size also has a different random initialization and sampled batches. Repeat runs to judge variability. The fixed three-character context and finite dataset can limit gains; larger models can also overfit. Undertraining and overfitting are different problems: a model can need more training without having memorized its data.

“Emergent” abilities, and the argument about them

Something odd shows up as models grow: certain skills, like multi-step arithmetic, following an unusual instruction, translating a rare language, seem largely absent in smaller models and then appear fairly suddenly past some size, rather than improving gradually. These are often called emergent abilities. Their interpretation is debated: some of the “sudden” jumps are partly an artifact of how the ability is measured : a strict all-or-nothing score can flip from zero to one abruptly even when the underlying skill was improving smoothly all along. Evaluate the actual task and metric, rather than assuming a particular parameter threshold guarantees an ability. Both the emergence study and the critique are linked in the sources below.

Scale isn't free

Larger training runs require more arithmetic, memory, and energy. Data quality, architecture, and optimization can change what that budget achieves. Deployment adds another tradeoff: a smaller model trained for longer may cost less to run for many users. MoE can reduce active computation relative to total size, but storing weights and routing between experts still have costs. Parameter count alone describes neither quality nor operating cost.

What am I looking at?

A layer is one processing step inside the model. GPT-2 small has 12 of them stacked in a row. Each layer reads the running representation of your text, mixes in a bit more context, and passes it up to the next. The model only commits to a next-token probability after the final layer, but there is a clever trick, called the logit lens, that lets us peek early: take the half-finished representation at any layer and run it through the same output step the model uses at the end. This produces a diagnostic prediction from that representation.

A guess at a middle layer is not the model's real answer. It is a probe reading, not a literal record of thoughts. The output readout was trained for the final representation, so applying it earlier can give poorly calibrated or unrelated predictions. A change in a bar does not establish exactly when the model learned or retrieved a fact.

What the bars measure: probability assigned by the readout to a token. The final layer gives GPT-2's actual next-token prediction at temperature 1; the earlier readings are diagnostic. Token probability describes a continuation under the model, not confidence that a statement is true.

How a sentence gets built

In standard autoregressive decoding, the model predicts a single next token, one is chosen, that token is appended to the input, and the model predicts again, now conditioned on that added token. This demo recomputes the full sequence each time. Other systems can reuse intermediate computations. A model can generate plans or intermediate steps in its context, but this demo exposes next-token predictions rather than a complete description of planning.

Temperature & sampling, in plain terms

Once you have a probability for every token, you still have to pick one. Greedy decoding always takes the single highest bar: fully deterministic, and quick to fall into repetitive loops. Sampling instead rolls a weighted die, so a token with 40% probability is picked about 40% of the time, and even long-shot tokens occasionally come up.

Temperature is the knob that reshapes those odds before the die is rolled. Turn it down and the probabilities sharpen toward the top token, concentrating mass on the leading candidates. Turn it up and they flatten out, handing rare tokens a real chance: more creative, but more likely to select unlikely continuations. Sampling is one reason repeated prompts can produce different output. Chat applications can also retrieve information or call tools before generating. Temperature alone does not guarantee creativity, correctness, or safety. With fixed logits, positive temperature does not change which token greedy decoding selects.

Some decoding configurations trim the distribution before rolling. Top-k keeps only the k most likely tokens; top-p (nucleus) keeps the smallest set of tokens whose probabilities add up to some threshold, say 0.9, and throws the rest away. A repetition penalty can also adjust scores of previously used tokens. The surviving probabilities are renormalized before sampling. These are optional strategies; their order and implementation vary. This demo uses greedy selection or temperature sampling from the full vocabulary, without top-k, top-p, or a repetition penalty.

Why “predict the next token” can sound so capable

It's fair to wonder how something this simple produces essays, code, and arguments. Part of the answer is scale: the model you just ran is tiny and often clumsy, but the same next-token objective, trained on far more text with vastly more parameters, absorbs an enormous amount of the structure of language and the world. To predict the next token well across billions of examples, a model has to pick up grammar, facts, styles, and patterns of reasoning, not because anyone programmed them in, but because they help lower the prediction error.

The other part is post-training. A raw predictor will happily continue your text in any direction; the helpful, instruction-following assistant you talk to is that predictor after extra rounds of fine-tuning and human feedback that steer it toward being useful and on-topic. It's worth being clear-eyed, though: because the core act is predicting plausible text rather than checking truth, a model can state false things with complete fluency. The widely-used term is hallucination. Sounding confident and being correct are simply not the same operation here.