GPT-6 Sol یا Luna؛ کیفیت بیشتر ارزش هزینهٔ ۲۰ برابری را دارد؟

در جدول قیمت API OpenAI، نرخ استاندارد هر میلیون توکن ورودی و خروجی برای GPT-6 Sol به‌ترتیب ۲ و ۱۰ دلار و برای GPT-6 Luna برابر ۰٫۱۰ و ۰٫۵۰ دلار است؛ با ترکیب توکنی یکسان، هزینهٔ Sol در هر دو بخش ۲۰ برابر می‌شود. برای درخواست‌های متمرکز و پرتعداد، Luna معمولاً انتخاب اقتصادی‌تری است.

Sol زمانی می‌تواند ارزش پرداخت بیشتر را داشته باشد که در کدنویسی دشوار یا کار عامل‌محور، نتیجهٔ پذیرفته‌شده را با تلاش و بازبینی کمتری تحویل دهد. این برتری را نمی‌توان از نام مدل یا یک امتیاز عمومی به هزینهٔ پروژه تعمیم داد: تعداد فراخوانی‌ها، طول خروجی، مصرف کش و نرخ پذیرش نتیجه، همگی در تصمیم اثر دارند.

سه بودجهٔ نمونه برای سه نوع گردش‌کار

محاسبه‌های زیر فرضی‌اند و فقط هزینهٔ توکن را با نرخ استاندارد و زمینهٔ کوتاه نشان می‌دهند. هزینهٔ ابزار، نوشتن کش، پردازش منطقه‌ای، درخواست تکراری و زمان بازبینی انسان در آن‌ها نیست. مقصود، پیش‌بینی قبض یک پروژه نیست؛ هر مثال نشان می‌دهد حجم اجرا چگونه اختلاف قیمت یک پاسخ را بزرگ می‌کند.

• گفت‌وگوی کوتاه: اگر هر نوبت ۱٬۰۰۰ توکن ورودی تازه و ۵۰۰ توکن خروجی داشته باشد، هزینهٔ Luna حدود ۰٫۰۰۰۳۵ دلار و هزینهٔ Sol حدود ۰٫۰۰۷ دلار است. برای ۱۰۰٬۰۰۰ نوبت هم‌اندازه، جمع به‌ترتیب ۳۵ و ۷۰۰ دلار می‌شود. در چنین کاری، حتی اگر تفاوت کیفیت هر پاسخ کوچک به نظر برسد، تکرار زیاد آن را به تصمیمی بودجه‌ای تبدیل می‌کند.
• بازبینی مخزن: با فرض ۵۰٬۰۰۰ توکن ورودی تازه از کد و ۳٬۰۰۰ توکن خروجی، یک بازبینی با Luna حدود ۰٫۰۰۶۵ دلار و با Sol حدود ۰٫۱۳ دلار هزینهٔ توکنی دارد. برای ۱٬۰۰۰ بازبینی مشابه، رقم‌ها به ۶٫۵ و ۱۳۰ دلار می‌رسند. این مقایسه فقط وقتی به انتخاب مدل کمک می‌کند که وصله‌ها با معیار یکسانی از نظر درستی، پوشش آزمون و زمان اصلاح سنجیده شوند.
• حلقهٔ عامل با ورودی کش‌شده: اگر هر فراخوانی شامل ۲۰۰٬۰۰۰ توکن ورودی واقعاً کش‌شده، ۲۰٬۰۰۰ توکن ورودی تازه و ۱۰٬۰۰۰ توکن خروجی باشد، هزینهٔ آن برای Luna حدود ۰٫۰۰۹ دلار و برای Sol حدود ۰٫۱۸ دلار است. در ۱٬۰۰۰ فراخوانی، این دو بودجه به ۹ و ۱۸۰ دلار می‌رسند. اگر بخشی از ورودی به‌جای خواندن از کش دوباره نوشته یا پردازش شود، هزینهٔ واقعی تغییر می‌کند.

