Splintr vs Gigatoken: Perbandingan Adil Dua Tokenizer Rust

Selepas kami menerbitkan artikel tentang Gigatoken, seorang pembaca meninggalkan komen yang agak menarik.

Katanya, splintr lebih baik.

Bukan sekadar lebih mudah digunakan atau sama laju. Dia maksudkan splintr secara keseluruhan lebih baik daripada Gigatoken.

Itu dakwaan yang agak besar.

Gigatoken sendiri mampu memproses korpus 11.9 GB pada kelajuan sekitar 24 GB/s dalam benchmark tertentu. Jadi saya cuba lihat sendiri dari mana datangnya perbezaan tersebut.

Saya baca README splintr, tengok benchmark yang disediakan dan bandingkan cara kedua-dua projek mengukur prestasi.

Jawapannya ternyata bergantung pada apa yang anda mahu lakukan.

Untuk penggunaan biasa, splintr memang mempunyai beberapa kelebihan yang sukar diabaikan.

Tetapi kalau tugas anda ialah memproses korpus berbilang gigabait pada server dengan jumlah core yang sangat banyak, Gigatoken masih mempunyai kelebihan yang besar.

Jadi, ini bukan cerita tentang satu projek "menang" dan satu lagi "kalah".

Apa sebenarnya splintr?

splintr ialah tokenizer Rust berlesen MIT yang turut menyediakan Python binding melalui pakej splintr-rs.

Projek ini dibangunkan oleh Farhan dan pendekatannya agak berbeza daripada Gigatoken.

Splintr cuba memberikan satu API untuk beberapa jenis tokenizer.

Di belakang AnyTokenizer, terdapat empat backend:

• Byte-level BPE — GPT-2, Llama 3, Qwen, DeepSeek dan Mistral v3
• SentencePiece BPE — Mistral v1 dan v2
• Unigram — T5, Gemma dan Albert
• WordPiece — BERT, DistilBERT dan Electra

Ia juga boleh mendapatkan vocab daripada beberapa sumber.

Antaranya vocab yang sudah dibundel dalam library, fail tokenizer.json daripada Hugging Face, fail .tiktoken dan vocab GGUF.

Sokongan GGUF ini menarik kerana format tersebut banyak digunakan oleh runtime yang berasaskan llama.cpp.

Dari sudut penggunaan, idea splintr agak mudah: tukar tokenizer atau model tanpa perlu menukar keseluruhan kod anda.

Contohnya:

from splintr import Tokenizer

tok = Tokenizer.from_pretrained("qwen3")
tok2 = splintr.from_json("tokenizer.json")
tok3 = Tokenizer("vocab.tiktoken", PATTERN)

tokens = tok.encode("Hello, world!")
batch = tok.encode_batch([
    "Hello, world!",
    "How are you?"
])

Bagi aplikasi yang menyokong beberapa model, pendekatan seperti ini memang berguna.

Bagaimana pula dengan benchmark?

Benchmark yang disediakan oleh splintr menggunakan AMD Ryzen 9 5900X dan cl100k_base, dengan versi tiktoken dan Hugging Face yang ditetapkan.

Keputusannya:

Dalam benchmark tersebut, splintr memang jauh lebih pantas daripada tiktoken.

Tetapi angka ini perlu dibaca dengan konteks.

Benchmark projek sendiri bukanlah benchmark bebas. Ia berguna untuk memahami kelebihan yang cuba ditunjukkan oleh projek, tetapi bukan bukti bahawa splintr akan menjadi 20 kali lebih pantas dalam semua keadaan.

Dan apabila splintr dibandingkan dengan Gigatoken, jurangnya menjadi jauh lebih kecil.

Menurut benchmark yang diterbitkan oleh splintr:

• masa memuatkan vocab sekitar 2 hingga 4 kali lebih pantas
• untuk teks tunggal, splintr kira-kira 1.5 kali lebih pantas pada x86-64
• pada Apple Silicon, keputusan teks tunggal boleh menjadi hampir sama
• untuk batch, kedua-duanya berada dalam julat yang hampir sama, dengan perbezaan sekitar ±20% bergantung pada mesin, vocab dan format output

