GigaToken - भाषा मॉडल tokenization को लगभग 1,000 गुना तेज करता है

 (github.com/marcelroed)
3 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • विभिन्न CPU और लोकप्रिय tokenizers को सपोर्ट करने वाला, टेक्स्ट को GB/s स्तर पर प्रोसेस करने वाला Tiktoken और HuggingFace Tokenizers का वैकल्पिक टूल
  • regex engine द्वारा की जाने वाली pre-tokenization को SIMD से optimize करता है, branches·thread communication·Python interaction घटाता है, और पहले देखे गए शब्दों की token mapping को प्रभावी ढंग से cache करता है
  • 11.9GB OpenWebText benchmark में GPT-2 throughput AMD EPYC 9565 पर 24.53GB/s, Apple M4 Max पर 8.79GB/s, और Ryzen 7 9800X3D पर 6.27GB/s रहा
  • HuggingFace·Tiktoken compatible modes मौजूदा code को लगभग वैसा ही रखते हैं, लेकिन output match कराने की लागत के कारण performance कम होती है; Rust द्वारा files को सीधे पढ़ने वाला Gigatoken API maximum parallelism और highest speed देता है
  • WordPiece और file output अभी supported नहीं हैं, SentencePiece optimization और Windows validation भी सीमित हैं, इसलिए फिलहाल यह BPE tokenizers और Linux·macOS या WSL environment के लिए ज्यादा उपयुक्त है

सपोर्ट का दायरा और इस्तेमाल का तरीका

  • Gigatoken language models के लिए high-speed tokenizer है, जो modern x86·ARM CPU और लगभग सभी सामान्य tokenizers को target करता है
  • इसे pip install gigatoken से install किया जाता है, और यह अपना API तथा HuggingFace Tokenizers·Tiktoken compatible modes देता है
  • compatible modes मौजूदा tokenizer को wrap करके क्रमशः .as_hf() या .as_tiktoken() में convert करते हैं
    • HuggingFace Tokenizers के output से बिल्कुल match कराने के लिए काफी काम लागू किया गया है
    • compatibility handling की performance cost नजरअंदाज नहीं की जा सकती, इसलिए यह अपने API के लगभग 1,000x acceleration तक नहीं पहुंचता, लेकिन कुल मिलाकर मौजूदा implementations से तेज है
  • अपना API "Qwen/Qwen3-8B" जैसे HuggingFace model name और TextFileSource लेकर file को सीधे encode करता है
    • Rust implementation data को सीधे पढ़कर अनावश्यक overhead छोड़ता है और parallelism को maximize करता है
    • Python data structures pass करने पर Python में data पढ़ने की cost बची रहती है

speed बढ़ाने वाला implementation

  • सबसे बड़ा सुधार आम तौर पर regex engine को सौंपी जाने वाली pre-tokenization को SIMD-based तरीके से सीधे बेहतर बनाने से आता है
  • branching को minimize किया गया है, और पहले देखे गए words के encoded tokens खोजने वाले pre-token mapping cache को खास तौर पर optimize किया गया है
    • cache तेजी से बढ़ता है और pre-token distribution long-tail form में होता है, इसलिए इसे handle करना मुश्किल है
  • Python के साथ interaction और threads के बीच communication घटाकर अतिरिक्त performance हासिल की गई है
  • यह किसी एक खास CPU या tokenizer के लिए tuned implementation नहीं है; modern x86·ARM CPU और कई tokenizer combinations को अलग-अलग optimize किया गया है, और results भी CPU तथा tokenizers के across consistent हैं

11.9GB OpenWebText benchmark

  • AMD EPYC 9565 144-core environment में GPT-2 throughput 24.53GB/s रहा, जो HuggingFace Tokenizers के 24.8MB/s से 989 गुना और Tiktoken के 36.0MB/s से 681 गुना तेज है
    • प्रमुख BPE family आम तौर पर लगभग 15.49~24.00GB/s दर्ज करती है
    • SentencePiece-based entries लगभग 2.51~4.82GB/s के साथ अपेक्षाकृत धीमी हैं
  • Apple M4 Max 16-core पर GPT-2 8.79GB/s है, जो HuggingFace की तुलना में 1,268 गुना और Tiktoken की तुलना में 140 गुना है
    • OLMo 2/3 ने HuggingFace की तुलना में 1,299 गुना, Qwen 2/2.5 ने 1,105 गुना दर्ज किया
  • AMD Ryzen 7 9800X3D 16-core पर GPT-2 6.27GB/s है, जो HuggingFace की तुलना में 106 गुना और Tiktoken की तुलना में 68 गुना है
    • प्रमुख BPE family लगभग 4.21~6.09GB/s, और अपेक्षाकृत कम optimized family लगभग 1.12~2.84GB/s हैं

