⚡ أبرز النقاط

أطلقت AWS نسخ M9g وM9gd المدعومة بـ Graviton5 في 10 يونيو 2026، مع 192 نواة Arm وذاكرة DDR5 وكاش L3 أكبر بخمس مرات وتحسّن في أداء الحوسبة بنسبة 25% مقارنةً بـ Graviton4 — مع مكاسب محددة بـ 35% للويب واستنتاج التعلم الآلي و30% لقواعد البيانات. تكلّف النسخ المبنية على Graviton بالفعل ما يصل إلى 20% أقل من نسخ EC2 المعادلة x86 مع استهلاك أقل للطاقة بنسبة تصل إلى 60%. وتأتي Meta وSnowflake وUber من بين أوائل المتبنين الملتزمين.

الخلاصة: يجب على قادة الهندسة تصنيف مخزون EC2 لديهم الآن — يمكن لمعظم أحمال العمل المعبّأة في حاويات الانتقال إلى Graviton5 في أيام واستيعاب ميزة التكلفة 20% وكفاءة الطاقة 60% فوراً.

اقرأ التحليل الكامل ↓

🧭 رادار القرار

الأهمية بالنسبة للجزائر
متوسط
▾
تتسارع اعتماد السحابة في الجزائر عبر قطاعات البنوك والاتصالات والجهات الحكومية، لكن معظم النشرات تستخدم حالياً خدمات سحابية مُدارة بدلاً من اختيار نسخ EC2 مباشرةً. مع انتقال المؤسسات الجزائرية من البنية التحتية المحلية إلى السحابة، ستُصبح اختيارات عائلات النسخ أكثر أهمية — وميزة التكلفة البالغة 20% لـ Graviton5 ذات صلة مباشرة بالنشرات الحساسة للتكاليف.
البنية التحتية جاهزة؟
جزئي
▾
لا تُشغّل AWS بعد منطقة مركز بيانات في الجزائر أو شمال أفريقيا. تصل المؤسسات الجزائرية إلى نسخ AWS M9g عبر مناطق باريس أو فرانكفورت أو البحرين، مما يضيف زمن انتظار. حتى وجود منطقة AWS محلية، تظل الفائدة الكاملة في الأداء من Graviton5 لأحمال العمل الجزائرية الحساسة للزمن مقيّدة بالمسافة الشبكية لا بقدرات النسخة.
المهارات متوفرة؟
جزئي
▾
مهارات هندسة السحابة المتوافقة مع Arm موجودة في مجتمع المطوّرين الجزائري المتنامي، وبصفة خاصة بين المهندسين الذين عملوا مع أكوام مبنية على الحاويات. تتطلب هجرة Graviton إعادة تجميع أحمال العمل لـ aarch64 — وهذا موثّق ومُجهَّز بالأدوات، لكنه يتطلب وقت مطوّر وانضباطاً في الاختبار. الفرق الهندسية الجزائرية التي تبني على الخدمات المُدارة (Lambda وRDS والحاويات) تواجه هذه الطبقة الانتقالية بدرجة أقل من تلك التي تدير أساطيل EC2 المباشرة.
الجدول الزمني للعمل
12-24 شهراً
▾
للمؤسسات الجزائرية التي تُقيّم حالياً استراتيجيات بنية تحتية تعتمد السحابة أولاً، يجب أن تكون نسخ M9g ضمن مجموعة التقييم. لتلك التي تُشغّل بالفعل أحمال عمل AWS، يستحق مراجعة الهجرة الجدولة في دورة التخطيط القادمة. مكاسب التكلفة وكفاءة الطاقة حقيقية ودائمة.
أصحاب المصلحة الرئيسيون
المدراء التقنيون، مهندسو السحابة، مدراء تقنية المعلومات، فرق DevOps للمؤسسات
نوع القرار
استراتيجي
▾
يمثّل هذا قراراً طويل الأمد في البنية التحتية بشأن محاذاة منصة الشرائح — لا مجرد تبديل نسخة، بل تحوّل في أهداف البناء الافتراضية ومنطق الشراء لجميع أحمال العمل السحابية المستقبلية.