Ini jauh lebih menarik daripada sekadar membandingkan nombor terbesar daripada setiap projek.

Kenapa angka Gigatoken nampak jauh lebih besar?

Di sinilah konteks benchmark menjadi penting.

Gigatoken pernah menunjukkan angka sekitar 24 GB/s ketika memproses korpus besar pada server AMD EPYC dengan jumlah core yang sangat tinggi.

Itu bukan jenis kerja yang sama seperti mengekod satu prompt atau beberapa ratus teks.

Bayangkan dua senario.

Senario pertama:

11.9 GB korpus
↓
server multi-core
↓
tokenisasi secara besar-besaran

Senario kedua:

prompt pengguna
↓
tokenizer
↓
beberapa ratus atau ribuan token

Kedua-duanya menggunakan tokenizer.

Tetapi keperluan prestasinya berbeza.

Untuk senario pertama, throughput keseluruhan sangat penting. Anda mahu CPU bekerja sebanyak mungkin untuk menghabiskan korpus dengan cepat.

Untuk senario kedua, latency lebih penting.

Kalau pengguna sedang menunggu respons LLM, mengurangkan masa tokenisasi daripada 2 ms kepada 1 ms mungkin lebih berguna daripada mencapai throughput berpuluh-puluh GB/s yang tidak pernah digunakan oleh aplikasi tersebut.

Sebab itu kita tidak boleh melihat angka "24 GB/s" dan terus menganggap Gigatoken lebih baik untuk semua jenis penggunaan.

Di mana splintr lebih menarik?

Kelebihan utama splintr sebenarnya bukan sekadar kelajuan.

Satu API untuk beberapa jenis tokenizer

Gigatoken lebih fokus kepada BPE.

Splintr pula menyokong BPE, Unigram dan WordPiece.

Kalau projek anda hanya menggunakan satu keluarga tokenizer, perbezaan ini mungkin tidak penting.

Tetapi untuk library atau runtime yang perlu menyokong banyak model, satu API untuk beberapa format boleh menjimatkan banyak kerja.

Sokongan GGUF

Ini antara ciri yang paling praktikal.

Splintr boleh membaca vocab GGUF melalui from_gguf_vocab.

Bagi projek yang menggunakan model tempatan dan ekosistem llama.cpp, sokongan ini boleh menjadi faktor pemilihan yang penting.

Gigatoken tidak mempunyai sokongan yang sama.

Semakan ketepatan token

Prestasi tokenizer tidak bermakna jika token yang dihasilkan salah.

Splintr menjalankan ujian terhadap tiktoken, Hugging Face tokenizers dan SentencePiece untuk memastikan token ID yang dihasilkan sepadan.

Benchmark harness-nya juga melakukan semakan output sebelum keputusan prestasi dianggap sah.

Ini penting terutamanya untuk library tokenizer.

Anda tidak boleh sekadar berkata:

"Tokenizer saya dua kali lebih laju."

Kalau hasil tokennya berbeza daripada tokenizer yang sepatutnya digunakan oleh model, kelajuan itu tidak banyak membantu.

Token khas untuk aplikasi AI

Splintr turut menyediakan token khas untuk beberapa kegunaan seperti ChatML, thinking, ReAct, tool calling dan citation RAG.

Kesemuanya dibina bersama vocab yang disokong.

Bagi aplikasi agent, ciri seperti ini lebih berguna daripada sekadar nombor throughput.

Streaming decoder

Splintr juga mempunyai streaming decoder dengan pengendalian sempadan UTF-8.

Ini sesuai untuk aplikasi yang menerima output LLM sedikit demi sedikit dan perlu menyahkodnya secara berterusan.

Cara ia menggunakan CPU

Splintr tidak menggunakan strategi yang sama untuk semua input.

Untuk teks kecil, ia memilih pemprosesan sequential kerana kos memulakan kerja paralel boleh menjadi lebih besar daripada manfaatnya.

Untuk batch, Rayon digunakan untuk memproses beberapa teks secara selari.

Untuk teks tunggal yang sangat besar, encode_rayon boleh digunakan.

