پرش به محتوای اصلی
ORYX

Blog · 13 دقیقه مطالعه

نقشه راه ذخیره‌سازی هوش مصنوعی متا در مقیاس بزرگ

در چند سال گذشته، قابلیت‌های مدل‌ها و اندازه مجموعه‌داده‌های آموزشی رشدی نمایی داشته‌اند.

سیدهارت باجاج و ونکاتاراقاوان سرینیواسان
Read in English →

چرا ذخیره‌سازی به گلوگاه هوش مصنوعی تبدیل شده است

در چند سال گذشته، هم قابلیت‌های مدل‌ها و هم اندازه مجموعه‌داده‌های آموزشی رشدی نمایی داشته‌اند و فاصله زمانی میان انتشار مدل‌های پیشرفته پیاپی از ماه‌ها به هفته‌ها کاهش یافته است؛ به همین دلیل دسترسی سریع و پایدار به ذخیره‌سازی، هم برای سرعت و هم برای هزینه نوآوری هوش مصنوعی حیاتی شده است. با این حال، در حالی که کارایی محاسبات هوش مصنوعی تقریباً هر دو سال سه‌برابر شده، رشد کارایی ذخیره‌سازی بسیار کندتر بوده و همین موضوع گلوگاه‌های ذخیره‌سازی را به یکی از دلایل اصلی توقف GPUها تبدیل کرده است. این نوشته شرح می‌دهد که چگونه معماری ذخیره‌سازی BLOB در متا برای حل دو چالش اصلی تحول یافته است: به حداکثر رساندن بهره‌وری GPU و به حداکثر رساندن سرعت پژوهش.

نمای کلی معماری ذخیره‌سازی

متا صدها خوشه ذخیره‌سازی در مقیاس اگزابایت را اجرا می‌کند که به Facebook، Instagram، Reality Labs، Meta AI، تبلیغات و پایگاه‌های داده داخلی این شرکت خدمت می‌رسانند. سرویس ذخیره‌سازی متا رابط‌های ذخیره‌سازی شیءمحور، فایل‌سیستم و دستگاه بلاک را روی لایه پایه‌ای Tectonic ارائه می‌دهد؛ لایه‌ای منطقه‌ای و چندمستأجری که با کدگذاری پاک‌شونده دوام و دسترس‌پذیری بالا فراهم می‌کند. لایه ذخیره‌سازی BLOB روی Tectonic قرار دارد. نویسندگان یادآوری می‌کنند که پیش‌تر مدل Llama مستقیماً روی لایه بلاک Tectonic آموزش داده شده بود؛ این معماری هنوز به‌طور گسترده در متا استفاده می‌شود، اما پشته آموزشی مدرن به‌تدریج به سمت رابط ذخیره‌سازی BLOB مهاجرت می‌کند.

به حداکثر رساندن بهره‌وری GPU و اهمیت تأخیر

بارهای کاری هوش مصنوعی به‌مراتب «داده‌محورتر» از برنامه‌های وب سنتی هستند: توان عملیاتی بالای پرنوسان، نیاز به تأخیر محدود و قابل‌پیش‌بینی حتی در بدترین حالت، و الگوهای ورودی/خروجی متغیر. در جریان آموزش، صدها هزار GPU به‌طور مکرر روی دسته‌های داده تکرار می‌کنند و در فواصل معین همگام‌سازی می‌شوند؛ اگر بارگذار داده روی حتی یک GPU در دریافت دسته بعدی کند باشد، همان GPU متوقف می‌شود و کل فرآیند آموزش همگام‌شده را کند می‌کند.

چرا معماری قدیمی برای هوش مصنوعی آماده نبود

پشته ذخیره‌سازی BLOB متا طی سال‌ها به‌صورت ارگانیک و در قالب لایه‌های متعدد شکل گرفته بود؛ خواندن یک شیء می‌توانست نیازمند چندین جست‌وجوی فراداده باشد که می‌توانست تا صدها میلی‌ثانیه تأخیر ایجاد کند — تأخیری که برای بارهای کاری هوش مصنوعی که به دسترسی میلی‌ثانیه‌ای نیاز دارند، غیرقابل‌قبول بود. تیم متا چهار پیش‌فرض طراحی قدیمی را شناسایی کرد که دیگر معتبر نبودند: نیازهای تأخیر اکنون سخت‌گیرانه‌ترند؛ تکرار سراسری داده دیگر موازنه مناسبی نیست؛ فلش به‌جای HDD لازم است؛ و محدودیت اصلی مراکز داده هوش مصنوعی اکنون توان مصرفی است نه فضا.

