‏چرا SLA دیتاسنتر، جاب آموزش شما رو نجات نمی‌ده

تز اصلی این مقاله اینه که سیستم‌های AI با قابلیت اطمینان بالا تو کولوکیشن، معمولاً خیلی قبل از اینکه ساختمون به مشکل بخوره، سر ورک‌لود شکست می‌خورن. آپتایم سنتی می‌سنجه که سایت آنلاین مونده یا نه؛ قابلیت اطمینان AI می‌سنجه که جاب درست تموم شده یا نه. یه فَسیلیتی می‌تونه کاملاً به SLA‌اش پایبند باشه درحالی‌که جاب آموزش شما بی‌سروصدا شکست می‌خوره یا نتیجهٔ بد می‌ده.

پس معیارها باید سطح ورک‌لود باشن: MFU (سهمی از توان محاسباتی تئوری GPU که آموزش واقعاً استفاده می‌کنه)، نرخ موفقیت جاب، زمان تکمیل چک‌پوینت و RTO یا سرعت برگشت ورک‌لود بعد از خرابی. نویسنده می‌گه اول SLO رو با زبون ورک‌لود تعریف کنین و بعد عقب‌گرد کنین به اینکه دیتاسنتر باید چی فراهم کنه — نه برعکس.

تو بخش برق و خنک‌کاری، عددها گویان: رک سازمانی معمولی حدود ۵ تا ۱۰ کیلووات می‌کشه، ولی یه رک GPU مدرن ممکنه ۳۰ تا ۱۵۰ کیلووات لازم داشته باشه. طراحی برق معمولاً با 2N به کابینت شروع می‌شه (دو مسیر تغذیهٔ کاملاً مستقل که هرکدوم بتونن کل بار رو ببرن)، ولی افزونگی فقط وقتی به درد می‌خوره که سوییچ بین مسیرها اون‌قدر تمیز و سریع باشه که کلاک GPUها حین انتقال نیفته.

خنک‌کاری جاییه که خیلی از استقرارها بی‌سروصدا شکست می‌خورن. تو این توان‌ها هوا نمی‌تونه حرارت رو به‌اندازهٔ کافی سریع ببره، پس خنک‌کاری مستقیم مایع (DLC) با کولدپلیت روی GPU لازمه — همراه با CDUهای افزونه، پمپ hot-swap، شیرهای ایزوله و تشخیص نشتی. مقاله یه مثال می‌زنه: تیم تصویربرداری پزشکی روی سایتی با خنک‌کاری N+1، حین سرویس یه CDU، دما بالا می‌ره، کلاک GPU تراتل می‌شه و لِیتنسی دو برابر می‌شه — SLA فَسیلیتی نقض نمی‌شه، ولی SLO ورک‌لود می‌شکنه. درس: N+1 بدون هدروم یعنی خنک‌کاری غیرقابل‌اتکا.

برای شبکه، انتخاب معمولاً بین InfiniBand (لِیتنسی خیلی کم و رفتار جمعی قطعی، ولی ایزولاسیون چندمستأجری محدود) و RoCEv2 روی اترنت (مقیاس‌پذیرتر و ایزولاسیون قوی‌تر، ولی نیازمند تنظیم سخت‌گیرانهٔ کنترل ازدحام) خلاصه می‌شه. نویسنده می‌گه سؤال درست پهنای‌باند پیک نیست؛ سؤال اینه که وقتی یه لینک سوییچ بالای رک وسط یه collective می‌ره، چی می‌شه — و جوابش باید قبل از پروداکشن نوشته و تست شده باشه.

استوریج هم دو الگوی متفاوت داره: خوندن آموزشی (ترتیبی و پرحجم؛ اگه عقب بمونه GPUها بین بچ‌ها گیر می‌کنن و MFU سقوط می‌کنه) و نوشتن چک‌پوینت (نوشتن انفجاری کل وضعیت مدل؛ اگه کند باشه یا شکست بخوره، پیشرفت آموزش با اولین خرابی از دست می‌ره). GPUDirect RDMA اجازه می‌ده استوریج مستقیم تو حافظهٔ GPU بنویسه و زمان چک‌پوینت رو خیلی کم کنه. مثال دوم مقاله هم دقیقاً همین‌جاست: یه نود استوریج وسط آموزش شبانه می‌میره، فایل‌سیستم موازی بازسازی می‌شه، جاب abort نمی‌شه ولی با کسری از توان می‌چرخه و هیچ آلارمی هم بلند نمی‌شه.

بخش پایانی دربارهٔ تست پذیرشه: تور دیتاسنتر و برگهٔ مشخصات، تست پذیرش نیستن. مقاله دو دسته تست پیشنهاد می‌ده — تست‌های خط پایهٔ کارایی (بنچمارک‌های NCCL مثل all-reduce و all-gather، یه چرخهٔ کامل آموزش واقعی، و اندازه‌گیری هم‌زمان خوندن و نوشتن استوریج) و تست‌های تزریق خطا (ایزوله‌کردن یه CDU، انداختن لینک سوییچ، کشتن یه نود استوریج). قاعدهٔ قبولی هم باید با زبون ورک‌لود نوشته بشه: هیچ جابی abort نشه، MFU تو زمان مشخص به خط پایه برگرده و چک‌پوینت‌ها سر وقت تموم بشن.

مقاله در نهایت رویکرد خود WhiteFiber رو معرفی می‌کنه — طراحی «سیستم منطبق» با تا ۱۵۰ کیلووات به کابینت، DLC، برق 2N، هم‌طراحی فابریک و استوریج، و آبزرویبیلیتی پیش‌فرض. توصیهٔ عملی‌اش برای خریدار اینه: شریک درست اونیه که قبل از امضا نتیجهٔ تست پذیرش، رانبوک خرابی و داشبورد تله‌متری رو نشونتون بده.

نکات کلیدی:

• آپتایم سایت با قابلیت اطمینان ورک‌لود یکی نیست؛ SLA می‌تونه سالم بمونه ولی جاب بمیره
• معیارهای درست: MFU، نرخ موفقیت جاب، زمان چک‌پوینت و RTO
• رک GPU مدرن ۳۰ تا ۱۵۰ کیلووات می‌خواد؛ خنک‌کاری مستقیم مایع و برق 2N الزامیه
• N+1 بدون هدروم یعنی یه خرابی CDU می‌تونه کلاک GPU رو تراتل کنه
• InfiniBand در برابر RoCEv2: انتخاب به مقیاس، مدل مستأجری و کیفیت تنظیم ازدحام بستگی داره
• بدون تست تزریق خطا (خنک‌کاری، شبکه، استوریج)، ادعای «آمادهٔ پروداکشن» فقط روی کاغذه