ابررایانه‌های هوش مصنوعی چگونه آموزش مدل‌های بزرگ را ممکن می‌کنند؟

گلوگاه فقط تعداد پردازنده نیست

آموزش مدل بزرگ یک مسئله سامانه‌ای است. شتاب‌دهنده‌ها باید داده را از حافظه دریافت کنند، گرادیان‌ها را میان گره‌ها مبادله کنند و در هر مرحله با یکدیگر همگام شوند. اگر شبکه میان سرورها کند باشد یا بارگذاری داده عقب بماند، افزایش تعداد GPU الزاماً زمان آموزش را به همان نسبت کاهش نمی‌دهد. پهنای باند حافظه، ارتباط بین‌پردازنده‌ای، ذخیره‌سازی، نرم‌افزار زمان‌بندی و نرخ استفاده واقعی همگی در کارایی مؤثرند.

برای مقایسه زیرساخت‌ها باید معیار را به مسئله کسب‌وکار پیوند داد. زمان رسیدن به نتیجه، هزینه هر آزمایش موفق، انرژی مصرفی، نرخ استفاده از شتاب‌دهنده و هزینه نگه‌داری از تعداد تراشه مهم‌ترند. آموزش از صفر نیز همیشه لازم نیست؛ تنظیم دقیق، بازیابی اطلاعات، تقطیر مدل یا استفاده از مدل کوچک‌تر می‌تواند با هزینه کمتر نیاز را برطرف کند. انتخاب سخت‌افزار باید بعد از اندازه‌گیری بارکاری واقعی انجام شود.

معیارهای سنجش عملکرد و هزینه

در یک پروژه واقعی، بهتر است ابتدا دامنه کاربرد محدود و معیار پذیرش روشن تعریف شود. خط مبنا باید پیش از اجرای راهکار ثبت شود تا بتوان تغییر عملکرد را با وضعیت قبلی مقایسه کرد. آزمایش کنترل‌شده، ثبت نسخه نرم‌افزار و داده ورودی و مستندسازی شرایط اجرا، نتیجه را قابل تکرار می‌کند.

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

معماری زیرساخت آموزش مدل‌های بزرگ

ابررایانش هوش مصنوعی یک سامانه کامل است، نه صرفاً مجموعه‌ای از GPUها. شتاب‌دهنده‌ها باید داده را از حافظه دریافت کنند، محاسبات ماتریسی را اجرا کنند و در آموزش توزیع‌شده گرادیان‌ها یا پارامترها را میان گره‌ها مبادله کنند. اگر شبکه، ذخیره‌سازی یا ورودی داده گلوگاه باشد، افزودن پردازنده بازده محدودی خواهد داشت.

سه الگوی موازی‌سازی پرکاربردند. در موازی‌سازی داده، نسخه‌ای از مدل روی چند دستگاه قرار می‌گیرد و هر دستگاه بخش متفاوتی از داده را پردازش می‌کند. در موازی‌سازی مدل، لایه‌ها یا بخش‌های بزرگ مدل میان دستگاه‌ها تقسیم می‌شوند. در pipeline parallelism مراحل محاسبه به صورت خط لوله اجرا می‌شوند. ترکیب این روش‌ها برای مدل‌های بزرگ رایج است، اما هماهنگی و سربار ارتباطی را افزایش می‌دهد.

حافظه شتاب‌دهنده یکی از محدودیت‌های اصلی است. وزن‌های مدل، فعال‌سازی‌ها، گرادیان‌ها و وضعیت بهینه‌ساز همگی حافظه مصرف می‌کنند. دقت عددی پایین‌تر، checkpointing، offloading و تقسیم مدل می‌توانند مصرف را کاهش دهند، ولی هر کدام بر دقت، سرعت یا پیچیدگی اثر می‌گذارند. مقایسه باید با بارکاری واقعی انجام شود، نه فقط مشخصات اسمی سخت‌افزار.

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

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

پیش از ساخت خوشه اختصاصی، یک benchmark نماینده از داده و مدل خود اجرا کنید. اندازه batch، طول توالی، روش موازی‌سازی و الگوی دسترسی به داده را ثابت نگه دارید و نتایج را با خط مبنا مقایسه کنید. همچنین برنامه بازیابی checkpoint و تحمل خرابی گره را بیازمایید؛ در آموزش چندروزه، یک خرابی سخت‌افزاری می‌تواند هزینه قابل توجهی ایجاد کند.

برنامه‌ریزی ظرفیت و هزینه برای خوشه هوش مصنوعی

