TokenDagger – OpenAI के Tiktoken से भी तेज़ tokenizer

• OpenAI के TikToken के साथ 100% compatible high-performance tokenizer, जो बड़े पैमाने के text processing में 2x से अधिक throughput और 4x तेज़ code tokenization speed देता है
• PCRE2-आधारित high-speed regular expression parsing engine के ज़रिए token pattern matching speed को अधिकतम करता है
• सरल किया गया BPE algorithm बड़े special token sets को प्रोसेस करते समय performance drop को न्यूनतम करता है
• वास्तविक benchmarks में code tokenization 4x से अधिक तेज़ है, और मौजूदा TikToken-आधारित code को बिना बदलाव के replace करके इस्तेमाल किया जा सकता है
• Python 3.8+ support, PyPI pip install tokendagger से आसानी से install किया जा सकता है, और PCRE2 dependency की आवश्यकता होती है

[GN⁺]

Hacker News की राय

• मुझे लगता है कि कम अवधि में AI/ML इंफ्रास्ट्रक्चर स्टैक में इस तरह C++ से मुख्य bottleneck हल करके अभी भी performance optimization की काफी गुंजाइश है। इसका मतलब पूरे सिस्टम को C++ में फिर से लिखना नहीं है, बल्कि समझदारी भरे engineering trade-off अक्सर वास्तविक performance gains देते हैं। खासकर ऐसा लगता है कि चीनी इंजीनियर इस तरह के काम में अच्छे हैं।
  • मेरे mentor सॉफ्टवेयर डेवलपमेंट को लेकर एक नज़रिया सिखाते थे: चरण 1, पहले इसे चलाओ; चरण 2, इसे तेज़ बनाओ; चरण 3, इसे सुंदर बनाओ। Transformers और LLMs अब उस स्तर पर पहुंच चुके हैं जहाँ वे काफ़ी अच्छी तरह काम करते हैं, इसलिए लगता है कि अभी performance improvement में सबसे बड़े advances का समय है।
  • लंबी अवधि में Python-केंद्रित दुनिया से बाहर निकलना सार्थक होगा। अगर ML engineers सिर्फ़ इसकी familiarity की वजह से इसे इस्तेमाल कर रहे हैं, तो यह future-oriented नहीं है।
  • वास्तव में TikToken Rust में लिखा गया है, इसलिए यह जानने की उत्सुकता है कि यह सुधार सच में C++ port की वजह से है या नहीं।
  • असल में tokenizing सबसे बड़ा bottleneck नहीं है; ज़्यादातर computation वास्तविक CUDA kernel execution में होता है। Python overhead बहुत कम है (vLLM भी मुख्यतः Python में लिखा गया है)। C++ में rewrite का मतलब लगभग हमेशा CUDA kernels को ज़्यादा कुशल तरीके से फिर से लिखना होता है।
• मुझे लगता है कि किसी मौजूदा सिस्टम का ऐसा drop-in replacement बनाना जो performance को काफ़ी बढ़ा दे, काफ़ी सुंदर काम है। ScyllaDB याद आता है।
  • वास्तव में अगर यह इस तरह का replacement न हो, तो मुझे नहीं लगता कोई इसे इस्तेमाल करेगा।
• LLM की कुल performance में tokenizer की अहमियत कितनी है, यह जानने की उत्सुकता है। मुझे tokenizer optimization में दिलचस्पी है लेकिन अभी तक इसे मापा नहीं है। मैंने माना था कि ज़्यादातर cost matmul से आती है, लेकिन टिप्पणियों को देखकर लगता है कि tokenizer का महत्व है।
  • Tokenizing आमतौर पर CPU पर होती है और training या inference में bottleneck बनना दुर्लभ है। ज़्यादातर समय GPU kernels में जाता है, और केवल बहुत छोटे models अपवाद हैं। tokenizer latency को CPU द्वारा अगला batch तैयार करने के तरीके से "छिपाया" भी जा सकता है।
  • tokenizer performance थोड़ी जटिल है, लेकिन जिन संस्थानों के पास असली expertise और resources हैं, वे अक्सर बेहद तेज़ tokenizer खुद लिखते हैं। SentencePiece और tiktoken ऐसे प्रमुख उदाहरण हैं जिन्हें complexity और deployment burden के बावजूद चुना जाता है। असली experts flame graphs देखकर bottleneck पहचानते हैं, और बड़े पैमाने की training में कभी-कभी पहले से tokenization भी कर लेते हैं। साथ ही ऐसा भी लगता है कि C++ फिर से उभर रहा है, जो Rust narrative के विपरीत होने के कारण उद्योग में कुछ तनाव भी दिखाता है। उम्मीद है कि इसके पीछे कोई नया कारण या insight हो।
  • बाकी टिप्पणियों की तरह, tokenizer वास्तव में bottleneck नहीं है; बस inference pipeline का पहला चरण होने की वजह से इस पर पहले काम किया गया।
  • Text tokenizing कुल computation का बहुत छोटा हिस्सा है। फिर भी petabyte-स्तर के डेटा प्रोसेसिंग में थोड़ा भी तेज़ होना हमेशा फ़ायदेमंद है।