Pendekatan ini masuk akal kerana 50 token prompt chat dan fail teks bersaiz gigabait bukan masalah yang sama.

Teknik dalaman yang digunakan splintr

Kalau kita tengok sedikit lebih dalam, terdapat beberapa keputusan implementasi yang menarik.

Antaranya:

• regex JIT/SIMD melalui regexr
• Aho-Corasick untuk special tokens
• linked-list BPE untuk mengelakkan masalah O(N²) pada input tertentu
• FxHashMap
• cache LRU

Kesemua ciri ini menunjukkan projek tersebut bukan sekadar membalut implementasi tokenizer sedia ada dengan API Rust.

Tetapi sekali lagi, ciri-ciri ini tidak semestinya bermaksud splintr akan mengalahkan Gigatoken dalam setiap benchmark.

Reka bentuk yang baik untuk workload tertentu boleh menjadi kurang sesuai untuk workload yang lain.

Gigatoken masih ada kelebihan yang besar

Di sinilah saya rasa komen pembaca tadi perlu diberi sedikit konteks.

Kalau anda hanya melihat fleksibiliti, API dan penggunaan biasa, splintr memang nampak lebih menarik.

Tetapi Gigatoken mempunyai satu kelebihan yang sangat jelas:

throughput mentah pada workload yang sangat besar.

Pada hardware seperti AMD EPYC 9565, Gigatoken dilaporkan boleh mencapai sekitar 24.53 GB/s untuk GPT-2 dalam benchmarknya.

Itu angka yang besar.

Kalau kerja anda ialah mengambil korpus OpenWebText 11.9 GB dan menukarkannya kepada token secepat mungkin menggunakan server dengan banyak core, Gigatoken memang lebih sesuai dengan masalah tersebut.

Ia juga mempunyai pendekatan khusus untuk pre-tokenization yang cuba mengurangkan bottleneck regex.

Dalam keadaan seperti ini, reka bentuk Gigatoken yang sangat fokus sebenarnya menjadi kelebihan.

Ia tidak cuba menjadi tokenizer untuk segala-galanya.

Ia cuba menjadi sangat pantas untuk masalah tertentu.

Dan itu bukan kelemahan.

Jadi, mana satu lebih baik?

Jawapannya bergantung pada apa yang anda lakukan.

Jadi, adakah pembaca itu betul?

Untuk banyak penggunaan biasa, ya.

Splintr lebih fleksibel dan lebih mudah dijadikan lapisan tokenizer untuk aplikasi yang menyokong banyak model.

Tetapi kalau maksud "lebih baik" ialah lebih laju dalam semua keadaan, jawapannya tidak.

Gigatoken masih mempunyai kelebihan yang jelas apabila workload anda benar-benar memerlukan throughput yang tinggi pada korpus besar.

Kesimpulan

Perbandingan tokenizer memang mudah menjadi pertandingan nombor.

24 GB/s nampak lebih hebat daripada 100 MB/s.

Tetapi nombor itu sahaja tidak memberitahu kita apa yang sebenarnya diuji.

Tokenizer yang digunakan untuk memproses korpus 11.9 GB pada server besar mempunyai masalah yang berbeza daripada tokenizer yang dipanggil beberapa ribu kali sehari untuk prompt LLM.

Sebab itu saya tidak akan kata splintr "membunuh" Gigatoken.

Kalau saya membina aplikasi yang menyokong banyak model, terutama model yang menggunakan GGUF, saya lebih cenderung memilih splintr.

Kalau saya membina pipeline prapemprosesan untuk korpus yang sangat besar dan mempunyai server dengan banyak core, Gigatoken masih sangat menarik.

Jadi komen pembaca itu ada asasnya — cuma bukan dalam bentuk yang paling mudah.

Splintr bukan pemenang mutlak. Gigatoken juga bukan.

Yang lebih penting ialah workload anda.

Dan itu mungkin perkara paling berguna untuk diingat apabila membaca benchmark projek open source: jangan tanya hanya "siapa paling laju?"

Tanya dulu:

"Laju untuk kerja yang mana?"