Google تضيف إلى Gemini API وضعي Flex وPriority لتحقيق التوازن بين السعر والموثوقية

في 2 أبريل 2026 أضافت Google إلى Gemini API وضعين جديدين للخدمة هما Flex وPriority، ليتمكن المطورون من التحكم بدقة أكبر في السعر وزمن الاستجابة والموثوقية دون تعقيد البنية المعمارية. والفكرة أن الطلبات الخلفية وطلبات المستخدمين الحرجة يمكن الآن توزيعها على مستويات خدمة مختلفة عبر الواجهة المتزامنة نفسها، بدلًا من بناء مسارين منفصلين لـ Standard API وBatch API.

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

كان تحقيق هذا الفصل في السابق يستلزم غالبًا الجمع بين الطلبات المتزامنة العادية من جانب المنتج وBatch API للمعالجة الخلفية الرخيصة. وقد وفّر ذلك في التكلفة، لكنه أضاف أعباء تشغيلية: إدارة المهام غير المتزامنة، وملفات الإدخال والإخراج، والاستعلام الدوري عن حالة التنفيذ. وتقول Google إن Flex وPriority يسدّان هذه الفجوة: فكلا الخيارين يعملان عبر نقاط النهاية المتزامنة القياسية، ويتم التبديل بينهما بواسطة المعامل service_tier في الطلب.

Flex وضع اقتصادي جديد للمهام التي تتحمل التأخير والأولوية الأدنى في التنفيذ. وتَعِد Google بتوفير يصل إلى 50% مقارنة بـ Standard API، إذا كان المطوّر مستعدًا للتضحية بجزء من الموثوقية وسرعة الاستجابة مقابل التكلفة. والنقطة الجوهرية أن Flex لا يحوّل العمل إلى عملية batch منفصلة: فهو ما زال طلبًا متزامنًا بمخطط التكامل المعتاد. وتقترح الشركة استخدام هذا الوضع في تحديثات CRM الخلفية، وفي المحاكاة البحثية واسعة النطاق، وفي سيناريوهات الوكلاء التي قد «يفكّر» فيها النموذج أو «يتصفح» المعلومات في الخلفية. ووفق بيانات Google، سيكون Flex متاحًا في جميع الباقات المدفوعة، ومدعومًا في طلبات GenerateContent وInteractions API.

أما Priority فمصمَّم، على العكس، لأكثر أنواع الحركة حساسية. وهو وضع مميز بأعلى مستوى من الضمانات، ويُفترض أن يساعد التطبيقات على اجتياز ذروات الحمل دون إزاحة الطلبات الحرجة. وتقول Google صراحةً إن هذه الطلبات تحصل على أعلى مستوى من الأهمية، ما يعني فرصة أكبر للحفاظ على استقرار العمل حتى عندما تكون المنصة محمّلة. وثمة تفصيل مهم آخر هو آلية التخفيض السلس: فإذا تجاوز التطبيق حدود Priority، فإن الطلبات الزائدة لا تفشل بخطأ، بل تُخدَّم تلقائيًا ضمن Standard. وقد يكون هذا أهم في بيئة الإنتاج من اتفاقية مستوى الخدمة (SLA) نفسها، لأنه يقلل خطر التدهور الكامل للوظيفة في لحظة تدفق المستخدمين.

وفي الوقت نفسه تجعل Google وضع Priority أكثر شفافية من حيث التشغيل والفوترة. فسيُذكر في استجابة API أي مستوى عالج الطلب تحديدًا، وبذلك تستطيع الفرق تحليل سلوك النظام، وحساب التكلفة، وتتبع سيناريوهات التدهور الفعلية. ومن الحالات النموذجية التي تذكرها الشركة روبوتات الدعم الفوري، ومسارات الإشراف المباشر على المحتوى، وأي طلبات حساسة للوقت. وعند الإطلاق سيكون Priority متاحًا للمشاريع المدفوعة من المستويين Tier 2 وTier 3 في GenerateContent API وInteractions API.

لا تقتصر أهمية هذا التحديث للمطورين على الأسعار. فGoogle تحاول عمليًا تبسيط الخيار الهندسي بين «الرخيص» و«الموثوق»، دون إجبار فرق المنتج على بناء نموذجي تكامل مختلفين. وإذا حقق Flex فعلًا التوفير الموعود البالغ 50% للأحمال الخلفية دون الانتقال إلى بنية batch، فقد يخفض ذلك كلفة سيناريوهات الوكلاء وخطوط المعالجة واسعة النطاق. أما إذا حافظ Priority باستمرار على الحركة الحرجة في أوقات الذروة، فسيحصل Gemini API على حجة أقوى لدى المنتجات الموجهة للمستخدمين، حيث تضرب الأعطال الإيرادات وتجربة المستخدم مباشرة.

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