GigaToken - Mempercepat tokenisasi model bahasa sekitar 1.000x

• Mendukung beragam CPU dan tokenizer yang umum dipakai, serta menjadi alternatif untuk Tiktoken dan HuggingFace Tokenizers yang memproses teks pada skala GB/s
• Pra-tokenisasi yang biasanya ditangani mesin regex dioptimalkan dengan SIMD, sambil mengurangi percabangan, komunikasi antar-thread, dan interaksi Python, serta meng-cache pemetaan token untuk kata yang sudah pernah dilihat secara efisien
• Pada benchmark OpenWebText 11.9GB, throughput GPT-2 mencapai 24.53GB/s di AMD EPYC 9565, 8.79GB/s di Apple M4 Max, dan 6.27GB/s di Ryzen 7 9800X3D
• Mode kompatibel HuggingFace dan Tiktoken memungkinkan kode lama tetap hampir tidak berubah, tetapi performanya turun karena biaya penyamaan output; Gigatoken API yang membaca file langsung dari Rust memberi paralelisme maksimum dan kecepatan tertinggi
• WordPiece dan output ke file belum didukung, sementara optimasi SentencePiece dan verifikasi Windows masih kurang matang, sehingga saat ini lebih cocok untuk tokenizer BPE dan lingkungan Linux·macOS atau WSL

---

Cakupan dukungan dan cara penggunaan

• Gigatoken adalah tokenizer berkecepatan tinggi untuk model bahasa, ditujukan untuk CPU x86·ARM modern dan hampir semua tokenizer umum
• Instal dengan pip install gigatoken dan tersedia API sendiri serta mode kompatibel untuk HuggingFace Tokenizers dan Tiktoken
• Mode kompatibel membungkus tokenizer yang ada dan mengubahnya dengan .as_hf() atau .as_tiktoken()
  • Diterapkan cukup banyak penyesuaian agar outputnya benar-benar identik dengan HuggingFace Tokenizers
  • Penanganan kompatibilitas punya biaya performa yang tidak bisa diabaikan, jadi tidak mencapai percepatan sekitar 1.000x seperti API asli, tetapi secara umum tetap lebih cepat daripada implementasi yang ada
• API aslinya menerima nama model HuggingFace seperti "Qwen/Qwen3-8B" dan TextFileSource untuk mengenkode file secara langsung
  • Implementasi Rust membaca data langsung sehingga melewati overhead yang tidak perlu dan memaksimalkan paralelisme
  • Jika yang diberikan adalah struktur data Python, biaya pembacaan data di Python tetap ada

Implementasi yang meningkatkan kecepatan

• Peningkatan terbesar biasanya datang dari pengoptimalan langsung berbasis SIMD untuk pra-tokenisasi yang umumnya diserahkan ke mesin regex
• Percabangan diminimalkan, dan cache pemetaan pra-token untuk mencari token hasil encoding dari kata yang sudah pernah dilihat dioptimalkan secara intensif
  • Cache cepat membesar dan distribusi pra-token berbentuk long-tail sehingga sulit ditangani
• Interaksi dengan Python dan komunikasi antar-thread dikurangi untuk memperoleh performa tambahan
• Implementasinya tidak disetel hanya untuk satu CPU atau satu tokenizer tertentu; kombinasi berbagai tokenizer dengan CPU x86·ARM modern dioptimalkan masing-masing, dan hasilnya juga konsisten di berbagai CPU dan tokenizer

Benchmark OpenWebText 11.9GB

• Pada lingkungan AMD EPYC 9565 144-core, throughput GPT-2 mencapai 24.53GB/s, yaitu 989x lebih cepat daripada 24.8MB/s milik HuggingFace Tokenizers dan 681x lebih cepat daripada 36.0MB/s milik Tiktoken
  • Keluarga BPE utama umumnya mencatat sekitar 15.49~24.00GB/s
  • Item berbasis SentencePiece relatif lebih lambat, sekitar 2.51~4.82GB/s
• Di Apple M4 Max 16-core, GPT-2 mencapai 8.79GB/s, yaitu 1.268x dibanding HuggingFace dan 140x dibanding Tiktoken
  • OLMo 2/3 mencatat 1.299x dibanding HuggingFace, dan Qwen 2/2.5 mencatat 1.105x