measurement conditions और interpretation

  • OWT(OpenWebText) को benchmark data के रूप में चुना गया क्योंकि यह Common Crawl documents extract करने के बाद मिलने वाले text का मोटे तौर पर representative है
  • Gigatoken पूरे file को पहले से split किए बिना process करता है, इसलिए split boundary search और automatic parallelization भी खुद करता है
  • comparison targets <|endoftext|> के आधार पर पहले से split किए गए data को process करते हैं
    • HuggingFace encode_batch_fast पहले 100MB का इस्तेमाल करता है
    • Tiktoken encode_ordinary_batch पहले 1GB का इस्तेमाल करता है
    • दोनों implementations cache नहीं करते, इसलिए processing speed आम तौर पर स्थिर रहती है; इसी वजह से यह comparison condition इस्तेमाल की गई
  • Tiktoken results केवल officially supported tokenizers में शामिल हैं
  • हर row vocabulary·merge·pre-tokenizer के समान set वाले एक unique tokenizer को represent करती है
    • Llama, Qwen, DeepSeek, GLM, Nemotron, Kimi, Phi, Gemma families के कई versions और derived models को समान tokenizer row में group किया गया है
  • सबसे धीमे entries Gigatoken में अभी पर्याप्त रूप से optimize न किए गए SentencePiece-based tokenizers हैं

support validation और large-scale processing

  • install किए बिना uvx --with tokenizers gigatoken bench command से HuggingFace model repository की tokenization validate की जा सकती है और time measure किया जा सकता है
  • GPT-2 validation example में 20,401 documents का output match हुआ
    • Apple M4 Max पर 11,920.51MB को 1.432 seconds में, 8,327.05MB/s पर process किया गया, जो HuggingFace से 1,353.13 गुना तेज था
    • AMD EPYC 9565 पर वही data 0.486 seconds में, 24,532.45MB/s पर process हुआ, जो 989.21 गुना तेज था
  • EPYC throughput के हिसाब से 130 trillion tokens के Common Crawl पूरे scale को 6.5 घंटे से कम में tokenize किया जा सकता है
  • examples Stanford CS336 OWT sample का इस्तेमाल करते हैं, और CLI by default validation तथा HuggingFace comparison के लिए file के पहले 100MB का उपयोग करता है
  • macOS पर first run में security check के कारण Rust code धीमा हो सकता है, इसलिए accurate measurement के लिए command को दो बार run करना पड़ सकता है
  • output mismatch या slow cases को GitHub Issue पर report करने का अनुरोध किया गया है

ज्ञात सीमाएं

  • Python iteration Rust में की जाती है, लेकिन internal CPython version-specific API से धीमे ABI3 का इस्तेमाल होता है
    • Python version-specific specialization की योजना है, और शुरुआती experiments में overhead-dominated cases 2 गुना तेज हुए
  • Gigatoken API में अभी file output sink implement नहीं है
  • WordPiece support नहीं है
  • SentencePiece-based tokenization सामान्य BPE की तुलना में कम optimized है
    • मुख्य रूप से Google models और BERT family द्वारा इस्तेमाल किए जाने के कारण इसकी priority अभी कम है
  • Windows testing पर्याप्त नहीं है, इसलिए फिलहाल WSL usage recommend किया गया है

