Bài 1 của series này nói qua tokenization: text vào → list số nguyên ra. Đủ để hiểu pipeline tổng quát. Nhưng có một chi tiết bị bỏ qua — thuật toán nào quyết định cách cắt? Và tại sao cùng một câu tiếng Việt, GPT-4 tốn 38 tokens còn một model khác tốn 19?

Câu trả lời nằm ở tokenizer. Không phải model, không phải prompt engineering. Tokenizer.

GPT-4 dùng cl100k_base — một biến thể byte-level BPE của OpenAI. Llama-3 dùng tiktoken custom với vocab 128k. Gemini dùng SentencePiece Unigram. BERT dùng WordPiece của Google từ 2012. Mỗi cái sinh ra số tokens khác nhau cho cùng một input — và vì API tính tiền theo token, context window tính theo token, mọi giới hạn tính theo token, tokenizer ảnh hưởng trực tiếp đến cost và capability.

Bài này đi qua ba thuật toán phổ biến nhất: BPE, WordPiece, SentencePiece. Kèm code chạy được để so sánh thực tế.

Tại sao không dùng từ hoặc ký tự?

Trước khi vào thuật toán, cần hiểu tại sao subword tokenization tồn tại. Có hai extreme hiển nhiên, và cả hai đều không dùng được trong thực tế.

Character-level: Cắt text thành từng ký tự một. Vocabulary chỉ vài trăm entries (26 chữ cái + số + punctuation + Unicode). Nghe nhỏ gọn, nhưng câu “Hello world” thành 11 tokens thay vì 2-3. Câu dài 500 ký tự thành 500 tokens. Attention mechanism phải xử lý sequence dài gấp nhiều lần — tốn quadratic memory theo sequence length. Không scale được.

Word-level: Cắt theo khoảng trắng, mỗi từ là một token. Đẹp về mặt trực giác. Nhưng vocabulary sẽ chứa hàng triệu entries — mỗi dạng biến thể của từ (run, runs, running, ran) là một entry riêng. Tiếng Việt hay tiếng Đức (ghép từ rất dài) sẽ bùng nổ. Vấn đề nghiêm trọng hơn: OOV (out-of-vocabulary) — từ chưa thấy trong training thì model không có token ID, không xử lý được.

Sweet spot — subword tokenization: Chia text thành đơn vị trung gian, lớn hơn ký tự nhưng nhỏ hơn từ. Common subword sequences được giữ nguyên (ing, tion, un-), rare words bị cắt nhỏ nhưng không hoàn toàn biến mất. Vocabulary khoảng 30k-128k entries — đủ lớn để linh hoạt, đủ nhỏ để model học được.