• Di AMD Ryzen 7 9800X3D 16-core, GPT-2 mencapai 6.27GB/s, yaitu 106x dibanding HuggingFace dan 68x dibanding Tiktoken
  • Keluarga BPE utama berada di kisaran 4.21~6.09GB/s, sedangkan keluarga yang relatif kurang dioptimalkan berada di kisaran 1.12~2.84GB/s

Kondisi pengukuran dan interpretasi

• OWT (OpenWebText) dipilih sebagai data benchmark karena dianggap cukup mewakili teks yang diperoleh setelah mengekstrak dokumen Common Crawl
• Gigatoken memproses tanpa membagi seluruh file terlebih dahulu, sehingga pencarian batas pemisahan dan paralelisasi otomatis juga ditangani sendiri
• Objek pembanding memproses data yang telah dibagi sebelumnya berdasarkan <|endoftext|>
  • HuggingFace encode_batch_fast menggunakan 100MB pertama
  • Tiktoken encode_ordinary_batch menggunakan 1GB pertama
  • Karena kedua implementasi tidak melakukan caching dan kecepatan prosesnya cenderung tetap, kondisi perbandingan ini digunakan
• Hasil Tiktoken hanya disertakan untuk tokenizer yang didukung secara resmi
• Setiap baris mewakili satu tokenizer unik dengan vocabulary, merge, dan pra-tokenizer yang sama
  • Berbagai versi dan model turunan dari keluarga Llama, Qwen, DeepSeek, GLM, Nemotron, Kimi, Phi, dan Gemma digabung dalam baris tokenizer yang sama
• Item yang paling lambat adalah tokenizer berbasis SentencePiece yang di Gigatoken belum cukup dioptimalkan

Verifikasi dukungan dan pemrosesan skala besar

• Tanpa instalasi, tokenisasi repositori model HuggingFace bisa diverifikasi dan diukur waktunya dengan perintah uvx --with tokenizers gigatoken bench
• Dalam contoh verifikasi GPT-2, output dari 20.401 dokumen cocok sepenuhnya
  • Di Apple M4 Max, 11,920.51MB diproses dalam 1.432 detik pada 8,327.05MB/s, 1.353,13x lebih cepat daripada HuggingFace
  • Di AMD EPYC 9565, data yang sama diproses dalam 0.486 detik pada 24,532.45MB/s, 989,21x lebih cepat
• Dengan laju pemrosesan EPYC, seluruh Common Crawl berskala 130 triliun token bisa ditokenisasi dalam kurang dari 6,5 jam
• Contohnya memakai sampel OWT Stanford CS336, dan CLI secara default menggunakan 100MB pertama file untuk verifikasi serta perbandingan dengan HuggingFace
• Pada eksekusi pertama di macOS, kode Rust bisa melambat karena pemeriksaan keamanan, jadi untuk pengukuran yang akurat perintah mungkin perlu dijalankan dua kali
• Ketidakcocokan output atau kasus lambat diminta untuk dilaporkan melalui GitHub Issue

Batasan yang diketahui

• Pemrosesan iterasi Python dilakukan di Rust, tetapi menggunakan ABI3 yang lebih lambat daripada API internal CPython per versi
  • Ada rencana spesialisasi per versi Python, dan dalam eksperimen awal kasus yang didominasi overhead menjadi 2x lebih cepat
• File output sink belum diimplementasikan di Gigatoken API
• WordPiece tidak didukung
• Tokenisasi berbasis SentencePiece memiliki tingkat optimasi yang lebih rendah daripada BPE umum
  • Prioritasnya saat ini juga rendah karena terutama digunakan oleh model Google dan keluarga BERT
• Pengujian Windows belum memadai, sehingga saat ini disarankan memakai WSL

Cakupan penggunaan AI

