۱۶ پردازنده RTX PRO 6000 پایداری زیرساخت توزیع‌شده Megatron را تأیید کرد

کنترل دقیق توپولوژی یک خوشه GPU، مرز میان یک عرضه موفق مدل و فروپاشی فاجعه‌بار حافظه است. در ۶ جولای ۲۰۲۶، مجموعه‌ای از تست‌های دوده‌ای (smoke tests) لایه زیرساختی یک خوشه ۲ گره‌ای شامل ۱۶ پردازنده RTX PRO 6000 Blackwell را تأیید کرد و ثابت کرد که آموزش توزیع‌شده برای مدل‌های ترکیب خبره‌ها (Mixture-of-Experts یا MoE) به چیزی فراتر از توان محاسباتی خام نیاز دارد.

بسیاری از توسعه‌دهندگان با آموزش توزیع‌شده مانند یک جعبه سیاه برخورد می‌کنند و به ابزارهای خودکار مثل FSDP تکیه می‌کنند. اما برای مدل‌های با پارامتر بالا و مسیریابی پیچیده، کنترل صریح بر نحوه تقسیم تنسورها و لایه‌ها روی سخت‌افزار غیرقابل‌بحث است. این چالش‌های مدیریتی در مقیاس توزیع‌شده، ضرورت توسعه‌ی رویکردهایی مانند ساده‌سازی موازی‌سازی توزیع‌شده از طریق مدل‌های گراف Directed Acyclic Graph (DAG) را بیش از پیش آشکار می‌کند. تمرکز این پروژه بر «قرارداد زیرساختی» بود: اطمینان از اینکه مدل‌ها می‌توانند بدون خطاهای NaN یا شکست در همگام‌سازی، تبدیل، تقسیم، آموزش و ذخیره شوند.

به نقل از گزارش منتشر شده در dev.to، هدف این پروژه کیفیت نهایی مدل نبود، بلکه تأیید پشته توزیع‌شده بود. کیفیت مدل به داده‌ها، دستورالعمل‌ها، ابرپارامترها، ارزیابی‌ها، بودجه توکن و تکرار تحلیل‌های حذف-و-اضافه (ablations) بستگی دارد. در مقابل، این تست‌ها بررسی کردند که آیا پشته آموزش توزیع‌شده از نظر راه‌اندازی، ساخت مدل، وارد کردن نقطه بازرسی (Checkpoint)، باز-تقسیم (resharding)، کاهش گرادیان مستقیم/معکوس، نبود NaNs و ذخیره نقاط بازرسی به‌درستی عمل می‌کند یا خیر.

به عبارت دیگر، پرسش اصلی این بود: آیا یک مدل می‌تواند تبدیل شده، روی GPUها تقسیم شود، برای چند گام آموزش ببیند، به‌درستی همگام شود، ذخیره گردد و سپس به‌عنوان پایه‌ای برای پیش‌آموزش (Pretraining) مستمر یا تنظیم نظارت‌شده (SFT) استفاده شود؟

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

• گره‌ها: ۲ گره در مجموع.
• محاسبات: ۸ پردازنده RTX PRO 6000 Blackwell در هر گره (مجموعاً ۱۶ پردازنده).
• ذخیره‌سازی: استفاده از NVMe محلی هر گره برای مجموعه‌داده‌ها، نقاط بازرسی و لاگ‌ها.
• شبکه: شبکه خصوصی بین‌گره‌ای اختصاصی برای NCCL و آموزش توزیع‌شده.

استراتژی تست بر اساس مقیاس تغییر می‌کرد. اکثر تست‌های مدل‌های بزرگتر روی یک گره ۸ پردازنده‌ای رایگان اجرا شدند، اما اجرای مدل Public WikiText 5D از تمام ظرفیت هر دو گره و هر ۱۶ پردازنده استفاده کرد.

معماری پشته نرم‌افزاری

