AWS تعرض مخططًا لتقاسم عنقود HyperPod EKS واحد بين عدة فرق

نشرت AWS بنية مرجعية تتيح تسليم عنقود Amazon SageMaker HyperPod واحد بإدارة EKS إلى عدة فرق في وقت واحد بصورة آمنة. يتكون المخطط من خمس طبقات: دخول موحّد عبر AWS IAM Identity Center، وSageMaker Domains منفصلة ومساحات أسماء Kubernetes للعزل، وHyperPod Task Governance للتوزيع العادل للمسرّعات، واحتساب للتكاليف على مستوى namespace لإصدار الفواتير الداخلية. وتأتي هذه البنية ردًّا على مشكلة شائعة: وحدات GPU باهظة الثمن وشحيحة، وتخصيص عنقود مستقل لكل فريق إهدار للموارد.

لماذا نقسم عنقودًا واحدًا

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

تجيب بنية AWS عن كل سؤال بمكوّن مستقل.

كيف يعمل العزل

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

بعد ذلك تعمل حدود مزدوجة. يحصل كل فريق على SageMaker Domain خاص به، أي بيئة عمل مستقلة تضم ملفات تعريف المستخدمين وأدوار التنفيذ. وبالتوازي تُنشأ له مساحة أسماء Kubernetes في عنقود EKS المشترك، حيث تعمل مهامه. يحدد Domain ما يراه الشخص وما يشغّله، بينما يحدد namespace مكان تنفيذ هذه المهام وبأي قيود على العتاد المشترك.

العدالة والمال

العزل وحده لا يكفي: فمن دون قواعد لتوزيع الحوسبة يتحول العنقود المشترك إلى صراع على الموارد. وهنا يأتي دور HyperPod Task Governance. فهو يتيح تحديد حصة من الموارد الحاسوبية وأولويات للمهام لكل فريق. ويمكن استخدام السعة الخاملة لدى الفرق الأخرى بصورة مؤقتة، وعندما يستعيد صاحبها حقه تتنحى المهام الأقل أولوية. وبهذا يرتفع معدل استخدام العنقود وتبقى الحصة المضمونة لكل فريق محفوظة.

الطبقة الأخيرة مالية. تُربط التكاليف بـ namespace، ومن ثم بفريق محدد. وهذا أساس chargeback: يرى قسم المحاسبة ومديرو الأقسام من استهلك كم، ويمكنهم إصدار فواتير داخلية دون جداول يدوية.

العناصر الرئيسية في المخطط:

• العنقود: Amazon SageMaker HyperPod واحد بإدارة EKS.
• المصادقة: AWS IAM Identity Center، وتقابل المجموعات الفرق.
• العزل: SageMaker Domain وnamespace في Kubernetes منفصلان لكل فريق.
• العدالة: HyperPod Task Governance مع الحصص والأولويات.
• المالية: توزيع التكاليف على مستوى namespace.

من أين تبدأ التنفيذ

تصف المصدر البنية فقط، لذا فإن ما يلي استنتاجاتي العملية وليس بيانات من AWS.

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

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