إيقاف Gemini 2.5: قائمة تحقق قبل إعادة توجيه الطلبات تلقائيًا في 1 ديسمبر

يدخل إيقاف Gemini 2.5 حيز التنفيذ في 1 ديسمبر 2026. في ذلك التاريخ، تبدأ الاستدعاءات الموجهة إلى gemini-2.5-pro وgemini-2.5-flash بالانتقال تلقائيًا إلى نماذج مختلفة. ستظل معظم الطلبات ناجحة، وهذا بالتحديد ما يستدعي الفحص الآن.

يتناول هذا الدليل ما أعلنته Google، والأثر في الفاتورة، والمعاملات التي تحتاج إلى إعادة كتابة، وكيفية التقرير لكل حمل عمل على حدة بين قبول إعادة التوجيه أو تثبيت نموذج عن قصد. إذا كنت تشغّل Gemini على Vertex AI، فاقرأ ذلك القسم أولًا، فتاريخ الإيقاف النهائي هناك قد مضى بالفعل.

ما أعلنته Google وما الذي يتغير فعليًا في 1 ديسمبر

تذكر ملاحظات إصدار Gemini API من Google، المنشورة في 2 نوفمبر 2026، أن الاستدعاءات الموجهة إلى gemini-2.5-pro ستنتقل تلقائيًا إلى gemini-3.8-flash، وأن الاستدعاءات الموجهة إلى gemini-2.5-flash ستنتقل إلى gemini-3.5-flash-lite. وتحدد ملاحظات الإصدار 1 ديسمبر 2026 موعدًا لبدء إعادة التوجيه. فمن ذلك التاريخ، سيتولى الرد على أي طلب API يذكر أيًا من هذين النموذجين نموذج آخر أحدث، وسيُحتسب الطلب بأسعار ذلك النموذج.

النطاق أضيق مما يوحي به العنوان. إذ تذكر صفحة إيقاف نماذج Gemini أن gemini-2.5-flash-lite غير موقوف ويظل متاحًا حتى إشعار آخر. ولا يتأثر سوى معرّفَي نموذجين.

المشكلة العملية أن الأمر لا ينتج عنه خطأ في الغالب. وقد يمر رد نموذج مختلف بصمت دون أن يلاحظه أحد.

لماذا تُعد إعادة التوجيه الصامتة أخطر من الخطأ

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

أثار القائمون على مكتبة llm-exe مفتوحة المصدر هذه المسألة في بلاغ على GitHub: تظل الاستدعاءات ناجحة، لكن مستخدمي gemini-2.5-pro يحصلون على نموذج من فئة Flash دون أي تحذير. ويصفون ذلك بأنه تراجع حقيقي في القدرات، ويقولون إنه "أسوأ من خطأ 404 لأن أحدًا لن يلاحظه".

تركت Google بعض الأسئلة مفتوحة. فإشعارها لا يوضح سبب ربط 2.5 Pro بنموذج Flash بدلًا من فئة أعلى، ولا يذكر ما إذا كان بإمكان العملاء إلغاء الاشتراك في إعادة التوجيه التلقائية.

نقترح التعامل مع هذا التحول على أنه تغيير في النموذج لم يختره فريقك، ومراجعته كما تُراجع أي ترقية مخطط لها، بجولة تقييم وفحص للتكلفة وموافقة من المسؤول.

صورة التكلفة: أرخص في ديسمبر ومختلفة اعتبارًا من يناير 2027

يذكر منشور Google لإطلاق Gemini 3.8 Flash سعرًا تمهيديًا قدره $0.75 لكل 1M من رموز الإدخال و$3.75 لكل 1M من رموز الإخراج حتى 31 ديسمبر 2026. أما Gemini 2.5 Pro فتكلفته $1.25 و$10.00 للمطالبات التي لا تتجاوز 200,000 رمز. واعتبارًا من 1 يناير 2027، تتضاعف أسعار 3.8 Flash لتصل إلى $1.50 و$7.50. وعند هذه الأسعار يصبح الإدخال أغلى مما كان عليه في 2.5 Pro، بينما يظل الإخراج أرخص.

