Tokenizer đang thành mặt trận mới

Tokenizer đang thành mặt trận mới

Gigatoken không chỉ là một benchmark nhanh. Nó là tín hiệu rằng bottleneck AI đang trôi từ model sang lớp dữ liệu, tiền xử lý và vận hành.

“Ủa, sao job chuẩn bị dữ liệu chạy lâu hơn cả train thử model?” — câu này mình nghe trong một buổi review pipeline, lúc cả team đang nhìn dashboard như nhìn mặt biển lúc mất sóng.

Không ai đổ lỗi cho tokenizer trước tiên. Người ta sẽ nghi GPU thiếu, model nặng, vector database chậm, network nghẽn, hoặc batch size sai. Tokenizer thường nằm ở góc khuất: một bước “chuyển chữ thành token” nghe nhỏ xíu, nên ít ai profile nghiêm túc.

Rồi Gigatoken xuất hiện với một cú đập khá mạnh vào thói quen đó: tokenization có thể là bottleneck thật, và nếu bạn đang xây hệ thống AI ở quy mô lớn, bỏ qua nó giống như lái tàu chỉ nhìn hải đăng phía xa mà quên kiểm tra mỏ neo đang kéo dưới nước.

Sơ đồ minh họa cho bài Tokenizer đang thành mặt trận mới

Sơ đồ tóm tắt ý chính của bài viết.

Tín hiệu lạ: tốc độ không còn chỉ nằm ở model

Gigatoken là một BPE tokenizer viết bằng Rust, có Python bindings. Tokenizer là lớp biến văn bản thành token để model xử lý; BPE là kiểu tách chữ phổ biến bằng cách ghép các cụm byte hoặc ký tự hay đi cùng nhau. Python bindings nghĩa là lõi chạy bằng Rust nhưng gọi được từ Python.

Con số gây chú ý: benchmark GPT-2 tokenizer trên corpus owt_train.txt 11,9 GB cho thấy Gigatoken đạt 24,53 GB/s trên máy dual-socket AMD EPYC 9565 144 core. Cùng cấu hình, OpenAI tiktoken đạt 36,0 MB/s, còn HuggingFace tokenizers đạt 24,8 MB/s. Trên Apple M4 Max, Gigatoken đạt 8,79 GB/s cho cùng workload; trên Ryzen 7 9800X3D đạt 6,27 GB/s.

Nhưng nếu chỉ đọc đến đây rồi kết luận “đổi tokenizer là xong”, bạn sẽ dễ đi nhầm luồng nước.

Điểm đáng bàn không phải là “989x nhanh hơn” để đem khoe trong slide. Điểm đáng bàn là: lớp tiền xử lý đang được tối ưu như một sản phẩm hạ tầng độc lập, không còn là đoạn code phụ trợ viết vội trước khi train hoặc ingest dữ liệu.

Cùng tuần, Marker 2 cũng cho thấy một hướng tương tự ở document pipeline: thay vì một đường xử lý PDF duy nhất, nó tách thành balanced, fast, và --disable_ocr, chọn theo thiết bị và chi phí. Photon-1 và Open Dreamer thì đẩy câu chuyện token/latent sang video và world model. ZUNA1.1 xử lý EEG bằng input variable-length thay vì khung cố định.

Tín hiệu thị trường ở đây khá rõ: ai kiểm soát được biểu diễn dữ liệu trước khi vào model, người đó kiểm soát chi phí và throughput tốt hơn.

Mổ lớp đầu tiên: benchmark đẹp nằm ở đường native

Gigatoken có hai cách dùng.

Một là compatibility mode: bọc quanh tokenizer hiện có của HuggingFace hoặc tiktoken, giữ output tương thích. Cách này tiện nếu bạn đã có pipeline cũ và không muốn thay đổi kết quả tokenization. Nhưng nó vẫn phải trả phí qua Python overhead, như tạo list hoặc chuyển string sang bytes. Theo chia sẻ trong nguồn, mode này có thể nhanh hơn khoảng 200–300x tùy cách dùng, nhưng không phải nơi sinh ra các con số GB/s cao nhất.

Hai là native API: để Rust đọc file trực tiếp. Đây là đường cho các số benchmark lớn. Nói thẳng ra thì, khác biệt nằm ở việc bạn có cho con tàu đi thẳng ra luồng sâu hay cứ bắt nó vòng qua bến trung chuyển Python.

Với builder, câu hỏi không phải “Gigatoken nhanh không?” mà là:

Nếu bạn đang phục vụ chat request ngắn, latency có thể bị chi phối bởi model inference, tool calling, retrieval hoặc network. Tokenizer nhanh hơn chưa chắc làm người dùng thấy khác biệt. Nhưng nếu bạn đang ingest kho tài liệu lớn, build dataset, chạy eval hàng triệu mẫu, hoặc chuẩn bị pretraining corpus, đây là chỗ đáng soi.

Ai hưởng lợi khi tokenizer thành hạ tầng?

Có ba nhóm sẽ hưởng lợi trước.

Nhóm làm data pipeline. Nếu team bạn thường xuyên ingest log, tài liệu, codebase, transcript hoặc web crawl, tokenization không còn là bước phụ. Nó quyết định tốc độ “bốc hàng lên tàu” trước khi model chạy. Với corpus lớn, vài phút và vài giờ khác nhau không chỉ là trải nghiệm dev; nó ảnh hưởng lịch chạy job, chi phí máy, và khả năng thử nhiều biến thể dữ liệu.

