GPT-Image-2.6 مقابل GPT-Image-2.5: التبديل مجرد سلسلة واحدة، لكن الفاتورة ليست كذلك

إنّ الانتقال من GPT-Image-2.5 إلى GPT-Image-2.6 هو، على مستوى واجهة برمجة التطبيقات، أقلّ ترقية إثارةً أطلقتها OpenAI طوال العام. نفس نقطتي النهاية، ونفس بطاقة الأسعار، ونفس الانقسام بين Flare وSunburst. يتغيّر نصّ اسم الطراز ولا يلزم تغيير أي شيء آخر. وهنا يكمن الفخّ أيضًا. يضيف GPT-Image-2.6 معاملًا واحدًا لم يكن لدى GPT-Image-2.5 قطّ — قرص ضبط التعقيد — وتركُه خارج الطلب لا يعني إيقاف تشغيله. فهو يُضبط افتراضيًا على «مرتفع». إنّ أي خطّ معالجة يبدّل النصّ ويُطلقه إلى التشغيل لا يشتري القدر نفسه من العمل مقابل المبلغ نفسه من المال؛ بل يشتري عملًا أكثر، ولهذا قد يتغيّر أول تقرير تكاليف بعد الترحيل رغم أنّ الأسعار المنشورة لم تتغيّر.

أصبح كلا الطرازين متاحين للاستخدام العام وفق الشروط التجارية نفسها، وهذا ما يجعل هذه المقارنة غير معتادة. لا توجد حجة حول التسعير يمكن طرحها. تدور الحجة بالكامل حول أين تُوجّه الأعمال الجديدة، وما إذا كانت حركة المرور لديك مهيأة بحيث تستفيد منها.

سطح API هو حقًا بديل مباشر — مع ثغرة واحدة فيه

أطلقت OpenAI نموذج GPT-Image-2.6 في 4 نوفمبر 2026 في صورة نموذجَي API بدلًا من نموذج واحد، موروثةً البنية التي أرسّتها مع الإصدار 2.5. الفئة الموجَّهة نحو التفاصيل والاتساق هي GPT-Image-2.6 Sunburst؛ أما فئة السرعة فهي GPT-Image-2.6 Flare. ويحتفظ سابقاهما، GPT-Image-2.5 Sunburst وGPT-Image-2.5 Flare، بالاسمين نفسيهما وبالعلاقة نفسها بينهما.

• سلاسل النماذج — gpt-image-2.6-flare وgpt-image-2.6-sunburst تحلّ محل gpt-image-2.5-flare وgpt-image-2.5-sunburst، بالمنطق نفسه للتسمية، واحد لزمن الاستجابة وآخر للتفاصيل.

• نقاط النهاية — /v1/images/generations و/v1/images/edits، دون تغيير. لا توجد نقطة نهاية جديدة يلزم دمجها.

• الأسعار — 5 دولارات لكل مليون رمز إدخال نصي، و8 دولارات لكل مليون رمز إدخال صور، و30 دولارًا لكل مليون رمز إخراج صور، مع إدخال مخزّن مؤقتًا بسعر 1.25 دولار و2.00 دولار. مطابق تمامًا بايتًا ببايت لـ 2.5.

• مستويات الجودة — منخفض، متوسط، مرتفع، xhigh، أقصى، وتلقائي. نفس السلّم.

• الأحجام الموصى بها — لا تزال 1024×1024 و1536×1024 و1024×1536 تتصدر الوثائق، مع قبول أبعاد مخصصة من مضاعفات 16 ونسب أبعاد من 1:3 إلى 3:1.

• الثغرة — الإصدار 2.6 غير متاح عبر Batch API. وإذا كانت وظيفتك الليلية بنصف السعر هي أساس إنفاقك على الصور، فإن تلك الوظيفة لن تتحرك بعد.

