Introduction
Welcome to the first lesson of our new module, "Training and Scaling Large Language Models." In the previous module, we concluded our deep dive into the architecture of modern LLMs, tracing their evolution and understanding their core components. We've essentially studied the engine's blueprint. Now, we shift our focus to the fuel and the assembly line: how do we prepare data for these models and train them at scale?
Our journey begins with the most fundamental step in the entire NLP pipeline: tokenization. This lesson addresses the learning outcome: Describe and compare tokenization methods (BPE, WordPiece, SentencePiece) and their trade-offs.
You'll discover that tokenization is far more than just splitting text. It's a critical engineering decision that defines a model's vocabulary, influencing its performance, computational cost, and ability to handle different languages. Understanding these methods is essential for any engineer looking to train, fine-tune, or even just efficiently use LLMs.
What is Tokenization and Why Does It Matter?
At its core, a language model is a machine for processing numbers, not text. Tokenization is the process of converting a raw string of text into a sequence of integers, where each integer (or "token") corresponds to an entry in a predefined vocabulary. The model then looks up these integers in an embedding matrix to get the vectors it actually computes over.
But how an LLM provider chooses to create that vocabulary and break down text has direct consequences for you as an engineer. Different models will tokenize the same text differently, affecting API costs, performance, and memory usage.
To get a practical sense of what tokens are and why they are the "currency of LLMs," let's start with a short, developer-focused video.
Most devs don't understand how LLM tokens work
The video 'Most devs don't understand how LLM tokens work' from the Matt Pocock channel provides an excellent, practical introduction to what tokens are and why they differ between models.
Please watch the first four and a half minutes of the video (00:00 - 04:43). Focus on: How input and output tokens relate to API costs. The observation that the same text yields different token counts for different models. The core idea of an encode (text to numbers) and decode (numbers to text) process.
As the video highlights, the central challenge is deciding what a token should represent. The simplest approaches have significant flaws:
- Word-based tokenization: Splitting by spaces and punctuation. This leads to an enormous vocabulary (e.g., "run", "running", and "ran" are three separate tokens) and fails completely on words not seen during training (Out-of-Vocabulary or OOV words).
- Character-based tokenization: Splitting into individual letters. The vocabulary is tiny (e.g., A-Z, 0-9, etc.), but sequences become extremely long, and it's difficult for the model to learn meaningful representations from single characters alone.
The solution that modern LLMs use is subword tokenization.
Subword Tokenization: The Best of Both Worlds
Subword tokenization is a hybrid approach. The core principle is:
- Common words (like "and", "the", "model") should remain as single tokens.
- Rare words (like "tokenization") should be broken down into smaller, meaningful subwords (e.g., "token", "##ization").
This elegantly solves the problems of the simpler methods. The vocabulary size remains manageable, and the model can handle any word, even OOV words, by decomposing them into known subwords.
To get a formal understanding of this concept, the Hugging Face documentation provides a great summary.
The Hugging Face Transformers documentation offers a clear explanation of why subword tokenization is necessary. We'll read the introductory sections that set the stage for the specific algorithms.
Read the 'Introduction' and 'Subword tokenization' sections. Focus on the limitations of word- and character-level tokenization and how the subword approach provides a robust compromise.
Now that we understand the "why," let's explore the "how." We'll examine the three most influential subword tokenization algorithms.
Core Tokenization Algorithms
1. Byte-Pair Encoding (BPE)
BPE is perhaps the most foundational subword algorithm. Originally a data compression technique, its application to NLP is straightforward and effective.
How it works:
- Initialization: Start with a vocabulary of all individual characters (or bytes) present in your training corpus.
- Iteration:
a. Count the frequency of all adjacent pairs of symbols in the corpus.
b. Find the most frequent pair (e.g., 'e' and 'r').
c. Merge this pair into a new, single symbol (e.g., 'er').
d. Add this new symbol to the vocabulary. - Repeat: Continue this process for a predetermined number of merges. The final vocabulary size is a hyperparameter you choose.
The result is a vocabulary that contains base characters plus progressively larger subwords built from the most common character sequences in the data.
This video provides a great visual walkthrough of the BPE algorithm.
LLM Tokenizers Explained: BPE Encoding, WordPiece and SentencePiece
The 'LLM Tokenizers Explained' video by DataMListic clearly demonstrates the BPE merging process with a simple example.
Watch the segment on Byte-Pair Encoding (00:33 - 02:15). Pay close attention to how the vocabulary is built up iteratively by merging the most frequent pairs.
A key variant is Byte-level BPE, used by models like GPT-2. Instead of starting with characters, it starts with the 256 possible bytes. This guarantees that every possible string can be tokenized without needing an "unknown" token, making it incredibly robust.
2. WordPiece
Used by BERT and its derivatives, WordPiece is very similar to BPE but uses a slightly more sophisticated criterion for merging.
How it works:
Like BPE, WordPiece starts with a base character vocabulary and learns merge rules. However, instead of merging the most frequent pair, it merges the pair that maximizes the likelihood of the training data if it were added to the vocabulary.
In simple terms, you can think of the likelihood score as:
This change means WordPiece prioritizes merges that are not just frequent, but also "surprising" or statistically significant, effectively evaluating what is lost by the merge to ensure it's worth it.
LLM Tokenizers Explained: BPE Encoding, WordPiece and SentencePiece
The same video also explains the key difference between BPE and WordPiece.
Now watch the section on WordPiece (02:03 - 03:28). Focus on understanding that the core difference from BPE is the merge criterion—it's based on likelihood, not just raw frequency.
3. SentencePiece
SentencePiece isn't so much a new tokenization algorithm as it is a language-agnostic framework for it. Its main innovation is to treat the input text as a raw stream of Unicode characters, including whitespace.
How it works:
- No Pre-tokenization: Unlike BPE and WordPiece, which typically rely on a pre-processing step to split text by spaces, SentencePiece operates directly on raw text.
- Whitespace is a Character: The space character is treated like any other character. It is often represented with a special symbol like
(a meta-character, not a literal underscore). - Algorithm: It then uses an underlying algorithm, typically BPE or Unigram (another method that starts with a large vocabulary and trims it down), to build the subword vocabulary.
This makes SentencePiece truly language-independent, as it doesn't make any assumptions about word boundaries. This is a massive advantage for multilingual models or for tokenizing languages like Japanese or Chinese that don't use spaces. Because whitespace is explicitly tokenized, the original text can be perfectly reconstructed (it is "lossless").
LLM Tokenizers Explained: BPE Encoding, WordPiece and SentencePiece
Let's complete our viewing with the section on SentencePiece.
Watch the final segment on SentencePiece (03:16 - 04:48). The key takeaway is that it operates on raw text and handles spaces explicitly, making it language-agnostic.
Test your understanding!
Imagine you are training a BPE tokenizer and a WordPiece tokenizer on a large English corpus. In the corpus, the pair of subwords ("re", "d") appears 1000 times, and the pair ("q", "u") appears 800 times.
However, the individual subword "q" is very rare, appearing almost exclusively before "u". The individual subword "re" is extremely common, appearing in many other contexts ("receive", "return", etc.).
Which algorithm is more likely to merge ("q", "u") first? Why?
Show answer
WordPiece is more likely to merge ("q", "u") first.
- BPE would choose based on raw frequency. Since
("re", "d")appears more often (1000 vs. 800 times), BPE would merge it first. - WordPiece looks at the likelihood increase. The likelihood score for
("q", "u")would be very high because the probability of the pairP(qu)is high relative to the product of the individual probabilitiesP(q) * P(u). Since"q"is rare on its own,P(q)is low, making the score for thequmerge large. In contrast, while("re", "d")is frequent,"re"is also very common on its own, soP(re)is high, leading to a smaller likelihood score for the merge.
Comparison and Trade-offs
The choice of tokenizer is an engineering trade-off between robustness, language support, and training objectives. The following table, from an excellent article by Yuzhu Li, summarizes the key differences at a glance.