در این مثال‌ها نسبت هزینه ثابت می‌ماند، زیرا نرخ ورودی تازه، ورودی کش‌شده و خروجی Sol هرکدام همان نسبت را با Luna دارند. بااین‌حال، مبلغ نهایی یک گردش‌کار الزاماً چنین نسبتی ندارد: مدل‌ها ممکن است برای رسیدن به پاسخ پذیرفتنی تعداد گام‌ها یا مقدار خروجی متفاوتی مصرف کنند. در مثال گفت‌وگو، هزینهٔ ۵۰۰ توکن خروجی از هزینهٔ ۱٬۰۰۰ توکن ورودی تازه بیشتر است؛ برآوردی که فقط اندازهٔ پرسش را حساب کند، همین بخش را از قلم می‌اندازد.

برتری کدنویسی Sol چه اندازه قابل اتکاست؟

در مقایسهٔ BenchLM، امتیاز ردهٔ کدنویسی Sol برابر ۶۲٫۵ و Luna برابر ۵۱٫۱ است؛ هر مدل در این رده یک ردیف عمومی با شواهد پشتیبانی‌شده دارد، اما بازه‌های اطمینان ۹۰ درصدی هم‌پوشانی دارند. Sol در این اندازه‌گیری جلوتر است، ولی فاصلهٔ مشاهده‌شده اندازهٔ قطعی برتری آن در هر مخزن یا تنظیم اجرا نیست.

برای کار کدنویسی، واحد مفید مقایسه «وصلهٔ پذیرفته‌شده» است، نه صرفاً یک پاسخ. اصلاح چند فایل وابسته، رعایت محدودیت‌های معماری و گذراندن آزمون‌ها ممکن است تعداد تلاش‌ها را تغییر دهد؛ یک پاسخ ظاهراً خوب نیز می‌تواند بازبینی طولانی بخواهد. اگر Sol در نمونه‌های واقعی یک تیم خطا یا رفت‌وبرگشت را کاهش دهد، ارزش این صرفه‌جویی باید کنار هزینهٔ توکن قرار گیرد. امتیاز عمومی به‌تنهایی چنین صرفه‌جویی‌ای را اندازه نمی‌گیرد.

در کار عامل‌محور، هزینهٔ هر گام کافی نیست

مشخصات GPT-6 Sol آن را برای کدنویسی پیچیده و گردش‌کار عامل‌محور معرفی می‌کند و پشتیبانی از ابزارهای Responses API مانند جست‌وجوی وب، پوستهٔ میزبانی‌شده و apply patch را فهرست می‌کند. همان مشخصات، پنجرهٔ زمینهٔ ۱٬۰۵۰٬۰۰۰ توکنی و سقف خروجی ۱۲۸٬۰۰۰ توکنی را نیز ثبت می‌کند.

دسترسی به ابزار، موفقیت در انجام یک کار چندمرحله‌ای را تضمین نمی‌کند. برای نمونه، یک عامل ممکن است خطا را پیدا کند، آزمون اجرا کند، وصله بسازد و پس از شکست آزمون دوباره تلاش کند؛ هر فراخوانی تازه به هزینه اضافه می‌شود. شواهد عمومی عامل‌محور برای این دو مدل نیز هم‌پایه نیست: ردیف Luna بر برآورد تکیه دارد و ردیف Sol شواهد پشتیبانی‌شدهٔ بیشتری دارد، بنابراین از اختلاف امتیاز آن رده نمی‌توان برندهٔ قطعی استخراج کرد. معیار اقتصادی، هزینهٔ مجموع گام‌ها تا رسیدن به نتیجهٔ قابل‌قبول است.

اگر کار شکست‌خورده به بازبینی انسانی پرهزینه یا چندین دور اصلاح منجر شود، قیمت بالاتر یک فراخوانی ممکن است در کل گردش‌کار جبران شود. برعکس، وقتی هر دو مدل وظیفه‌ای محدود و قابل‌اعتبارسنجی را با تعداد گام مشابه انجام می‌دهند، نرخ پایین‌تر Luna اثر مستقیم‌تری بر بودجه دارد. برای همین، کاربرد عامل‌محور به‌تنهایی دلیل کافی برای فرستادن همهٔ درخواست‌ها به Sol نیست.

