AWS تضيف 3 فحوصات إلى تدريب النماذج لاكتشاف أخطاء GPU الصامتة

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

هذا تحليل هندسي مفيد للفرق التي تدرّب النماذج على عدة عقد GPU. ففيه شيفرة الفحوصات وإجراء الاستعادة عبر SageMaker HyperPod. والفكرة الرئيسية تنطبق على نطاق أوسع من سحابة بعينها: غياب التحذيرات العتادية لا يعني أن الحسابات صحيحة.

كيف يصبح خطأ واحد خطأً مشتركًا

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

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

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

ولتقدير حجم المشكلة، تورد AWS بيانات عن تدريب Llama 3 405B: ففي 54 يومًا ربطت Meta ستًا من 419 انقطاعًا غير متوقع بتلف صامت للبيانات. وتشمل هذه الإحصائية الحالات المكتشفة التي أمكن ربطها بعطل، ولا تعكس وتيرة جميع الأخطاء غير الملحوظة.

ثلاثة فحوصات في حلقة التدريب

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

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

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

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

ما يجب مراعاته قبل التطبيق

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

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

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