نماذج OpenAI قادمة إلى Google Cloud: ما الذي ينبغي لفرق المؤسسات اختباره قبل الانتقال؟

تجلب OpenAI نماذجها المتقدمة وسير عمل Codex إلى Model Garden في Google Cloud. ويحمل الإعلان أهمية استراتيجية، لكن الخبر العملي أضيق نطاقًا: إذ سيتمكن بعض عملاء Google Cloud من بدء تقييم نماذج OpenAI ضمن بيئة قائمة أصلًا لشراء الخدمات السحابية وإدارة الهويات والحوكمة. ومن المقرر طرح الإتاحة العامة خلال الأسابيع المقبلة، بينما يبدأ الإطلاق الأولي على هيئة معاينة خاصة.

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

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

ما الذي أُعلن فعليًا

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

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

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

وتظل Microsoft الشريك السحابي الرئيسي لـOpenAI. لذلك ينبغي قراءة الترتيب مع Google باعتباره توسعًا في التوزيع، لا استبدالًا لـAzure أو إعلانًا عن تخلي OpenAI عن علاقاتها السحابية القائمة.

لماذا تغيّر قرار الشراء

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

هناك أربعة آثار عملية.

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

ثانيًا، قد يصبح من الأسهل تركيز إدارة الهويات والوصول في مكان واحد. وتقول Google Cloud إن أحمال OpenAI ستستخدم عناصر التحكم في الوصول، والهويات الموثقة، وسجلات التدقيق، ووسائل الحماية التي توفرها VPC Service Controls. ويمكن أن تساعد هذه الضوابط المؤسسة في الإجابة عن أسئلة تشغيلية أساسية: أي خدمة استدعت النموذج؟ وأي هوية سمحت بذلك؟ وأي مشروع دفع التكلفة؟ وأي سياسة طُبقت على الطلب؟

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

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

المعاينة الخاصة هي أول إشارة تحذير

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

ينبغي للفرق التي تقيّم المعاينة تسجيل ظروف كل اختبار:

• معرّف النموذج وإصداره بدقة؛
• منطقة Google Cloud أو نقطة النهاية المستخدمة؛
• ما إذا كانت الطلبات قد مرّت عبر خدمة إقليمية أو عالمية؛
• حدود الرموز، وحجم السياق، وإعدادات المخرجات؛
• سلوك استدعاء الأدوات وقواعد انتهاء المهلة؛
• سلوك الأمان أو تصفية المحتوى؛
• إعدادات التسجيل والاحتفاظ بالبيانات والوصول إليها؛
• مصدر السعر ووحدة الفوترة المستخدمة في الاختبار.

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

ما الذي ينبغي اختباره قبل نقل العمل الحقيقي؟

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

1. اختبر نتيجة العمل، لا نثر النموذج

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

قِس النتيجة باستخدام مجموعة تقييم ثابتة. واحتفظ بمجموعة منفصلة من الأمثلة غير المرئية لتقليل احتمال أن يؤدي ضبط المطالبة إلى الإفراط في ملاءمة حالات الاختبار. أدرج الطلبات الصعبة والعادية؛ فالنموذج الذي يؤدي جيدًا في الحالات الطرفية فقط ليس بالضرورة الخيار الأفضل للإنتاج.

2. قارن التكلفة الكاملة للمهمة

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

احسب تكلفة كل مهمة أعمال مكتملة، لا تكلفة كل مليون رمز فقط. مثلًا:

تكلفة كل مهمة مكتملة =
  استخدام النموذج
  + استدعاءات الاسترجاع والأدوات
  + التنسيق والبنية التحتية
  + إعادة المحاولات والمحاولات الفاشلة
  + المراجعة البشرية

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

3. قِس زمن الاستجابة باعتباره توزيعًا

لا تكتفِ بالإبلاغ عن متوسط زمن الاستجابة. تتبّع زمن الاستجابة الوسيط، وp95، وp99 لسير العمل الكامل. وافصل الوقت الذي يُقضى في انتظار النموذج عن الوقت المستغرق في الاسترجاع، وتنفيذ الأدوات، وفحوص السياسات، وعرض الاستجابة.

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

4. اختبر سلوك النظام عند الفشل والتعافي

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

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

5. تحقّق من حدود البيانات بالأدلة

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

اطلب إجابات مكتوبة عن أسئلة من قبيل:

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

عبارة «داخل سحابتنا» ليست وصفًا كافيًا للخصوصية. فقد يمر الطلب عبر عدة خدمات مُدارة، ولكل منها سلوكها الخاص في التسجيل والاحتفاظ ووصول المسؤولين. اعتبر وثائق المزوّد والعقد المرجع الحاسم لنشر الخدمة الذي ستستخدمه فعليًا.

لا تكون فائدة اختيار النموذج حقيقية إلا إذا كان التطبيق قادرًا على تحمّلها

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

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

لا تفترض أن الطلب المتوافق مع OpenAI قابل للنقل سلوكيًا. فقد يختلف المزوّدون في طريقة تعاملهم مع تعليمات النظام، ومخططات JSON، وأحداث البث، ومعاملات الأدوات، وعدّ الرموز، واستجابات الرفض، والسياق المخزن مؤقتًا، ومرشحات السلامة. قد تجعل طبقة توافق رقيقة عملية الدمج الأولى سريعة، لكنها قد تخفي اختلافات مهمة. يجب اختبار قابلية النقل على مستوى المهام المكتملة ومعالجة حالات الفشل.

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

ما الذي ينبغي لعملاء Google Cloud السؤال عنه بشأن التكلفة؟

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

أنشئ مقارنة تشمل ثلاثة سيناريوهات على الأقل:

1. المزوّد الحالي والبنية الحالية؛
2. نماذج OpenAI التي تُشترى عبر Google Cloud؛
3. مزوّد ثانٍ أو نموذج مفتوح يعمل عبر المنصة نفسها.

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

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

من ينبغي له التجربة الآن

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

• فريق منصة يقارن بين OpenAI وGemini وClaude والنماذج المفتوحة على عبء العمل المؤسسي نفسه؛
• مؤسسة خاضعة للتنظيم تحتاج إلى ضوابط مركزية للهوية والتدقيق وحدود البيانات؛
• فريق أدوات للمطورين يختبر سير عمل Codex بالقرب من المستودعات وأنظمة البناء وأدوات الرصد الحالية؛
• فريق مالي أو للمشتريات يريد معرفة ما إذا كانت التزامات السحابة قادرة على دعم برنامج متعدد النماذج؛
• فريق معماري يصمم موجّهًا للنماذج ومستعدًا للحفاظ على اختبارات خاصة بكل مزود.

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

من ينبغي له الانتظار

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

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

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

التحول الأكبر: السحب تتحول إلى موزعين للنماذج

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

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

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

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