Word-level:   "running" → [running]        (1 token, nhưng OOV nếu chưa thấy)
Char-level:   "running" → [r,u,n,n,i,n,g] (7 tokens, quá dài)
Subword:      "running" → [run, ##ning]    (2 tokens, cân bằng)

Ba thuật toán dưới đây đều implement subword approach, nhưng theo cách khác nhau.

Phần 1: BPE — Byte Pair Encoding

BPE không phải thuật toán mới. Nó đến từ năm 1994 — Philip Gage viết nó như một thuật toán nén văn bản: tìm cặp bytes xuất hiện nhiều nhất, thay bằng một byte chưa dùng, lặp lại. Compress. Đơn giản.

Năm 2016, Rico Sennrich et al. tái áp dụng BPE cho Neural Machine Translation trong paper “Neural Machine Translation of Rare Words with Subword Units”. Thay vì nén để giảm size, họ dùng merge operations để học vocabulary. Từ đó BPE thành standard cho NLP.

Thuật toán BPE training:

Bắt đầu từ corpus training. Giả sử corpus chứa các từ sau (với frequency):

low:  5 lần
lower: 2 lần
lowest: 6 lần
newer: 3 lần
wider: 2 lần

Bước 1: Tách mỗi từ thành ký tự, thêm ký tự </w> để đánh dấu cuối từ:

l o w </w>       : 5
l o w e r </w>   : 2
l o w e s t </w> : 6
n e w e r </w>   : 3
w i d e r </w>   : 2

Bước 2: Đếm tất cả cặp ký tự liền nhau. Cặp (e, r) xuất hiện 2 + 3 + 2 = 7 lần — nhiều nhất. Merge:

l o w </w>       : 5
l o w er </w>    : 2
l o w e s t </w> : 6
n e w er </w>    : 3
w i d er </w>    : 2

Bước 3: Lặp lại. Tiếp theo (l, o) merge thành lo, rồi (lo, w) merge thành low, v.v. Sau mỗi merge, vocabulary tăng thêm một entry.

Quá trình tiếp tục cho đến khi đạt vocab size mục tiêu (thường 30k-100k merges). Mỗi merge rule được lưu lại theo thứ tự — đây là tokenizer đã được train.

BPE inference (encode một text mới):

Cắt text thành ký tự, áp dụng merge rules theo đúng thứ tự đã học. Rules học trước được apply trước. Text chưa thấy trong training vẫn tokenize được vì cuối cùng có thể fallback về ký tự đơn.

Byte-level BPE (biến thể của OpenAI):

GPT-2, GPT-3, GPT-4 dùng một biến thể quan trọng: thay vì bắt đầu từ Unicode characters, bắt đầu từ bytes. Mọi Unicode character đều biểu diễn được qua 1-4 bytes UTF-8. Vocabulary bắt đầu với 256 entries (tất cả giá trị byte có thể), sau đó merge. Kết quả: không có token nào là “unknown” — mọi text trên thế giới đều tokenize được, kể cả emoji, ký tự Nhật, hay binary data.

Đây là lý do cl100k_base của GPT-4 hoạt động với mọi ngôn ngữ — kể cả ngôn ngữ chưa từng thấy trong training. Chi phí là tiếng Việt hay tiếng Thái tốn nhiều bytes hơn (dấu UTF-8 multi-byte), nên tốn nhiều tokens hơn English.

Phần 2: WordPiece

WordPiece ra đời năm 2012 tại Google, ban đầu cho hệ thống nhận dạng giọng nói tiếng Nhật và Hàn. Sau đó được áp dụng rộng rãi cho BERT (2018) và trở thành thuật toán gắn liền với dòng model BERT/RoBERTa.

Về cơ bản, WordPiece cũng là merge-based như BPE. Điểm khác biệt chính: tiêu chí chọn cặp để merge khác nhau.

BPE chọn cặp có frequency cao nhất (xuất hiện nhiều nhất trong corpus).

WordPiece chọn cặp maximize likelihood của toàn bộ corpus theo một language model đơn giản. Cụ thể, score của một cặp (A, B) được tính là:

score(A, B) = freq(AB) / (freq(A) * freq(B))

Mẫu số là tích frequency của từng phần riêng lẻ. Điều này có nghĩa: WordPiece ưu tiên merge các ký tự mà khi đứng riêng rất hiếm, nhưng cùng nhau lại phổ biến. Thay vì chỉ đếm tần suất tuyệt đối, nó đo mức độ “kết dính” của hai phần.

Ký hiệu đặc biệt ##:

WordPiece dùng prefix ## để đánh dấu các subword không phải đầu từ. Ví dụ:

"unaffable"  →  ["un", "##aff", "##able"]
"running"    →  ["running"]           # từ có trong vocab
"tokenizing" →  ["token", "##izing"]

Prefix ## giúp model biết context: "##ing" là hậu tố (suffix) khác với "ing" đứng đầu từ. Khi decode ngược lại, gặp ## thì bỏ dấu cách.

Trade-off so với BPE:

WordPiece phức tạp hơn để train (cần compute likelihood mỗi bước). Nhưng với ngôn ngữ có morphology phong phú — tiếng Đức, tiếng Thổ Nhĩ Kỳ, ngôn ngữ có nhiều prefix/suffix — WordPiece thường cho subword segmentation tự nhiên hơn vì nó tìm cách gộp các morpheme (đơn vị nghĩa nhỏ nhất của từ) với nhau.

BERT vocabulary 30,522 tokens (30k). Đủ để bao phủ tiếng Anh tốt. Nhưng khi BERT chạy trên tiếng Việt hoặc tiếng Trung, nhiều ký tự không có trong vocab → tokenize kém hiệu quả hơn.

Phần 3: SentencePiece

BPE và WordPiece đều có một giả định ngầm: text đã được split theo whitespace trước. Tiếng Anh thì ổn — từ cách nhau bởi dấu cách. Nhưng tiếng Trung, tiếng Nhật, tiếng Thái không có dấu cách giữa từ. Và tiếng Ả-rập viết liền khối. Pre-tokenize các ngôn ngữ đó cần tool riêng — pipeline phức tạp, lỗi phụ thuộc vào tokenizer ngôn ngữ, khó deploy.

Google Research giải quyết vấn đề này với SentencePiece (2018, Kudo & Richardson). Ý tưởng cốt lõi: treat raw text as a sequence of Unicode characters, không pre-tokenize gì cả. Kể cả whitespace cũng là một ký tự thông thường — được encode thành ký hiệu _ (underscore). Kết quả: pipeline đơn giản hơn, ngôn ngữ-agnostic, reproducible.

SentencePiece hỗ trợ hai mode:

Mode 1 — BPE: Giống thuật toán BPE đã mô tả, nhưng áp dụng trên raw Unicode characters thay vì pre-tokenized words. Whitespace được xử lý như ký tự bình thường.

Mode 2 — Unigram Language Model: Đây là điểm phân biệt SentencePiece với BPE và WordPiece. Thay vì bắt đầu nhỏ và merge (bottom-up), Unigram bắt đầu với vocab rất lớn (thường hàng trăm nghìn entries), rồi iteratively prune — loại bỏ các tokens ít đóng góp nhất cho likelihood của corpus.

Unigram training:
1. Khởi tạo vocab lớn (ví dụ: tất cả substrings có frequency >= ngưỡng)
2. Với mỗi token trong vocab:
   - Tính loss nếu xoá token này (model buộc phải tokenize bằng cách khác)
3. Xoá p% tokens có loss thấp nhất (ít ảnh hưởng nếu bỏ)
4. Lặp lại đến khi đạt vocab size mục tiêu

Unigram inference dùng Viterbi algorithm để tìm cách tokenize tối ưu — chuỗi tokens có tổng log-probability cao nhất.

Tại sao T5, Gemini, Llama-1/2 chọn SentencePiece:

Multilingual từ đầu. Không phụ thuộc whitespace tokenizer của ngôn ngữ cụ thể. Model có thể train trên 100 ngôn ngữ trong cùng một corpus mà không cần custom pre-processor cho từng ngôn ngữ. Đây là lý do SentencePiece trở thành default cho các model đa ngôn ngữ lớn.

Phần 4: So sánh thực tế

TokenizerDùng bởiVocab sizeĐặc điểm
BPE byte-levelGPT-2, GPT-3, GPT-4 (cl100k_base)50k / 100kRobust mọi Unicode, không có unknown token
tiktoken customLlama-3, Mistral128kFast Rust implementation, byte-level BPE
WordPieceBERT, DistilBERT, RoBERTa30k## prefix, tốt cho morphology
SentencePiece BPEALBERT, XLM-R32k-250kNgôn ngữ-agnostic, không cần pre-tokenize
SentencePiece UnigramT5, mT5, Gemini, Llama-1/232k-256kProbabilistic, optimal segmentation

Một điểm dễ nhầm: tiktoken (thư viện Python của OpenAI) và BPE là hai thứ khác nhau. tiktoken là implementation (viết bằng Rust, rất nhanh), còn BPE là algorithm. tiktoken implement byte-level BPE cho nhiều encoding: cl100k_base (GPT-4), o200k_base (GPT-4o), p50k_base (GPT-3). Llama-3 dùng tiktoken để implement tokenizer của nó với vocab riêng 128k.

Vocab size quan trọng vì nó ảnh hưởng đến:

  • Model size: Embedding matrix lưu vocab_size × embedding_dim params. Vocab 128k với dim 4096 = 512M params chỉ cho embedding — đáng kể.
  • Tokenization efficiency: Vocab lớn hơn → ít tokens hơn cho cùng một text → context window dài hơn “hiệu quả”.
  • Rare language coverage: Vocab nhỏ (30k train trên English) sẽ tokenize tiếng Việt kém hơn vocab lớn train trên multilingual data.

Phần 5: Hands-on — so sánh tokenizers trên text Việt và English

Install tiktoken:

pip install tiktoken
import tiktoken

# GPT-4 encoding
gpt4 = tiktoken.get_encoding("cl100k_base")

texts = [
    "Hello world, how are you doing today?",
    "Xin chào thế giới, bạn khỏe không?",
    "xin chao the gioi ban khoe khong",
    "The transformer architecture uses multi-head attention.",
    "Kiến trúc transformer dùng multi-head attention.",
    "kien truc transformer dung multi-head attention",
]

print(f"{'Text':45} | {'chars':>5} | {'tokens':>6} | {'t/c':>5}")
print("-" * 70)
for t in texts:
    tokens = gpt4.encode(t)
    ratio = len(tokens) / len(t)
    print(f"{t[:45]:45} | {len(t):5} | {len(tokens):6} | {ratio:.3f}")

Output thực tế (chạy trên cl100k_base):

Text                                          | chars | tokens |   t/c
----------------------------------------------------------------------
Hello world, how are you doing today?         |    37 |      9 | 0.243
Xin chào thế giới, bạn khỏe không?           |    35 |     23 | 0.657
xin chao the gioi ban khoe khong              |    33 |      9 | 0.273
The transformer architecture uses multi-...  |    53 |      8 | 0.151
Kiến trúc transformer dùng multi-head a...   |    47 |     21 | 0.447
kien truc transformer dung multi-head at...  |    47 |     10 | 0.213

Số liệu này minh họa ba pattern rõ ràng:

Pattern 1 — Dấu tiếng Việt là “đắt”: Câu tiếng Việt có dấu tốn 0.657 tokens/char, gấp gần 3 lần English (0.243). Lý do: ký tự có dấu như ề, ặ, ổ encode thành multi-byte UTF-8, và BPE vocabulary của cl100k_base train trên English-dominant data không có sẵn merge rule cho các byte sequence đó → phải split nhiều tokens.

Pattern 2 — Tiếng Việt không dấu bằng English: "xin chao the gioi ban khoe khong" tốn 9 tokens — tương đương English thuần. Đây là lý do nhiều dev gõ không dấu khi chat nhanh với LLM. Không phải lười — là optimize token count.

Pattern 3 — Technical terms giữ nguyên tiết kiệm: "transformer", "multi-head attention" là English, tokenizer học tốt → ít tokens. Câu mix Việt-English technical thường hiệu quả hơn pure tiếng Việt.

Để xem raw tokens (không chỉ count):

text = "Xin chào thế giới"
tokens = gpt4.encode(text)
print(tokens)
# [55, 258, 39356, 103, 128, 99, 99, 105, 224, 99, 32, 99, 116, ...]
# Nhiều token cho chuỗi ký tự ngắn

# Decode từng token để xem cắt ở đâu
for tok in tokens:
    print(repr(gpt4.decode([tok])), end=" | ")

Benchmark chi tiết hơn về Vietnamese token efficiency trong thực tế sử dụng (5626 prompts, 555 sessions) có thể xem tại bài Tiếng Việt tốn hơn x2 token? Data nói khác — kết quả đi ngược một số claim phổ biến.

Phần 6: Implications cho dev

1. API cost là thật và tokenizer quyết định nó

OpenAI tính giá per token, không per character, không per word. Nếu bạn build một feature xử lý document tiếng Việt, cùng một document sẽ tốn khác nhau tùy model. GPT-4o với o200k_base (vocab 200k, train multilingual nhiều hơn) sẽ tokenize tiếng Việt hiệu quả hơn so với GPT-3.5 với cl100k_base.

Trước khi build production feature, benchmark tokenization với actual data domain của bạn:

import tiktoken

def estimate_cost(text, encoding_name="cl100k_base", cost_per_1k=0.01):
    enc = tiktoken.get_encoding(encoding_name)
    n_tokens = len(enc.encode(text))
    return n_tokens, n_tokens / 1000 * cost_per_1k

with open("sample_document.txt") as f:
    content = f.read()

tokens, cost = estimate_cost(content)
print(f"Tokens: {tokens}, estimated cost: ${cost:.4f}")

2. Context window limit là về tokens, không chars

GPT-4 context window 128k tokens. Nếu bạn nhét một file PDF tiếng Việt 100 trang vào, nó có thể không fit — vì tiếng Việt có dấu tốn 2.5-3x tokens so với English cùng độ dài. Một trang A4 tiếng Việt dày đặc có thể tốn 600-800 tokens.

Khi thiết kế RAG hoặc summarization pipeline, tính toán token budget với actual tokenizer của model bạn dùng, không phải estimate theo char count.

3. Khi chọn model cho multilingual task

Model train tokenizer trên multilingual corpus sẽ xử lý tiếng Việt tốt hơn. Không chỉ về độ chính xác mà còn về token efficiency. Llama-3 với tiktoken 128k train trên nhiều ngôn ngữ hơn sẽ tokenize tiếng Việt ít tốn hơn BERT vocabulary 30k English-dominant.

Nếu bạn serving một LLM open-source tự host cho user tiếng Việt, tokenizer là một tiêu chí chọn model — bên cạnh benchmark NLP thuần.

4. Khi train model mới (fine-tuning hoặc từ đầu)

Nếu domain data của bạn khác nhiều so với pre-training data (ví dụ: medical records tiếng Việt, legal documents, code trong một ngôn ngữ lập trình obscure), có thể training tokenizer mới trên domain data sẽ cho hiệu quả tốt hơn.

Sentencepiece cho phép train tokenizer mới hoàn toàn:

import sentencepiece as spm

spm.SentencePieceTrainer.train(
    input='domain_corpus.txt',
    model_prefix='domain_tokenizer',
    vocab_size=32000,
    model_type='bpe',     # hoặc 'unigram'
    character_coverage=0.9999,  # cho non-Latin scripts
)

Đây là bước các team NLP làm khi adapt model cho ngôn ngữ mới hoặc domain chuyên biệt.

5. Debugging weird model output

Khi model output sai lạ theo cách khó giải thích — nhầm số, cắt giữa chừng, không nhận ra entity name — tokenization thường là suspect đầu tiên. Kiểm tra:

text = "GPT-4o-mini"
tokens = enc.encode(text)
for tok in tokens:
    print(repr(enc.decode([tok])), end=" | ")
# 'GPT' | '-' | '4' | 'o' | '-' | 'mini' |
# Tên model bị split thành 6 tokens — model có thể "đọc" khác nhau

Nếu một entity quan trọng bị split theo cách kỳ lạ, có thể cần viết lại prompt để entity đó tokenize thành ít tokens hơn, hoặc thêm context cho model.

Cheatsheet

Ba thuật toán:

AlgorithmCách build vocabHướngSpecial
BPEMerge cặp frequent nhấtBottom-up (char → merge)Byte-level variant cho Unicode robustness
WordPieceMerge cặp maximize likelihoodBottom-up (char → merge)## prefix cho non-initial subwords
Unigram (SentencePiece)Prune vocab lớn về vocab targetTop-down (large → prune)Probabilistic, optimal via Viterbi

Tokenizers trong thực tế:

ModelTokenizer libAlgorithmVocab size
GPT-4, GPT-4otiktoken cl100k_baseByte-level BPE100,277
GPT-4o (mới)tiktoken o200k_baseByte-level BPE200,019
Llama-3tiktoken customByte-level BPE128,256
BERTHuggingFace tokenizersWordPiece30,522
T5, mT5SentencePieceUnigram32,000
GeminiSentencePieceUnigram256,000
Llama-1, Llama-2SentencePieceBPE32,000

5 điểm phải nhớ:

  • Tokenizer train trên English-dominant data sẽ tokenize tiếng Việt kém hiệu quả hơn (tốn nhiều tokens hơn cho cùng nội dung)
  • Vocab size lớn hơn không tự động nghĩa là tốt hơn — trade-off với model size
  • BPE byte-level không có “unknown token” — mọi text đều tokenize được
  • API cost, context limit, và multilingual support đều phụ thuộc trực tiếp vào tokenizer
  • Khi debugging model behavior kỳ lạ, kiểm tra tokenization của input trước

Lời kết

Bây giờ bạn biết text thực sự biến thành tokens như thế nào — không phải magic, là thuật toán merge hoặc prune có thể code được. BPE: start small, merge greedily. WordPiece: start small, merge by likelihood. SentencePiece Unigram: start big, prune iteratively.

Bài 7 sẽ đi vào phần thực hành nặng nhất của tokenization: build BPE tokenizer từ đầu bằng Python thuần, theo cách Andrej Karpathy làm trong minbpe. Không dùng thư viện nào ngoài standard library. Sau bài đó, bạn sẽ hiểu tại sao merge rules được lưu theo thứ tự, tại sao encode nhanh hơn train, và tại sao một số ký tự Unicode “đắt” hơn những cái khác ở mức bytes.

Trong lúc chờ, có một bài tập ngắn: install tiktoken, lấy 5-10 prompt bạn thường gửi cho LLM nhất, chạy encode(), đếm tokens. Tính chi phí thực tế nếu dùng GPT-4o (input price theo token). Thường kết quả khác khá nhiều so với ước tính “viết ngắn là rẻ”.

import tiktoken

enc = tiktoken.get_encoding("o200k_base")  # GPT-4o

prompt = """Hãy review code này và cho tôi biết..."""  # prompt của bạn
tokens = enc.encode(prompt)
print(f"Tokens: {len(tokens)}")
print(f"GPT-4o cost (input): ${len(tokens) / 1_000_000 * 2.50:.6f}")  # $2.50/1M tokens

Tokenizer là layer zero của mọi LLM system. Hiểu nó là hiểu tại sao model behave theo cách nó đang làm.