خلاصة سريعة: يجب على مهندسي السحابة الجزائريين الذين يُقيّمون نشرات AWS إضافة M9g إلى قائمة النسخ المختارة الآن، لا سيما للتطبيقات المعبّأة في حاويات وخطوط استنتاج التعلم الآلي. تخفيض التكلفة بنسبة 20% وتحسّن كفاءة الطاقة بنسبة 60% مزايا دائمة تتضاعف مع نمو البصمة السحابية — وأدوات الهجرة نحو Arm ناضجة بما يكفي لتمكين معظم أحمال العمل الحديثة من إجراء التحوّل في سبرينت واحد.

إعلان

ما أعلنته AWS في 10 يونيو

أتاحت AWS معالج Graviton5 للعموم في 10 يونيو 2026، وربطته بعائلتَي نسخ: M9g لأحمال العمل ذات الأغراض العامة، وM9gd للتوزيعات كثيفة التخزين. كان الإعلان متوقعاً منذ مؤتمر AWS re:Invent في ديسمبر 2025، غير أن التوفر العام يحوّل شريحة خريطة الطريق إلى قرار شراء فعلي.

الرقم الرئيسي هو 192 نواة Arm لكل شريحة — أعلى عدد نوى في تاريخ سلسلة Graviton. لكن العدد وحده لا يروي القصة كاملة. وفقاً لتغطية SiliconAngle للإطلاق، يأتي Graviton5 بدعم ذاكرة DDR5 وتكامل PCIe، وهما أوّلان في عائلة Graviton. كاش L3 أكبر بخمس مرات من Graviton4، وكل نواة تصل إلى 2.6 ضعف من كاش L3 — تحسّن هيكلي يقلّل زمن انتظار الوصول إلى الذاكرة لأحمال العمل المتوازية التي تُعرّف البنى السحابية الحديثة.

تُفيد AWS بأن التحسّن الإجمالي في أداء الحوسبة يبلغ 25% مقارنةً بـ Graviton4. وعند التعمق في أنواع أحمال العمل، تتوسع الأرقام: أسرع بـ 35% في تطبيقات الويب واستنتاج نماذج التعلم الآلي، وأسرع بـ 30% في قواعد البيانات. تُضيف نسخة M9gd وحدة تخزين NVMe محلية — تصل إلى 11.4 تيرابايت من SSD لكل نسخة — مع عمليات إدخال/إخراج أسرع بـ 30% في الثانية مقارنةً بالجيل السابق. تتحسّن سرعة نقل الشبكة بنسبة 15% إجمالاً، وتصل نسخ M9g الكبيرة إلى ضعف سرعة نقل Amazon EBS مقارنةً بنظيراتها من Graviton4.

يستخدم أكثر من 120,000 عميل من عملاء AWS أجيالاً سابقة من Graviton، وفقاً لـ صفحة منتج AWS Graviton الرسمية. هذه القاعدة المنشأة لا تنتقل تلقائياً إلى Graviton5، لكنها تشير إلى مدى تغلغل النسخ المبنية على Arm في أحمال عمل المؤسسات التي كانت ستختار x86 تاريخياً.

حرب الشرائح المخصصة ولماذا تتصاعد في 2026

لم يظهر Graviton5 في عزلة. فهو أحدث خطوة في حملة متعددة السنوات من قِبَل مزودي الخدمات السحابية الكبار لإزاحة الشرائح التجارية من مراكز بياناتهم. المنطق الاستراتيجي بسيط: امتلاك خريطة طريق المعالج يتيح لمزود السحابة التحسين لأحمال عمله الخاصة، والانفصال عن دورات إصدار Intel وAMD، واستيعاب الهامش الذي كان يذهب سابقاً لبائعي الشرائح.

بدأت AWS هذا النهج عام 2018 بـ Graviton1. وسّع كل جيل ميزة الأداء وتغطية حالات الاستخدام. فتح Graviton4 طبقة قواعد البيانات. يُعدّ Graviton5 موجَّهاً صراحةً للذكاء الاصطناعي الوكيل — أحمال العمل التي تتطلب حوسبة CPU مستمرة وعالية الإنتاجية على نطاق واسع، بما يشمل الاستدلال الفوري، وتوليد الأكواد، وتنسيق المهام متعددة الخطوات. عدد 192 نواة ليس عشوائياً؛ فهو مُعاير لنماذج التزامن التي تولّدها عوامل الذكاء الاصطناعي عند تشغيل خيوط استدلال متعددة في وقت واحد.