محیط آموزش بر یک رویکرد لایه‌ای برای پر کردن شکاف بین فرمت‌های عمومی مدل و زمان‌های اجرای توزیع‌شده متکی بود:

• Megatron-LM: به‌عنوان زمان اجرای اصلی آموزش، مدیریت اسکریپت‌های راه‌اندازی، گروه‌های موازی مدل، بهینه‌ساز توزیع‌شده و جریان نقاط بازرسی را بر عهده داشت.
• Megatron-Bridge: به‌عنوان لایه ترجمه حیاتی عمل کرد. این ابزار اسنپ‌شات‌های Hugging Face را به فرمت‌های نقطه بازرسی سازگار با Megatron تبدیل کرد. این لایه جزئیات معماری خاصی مانند مسیریابی MoE، چیدمان خبره‌ها، انواع مدل‌های توجه، بلوک‌های Mamba، فایل‌های توکن‌ساز، پیکربندی دقت (precision) و چیدمان موازی‌سازی هدف را مدیریت نمود.
• Megatron-Core: پیش‌نیازهای (primitives) موازی‌سازی تنسور، خط‌لوله، زمینه، خبره و توالی را فراهم کرد که توسط مدل‌ها استفاده می‌شوند.
• Transformer Engine: هسته‌های بهینه ترنسفورمر، مسیرهای FP8، هسته‌های توجه و هم‌پوشانی ارتباطات (communication overlap) را ارائه داد.
• NCCL: جمع‌آوری‌های GPU را که برای موازی‌سازی تنسور، داده، مسیریابی خبره و ارتباطات چندگره ضروری است، مدیریت کرد.
• Torch Distributed Checkpointing: ذخیره/بارگذاری نقاط بازرسی تکه‌شده (sharded) و باز-تقسیم آن‌ها را در چیدمان‌های مختلف هندل کرد.
• Hugging Face Integration: دانلود مدل‌های عمومی و توکن‌سازها و وارد کردن اولیه نقطه بازرسی را مدیریت نمود.
• مسیرهای دقت: این پشته از دقت‌های BF16، FP8 و MXFP8 پشتیبانی می‌کرد.

نحوه اتصال قطعات

این پشته سه لایه اصلی را برای تضمین انتقال پایدار از یک فایل وزن عمومی به یک فرآیند آموزش توزیع‌شده حفظ می‌کند. اول، فرمت منبع مدل که معمولاً با اسنپ‌شات‌های Hugging Face شروع می‌شود. در حالی که این فرمت برای استنتاج (inference) راحت است، اما چیدمانی نیست که Megatron برای آموزش توزیع‌شده از آن استفاده می‌کند.

دوم، لایه تبدیل و ارائه‌دهنده مدل (از طریق Megatron-Bridge) این اسنپ‌شات‌ها را به فرمت داخلی Megatron نگاشت می‌کند. اینجا جایی است که متخصصان چیدمان موازی‌سازی (مانند TP=2, PP=2 یا EP=4) را تعریف می‌کنند. در نهایت، لایه آموزش توزیع‌شده (Megatron-LM/Core) مدل را با استفاده از گروه‌های موازی صریح آموزش می‌دهد.

جریان عملیاتی یک خط لوله خطی را دنبال می‌کند: مدل/توکن‌ساز Hugging Face $ \rightarrow $ وارد کردن/ارائه‌دهنده مدل Megatron-Bridge $ \rightarrow $ نقطه بازرسی فرمت Megatron $ \rightarrow $ راه‌اندازی توزیع‌شده Megatron $ \rightarrow $ آموزش $ \rightarrow $ اعتبارسنجی $ \rightarrow $ ذخیره نقطه بازرسی $ \rightarrow $ بررسی لاگ‌ها.

مدل ذهنی موازی‌سازی

