معالجة الأعطال في مجموعات الذكاء الاصطناعي: ما الذي يتعطل فعلياً وكيفية التعافي

يُعدّ التدريب الموزّع أحد أنواع أحمال العمل التي لا تُمثّل فيها أعطال الأجهزة إزعاجًا نادرًا، بل تُشكّل عبئًا تشغيليًا مستمرًا. وقد سجّل تقرير تحليل الأعطال الذي نشرته شركة ميتا (Llama 3.1 405B) 419 انقطاعًا غير متوقع على مدار 54 يومًا على مجموعة حوسبة تضم 16,384 وحدة معالجة رسومية (GPU): أي بمعدل انقطاع واحد كل ثلاث ساعات، مع مسؤولية أعطال وحدات معالجة الرسوميات وذاكرة HBM عن نصف هذه الانقطاعات تقريبًا. هذه هي تجربة التشغيل المستمر لآلاف وحدات معالجة الرسوميات بكثافة عالية.

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

أنماط الفشل الفعلية

هناك فئتان مهمتان: أحداث الأجهزة (مثل وحدة معالجة الرسومات، ووحدة تزويد الطاقة، وبطاقة الشبكة، والقرص الصلب) وأحداث البرامج (مثل CUDA، وNCCL، والإطار البرمجي، واستجابة نظام التشغيل السلبية لحدث عابر). فيما يلي ترتيب تقريبي لمدى تكرار كل منهما في محطات العمل متعددة وحدات معالجة الرسومات أو المجموعات الصغيرة.

أخطاء XID لوحدة معالجة الرسومات

