Gigatoken: Tokenisasi 989x Lebih Pantas Dalam Rust

Tokenisasi biasanya bukan bahagian yang banyak mendapat perhatian apabila kita bercakap tentang prestasi LLM. Ia berlaku sebelum model memproses input, jadi kerja tersebut mudah dianggap sebagai langkah kecil dalam keseluruhan pipeline.

Tetapi apabila jumlah data sudah mencecah berbilang gigabait atau terabait, masa yang digunakan untuk tokenisasi mula menjadi penting.

Gigatoken ialah sebuah tokenizer Rust berlesen MIT yang menyediakan Python bindings dan memberi tumpuan khusus kepada tokenization throughput. Dalam benchmark yang diterbitkan oleh projek itu, korpus OpenWebText bersaiz 11.9 GB diproses menggunakan tokenizer GPT-2 pada AMD EPYC 9565 dual-socket dengan 144 cores.

Gigatoken mencatatkan 24.53 GB/s.

Sebagai perbandingan, tokenizers daripada HuggingFace mencatatkan 24.8 MB/s dan tiktoken mencatatkan 36.0 MB/s dalam benchmark yang sama. Berdasarkan angka tersebut, Gigatoken ialah kira-kira 989x lebih pantas daripada HuggingFace dan 681x lebih pantas daripada tiktoken.

Angka yang dilaporkan projek itu turut menunjukkan perbezaan yang besar pada beberapa jenis hardware lain:

Projek ini open-source di GitHub di bawah lesen MIT. Ia juga menyediakan Python bindings di PyPI melalui pip install gigatoken.

Kenapa tokenisasi boleh menjadi bottleneck

Tokenisasi sudah lama dianggap sebagai masalah yang agak selesai. Dalam banyak pipeline, perhatian lebih banyak diberikan kepada prestasi model, GPU dan inference, manakala masa yang digunakan oleh encoder tidak diperiksa dengan begitu terperinci.

Library seperti tokenizers daripada HuggingFace dan tiktoken juga sudah menggunakan Rust dan pemprosesan selari.

Gigatoken cuba mendapatkan lebih banyak prestasi daripada bahagian yang biasanya tidak begitu diberi perhatian: regex pre-tokenization dan proses merge BPE.

Dalam tokenizer berasaskan BPE, teks perlu melalui proses pre-tokenization terlebih dahulu. Regex digunakan untuk membahagikan teks kepada segmen sebelum proses merge token dilakukan.

Menurut reka bentuk Gigatoken, bahagian tersebut digantikan dengan implementasi custom dan digabungkan dengan struktur data yang membolehkan lebih banyak kerja dilakukan secara selari.

Kesan akhirnya ialah lebih banyak bahagian proses tokenisasi boleh menggunakan beberapa CPU cores secara serentak.

Dua cara untuk menggunakannya

Gigatoken menyediakan dua jenis API.

API native direka untuk mendapatkan throughput yang tinggi. Ia boleh membaca raw bytes dan memproses fail atau kelompok data secara selari:

import gigatoken as gt

# native API — kawasan GB/s
encoder = gt.Tokenizer("gpt2")
tokens = encoder.encode_batch([raw_bytes], parallel=True)

# compatibility mode: balut tokenizer sedia ada, hasil yang sama
compatible = gt.Tokenizer(some_tiktoken_encoding).as_tiktoken()
ids = compatible.encode("hello, operator", allowed_special="all")

Terdapat juga compatibility mode yang membalut tokenizer HuggingFace atau tiktoken sedia ada. Tujuannya ialah membolehkan kod sedia ada menggunakan Gigatoken tanpa perlu mengubah keseluruhan pipeline.

Mod ini tidak mencapai throughput API native. Menurut angka yang diberikan projek, prestasinya berada sekitar 200-300x lebih pantas berbanding implementasi asal, bukannya sekitar 1000x. Salah satu sebabnya ialah lapisan Python masih terlibat dalam pembinaan list dan penukaran string.

Walaupun begitu, pendekatan ini lebih mudah untuk diuji kerana kod sedia ada boleh menggunakan API yang hampir sama.

Ujian bebas di KrabArena turut melaporkan angka yang tinggi. Pada VM Xeon 4-vCPU, Gigatoken mencatatkan 277.8 MB/s, kira-kira 26x lebih laju daripada tiktoken dan 83x lebih laju daripada HuggingFace. Output tersebut juga dilaporkan sepadan dengan hasil rujukan untuk 35,356 dokumen yang diuji.

Di mana angkanya lebih sederhana

Angka 989x memang menarik, tetapi ia perlu dilihat dalam konteks.

Gigatoken sangat tertumpu pada BPE. Untuk vocabulary berasaskan SentencePiece, peningkatan yang dilaporkan dalam benchmark yang sama ialah sekitar 7-22x. WordPiece pula tidak disokong.

Cara benchmark dijalankan juga perlu diambil kira. Baseline diproses menggunakan input yang telah dipecahkan kepada chunk, manakala Gigatoken membaca keseluruhan fail secara terus. Perbezaan ini boleh memberi kesan kepada keputusan, jadi angka tersebut tidak semestinya mewakili setiap jenis penggunaan sebenar.

Workload juga penting.

Gigatoken lebih menarik untuk kerja offline yang memproses data dalam jumlah besar dan memerlukan throughput tinggi. Untuk satu dokumen kecil pada satu-satu masa, terutama apabila latency setiap request menjadi keutamaan, kelebihan tersebut mungkin jauh lebih kecil.

Jadi, perbandingan 989x tidak bermaksud setiap penggunaan tokenizer akan menjadi 989 kali lebih pantas.

Patutkah anda bertukar?

Ada beberapa situasi yang memang sesuai untuk mencuba Gigatoken.

Pertama, jika anda memproses korpus yang besar seperti data pre-training, membina semantic index atau menghasilkan batch embeddings.

Kedua, jika proses tokenisasi sendiri sudah menjadi CPU-bound dan mengambil sebahagian besar masa dalam pipeline anda.

Pemasangannya juga mudah:

pip install gigatoken

Tetapi jika anda hanya memproses prompt pendek dan sangat bergantung pada tingkah laku HuggingFace atau tiktoken untuk setiap request, tidak ada sebab untuk menukar semuanya semata-mata kerana angka benchmark tersebut.

Gigatoken lebih menarik apabila masalah anda memang berkaitan dengan throughput.

Itulah bahagian yang patut diberi perhatian. Tokenisasi mungkin kelihatan seperti kerja kecil apabila hanya melihat satu request. Tetapi apabila sistem perlu memproses berbilang gigabait data, kerja yang sama boleh menjadi sebahagian besar daripada compute cost.

Gigatoken menunjukkan bahawa masih ada ruang untuk mengoptimumkan bahagian ini.

Projek tersebut muncul di Hacker News dan GitHub pada Julai 2026 dan dibangunkan oleh seorang pelajar PhD dari Stanford. Jika anda mengendalikan pipeline pemprosesan teks berskala besar, Gigatoken sekurang-kurangnya wajar diuji menggunakan data dan hardware anda sendiri sebelum membuat keputusan untuk bertukar.

Dan seperti yang kami bincangkan dalam tulisan tentang AI pipeline, kelajuan sahaja tidak cukup. Dalam mana-mana AI pipeline, hasil yang pantas masih perlu diperiksa untuk memastikan ia benar-benar menghasilkan apa yang kita mahu.