- Çeşitli CPU'ları ve yaygın olarak kullanılan tokenizer'ları destekleyen, metni GB/s düzeyinde işleyen bir Tiktoken ve HuggingFace Tokenizers alternatifi
- Genelde regex motorunun üstlendiği ön tokenizasyonu SIMD ile optimize ediyor; dal, thread iletişimi ve Python etkileşimini azaltıyor; daha önce görülen kelimelerin token eşlemesini verimli biçimde önbelleğe alıyor
- 11.9GB OpenWebText benchmark'ında GPT-2 throughput'u AMD EPYC 9565'te 24.53GB/s, Apple M4 Max'te 8.79GB/s ve Ryzen 7 9800X3D'de 6.27GB/s olarak ölçüldü
- HuggingFace ve Tiktoken uyumluluk modları mevcut kodu neredeyse olduğu gibi koruyor, ancak çıktı eşleşmesinin maliyeti nedeniyle performans düşüyor; dosyayı doğrudan Rust'ın okuduğu Gigatoken API ise en yüksek paralellik ve en yüksek hızı sağlıyor
- WordPiece ve dosya çıktısı henüz desteklenmiyor; SentencePiece optimizasyonu ve Windows doğrulaması da yetersiz, bu yüzden şu anda BPE tokenizer'lar ile Linux·macOS veya WSL ortamları için daha uygun
Destek kapsamı ve kullanım şekli
- Gigatoken, dil modelleri için yüksek hızlı bir tokenizer olup modern x86·ARM CPU'ları ve neredeyse tüm yaygın tokenizer'ları hedefliyor
pip install gigatokenile kuruluyor ve kendi API'siyle birlikte HuggingFace Tokenizers ve Tiktoken uyumluluk modu sunuyor- Uyumluluk modu, mevcut tokenizer'ı sararak sırasıyla
.as_hf()veya.as_tiktoken()ile dönüştürüyor- HuggingFace Tokenizers ile çıktının tam olarak eşleşmesi için önemli miktarda çalışma uygulanmış
- Uyumluluk işlemlerinin göz ardı edilemeyecek bir performans maliyeti var; bu yüzden kendi API'sinin yaklaşık 1.000 kat hız artışına ulaşmasa da genel olarak mevcut uygulamalardan daha hızlı
- Kendi API'si,
"Qwen/Qwen3-8B"gibi bir HuggingFace model adı veTextFileSourcealarak dosyayı doğrudan encode ediyor- Rust implementasyonu veriyi doğrudan okuyarak gereksiz overhead'i atlıyor ve paralelliği en üst düzeye çıkarıyor
- Python veri yapıları aktarılırsa Python'da veri okuma maliyeti devam ediyor
Hızı artıran implementasyon
- En büyük iyileştirme, genelde regex motoruna bırakılan ön tokenizasyonun SIMD tabanlı olarak doğrudan ileri düzeyde optimize edilmesinden geliyor
- Dallanmalar en aza indiriliyor ve daha önce görülen kelimelerin encode edilmiş token'larını bulmak için kullanılan ön token eşleme önbelleği yoğun biçimde optimize ediliyor
- Önbellek hızla büyüyor ve ön token dağılımı uzun kuyruklu olduğundan yönetmesi zor
- Python ile etkileşim ve thread'ler arası iletişim azaltılarak ek performans elde ediliyor
- Belirli bir CPU'ya ya da tek bir tokenizer'a özel bir implementasyon yerine, modern x86·ARM CPU'lar ve çeşitli tokenizer kombinasyonları ayrı ayrı optimize edilmiş; sonuçlar da CPU'lar ve tokenizer'lar genelinde tutarlı
11.9GB OpenWebText benchmark'ı
- 144 çekirdekli AMD EPYC 9565 ortamında GPT-2 throughput'u 24.53GB/s ile HuggingFace Tokenizers'ın 24.8MB/s değerinden 989 kat, Tiktoken'ın 36.0MB/s değerinden 681 kat daha hızlı
- Başlıca BPE ailesi çoğunlukla yaklaşık 15.49~24.00GB/s kaydediyor
- SentencePiece tabanlı öğeler ise yaklaşık 2.51~4.82GB/s ile görece daha yavaş
- 16 çekirdekli Apple M4 Max'te GPT-2 8.79GB/s ile HuggingFace'e göre 1.268 kat, Tiktoken'a göre 140 kat daha hızlı
- OLMo 2/3, HuggingFace'e göre 1.299 kat; Qwen 2/2.5 ise 1.105 kat hız kaydediyor
- 16 çekirdekli AMD Ryzen 7 9800X3D'de GPT-2 6.27GB/s ile HuggingFace'e göre 106 kat, Tiktoken'a göre 68 kat daha hızlı
- Başlıca BPE ailesi yaklaşık 4.21~6.09GB/s, görece daha az optimize edilmiş aileler ise yaklaşık 1.12~2.84GB/s seviyesinde
Ölçüm koşulları ve yorumlama
- OWT(OpenWebText), Common Crawl belgeleri çıkarıldıktan sonra elde edilen metni kabaca temsil ettiği için benchmark verisi olarak seçildi
- Gigatoken tüm dosyayı önceden bölmeden işlediği için bölme sınırı arama ve otomatik paralelleştirme işlemlerini de doğrudan kendisi yapıyor
- Karşılaştırılan araçlar,
<|endoftext|>temel alınarak önceden bölünmüş veriyi işliyor- HuggingFace
encode_batch_fast, ilk 100MB'ı kullanıyor - Tiktoken
encode_ordinary_batch, ilk 1GB'ı kullanıyor - Her iki implementasyon da önbellekleme yapmadığı için işleme hızları genel olarak sabit kalıyor; bu nedenle bu karşılaştırma koşulları kullanılmış
- HuggingFace
- Tiktoken sonuçları yalnızca resmi olarak desteklenen tokenizer'ları içeriyor
- Her satır, sözlük·merge·ön tokenizer'ı aynı olan tekil bir tokenizer'ı temsil ediyor
- Llama, Qwen, DeepSeek, GLM, Nemotron, Kimi, Phi ve Gemma ailelerinin çeşitli sürümleri ile türev modeller aynı tokenizer satırında gruplanıyor
- En yavaş öğeler, Gigatoken içinde henüz yeterince optimize edilmemiş SentencePiece tabanlı tokenizer'lar
Destek doğrulaması ve büyük ölçekli işleme
- Kurulum yapmadan
uvx --with tokenizers gigatoken benchkomutuyla HuggingFace model deposundaki tokenizasyon doğrulanabilir ve süre ölçülebilir - GPT-2 doğrulama örneğinde 20,401 belge için çıktılar birebir eşleşiyor
- Apple M4 Max'te 11,920.51MB veri 1.432 saniyede, 8,327.05MB/s hızla işlendi ve HuggingFace'ten 1,353.13 kat daha hızlıydı
- AMD EPYC 9565'te aynı veri 0.486 saniyede, 24,532.45MB/s hızla işlendi ve 989.21 kat daha hızlıydı
- EPYC throughput'u ile, 130 trilyon token büyüklüğündeki Common Crawl verisinin tamamı 6.5 saatten kısa sürede tokenize edilebilir
- Örneklerde Stanford CS336 OWT örneği kullanılıyor ve CLI varsayılan olarak doğrulama ile HuggingFace karşılaştırması için dosyanın ilk 100MB'ını kullanıyor
- macOS'ta ilk çalıştırma, güvenlik denetimi nedeniyle Rust kodunu yavaşlatabilir; doğru ölçüm için komutun iki kez çalıştırılması gerekebilir
- Çıktı uyuşmazlıkları veya yavaş örneklerin GitHub Issue üzerinden bildirilmesi isteniyor
Bilinen kısıtlar
- Python iterasyon işlemesi Rust'ta yapılıyor, ancak dahili CPython sürüme özel API'ler yerine daha yavaş olan ABI3 kullanılıyor
- Python sürümüne özel optimizasyonlar planlanıyor; ilk deneylerde overhead'in baskın olduğu durumlarda 2 kat hızlanma görüldü
- Gigatoken API'de henüz dosya çıktı sink'i implement edilmedi
- WordPiece desteklenmiyor
- SentencePiece tabanlı tokenizasyon, yaygın BPE'ye göre daha düşük düzeyde optimize edilmiş
- Bunun başlıca nedeni Google modelleri ve BERT ailesi tarafından kullanılması; bu yüzden şu anki önceliği de düşük
- Windows testleri yeterli olmadığı için şu anda WSL kullanımı öneriliyor
Yapay zeka kullanım kapsamı
- Kod tabanının büyük bölümü yapay zeka olmadan doğrudan yazıldı; bu proje Git geçmişinden doğrulanabilir
- Projenin son aşamalarında yapay zeka şu işler için kullanıldı
- Kullanıcı API'sinin implementasyonu
- Daha fazla tokenizer için ön tokenizer'ın genelleştirilmesi·taşınması ve uyumluluğun genişletilmesi
- Padding, truncation ve Unicode normalization desteği
- AVX512·AVX2·NEON arasında SIMD stratejisinin taşınması
- Dal kaldırma ve ön token önbellek katmanının iyileştirilmesiyle son yaklaşık 4 kat performans artışı
- Refactoring ve kod yeniden kullanımının iyileştirilmesi
1 yorum
Hacker News yorumları
“Kodun büyük bölümünü yapay zekâ olmadan bizzat yazdım; Git geçmişinden de görülebilir” denmesi, insan programlaması bitti iddiasını boşa çıkarıyor
Tek bir CPU ve tek bir tokenizer değil, güncel x86·ARM ile birden fazla tokenizer kombinasyonunun tamamı aşırı optimize edilerek tutarlı performans elde edilmiş
Genelde regex motoruna bırakılan ön tokenizasyonu SIMD ile doğrudan optimize etmiş, dallanmaları en aza indirmiş ve daha önce görülen kelimelerin kodlama sonucunu hızlı bulmak için ön token eşleme önbelleğini de iyileştirmiş. Bu alandaki önbellekler hızla büyür ve dağılımın uzun kuyruğu nedeniyle yönetmesi zordur
Python ile etkileşimi ve thread’ler arası iletişimi de en aza indirmiş
Yaratıcı programlamayla inanılması güç hızlara ulaşan simdjson akla geliyor. Yaygın kullanılırsa enerji, maliyet ve karbon emisyonlarını ciddi ölçüde azaltabilir; bu yüzden bir Rust crate’i de yayımlansa iyi olur, gerekirse bizzat yardımcı olmak isterim
Ekonomi ve çevre açısından bakılırsa istekleri toplu işleme daha büyük etki yaratır. En pahalı sorun GPU kullanım oranının düşmesidir; işleri toplu işleme biçimine uydurursanız mevcut OAI’de bile %50 tasarruf edebilirsiniz. Tüm yanıtlar hemen gerekmiyorsa bazıları birkaç gün bekleyebilir; araç çağrıları zaman aşımına uğramaz ve LLM’in kendisi için duvar saati zamanı diye bir şey yoktur
Depoyu klonlayıp inceledim; ön tokenizasyon regex’ini değiştirme ve önbellek optimizasyonu genel olarak da faydalı yaklaşımlar. Tokenizasyon topluluğunun tamamının bu hız artışının sırrını öğrenmek isteyeceği kadar iyi bir çalışma
Harika bir başarı, ama tokenizasyon genelde toplam çıkarım süresinin %0,1’inden azını oluşturur. Yine de tokenizasyonun kendisine ihtiyaç duyan uygulamalar için çok faydalı olacaktır
Daha küçük modellerde veya daha hızlı GPU’larda etki daha da artar; README’ye koymadan önce ek doğrulama gerekiyor. Benchmark kaynağı fastokens
Kaynak: https://www.gartner.com/en/newsroom/press-releases/2026-07-2...
Çıkarım anından çok çevrimdışı ön eğitim verisi hazırlamada daha faydalı görünüyor. Eğitim derlemi olarak birkaç terabayt metni token’lara ayırırken zaman ve maliyet tasarrufu sağlar, veri kümesini ayarlama yineleme döngülerini de kısaltır
Toplam çalışma süresinin %0,1’ini oluşturan bir parçayı 1.000 kat hızlandırmak için mühendislik gücü harcamak, yazılım geliştiriciliğe en çok yakışan davranışın ta kendisi
https://x.com/mitchellh/status/2074225453217505494
LLM’ler 1.000 kat iyileştirme sınırına çok daha yakın, ancak temel PyTorch işlemleri bile basit bir yeniden yazıma göre çoğu zaman 2 kat yavaş kalıyor; daha iyi zamanlama algoritmaları 5–10 kat iyileşme sağlayabiliyor. Hızlı tokenizasyon, şimdiye kadar uygulanamaz olduğu için göz ardı edilen başka özelliklerin de önünü açabilir
Grafikteki sayıları anlamak için uzun süre bakmak gerekecek kadar inanılmaz bir performans
ClickHouse’un da tam olarak ihtiyaç duyduğu özellik; https://github.com/ClickHouse/ClickHouse/issues/108247 üzerinde denemeyi planlıyorum
README’nin çekirdek başına performansı daha fazla vurgulaması iyi olur; gerçek algoritmada mükemmel hash tablosu eşleştirmesinin faydalı olup olmayacağını merak ediyorum
Öyleyse çıkarım pipeline’ının diğer kısımlarında hâlâ kaç tane 1.000 kat optimizasyon fırsatı kaldığını merak ediyorum