گوگل Gemini برای هر تصویری تا ابعاد ۳۸۴ × ۳۸۴ پیکسل، ۲۵۸ توکن محاسبه میکند. اگر تصویری از این اندازه بزرگتر باشد، Gemini برای هر کاشی (tile) ۷۶۸ × ۷۶۸ پیکسلی، ۲۵۸ توکن دیگر اضافه میکند. بنابراین، یک تصویر ۵۰۰ × ۵۰۰ پیکسلی همان هزینه یک تصویر ۳۸۴ × ۳۸۴ پیکسلی را دارد، در حالی که یک قاب ۱۹۲۰ × ۱۰۸۰ پیکسلی شامل ۶ کاشی شده و از ۱۵۴۸ توکن استفاده میکند. برای توسعهدهندگانی که به ازای هر توکن هزینه پرداخت میکنند، عبور از مرز ۷۶۸ پیکسلی میتواند هزینه را تا ۷۵٪ تغییر دهد.
نحوه قیمتگذاری تصاویر در Gemini
Gemini با تصاویر به عنوان شبکهای از قطعات بصری (patches) برخورد میکند. یک مربع ۳۸۴ پیکسلی به ۲۵۶ قطعه تقسیم میشود؛ دو توکن اضافی برای علامتگذاری شروع و پایان توالی بصری در نظر گرفته میشود که قیمت ثابت ۲۵۸ توکنی را ایجاد میکند. هر چیزی بزرگتر از این، مرحله کاشیبندی (tiling) را فعال میکند: سیستم تصویر را به کاشیهای ۷۶۸ پیکسلی برش میدهد، هر کاشی را به طور مستقل ارزیابی میکند و برای هر کدام ۲۵۸ توکن محاسبه میکند.
تعداد توکنها با تعداد کاشیها مقیاسبندی میشود، نه با پیکسلهای خام. یک عکس ۱۲۸۰ × ۷۲۰ پیکسلی دو کاشی را اشغال میکند (۵۱۶ = ۲ × ۲۵۸ توکن). یک قاب 4K با ابعاد ۳۸۴۰ × ۲۱۶۰ پیکسل، پانزده کاشی را پوشش میدهد که ۳۸۷۰ توکن هزینه دارد. قانون ساده است: تعداد مربعهای ۷۶۸ پیکسلی که تصویر اشغال میکند را بشمارید، در ۲۵۸ ضرب کنید و هزینه توکنها به دست میآید.
چرا این قانون اهمیت دارد
مدل توکن Gemini مستقیماً به هزینههای API تبدیل میشود.
روشهای عملی برای کاهش هزینه
- زیر حد مجاز کاشیها بمانید. یک تصویر ۸۰۰ × ۸۰۰ پیکسلی به چهار کاشی ۷۶۸ پیکسلی تقسیم میشود که ۱۰۳۲ توکن هزینه دارد؛ یعنی چهار برابر قیمت یک تصویر ۷۶۸ × ۷۶۸ پیکسلی. با تغییر اندازه به دقیقاً مرز کاشی، ۷۵٪ صرفهجویی کنید.
- فضای خالی را حذف کنید. حاشیههای سفید بزرگ همچنان قطعاتی ایجاد میکنند که در مجموع توکنها محاسبه میشوند. برش دادن (cropping) این حاشیهها میتواند هزینهها را تا دو سوم کاهش دهد.
- به خوانایی OCR توجه کنید. Gemini متن را تنها زمانی میخواند که ارتفاع کاراکترها تقریباً ۱۵ تا ۲۰ پیکسل باشد. اگر اندازه یک سند را به کمتر از این حد کاهش دهید، مدل کلمات را از دست میدهد و شما را مجبور میکند به ورودی متنی روی بیاورید که ممکن است گرانتر باشد.
- قانون ارتفاع در هر خط را اعمال کنید. برای اسناد متنی ساده، ارتفاع کل تصویر را برابر با تعداد خطوط ضرب در ۲۵ پیکسل در نظر بگیرید. این «فرمول طلایی» فاصله بین خطوط را خوانا نگه میدارد و در عین حال تصویر را در محدوده یک کاشی حفظ میکند.
- برای دادههای متراکم، تصاویر را ترجیح دهید. یک اسکرینشات از یک صفحه گسترده (spreadsheet) بزرگ یا یک معادله LaTeX اغلب اطلاعات بیشتری را در هر توکن نسبت به تایپ کردن همان دادهها ارائه میدهد. وقتی تراکم بالا باشد، هزینه ۲۵۸ توکنی تصویر میتواند ارزانتر از بار (payload) متنی معادل باشد.
زمانی که تصاویر بر متن غلبه میکنند
اقتصاد توکن برای چندین نوع محتوا به نفع تصاویر تغییر میکند:
- خطوط غیرلاتین. خطوط هندی، چینی، عربی و موارد مشابه برای انتقال یک ایده کوتاه به کاراکترهای زیادی نیاز دارند؛ در حالت متنی، هر کاراکتر همچنان یک توکن محسق میشود، در حالی که همان محتوا در یک کاشی تصویر جای میگیرد.
- نمادگذاریهای ریاضی پیچیده. فرمولهای LaTeX تعداد توکنها را به شدت افزایش میدهند. یک تصویر رندر شده از فرمول در یک کاشی باقی میماند و اغلب هزینه کمتری نسبت به رشته (string) خام LaTeX دارد.
- طرحهای رابط کاربری (UI) بزرگ یا جداول. رندر کردن یک طرح اولیه (mockup) رابط کاربری تمامصفحه یا یک جدول چند صفحهای به صورت تصویر، نیاز به توصیف هر عنصر به صورت متنی را از بین میبرد و اطلاعات را در چند کاشی فشرده میکند.
موازنه (Trade-off)
کاهش بیرویه اندازه تصویر میتواند نتیجه معکوس داشته باشد. اگر کاراکترها به کمتر از حداقل ۱۵ پیکسل برسند، OCR مدل Gemini با شکست مواجه میشود و توسعهدهندگان مجبور میشوند به ارسال متن خام روی بیاورند که پتانسیل افزایش هزینه توکن را دارد. برش (cropping) بیش از حد نیز ممکن است زمینهای (context) را که مدل برای پاسخگویی صحیح به آن نیاز دارد، حذف کند. نقطه بهینه، تغییر اندازه ملایمی است که مرز کاشی را رعایت کرده و در عین حال خوانایی را حفظ کند.
خلاصه کلام
درک محاسبات توکن تصویر در Gemini، یک هزینه پنهان را به یک متغیر قابل کنترل تبدیل میکند. تصاویر را در اندازه ۷۶۸ پیکسل یا کمتر نگه دارید، فضاهای خالی غیرضروری را حذف کنید و مطمئن شوید که متن خوانا باقی میماند تا دهها یا صدها توکن از هر درخواست کم کنید. برای محتوای متراکم دادهها (خطوط غیرلاتین، ریاضیات، جداول)، تصاویر اغلب همان بینش را با کسری از قیمت توکن ارائه میدهند. پیشپردازش هوشمند، و نه کاهش اندازه کورکورانه، کلید یک ادغام بهینه با Gemini است.
Source: dev.to/kushaagr