• tiktoken के साथ मेल बैठाने के लिए vocab format conversion की ज़रूरत पड़ती है, लेकिन अगर यह आवश्यकता भी हट जाए तो इस्तेमाल के लिए यह वास्तव में पूरी तरह compatible drop-in replacement बन जाएगा। साथ ही ऐसा दो-तरफ़ा उदाहरण भी अच्छा होगा जिसमें tiktoken initialize करने के बाद tokendagger initialize करके यह verify किया जाए कि परिणाम समान हैं।
  • version 0.1.1 से यह सचमुच एक drop-in replacement बन गया है। जल्द ही examples भी जोड़ने का इरादा है।
  • आपने बिल्कुल सही point उठाया, इसलिए मैंने तुरंत update कर दिया।
• यह project BPE crate की तुलना में कैसा है, यह भी जानना चाहूंगा। उस crate की ताकत text को incrementally re-tokenize करने की क्षमता है, और वह tiktoken से तेज़ भी है।
  • अगला कदम incremental re-tokenization feature जोड़ना और उस crate के साथ benchmark करना है।
• दूसरे LLMs के लिए local tokenizer कैसे मिले, यह जानना चाहता हूँ। उदाहरण के लिए Gemini केवल remote API देता है। क्या यह proprietary है, या बड़े पैमाने पर API calls करके token mapping का अनुमान लगाया जा सकता है?
  • Gemini SentencePiece का उपयोग करता है और Gemma के साथ वही tokenizer vocabulary साझा करता है (संदर्भ1, संदर्भ2, संदर्भ3)। बड़े labs में Claude 3 या उससे ऊपर उपयोग करने वाली Anthropic ही ऐसी है जिसके पास local tokenizer नहीं है।
  • Model-specific tokenizers आमतौर पर SentencePiece या Byte-pair encoding(BPE) जैसे core algorithms साझा करते हैं, और wrapper स्तर पर special tokens handling जैसी चीज़ों में अंतर होता है। tiktoken और TokenDagger भी BPE implementations हैं। अगर library स्तर पर model-specific विशेषताएँ शामिल कर दी जाएँ, तो थोड़ा performance gain और आसान integration मिल सकता है। यह कोई बहुत बड़ा काम नहीं है, इसलिए नए models के अनुरूप ढालना भी कठिन नहीं है। संदर्भ उदाहरण: llama का tokenizer.py, Mistral tokenizer
  • मुझे पता था कि Gemini, SentencePiece का उपयोग करता है।
• मैंने पहले कुछ ऐसा ही आज़माया था: tokie। व्यवहार में tokenizer runtime cost का ज़्यादातर हिस्सा pre-tokenizing (regex) में जाता है। लगता है आपने कोई तेज़ regex approach निकाली है। क्या आपने यह भी तुलना की कि अगर सिर्फ़ regex engine बदला जाए और BPE को tiktoken जैसा ही रखा जाए, तो performance में कितना बदलाव आता है? अगर हाँ, तो शायद upstream contribution भी संभव हो।
  • शानदार project है। tiktoken maintain करने वाले व्यक्ति से संपर्क कर लिया है।
• Huggingface tokenizers के साथ भी performance comparison होना चाहिए। tiktoken readme के benchmark अब बहुत पुराने लगते हैं।
  • मेरी निजी राय में tiktoken, huggingface tokenizers से हमेशा धीमा रहा है। क्यों, यह समझने के लिए मैंने अभी तक tiktoken को गहराई से नहीं देखा, लेकिन HF Rust tokenizer user के रूप में मेरा अनुभव यही है।
• मैं tiktoken के WASM bindings भी देखना चाहूंगा, या फिर यह जानना कि शुद्ध js implementation में "b" से आया performance improvement लागू किया जा सकता है या नहीं।
• यह वाकई शानदार project है। हम भी tiktoken का उपयोग करते हैं, और अगर drop-in compatibility के साथ performance improvement मिलता है, तो उसका असर जानने की उत्सुकता है। drop-in तरीका चुनना बेहतरीन है।