एआई टोकन काउंटर और कॉन्टेक्स्ट फ़िट
कोई भी टेक्स्ट चिपकाइए और देखिए वह क़रीब कितने टोकन बनेगा, दी गई कॉन्टेक्स्ट विंडो में समाएगा या नहीं, और आपकी अपनी API दरों पर उसकी लागत क्या होगी। सब कुछ आपके ब्राउज़र में चलता है — टेक्स्ट कभी अपलोड नहीं होता।
क्या यह कॉन्टेक्स्ट विंडो में समाता है?
| कॉन्टेक्स्ट विंडो | आपका टेक्स्ट | समाएगा? |
|---|
कॉन्टेक्स्ट विंडो में आपका इनपुट, मॉडल का जवाब और ऐप जो कुछ पर्दे के पीछे जोड़ता है (सिस्टम प्रॉम्प्ट, निकाले गए दस्तावेज़, चैट इतिहास) — सब एक ही जगह में बँटते हैं। थोड़ी जगह ख़ाली छोड़िए — विंडो को लबालब भर देने पर ही जवाब बीच में कट जाते हैं।
इसकी लागत क्या होगी?
इनपुट लागत के लिए ऊपर चिपकाया गया टेक्स्ट चाहिए — क़ीमत निकालने के लिए कुछ चिपकाइए।
यह अनुमान कैसे काम करता है (और यह सटीक क्यों नहीं है)
असली टोकनाइज़ेशन आपके टेक्स्ट पर मॉडल-विशिष्ट BPE शब्दावली चलाता है — और हर मॉडल परिवार अलग शब्दावली इस्तेमाल करता है, इसलिए “सही” गिनती हर मॉडल के लिए अलग होती है। ब्राउज़र में यह ढंग से करने का मतलब है हर परिवार के लिए कई मेगाबाइट की शब्दावली भेजना, जो इस पेज को धीमा कर देगा — वह भी उस संख्या के लिए जो आपको सिर्फ़ मोटे तौर पर चाहिए।
इसके बजाय यहाँ अक्षरों और शब्दों पर आधारित अनुमान लगाया जाता है, जिसमें रिक्त स्थान, विराम चिह्न और अंकों को अलग-अलग वज़न दिया गया है; सामान्य अंग्रेज़ी गद्य में यह असली गिनती के लगभग 10–15% के भीतर रहता है। दो जगह यह अनुमान चूकता है: कोड और ढेर सारे विराम चिह्नों वाला टेक्स्ट अनुमान से घना टोकनाइज़ होता है, और ग़ैर-लैटिन लिपियाँ (चीनी, जापानी, अरबी, हिंदी) अंग्रेज़ी के मुक़ाबले प्रति अक्षर काफ़ी ज़्यादा टोकन लेती हैं — अक्सर 2–3 गुना।
अगर बिलिंग के लिए सटीकता चाहिए तो अपने प्रोवाइडर का अपना टोकनाइज़र एंडपॉइंट इस्तेमाल कीजिए। “यह समाएगा या नहीं” और “मोटे तौर पर कितना ख़र्च होगा” जैसे सवालों के लिए अनुमान ही काफ़ी है।
टोकन असल में है क्या
मॉडल न अक्षर पढ़ते हैं न शब्द — वे टोकन पढ़ते हैं, जो दोनों के बीच के टुकड़े होते हैं। आम शब्द आम तौर पर एक टोकन होते हैं; लंबे या असामान्य शब्द कई टुकड़ों में बँट जाते हैं। “Unbelievable” शायद तीन टोकन बने, जबकि “the” एक ही टोकन है। अंग्रेज़ी गद्य में एक टोकन औसतन लगभग चार अक्षर, यानी क़रीब तीन-चौथाई शब्द होता है।
क़ीमत और सीमा, दोनों टोकन में ही तय होती हैं: जो आप भेजते हैं, जो वापस आता है, और मॉडल एक बार में जितना रख सकता है।
आपका टेक्स्ट आपके अंदाज़े से ज़्यादा सघन क्यों है
- कोड ठीक से टोकनाइज़ नहीं होता — इंडेंटेशन, ब्रैकेट और camelCase, सबके टोकन लगते हैं। 500 लाइन की फ़ाइल में अक्षरों की गिनती से लगाए अंदाज़े के मुक़ाबले कहीं ज़्यादा टोकन बन सकते हैं।
- ग़ैर-अंग्रेज़ी टेक्स्ट महँगा है। जो भाषाएँ लैटिन लिपि नहीं इस्तेमाल करतीं, उनमें अक्सर प्रति अक्षर 2–3 गुना ज़्यादा टोकन लगते हैं — इसीलिए वही प्रॉम्प्ट जापानी में अंग्रेज़ी से कई गुना महँगा पड़ सकता है।
- दोहराव सस्ता है, ढाँचा नहीं। JSON और Markdown का ढाँचा कई कॉल में तेज़ी से जुड़ता जाता है।
कॉन्टेक्स्ट विंडो ≠ आपका बजट
दस लाख टोकन की विंडो का मतलब यह नहीं कि आपको दस लाख टोकन भेजने ही चाहिए। बहुत लंबे इनपुट में बीच के हिस्सों पर मॉडल का ध्यान कमज़ोर पड़ जाता है, लेटेंसी बढ़ती है, और लागत उसी अनुपात में सीधे बढ़ती जाती है। रिट्रीवल — यानी सिर्फ़ काम के अंश निकालकर भेजना — आम तौर पर पूरी विंडो ठूँस देने से बेहतर भी पड़ता है और सस्ता भी।
अक्सर पूछे जाने वाले प्रश्न
यह काउंटर कितना सटीक है?
सामान्य अंग्रेज़ी गद्य के लिए क़रीब 10–15% के भीतर। कोड और ग़ैर-लैटिन लिपियाँ अनुमान से ऊपर जाती हैं। बिलिंग के सटीक आँकड़ों के लिए अपने प्रोवाइडर का टोकनाइज़र इस्तेमाल कीजिए।
क्या मेरा टेक्स्ट कहीं अपलोड होता है?
नहीं। गणना आपके ब्राउज़र में ही होती है। न कोई रिक्वेस्ट, न लॉगिंग, न स्टोरेज।
आप मॉडल की क़ीमतें क्यों नहीं दिखाते?
क्योंकि वे बदलती रहती हैं, और किसी पुरानी क़ीमत को भरोसे के साथ दिखाना क़ीमत न दिखाने से बुरा है। अपने प्रोवाइडर की मौजूदा दरें डालिए, हिसाब यह टूल कर देगा।
क्या तस्वीरें और ऑडियो टोकन खर्च करते हैं?
हाँ — मल्टीमॉडल इनपुट भी टोकन में बदले जाते हैं, और दर प्रोवाइडर तथा रिज़ॉल्यूशन के हिसाब से बदलती है। यह टूल सिर्फ़ टेक्स्ट के लिए है।
संबंधित: RAG क्या है? · किस काम के लिए कौन-सा एआई मॉडल · सभी मुफ़्त टूल