‏قابل‌اعتماد نگه داشتنِ GPU در مقیاس بزرگ

نویسنده‌ها می‌گن آموزشِ توزیع‌شدهٔ GPU دیگه تو کلِ صنعت عادی شده و برای رسیدن به مقیاسِ امروز باید کلی چیز رو درست کرد: تشخیصِ خرابی‌هایی که یه ران رو زمین می‌زنن، پیدا کردنِ کندی‌های خاموشی که هیچ‌وقت خودشونو اعلام نمی‌کنن، اعتبارسنجیِ سلامتِ فابریک روی هزاران لینک، زمان‌بندی حول سخت‌افزاری که بالاخره خراب می‌شه، و ریکاوریِ تمیز موقع خرابی. این اولین پست از یه سریه و به گفتهٔ اون‌ها روی «پایه» تمرکز داره.

دیتابریکس می‌گه بیشتر خرابی‌های GPU در مقیاس بالا سه دسته‌ان. جابِ کرش‌کرده ساده‌ترین حالته چون فوری می‌فهمی، ولی معمولاً همه‌شون با یه پیامِ NCCL watchdog timeout ظاهر می‌شن که فقط نشونه‌ست نه ریشه. کندیِ خاموش خطرناک‌تره: یه GPUِ تنزل‌یافته همچنان پیش می‌ره و لاگ‌ها سالم به نظر می‌رسن، ولی throughput رو کندترین GPU گیر می‌کنه و پول و محاسبه هدر می‌ره (با سیگنال‌هایی مثل HW_THERMAL_SLOWDOWN تو DCGM دیده می‌شه). خرابیِ عددی هم وقتیه که ECC نتونه خطای حافظه رو جبران کنه و نتیجه به‌شکلِ NaN شدنِ loss یا افتِ کیفیتِ مدل ظاهر بشه.

به گفتهٔ نویسنده‌ها نرخِ رخدادِ خرابیِ GPU می‌تونه یه مرتبه بزرگ‌تر از CPU باشه؛ با فرضِ محافظه‌کارانهٔ ۱٪ سالانه، یه جابِ ۲۵۶تایی رو ۳۰ روز حدود ۱۹٪ و یه جابِ ۱۰۲۴تایی حدود ۵۷٪ احتمالِ خرابی داره. یعنی تو این مقیاس، خرابی حین ران انتظار می‌ره نه استثنا. دو سرمایه‌گذاریِ بنیادی این وضع رو مدیریت می‌کنه: استرس‌تست با بارهای پیشرفته، و یه سیستمِ health checkِ چندمرحله‌ای.

دیتابریکس می‌گه همون بارهای سنگینی که مشتری‌ها استفاده می‌کنن — مثل یادگیریِ تقویتی برای مدل‌های کدنویسیِ ایجنتی و سیستم‌های هوشِ اسناد — رو اجرا می‌کنه تا مشکلاتی مثل بی‌ثباتیِ فابریک، نقاطِ داغِ حرارتی و حالت‌های مرزیِ ارتباطِ جمعی زودتر رو بشن. یه نمونه‌ش این بود: یه ران بعد از ۷ ساعت با NCCL timeout کرش کرد، درحالی‌که فقط یه پورتِ InfiniBand یک‌بار قطع و وصل شده بود. ریشه این بود که کدوم تایم‌اوت زودتر شلیک می‌کنه: NCCL_IB_TIMEOUT (حدود ۷ ثانیه، لایهٔ ترنسپورتِ IB) خیلی زودتر از watchdogِ پای‌تورچ (حدود ۱۰ دقیقه) عمل می‌کنه. درسش این بود که سیگنالِ مهم، مجموعِ زمانِ قطعیه نه تعدادِ flap؛ برای همین دیفالت‌ها رو تنظیم کردن و با همون سیگنال، جاب رو سریع از checkpoint ری‌استارت می‌کنن.

قلبِ کار، سرویسی به اسم gpu-monitor‌ه که رو هر نودِ GPU در کلِ چرخهٔ عمر اجرا می‌شه. چک‌های بوت‌استرپِ فعال موقعِ provision و بینِ کارها اجرا می‌شن (سرعتِ محاسبه و burn-in، اتصالِ نظیربه‌نظیرِ NVLink/NVSwitch، درستی و پهنای‌باندِ NCCL درون‌نودی، DCGM). چک‌های پیوستهٔ پسیو زیرِ فشارِ بار مراقبِ خرابی‌های غیرقطعی‌ان (وضعیتِ لِینِ NVLink، دلایلِ throttle، قطعیِ پورت بر اساسِ زمانِ تجمعی، خطاهای XID، خطاهای PCIe AER، گرادیانِ حرارتی). چک‌های چندنودیِ دوره‌ای هم رو نودهای بی‌کار، سلامتِ فابریکِ بین‌نودی رو با پروبِ پهنای‌باندِ NCCL از ۸ بایت تا ۲ گیگ می‌سنجن (پیام‌های کوچیک تأخیرمحور، پیام‌های بزرگ پهنای‌باندمحور). نودِ خراب قرنطینه، ری‌ست و دوباره تست می‌شه.

جمع‌بندیِ نویسنده‌ها اینه که قابلیتِ اطمینانِ GPU یه سیستمِ «انباشتی»‌ه: هر نسلِ سخت‌افزار و هر الگوی بارِ جدید، حالت‌های خرابیِ تازه‌ای رو می‌سازه که باید به چک‌ها اضافه بشن و هر کدوم سیستم رو قوی‌تر می‌کنه. به گفتهٔ اون‌ها زیرساختِ قابل‌اعتمادِ GPU در این مقیاس، همون چیزیه که نسلِ بعدیِ محصولاتِ AI رو ممکن می‌کنه.

نکات کلیدی:

• خرابیِ GPU سه دسته‌ست: کرشِ آشکار، کندیِ خاموش، و خرابیِ عددی
• کندیِ خاموش گرونه چون throughput رو کندترین GPU گیر می‌کنه بی‌آنکه کسی بفهمه
• در این مقیاس خرابی انتظار می‌ره: جابِ ۱۰۲۴تایی رو ۳۰ روز حدود ۵۷٪ احتمالِ خرابی داره
• درسِ NCCL: سیگنالِ مهم مجموعِ زمانِ قطعیه، نه تعدادِ flap؛ NCCL_IB_TIMEOUT زودتر از watchdog شلیک می‌کنه
• gpu-monitor سخت‌افزار رو قبل، حین و بینِ کارها چک می‌کنه و نودِ خراب رو قرنطینه می‌کنه