AI इस्तेमाल का दायरा

  • codebase का अधिकतर हिस्सा AI के बिना सीधे लिखा गया है, और project Git history में यह verify किया जा सकता है
  • project के final stage में AI का इस्तेमाल इन कामों के लिए किया गया
    • user-facing API implementation
    • ज्यादा tokenizers के लिए pre-tokenizer generalization·porting और compatibility expansion
    • padding, truncation, Unicode normalization support
    • AVX512·AVX2·NEON के बीच SIMD strategy porting
    • branch removal और pre-token cache hierarchy improvement के जरिए आखिरी लगभग 4x performance improvement
    • refactoring और code reuse improvement

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की रायें

  • यह कहना कि “ज़्यादातर कोड AI के बिना सीधे लिखा गया था, और Git इतिहास में भी इसकी पुष्टि की जा सकती है”, human programming is dead वाली घोषणा को फीका कर देता है

  • यह किसी एक खास CPU और tokenizer के लिए नहीं, बल्कि नवीनतम x86·ARM और कई tokenizer combinations के पूरे सेट पर ज़रूरत से ज़्यादा optimization करके लगातार performance हासिल करने का मामला है
    आम तौर पर regex engine पर छोड़ी जाने वाली pre-tokenization को SIMD से सीधे optimize किया गया, branching को कम किया गया, और पहले से देखे गए शब्दों के encoding results जल्दी ढूंढने के लिए pre-token mapping cache भी सुधारा गया। इस क्षेत्र में cache बहुत जल्दी बड़ा हो जाता है और distribution की tail लंबी होती है, इसलिए इसे संभालना मुश्किल होता है
    Python के साथ interaction और threads के बीच communication भी कम से कम रखा गया

  • इससे simdjson याद आता है, जो creative programming से यक़ीन करना मुश्किल speed देता है। अगर यह व्यापक रूप से इस्तेमाल हुआ, तो power, cost और carbon emissions को काफ़ी कम किया जा सकता है, इसलिए अच्छा होगा अगर एक Rust crate भी जारी किया जाए; ज़रूरत हो तो मैं खुद मदद करना चाहूँगा

    • tokenization शायद ही कभी कोई meaningful bottleneck रहा है, और JSON serialization भी ज़्यादातर ऐसा ही है। serialization और tokenization से कहीं ज़्यादा energy I/O और storage में खर्च होती है
      economics और environment के लिहाज़ से request batching कहीं ज़्यादा असरदार है। सबसे महंगी समस्या GPU utilization का कम होना है, और अगर काम को batch processing के हिसाब से ढाला जाए तो अभी OAI में भी 50% बचत हो सकती है। अगर हर जवाब तुरंत नहीं चाहिए, तो कुछ के लिए कुछ दिन इंतज़ार भी किया जा सकता है; tool calls timeout नहीं होते, और LLM के लिए खुद कोई wall-clock time नहीं होता

  • repository clone करके देखा, तो pre-tokenization regex replacement और cache optimization आम तौर पर भी उपयोगी approach लगते हैं। यह इतना शानदार काम है कि पूरी tokenization community इस speedup का राज़ सीखना चाहेगी

    • जल्द ही project की technical explanation और paper, साथ में presentation video भी बनाकर Discord पर share करने वाले हैं
    • inference ही नहीं, proprietary datasets का इस्तेमाल करने वाली training में भी इसकी बड़ी value है, और यह सब एक ही व्यक्ति ने किया है, यह भी प्रभावशाली है

  • शानदार उपलब्धि है, लेकिन आम तौर पर tokenization कुल inference time का 0.1% से भी कम होता है। फिर भी, जिन applications में tokenization खुद ज़रूरी है, वहाँ यह बहुत उपयोगी होगा

    • inference method के हिसाब से tokenization का हिस्सा काफ़ी बड़ा भी हो सकता है। एक single B200 पर 8B Qwen3 चलाकर की गई शुरुआती measurements में gigatoken पर बदलने से time to first token (TTFT) input length 2,048 पर औसतन 5.5%, 8,192 पर 8.4%, और 32,768 पर 7.8% कम हुआ
      छोटे models या तेज़ GPUs पर असर और बड़ा होता है, और README में डालने से पहले अतिरिक्त validation की ज़रूरत है। benchmark का स्रोत fastokens है
    • AI platforms में बाद के routing·rate limiting आदि तय करने के लिए request की शुरुआत में जल्दी tokenization करना पड़ता है। कुल request time में इसका हिस्सा छोटा हो, फिर भी efficiency महत्वपूर्ण है
    • tokenization ज़्यादातर serial processing होती है, इसलिए अगर initial prompt बड़ा हो तो input processing time में इसका हिस्सा काफ़ी बड़ा हो सकता है। model inference को सौंपने के बाद सभी tokens को parallel process किया जा सकता है
    • inference compute का 1/1,000 भी scale बड़ा होने पर नज़रअंदाज़ करना मुश्किल है। Gartner ने 2026 के inference spending का अनुमान लगभग 28 अरब डॉलर लगाया है, इसलिए ऊपर की धारणाएँ लागू करें तो यह सालाना 2.8 करोड़ डॉलर के स्तर का मामला है
      स्रोत: https://www.gartner.com/en/newsroom/press-releases/2026-07-2...
    • खासकर छोटे models में time to first token latency को काफ़ी घटाया जा सकता है। Groq या Cerebras जैसे inference providers के लिए total throughput जितनी ही latency भी महत्वपूर्ण है

  • inference के समय से ज़्यादा यह offline pretraining data preparation में उपयोगी लगता है। training corpus के लिए कई terabytes text को tokenize करते समय समय और लागत बच सकती है, और dataset को tweak करने का iteration cycle भी छोटा हो सकता है

  • कुल execution time के 0.1% हिस्से को 1,000x faster बनाने के लिए engineering क्षमता झोंक देना ही सबसे software developer जैसी हरकत है

    • मैंने Rust में high-resolution word cloud लगभग 100ms में बनाई थी, और आगे optimize करके उसे करीब 16ms तक ले गया। दुनिया को इतनी तेज़ word cloud generator की ज़रूरत नहीं है, लेकिन अगर बनानी है तो जितनी तेज़ हो सके उतनी होनी चाहिए
    • “excellence की pursuit को किसी justification की ज़रूरत नहीं होती”
      https://x.com/mitchellh/status/2074225453217505494
    • यह workflow पर निर्भर करता है। ऐसे use cases भी हैं जहाँ text को सीधे model में नहीं डाला जाता, बल्कि सिर्फ tokenization किया जाता है
    • अगर किसी low-level component में भी 1,000x improvement हो जाए, तो गुणात्मक रूप से नई capabilities संभव हो जाती हैं। उस हिस्से का पूरे सिस्टम में सिर्फ 0.1% होना भी अक्सर इस वजह से होता है कि project भर में बार-बार “कुल performance पर असर नहीं है, तो इसे ठीक से क्यों बनाएं” वाला रवैया अपनाया गया होता है
      LLMs पहले से ही 1,000x improvement की सीमा के काफ़ी करीब हैं, लेकिन बुनियादी PyTorch operations भी अक्सर simple rewrites की तुलना में 2x धीमे होते हैं, और बेहतर scheduling algorithms 5~10x improvement दे सकते हैं। तेज़ tokenization उन दूसरी features के दरवाज़े भी खोल सकती है जिन्हें अब तक असंभव मानकर नज़रअंदाज़ किया गया था
    • अगर routing के लिए ultra-small language model (SLM) चलाने हेतु tokenization की जा रही है, तो इसका हिस्सा 0.1% से कहीं ज़्यादा हो सकता है। यह वैसा ही सोचने जैसा है कि “PC ज़्यादातर समय desktop पर idle रहता है, इसलिए GPU driver optimization महत्वपूर्ण नहीं है”

  • graph के numbers समझने के लिए काफ़ी देर तक देखना पड़े, इतनी यक़ीन से बाहर performance है

  • ClickHouse में भी ठीक यही चीज़ चाहिए, इसलिए https://github.com/ClickHouse/ClickHouse/issues/108247 में इसे आज़माने वाले हैं
    अच्छा होगा अगर README per-core performance को और ज़्यादा उभारकर दिखाए, और यह भी जिज्ञासा है कि असली algorithm में perfect hash table matching मददगार होगा या नहीं

  • तब यह सवाल उठता है कि inference pipeline के दूसरे हिस्सों में अभी भी 1,000x optimization opportunities कितनी बची हुई हैं

    • tokenization layer के विपरीत, inference के दूसरे बदलावों में सिर्फ सही या ग़लत का सरल फ़ैसला करना मुश्किल होता है
    • ऐसे हिस्से बहुत हैं, और लगभग हर component पर dedicated teams और research लगी हुई है। आगे भी कई बड़े breakthroughs आने की संभावना है
    • inference time में बड़ा हिस्सा लेने वाले क्षेत्रों में शायद पहले से ही कहीं ज़्यादा optimization effort लगाया गया होगा