بازسازی زیربنا

متا زیرسیستم فراداده خود را بازنویسی کرد و آن را در یک طرحواره واحد مبتنی بر ZippyDB ادغام کرد که جست‌وجو را به زمان ثابت می‌رساند؛ پراکسی لایه داده را حذف کرد و به جای آن یک SDK کلاینت «سنگین‌وزن» ساخت که داده را مستقیماً از سرورهای Tectonic به کلاینت‌ها جریان می‌دهد؛ و به مدل استقرار منطقه‌ای روی آورد که در آن یک پشته سبک ذخیره‌سازی BLOB منطقه‌ای در کنار GPUها در هر منطقه هوش مصنوعی مستقر می‌شود.

مدیریت جهش‌ها و نقاط داغ

متا دو سازوکار را تطبیق داد: یک حافظه پنهان توزیع‌شده داده که از حافظه آزاد میزبان‌های GPU استفاده می‌کند، و یک حافظه پنهان توزیع‌شده فراداده. در عمل، حافظه پنهان داده به نرخ اصابت میانگین حدود ۸۰ درصد می‌رسد و حافظه پنهان فراداده در ۱ تا ۲ میلی‌ثانیه پاسخ می‌دهد؛ این دو مکانیزم با هم جهش‌های ترافیکی را جذب می‌کنند و تأخیرها را بهبود می‌بخشند.

بهینه‌سازی‌های سطح پروتکل

تیم متا با رفع گلوگاه‌های سطح پروتکل، بخش باقی‌مانده کارایی را نیز پوشش داد؛ از جمله استفاده از «خواندن‌های دوسویه» برای مقابله با تأخیر دنباله‌ای، و ساخت کنترل هم‌زمانی پویا برای تنظیم خودکار میزان موازی‌سازی در طول جهش‌های خروجی ناشی از رویدادهای ذخیره نقطه‌بازرسی.

به حداکثر رساندن سرعت پژوهش

با کمیاب‌تر و پراکنده‌تر شدن جغرافیایی GPUها، پژوهشگران پیش‌تر مجبور بودند به‌صورت دستی مجموعه‌داده‌ها را به منطقه GPUهایشان منتقل کنند — گردش‌کاری که می‌توانست ساعت‌ها طول بکشد. متا بارگذاری داده را بر پایه یک مدل حافظه پنهان چندلایه بازطراحی کرد: حافظه و فلش میزبان GPU به‌عنوان حافظه پنهان L1/L2 عمل می‌کنند و فضای ذخیره‌سازی BLOB منطقه‌ای به‌عنوان حافظه پنهان L3، در حالی که فضای سراسری HDD به‌عنوان منبع نهایی حقیقت باقی می‌ماند. این رویکرد جدید پس از استقرار به‌سرعت پذیرفته شد و زمان بارگذاری داده را به‌طور قابل‌توجهی کاهش داده است.

جمع‌بندی و کارهای آینده

نویسندگان نتیجه می‌گیرند که چون بارهای کاری مدرن هوش مصنوعی بسیار داده‌محور هستند، ذخیره‌سازی مستقیماً بر هزینه محاسباتی و سرعت نوآوری تأثیر می‌گذارد. برآورده کردن این نیازها مستلزم بازاندیشی کامل معماری ذخیره‌سازی BLOB متا بود. مقاله با اشاره به این‌که این کار همچنان ادامه دارد و تحولات بیشتری در ذخیره‌سازی در دست برنامه‌ریزی است پایان می‌یابد؛ فهرست طرح‌های آتی در این خلاصه بازتولید نشده و در منبع اصلی موجود است.

منابع

Next step

اوریکس را روی سناریوی واقعی شبکه‌ی خودتان ببینید.

در جلسه‌ی دمو، به‌جای ارائه‌ی عمومی، یک سناریوی واقعی از محیط شما را بررسی می‌کنیم: یک تغییر پرریسک، یک رخداد اخیر، یا حجم لاگی که تیم شما هر روز با آن روبه‌روست.