تصور کنید هزاران پردازنده گرافیکی روی یک مدل با میلیاردها پارامتر کار میکنند و ناگهان یکی از آنها میسوزد؛ در حالت عادی، تمام محاسبات چند هزار دلاری شما در یک لحظه به زباله میرود. اما اکنون این کابوس برای مهندسان زیرساخت در حال پایان است.
طبق اعلام رسمی PyTorch در ۲۵ ژوئیه ۲۰۲۶، ادغام runtime Monarch با پردازندههای گرافیکی (GPU) — سختافزارهای قدرتمندی که مثل موتورهای جت، حجم عظیمی از داده را همزمان پردازش میکنند — در اکوسیستم AMD و از طریق دستیار نرمافزاری (ROCm) عملی شد. این تغییر به این معناست که حتی اگر تعدادی از گرههای محاسباتی سقوط کنند، روند آموزش متوقف نمیشود.
همانطور که در تحلیلهای پیشین ما دربارهی پایداری مراکز داده اشاره کردیم، روشهای سنتی بر پایه نقطه بازرسی (Checkpoint) بودند؛ یعنی هر چند وقت یکبار تمام وضعیت مدل ذخیره میشد. اگر یک GPU خراب میشد، کل خوشه متوقف شده و از آخرین نقطه ذخیره میگشت — درست مثل یک پروژه گروهی که اگر یک نفر یادداشتهایش را گم کند، همه مجبور شوند کارهای هفته پیش را دوباره انجام دهند. این چالشهای مربوط به مدیریت وضعیت حافظه و سرعت بازیابی، مشابه نکاتی است که در بهینهسازی زمان راهاندازی GPUها توسط سیستم اسنپشات Cerebrium بررسی کرده بودیم.
PyTorch Monarch این مدل خشک را با یک زمانبندی مبتنی بر Actor جایگزین کرد. این سیستم اجازه میدهد توسعهدهندگان کل خوشههای GPU را از طریق یک برنامه پایتون مدیریت کنند و استراتژی موازیسازی را از مکانیسم تحمل خطا جدا کنند. در نتیجه، سقوطها در پایینترین سطح ممکن ایزوله شده و دیگر باعث خاموشی کلی نمیشوند.
به نقل از مستندات فنی این پروژه، انتقال این سیستم به سختافزار AMD نیازمند تلاش مهندسی گستردهای بود. تیم توسعه از ابزار hipify_torch برای تبدیل کدهای C++ از CUDA به HIP استفاده کرد و آن را به RCCL متصل نمود تا با استانداردهای انویدیا همراستا باشد.
مدیریت حافظه نیز توسط یک سیستم ساخت (Build System) بهروزرسانیشده انجام شد که پلتفرم را شناسایی کرده و فراخوانهای درایور CUDA را به معادلهای HIP هدایت میکند. برای دسترسی مستقیم به حافظه از راه دور (RDMA)، مسیر libibverbs حفظ شد تا سرعت انتقال دادهها در سطح حداکثری باقی بماند.
برای حفظ سازگاری با Rust، توسعهدهندگان ماژول rocm_compat را ساختند. این لایه واسط، نمادهای HIP را تحت نامهای CUDA بازخروجی میکند تا کد هسته Rust نسبت به پلتفرم بیتفاوت باشد. طبق گزارش تیم فنی، تمامی ۱٬۱۷۱ تست با موفقیت پاس شدند و پشتیبانی کامل از ROCm 7.0+ تأیید شد.
برای اثبات کارایی، این سیستم با موتور آموزش TorchTitan و لایه تحمل خطای TorchFT ادغام شد. این معماری سهلایه محیطی «بدون نقطه بازرسی» ایجاد میکند:
- Monarch: مدیریت سازماندهی خوشه و ایجاد ReplicaActors.
- TorchFT: هماهنگی حد نصاب (Quorum) و نادیده گرفتن گرههای خراب هنگام همگامسازی.
- TorchTitan: اجرای عملیات رفت و برگشتی (Forward/Backward) در مدل FSDP.
در جریان بازیابی، وقتی یک پردازش GPU سقوط میکند، ناظر Monarch فوراً خطا را ثبت میکند. در حالی که گره خراب در حال ریبوت است، سایر نسخههای سالم به آموزش مستقل خود ادامه میدهند.
سپس فرآیندی به نام «انتقال نقطه بازرسی همتا» (Peer Checkpoint Transfer) آغاز میشود. یک گره سالم — به عنوان اهداکننده — وضعیت فعلی مدل و بهینهساز (Optimizer) را مستقیماً به گره در حال بازیابی منتقل میکند. خوشه تنها برای لحظهای کوتاه متوقف میشود تا حد نصاب جدید شکل بگیرد و سپس با سرعت کامل به همگامسازی بازمیگردد.
اعتبارسنجی این سیستم روی خوشههای AMD Instinct MI300 انجام شد. در یک خوشه ۱۶ گرهی با ۱۲۸ پردازنده گرافیکی، تیم هر ۱۸۰ ثانیه یک شکست RCCL تزریق کرد در حالی که مدل Llama 3 8B در حال آموزش بود. منحنی زیان (Loss Curve) کاملاً پایدار ماند و سیستم بهطور پویا بین ۸ تا ۱۶ کارگر فعال نوسان کرد بدون اینکه نیاز به شروع مجدد باشد.
با گسترش مقیاس به یک خوشه ۳۲ گرهی کوبرنتیز با ۲۵۶ پردازنده MI355، پایداری بالایی مشاهده شد. کاهش میانگین زیان جهانی از ۱۲ به حدود ۴، ثابت کرد که این مدل تحمل خطا در مقیاسهای بزرگ و با ارکستراتورهای مختلف کار میکند.
این ادغام پیشفرض قدیمی را که آموزشهای مقیاسبزرگ AI باید «شکننده» باشند، تغییر میدهد. با حرکت از نقاط بازرسی سراسری به سمت بازیابی محلی و مبتنی بر Actor، صنعت میتواند بهرهوری GPU را به حداکثر برساند و هزینههای هنگفت ناشی از اتلاف محاسبات را کاهش دهد.
برای مهندسان، این یعنی «هزینه شکست» دیگر یک مالیات خطی روی اندازه خوشه نیست. تمرکز از «اجتناب از سقوط» به «مدیریت سیستمی که با وقار تخریب شده و خود را ترمیم میکند» منتقل میشود.
گام بعدی شما
- اگر از زیرساختهای AMD استفاده میکنید، مستندات ROCm 7.0 را برای فعالسازی قابلیتهای Monarch بررسی کنید.
- استراتژیهای Checkpointing خود را بازبینی کنید تا بفهمید کجا میتوان هزینه ذخیرهسازی را با بازیابی همتا جایگزین کرد.
- در صورت استفاده از TorchTitan، لایه TorchFT را برای مدیریت گرههای نامطمئن در خوشههای بزرگ پیادهسازی نمایید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو