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

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

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

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

Flex هو وضع اقتصادي جديد للمهام التي يمكنها تحمل الكمون وأولوية تنفيذ أقل. يعد جوجل بتوفيرات تصل إلى 50 في المئة مقارنة بـ Standard API إذا كان المطور مستعداً للتضحية بجزء من الموثوقية وسرعة الاستجابة من أجل التكلفة. النقطة الرئيسية هي أن Flex لا يحول العمل إلى عملية batch منفصلة: لا تزال طلباً متزامناً مع نمط تكامل مألوف.

تقترح الشركة استخدام هذا الوضع لتحديثات CRM الخلفية والمحاكاة البحثية على نطاق واسع والسيناريوهات المتعلقة بالوكلاء حيث يمكن للنموذج "التفكير" أو "مراجعة" المعلومات في الخلفية. وفقاً لجوجل، سيكون Flex متاحاً على جميع الخطط المدفوعة ويدعم في طلبات GenerateContent و Interactions API. Priority، على النقيض من ذلك، مصمم لحركة المرور الأكثر حساسية.

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

للإنتاج، قد يكون هذا أكثر أهمية من SLA نفسه، لأنه يقلل من خطر التدهور الكامل للوظيفة أثناء ارتفاع المستخدمين. في نفس الوقت، يجعل جوجل وضع Priority أكثر شفافية من حيث العمليات والفواتير. ستشير استجابة API إلى مستوى المعالجة الدقيق الذي تعامل مع الطلب المحدد، بحيث يمكن للفريق تحليل سلوك النظام وحساب التكاليف وتتبع سيناريوهات التدهور الفعلية.

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

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

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