السطر الأخير هو ما يعطّل شيئًا فعليًا. كل ما فوقه مجرد استبدال نصي وتشغيل اختبار انحدار. أما فجوة المعالجة الدُفعية فهي عائق معماري تحديدًا لأحمال العمل — الكتالوجات الضخمة، وعمليات التعبئة الليلية، وتوليد A/B على نطاق واسع — حيث يكون خصم 50% هو السبب في وجود حمل العمل أصلاً.

قرص التعقيد هو الميزة الحقيقية، والمفاجأة تكمن في إعداده الافتراضي.

التعقيد محور جديد يقف إلى جانب الجودة لا داخلها، والفرق بينهما أهم مما يبدو. الجودة تتحكم في التنفيذ: كم من رموز الإخراج تُستهلك في الصورة. أما التعقيد فيتحكم في التخطيط: كم من الاستدلال يجريه النموذج قبل أن يبدأ التنفيذ. يمكنك أن تطلب صورة منخفضة الجودة لمشهد معقد، أو صورة عالية الجودة لمشهد بسيط، وفي 2.6 يكون هذان طلبين منفصلين حقًا.

يوضح التوثيق صراحةً أن حذف المعامل يضبط قيمته الافتراضية على high. لذا فإن المستدعي الذي ينقل طلب 2.5 بتغيير اسم الطراز فقط دون أي شيء آخر يكون بصمت قد اختار الحد الأقصى لميزانية التخطيط في كل استدعاء. هذا ليس خطأً — إنه الافتراضي المعقول لطراز تتمثل ميزته البيعية في التفكير أكثر — لكنه يعني أن الشهر الأول من حركة طلبات 2.6 ليس مقارنة مثل بمثل مع الشهر الأخير من حركة طلبات 2.5.

هناك نقطة بيانات عامة واحدة على الأقل تشير في الاتجاه نفسه. فقد أفاد اختبار عملي بثلاث صور نُشر في 4 نوفمبر بتكلفة 0.1245 دولار مقابل مخرجات 2.6، في مقابل 0.0446 دولار لنفس الصور الثابتة على 2.5 — أي نحو ثلاثة أضعاف، وفق قائمة أسعار لم تتغير. ثلاث صور ليست معيارًا قياسيًا ولا ينبغي الاقتباس منها على هذا الأساس؛ فالعينة أصغر بكثير من أن تثبت مُضاعِفًا. لكن ما تفعله هو أنها تُظهر الآلية، والآلية موثّقة: مزيد من رموز التخطيط لكل طلب، مفعّلة افتراضيًا، وتُحتسب بسعر 30 دولارًا لكل مليون.

إذا كنت ستتخذ خطوة تشغيلية واحدة من هذا المقال، فاتخذ هذه. اضبط التعقيد صراحةً — وmedium تخمين أولي معقول لمطابقة سلوك حقبة 2.5 — ثم قِس رموز الإخراج لكل طلب قبل وبعد. لا تقِس الدولارات لكل طلب. ستخبرك الدولارات لكل طلب أن بطاقة الأسعار لم تتغير، وهو ما كنت تعرفه بالفعل. ستخبرك الرموز لكل طلب ما إذا كان النموذج يقوم بعمل أكثر مما طلبته.

أين يقع فعليًا التسريع المزعوم بنسبة 50%

تصف OpenAI نموذج GPT-Image-2.6 بأنه أسرع بنحو 50% إجمالًا، لكن الأرقام الخاصة بكل فئة أكثر إثارة للاهتمام بكثير من العنوان الرئيسي، وهي أرقام المورّد نفسه وليست قياسات مستقلة. ويُذكر أن Flare أسرع بنحو 2.6× من سابقه، إذ تكتمل عمليات العرض منخفضة الجودة في غضون ست ثوانٍ فقط. أما Sunburst فيُذكر أنه يبلغ نحو 1.15×.

