Before you can read Vocabulary size tradeoffs, you need to own every symbol it throws at you. This page builds each one from absolute zero: plain words → the picture → why the topic needs it. We go in order, so each symbol leans only on the ones before it.
Picture a numbered list: entry 0, entry 1, ..., entry V−1. Every token that comes out of the tokenizer must be one of these rows — nothing off-menu is allowed.
The topic needs V because it is the first of the two dial settings we trade off. Turning V up makes the menu longer (costs memory) but the sequences shorter (saves compute). See 4.2.02-Byte-pair-encoding and 4.2.03-WordPiece-and-SentencePiece for how the menu is actually built.
The second figure shows the same fixed text becoming different n as V changes. Notice: bigger V → smaller n for the same text, because each fatter token swallows more characters.
The topic needs n because it is the second dial — and it appears squared in the compute cost, which is why it matters so much.
The picture: imagine laying tiles of width ℓˉ over a strip of fixed length (the text). Wider tiles → fewer tiles → smaller n. Bigger V empirically makes ℓˉ grow (more common groups get their own menu entry), but only slowly — doubling V nudges ℓˉ up ~20–30%, not double.
Why the topic needs them: the memory saved by a shorter sequence gets multiplied by b×L and by every batch you ever run. Small per-batch savings compound into large totals over a training run — that is what tips the breakeven toward large V. See 5.1.03-Memory-optimization-techniques.
Recall Quick sanity check on units
Attention score memory for one batch =b×L×n×n×(bytes per number). The scores are scalars (one number per token-pair), so there is no×d here — a very common mis-step.
The two arrows into the topic node T are the whole story: the memory branch (V×d) and the compute branch (n2d) meet, and choosing V is choosing where on that seesaw to sit. This carries straight into 6.2.01-Multilingual-models, where many languages force V upward.