II · THE IDEA · ARTIFICIAL INTELLIGENCE
Tokens: How Language Becomes Something a Model Can Process
▶ Listen · narrated
Ask a model to count the r's in strawberry and it may get it wrong. Not because it cannot count, but because it never saw the letters.
At a glance
- What it is
- Splitting text into units from a fixed vocabulary, then mapping each to an integer id
- Typical vocabulary
- Tens of thousands of entries, learned from data rather than designed
- Rough guide
- In English, one token averages about four characters
- Why it exists
- A model needs a finite input alphabet; whole words are too many, single characters too few
- Where it bites
- Spelling, arithmetic, rhyme, and the cost of non-English text
Think of a set of fridge magnets. Not one magnet per letter, and not one per word — a mixed set, where the words you use constantly get their own magnet, and rarer words have to be spelled out from smaller pieces you snap together. "The" is a single magnet. "Tokenisation" might take two or three.
Before a model reads your sentence, it rebuilds it out of these magnets. Then it swaps each magnet for its number in the box — magnet 4383, magnet 991 — because numbers are the only thing the model can actually work with.
That is the whole idea. Two things follow from it, and both are worth carrying around.
The first is that the model does not see letters. It sees the magnets. Asking it how many r's are in "strawberry" is like asking someone to count the letters in a word when they are only allowed to look at two or three tiles that spell it. Often they will know the answer from memory. Sometimes they will not.
The second is that the magnet set was not designed — it was assembled by looking at an enormous amount of text and keeping whichever fragments came up most. So it fits the languages that dominated that text, and fits others badly. Writing in a language the set was not built for means using far more magnets to say the same thing.
Tokenisation maps a string to a sequence of integers drawn from a fixed vocabulary, and it is the boundary between text and tensor. The dominant family is subword segmentation, of which byte pair encoding is the canonical instance.
BPE is trained, not specified. Initialise the vocabulary with the base units — bytes, in modern byte-level variants, which guarantees no out-of-vocabulary input is possible. Count the frequency of every adjacent symbol pair across the training corpus. Merge the most frequent pair into a new symbol and record the merge. Repeat until the vocabulary reaches the target size, typically between roughly 30,000 and 200,000 entries in current models. The learned artefact is the ordered list of merges; encoding applies them greedily in order, so segmentation is deterministic for a given text.
Byte-level BPE is the reason arbitrary Unicode, emoji and malformed input can be represented without special handling: the fallback is always the raw byte. SentencePiece takes a further step by treating the input as a raw stream and encoding whitespace explicitly as a meta-symbol, which removes the dependency on language-specific word segmentation. It also offers a unigram language-model segmenter as an alternative to BPE, which selects a segmentation by likelihood rather than by greedy merge order and admits probabilistic sampling of alternative segmentations during training.
The practical consequences follow from the vocabulary being frozen with respect to the model. Embedding matrices are indexed by token id, so the tokeniser and the model weights are a matched pair; swapping one invalidates the other. Sequence length in tokens — not characters — determines attention cost, which is quadratic in the number of tokens for standard attention, and determines KV cache size, which grows linearly. Fertility, the average tokens per word, varies sharply by language and directly determines both the effective context length and the per-request cost for that language.
Two failure modes are worth naming precisely. Character-level tasks are hard because character identity is not recoverable from a token embedding except insofar as the model has learned it indirectly from text describing spelling. And under-trained tokens — vocabulary entries that survive the merge process but occur near-zero times in the model's pretraining corpus, often because tokeniser and model were trained on different data — retain embeddings close to initialisation and can produce badly out-of-distribution behaviour when prompted.
Look closer
The split is not on word boundaries
Common words usually survive intact — "the", "and", "model" are each one token. Rarer words fracture. "Tokenisation" might arrive as "token" + "isation", and an unusual surname may come apart into three or four fragments that mean nothing individually. The leading space is normally part of the token too: " model" and "model" are different entries in the vocabulary, which is why a stray space can change a model's behaviour more than it seems it should.
Every token is just an integer
After splitting, each piece is replaced by its index in the vocabulary. That number carries no meaning at all — token 4383 is not more or less than token 4384 in any sense the model can use. Meaning only appears at the next step, when each id is used to look up a learned vector. The id is a name, not a measurement. This is worth holding on to, because it is the reason the embedding lesson matters.
The vocabulary was learned, not written
Nobody sat down and decided that "isation" deserved its own entry. The vocabulary is produced by running a merge algorithm over a large corpus and keeping whichever fragments turn out to be frequent. That means it encodes the statistics of the training data — including which languages were well represented. A tokeniser built mostly on English will handle English efficiently and spend far more tokens on the same content in Thai or Telugu.
The story
Everything a language model does begins with an act of chopping.
The model is a mathematical function. It consumes numbers and produces numbers. It has no notion of a letter, a word, or a sentence, and no mechanism for acquiring one. So the very first thing any system does with your text is convert it into a sequence of integers — and the scheme for doing that conversion is the tokeniser.
The obvious approaches both fail. Give every word its own number and the vocabulary becomes unbounded: new words appear constantly, proper nouns are endless, and any word the model never saw during training has no id at all. Go the other way and treat each character as a token and the vocabulary becomes trivially small, but now the model must learn that the twelve characters t-o-k-e-n-i-s-a-t-i-o-n form a meaningful unit, and every sequence becomes very long — which matters enormously, because attention cost grows with the square of sequence length.
Subword tokenisation is the compromise, and it is the one everything modern uses. Frequent strings get their own entry; infrequent ones are assembled from smaller pieces. Common words stay whole, rare words break into fragments, and nothing is ever out-of-vocabulary because the fragments bottom out at individual bytes.
The method that made this standard was introduced by Sennrich, Haddow and Birch in 2016, adapting a 1990s data-compression algorithm called byte pair encoding. Start with characters, count adjacent pairs across the corpus, merge the most frequent pair into a new symbol, and repeat until the vocabulary reaches the size you want. It is almost embarrassingly simple, and it works. Kudo and Richardson's SentencePiece later packaged the idea so it could run directly on raw text without language-specific pre-processing — significant for languages that do not put spaces between words.
The consequences are not confined to preprocessing. They surface as behaviour.
Counting letters is the famous one. If "strawberry" reaches the model as two or three tokens, the individual r's are not separate objects it can enumerate — they are interior details of chunks it has only ever seen whole. It can often answer correctly anyway, because it has read text about spelling, but it is reasoning about the word rather than inspecting it.
Arithmetic degrades for related reasons. Whether a number splits as "1", "234" or "12", "34" depends on what the merge algorithm happened to find frequent, and the split is not consistent across magnitudes. Digits that should be positionally equivalent land in different chunks.
Rhyme and wordplay suffer because the model sees the end of a word only if the tokenisation exposes it.
And cost is unevenly distributed. The same paragraph in English and in a language poorly represented in the tokeniser's training data can differ by a factor of two or more in token count — which means it consumes more of the context window, takes longer to generate, and costs more per request. That is a fairness problem baked in before the model does any thinking at all.
None of this is a bug in a particular model. It is a structural consequence of the fact that text has to become integers somehow, and every scheme for doing so makes some things easy to see and other things invisible.
Why it mattered then
Before subword methods, machine translation systems had a hard vocabulary ceiling and a persistent unknown-word problem. Rare words — names, technical terms, morphologically rich forms — were replaced with a generic placeholder, and the output was correspondingly poor. The 2016 subword paper was written specifically to fix rare-word translation, and it did: it removed the open-vocabulary problem entirely, because any string can be built from smaller pieces. That unlocked training on genuinely open text corpora, which is a precondition for everything that came after.
Why it matters now
Tokenisation is the layer people skip, and then spend a week debugging. Context limits are counted in tokens, not characters. Pricing is per token. Throughput is per token. When a local model produces subtly degraded output, a mismatched tokeniser or chat template is a common cause. And it sets a hard ceiling on certain tasks: if you need reliable character-level manipulation, the right move is usually to do it in code rather than asking the model, because the model is working with the wrong primitives for the job.
The surprising detail
The tokeniser is trained separately from the model, and once chosen it is effectively frozen. Changing it invalidates every learned embedding, because the ids no longer point at the same things — so a decision made early, on a particular corpus, propagates through the entire lifetime of the model. There is also a well-documented failure mode involving tokens that appear in the tokeniser's vocabulary but almost never in the training text. Their embeddings stay close to their random initialisation, and prompting a model with them can produce strikingly erratic output. They are sometimes called glitch tokens, and they are an artefact of the tokeniser and the training corpus being built from different data.
What is disputed
The rule of thumb that one token is about four English characters is an average across ordinary prose, not a property of the system. Code, numbers, non-Latin scripts and unusual names all diverge from it substantially, and the exact ratio differs between tokenisers. Treat it as a rough budgeting aid, never as a measurement.
Remember this
Tokens are the model's alphabet, and it is not ours. Anything that depends on letters — spelling, counting, rhyme — is being done through a layer that hid them.
Test yourself
You give a model a document in English and the same document translated into a language that was thinly represented in the tokeniser's training corpus. The second one uses far more tokens. Name two distinct practical consequences, beyond simply costing more.
First, it consumes more of the context window, so less of the document — or less conversation history — fits before something must be dropped. A 100,000-token limit is a much smaller document in the second language. Second, generation is slower and more expensive per unit of actual content, because time and cost scale with tokens rather than with meaning. A third consequence worth knowing: quality itself can degrade, because a word fragmented into many low-frequency pieces gives the model a weaker, more diffuse signal than a word it holds as a single well-trained unit. The tokeniser's training distribution therefore becomes an equity issue, not just an engineering detail.
Go deeper
- Neural Machine Translation of Rare Words with Subword Units · arXiv · Rico Sennrich et al. · 2015-08-31
- SentencePiece: A simple and language independent subword tokenizer and detokenizer for Neural Text Processing · arXiv · Taku Kudo et al. · 2018-08-19
Image: Original diagram, The Daily Triptych. Licence: Original work. Source.