تضيف Google طبقتي Flex وPriority إلى Gemini API مع انقسام أحمال عمل الذكاء الاصطناعي إلى مسارين

تعيد Google تشكيل Gemini API حول العمل الخلفي والعمل التفاعلي

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

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

ما الذي تفعله الطبقتان الجديدتان

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

أما Priority Inference فيتجه في الاتجاه الآخر. تقول Google إنه يوفر أعلى مستوى من الضمان بسعر أعلى، وموجهًا إلى التطبيقات التفاعلية الحرجة مثل روبوتات المحادثة والمساعدين البرمجيين، حيث تهم موثوقية الاستجابة أكثر من تقليل التكلفة.

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

لماذا يهم هذا المطورين

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

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

وبالفعل، يجري تعديل Gemini API ليتوافق مع واقع جديد للتطبيقات. بعض الطلبات جزء من المحادثة. وأخرى هي العمل غير المرئي الذي يهيئ أو يبحث أو يثري أو يقيم في الخلفية. واعتبار هذه المهام فئات خدمة أولية له ما يبرره عمليًا.

اقتصاديات الذكاء الاصطناعي الوكالي

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

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

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

سطح تحكم أوضح

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

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

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

هذه المقالة مبنية على تقرير من Google AI Blog. اقرأ المقال الأصلي.