• Sebagian besar codebase ditulis langsung tanpa AI, dan hal ini bisa dikonfirmasi lewat riwayat Git proyek
• Pada tahap akhir proyek, AI digunakan untuk tugas berikut
  • Implementasi API untuk pengguna
  • Generalisasi·porting pra-tokenizer dan perluasan kompatibilitas untuk lebih banyak tokenizer
  • Dukungan padding, truncation, dan normalisasi Unicode
  • Porting strategi SIMD di antara AVX512·AVX2·NEON
  • Sekitar peningkatan performa 4x terakhir melalui penghapusan percabangan dan perbaikan hierarki cache pra-token
  • Refactoring dan peningkatan reuse kode

[GN⁺]

Opini Hacker News

• Katanya, “sebagian besar kode ditulis langsung tanpa AI, dan itu bisa diverifikasi di riwayat Git”, jadi klaim pemrograman manusia sudah berakhir terasa jadi tidak meyakinkan

• Ini bukan sekadar dioptimalkan berlebihan untuk satu CPU dan satu tokenizer tertentu, melainkan untuk seluruh kombinasi x86·ARM modern dan berbagai tokenizer agar menghasilkan performa yang konsisten
  Pra-tokenisasi yang biasanya diserahkan ke regex engine dioptimalkan langsung dengan SIMD sambil meminimalkan percabangan, dan cache pemetaan pra-token juga diperbaiki agar hasil encoding untuk kata yang sudah pernah dilihat bisa ditemukan dengan cepat. Cache di bidang ini cepat membesar dan ekor distribusinya panjang, jadi sulit ditangani
  Interaksi dengan Python dan komunikasi antarthread juga diminimalkan

• Mengingatkan pada simdjson, yang menghasilkan kecepatan yang sulit dipercaya lewat pemrograman kreatif. Kalau dipakai luas, ini bisa sangat mengurangi listrik·biaya·emisi karbon, jadi akan bagus kalau ada crate Rust juga, dan kalau perlu saya ingin ikut membantu

  • Tokenisasi hampir tidak pernah menjadi bottleneck yang berarti, dan serialisasi JSON umumnya juga begitu. Jauh lebih banyak energi dihabiskan untuk I/O dan storage daripada untuk serialisasi dan tokenisasi
    Jika memikirkan efisiensi ekonomi dan lingkungan, batching request memberi dampak yang jauh lebih besar. Masalah termahal adalah turunnya utilisasi GPU, dan jika pekerjaan disesuaikan ke bentuk batch, bahkan di OAI saat ini bisa menghemat 50%. Jika tidak semua jawaban harus langsung tersedia, sebagian bisa menunggu beberapa hari, tool call tidak mengalami timeout, dan bagi LLM sendiri tidak ada waktu dinding

• Saya meng-clone repositorinya dan melihat-lihat, dan penggantian regex pra-tokenisasi serta optimasi cache adalah pendekatan yang berguna secara umum. Ini pekerjaan yang sangat bagus sampai-sampai seluruh komunitas tokenisasi pasti ingin belajar rahasia peningkatan kecepatan seperti ini

  • Dalam waktu dekat akan dibuat penjelasan teknis dan makalah proyek ini, plus video presentasi, lalu dibagikan juga di Discord
  • Ini bernilai besar bukan hanya untuk inferensi, tetapi juga untuk pelatihan dengan dataset proprietari, dan fakta bahwa semua ini dikerjakan oleh satu orang juga mengesankan

• Hasil yang keren, tapi tokenisasi biasanya kurang dari 0,1% dari total waktu inferensi. Meski begitu, ini akan sangat berguna untuk aplikasi yang memang membutuhkan tokenisasi itu sendiri

  • Bergantung pada cara inferensi dilakukan, porsi tokenisasi juga bisa cukup besar. Dalam pengukuran awal saat menjalankan 8B Qwen3 di satu B200, ketika diganti ke gigatoken, time to first token (TTFT) turun rata-rata 5,5% pada panjang input 2.048, 8,4% pada 8.192, dan 7,8% pada 32.768
    Efeknya makin besar pada model kecil atau GPU yang lebih cepat, dan perlu validasi tambahan sebelum dimasukkan ke README. Sumber benchmark-nya adalah fastokens
  • Di platform AI, request perlu ditokenisasi dengan cepat di awal untuk menentukan routing·rate limiting dan seterusnya. Walau porsinya kecil dalam total waktu request, efisiensinya tetap penting
  • Tokenisasi kebanyakan diproses secara serial, jadi kalau prompt awal besar, ia bisa mengambil porsi besar dari waktu pemrosesan input. Setelah diserahkan ke inferensi model, semua token bisa diproses paralel
  • Bahkan 1/1.000 dari komputasi inferensi pun sulit diabaikan saat skalanya besar. Gartner memperkirakan belanja inferensi pada 2026 sekitar 28 miliar dolar, jadi dengan asumsi tadi, itu berarti sekitar 28 juta dolar per tahun
    Sumber: https://www.gartner.com/en/newsroom/press-releases/2026-07-2...
  • Khususnya pada model kecil, ini bisa sangat mengurangi latensi time to first token. Bagi penyedia inferensi seperti Groq atau Cerebras, latensi sama pentingnya dengan throughput total