حملا عمل توضيحيان

يستعرض تحليل من جهة خارجية نشرته Data Studios حملَي عمل على سبيل المثال. وهما ليسا اختبارَي أداء معياريين وليسا من قياسات Optijara.

في مثال مساعد الدعم، تنخفض الفاتورة الشهرية من $9,300 إلى $4,500 في ديسمبر، ثم تعود لترتفع إلى $9,000 اعتبارًا من يناير 2027. وترد أحجام الرموز التي تستند إليها هذه الإجماليات في تحليل Data Studios، لذا تحقق منها هناك قبل المقارنة بحركة بياناتك.

أما صف المستندات الطويلة فيذكر افتراضاته، ولذلك يمكنك إعادة حسابه من جدول الأسعار. تبلغ التكلفة $810 على 2.5 Pro لأن كل مطالبة تقع ضمن شريحة السياق الطويل الأعلى سعرًا. وعلى 3.8 Flash تبلغ $240 في ديسمبر و$480 اعتبارًا من يناير، لأن 3.8 Flash لا يفرض رسومًا إضافية على السياق الطويل.

عدد الرموز أهم من سعر الرمز

يذكر منشور الإطلاق من Google أن 3.8 Flash قد يستهلك رموزًا أكثر لتعظيم الأداء، خاصة عند مستويات الجهد الأعلى. وقد يلتهم الحجم الأكبر جزءًا من انخفاض سعر الرمز أو كله. قِس أعداد الرموز الفعلية على حركة بياناتك قبل الوثوق بأي جدول حسابات، بما في ذلك الأمثلة أعلاه.

تغييرات المعاملات التي تعطل السلوك أو تغيره بصمت

حلول thinking_level محل thinking_budget

تستخدم نماذج Gemini 3.x المعامل thinking_level بدلًا من thinking_budget. ويقبل Gemini 3.8 Flash المستويات low وmedium وhigh، وتذكر وثائق نموذج 3.8 Flash من Google أن المستوى minimal يُرجع خطأ. تأكد من الصياغة الحالية في سجل تغييرات Gemini API وفي صفحة النموذج.

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

معاملات أخذ العينات في طريقها إلى الزوال

توجّه إرشادات الترحيل من Google المطورين إلى إزالة temperature وtop_p وtop_k. فهذه المعاملات معلن إيقافها، وهي مُتجاهَلة اليوم، وستُرجع HTTP 400 في الأجيال القادمة. أزل candidate_count أيضًا، إذ لا يدعمه Gemini 3 وما بعده. راجع سجل تغييرات Gemini API وصفحة الإيقاف قبل المساس بالشيفرة.

هذه ليست مسألة تخص إعادة التوجيه وحدها. إذ تؤكد وثائق Gemini API من Google أن معاملات أخذ العينات هذه تُتجاهل في Gemini 3.6 Flash وGemini 3.5 Flash-Lite وGemini 3.5 Flash Cyber. فإذا كنت تستدعي هذه النماذج، فقد يكون بعض إعداداتك بلا أثر بالفعل. وأي سير عمل اعتمد على درجة حرارة منخفضة للحصول على مخرجات متسقة قد فقد هذا التحكم، لذا اختبر الاتساق مباشرة.

المسار من 2.5 Flash إلى 3.5 Flash-Lite

نقترح الفصل بين ما هو موثق في هذا المسار وما لا يزال على فريقك اختباره أو البحث عنه.

• معروف: حدود الإخراج. يملك Gemini 3.5 Flash-Lite، بديل 2.5 Flash، نافذة سياق بسعة 1M رمز ويدعم حتى 64,000 رمز إخراج. تحقق من توافق إعدادات الحد الأقصى للإخراج ومنطق التقسيم لديك.
• معروف: معاملات أخذ العينات. مُتجاهَلة بالفعل في 3.5 Flash-Lite، كما ذُكر أعلاه.
• للاختبار: مستويات التفكير. نقترح اختبار كل قيمة من قيم thinking_level تخطط لإرسالها، بما في ذلك minimal.
• للبحث: التكلفة. نقترح تسعير هذا المسار بناءً على الأسعار المنشورة الحالية من Google.