پیش از انتخاب تعداد شتاب‌دهنده‌ها، نوع بارکاری را مشخص کنید. آموزش مدل، fine-tuning، ارزیابی، استنتاج برخط و پردازش دسته‌ای الگوهای متفاوتی از حافظه و ارتباط شبکه دارند. آموزش معمولاً به همگام‌سازی مکرر میان دستگاه‌ها نیاز دارد؛ استنتاج برخط ممکن است به تأخیر پایین و ظرفیت پایدار حساس باشد؛ و پردازش دسته‌ای می‌تواند با زمان‌بندی منعطف‌تر و نرخ بهره‌برداری بالاتر اجرا شود. خرید یک پیکربندی واحد برای همه این وظایف اغلب به استفاده ناکارآمد از منابع منجر می‌شود.

برای تخمین حافظه، وزن‌ها تنها بخش مصرف نیستند. در آموزش باید فعال‌سازی‌ها، گرادیان‌ها و وضعیت optimizer نیز در نظر گرفته شوند. نوع دقت عددی، طول توالی، اندازه batch و معماری مدل بر نیاز حافظه اثر می‌گذارند. در استنتاج، KV cache برای مدل‌های زبانی و طول زمینه می‌تواند سهم بزرگی از حافظه را مصرف کند. بنابراین ظرفیت واقعی باید با بارکاری نماینده و تنظیمات تولیدی اندازه‌گیری شود.

مقیاس‌پذیری خطی را فرض نکنید. دو برابر کردن تعداد GPU الزاماً زمان آموزش را نصف نمی‌کند، زیرا تبادل گرادیان، همگام‌سازی، بارگذاری داده و زمان‌بندی می‌توانند گلوگاه شوند. معیار scaling efficiency نسبت عملکرد واقعی به عملکرد ایده‌آل را نشان می‌دهد. اگر با افزایش گره‌ها بهره‌وری افت کند، باید بررسی کرد مشکل از شبکه، اندازه batch، توزیع داده، موازی‌سازی یا عدم توازن میان گره‌هاست.

شبکه خوشه باید با توپولوژی محاسباتی هماهنگ باشد. پهنای باند اسمی بالا کافی نیست؛ ازدحام، oversubscription، تأخیر و مسیرهای ارتباطی میان گره‌ها نیز اهمیت دارند. در معماری‌های بزرگ، ارتباط جمعی مانند all-reduce می‌تواند بخش مهمی از زمان هر گام آموزش را بگیرد. آزمون شبکه با الگوی واقعی تبادل داده، از اتکا به عدد تبلیغاتی لینک مطمئن‌تر است.

ذخیره‌سازی و جریان داده نیز باید در طراحی دیده شوند. اگر هر epoch با تأخیر در خواندن فایل‌ها آغاز شود، شتاب‌دهنده‌ها بیکار می‌مانند. قالب داده، اندازه shardها، cache محلی، تعداد workerهای بارگذار و throughput ذخیره‌سازی را بررسی کنید. checkpointها باید در بازه‌ای ذخیره شوند که تعادل مناسبی میان هزینه نوشتن و میزان کار ازدست‌رفته در خرابی ایجاد کند. بازیابی از checkpoint را عملاً آزمایش کنید، نه اینکه فقط وجود فایل را بررسی کنید.

در محاسبه هزینه کل مالکیت، قیمت سرور را با برق، سرمایش، رک، شبکه، فضای مرکز داده، نیروی متخصص، پشتیبانی و استهلاک ترکیب کنید. شاخص‌هایی مانند هزینه هر ساعت شتاب‌دهنده، هزینه هر میلیون توکن، انرژی به‌ازای هر درخواست و زمان رسیدن به کیفیت هدف، مقایسه گزینه‌ها را معنادارتر می‌کنند. در برخی پروژه‌ها اجاره ظرفیت ابری برای بارهای نامنظم اقتصادی‌تر است؛ در بار پایدار و قابل پیش‌بینی، زیرساخت اختصاصی ممکن است توجیه پیدا کند.

آزمون پذیرش خوشه باید حداقل سه لایه داشته باشد: سلامت سخت‌افزار و حافظه، عملکرد شبکه و ذخیره‌سازی، و benchmark انتها‌به‌انتها با مدل واقعی. نرخ خطای محاسباتی، خطای حافظه، دمای تجهیزات، مصرف انرژی، utilization و زمان توقف را پایش کنید. برای مقایسه مدل‌ها و سامانه‌ها می‌توان از نتایج و روش‌های MLPerf Training و MLPerf Inference به‌عنوان مرجع استفاده کرد، اما نتیجه نهایی باید با داده و محدودیت‌های خود سازمان سنجیده شود.

