Gigatoken: Tokenisasi 989x Lebih Pantas Dalam Rust

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 — dan itulah juga sebab kiraan token muncul dalam bil inference anda.

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 itu 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. Satu amaran yang terpakai untuk setiap angka replikasi pihak ketiga yang anda nampak dipetik untuk projek ini: semak semula terhadap halaman benchmark semasa repo sebelum mengulanginya — angka awal untuk repo yang bergerak pantas rosak dalam masa berminggu-minggu.

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

Laporan replikasi pihak ketiga kadangkala memetik angka yang lebih tinggi daripada halaman benchmark projek sendiri. Angka-angka itu tidak disahkan di sini — ambil sebagai petunjuk arah aliran, bukan ukuran, dan semak terhadap repo semasa sebelum membuat keputusan.

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 itu tidak semestinya mewakili setiap jenis penggunaan sebenar — bandingannya dengan pesaing terdekat ialah bacaan susulan yang wajar.

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, kelebihannya mungkin jauh lebih kecil.

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

Cara Membaca 989x

Angka utama ialah nisbah throughput pada hardware banyak-core, bukan pecutan sejagat. Nisbah berbeza merentas mesin dalam jadual projek sendiri tepat kerana keuntungannya berbentuk kiraan core: lebih banyak core, lebih banyak pipeline berjalan serentak, lebih besar gandaan. Pada VM kecil kod yang sama menunjukkan kelebihan jauh lebih rendah. Baca 989x sebagai "inilah yang dibeli oleh keselarian apabila core banyak," bukan "semuanya mentoken 1,000 kali lebih pantas sekarang."

Throughput Bukan Latency

Kerja batch dan interaktif mahukan benda berbeza. Pemprosesan korpus luar talian pentingkan megabait sesaat merentas gigabait; request chat pentingkan milisaat untuk satu prompt pendek. Gigatoken memenangi permainan pertama secara rekaan — struktur serentak ke atas seluruh fail — dan jelas tidak menjanjikan yang kedua, di mana overhed setiap panggilan mendominasi. Padankan tool dengan permainan sebelum memetik angka utama.

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 itu.

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 itu muncul di GitHub dan 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.

Sumber

• GitHub: Gigatoken