استدعاء الأدوات والدوال

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

دليل العمل: قائمة تحقق من سبع خطوات لترحيل Gemini 2.5

نقترح تعيين مسؤول وتاريخ مستهدف لكل خطوة قبل موعد التحول.

• [ ] الخطوة 1، الجرد. ابحث في الشيفرة والإعدادات ومتغيرات البيئة وقوالب البنية التحتية ومغلِّفات SDK عن gemini-2.5-pro وgemini-2.5-flash، بما في ذلك القيم الافتراضية داخل المكتبات الخارجية وأطر عمل الوكلاء. واستثنِ gemini-2.5-flash-lite.
• [ ] الخطوة 2، التصنيف. صنّف كل استدعاء بحسب المخاطر التجارية (موجّه للعملاء، كثيف الاستدلال، يستدعي الأدوات، دفعي، طويل السياق) وعيّن له مسؤولًا.
• [ ] الخطوة 3، إعادة كتابة المعاملات. استبدل thinking_budget بالمعامل thinking_level (low أو medium أو high، دون minimal على 3.8 Flash). اختبر كل مستوى على 3.5 Flash-Lite. وأزل temperature وtop_p وtop_k وcandidate_count.
• [ ] الخطوة 4، إعادة الاختبار. شغّل مجموعة تقييم ثابتة وتدفقات استدعاء الأدوات لديك على النموذج المستهدف، مع مقارنة الجودة وزمن الاستجابة واستهلاك الرموز بخط أساس من النموذج الحالي.
• [ ] الخطوة 5، نموذج التكلفة. سعّر استهلاك الرموز المقيس لكل مسار.
• [ ] أحمال عمل 2.5 Pro: بأسعار 3.8 Flash لشهر ديسمبر 2026، ثم بأسعار يناير 2027.
• [ ] أحمال عمل Flash السابقة: نقترح تسعيرها بناءً على الأسعار المنشورة الحالية من Google للنموذج المستهدف.
• [ ] الخطوة 6، القرار. ثبّت كل حمل عمل على معرّف نموذج صريح، أو دوّن أنك تقبل هدف إعادة التوجيه.
• [ ] الخطوة 7، المراقبة بعد 1 ديسمبر. سجّل معرّف النموذج المطلوب وأي بيانات وصفية عن النموذج أو إصداره يُرجعها الرد، وأطلق تنبيهًا عند اختلافهما. فالمعرّف المطلوب وحده لن يكشف إعادة التوجيه. تابع الرموز والإنفاق، وراقب التخزين المؤقت، إذ لم توثق Google سلوك الردود أو ذاكرات التخزين المؤقت في ظل إعادة التوجيه.

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

التثبيت عن قصد أو قبول إعادة التوجيه: مراجعة المؤشرات الثلاثة

نسمي إطار العمل الذي نستخدمه لهذا القرار مراجعة المؤشرات الثلاثة (Three-Dial Review). امنح كل حمل عمل درجة منخفضة أو متوسطة أو مرتفعة على كل مؤشر.

• المخاطر. من يرى المخرجات، وماذا يحدث إذا كانت خاطئة؟ تحصل الإجابات الموجهة للعملاء والمحتوى الخاضع للتنظيم واستدعاءات الأدوات التي تغيّر البيانات على درجة مرتفعة.
• الاعتماد على الاستدلال. هل اخترت 2.5 Pro من أجل الاستدلال متعدد الخطوات، أم أنه أصبح الخيار الافتراضي فحسب؟
• الحساسية للتكلفة. ما حصة حمل العمل هذا من إنفاقك على Gemini، وما سرعة نموها؟

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

يذكر منشور الإطلاق من Google أيضًا أنه حيثما كانت كفاءة الحوسبة هي القيد الرئيسي، يمكن للمطورين استخدام مستويات جهد أقل أو مواصلة استخدام Gemini 3.7 Flash، الذي يظل مدعومًا بالكامل لأحمال العمل التي تضع الكفاءة أولًا. وإذا كانت الكفاءة هي قيدك الرئيسي، فنقترح إدراج هذا النموذج في تقييمك كخيار للتثبيت.

