جدولة مؤثرة لمجموعات GPU

بناء مجدول لمجموعة حاسوبية لإعطاء الأولوية للأبحاث عالية الأثر مع الحفاظ على إشغال كامل

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

الأساس هو التوافر: أي عدد المرات التي تكون فيها الأجهزة سليمة وجاهزة للعمل. وفوق هذا يأتي الإشغال: أي نسبة الوقت المتاح المخصص لحمل عمل محدد. ثم يأتي الأثر: أي عدد المرات التي تُختار فيها الأحمال العملية الأكثر قيمة لتلقي الموارد. وتُوّج الهرم بـ الاستخدام: أي نسبة قدرة GPU المستخدمة على مدى عمر حمل العمل.

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

الإفراط في الالتزام

في Ai2، ندير آلافًا من وحدات NVIDIA H100 وB200 وB300 الموزعة في مجموعات يتراوح حجمها بين 88 و1024 وحدة GPU. صُممت هذه المجموعات للتدريب الموزع على نطاق واسع لنماذج الذكاء الاصطناعي، وتخدم مجموعة من نحو 150 باحثًا داخليًا يشمل عملهم مجموعة متنوعة من مجالات الذكاء الاصطناعي، بما في ذلك التدفق الكامل لتدريب نماذج LLM وVLM، ومحاكاة التعلم المعزز (RL) في الروبوتات، والتدريب اللاحق لحالات الاستخدام الوكيلة العلمية.

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

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

مأساة المشاعات

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

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

ميزانيات لا جداول زمنية

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

كنا نحل يدويًا مشكلة الحقيبة (knapsack)، محاولين ملاءمة احتياجات بحثية متغيرة باستمرار في جدول زمني ثابت. أردنا حافز الملكية، لكننا أردنا أيضًا الحفاظ على إشغال كامل للـ GPUs.

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

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

تمثل القيم بين قوسين السعة الإجمالية للمجموعة المخصصة لمشروع ورقي (leaf).

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

الحصة العادلة

بالتزامن مع أداة موازنة وقت GPU هذه، بنينا جدولًا هرميًا بالحصة العادلة لإدارة الإشغال الفعلي للتخصيصات عبر شجرة البرنامج بأكملها. الخوارزمية هنا ليست جديدة—الحصة العادلة الهرمية عبر نافذة زمنية جزء من سلسلة تعود إلى Hadoop Fair Scheduler في 2009، ونفس النهج قيد الاستخدام الفعلي اليوم في SLURM’s Fair Tree و YARN’s Fair Scheduler. الجديد بالنسبة لنا هو المدخلات: الشجرة تعكس هيكل البرنامج البحثي، والأوزان هي ميزانيات يضعها المدراء بدلًا من حصص ثابتة.

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

«الجدول الجديد يجعلنا نشعر وكأن لدينا 30% قدرة حوسبية إضافية. في الجدول القديم، إذا كانت لدينا لحظات لم نكن فيها بحاجة إلى كامل حدّ السلوتات لدينا، كانت تلك القدرة تضيع فعليًا. الآن مع الجدول الجديد، إذا حدث ذلك، يمكننا لاحقًا التجاوز فوق حد التخصيص (burst) ومع ذلك نرى مهامنا مجدولة بسرعة ودون استباق، مما يتيح لنا عمليًا استعادة تلك القدرة. أحمال عملنا متقطعة غالبًا، لذا أعاد لنا هذا قدرًا كبيرًا من القدرة الحوسبية.» — كريس كلارك

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

عقد الجدولة

ميزة إضافية في التدريب الموزع تجعل التوزيع العادل للموارد أمرًا صعبًا هي أن أحمال العمل قد تعمل لوقت طويل جدًا. مهام التدريب تعمل بانتظام لساعات وأيام، وأحيانًا حتى أسابيع. بمجرد جدولتها، قد يبقى حمل العمل على الـ GPUs المخصصة له لأسبوع أو أكثر، دون توفير أي فرصة للآخرين للحصول على وقتهم المخصص. هذه هي خاصية النظام التي جعلت احتلال GPU (squatting) ممكنًا. وهي أيضًا ما أجبر مهندسي الاتصال (on-call) على التفاوض مع مالكي المهام طويلة الأمد لمعالجة مشكلات الصيانة المستمرة.

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

يتبع دورة حياة الحِمل هذا النمط:

1. يُرسَل الحِمل مع حد أدنى لزمن التشغيل ويشير إلى ما إذا كان قابلًا للاستئناف أم لا.
2. تتم جدولة الحِمل وفقًا لخوارزمية الحصة العادلة، موزونًا بنسبة الاحتلال الفعلي إلى الوقت المخصص في نافذة الرجوع.
3. يعمل الحِمل لمدة الحد الأدنى لزمن تشغيله، وهو ما يُخصم من مخصصاته.
4. قد يستمر الحِمل في العمل طالما استمرت المخصصات المرتبطة به في ترتيبه على الآخرين. ويُخصم هذا الوقت أيضًا من مخصصاته.
5. قد يُستبق الحِمل ويُعاد إدراجه في قائمة الانتظار، مما يعيده إلى الخطوة 2.
6. يكتمل الحِمل، محررًا مطالبته بأي موارد.

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

المحاكاة

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

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

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

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

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

النتائج

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

منذ الطرح، لاحظنا المستخدمين والفرق يتلقون باستمرار وقت GPU المخصص لهم. نحسب الوقت المستحق لفريق على أساس مخصصاته مقيدًا ساعة بساعة بطلبه الفعلي. خلال فترة الاختبار البالغة 30 يومًا، تم تسليم 98% من ساعات GPU المستحقة للفرق، وحصل 13 من أصل 15 مخصصًا للفرق على 95% أو أكثر، مع تلقي أسوأ حالة 90%. وابقى الاحتلال على العنقود مستقرًا عند 98% قبل التغيير وبعده، مع تجاوز الطلب للسعة بمقدار 2-3x في الفترتين. وكان 18% من وقت GPU المسلَّم غير مخصص، وهو كيف حافظنا على احتلال مرتفع خلال الفترات التي لم تكن فيها حالات الاستخدام الممولة جاهزة للتشغيل.

أثبتت نتائج المحاكي لدينا دقتها الاتجاهية مع النتائج الحقيقية التي تجاوزت توقعاتنا. انخفض زمن انتظار قائمة الانتظار p90 لأعباء التصحيح (debug) من 2 ساعة إلى 30 ثانية تحت المجدول الجديد، مقابل تنبؤ محاكى بـ 6 ساعات إلى 5 دقائق من سيناريوهات اختبار معدّة يدويًا. ومن الجدير بالذكر أن حجم العينة الأصغر لأعباء التصحيح في خط الأساس يعني وجود تباين أعلى في تلك القياسات. وتحسنت زمنية انتظار قائمة الانتظار عمومًا كنتيجة جانبية للتقسيم الزمني: في أكبر عناقيد H100 لدينا، انخفض الوسيط لزمن انتظار قائمة الانتظار من 5 دقائق إلى 24 ثانية، وانخفض زمن الانتظار p90 بنحو الثلث (من 2.8 ساعة إلى 1.8 ساعة).

وبالمقارنة مع المشاكل الثلاث التي وضعناها نصب أعيننا لحلها:

1. الاحتلال (Squatting): تبدأ أعباء التصحيح القصيرة في أقل من دقيقة، مما يقلل من قيمة الاحتلال. وتُخصم تكلفة هذا السلوك من ميزانية المحتل، مما يمنعه من الحصول على وقت عندما يحتاجه فعلًا.

2. تضخم الأولويات: ما زلنا نسمح للأعباء بتحديد الأولوية، لكنها لا تؤثر إلا على الترتيب داخل الفريق. ويكون لدى المديرين حافز لمراقبة الأولويات عبر المجموعة لتحسين استخدام ميزانياتهم.

3. أعمال التشغيل والصيانة المرهقة (On-call toil): تُصفّى المضيفات غير الصحية تلقائيًا مع وصول الأعباء إلى الحد الأدنى من وقت التشغيل. وانخفضت الإصلاحات التي تتطلب تدخلًا بشريًا بنسبة 74%.

التحديات

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

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

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

مثال على تمثيل بصري لاستخدام التخصيص عبر الزمن.

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

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

المستقبل

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

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