دلیل استفاده از Megatron، امکان دسترسی مستقیم به چندین محور موازی‌سازی است. این محورها ضرب ساده نیستند؛ یک اندازه جهانی (world size) از نظر ریاضی معتبر ممکن است به‌دلیل تعداد لایه‌ها، در دسترس نبودن هسته یا فشار حافظه شکست بخورد.

• موازی‌سازی تنسور (TP): عملیات تنسورهای متراکم را درون لایه‌ها تقسیم می‌کند. این کار حافظه و محاسبات هر GPU را برای عملیات ماتریسی بزرگ کاهش می‌دهد.
• موازی‌سازی خط‌لوله (PP): لایه‌های مدل را روی مراحل خط‌لوله تقسیم می‌کند، به گونه‌ای که GPUهای مختلف بلوک‌های لایه متفاوتی را نگه دارند.
• موازی‌سازی زمینه (CP): توکن‌های توالی/زمینه بلند را تقسیم می‌کند و آموزش با زمینه‌های طولانی‌تر را ممکن می‌سازد.
• موازی‌سازی داده (DP): دسته‌های داده را روی گروه‌های مدل تکثیر شده تقسیم می‌کند تا توان عملیاتی افزایش یابد و گرادیان‌ها همگام شوند.
• موازی‌سازی خبره (EP): خبره‌های MoE را روی GPUها توزیع می‌کند تا از ذخیره تمام خبره‌ها در هر GPU جلوگیری شود.
• موازی‌سازی تنسور خبره (ETP): وزن‌های درون هر خبره مجزا را تکه‌تکه می‌کند؛ این کار زمانی مفید است که خبره‌ها بیش از حد بزرگ باشند.
• موازی‌سازی داده خبره (EDP): توان عملیاتی موازی‌سازی داده را برای گروه‌های خبره اضافه می‌کند.
• موازی‌سازی توالی (SP): حافظه فعال‌سازی (activation memory) را درون گروه‌های موازی-تنسور ذخیره می‌کند بدون اینکه بعد جدیدی به اندازه جهانی اضافه کند.

اعتبارسنجی مدل‌ها و نتایج تجربی

بر اساس مستندات پروژه، یک اجرای موفق «تست دوده‌ای» مستلزم مقداردهی اولیه گروه فرآیند توزیع‌شده در تمام رتبه‌ها، ساخت مدل با چیدمان درخواستی، شناسایی مسیرهای داده در هر گره، گذر مستقیم بدون خطای ابعاد، یک گذر معکوس کامل و همگام‌سازی گرادیان، نبود NaNs و نوشتن موفق نقطه بازرسی توزیع‌شده بود.

DeepSeek-V2-Lite (۱۶ میلیارد پارامتر / ۲.۴ میلیارد فعال)
این مدل مسیرهای وارد کردن و FP8 را تأیید کرد. حجم اسنپ‌شات/نقطه بازرسی حدود ۳۰ گیگابایت بود. یک کشف کلیدی این بود که PP=2 به دلیل وجود ۲۷ لایه در مدل، نیازمند تقسیم نابرابر لایه‌ها بود؛ تیم از FIRST_PP_LAYERS=14 و LAST_PP_LAYERS=13 استفاده کرد. در حالی که مسیرهای BF16 و FP8 با تأخیر پاس شدند، مسیر توجه MLA با یک مشکل بک‌اند مواجه شد که CP=2 را مسدود کرد.

Nemotron-3-Nano (۳۰ میلیارد پارامتر / ۳ میلیارد فعال)
این مدل ترکیبی MoE-Mamba2-Transformer ثابت کرد که PP=2 یک ابزار حیاتی برای مدیریت حافظه است. چیدمان‌های خالص TP+EP برای محیط عملیاتی بیش از حد فشرده بودند، اما موازی‌سازی خط‌لوله فضای خالی (headroom) لازم را ایجاد کرد. به‌دلیل عدم نصب causal-conv1d مسیر سریع Mamba غیرفعال شد و به مسیر کندتر بازگشت. همچنین UB_SKIPMC=1 برای حل تداخل CUDA multicast در Transformer Engine برای TP=2 لازم بود.

Public WikiText 5D (اجرای ۱۶ پردازنده)
این تست از ۲ گره و ۱۶ GPU با یک مدل کنترلی شامل ۴ لایه، اندازه پنهان ۲۵۶ و FFN ۵۱۲ استفاده کرد. چیدمان متراکم TP=2, PP=2, CP=2, DP=2 و چیدمان خبره ETP=1, EP=4, EDP=2, PP=2 به کار گرفته شد. در حالت BF16 با FlashAttention، ۲۰ تکرار انجام شد و نقاط بازرسی در تکرار ۱۰ و ۲۰ ذخیره شدند. حافظه بسیار پایین ماند و در رتبه‌های مشاهده شده زیر ۰.۹ گیگابایت بود.

DeepSeek-V4-Flash
این هدف به تنظیمات توزیع‌شده Megatron و بررسی مسیر MXFP8 رسید، اما در یک گره ۸ پردازنده‌ای ۹۶ گیگابایتی جا نشد که تأییدکننده «دیوار حافظه» برای این مقیاس خاص از مدل بود.

مشاهدات حافظه زمان اجرا

لاگ‌های حافظه Rank-0 دلیل ضرورت چیدمان‌های خاص را روشن کرد:

• DeepSeek-V2-Lite (EP=8, BF16): ۴۲.۶ تا ۴۳.۲ گیگابایت رزرو شد. این خط پایه به‌راحتی روی یک گره ۸ پردازنده‌ای جا شد.
• DeepSeek-V2-Lite (TP=2, PP=2, EP=2, SP, BF16/FP8): ۳۷ تا ۴۱ گیگابایت رزرو شد. PP نابرابر با TP/EP شکل حافظه بهتری نسبت به حالت EP-only ایجاد کرد.
• Nemotron-3-Nano (EP=8, BF16): ۸۲.۹ تا ۸۵.۹ گیگابایت رزرو شد. مدل ترکیبی Mamba/MoE جا شد اما حافظه بسیار بیشتری مصرف کرد.
• Nemotron-3-Nano (PP=2, EP=4, BF16): ۷۳.۵ گیگابایت رزرو شد. PP فضای خالی ضروری را فراهم کرد.
• Nemotron-3-Nano (TP=2, EP=4, SP, BF16): ۹۸.۷ گیگابایت رزرو شد. این حالت عمل کرد اما برای یک چیدمان تولیدی پایدار بیش از حد فشرده بود.

گلوگاه‌های زیرساختی و اصلاحات

این فرآیند چندین حالت شکست بحرانی را آشکار کرد و نیازمند مداخلات فنی خاصی بود:

• مسائل مجموعه‌داده و محیط: فایل‌های کش GPTDataset در یک گره بود اما در دیگری نبود. اصلاح: استقرار مجموعه‌داده‌ها و توکن‌سازها در مسیرهای مطلق یکسان در هر دو گره و ساخت کش‌های محلی در هر یک.

• محیط پایتون: یک کمکی مجموعه‌داده ممکن بود محیط پایتون اشتباه را انتخاب کند. اصلاح: افزودن یک لایه لانچر (shim) برای اطمینان از اینکه بیلد‌های کمکی از محیط مجازی مورد نظر و pybind11 include استفاده می‌کنند.

• وارد کردن‌های اختیاری: دستورالعمل‌های Bridge بسته‌های غیرضروری مثل diffusers و nvidia_resiliency_ext را فراخوانی می‌کردند. اصلاح: استفاده از بارگذاری‌های محدودتر دستورالعمل‌ها و استاب‌های (stubs) کوچک.