هذان الرقمان يصفان ترقيتين مختلفتين تمامًا. إذا كانت خطوط معالجتك تشغّل Flare من أجل التكرار — استكشاف الصور المصغّرة، وضبط المطالبات (prompts)، وأي مهمة ينتظر فيها إنسان النتيجة — فإن 2.6 يمثّل نقلة نوعية، والهجرة تدفع تكلفتها من حيث الانتباه وحده. أما إذا كانت خطوط معالجتك تشغّل Sunburst من أجل جودة المخرجات النهائية، فإن تحسينًا في زمن الاستجابة بنسبة 15% يقع ضمن نطاق التباين الطبيعي بين التشغيلات في معظم إعدادات الاستضافة، والسرعة ليست سببًا للهجرة على الإطلاق.

يجدر التنبيه بصراحة: الاختبار العملي الصغير نفسه الذي أبلغ عن تضخّم الرموز أبلغ أيضًا عن أن 2.6 أبطأ من 2.5 في صوره الثلاث، وهو ما يتعارض مع ادعاء المورّد. ومع n=3، فهذا ضجيج وليس دحضًا. لكنه تذكير بأن «أسرع بنسبة 50%» رقم إجمالي في عرض الإطلاق عبر مستويات الجودة، بينما خط المعالجة الحقيقي يرى مستوى واحدًا عند إعداد جودة واحد.

لم يسجل أحد 2.6 بعد، ولا يزال 2.5 في المركز الأول.

هذا هو الجزء من المقارنة الذي تتجاهله معظم التغطية. لم يكن لدى Artificial Analysis، وهي تشغّل لوحاتها AA-Image-T2I v2.1 ولوحات التحرير، أي صف على الإطلاق لـ GPT-Image-2.6 عند الاطلاع عليها في 5 نوفمبر 2026. ليست درجة منخفضة — بل لا يوجد صف.

ما تُظهره تلك اللوحات بالفعل هو أن النموذج الذي يجري استبداله ما زال يفوز بها:

• تحويل النص إلى صورة — GPT-Image-2.5 Sunburst (max) بـ 1,224 نقطة إيلو من 13,153 صوتًا، في المركز الأول. GPT-Image-2.5 Flare (max) بـ 1,207 من 12,498، في المركز الثاني. GPT Image 2 (high) بـ 1,188، في المركز الثالث.

• تحرير الصور — GPT-Image-2.5 Sunburst (max) 1,200 من أصل 18,370 صوتًا، في المركز الأول. GPT-Image-2.5 Flare (max) 1,183 من أصل 19,259، في المركز الثالث خلف MAI-Image-2.7-Preview عند 1,197.

تشير مواد إطلاق OpenAI إلى Design Arena لاحتلال 2.6 Sunburst المركز الأول. هذا ادعاء حقيقي على لوحة حقيقية، لكنه يمثل مجموعة مُقيّمين مختلفة على مقياس مختلف، واختيار البائع اللوحةَ التي تُجمّل إصداره ليس دليلاً يمكن للمشتري أن يستفيد منه. أما الرقم المماثل القائم على تصويت طرف ثالث الخاص بـ2.6 فغير موجود بعد. وإلى أن يوجد، فإن الموقف القابل للدفاع عنه هو أن 2.5 هو أعلى نموذج صور مُقيَّم باستقلالية على كلتا اللوحتين الرئيسيتين، وأن 2.6 غير مُثبت — أفضل بالطرق المحددة التي تقول OpenAI إنه أفضل بها، وغير مقيس في كل ما عداها.

ترحيل يمكن إنجازه في عصر واحد

إن التبديل رخيص بما يكفي بحيث يكون النهج المعقول ليس ترحيلًا شاملًا دفعة واحدة، بل ترحيلًا مدروسًا، يُنفَّذ على مطالباتك الخاصة بدلًا من مجموعة مطالبات معيارية تابعة لأي جهة.

ابدأ بتثبيت التعقيد على قيمة اخترتها أنت، بحيث يكون التغيير تغييرًا أجريته أنت لا تغييرًا جاء افتراضيًا. ثم أعد تشغيل بضع مئات من المطالبات الحقيقية من سجلات الإنتاج لديك — لا المطالبات النظيفة في بيئات الاختبار، بل الفوضوية التي فيها أخطاء إملائية ونسب أبعاد غير ملائمة. قارن رقمين: رموز الإخراج لكل صورة مقبولة، والصور المقبولة لكل مئة محاولة. الثاني هو الذي سيظهر فيه تحسّن الاتساق، وهو الرقم الذي يحدد فعليًا ما إذا كانت الترقية توفر المال، لأن الصورة التي ترميها تستهلك ميزانية الرموز كاملة ولا تعود بشيء.