در نهایت، ظرفیت‌سنجی را به یک خرید یک‌باره محدود نکنید. نرخ رشد داده، افزایش طول زمینه مدل‌ها، تغییر معماری و تقاضای کاربران می‌تواند نیاز محاسباتی را در چند ماه تغییر دهد. طراحی ماژولار، امکان افزودن گره، تعویض نسل شتاب‌دهنده و جابه‌جایی workload میان محیط‌ها را حفظ می‌کند. زیرساخت موفق فقط سریع‌ترین خوشه نیست، بلکه خوشه‌ای است که در زمان مناسب، با هزینه قابل کنترل و قابلیت اطمینان کافی، خروجی مورد نیاز را تحویل دهد.

نمونه برنامه‌ریزی ظرفیت برای خوشه آموزش هوش مصنوعی

فرض کنید قرار است مدلی با چند میلیارد پارامتر روی چندین شتاب‌دهنده آموزش داده شود. برآورد ظرفیت را با اندازه مدل به‌تنهایی انجام ندهید. وزن‌ها، گرادیان‌ها، وضعیت بهینه‌ساز، فعال‌سازی‌های میانی و بافرهای ارتباطی هم حافظه مصرف می‌کنند. روش دقت عددی، اندازه batch، طول توالی و راهبرد موازی‌سازی می‌توانند نیاز حافظه را به‌طور چشمگیری تغییر دهند.

در موازی‌سازی داده، نسخه‌ای از مدل روی هر شتاب‌دهنده قرار می‌گیرد و batch میان دستگاه‌ها تقسیم می‌شود؛ گرادیان‌ها باید همگام شوند. در موازی‌سازی مدل، بخش‌هایی از شبکه میان دستگاه‌ها توزیع می‌شوند و ارتباط میان لایه‌ها اهمیت پیدا می‌کند. موازی‌سازی pipeline نیز مراحل مدل را در چند گروه قرار می‌دهد، اما ممکن است به دلیل حباب‌های pipeline بخشی از ظرفیت بلااستفاده بماند. انتخاب ترکیب مناسب به معماری مدل و توپولوژی شبکه وابسته است.

شبکه بین شتاب‌دهنده‌ها می‌تواند گلوگاه اصلی باشد. پهنای باند بالا بدون تأخیر پایین و توپولوژی مناسب کافی نیست. ترافیک all-reduce، انتقال فعال‌سازی و هماهنگی میان گره‌ها باید با ابزارهای profiling اندازه‌گیری شود. oversubscription در سوئیچ یا مسیر نامناسب کابل‌کشی ممکن است باعث شود افزایش تعداد GPUها، سرعت آموزش را متناسب افزایش ندهد.

ذخیره‌سازی نیز باید با نرخ تولید checkpoint و بارگذاری داده هماهنگ باشد. اگر چندین worker هم‌زمان فایل‌های کوچک فراوان بخوانند، metadata و عملیات ورودی‌وخروجی می‌تواند محدودکننده شود. قالب داده بهینه، shard مناسب، cache محلی و پیش‌خوانی کنترل‌شده زمان انتظار شتاب‌دهنده را کاهش می‌دهند. checkpoint باید قابل بازیابی باشد و دوره‌ای صحت آن آزمایش شود؛ فایل ذخیره‌شده‌ای که بازیابی نمی‌شود، محافظت واقعی نیست.

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

پیش از توسعه خوشه، یک benchmark نماینده اجرا کنید و زمان هر مرحله را جداگانه اندازه بگیرید: بارگذاری داده، forward، backward، همگام‌سازی، ذخیره checkpoint و ارزیابی. سپس تعداد دستگاه‌ها را افزایش دهید و مقیاس‌پذیری موازی را محاسبه کنید. اگر دو برابر کردن دستگاه‌ها تنها ۱٫۳ برابر سرعت ایجاد می‌کند، باید علت را در ارتباط، حافظه، ورودی‌وخروجی یا اندازه کار جست‌وجو کرد.

برای عملیات پایدار، سلامت GPU، خطاهای حافظه، دمای تجهیزات، مصرف انرژی، نرخ خرابی گره و زمان بازیابی را پایش کنید. زمان‌بندی jobها باید اولویت، سهمیه و قابلیت لغو یا ازسرگیری داشته باشد. طراحی خوشه موفق فقط بیشینه‌کردن تعداد شتاب‌دهنده نیست؛ هدف، انجام کار علمی یا تجاری با کیفیت قابل تکرار و هزینه قابل کنترل است.