NVIDIA تعرض الحتمية على مستوى البت في Megatron Core للتدريب المسبق على آلاف وحدات GPU

يكلّف تدريب نموذج بتريليونات المعاملات على آلاف وحدات GPU ملايين الدولارات ويستغرق أسابيع. وإذا ظهرت في منتصف التشغيل قفزة في الخسارة (loss) أو قيم NaN، فعادةً لا يمكن إعادة إنتاجها، لأن ترتيب العمليات يتغير من تشغيل إلى آخر فيختفي الخطأ. نشرت NVIDIA على Developer Blog مادة عن كيفية تحقيق الحتمية على مستوى البت في التدريب المسبق داخل Megatron Core. فالتشغيلان بالبيانات والإعدادات نفسها يجب أن يعطيا نتائج متطابقة حتى آخر بت.

لماذا يندر تحقيق الحتمية في التدريب المسبق

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

وذكر المصدر عوامل تزيد الأمر تعقيدًا:

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

أما الأساليب التي يعتمد عليها Megatron Core لضبط ترتيب العمليات، وكلفة الحتمية من حيث السرعة، فلم يكشف عنهما الجزء المتاح من المادة. ينبغي البحث عن هذه البيانات في النسخة الكاملة منها.

ماذا تمنح القابلية للتكرار على مستوى البت

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

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

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

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

ثمن الحتمية وأين تفيد

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

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

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

خلاصة عملية للفرق

على الفرق التي تدرّب نماذجها الخاصة على Megatron Core أن تُعدّ تشغيلًا قصيرًا للتحقق في الوضع الحتمي وتضمّنه في CI. فأي تغيير في الشيفرة أو برامج التشغيل أو إعدادات التوازي يُقارَن أولًا بالمرجع عبر تجزئات (hashes) الأوزان بعد عدد ثابت من الخطوات. وأي اختلاف يبيّن فورًا أن التغيير أثّر في السلوك العددي.

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