mT5 › Multilingual Tokenization

Michael BrenndoerferOctober 20, 20258 min read
Language AI HandbookAll chapters
Part 25 of 67Encoder-Decoder Models
Chapter 182mT5 › Multilingual Tokenization
Reading section 4 of 11 · Multilingual Tokenization · 8 minSection 4 of 11 · 8 min

Book contents

Section 4 of 11 · 8 min read

mT5 › Multilingual TokenizationOne section · Sections in this chapter4 / 11 ↓
Reading tools Definitions & inline links

Choose your expertise level to adjust how many terms are explained. Beginners see more tooltips, experts see fewer to maintain reading flow. Hover over underlined terms for instant definitions.

Article links

Make inline references clickable

Training a single model on 101 languages requires a vocabulary that can effectively tokenize all of them. This presents a challenging problem combining computational linguistics and machine learning efficiency. As we covered in the SentencePiece chapter, subword tokenization algorithms learn vocabularies from data by identifying frequently occurring character sequences. The challenge for multilingual models is that vocabulary slots are finite. A larger vocabulary means more parameters in the embedding layer and slower softmax computation during training and inference. Yet a vocabulary that is too small cannot adequately represent the diverse morphological patterns and writing systems found across 101 languages.

mT5 uses a SentencePiece unigram model with a vocabulary of 250,000 subword tokens, compared to T5's 32,000 tokens for English only. This 8x increase accommodates the diverse character sets and morphological patterns across 101 languages. The expansion is necessary because different language families have fundamentally different word formation rules: agglutinative languages like Turkish build complex words by chaining morphemes, while isolating languages like Chinese use single characters to represent concepts. A vocabulary optimized for English would fragment Turkish words into unrecognizable pieces while failing to provide useful decompositions for Chinese characters.

The vocabulary training process samples from mC4 using the same temperature-based sampling as model training. This design choice is important for so low-resource languages contribute meaningful vocabulary entries rather than being drowned out by English. Without temperature sampling during vocabulary construction, the tokenizer would learn subword patterns primarily from English text, leading to poor tokenization quality for low-resource languages.

In[7]:
Code
# Conceptual vocabulary training with temperature sampling
# (Actual mT5 used proprietary SentencePiece training)


def sample_training_text(corpus_sizes, temperature, total_chars=10_000_000):
    """
    Sample text for vocabulary training with temperature.
    Returns approximate character counts per language.
    """
    probs = corpus_sizes ** (1 / temperature)
    probs = probs / probs.sum()

    # Allocate characters proportionally to tempered probabilities
    char_counts = (probs * total_chars).astype(int)
    return char_counts


# Compare vocabulary training samples
languages_vocab = ["English", "Russian", "Japanese", "Swahili", "Yoruba"]
sizes_vocab = np.array([2749, 743, 261, 1.8, 0.06])

# Calculate allocations for both sampling strategies
proportional = sample_training_text(sizes_vocab, temperature=1)
tempered = sample_training_text(sizes_vocab, temperature=100)
Out[8]:
Console
Character allocation for vocabulary training (10M total):

Language        Proportional           T=100      Boost
-------------------------------------------------------
English            7,321,178       2,087,125       0.3x
Russian            1,978,768       2,059,997       1.0x
Japanese             695,099       2,038,559       2.9x
Swahili                4,793       1,939,588     404.7x
Yoruba                   159       1,874,728   11790.7x

Temperature sampling ensures that even low-resource languages contribute substantial training data for vocabulary learning. Without this adjustment, languages like Yoruba might have fewer than 200 characters in the training sample. This is far too few for meaningful subword discovery. The SentencePiece algorithm needs sufficient examples of each language to identify common character patterns and build effective subword units.

Script Coverage

The 250K vocabulary must cover many writing systems. These include Latin and Cyrillic, Arabic and Hebrew, plus Chinese and Japanese. Korean and numerous other writing systems also need representation. Each writing system brings its own characteristics: alphabetic scripts like Latin and Cyrillic build words from individual letters, syllabic scripts like Japanese hiragana represent syllables, and logographic scripts like Chinese use characters that represent morphemes or words. The vocabulary breakdown reflects this diversity, with capacity allocated across script families to ensure adequate coverage:

Out[9]:
Visualization
Pie chart showing mT5 vocabulary distribution across Latin, Cyrillic, CJK, and other scripts.
Approximate composition of the mT5 250K vocabulary by script family. Latin-based scripts dominate but significant capacity is allocated to other writing systems.

