OpenAI در ۲۲ سپتامبر GPT-6 Sol و GPT-6 Luna را عرضه کرد؛ دو مدل از خانواده GPT-6 که برای استدلال، برنامهنویسی و کارهای عاملمحور با هزینه پایینتر طراحی شدهاند. نکته مهم فقط اضافهشدن دو انتخاب جدید نیست. اختلاف قیمت Sol و Luna آنقدر زیاد است که مسیریابی میان مدلها به یک تصمیم معماری و اقتصادی تبدیل میشود.
برای درخواستهای استاندارد تا سقف ۲۷۲ هزار توکن ورودی، قیمت GPT-6 Sol به ازای هر یک میلیون توکن ورودی ۲ دلار، برای ورودی ذخیرهشده در حافظه نهان ۰٫۲۰ دلار و برای خروجی ۱۰ دلار است. قیمتهای GPT-6 Luna بهترتیب ۰٫۱۰، ۰٫۰۱ و ۰٫۵۰ دلار هستند. هر دو مدل از متن و تصویر بهعنوان ورودی پشتیبانی میکنند و از طریق Responses API و Chat Completions در دسترساند.
Luna هزینه مراحل ساده عامل را بهطور جدی پایین میآورد
ورودی و خروجی Luna در تعرفه استاندارد یکبیستم Sol قیمت دارد. برای سامانهای که در یک مأموریت دهها بار مدل را برای دستهبندی، استخراج اطلاعات، برنامهریزی اولیه یا تغییرهای ساده کد فراخوانی میکند، استفاده از مدل قویتر در همه مراحل دیگر انتخاب بدیهی نیست.
تحلیل Aipolix این است که باید مسیریابی را در سطح کل گردش کار سنجید. میتوان مراحل ساده را به Luna سپرد و موارد دشوار را به Sol فرستاد، اما فقط زمانی که مدل ارزانتر باعث تلاش مجدد، تصمیم میانی اشتباه یا بازبینی انسانی بیشتر نشود. معیار مناسب، هزینه هر مأموریت پذیرفتهشده است نه صرفاً قیمت توکن.
این تفاوت در عاملها اهمیت بیشتری دارد، چون یک درخواست کاربر میتواند زنجیرهای از برنامهریزی، انتخاب ابزار، ویرایش کد، بررسی و تکرار ایجاد کند. اختلاف کوچک در هر مرحله در کل مسیر جمع میشود.
Sol برای کارهای دشوار، زمینه بزرگی در اختیار میگذارد
مستندات OpenAI، GPT-6 Sol را برای برنامهنویسی پیچیده و گردش کار عاملها معرفی میکند. این مدل پنجره زمینه ۱٫۰۵ میلیون توکنی و سقف خروجی ۱۲۸ هزار توکن دارد. میزان استدلال نیز از none تا max قابل تنظیم است.
زمینه بزرگ میتواند نیاز به حذف بخشهای زیادی از مخزن کد، اسناد یا سابقه نشست را کمتر کند، اما رایگان نیست. طبق تعرفه فعلی، وقتی ورودی از ۲۷۲ هزار توکن عبور کند، نرخ ورودی و حافظه نهان دو برابر میشود و قیمت خروجی برای کل درخواست ۵۰ درصد افزایش پیدا میکند.
بنابراین مرز ۲۷۲ هزار توکن فقط یک جزئیات مالی نیست. تیم باید بسنجد آیا زمینه اضافه واقعاً خطاهای ناشی از کمبود اطلاعات، تلاشهای مجدد یا پیچیدگی بازیابی را آنقدر کاهش میدهد که هزینه بیشتر توجیه شود.
معماریهای فعلی API میتوانند مدلها را مستقیم آزمایش کنند
Sol و Luna از طریق Responses API و Chat Completions ارائه شدهاند. OpenAI برای ابزارهای داخلی و فراخوانی تابع در Sol، Responses API را پیشنهاد میدهد. پشتیبانی از تصویر نیز امکان استفاده در عاملهایی را میدهد که با اسکرینشات، سند یا داده بصری کار میکنند.
برای تیمی که از قبل Responses API دارد، نیازی به پروتکل تازه برای عامل نیست. میتوان Sol و Luna را بهعنوان مقصدهای مختلف در همان سازوکار مسیریابی و ارزیابی قرار داد. در یک آزمون منصفانه باید دستورها، ابزارها، مجوزها و معیار پذیرش ثابت بمانند و نرخ موفقیت، تعداد فراخوانی ابزار، زمان، تکرار و هزینه کل مقایسه شوند.
اقامت داده در اروپا یک محدودیت اجرایی دیگر است
طبق صفحه فعلی تعرفه، اقامت داده در اتحادیه اروپا برای Sol و Luna فقط با پردازش Standard در دسترس است و پردازش منطقهای در موارد مشمول ۱۰ درصد هزینه بیشتر دارد.
برای سازمانهای اروپایی، از جمله شرکتهای پرتغالی، انتخاب مدل از شیوه پردازش جدا نیست. اگر اقامت داده الزام باشد، ارزانترین گزینه پردازش الزاماً قابل استفاده نخواهد بود. بنابراین مقایسه هزینه باید دقیقاً با تنظیمات مورد نیاز محیط تولید انجام شود.
مدل ارزانتر جای مهندسی درست عامل را نمیگیرد
کاهش قیمت فراخوانی آزمایش را ارزانتر میکند، اما مسئله قابلیت اتکا را حل نمیکند. کنترل ابزار، مدیریت وضعیت، ارزیابی، نقطههای بازیابی و رسیدگی به خطا همچنان تعیین میکنند یک عامل مفید و قابل اعتماد باشد یا نه.
فرصت اصلی Luna امکان اجرای تعداد بسیار بیشتری از مراحل استدلال در یک بودجه ثابت است. خطر اصلی این است که فرض کنیم این موضوع خودبهخود هزینه مأموریت را پایین میآورد. یک تصمیم ضعیف در ابتدای مسیر میتواند چندین فراخوانی اضافی ایجاد کند.
پیش از تغییر محیط تولید چه چیزی را بسنجیم؟
بهتر است مدل فعلی با دو حالت مقایسه شود: استفاده کامل از Sol و مسیری که کار را از Luna شروع میکند و در صورت نیاز به Sol میفرستد. ابزار و سیاست باید یکسان بمانند. نرخ مأموریتهای پذیرفتهشده، ارجاعها، تکرارها، فراخوانی ابزار، استفاده از زمینه بلند، زمان و بازبینی انسانی را ثبت کنید.
اهمیت این عرضه در گسترش فاصله قیمت داخل یک خانواده از مدلهای استدلالی است. بهترین معماری لزوماً مدلی نیست که در همه مراحل قویترین گزینه را انتخاب کند؛ باید توان مدل را جایی مصرف کند که نتیجه نهایی را واقعاً تغییر میدهد.