تتبع Google مساراً موازياً مع Axion، معالجها المبني على Arm لمراكز البيانات. تطوّر Microsoft معالج Cobalt 100. النمط الآن هيكلي: كل مزود سحابة كبير يبني أو يستحوذ على شرائح مخصصة. ما يعنيه ذلك للمؤسسات هو أنه بحلول عام 2027، لن تكون نسخة x86 هي الاختيار الافتراضي على أي سحابة رئيسية — ستكون اختياراً متعمداً لأحمال العمل ذات التبعيات ISA المحددة أو قيود الترخيص البرمجي.

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

إعلان

ما يكشفه ثلاثة من أوائل المتبنين عن نماذج التوزيع

التزمت Meta وSnowflake وUber علناً بنشر نسخ Graviton5، كما أفادت Guru3D في تغطيتها لإطلاق Graviton5. قراءة ملامح استخدامهم تكشف ثلاثة نماذج توزيع ستُعرّف الاعتماد المبكر.

يتوافق اهتمام Meta مع الاستنتاج على نطاق واسع. استنتاج نماذج اللغة الكبيرة هو حمل عمل يجمع بين CPU والمسرّعات، حيث يتولى CPU عمليات الترميز والجدولة وخطوات المعالجة السابقة/اللاحقة المحيطة بحسابات GPU. شريحة بـ 192 نواة مع كاش L3 أكبر بـ 2.6 مرة لكل نواة تعني أن كل CPU يستطيع التعامل مع جلسات استنتاج متزامنة أكثر بكثير قبل التشبع — مما يقلّل مباشرةً عدد نسخ GPU المطلوبة.

يُشير نشر Snowflake إلى أحمال عمل قواعد البيانات والتحليلات. تحسّن أداء قواعد البيانات بنسبة 30% ومضاعفة سرعة نقل EBS على النسخ الكبيرة يعالجان القيد الهيكلي المحوري لـ Snowflake: نقل مجموعات البيانات الكبيرة بين التخزين والحوسبة وقت الاستعلام. إدخال/إخراج أسرع يعني زمن استجابة أقل للاستعلامات بالتكلفة ذاتها، أو الزمن ذاته بتكلفة أقل.

يُشير اعتماد Uber إلى الخدمات المصغّرة الموزعة واتخاذ القرار الفوري — مطابقة الرحلات، والتسعير الديناميكي، وكشف الاحتيال. هذه بالضبط هي أحمال العمل التي يستهدفها تحسّن سرعة نقل الشبكة بـ 15% وانخفاض زمن الانتظار بين النوى. لشركة تشغّل آلاف الخدمات المصغّرة عبر ملايين الطلبات المتزامنة، يتضاعف تحسّن الحوسبة بنسبة 25% عبر الأسطول بأكمله.

ما يجب على قادة الهندسة التقنية فعله حيال Graviton5

1. مراجعة مخزون نسخ x86 لتحديد المرشحين لهجرة Graviton

الخطوة الأولى ليست تجريباً — إنها تمرين تصنيف. قسّم مخزون EC2 إلى ثلاث مجموعات: (أ) أحمال العمل التي لا تعتمد على ISA مع أنظمة بيئية (runtimes) في حاويات — هذه تُهاجر بإعادة تجميع وتغيير إعداد؛ (ب) أحمال العمل مع تراخيص برامج تجارية تقيّد نشر Arm — هذه تتطلب تفاوضاً مع البائع قبل الهجرة؛ (ج) أحمال العمل المرتبطة بـ x86 بسبب كود أصيل قديم أو تجميع مدمج — هذه تحتاج مساراً أطول للمعالجة.

تُفيد AWS بأن أكثر من 120,000 عميل أكملوا هجرات Graviton بالفعل، وكثير منهم أنهوها في ساعات. نضجت الأدوات بشكل كبير منذ Graviton1. لأحمال العمل في المجموعة (أ) التي تعمل على حاويات أو بيئات تشغيل حديثة مُفسَّرة (Python، Node.js، JVM، Go)، مسار الهجرة موثّق والمخاطر منخفضة. أولِّ هذه أولاً — إنها أسرع مسار لاستيعاب تخفيض التكلفة بـ 20% وتحسّن كفاءة الطاقة بـ 60%.