Let's distill these trade-offs:
| Feature | Byte-Pair Encoding (BPE) | WordPiece | SentencePiece |
|---|---|---|---|
| Merge Criterion | Highest frequency pair. | Pair that maximizes data likelihood. | Uses an underlying algorithm (like BPE or Unigram). |
| Pre-tokenization | Required. Typically splits text by spaces and punctuation. | Required. Similar to BPE. | Not required. Operates on raw text stream. |
| Whitespace | Usually discarded during pre-tokenization. | Usually discarded during pre-tokenization. | Encoded as part of the token. This makes it losslessly reversible. |
| Language Support | Best for languages with clear word boundaries (e.g., English). | Best for languages with clear word boundaries. | Language-agnostic. Excellent for multilingual contexts and no-space languages. |
| Famous Users | GPT-2, RoBERTa | BERT, DistilBERT, Electra | T5, Llama, ALBERT, XLNet |
To solidify this comparison, let's turn to one more resource that lays out these differences and provides examples of models that use each method.
Natural Language Processing • Tokenizer
The article 'Natural Language Processing • Tokenizer' from aman.ai offers a fantastic comparative analysis that summarizes the core ideas and use cases for each method.
Please read the 'Comparative Analysis' and 'Use-cases' sections. This will reinforce the unique characteristics of each algorithm and connect them to the specific LLMs you'll encounter in practice.
Conclusion
You have now explored the fundamental methods used to convert raw text into a format that Large Language Models can understand. This seemingly simple pre-processing step is a cornerstone of modern NLP, with deep implications for model performance and efficiency.
Key Takeaways:
- Subword tokenization is the dominant paradigm, balancing the trade-offs between word-level (large vocabulary, OOV issues) and character-level (long sequences, poor semantics) methods.
- Byte-Pair Encoding (BPE) is a greedy algorithm that iteratively merges the most frequent pairs of tokens. It is simple and effective.
- WordPiece is a probabilistic variant of BPE, merging token pairs that most increase the likelihood of the training data, not just the most frequent ones.
- SentencePiece is a language-agnostic framework that operates on raw text streams without pre-tokenization, making it highly versatile for multilingual applications. The Llama family of models uses SentencePiece.
- The choice of tokenizer involves engineering trade-offs regarding language support, vocabulary construction, and reversibility.
What's Next?
Understanding the theory is one thing; seeing it in action is another. In our next lesson, we will move from description to implementation. You will implement a basic Byte-Pair Encoding (BPE) tokenizer from scratch. This hands-on exercise will solidify your understanding of how a vocabulary is built and how raw text is segmented, bridging the gap between concept and code.