• نقاط بازرسی و باز-تقسیم: جریان وارد کردن نیاز به یک مرحله تبدیل Hugging Face به Megatron پیش از آموزش داشت که برای DeepSeek-V2-Lite تأیید شد. باز-تقسیم Megatron برای اجراهای موفق عمل کرد، زیرا TP/PP زمان اجرا اغلب با چیدمان وارد کردن متفاوت بود.

• ازسرگیری چندگره: در حالی که آموزش/ذخیره/ارزیابی تازه عمل می‌کرد، ازسرگیری از یک نقطه بازرسی محلی گره موقت، پس از بارگذاری متادیتا با Timeout مواجه شد. این مورد هنوز حل نشده و احتمالاً نیاز به یک نمای نقطه بازرسی پایدار مشترک دارد.

• بلاک‌های خاص معماری: لایه‌های DeepSeek-V2-Lite نیازمند تقسیم نابرابر ۱۴/۱۳ بود. موازی‌سازی زمینه (CP=2) در مدل GPT سفارشی و Nemotron تأیید شد اما برای DeepSeek MLA مسدود ماند. مسیر Mamba به دلیل نبود causal-conv1d غیرفعال شد.

تحلیل تحریریه

این آزمایش گفتگو را از «آیا می‌توانیم این مدل را آموزش دهیم؟» به «چگونه تقسیم را کنترل کنیم؟» تغییر می‌دهد. مهم‌ترین دستاورد، نقش Megatron-Bridge است. با تبدیل تبدیل مدل و چیدمان نقاط بازرسی به بخشی از سیستم آموزش (به جای یک مرحله پیش‌پردازش)، توسعه‌دهندگان می‌توانند از تله رایج «عدم تطابق زمان اجرا» که در آن چیدمان وارد کردن با چیدمان آموزش متفاوت است، اجتناب کنند.

علاوه بر این، نتایج Nemotron-3-Nano ثابت می‌کند که موازی‌سازی خط‌لوله (PP) صرفاً یک بهینه‌سازی برای توان عملیاتی نیست. در معماری‌های ترکیبی MoE، مقدار PP یک ابزار مدیریت حافظه اولیه است. بدون آن، حتی GPUهای پیشرفته Blackwell هنگام مواجهه با خبره‌های مسیریابی پیچیده و وضعیت‌های بهینه‌ساز (optimizer states)، با دیوار حافظه برخورد می‌کنند. این موضوع تأکید می‌کند که در مدل‌های MoE، مدیریت بهینه حافظه کلید است، مشابه آنچه در رویکردهای طراحی ترکیبی CPU-GPU برای حذف نیاز به کوانتیزه‌سازی دیده می‌شود.

برای متخصصان، این ثابت می‌کند که «تست‌های دوده‌ای» (اجراهای کوتاهی که کل مسیر زیرساختی از لانچ توزیع‌شده تا ذخیره نقطه بازرسی را اعتبارسنجی می‌کنند)، تنها راه تأیید قرارداد توزیع‌شده پیش از تخصیص بودجه‌های عظیم توکن به یک اجرای آموزشی است. برای بررسی عمیق‌تر مسیریابی MoE یا تعامل بین TP و SP، باید به‌روزرسانی‌های اخیر primitives در Megatron-Core یا پیاده‌سازی تقسیم نابرابر خط‌لوله برای مدل‌های با تعداد لایه فرد را تحلیل کرد.

• بررسی پیاده‌سازی تقسیم نابرابر خط‌لوله (uneven pipeline splitting) برای مدل‌هایی با تعداد لایه‌های فرد.
• تحلیل به‌روزرسانی‌های اخیر primitives در Megatron-Core برای درک عمیق‌تر تعامل بین TP و SP.
• تست مسیرهای MXFP8 در مدل‌های مقیاس کوچک‌تر پیش از ورود به دیوار حافظه در مدل‌های غول‌آسا.

این تنها آغاز ماجراست؛ اثر موج‌گونه‌ی این تصمیم بر اکوسیستم متن‌باز را در گزارش بعدی بررسی خواهیم کرد.