Google Gemini ३८४ × ३८४ px पर्यंतच्या कोणत्याही इमेजसाठी २५८ टोकन्स आकारते. जर इमेजचा आकार त्यापेक्षा जास्त असेल, तर Gemini प्रत्येक ७६८ × ७६८ px टाइलसाठी आणखी २५८ टोकन्सचा अतिरिक्त शुल्क आकारते. त्यामुळे ५०० × ५०० px च्या फोटोसाठी ३८४ × ३८४ px इतकाच खर्च येतो, तर १९२० × १०८० px च्या फ्रेमसाठी सहा टाइल्स लागतात आणि १,५४८ टोकन्स वापरले जातात. प्रति टोकन पैसे देणाऱ्या डेव्हलपर्ससाठी, ७६८-पिक्सेलची मर्यादा ओलांडल्यामुळे खर्च ७५% पर्यंत बदलू शकतो.

Gemini इमेजचे दर कसे ठरवते

Gemini फोटोंना व्हिज्युअल पॅचेसच्या (visual patches) ग्रिडप्रमाणे हाताळते. ३८४-पिक्सेलचा चौरस २५६ पॅचेसमध्ये विभागला जातो; व्हिज्युअल सिक्वेन्सची सुरुवात आणि शेवट दर्शवण्यासाठी दोन अतिरिक्त टोकन्स वापरले जातात, ज्यामुळे २५८ टोकन्सचा निश्चित दर मिळतो. यापेक्षा मोठी कोणतीही इमेज असल्यास 'टायलिंग' (tiling) प्रक्रिया सुरू होते: सिस्टम इमेजचे ७६८-पिक्सेलच्या टाइल्समध्ये तुकडे करते, प्रत्येक टाइलचे स्वतंत्रपणे मूल्यमापन करते आणि प्रत्येक टाइलसाठी २५८ टोकन्स आकारते.

टोकनची संख्या कच्च्या पिक्सेलवर (raw pixels) नाही, तर टाइल्सच्या संख्येवर अवलंबून असते. १२८० × ७२० px चा फोटो दोन टाइल्स व्यापतो (२५८ × २ = ५१६ टोकन्स). ३८४० × २१६० px च्या 4K फ्रेमसाठी पंधरा टाइल्स लागतात, ज्याचा खर्च ३,८७० टोकन्स होतो. नियम सोपा आहे—इमेजने व्यापलेल्या ७६८-पिक्सेलच्या चौरसांची गणना करा, त्याला २५८ ने गुणा आणि तुमचा टोकन बिल तयार होईल.

हा नियम का महत्त्वाचा आहे

Gemini चे टोकन मॉडेल थेट API खर्चावर परिणाम करते.

बिल कमी करण्याचे व्यावहारिक मार्ग

  • टाईल मर्यादेच्या आत राहा. ८०० × ८०० px ची इमेज चार ७६८-पिक्सेलच्या टाइल्समध्ये विभागली जाते, ज्याचा खर्च १,०३२ टोकन्स होतो—हा ७६८ × ७६८ px च्या फोटोच्या किमतीपेक्षा चारपट आहे. नेमक्या टाइलच्या सीमेपर्यंत इमेज रिसाईज करा आणि ७५% बचत करा.
  • रिकामी जागा कमी करा. मोठ्या पांढऱ्या मार्जिनमुळे (margins) तयार होणारे पॅचेस देखील टोकनच्या एकूण गणनेत येतात. ही मार्जिन क्रॉप केल्यामुळे खर्च दोन तृतीयांश कमी होऊ शकतो.
  • OCR वाचनीयतेची काळजी घ्या. जेव्हा अक्षरांची उंची साधारणपणे १५-२० px असते, तेव्हाच Gemini मजकूर वाचू शकते. जर तुम्ही डॉक्युमेंट त्यापेक्षा कमी आकारात रिसाईज केले, तर मॉडेलला शब्द वाचता येत नाहीत, ज्यामुळे तुम्हाला महागड्या टेक्स्ट इनपुटचा पर्याय वापरावा लागू शकतो.
  • प्रति ओळ उंचीचा नियम वापरा. साध्या मजकूर असलेल्या डॉक्युमेंटसाठी, एकूण इमेजची उंची ही ओळींच्या संख्येला २५ px ने गुणून मिळालेल्या उंचीइतकी असावी. हे "गोल्डन फॉर्म्युला" ओळींमधील अंतर वाचनीय ठेवते आणि एकाच टाइलमध्ये राहण्यास मदत करते.
  • दाट माहितीसाठी इमेजला प्राधान्य द्या. मोठ्या स्प्रेडशीटचा स्क्रीनशॉट किंवा LaTeX समीकरण हे तेच डेटा टाईप करण्यापेक्षा प्रति टोकन अधिक माहिती देऊ शकते. जेव्हा माहितीची घनता जास्त असते, तेव्हा इमेजचा २५८-टोकन खर्च हा त्या माहितीच्या समकक्ष टेक्स्ट पेलोडपेक्षा स्वस्त असू शकतो.