Nhóm làm eval và benchmark nội bộ. Eval LLM thường cần tokenize prompt, completion, ground truth, hoặc dataset nhiều lần. Nếu tokenizer chậm, bạn sẽ ngại chạy lại test sau mỗi thay đổi. Kết quả là team ra quyết định dựa trên ít mẫu hơn, hoặc trì hoãn eval đến cuối sprint.

Nhóm build sản phẩm AI có multi-model routing. Khi bạn route request qua nhiều model, mỗi model có tokenizer khác nhau. Gigatoken benchmark hỗ trợ nhiều họ tokenizer như GPT-2, Llama, Qwen, DeepSeek, GLM, Kimi, Nemotron, Phi, OLMo, Gemma, Mistral. Điều này gợi ý một tương lai nơi tokenizer layer được chuẩn hóa và tối ưu riêng, thay vì bị dính chặt vào từng SDK.

Ví dụ cụ thể: giả sử team bạn có một pipeline RAG xử lý tài liệu pháp lý tiếng Việt. Mỗi lần cập nhật dữ liệu, hệ thống phải parse PDF, chia chunk, đếm token, lọc chunk quá dài, rồi embed. Nếu phần đếm và encode token đang chạy qua wrapper Python từng đoạn nhỏ, bạn có thể tối ưu retrieval cả tuần mà vẫn không chạm vào điểm nghẽn thật.

Ai bị ép đổi cách làm?

Đầu tiên là các framework thích giấu tokenizer sau abstraction. Abstraction tốt khi giúp dev nhanh hơn, nhưng nguy hiểm khi làm mất khả năng đo. Nếu tool chỉ trả về “processed documents” mà không cho biết tokenization mất bao lâu, bạn đang lái trong sương.

Thứ hai là các team chỉ benchmark model endpoint. Rất nhiều bảng so sánh nội bộ ghi latency của LLM call, nhưng bỏ qua thời gian trước và sau đó: load tài liệu, OCR, chunking, tokenization, reranking, formatting output. Trong production, người dùng không quan tâm đoạn nào “không thuộc model”. Họ chỉ thấy tổng thời gian.

Thứ ba là các nhà cung cấp API và inference platform. Khi model serving ngày càng tối ưu, phần còn lại của stack sẽ bị soi kỹ hơn. Throughput — lượng dữ liệu xử lý trong một đơn vị thời gian — không còn là chỉ số của GPU server. Nó trở thành chỉ số của toàn hải trình dữ liệu.

Đây cũng là lý do Marker 2 đáng để đặt cạnh Gigatoken. Một bên tối ưu tokenizer, một bên tối ưu document conversion. Cả hai đều nói cùng một câu: dữ liệu trước khi vào model không phải “phụ bếp”, nó là production surface.

Giữ lại gì, bỏ qua gì?

Điều nên giữ lại:

  1. Profile tokenization như một stage riêng. Đừng gộp nó vào “preprocessing”. Ghi thời gian encode, số byte/s, số token/s, memory peak, và mode đang dùng.
  2. Tách compatibility khỏi performance path. Nếu cần parity, dùng compatibility mode. Nếu cần tốc độ ingest lớn, thử native path. Hai mục tiêu này không nên bị nhét vào một quyết định.
  3. Đo trên dữ liệu của bạn. Benchmark GPT-2 trên corpus lớn rất hữu ích để thấy trần hiệu năng, nhưng dữ liệu tiếng Việt, code, PDF text lỗi, hoặc transcript có phân bố khác.
  4. Xem tokenizer như dependency có SLA. Nếu nó hỏng parity, thay đổi token count, hoặc làm lệch chunking, downstream sẽ đổi theo.

Điều nên bỏ qua:

Một buổi chiều đủ để bạn làm bài test nhỏ:

# 1. Chọn một sample thật từ pipeline của bạn
# Ví dụ: 1-5 GB text đã extract từ PDF, log, code hoặc transcript

# 2. Đo tokenizer hiện tại
# Ghi lại: thời gian chạy, CPU usage, memory, số token sinh ra

# 3. Thử gigatoken ở compatibility mode nếu pipeline đang dùng HF/tiktoken
pip install gigatoken

# 4. Nếu workload là file lớn, thử đường native nếu phù hợp
# So sánh output parity trước, rồi mới so throughput

# 5. Ghi quyết định: giữ, thay, hay chỉ dùng cho batch ingest

Kết quả quan trọng nhất không phải là “nhanh hơn bao nhiêu lần”. Kết quả quan trọng là bạn biết tokenization có đáng nằm trong roadmap tối ưu hay không.

Cách nghĩ mới cho team builder

Sau bài này, mình muốn bạn đổi một thói quen: đừng xem release về tokenizer, OCR, latent encoder hay document converter là tin phụ quanh model.

Photon-1 nói về học từ video không cần action labels. Open Dreamer mở recipe world model. ZUNA1.1 linh hoạt hơn với tín hiệu EEG không đều. Marker 2 chọn mode theo thiết bị và chất lượng. Gigatoken đẩy tokenization lên tốc độ GB/s. Các mảnh này khác nhau, nhưng cùng chỉ về một hướng: thị trường AI đang cạnh tranh ở lớp biến dữ liệu thô thành biểu diễn có thể tính toán được.

Với team Việt Nam, nơi ngân sách GPU, nhân sự infra và thời gian chạy job đều phải cân kỹ, đây là tin đáng mừng. Bạn không nhất thiết phải đu theo model mới nhất. Có khi chỉ cần tìm đúng đoạn dây neo đang kéo chậm cả hệ thống, rồi cắt nó đúng cách.

Đúc kết gọn: model là cánh buồm, nhưng dữ liệu vào chậm thì gió thuận cũng chỉ để ngắm.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo