Google Gemini ৩৮৪ × ৩৮৪ px পর্যন্ত যেকোনো ছবির জন্য ২৫৮ টোকেন চার্জ করে। যদি কোনো ছবি সেই আকারের চেয়ে বড় হয়, তবে Gemini প্রতি ৭৬৮ × ৭৬৮ px টাইল-এর জন্য আরও ২৫৮ টোকেন চার্জ যোগ করে। তাই একটি ৫০০ × ৫০০ px ছবির খরচ একটি ৩৮৪ × ৩৮৪ px ছবির মতোই, যেখানে একটি ১৯২০ × ১০৮০ px ফ্রেম ছয়টি টাইল জুড়ে বিস্তৃত এবং এতে ১,৫৪৮ টোকেন ব্যবহৃত হয়। যারা প্রতি টোকেনের জন্য পেমেন্ট করেন সেই ডেভেলপারদের জন্য, ৭৬৮-পিক্সেল সীমা অতিক্রম করা খরচ ৭৫% পর্যন্ত পরিবর্তন করতে পারে।
Gemini যেভাবে ছবির দাম নির্ধারণ করে
Gemini ছবিগুলোকে ভিজ্যুয়াল প্যাচ বা খণ্ডের একটি গ্রিড হিসেবে বিবেচনা করে। একটি ৩৮৪-পিক্সেল বর্গক্ষেত্র ২৫৬টি প্যাচে বিভক্ত হয়; ভিজ্যুয়াল সিকোয়েন্সের শুরু এবং শেষ চিহ্নিত করতে আরও দুটি অতিরিক্ত টোকেন যোগ করা হয়, যার ফলে ফ্ল্যাট ২৫৮-টোকেন মূল্য নির্ধারিত হয়। এর চেয়ে বড় যেকোনো কিছুর ক্ষেত্রে একটি টাইল করার প্রক্রিয়া শুরু হয়: সিস্টেমটি ছবিটিকে ৭৬৮-পিক্সেল টাইল-এ বিভক্ত করে, প্রতিটি টাইল স্বতন্ত্রভাবে মূল্যায়ন করে এবং প্রতিটি টাইলের জন্য ২৫৮ টোকেন চার্জ করে।
টোকেনের সংখ্যা পিক্সেলের পরিমাণের ওপর নয়, বরং টাইল-এর সংখ্যার ওপর নির্ভর করে। একটি ১২৮০ × ৭২০ px ছবি দুটি টাইল দখল করে (২৫৮ × ২ = ৫১৬ টোকেন)। একটি ৩৮৪০ × ২১৬০ px 4K ফ্রেম পনেরোটি টাইল জুড়ে থাকে, যার খরচ ৩,৮৭০ টোকেন। নিয়মটি সহজ—ছবিটি কতটি ৭৬৮-পিক্সেল বর্গক্ষেত্র দখল করে তা গণনা করুন, তাকে ২৫৮ দিয়ে গুণ করুন, তাহলেই আপনি টোকেন বিল পেয়ে যাবেন।
কেন এই নিয়মটি গুরুত্বপূর্ণ
Gemini-র টোকেন মডেল সরাসরি API খরচের ওপর প্রভাব ফেলে।
বিল কমানোর ব্যবহারিক উপায়সমূহ
- টাইল সীমার নিচে থাকুন। একটি ৮০০ × ৮০০ px ছবি চারটি ৭৬৮-পিক্সেল টাইল-এ বিভক্ত হয়, যার খরচ ১,০৩২ টোকেন—যা একটি ৭৬৮ × ৭৬৮ px ছবির তুলনায় চারগুণ বেশি। টাইল-এর সঠিক সীমানায় রিসাইজ করে ৭৫% সাশ্রয় করুন।
- অপ্রয়োজনীয় খালি জায়গা বাদ দিন। বড় সাদা মার্জিনগুলোও প্যাচ তৈরি করে যা টোকেন গণনায় অন্তর্ভুক্ত হয়। এই মার্জিনগুলো ক্রপ করলে খরচ দুই-তৃতীয়াংশ পর্যন্ত কমানো সম্ভব।
- OCR পঠনযোগ্যতার দিকে খেয়াল রাখুন। অক্ষরগুলো মোটামুটি ১৫–২০ px উচ্চতার হলে Gemini টেক্সট পড়তে পারে। কোনো ডকুমেন্ট সেই সীমার নিচে ডাউনস্কেল করলে মডেলটি শব্দগুলো চিনতে ভুল করতে পারে, যার ফলে টেক্সট ইনপুট ব্যবহারের প্রয়োজন হতে পারে যা আরও ব্যয়বহুল হতে পারে।
- প্রতি লাইনের উচ্চতার নিয়ম প্রয়োগ করুন। সাধারণ টেক্সট ডকুমেন্টের ক্ষেত্রে, মোট ছবির উচ্চতা যেন (লাইনের সংখ্যা × ২৫ px) হয় সেদিকে লক্ষ্য রাখুন। এই “গোল্ডেন ফর্মুলা” লাইন স্পেসিং পঠনযোগ্য রাখে এবং একই সাথে একটি মাত্র টাইল-এর মধ্যে সীমাবদ্ধ রাখে।
- ঘন তথ্যের জন্য ছবি ব্যবহার করুন। একটি বড় স্প্রেডশিট বা LaTeX সমীকরণের স্ক্রিনশট টাইপ করার চেয়ে প্রতি টোকেনে অনেক বেশি তথ্য প্রদান করতে পারে। যখন তথ্যের ঘনত্ব বেশি হয়, তখন ছবির ২৫৮-টোকেন খরচ সমপরিমাণ টেক্সট পেলোডের চেয়ে সস্তা হতে পারে।
কখন ছবি টেক্সটের চেয়ে ভালো
কিছু নির্দিষ্ট ধরণের কন্টেন্টের ক্ষেত্রে টোকেন অর্থনীতির ভারসাম্য ছবির পক্ষে চলে যায়:
- নন-ল্যাটিন স্ক্রিপ্ট। হিন্দি, চীনা, আরবি এবং এই জাতীয় স্ক্রিপ্টে একটি ছোট ধারণা প্রকাশ করতে অনেকগুলো অক্ষরের প্রয়োজন হয়; টেক্সট মোডে প্রতিটি অক্ষর একটি টোকেন হিসেবে গণ্য হয়, যেখানে একই ভিজ্যুয়াল একটি মাত্র ইমেজ টাইল-এ এঁটে যায়।
- জটিল গাণিতিক নোটেশন। LaTeX ফর্মুলার ক্ষেত্রে টোকেন সংখ্যা অনেক বেড়ে যায়। ফর্মুলার একটি রেন্ডার করা ছবি একটি টাইল-এর মধ্যেই থাকে, যা প্রায়শই র-LaTeX স্ট্রিং-এর চেয়ে কম খরচে সম্পন্ন হয়।
- বড় UI লেআউট বা টেবিল। একটি ফুল-স্ক্রিন UI মকআপ বা মাল্টি-পেজ টেবিল ছবি হিসেবে রেন্ডার করলে প্রতিটি এলিমেন্ট বর্ণনা করার প্রয়োজন পড়ে না, ফলে তথ্যগুলো মাত্র কয়েকটি টাইল-এ সংকুচিত হয়ে আসে।
ভারসাম্য রক্ষা
নির্বিচারে ছবির আকার ছোট করলে উল্টো ফল হতে পারে। যদি অক্ষরগুলো ১৫-পিক্সেলের ন্যূনতম সীমার নিচে চলে যায়, তবে Gemini-র OCR ব্যর্থ হবে এবং ডেভেলপারদের টেক্সট পাঠানোর বিকল্প বেছে নিতে হবে—যা টোকেন বিল বাড়িয়ে দিতে পারে। অতিরিক্ত ক্রপিং করলে মডেলটি সঠিকভাবে উত্তর দেওয়ার জন্য প্রয়োজনীয় কনটেক্সট বা প্রেক্ষাপট হারিয়ে ফেলতে পারে। সঠিক উপায় হলো এমনভাবে রিসাইজ করা যা পঠনযোগ্যতা বজায় রেখে টাইল সীমানাকে সম্মান করে।
সারকথা
Gemini-র ইমেজ টোকেন অংক বোঝা একটি লুকানো খরচকে একটি নিয়ন্ত্রণযোগ্য চলকে পরিণত করে। প্রতিটি রিকোয়েস্ট থেকে ডজন বা শত শত টোকেন বাঁচাতে ছবিগুলোকে ৭৬৮ px বা তার নিচে রাখুন, অপ্রয়োজনীয় হোয়াইটস্পেস বাদ দিন এবং টেক্সট পঠনযোগ্য রাখা নিশ্চিত করুন। ঘন তথ্যের কন্টেন্টের ক্ষেত্রে—যেমন নন-ল্যাটিন স্ক্রিপ্ট, গণিত, টেবিল—ছবিগুলো প্রায়ই অনেক কম টোকেন খরচে একই তথ্য প্রদান করে। অন্ধভাবে ডাউনস্কেল না করে স্মার্ট প্রি-প্রসেসিং করাই হলো একটি সাশ্রয়ী Gemini ইন্টিগ্রেশনের চাবিকাঠি।
উৎস: dev.to/kushaagr