The vocabulary expansion from 32K to 250K tokens has measurable implications for model efficiency. Each token requires an embedding vector that maps the discrete token to a continuous representation the model can process. The embedding matrix size therefore grows proportionally with vocabulary size, creating a direct tradeoff between linguistic coverage and parameter efficiency:

In[10]:
Code
# Compare embedding matrix sizes
embedding_dim = 1024  # mT5-Large uses 1024-dimensional embeddings

t5_vocab = 32_000
mt5_vocab = 250_000

t5_params = t5_vocab * embedding_dim
mt5_params = mt5_vocab * embedding_dim
Out[11]:
Console
T5 embedding parameters:    32,768,000 (32.8M)
mT5 embedding parameters:  256,000,000 (256.0M)
Increase factor:          7.81x

The embedding layer expansion from 32.8M to 256M parameters represents a significant overhead, particularly for smaller model variants. For mT5-Small with approximately 300M total parameters, the embeddings alone account for a substantial fraction of model capacity. This means that a non-trivial portion of the model's learning capacity is dedicated purely to representing the expanded vocabulary, leaving less capacity for learning language understanding and generation. The designers of mT5 judged this tradeoff worthwhile because adequate vocabulary coverage is foundational. A model cannot learn patterns in text it cannot properly tokenize.

Tokenization Efficiency

Multilingual tokenizers face a fertility tradeoff. Tokens optimized for one language may fragment words in another, leading to longer sequences and slower processing. This phenomenon occurs because subword patterns that are common in one language may be rare or nonexistent in another. For instance, the English suffix "-tion" appears frequently and would likely become a single token. However, this character sequence rarely occurs in Japanese. When mT5's tokenizer encounters Japanese text, it must use different subword patterns entirely. Let's examine how mT5's tokenizer handles different languages:

In[12]:
Code
from transformers import T5Tokenizer

# Load mT5 tokenizer (use slow tokenizer to avoid conversion issues)
tokenizer = T5Tokenizer.from_pretrained("google/mt5-small")

# Test sentences (translations of "The quick brown fox jumps over the lazy dog")
test_sentences = {
    "English": "The quick brown fox jumps over the lazy dog.",
    "Spanish": "El rápido zorro marrón salta sobre el perro perezoso.",
    "German": "Der schnelle braune Fuchs springt über den faulen Hund.",
    "Russian": "Быстрая коричневая лиса перепрыгивает через ленивую собаку.",
    "Japanese": "素早い茶色の狐が怠惰な犬を飛び越える。",
    "Chinese": "敏捷的棕色狐狸跳过懒狗。",
    "Arabic": "الثعلب البني السريع يقفز فوق الكلب الكسول.",
    "Swahili": "Mbweha mwepesi wa kahawia anaruka juu ya mbwa mvivu.",
}
Out[13]:
Console
mT5 Tokenization Efficiency by Language:

Language        Chars   Tokens  Chars/Tok
------------------------------------------
English            44       14       3.14
Spanish            53       19       2.79
German             55       19       2.89
Russian            59       20       2.95
Japanese           19       17       1.12
Chinese            12       14       0.86
Arabic             42       17       2.47
Swahili            52       20       2.60

Average             -        -       2.35
Out[14]:
Visualization
Bar chart showing characters per token ratio for different languages in mT5.
Tokenization efficiency varies significantly across languages and writing systems. Higher characters-per-token ratios indicate more efficient tokenization, with Latin-script languages generally achieving better compression.

The tokenization efficiency results show that Latin-script languages achieve roughly 4-6 characters per token. This holds for English and Spanish as well as German, while languages like Japanese and Chinese with unique scripts show different patterns. Arabic script languages fall somewhere in between. These efficiency differences directly impact sequence lengths. Less efficient tokenization means longer sequences for the same content, which affects both computational cost and the model's ability to capture long-range dependencies within its context window. A sentence that tokenizes to 10 tokens in English might require 20 tokens in another language, effectively halving the amount of context the model can consider for that language within a fixed context window.

In practice, this fertility gap has downstream consequences for fine-tuning and inference that are easy to miss. When you set a maximum input length of 512 tokens for an mT5 fine-tuning job, a document that fits comfortably in English might get truncated when expressed in a language with higher fertility. This means that languages already disadvantaged by lower pre-training data volumes can also end up with shorter effective context during fine-tuning, compounding the disadvantage. When deploying mT5 for a multilingual application, it is worth measuring the token-to-word ratio for each target language and adjusting the maximum sequence length accordingly, or at least being aware that different languages effectively see different context windows at the same token limit.