Slurm: المجدول الذي يقرر من يحصل على وحدة معالجة الرسومات

ملخص

• يخصص Slurm العُقد ووحدات المعالجة المركزية والذاكرة ووحدات معالجة الرسومات وغيرها من الموارد، ويحوّل الأقسام والأولويات وقواعد جودة الخدمة والحصص العادلة والحجوزات إلى قرارات داخل قائمة الانتظار.
• تتيح TRES وGRES والطوبولوجيا ومجموعات التحكم للمشغلين جدولة المسرّعات بوصفها موارد مادية خاضعة لقيود؛ فعدد وحدات معالجة الرسومات وحده لا يضمن موضعاً مفيداً أو تنفيذاً كفؤاً.
• أسس مطورو Slurm شركة SchedMD في عام 2010 لتقديم الهندسة التجارية والدعم والتدريب؛ واستحوذت NVIDIA على الشركة في 15 ديسمبر 2025، وتعهدت باستمرار التطوير مفتوح المصدر والمحايد تجاه المورّدين.
• ستعتمد المصداقية بعد الاستحواذ على الاختبارات متعددة المورّدين وسلوك الإصدارات وأنماط المساهمة، بينما يظل كل مشغل عنقود مسؤولاً عن السياسة التي يختبرها مستخدموه فعلياً.

وحدة معالجة الرسومات الخاملة ليست بالضرورة متاحة

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

يجعل هذا التسلسل Slurm أكثر من مجرد قائمة انتظار. فهو مستوى تحكم في القبول والتخصيص لفئة كبيرة من أنظمة الحوسبة عالية الأداء والذكاء الاصطناعي. يرسل المستخدمون المهام؛ ويقيّمهاslurmctldفي ضوء حالة العنقود وسياساته؛ وتشغّل عملياتslurmdعلى عُقد الحوسبة الأعمال وتراقبها؛ بينما يديرslurmstepdخطوات كل مهمة على حدة. ويمكن لخدمةslurmdbdالاختيارية تسجيل المهام واستخدام الموارد وعلاقات الحسابات في قاعدة بيانات.

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

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

يحوّل Slurm السياسة المحلية إلى وقت تشغيل فعلي

بدأ Slurm ضمن تعاون قاده Lawrence Livermore National Laboratory، وظهر لأول مرة في عام 2002. وكانت مهمته الأولى تنسيق أعمال متوازية أُرسلت بصورة مستقلة عبر عناقيد Linux كبيرة، من دون مطالبة كل تطبيق بفهم الجهاز بالكامل. وفصلت البنية الأصلية تخصيص الموارد عن تنفيذ المهام، وقدمت طبقة تحكم مشتركة يمكن تكييفها بين المؤسسات.

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

حدث التحول الأعمق مع تراكم أدوات السياسة في Slurm. تجمع الأقسام العُقد في فئات خدمة أو مجموعات إدارية. وتربط الارتباطات المستخدمين والحسابات بالحصص والحدود والاستخدام التاريخي. ويمكن لقواعد جودة الخدمة تغيير الأولوية أو الحدود أو سلوك الاستباق. وتحجز الحجوزات الموارد للصيانة أو الفعاليات أو المستخدمين المحددين. كما يمكن للأولوية متعددة العوامل الجمع بين العمر والحصة العادلة وحجم المهمة والقسم وجودة الخدمة والعوامل التي يحددها الموقع.

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

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

تحدد الحصة العادلة من ينتظر، لا معنى الإنصاف

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

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

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

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

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

تملأ الجدولة الخلفية الفجوات الخالية بأعمال مفيدة

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

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

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

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

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

جعلت وحدات معالجة الرسومات هيئة التخصيص بأهمية حجمه

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

يمثل Slurm الموارد غير المتجانسة من خلال الموارد القابلة للتتبع، أو TRES، والموارد العامة، أو GRES. ويمكن عد وحدات معالجة الرسومات وتصنيفها وربطها بالعُقد. كما يمكن لتكامل الأجهزة ومجموعات التحكم تقييد المهمة بالمسرّعات المخصصة لها. وتستطيع إضافات الطوبولوجيا والقيود مساعدة المجدول في توزيع العمل مع قدر من الوعي بالبنية المادية للجهاز.

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

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

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

يقع المجدول فوق النسيج لكنه يظل معتمداً عليه

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

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

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

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

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

حوّلت SchedMD مشروعاً مفتوحاً إلى نشاط للدعم

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

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

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

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

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

غيّرت NVIDIA الحوافز المحيطة بالإشراف

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

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

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

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

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

لذلك ينبغي صياغة سؤال الحياد بوصفه اختباراً هندسياً قابلاً للرصد. هل تظل الواجهات عامة حيثما أمكن؟ وهل تُعالج المشكلات التي تؤثر في العتاد المنافس بصورة علنية وسريعة؟ وهل تختبر عمليات الإصدار وبيئات التكامل المستمر قاعدة عتاد غير متجانسة فعلاً؟ وهل يظل بوسع المساهمين الخارجيين التأثير في الشفرة من دون المرور عبر منتج احتكاري تابع لـNVIDIA؟

يمنح المصدر المفتوح المشغلين حق الخروج، لا بديلاً مجانياً

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

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

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

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

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

يضع Slinky مستويي تحكم في البيئة نفسها

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

Slinky هو محاولة SchedMD للربط بين هذين العالمين. يستطيعslurm-operatorنشر مكونات Slurm وإدارتها من خلال آليات موجهة إلى Kubernetes، بينما ينسقslurm-bridgeالعمل بين Kubernetes وSlurm على موارد مشتركة. وصدر الإصدار 1.2.0 في 2 يوليو 2026 بعد ظهور أول سلسلة مستقرة في أواخر عام 2025.

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

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

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

وسّع تاريخ Slurm مراراً حدود ما ينسقه المجدول. يواصل التكامل مع Kubernetes هذا النمط، لكن كل سطح تحكم جديد يزيد أهمية معرفة موضع انتقال المسؤولية عند حدوث عطل.

قد تحسن قائمة الانتظار الاستخدام وتظل تنتج نتيجة سيئة

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

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

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

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

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

تحتاج العملية الموثوقة إلى قابلية تدقيق كافية للتمييز بين هذه الحالات.

سطح التحكم الحقيقي موزع بين عدة جهات

قد يبدو الإشراف على Slurm مركزياً لأن متحكماً واحداً يجدول العنقود، ولأن شركة واحدة توظف الآن كثيراً من خبراء المشروع. لكن التحكم موزع عملياً.

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

هذا التحكم متعدد الطبقات هو الحقيقة المركزية في Slurm. فلا تملك جهة واحدة النتيجة بأكملها.

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

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

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