أخبار

نماذج OpenAI تصل إلى Google Cloud ضمن معاينة خاصة

تفتح Google Cloud وصولا خاصا إلى 3 نماذج OpenAI، مع فوترة عبر Marketplace وربط Codex. ومن المخطط طرح الإتاحة العامة وعدة قدرات أمنية لاحقا.

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

أعلنت OpenAI وGoogle Cloud في 21 أكتوبر 2026 انضمام نماذج OpenAI إلى Model Garden في Google Cloud. وتقول Google إن GPT-6 Astra وGPT-6.1 Sol وGPT-6 Luna تدخل مرحلة معاينة خاصة لعملاء مختارين من المؤسسات. وتخطط OpenAI للإتاحة العامة خلال الأسابيع المقبلة، لذلك لا يعني الإعلان وصولا فوريا لكل عميل سحابي.

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

3 نماذج لأدوار مختلفة

تقدم Google نموذج GPT-6 Astra للمهام الصعبة في البرمجة واستخدام الحاسوب والعمل المهني والعلوم. وتصف GPT-6.1 Sol بأنه خيار أقل تكلفة يقترب من قدرات Astra في عمل الوكلاء، بينما يستهدف GPT-6 Luna المهام اليومية السريعة والمنخفضة التكلفة. هذه أوصاف تقدمها الشركة، وليست نتائج اختبار مقارن مشترك جديد نُشر مع الإعلان.

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

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

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

الفوترة عبر Google Cloud Marketplace

تقول الشركتان إن المشتريات ستتم عبر Google Cloud Marketplace، وإن الاستخدام سيظهر في فاتورة Google Cloud. ويمكن للمؤسسات تطبيق التزامات الإنفاق السحابي الحالية على هذه المشتريات. وتضيف Google أن الاستخدام يُحتسب ضمن Flexible Savings Plans عبر موردي النماذج، وفقا لخطة الحساب والشروط المعنية.

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

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

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

ضوابط البيانات وما لم يصل بعد

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

يقول الإعلان إن كل تفاعل مع وكيل أو نموذج يجري بهوية مصادق عليها، مع حماية VPC Service Controls. والهدف تمكين المسؤولين من معرفة من يصل إلى المعلومات وتتبع النشاط. لكن وجود ضوابط وصول لا يغني عن إعداد الصلاحيات بصورة صحيحة، وخصوصا تحديد مصادر المعلومات التي يمكن للوكيل الوصول إليها.

هناك قدرتان أمنيتان موصوفتان صراحة بأنهما قادمتان: خيارات Zero Data Retention وConfidential Compute. تتعلق الأولى بسياسات عدم الاحتفاظ بالبيانات، بينما تحمي الثانية معالجة المعلومات داخل بيئة معزولة. ولا ينبغي عرضهما كميزتين متاحتين بالفعل لكل مشارك في المعاينة، أو كحماية تشمل تلقائيا كل حمل عمل.

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

ربط Codex الآن وتكاملات إضافية لاحقا

تقول Google إن العملاء المؤهلين يستطيعون استخدام واجهات API وربط مسارات العمل المحلية في Codex CLI وتطبيق سطح المكتب بمنصة Gemini لإجراء الاستدلال. وهذا ربط بين بيئة عمل وخدمة حوسبة. ولا يعلن انتقال كل منتجات Codex إلى Google، ولا حصول جميع المستخدمين تلقائيا على وصول جديد دون إعداد.

تصف الشركتان أيضا تكاملا مستقبليا مع Google Antigravity وأدوات Gemini للمؤسسات. وتشير OpenAI إلى Gemini Agent، بينما تستخدم Google اسم Gemini for business. ولا يقدم أي من الإعلانين جدولا زمنيا مفصلا لكل واجهة، لذلك يجب التمييز بين الوصول الخاص الذي يبدأ الآن والتكاملات اللاحقة.

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

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