Maia 300 يعد بكفاءة أعلى 40%، لكن عملاء Azure لن يحصلوا عليه بعد

|الكاتب: فريق تحرير QUASA|5 دقيقة للقراءة
Maia 300 يعد بكفاءة أعلى 40%، لكن عملاء Azure لن يحصلوا عليه بعد

في إعلان Microsoft يوم 12 أكتوبر 2026، كشفت الشركة عن نظام Azure Maia 300 وحددت بدء نشره الإنتاجي في 2027، مع توقع أن ينتج رموزاً أكثر بنسبة 40% لكل ميغاواط مقارنة بأنظمة رائدة تعتمد على معالجات الرسوميات. وتريد الشركة أن تصبح عائلة Maia منصة الاستدلال الأساسية لمنتجاتها وخدماتها. إنها خطة لتشغيل أعباء Microsoft، وليست إعلاناً عن مثيلات Maia 300 قابلة للاستئجار لعملاء Azure.

وفي تغطية Axios، قالت راني بوركار، المسؤولة عن أنظمة عتاد Azure وبنيتها التحتية في Microsoft، «We prioritize Maia for inference»، وأوضحت الصحيفة أن خطة جعله منصة الاستدلال الأساسية تخص خدمات Microsoft ولا تؤكد شمول عملاء Azure الخارجيين، بمن فيهم OpenAI. لم تعلن الشركة موعداً أو سعراً أو مناطق توافر لاستئجار المسرّع. وهكذا يختلف الموعد المقرر لتشغيل العتاد داخل Microsoft عن موعد طرحه، إن حدث، مورداً سحابياً يختاره العميل بنفسه.

ماذا تقيس زيادة الرموز لكل ميغاواط؟

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

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

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

لماذا تصمم Microsoft نظاماً بحجم الرف؟

يعتمد رفع سعة الاستدلال هنا على جمع المسرّعات والذاكرة والاتصال في نظام واحد. وتورد تغطية Data Center Dynamics أن تكوين الرف الكامل يضم 96 مسرّعاً ضمن حد قدرة يبلغ 167 كيلوواط، مع سعة ذاكرة عالية النطاق قدرها 27.6 تيرابايت؛ وتصل مقارنة Microsoft لإنتاج الرموز في هذا التكوين إلى سبعة أمثال رف Maia 200. المقارنة الأخيرة تخص إنتاج الرف، ولا تعني أن الشريحة المنفردة أسرع بالمقدار نفسه.

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

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

أي خدمات ستستفيد من Maia؟

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

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

متى يصبح Maia خياراً لعميل Azure؟

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

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

اقرأ أيضًا:

مشاركة:

اشترك في نشرتنا الإخبارية

احصل على أحدث أخبار الويب 3 والذكاء الاصطناعي والعملات المشفرة مباشرة في بريدك.

0