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