سجلات النواة (dmesg, journalctl -kتُعدّ هذه البيانات مصدر الحقيقة. تُصدر NVIDIA سطر XID عند حدوث أي عطل في وحدة معالجة الرسومات. وهذه هي البيانات التي تراها فعليًا:

ملاحظتان من واقع التجربة:

• XID 79 هو الرقم الذي يتصل العملاء بشأنه في حالة من الذعر. "اختفت وحدة معالجة الرسومات." في حالة استخدام وصلات PCIe ذات 4 أو 8 منافذ، فإن الخطأ XID 79 غالبًا ما يكون بسبب مشكلة في وصلة PCIe، أو انفصال موصل الطاقة نتيجةً لدورات التبريد والتدفئة، أو إيقاف تشغيل تلقائي بسبب الحرارة - وليس بسبب عطل في وحدة معالجة الرسومات. أعد تركيبها، وأعد توصيل الكابلات، وأعد الاختبار قبل إرسالها للصيانة.
• XID 48 و 63 حقيقيان. تتراكم عيوب تصحيح الأخطاء (ECC) تدريجيًا على مدى أشهر في البطاقات المستخدمة بكثافة. يقوم معالج الرسوميات (GPU) بإيقاف الصفحات تلقائيًا حتى ينفد لديه عدد الصفوف الاحتياطية. بعد ذلك، تصبح البطاقة غير آمنة للتدريب؛ لذا يقوم معظم المشغلين باستبدالها.

نفاد ذاكرة CUDA أثناء التشغيل

يُعدّ هذا العطل التدريبي الأكثر شيوعًا على أجهزتنا، وغالبًا ما يكون خطأ المُشغّل وليس عطلًا في الجهاز. النمط المعتاد: يعمل التدريب بشكل جيد لـ 200 خطوة، ثم يتعطل فجأة. CUDA error: out of memoryالسبب عادةً هو:

1. تنمو ذاكرة التنشيط مع طول التسلسل — العينات الأطول في وقت لاحق من الحقبة تتجاوز الميزانية.
2. عملية نظيرة على نفس وحدة معالجة الرسومات. nvidia-smi يظهر معرفين للعملية (PID)؛ كان من المفترض إيقاف أحدهما ولكنه لم يُوقف.
3. تجزئة الذاكرة. يرفض مُخصِّص التخزين المؤقت في PyTorch كتلة متجاورة كبيرة حتى مع وجود ذاكرة حرة كافية. الحل: PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True.

مضاعفة وحدة معالجة الرسومات لا تُجدي نفعًا. الحل الأمثل هو تقليل حجم الدفعات الصغيرة، أو تفعيل نقاط التحقق من التدرج، أو تجزئة المُحسِّن (انظر كيه02 ).

انقطاعات مهلة NCCL وأعطال الشبكة

مجموعات NCCL (all_reduce, all_gather, reduce_scatterتتم معالجة الأخطاء بشكل متزامن عبر جميع المستويات. إذا تعطل مستوى واحد - بسبب عطل في بطاقة الشبكة، أو ازدحام في المحول، أو خلل في مُجدول النواة، أو بطء وحدة معالجة الرسومات - فإن جميع المستويات الأخرى تنتظر عند المجموعة التالية، ويتوقف العمل بالكامل. بدون معالجة الأخطاء غير المتزامنة، يكون التعطل صامتًا؛ ويبدو أن العمل "معلق" حتى يتم تفعيل مهلة مراقبة النظام (30 دقيقة افتراضيًا).

الحل هو متغير بيئي واحد:

export TORCH_NCCL_ASYNC_ERROR_HANDLING=1
export TORCH_NCCL_TRACE_BUFFER_SIZE=20000  # for post-mortem analysis

ثم يتوقف PyTorch عن العمل بسبب SIGABRT في حالة انتهاء مهلة المجموعة. بالاقتران مع torchelastic، تبدأ المهمة من آخر نقطة تفتيش. ملاحظة: الإصدار الأقدم NCCL_ASYNC_ERROR_HANDLING مهمل.

انقطاع الاتصال بالعقدة وأعطال وحدة تزويد الطاقة

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

تعطل وحدة تزويد الطاقة يُعد عطلاً كارثياً. على خادم مزود بثمانية وحدات معالجة رسومية وحدات تزويد طاقة ATX مزدوجة في تكوين سكة منفصلة، يؤدي عطل وحدة تزويد الطاقة إلى لست نظام احتياطي متساوٍ. وحدة تزويد الطاقة A تُشغّل وحدات معالجة الرسومات من 0 إلى 3، ووحدة تزويد الطاقة B تُشغّل وحدات معالجة الرسومات من 4 إلى 7. في حال تعطل وحدة تزويد الطاقة B، ستختفي أربع وحدات معالجة رسومات إلى معرف XID 79 في غضون أجزاء من الثانية. يتطلب الاستعادة استبدالًا فعليًا. يتطلب النظام الاحتياطي الحقيقي وحدات CRPS قابلة للتبديل السريع 1+1، وهو ما يُناسب خوادم الحاسوب، وليس محطات عمل المستهلكين التي تعتمد على وحدات معالجة الرسومات.

فشل الكتابة على وحدة التخزين أثناء نقطة التحقق

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

تسريبات ECC بطيئة

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

الكشف - ما يجب مراقبته

ثلاث طبقات: مستوى النواة (أسطر XID في dmesg)، مورد وحدة معالجة الرسومات (مصدر DCGM إلى بروميثيوس، dcgmi diag (للفحوصات النشطة)، وعلى مستوى الإطار (مراقب PyTorch، ومخزن تتبع NCCL، وتنبيهات الفقد/الإنتاجية).

التنبيهات المهمة:

• اي XID 48 / 63 / 79 / 92 سطر في سجل النظام dmesg → صفحة
• درجة حرارة وحدة معالجة الرسومات > 85 درجة مئوية لأكثر من 5 دقائق → صفحة
• تزايد عدد أخطاء ECC المتقلبة ← التذكرة، وليس الصفحة
• دي سي جي إم dcgm_thermal_violation قيمة غير صفرية ← مشكلة في التبريد، تحقق من تدفق الهواء
• عدم انخفاض خسارة التدريب لأكثر من 100 خطوة ← يستحق الأمر مراجعة

أمثلة حقيقية لسجلات الفشل

ما تراه بالفعل في journalctl -k عندما يتم تشغيل XID 79 (RTX 5090، كابل الرفع مفصول أثناء دورات التبريد والتدفئة):

Apr 22 03:14:17 kentino-ai-04 kernel: NVRM: Xid (PCI:0000:c1:00): 79, pid='<unknown>', name=<unknown>, GPU has fallen off the bus.
Apr 22 03:14:17 kentino-ai-04 kernel: NVRM: GPU 0000:c1:00.0: GPU is on Board .
Apr 22 03:14:17 kentino-ai-04 kernel: NVRM: A GPU crash dump has been created. If possible, please run
Apr 22 03:14:17 kentino-ai-04 kernel: NVRM: nvidia-bug-report.sh as root to collect this data before
Apr 22 03:14:17 kentino-ai-04 kernel: NVRM: the NVIDIA kernel module is unloaded.

كيف يبدو انقطاع الاتصال في NCCL، باختصار:

[E ProcessGroupNCCL.cpp:475] [Rank 3] Watchdog caught collective operation timeout:
WorkNCCL(SeqNum=842, OpType=ALLREDUCE, NumelIn=268435456, NumelOut=268435456,
Timeout(ms)=1800000) ran for 1800321 milliseconds before timing out.
[E ProcessGroupNCCL.cpp:489] [Rank 3] Some NCCL operations have failed or timed out.
terminate called after throwing an instance of 'std::runtime_error'

يُبلغ النظام ذو الرتبة 3 عن المشكلة، لكنه نادرًا ما يكون هو السبب الحقيقي. النظام البطيء هو النظام الذي لم يصل بعد. يُظهر سجل تتبع NCCL الرتب التي تم حظرها عند كل استدعاء، ومن هنا يُمكن تحديد النظام المُسبب للمشكلة.

أنماط التعافي

يتم إنشاء نقاط حفظ بشكل متكرر بما يكفي بحيث تكون إعادة التشغيل غير مكلفة

لتحسين دقة 7 بايت على 8 وحدات معالجة رسومية RTX 5090 مع نقاط تحقق محلية NVMe: يتم كتابة حوالي 14 جيجابايت بسرعة 3 جيجابايت/ثانية، أي ما يعادل 5 ثوانٍ لكل نقطة تحقق، كل 30 دقيقة تُضيف 0.3% من الحمل الزائد، وأسوأ حالة فقدان للبيانات هي 15 دقيقة. أما بالنسبة لنقطة تحقق مجزأة FSDP بحجم 70 بايت على نفس الجهاز: يتم تجزئة حوالي 140 جيجابايت على 8 وحدات معالجة رسومية بالتوازي، مع حمل زائد مماثل. حل اقتصادي، جربه.

تستغرق عملية التحقق المسبق الكاملة لتدريب نموذج Llama-70B عبر وحدة تخزين الشبكة حوالي 520 جيجابايت، وقد تمتد لأكثر من 20 دقيقة؛ وهنا تبرز أهمية استخدام تقنية التحقق المتدرج غير المتزامن (كتابة محلية سريعة، ونقل بطيء إلى وحدة التخزين الدائمة). أما في نموذج Kentino، فيتم التحقق من كل 15-30 دقيقة إلى وحدة NVMe محلية، ثم تتم المزامنة مع وحدة التخزين الشبكية (NAS) عند انتهاء التشغيل. أي حل أكثر تعقيدًا يُعدّ مبالغة.

إعادة تشغيل تلقائية باستخدام تورشيلاستيك

torchrun يدعم التدريب المرن بشكل افتراضي:

torchrun \
    --nnodes=1:1 \
    --nproc-per-node=8 \
    --max-restarts=3 \
    --rdzv-backend=c10d \
    --rdzv-endpoint=localhost:29500 \
    train.py --checkpoint-dir /mnt/nvme/ckpt

مع TORCH_NCCL_ASYNC_ERROR_HANDLING=1التسلسل هو: تعليق مجموعة NCCL → رفع مراقب PyTorch للأمر → إجهاض العملية بإشارة SIGABRT → يقوم torchelastic بإنهاء العمليات الشقيقة وإعادة التشغيل من latest_checkpoint.ptيستغرق التسلسل الكامل عادةً من 60 إلى 120 ثانية. وتمر النبضات العابرة خلال هذه الفترة. أما العطل الدائم (مثل خطأ XID 79 في وحدة معالجة الرسومات) فيؤدي إلى احتراق --max-restarts ثم يتم وضع الميزانية، وبعد ذلك يكون هناك شخص في حلقة الوصل.

الممارسة التشغيلية

إن العامل الأهم في تحديد تكلفة الفشل ليس رمز الاسترداد، بل ما تفعله. قبل يبدأ العمل.

فحوصات ما قبل الرحلة

قبل تشغيل أي شيء سيستغرق أكثر من ساعتين، قم بتشغيل تسلسل التحقق:

# 1. Per-GPU stress test — catches silent thermal/ECC issues
gpu-burn 600                        # 10 minutes per GPU at full load

# 2. DCGM diagnostic — finds latent hardware faults
sudo dcgmi diag -r 3                # level 3 = thorough, ~15 min

# 3. NCCL fabric test — validates inter-GPU bandwidth on the box
mpirun -np 8 ./build/all_reduce_perf -b 8 -e 1G -f 2 -g 1

# 4. PyTorch dry-run — one step, full batch size, all ranks
torchrun --nproc-per-node=8 dryrun.py

على خادم نظيف مزود بثمانية بطاقات رسومات RTX 5090، all_reduce_perf يجب أن يتراوح عرض نطاق ناقل البيانات بين 50 و80 جيجابايت/ثانية، وذلك حسب بنية PCIe. انخفاضه بشكل ملحوظ عن ذلك يشير إلى وجود مشكلة في الموصلات الرأسية أو البنية - يجب إصلاحها قبل بدء التدريب. نجري اختبار gpu-burn لمدة ساعة كاملة كجزء من ضمان الجودة قبل الشحن على كل جهاز يغادر كينتينو.

ترقبوا التسريبات البطيئة

تتراكم الذاكرة في قواعد البيانات البرمجية الحقيقية: يحتفظ خطاف التسجيل بمرجع موتر، وينسى مسار الاستثناء مسح المخزن المؤقت، ويُسرّب مُجدول LR دالة مغلقة. والنتيجة هي نفاد الذاكرة في الخطوة 5000 من عملية تشغيل من 10000 خطوة. الحل الأرخص: الطباعة torch.cuda.memory_allocated() كل N خطوة إلى سجل التدريب. إذا كان ينمو، فلا ينبغي أن يكون كذلك.

الواقع الإحصائي على نطاق كينتينو

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

تم معايرة التقديرات بناءً على البيانات الوصفية (حالة عطل واحدة لكل 50,000 ساعة تشغيل لوحدة معالجة الرسومات). تختلف الأرقام الفعلية باختلاف طراز وحدة معالجة الرسومات - حيث تتعطل وحدات 4090 و5090 المخصصة للمستهلكين المزودة بوصلات توسعة بشكل متكرر أكثر من وحدات L40 المخصصة لمراكز البيانات في هياكلها الأصلية، ويعود ذلك بشكل رئيسي إلى تآكل موصلات PCIe والطاقة.

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

تكلفة إعادة التشغيل

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

معظم المحتوى المتاح على الإنترنت حول معالجة الأعطال مُصممٌ لمستوى الحوسبة فائقة التوسع. أما في حجم كينتينو، فإن معظمه يُعتبر تصميمًا مُبالغًا فيه. القاعدة الأساسية هي: مراقبة سجلات النواة، وإنشاء نقطة استعادة على وحدة تخزين NVMe محلية، ثم ضبط... TORCH_NCCL_ASYNC_ERROR_HANDLING=1قم بتشغيل برنامج gpu-burn قبل القيام بالمهام الكبيرة.

---

هذا جزء من ويكي كينتينو، وهي سلسلة مرجعية حول الحوسبة الذكية، والروبوتات، والأنظمة التي تربط بينهما. نرحب بالتعليقات والتصويبات على info@kentino.com.