پنجرهٔ زمینهٔ برابر چه تغییری در انتخاب می‌دهد؟

مشخصات GPT-6 Luna نیز پنجرهٔ زمینهٔ ۱٬۰۵۰٬۰۰۰ توکنی و سقف خروجی ۱۲۸٬۰۰۰ توکنی را ثبت می‌کند؛ همچنین ابزارهای Responses API از جمله جست‌وجو، پوستهٔ میزبانی‌شده و apply patch را در فهرست پشتیبانی‌شده‌ها دارد. بنابراین ظرفیت اعلام‌شدهٔ پنجره و دسترسی به این ابزارها، به‌خودی‌خود مزیت Sol برای وارد کردن مخزن بزرگ‌تر نیست.

ظرفیت پنجره را باید از قیمت استفاده از آن جدا کرد. برای هر دو مدل، وقتی ورودی یک درخواست از ۲۷۲٬۰۰۰ توکن بگذرد، نرخ ورودی و کش برای کل درخواست دو برابر و نرخ خروجی یک‌ونیم برابر می‌شود. پس بودجه‌های نمونهٔ بالا را نمی‌توان بدون تغییر به درخواستی بسیار بلند تعمیم داد. فرستادن همهٔ فایل‌های یک مخزن فقط به این دلیل که در پنجره جا می‌شوند، ممکن است هم هزینه را بالا ببرد و هم اطلاعات نامرتبط وارد کار کند.

ماتریس انتخاب بر پایهٔ کیفیت لازم و تعداد فراخوانی

انتخاب عملی به دو محور بستگی دارد: نتیجه باید چه اندازه دقیق باشد و همان کار چند بار تکرار می‌شود؟ خانه‌های زیر قاعدهٔ تصمیم‌اند، نه تضمینی دربارهٔ خروجی مدل‌ها.

• کیفیت لازم معمولی، فراخوانی زیاد: Luna مبنای اقتصادی مناسب‌تری است. برای گفت‌وگوی کوتاه، استخراج داده یا تبدیل قالب با خروجی قابل‌اعتبارسنجی، اختلاف کوچک هر نوبت در مقیاس بالا جمع می‌شود.
• کیفیت لازم معمولی، فراخوانی کم: Luna همچنان انتخاب ساده‌ای است، اما مبلغ API ممکن است در برابر زمان بررسی دستی ناچیز باشد. اگر هر پاسخ به قضاوت انسانی نیاز دارد، هزینهٔ آن بررسی را نیز کنار قیمت مدل بگذارید.
• کیفیت لازم بالا، فراخوانی کم: Sol برای وظایف دشوارتر گزینهٔ قابل‌آزمایش است. در یک بازبینی پیچیده، کاهش خطای وصله یا زمان اصلاح می‌تواند از اختلاف قیمت یک درخواست مهم‌تر باشد.
• کیفیت لازم بالا، فراخوانی زیاد: تفکیک کار معمولاً از انتخاب یک مدل برای همهٔ درخواست‌ها دقیق‌تر است. وظایف روشن و قابل‌اعتبارسنجی می‌توانند از Luna آغاز شوند و موارد دشوار یا ناموفق به Sol برسند؛ آستانهٔ ارجاع به نرخ خطای مشاهده‌شده و هزینهٔ اصلاح بستگی دارد.

یک قاعدهٔ حسابداری مرز تصمیم را روشن می‌کند: با ترکیب توکن و تعداد تلاش یکسان، یک فراخوانی Sol به‌اندازهٔ ۲۰ فراخوانی Luna هزینهٔ توکنی دارد. اگر Sol توکن کمتر مصرف کند یا تلاش‌های ناموفق و بازبینی را کاهش دهد، این نسبت در سطح کار کامل عوض می‌شود. برای انتخاب نهایی، مجموع هزینهٔ فراخوانی، ابزار و اصلاح را بر تعداد کارهایی تقسیم کنید که واقعاً معیار پذیرش شما را گذرانده‌اند.