2. قياس الأداء مقابل ملف حمل العمل الفعلي لديك، لا ادعاءات AWS الإجمالية

تحسّن الحوسبة البالغ 25% هو متوسط عبر فئات أحمال العمل. ستختلف نتائجك بشكل كبير. تطبيقات الويب وأحمال استنتاج التعلم الآلي ترى 35% تحسناً؛ قواعد البيانات ترى 30%. الحوسبة الدفعية وترميز الفيديو والمحاكاة العلمية ستمتلك ملفاتها الخاصة. قبل الالتزام بعائلات نسخ على نطاق واسع، شغّل حمل عمل الإنتاج الفعلي — أو إعادة تشغيل تمثيلية — على نسخ M9g بالتوازي مع نوع نسختك الحالي.

توفر AWS مستوى تجريبياً مجانياً (t4g.small، 750 ساعة/شهر حتى ديسمبر 2026) للتقييم الأولي. لقياسات الأداء على نطاق الإنتاج، شغّل اختباراً موازياً لأسبوعين: وجّه نسبة من حركة المرور إلى نسخ M9g وقارن نسب الأثر في الزمن الاستجابي والإنتاجية ومعدلات الخطأ مقابل خطك الأساسي. استخدم التكلفة لكل معاملة كمقياس رئيسي — وليس الإنتاجية الخام التي تحسّن المتغير الخطأ.

3. دمج NVMe المحلي لـ M9gd في مراجعة بنية التخزين لديك

نسخة M9gd مع ما يصل إلى 11.4 تيرابايت من SSD NVMe المحلي ليست مجرد ترقية تخزين — إنها تغيّر الحسابات المعمارية للوصول إلى البيانات الحساسة للزمن. التطبيقات التي تسحب حالياً البيانات الساخنة من EBS أو ElastiCache بسبب ارتفاع زمن انتظار EBS قد تتمكن من التوحيد على نسخ M9gd مع NVMe المحلي، مما يزيل طبقة من تعقيد البنية التحتية.

المقايضة هي تقلبية مخزن النسخة: لا يستمر NVMe المحلي عبر إيقاف النسخة. النمط الذي ينجح هو استخدام مخزن النسخة للبيانات الساخنة المؤقتة (ذاكرات التخزين المؤقت، منازل الكتابة، مجموعات العمل) مع المزامنة إلى EBS المتين أو S3 عند نقاط التحقق. إذا كان تطبيقك يتعامل بالفعل مع فشل النودات بشكل سليم — أقسام Kafka، ونسخ Redis، وتكرار Cassandra — يتناسب NVMe المحلي لـ M9gd بشكل طبيعي. إذا كان تطبيقك يفترض ديمومة التخزين عبر إعادة التشغيل، تضيف M9gd عملاً معمارياً قد لا يستحق مكسب الزمن لحالة استخدامك.

4. إعادة تقييم افتراضات ميزانية البنية التحتية للذكاء الاصطناعي الوكيل لديك

صُمِّم Graviton5 صراحةً لنماذج التزامن الخاصة بالذكاء الاصطناعي الوكيل. إذا كانت خطة البنية التحتية للذكاء الاصطناعي لعام 2026 لديك تتضمن أطر تنسيق متعددة العوامل — سواء LangChain، أو LlamaIndex، أو واجهة برمجة استخدام الأدوات من Anthropic، أو تنسيق خاص — فإن افتراضات تحجيم CPU الخاصة بك ربما وُضعت قبل توفر Graviton5. نسخة بـ 192 نواة مع أداء استنتاج تعلم آلي أفضل بـ 35% تغيّر نسبة نسخ CPU إلى GPU التي تحتاجها في مجموعة تقديم العوامل.

تحديداً: خطوات المعالجة السابقة واللاحقة حول استنتاج GPU (تنسيق المطالبات، وعدّ الرموز، وإدارة السياق، وتحليل المخرجات) مقيّدة بـ CPU. على نسخة من حقبة Graviton4، كانت هذه الخطوات قد تُشكّل عنق زجاجة لـ GPU سريع. على Graviton5، تنتهي الخطوات ذاتها بشكل أسرع ومع تزامن أكثر، مما يعني تحسّن استخدام GPU لديك — تحصل على إنتاجية استنتاج أكبر من نفس الاستثمار في المسرّعات.

