DL0081 Tokenizer Vocabulary Size Effects

How does the tokenizer vocabulary size affect LLM model quality, memory, and throughput?

Answer

Vocabulary size V is one of the few hyperparameters that moves quality, memory, and throughput in opposite directions at the same time, so there is a genuine optimum rather than a “bigger is better” rule. On the cost side, the embedding and unembedding tables grow linearly in V (up to 2Vd parameters when untied), the output projection adds 2Vd FLOPs per token, and the training-time logits tensor of shape b \times T \times V in fp32 becomes one of the largest activations in the whole model. On the benefit side, a larger vocabulary compresses text into fewer tokens, which shortens sequences, shrinks the KV cache, cuts the O(T^2) attention term, and reduces the number of autoregressive decode steps needed to emit the same text. The catch is that compression improves only logarithmically in V while cost grows linearly, and each added token gets a smaller slice of the training signal, so rare embeddings end up undertrained. Empirically the optimum grows with model size: 32k was reasonable for GPT-2-era models, Meta’s Llama 3 moved to 128,256 tokens, and Google’s Gemma 2 uses 256,128, while byte-level and byte-patch models sit at the opposite extreme.

(1) Memory Cost Is Linear: at d = 4096 and V = 128\text{k}, untied tables hold about 1.05B parameters, roughly 13% of an 8B model, and 2.1 GB of bf16 weights before optimizer state.
(2) Compression Gain Is Logarithmic: going 32k → 128k buys only about 11% fewer tokens per document in English, while the embedding tables quadruple.
(3) The Output Softmax Dominates Small Models: the d \times V projection is about 7% of forward FLOPs for an 8B model but roughly a third for a 1B model with d = 2048.
(4) Quality Is Non-Monotonic: too small and sequences are long and multilingual fertility explodes; too large and rare rows receive too few gradient updates, producing dead or glitch tokens.
(5) Throughput Has Two Units: tokens per second falls slightly as V grows, but bytes (or words) per second usually rises because fewer steps are needed for the same text.

Two bar panels: left panel shows bytes per token rising from 3.1 at 8k vocabulary to 3.9 at 32k, 4.1 at 50k, 4.4 at 128k and 4.6 at 256k; right panel shows relative sequence length for a fixed document falling from 1.26 at 8k to 1.00 at 32k, 0.95 at 50k, 0.89 at 128k and 0.85 at 256k

Figure 1: Illustrative English compression: quadrupling the vocabulary from 32k to 128k lifts bytes per token from 3.9 to 4.4, which shortens sequences by only about 11%, while the embedding tables grow 4x.

The most under-appreciated cost is not the weights but the logits activation. Cross-entropy is normally computed in fp32, so a single 8192-token sequence against a 128k vocabulary materializes 8192 \times 128000 \times 4 bytes, about 4.2 GB, and a microbatch of four pushes past 16 GB before the backward pass. This is why large-vocabulary training runs adopt chunked or fused cross-entropy kernels that never hold the full logits matrix, and why teams sometimes cap V purely for activation-memory reasons. At inference the picture flips: the vocabulary contributes a fixed d \times V GEMM per decode step, which is cheap relative to the KV-cache reads in a large model, and the shorter sequence means fewer steps overall, so end-to-end latency for generating a fixed passage typically improves. A separate trap is evaluation: validation loss is not comparable across tokenizers, because the per-token loss is defined over a different unit of text, so comparisons must be normalized to bits per byte or bits per character.

Mathematical Formulation:
P_{emb} = 2 V d
T = B / c(V)
c(V) \approx a + \beta \log V
C = 6 (N_{nv} + P_{emb}) T
M_{logits} = b \, T \, V \, p
V^{\star} \propto N_{nv}^{0.83}

Where:

  • P_{emb} is the parameter count of the input embedding plus output unembedding; the factor 2 drops to 1 when the two are tied.
  • V is the vocabulary size and d the model width; N_{nv} is the non-vocabulary (attention plus MLP) parameter count.
  • B is the raw text size in bytes, c(V) the compression ratio in bytes per token, and T the resulting token count; a and \beta are corpus- and language-dependent fit constants.
  • C is approximate training FLOPs under the 6ND rule, which is why a larger V both adds parameters and removes tokens.
  • M_{logits} is the logits activation in bytes, with microbatch b and precision p (4 for fp32); V^{\star} is the compute-optimal vocabulary, whose exponent near 0.83 means it grows more slowly than the rest of the model.
Two U-shaped curves of relative loss in bits per byte versus vocabulary size on a log-2 axis from 4k to 256k: the 300M non-embedding parameter curve bottoms out near 24k, and the 7B curve sits lower overall and bottoms out near 96k, showing the optimum shifting right with model size

Figure 2: Illustrative shape of the trade-off at fixed compute: loss measured in bits per byte is U-shaped in V, and the minimum shifts right as non-embedding capacity grows, because a bigger body can afford to spend parameters on the vocabulary.

PropertySmall BPE (32k)Large BPE (128k-256k)Byte level (256)
Bytes per token (English)about 3.9about 4.4 to 4.61.0
Embedding params at d=2048, untied131M525M to 1.05B1M
fp32 logits per 8192-token sequence1.05 GB4.2 GB to 8.4 GB8 MB
Average updates per row over 300B tokensabout 9Mabout 1M to 2Mover 1B
Sequence length for a fixed documentbaseline0.85x to 0.89xabout 3.9x
Main weaknessHigh fertility on non-English text and codeUndertrained rare rows, huge logits activationLong sequences, many decode steps
Best fitSub-1B on-device models, single-language domainsMultilingual frontier models with long contextsNoisy input, character tasks, patch-based research

Login to view more content


Log in to track your progress

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *