# Transformers v5 中的分词：更简单、清晰与模块化

- 来源：Hugging Face：Blog（RSS）
- 发布时间：2025-12-18 08:00
- AIHOT 分数：73
- AIHOT 标记：精选
- AIHOT 链接：https://aihot.virxact.com/items/cmoegbhak00a1slxxrimmhnqr
- 原文链接：https://huggingface.co/blog/tokenizers

## 精选理由

Transformers库tokenization模块重构，开发者可更高效处理文本数据。

## AI 摘要

Transformers v5 发布了全新的分词处理架构，核心变化是引入了更简单、统一的 API 设计，将分词器、后处理器和解码器模块化。新版移除了大量遗留代码，使代码库体积减少了约 40%，并显著提升了处理长文本和特殊 token 的灵活性。这一改进旨在降低开发者使用门槛，同时为各类大语言模型（如 GPT、Claude、LLaMA）提供更高效、一致的分词支持。

## 正文

Tokenization in Transformers v5: Simpler, Clearer, and More Modular

Published December 18, 2025

Ita Zaporozhets

itazap

Aritra Roy Gosthipaty

ariG23498

Arthur Zucker

ArthurZ

Sergio Paniego

sergiopaniego

merve

merve

Pedro Cuenca

pcuenq

Transformers v5 redesigns how tokenizers work. The big tokenizers reformat separates tokenizer design from trained vocabulary (much like how PyTorch separates neural network architecture from learned weights). The result is tokenizers you can inspect, customize, and train from scratch with far less friction.

TL;DR: This blog explains how tokenization works in Transformers and why v5 is a major redesign, with clearer internals, a clean class hierarchy, and a single fast backend. It’s a practical guide for anyone who wants to understand, customize, or train model-specific tokenizers instead of treating them as black boxes.

Table of Contents

What is Tokenization?

The Tokenization Pipeline

Tokenization Algorithms

Accessing tokenizers through transformers

The Tokenizer Class Hierarchy in transformers

AutoTokenizer Automatically Selects the Correct Tokenizer Class

v5 Separates Tokenizer Architecture from Trained Vocab

Summary

For experts: If you're already familiar with the concepts and want to understand the changes in v5, go to v5 Separates Tokenizer Architecture from Trained Vocab

Before diving into the changes, let's quickly cover what tokenization does and how the pieces fit together.

What is tokenization?

Language models don't read raw text. They consume sequences of integers usually called token IDs or input IDs. Tokenization is the process of converting raw text into these token IDs. (Try the tokenization playground here to visualize tokenization.)

Tokenization is a broad concept used across natural language processing and text processing generally. This post focuses specifically on tokenization for Large Language Models (LLMs) using the transformers and tokenizers libraries.

from transformers import AutoTokenizer
tokenizer = AutoTokenizer.from_pretrained("HuggingFaceTB/SmolLM3-3B")

text = "Hello world"
tokens = tokenizer(text)

print(tokens["input_ids"])

print(tokenizer.convert_ids_to_tokens(tokens["input_ids"]))

Ġworld (above) is a single token that represents the character sequence " world" (with the space).

A token is the smallest string unit the model sees. It can be a character, word, or subword chunk like "play" or "##ing" ("##" is a pattern, don't worry if you don't completely understand it now 🤗). The vocabulary maps each unique token to the token ID.

from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("HuggingFaceTB/SmolLM3-3B")
print(tokenizer.vocab)

A good tokenizer compresses text into the smallest amount of tokens. Fewer tokens means more usable context without increasing model size. Training a tokenizer boils down to finding the best compression rules for your datasets. For example, if you work on Chinese corpus you can sometimes find very nice surprises 😉.

The tokenization pipeline

Tokenization happens in stages. Each stage transforms text before passing it to the next:

Stage Purpose Example

Normalizer Standardizes text (lowercasing, unicode normalization, whitespace cleanup) "HELLO World" → "hello world"

Pre-tokenizer Splits text into preliminary chunks "hello world" → ["hello", " world"]

Model Applies the tokenization algorithm (BPE, Unigram, etc.) ["hello", " world"] → [9906, 1917]

Post-processor Adds special tokens (BOS, EOS, padding) [9906, 1917] → [1, 9906, 1917, 2]

Decoder Converts token IDs back to text [9906, 1917] → "hello world"

Each component is independent. You can swap normalizers or change the algorithm without rewriting everything else.

You can access the rust based tokenizer through _tokenizer. We go in more depth about it in this section

from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("google/gemma-3-270m-it")

print(f"{tokenizer._tokenizer.normalizer=}")

print(f"{tokenizer._tokenizer.pre_tokenizer=}")

print(f"{tokenizer._tokenizer.model=}")

print(f"{tokenizer._tokenizer.post_processor=}")

print(f"{tokenizer._tokenizer.decoder=}")

Tokenization algorithms

The following algorithms dominate modern language model tokenizers:

Byte Pair Encoding (BPE) iteratively merges the most frequent character pairs. This algorithm is deterministic and widely used. (Read more about BPE)

from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("openai/gpt-oss-20b")
print(tokenizer._tokenizer.model)

Unigram takes a probabilistic approach, selecting the most likely segmentation from a large initial vocabulary. This is more flexible than the strict BPE. (Read more about Unigram)

from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("google-t5/t5-base")
print(tokenizer._tokenizer.model)

WordPiece resembles BPE but uses different merge criteria based on likelihood. (Read more about WordPiece)

from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("bert-base-uncased")
print(tokenizer._tokenizer.model)

Accessing tokenizers through transformers

The tokenizers library is a Rust-based tokenization engine. It is fast, efficient, and completely language model agnostic. The library handles the mechanics of converting text into token IDs and back. The tokenizers library is a general-purpose tool that implements the tokenization algorithms, but does not implement the conventions that connect those algorithms to specific language models.

Consider what happens when you use tokenizers directly with the SmolLM3-3B model:

from tokenizers import Tokenizer

tokenizer = Tokenizer.from_pretrained("HuggingFaceTB/SmolLM3-3B")
text = "Hello world"
encodings = tokenizer.encode(text)

print(encodings.ids)

print(encodings.tokens)

The output is raw tokenization. You get token IDs and the string pieces they correspond to. Nothing more.

Now consider what's missing. The SmolLM3-3B is a conversational model. When you interact with it, you typically structure your input as a conversation with roles like "user" and "assistant". The language model expects special formatting tokens to indicate these roles. The raw tokenizers library has no concept of any of this.

How do you bridge the gap between raw tokenization and model requirements?

The transformers library bridges this gap. The library is primarily known as a model definition library, but it also provides a tokenizer abstraction layer that wraps the raw tokenizers backend and adds model-aware functionality.

Here's the same tokenization with the transformers wrapper:

from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("HuggingFaceTB/SmolLM3-3B")

prompt = "Give me a brief explanation of gravity in simple terms."
messages = [{"role": "user", "content": prompt}]
text = tokenizer.apply_chat_template(
messages,
tokenize=False,
add_generation_prompt=True,
)

print(text)

model_inputs = tokenizer([text], add_special_tokens=False, return_tensors="pt")

Notice how the special tokens like <|im_start|> and <|im_end|> are applied to the prompt before tokenizing. This is useful for the model to learn where a new sequence starts and ends.

The transformers tokenizer adds everything the raw library lacks:

Chat template application. The apply_chat_template method formats conversations according to the model's expected format, inserting the correct special tokens and delimiters.

Automatic special token insertion. Beginning-of-sequence and end-of-sequence tokens are added where the model expects them.

Truncation to context length. You can specify truncation=True and the tokenizer will respect the model's maximum sequence length.

Batch encoding with padding. Multiple inputs can be padded to the same length with the correct padding token and direction.

Return format options. You can request PyTorch tensors (return_tensors="pt"), NumPy arrays and others.

transformers implements the tokenization API that is most commonly used in the entire ML community (encode, decode, convert_tokens_to_ids, etc.)

The tokenizer class hierarchy in transformers

The transformers library organizes tokenizers into a class hierarchy. At the top sits a base class that defines the common interface. Below it, backend classes handle the actual tokenization using different engines. At the bottom, model-specific classes configure the backends for particular models.

The class hierarchy for tokenizers inside transformers

PreTrainedTokenizerBase defines the common interface for all tokenizers

PreTrainedTokenizerBase is the abstract base class for all tokenizers in transformers. It defines the interface that every tokenizer must implement.

The base class handles functionality that doesn't depend on the tokenization backend:

Special token properties. Properties like bos_token, eos_token, pad_token, and unk_token are defined here. These properties provide access to the special tokens that models use to mark sequence boundaries and handle unknown inputs.

Encoding interface. The __call__ method, encode, and encode_plus methods are defined here. These methods accept text input and return token IDs along with attention masks and other metadata.

Decoding interface. The decode and batch_decode methods convert token IDs back to text.

Serialization. The save_pretrained and from_pretrained methods handle downloading the correct files, reading information, saving tokenizers to disk etc.

Chat template support. The apply_chat_template method lives here, formatting conversations according to Jinja templates stored in the tokenizer configuration.

Every tokenizer in transformers ultimately inherits from PreTrainedTokenizerBase. The base class ensures consistent behavior across all tokenizers, regardless of which backend they use for the actual tokenization.

TokenizersBackend wraps the tokenizers library

TokenizersBackend is the primary backend class for most modern tokenizers. It inherits from PreTrainedTokenizerBase and wraps the Rust-based tokenizers library.

The class stores the Rust tokenizer object internally:

class TokenizersBackend(PreTrainedTokenizerBase):
def __init__(self, tokenizer_object, ...):
self._tokenizer = tokenizer_object
...

When you call encoding methods on a TokenizersBackend tokenizer, the class delegates the actual tokenization to the Rust backend:

def _batch_encode_plus(self, batch_text_or_text_pairs, ...):
encodings = self._tokenizer.encode_batch(batch_text_or_text_pairs, ...)
...

The Rust backend performs computationally intensive work, while the Python wrapper adds the model-aware features on top.

Many model-specific tokenizers inherit from TokenizersBackend, examples include:

LlamaTokenizer

GemmaTokenizer

These model-specific classes configure the backend with the correct vocabulary, merge rules, special tokens, and normalization settings for their respective models.

PythonBackend provides a pure-Python mixin

PythonBackend inherits from PreTrainedTokenizerBase and implements tokenization in pure Python. The class is aliased as PreTrainedTokenizer.

The pure-Python backend exists for several reasons:

Custom tokenization logic. Some models require tokenization behavior that doesn't fit the standard tokenizers pipeline.

Legacy compatibility. Older model implementations may rely on Python-specific behavior.

The Python backend is slower than the Rust backend. For most use cases, the Rust-backed TokenizersBackend is preferred.

Model-specific tokenizers that inherit from PythonBackend (or its alias PreTrainedTokenizer) include some older or specialized models, like:

CTRLTokenizer

CanineTokenizer

SentencePieceBackend handles SentencePiece models

SentencePieceBackend inherits from PythonBackend and provides integration with Google's SentencePiece library. SentencePiece is a standalone tokenization library that many models use, particularly those trained by Google.

The backend wraps a SentencePiece processor:

class SentencePieceBackend(PythonBackend):
def __init__(self, vocab_file, ...):
self.sp_model = spm.SentencePieceProcessor()
self.sp_model.Load(vocab_file)
...

Models that use SentencePiece tokenization inherit from this backend. Examples include:

SiglipTokenizer

BartphoTokenizer

The SentencePiece backend inherits from PythonBackend rather than directly from PreTrainedTokenizerBase because it shares much of the same interface and padding/truncation logic.

AutoTokenizer automatically selects the correct tokenizer class

AutoTokenizer is the recommended entry point for loading tokenizers. It automatically determines which tokenizer class to use for a given model and returns an instance of that class.

from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("gpt2")

Behind the scenes, AutoTokenizer performs these steps:

Download the tokenizer configuration. The from_pretrained method fetches tokenizer_config.json from the Hub (or from a local directory).

Identify the model type. The configuration contains metadata that identifies the model type (e.g., "gpt2", "llama", "bert").

Look up the tokenizer class. AutoTokenizer maintains a mapping called TOKENIZER_MAPPING_NAMES that maps model types to tokenizer class names:

TOKENIZER_MAPPING_NAMES = {
"gpt2": "GPT2Tokenizer",
"llama": "LlamaTokenizer",
"bert": "BertTokenizer",
...
}

Instantiate the correct class. AutoTokenizer imports the appropriate tokenizer class and calls its from_pretrained method.

Return the configured tokenizer. You receive a fully configured, model-specific tokenizer ready for use.

The benefit of AutoTokenizer is that you don't need to know which tokenizer class a model uses. Whether a model uses LlamaTokenizer, GPT2Tokenizer, or BertTokenizer, the same AutoTokenizer.from_pretrained("model-name") call works.

The tokenizer system in transformers forms a layered architecture:

Layer Component Responsibility

Entry Point AutoTokenizer Automatically selects and instantiates the correct tokenizer class

Model-Specific LlamaTokenizer, GPT2Tokenizer, etc. Configures the backend with model-specific architecture of normalizer, pre tokenizer, etc, special tokens, and settings

Backend TokenizersBackend, PythonBackend, SentencePieceBackend Implements the actual tokenization using a specific engine

Base PreTrainedTokenizerBase Defines the common interface and shared functionality

Engine tokenizers (Rust), SentencePiece, Pure Python Performs raw tokenization

v5 Separates Tokenizer Architecture from Trained Vocab

The most significant change in Transformers v5 is a philosophical shift in how tokenizers are defined. Tokenizers now work like PyTorch's nn.Module: you define the architecture first, then fill it with learned parameters.

The problem with v4: tokenizers were opaque and tightly coupled

In v4, tokenizers were black boxes tied to pretrained checkpoint files. If you loaded LlamaTokenizerFast, you couldn't easily answer basic questions about it:

Is it BPE or Unigram?

How does it normalize text?

What pre-tokenization strategy does it use?

What are the special tokens and their positions?

The __init__ method gave no clues. You had to dig through serialized files or external documentation to understand what the tokenizer actually did.

LlamaTokenizerFast as seen in v4 transformers

v4 also maintained two parallel implementations for every model:

a "slow" Python tokenizer (LlamaTokenizer inheriting from PreTrainedTokenizer) and

a "fast" Rust-backed tokenizer (LlamaTokenizerFast inheriting from PreTrainedTokenizerFast).

This meant:

Two files per model (e.g., tokenization_llama.py and tokenization_llama_fast.py)

Code duplication across hundreds of models

Behavioral discrepancies between slow and fast versions, leading to subtle bugs

A growing test suite dedicated to verifying that slow and fast tokenizers produced identical outputs

User confusion about which tokenizer to use and when

Worst of all, you couldn't create an empty tokenizer architecture. If you wanted to train a LLaMA-style tokenizer on your own data, there was no clean way to instantiate a "blank" LLaMA tokenizer and fill it with your vocabulary and merges. Tokenizers existed only as loaded checkpoints, not as configurable templates.

The v5 solution: architecture and parameters are now separate

v5 treats tokenizer architecture (normalizer, pre-tokenizer, model type, post-processor, decoder) as distinct from trained parameters (vocabulary, merges). This mirrors how PyTorch separates model architecture from learned weights.

With nn.Module, you define layers first:

from torch import nn

model = nn.Sequential(
nn.Embedding(vocab_size, embed_dim),
nn.Linear(embed_dim, hidden_dim),
)

V5 tokenizers follow the same pattern:

from transformers import LlamaTokenizer

tokenizer = LlamaTokenizer()

tokenizer.train(files=["my_corpus.txt"])

The tokenizer class now explicitly declares its structure. Looking at LlamaTokenizer in v5, you can immediately see:

It uses BPE as its tokenization model

It may add a prefix space before text

Its special tokens (unk, bos, eos) sit at specific vocabulary positions

It does not normalize input text

Its decoder replaces the metaspace character ▁ with spaces

LlamaTokenizer as seen in v5 transformers

This transparency was impossible in v4, where the same information was buried in serialized files.

One file, one backend, one recommended path

v5 consolidates the two-file system into a single file per model. LlamaTokenizer now inherits from TokenizersBackend, which wraps the Rust-based tokenizer that was previously exposed as the “fast” implementation and is now the default.

The former “slow” Python implementation lives explicitly behind PythonBackend, and SentencePieceBackend remains for models that require it, but Rust-backed tokenization is the preferred default.

This change eliminates:

Duplicate code across slow/fast implementations

The confusing Tokenizer vs TokenizerFast naming convention

Test suites dedicated to checking slow-fast parity

Users now have one clear entry point. Advanced users who need to customize can still access lower-level components, but the library no longer forces everyone to navigate two parallel implementations.

You can now train model specific tokenizers from scratch

Suppose you want a tokenizer that behaves exactly like LLaMA's – same normalization, same pre-tokenization, same BPE model type – but trained on a domain-specific corpus (medical text, legal documents, a new language). In v4, this required manually reconstructing the tokenizer pipeline from low-level tokenizers library primitives. In v5, you can instantiate the architecture directly and call train:

from transformers import LlamaTokenizer
from datasets import load_dataset

tokenizer = LlamaTokenizer()

dataset = load_dataset("wikitext", "wikitext-2-raw-v1", split="train")

def get_training_corpus():
batch = 1000
for i in range(0, len(dataset), batch):
yield dataset[i : i + batch]["text"]

trained_tokenizer = tokenizer.train_new_from_iterator(
text_iterator=get_training_corpus(),
vocab_size=32000,
length=len(dataset),
show_progress=True,
)

trained_tokenizer.push_to_hub("my_custom_tokenizer")

tokenizer = LlamaTokenizer.from_pretrained("my_custom_tokenizer")

The resulting tokenizer will have your custom vocabulary and merge rules, but will process text identically to how a standard LLaMA tokenizer would with the same whitespace handling, same special token conventions, same decoding behavior.

Aspect V4 V5

Files per model Two (tokenization_X.py, tokenization_X_fast.py) One (tokenization_X.py)

Default backend Split between Python and Rust Rust (TokenizersBackend) preferred

Architecture visibility Hidden in serialized files Explicit in class definition

Training from scratch Required manual pipeline construction tokenizer.train(files=[...])

Component inspection Difficult, undocumented Direct properties (tokenizer.normalizer, etc.)

Parent classes PreTrainedTokenizer, PreTrainedTokenizerFast TokenizersBackend (or SentencePieceBackend, PythonBackend)

The shift from "tokenizers as loaded checkpoints" to "tokenizers as configurable architectures" makes the library more modular, more transparent, and more aligned with how practitioners think about building ML systems.

Summary

Transformers v5 brings three improvements to tokenization:

One file per model instead of separate slow/fast implementations

Visible architecture so you can inspect normalizers, pre-tokenizers, and decoders

Trainable templates that let you create custom tokenizers matching any model's design

The wrapper layer between tokenizers and Transformers remains essential. It adds model awareness, context lengths, chat templates, special tokens, that raw tokenization doesn't provide. V5 just makes that layer clearer and more customizable.

If you are looking to learn more about tokenization here are some resources:

Let's build the GPT Tokenizer

Gotchas in Tokenizer Behavior Every Developer Should Know

Chat Templates

A list of resources we have gathered from the community!

Models mentioned in this article 2

Spaces mentioned in this article 1

More Articles from our Blog

transformersv5community

Hot

Transformers v5: Simple model definitions powering the AI ecosystem

311

December 1, 2025

torchprofileCUDA

Profiling in PyTorch (Part 2): From nn.Linear to a Fused MLP

+1

34

June 11, 2026

Community

FHSEOHub

Dec 20, 2025

I think it depends on the nature of tools

·

ariG23498

Article author Dec 23, 2025

What depends on the nature of tools? 😳

deleted

Dec 21, 2025

This comment has been hidden

Sifal

Jan 10

Thanks for doing this! I had to train some tokenizers with the v4, it was indeed not straightforward to understand the behavior.

I had two questions:

You said: older model implementations may rely on Python-specific behavior.
Curious if you had any example

You sometimes say "fast" (between quotes) is it just to refer to the fastTokenizers backend or can the implementation actually be slower than the python implementation because of some kind of rust overhead?

·

ariG23498

Article author Jan 12

Glad that this was useful to you.

All the classes that extend the PreTrainedTokenizer (which is an alias to the PythonBackend will serve as you examples. (GitHub Search)

The rust backend is faster compare to the other implementations.

· or to comment

Models mentioned in this article 2

Spaces mentioned in this article 1