الصورة الأكبر: ما يعنيه الشريح المخصص لاقتصاديات السحابة حتى 2028

إطلاق Graviton5 ليس مجرد إعلان منتج منفرد. إنه نقطة بيانات في تحوّل هيكلي سيتكشّف حتى نهاية العقد.

مسار الشرائح المخصصة للمزودين الكبار راسخ الآن: AWS (Graviton، Trainium، Inferentia)، وGoogle (Axion، TPU)، وMicrosoft (Cobalt، Maia). في كل دورة، تكسب هذه الشرائح أرضاً على الشرائح التجارية لمجموعة أوسع من أحمال العمل. النقطة التي يكون فيها حمل العمل المُشغَّل على شرائح مخصصة دائماً أرخص من نفس حمل العمل على Intel أو AMD — في غياب الارتباط بـ ISA — تقترب. للحوسبة العامة، تجادل AWS بأن هذه النقطة تجاوزها بالفعل بادعاء ميزة التكلفة البالغة 20%.

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

تابعوا AlgeriaTech على LinkedIn للتحليلات التقنية المهنية تابعوا على LinkedIn
تابعونا @AlgeriaTechNews على X للحصول على أحدث تحليلات التكنولوجيا تابعنا على X

إعلان

الأسئلة الشائعة

ما الفرق بين نسخ AWS Graviton5 M9g وM9gd؟

نسخ M9g هي نسخ حوسبة للأغراض العامة مُحسَّنة لتطبيقات الويب وقواعد البيانات واستنتاج التعلم الآلي وأحمال العمل الموزعة. تُضيف نسخ M9gd تخزين SSD NVMe محلي — يصل إلى 11.4 تيرابايت لكل نسخة — مما يجعلها مناسبة للتطبيقات التي تتطلب الوصول بزمن انتظار منخفض إلى مجموعات بيانات مؤقتة كبيرة مثل ذاكرات التخزين المؤقت ومنازل الكتابة ومجموعات العمل التحليلية. كلاهما يستخدمان نفس شريحة Graviton5 ذات 192 نواة ويُقدّمان نفس تحسّن الأداء بنسبة 25% مقارنةً بـ Graviton4.

كيف يُقارن Graviton5 بأجيال AWS Graviton السابقة؟

يُقدّم Graviton5 أداء حوسبة إجمالياً أعلى بـ 25% من Graviton4، مع تحسينات محددة بـ 35% لتطبيقات الويب واستنتاج التعلم الآلي و30% لأحمال عمل قواعد البيانات. كاش L3 أكبر بخمس مرات من Graviton4، وكل نواة تصل إلى 2.6 ضعف من الكاش — مما يُقلّل زمن انتظار الذاكرة لأحمال العمل المتزامنة. يُقدّم Graviton5 أيضاً ذاكرة DDR5 وتكامل PCIe، وهما أوّلان في عائلة Graviton، إلى جانب سرعة نقل شبكة أعلى بـ 15% وما يصل إلى ضعف سرعة نقل EBS على النسخ الكبيرة.

هل يجب على المؤسسات هجرة أحمال عمل x86 إلى Graviton5 فوراً؟

ليس دفعة واحدة. النهج الصحيح هو تصنيف أحمال العمل إلى ثلاث مجموعات: أحمال العمل المعبّأة في حاويات أو ذات بيئات تشغيل حديثة بدون تبعيات ISA (هجرة سريعة — أياماً إلى أسابيع)، والبرامج التجارية مع قيود ترخيص Arm (تتطلب تفاوضاً مع البائع أولاً)، والكود الأصيل القديم لـ x86 (مسار معالجة أطول). تُفيد AWS بأن كثيراً من العملاء يُكملون هجرات Graviton في ساعات باستخدام الأدوات الحالية. لمعظم المنظمات، البدء بالمجموعة الأولى يستوعب غالبية وفورات التكاليف بحد أدنى من المخاطر، بينما تُؤجَّل المجموعة الثالثة حتى يُصدر موردو البرامج إصدارات Arm الأصيلة.

المصادر والقراءات الإضافية