जेव्हा इमेज मजकुरापेक्षा सरस ठरते

खालील प्रकारच्या मजकुरासाठी टोकन इकॉनॉमी इमेजच्या बाजूने झुकते:

  • नॉन-लॅटिन स्क्रिप्ट्स (Non-Latin scripts). हिंदी, चिनी, अरबी आणि तत्सम लिपींमध्ये एखादी छोटी कल्पना व्यक्त करण्यासाठी अनेक अक्षरांची गरज असते; टेक्स्ट मोडमध्ये प्रत्येक अक्षर एक टोकन बनते, तर तीच दृश्य माहिती एका इमेज टाइलमध्ये बसू शकते.
  • जटिल गणितीय चिन्हे. LaTeX सूत्रांमुळे टोकनची संख्या खूप वाढते. सूत्राची रेंडर केलेली इमेज एका टाइलमध्ये राहते, ज्याचा खर्च अनेकदा मूळ LaTeX स्ट्रिंगपेक्षा कमी असतो.
  • मोठे UI लेआउट्स किंवा टेबल्स. पूर्ण-स्क्रीन UI मॉकअप किंवा बहु-पृष्ठीय टेबल इमेज म्हणून रेंडर केल्यामुळे प्रत्येक घटकाचे शब्दांत वर्णन करण्याची गरज उरत नाही, ज्यामुळे माहिती काही मोजक्या टाइल्समध्ये संकुचित होते.

तडजोड (The trade-off)

इमेजचा आकार विनाकारण कमी केल्यास त्याचे उलट परिणाम होऊ शकतात. जर अक्षरे १५-पिक्सेलच्या किमान मर्यादेपेक्षा लहान झाली, तर Gemini चे OCR काम करणे थांबवते आणि डेव्हलपर्सना मूळ मजकूर पाठवावा लागतो—ज्यामुळे टोकन बिल वाढू शकते. अतिरेकी क्रॉपिंगमुळे मॉडेलला अचूक उत्तर देण्यासाठी आवश्यक असलेला संदर्भ (context) देखील कापला जाऊ शकतो. योग्य पद्धत म्हणजे टाइलच्या सीमेचा विचार करून आणि वाचनीयता टिकवून ठेवून इमेजचा मध्यम प्रमाणात रिसाईज करणे.

सारांश

Gemini च्या इमेज टोकन गणिताचा समज असल्यास, लपलेला खर्च एका नियंत्रणीय घटकात बदलता येतो. प्रत्येक विनंतीमधून (request) दहा-वीस किंवा शेकडो टोकन्स वाचवण्यासाठी इमेज ७६८ px किंवा त्यापेक्षा कमी ठेवा, अनावश्यक व्हाईटस्पेस कमी करा आणि मजकूर वाचनीय राहील याची खात्री करा. दाट माहिती असलेल्या मजकुरासाठी—नॉन-लॅटिन स्क्रिप्ट्स, गणित, टेबल्स—इमेज अनेकदा कमी टोकन किमतीत तीच माहिती देतात. अंधाधुंदपणे आकार कमी करण्यापेक्षा, स्मार्ट प्रीप्रोसेसिंग (preprocessing) करणे हीच कार्यक्षम Gemini इंटिग्रेशनची गुरुकिल्ली आहे.

स्रोत: dev.to/kushaagr