• Ini tampak lebih berguna untuk persiapan data pra-pelatihan offline daripada saat inferensi. Saat menokenisasi teks berukuran beberapa terabyte untuk korpus pelatihan, ini bisa menghemat waktu dan biaya, sekaligus mempersingkat siklus iterasi saat menyesuaikan dataset

• Mencurahkan kemampuan rekayasa untuk membuat bagian yang hanya mengambil 0,1% dari total waktu eksekusi menjadi 1.000 kali lebih cepat justru terasa seperti perilaku paling khas seorang pengembang perangkat lunak

  • Saya pernah membuat word cloud resolusi tinggi dalam sekitar 100ms dengan Rust, lalu lewat optimasi tambahan menurunkannya menjadi sekitar 16ms. Dunia mungkin tidak membutuhkan generator word cloud secepat itu, tapi kalau mau dibuat, ya seharusnya secepat mungkin
  • “Mengejar keunggulan tidak membutuhkan pembenaran”
    https://x.com/mitchellh/status/2074225453217505494
  • Itu bergantung pada alur kerja. Ada juga penggunaan yang hanya melakukan tokenisasi tanpa langsung memasukkan teks ke model
  • Bahkan jika hanya subkomponen, peningkatan 1.000 kali bisa memungkinkan fitur baru secara kualitatif. Fakta bahwa bagian itu hanya 0,1% dari total pun sering kali merupakan hasil dari sikap yang berulang di seluruh proyek: “kalau tidak memengaruhi performa keseluruhan, kenapa harus dibuat dengan benar?”
    LLM jauh lebih dekat ke batas peningkatan 1.000 kali, tetapi operasi dasar PyTorch pun sering 2 kali lebih lambat daripada penulisan ulang sederhana, dan algoritme penjadwalan yang lebih baik kadang memberi peningkatan 5~10 kali. Tokenisasi cepat juga bisa membuka fitur lain yang selama ini diabaikan karena dianggap mustahil diwujudkan
  • Jika tokenisasi dipakai untuk menjalankan small language model (SLM) superkecil untuk routing, porsinya bisa jauh lebih besar dari 0,1%. Ini mirip pola pikir “karena PC kebanyakan diam di desktop, optimasi driver GPU jadi tidak penting”

• Performanya sulit dipercaya sampai saya harus menatap angka-angka di grafik cukup lama untuk memahaminya

• Ini juga tepat fungsi yang dibutuhkan ClickHouse, jadi akan dicoba di https://github.com/ClickHouse/ClickHouse/issues/108247
  Akan lebih baik kalau README lebih menekankan performa per core, dan saya penasaran apakah pencocokan perfect hash table akan membantu algoritme nyatanya

• Jadi penasaran, di bagian lain dari pipeline inferensi masih ada berapa banyak peluang optimasi 1.000 kali yang tersisa

  • Berbeda dari lapisan tokenisasi, perubahan lain pada inferensi sulit dinilai hanya dengan keputusan benar/salah yang sederhana
  • Ada banyak bagian seperti itu, dan hampir semua komponen sudah punya tim khusus serta riset sendiri. Kemungkinan besar masih akan ada banyak terobosan besar ke depan
  • Untuk bagian yang mengambil porsi lebih besar dari waktu inferensi, kemungkinan upaya optimasinya juga sudah jauh lebih banyak dicurahkan