احتفظ بمسار احتياطي إلى 2.5 لأعمال الدفعات، لأن 2.6 لا يمكنه خدمتها بعد. وتعامل مع أي حركة Sunburst كمسألة جودة لا كمسألة سرعة — فإذا لم يتغير معدل القبول، فأنت قد اشتريت تحسينًا في زمن الاستجابة بنسبة 15% وفاتورة تخطيط أكبر.

متى يكون البقاء على 2.5 هو الإجابة الصحيحة

ثلاث حالات واضحة بما يكفي لتسميتها. ينبغي أن تبقى أحمال عمل الدفعات، لأن 2.6 ليس على Batch API بينما 2.5 عليه. وينبغي أن تبقى خطوط أنابيب جودة Sunburst ما لم يقل اختبار معدل القبول غير ذلك، لأن تسريعًا بمقدار 1.15× لا يبرر تغيير نموذج التكلفة. وأي شخص معدل قبوله الحالي مقبول بالفعل ينبغي أن يبقى، لأن القدرات الجديدة — تصدير SVG، وGIF متحرك، والتحرير الموجّه بالترميز — هي ميزات إضافية، وليست تحسينات جودة، وأنت تحتاجها فقط إذا كان لديك مُخرَج يتطلبها.

الترقية حقيقية. غير أنها مركّزة فقط في زمن استجابة Flare وفي صيغ إخراج جديدة، وهذه أضيق مما يوحي به «نموذج جديد».

التوافر، والشكل المحرج للترحيل المنقسم

يوفّر OrcaRouter GPT-Image-2.5 Flare وGPT-Image-2.5 Sunburst اليوم بسعر القائمة دون أي هامش ربح (0%)، أي أن سعر المزوّد هو ذاته السعر الذي تدفعه من دون أي هامش يُضاف فوقه. أما GPT-Image-2.6 فليس مدرجًا في الكتالوج حتى 5 نوفمبر 2026 — أي بعد يوم من إطلاقه — ما يجعل المشكلة العملية المباشرة مشكلة توجيه لا مشكلة نمذجة: فخلال الاختبار المقارن، تسير حركة 2.5 عبر مفتاح واحد مع تحويل تلقائي عند الفشل، بينما تذهب حركة 2.6 مباشرة إلى OpenAI بموجب عقد ثانٍ وفاتورة ثانية.

هذا الانقسام يستحق التخطيط له بدلًا من اكتشافه. راجع الكتالوج قبل أن تخصّص مسارًا إنتاجيًا للإصدار 2.6، لأن التكافؤ يوم الإطلاق ليس شيئًا يمكن لأي موجّه أن يَعِد به على نموذج عمره أربع وعشرون ساعة. وعندما يصل الأمر، فإن قاعدة التمرير المباشر تعني أن سعر المورّد هو ما تدفعه في اليوم نفسه — أي أن تغييرًا في السعر من جانب OpenAI سيصل دون إعادة تفاوض من جانبنا — لكن حتى ذلك الحين، فالقراءة الصادقة للموقف هي أن 2.5 قابل للتوجيه و2.6 ليس كذلك.

وهذا حجة أخرى لصالح الترحيل الذي يستغرق فترة بعد الظهر بدلًا من ذاك الذي يستغرق عطلة نهاية الأسبوع. شغّل 2.5 عبر الموجّه، وأبقِ خط أساس التكلفة لديك مستقرًا، وأضف 2.6 خلف علم ميزة بعد أن تقيس ما يفعله إعداد التعقيد الافتراضي بأعداد الرموز لديك. النموذج لن يختفي، وستصل نقطة نهاية الدُفعات قبل أن تحين دورة التخطيط الربعية التالية لديك.