تعلن Google عن درجة 54.9% لنموذج 3.8 Flash في HLE-Verified. هذا سياق مصدره المورد، وليس دليلًا على ملاءمة النموذج لمهمتك. ونقترح أن تجعل مجموعة التقييم الخاصة بك هي الفيصل، ويقدم مقالنا عن سبب حاجة درجات الاختبارات المعيارية إلى بروتوكولات قراءة إضافية حول كيفية وزن الأرقام البارزة.

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

Vertex AI: تاريخ الإيقاف النهائي قد مضى بالفعل

يُدرج جدول دورة الحياة في Vertex تاريخ 20 أكتوبر 2026 موعدًا للإيقاف النهائي لكل من gemini-2.5-pro وgemini-2.5-flash. وقد مضى ذلك التاريخ. وقد تكون استدعاءات Vertex AI التي لا تزال تذكر أيًا من النموذجين فاشلة بالفعل أو يخدمها نموذج آخر، لذا افحص سجلات هذا الأسبوع ومعدلات الأخطاء لهذين المعرّفين قبل الانتقال إلى Developer API.

توثّق Vertex AI دورات حياة النماذج بصورة منفصلة عن Gemini Developer API. وتذكر Google أنها عند جدولة إيقاف نموذج هناك، تنشر تاريخًا محددًا يمنحك ما لا يقل عن 45 يومًا للترحيل. وتختلف البدائل المقترحة أيضًا: gemini-3.8-flash أو gemini-3.5-flash بديلًا لنموذج Pro، وgemini-3.8-flash أو gemini-3.5-flash-lite بديلًا لنموذج Flash. ولا يذكر إشعار إعادة التوجيه من Google كيف ينطبق تغيير 1 ديسمبر على Vertex AI. وإذا كنت تستخدم الواجهتين، فافحص كلًا منهما وفق شروطها الخاصة.

الأخطاء الشائعة التي تقع فيها الفرق في هذا الترحيل

• التقاط خط الأساس بعد فوات الأوان. بعد 1 ديسمبر، لن يصل استدعاء Gemini API الموجه إلى gemini-2.5-pro إلى 2.5 Pro.
• إغفال القيم الافتراضية في CI وبيانات الاختبار الثابتة. نقترح فحص بيانات الاختبار الثابتة والمحاكيات واختبارات الدخان وإعدادات بيئة التجهيز بحثًا عن معرّفات نماذج مكتوبة مباشرة في الشيفرة.
• ترك ذاكرات التخزين المؤقت والتقييمات مرتبطة بالمعرّفات القديمة. قد تجد الفرق أن كل ما يعتمد على سلسلة اسم النموذج مفتاحًا يخلط النتائج القديمة والمعاد توجيهها تحت تسمية واحدة. أعد بناء المفاتيح، أو ضع علامة على تاريخ التحول.
• ضبط تنبيهات الميزانية خلال ديسمبر. ستقلل الحدود المضبوطة على إنفاق ديسمبر من تقدير إنفاق يناير، حين تتضاعف أسعار 3.8 Flash.
• ترحيل الاستدعاءات الخطأ أو إغفال المخفية منها. النموذج gemini-2.5-flash-lite غير موقوف، وقد تختبئ المعرّفات المتأثرة داخل مغلِّفات خارجية لن يصل إليها البحث في مستودعك.

تحفظات وأسئلة مفتوحة

لم تذكر Google ما إذا كانت الردود ستُظهر أن الطلب المعاد توجيهه قد خدمه النموذج البديل. كما لم تذكر ما سيحدث لذاكرات السياق المؤقتة الصريحة المنشأة على نماذج Gemini 2.5، ولا يوجد خيار معلن لإلغاء الاشتراك.

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

إذا كنت ترى أن رأيًا ثانيًا سيفيدك، فبإمكان Optijara إجراء تدقيق ترحيل لاستدعاءات Gemini لديك أو المساعدة في بناء خط الأساس للتقييم الذي ستقارن به.