پیش از انتخاب GPU وقفه‌پذیر، ادامه آموزش را آزمایش کنید

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

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

برای هشدار خاموشی، نقش کمکی تعریف کنید

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

مستندات AWS برای توقف یا خاتمه نمونه Spot از هشدار دو دقیقه‌ای می‌گوید، اما تحویل هشدار را بهترین‌تلاش توصیف می‌کند. در حالت خواب زمستانی، آن فرصت دو دقیقه‌ای وجود ندارد و فرایند بلافاصله آغاز می‌شود.

راهنمای Google Cloud میان فاصله اعلام وقفه و دوره خاموشی فرق می‌گذارد: فاصله پیش‌فرض صفر است و دوره خاموشی، بهترین‌تلاش و حداکثر ۳۰ ثانیه است. گزینه فاصله ۱۲۰ ثانیه‌ای نیز مستند شده است. تنظیم واقعی ماشین را بررسی کنید؛ یک عدد را قرارداد همه ارائه‌دهندگان ندانید.

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

دقیقاً چه چیزی را می‌خواهید ادامه دهید؟

سه خواسته را جدا کنید: استفاده از وزن‌ها برای پاسخ‌دادن، شروع آزمایشی تازه از وزن‌های قبلی، و ادامه اجرای قطع‌شده. هر سه کار مشروع‌اند، اما قرارداد یکسان ندارند. اگر بهینه‌ساز را عمداً از نو می‌سازید، آن را آزمایش تازه ثبت کنید؛ برچسب «ادامه» نباید تغییر روش آموزش را پنهان کند.

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

پیشنهاد ما این فهرست وابسته به نوع اجراست. هر ردیف باید یا ذخیره شود، یا روش بازسازی آزموده‌شده داشته باشد، یا با دلیل روشن نامربوط اعلام شود:

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

موقعیت داده را با شماره دور اشتباه نگیرید

شماره دور آموزش نمی‌گوید در میانه آن دور کدام نمونه‌ها مصرف شده‌اند. اگر ترتیب داده تصادفی است، ثبت عدد گام بدون حفظ یا بازسازی ترتیب نیز کافی نیست. در جریان داده‌ای که مرتب تغییر می‌کند، «از نمونه بعدی» حتی ممکن است معنای ثابتی نداشته باشد. نسخه ورودی و قاعده ادامه باید مشخص باشند.

در مرجع Trainer نسخه ۵٫۰٫۰، گزینه save_only_model وضعیت بهینه‌ساز، برنامه نرخ یادگیری و مولد تصادفی را کنار می‌گذارد و برای ادامه آموزش کافی نیست. همان مرجع هشدار می‌دهد که ignore_data_skip=True ادامه را سریع‌تر آغاز می‌کند، ولی نتیجه اجرای قطع‌شده را حفظ نمی‌کند.

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

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

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

فقط نسخه کامل را به‌عنوان آخرین ذخیره معرفی کنید

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

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

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

حداقل یک نسخه کامل قبلی را تا تأیید جانشین نگه دارید. محل ماندگار نیز باید بیرون از دامنه خرابی فرض‌شده باشد: پوشه‌ای روی همان دیسک ازدست‌رفتنی، پشتیبان خرابی آن دیسک نیست. بحث نقاط سازگار بازیابی سامانه برای انتخاب این مرز مفید است؛ این مقاله مرز را به فرایند آموزش محدود می‌کند.

آزمون را در یک فرایند تازه انجام دهید

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

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

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

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

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

در مثال ۳۰۰ گامی، ذخیره ناقص را حساب نکنید

فرض کنید اجرای آموزشی به گام ۳۰۰ رسیده، بسته گام ۲۴۰ کامل است و نوشتن بسته گام ۲۸۰ نیمه‌تمام مانده است. ماشین از دست می‌رود. اگر قرارداد ادامه سالم باشد، نقطه مجاز بازگشت گام ۲۴۰ است و ۶۰ گام باید دوباره محاسبه شود؛ نه ۲۰ گام. این اعداد نمونه آموزشی‌اند، نه نتیجه سنجش ژرف.

پیش از آغاز محاسبه تازه، بازیاب باید شناسه بسته ۲۴۰، نسخه داده و محیط مورد انتظار را نشان دهد. سپس وضعیت آموزش و موقعیت داده را برگرداند. گام ۲۴۱ نخستین کار بعدی است؛ شماره ۳۰۱ روی یک شمارنده، بدون وضعیت متناظر، ادامه واقعی نمی‌سازد.

حالا فرض کنید فایل وزن‌های گام ۲۸۰ سالم است، اما وضعیت بهینه‌ساز آن وجود ندارد. تیم شاید بخواهد آزمایش تازه‌ای از آن وزن‌ها شروع کند. این انتخاب را با شناسه و توضیح تازه ثبت کند و آن را با ادامه اجرای اصلی یکی نگیرد. قابلیت استفاده از وزن‌ها با حفظ مسیر آموزش فرق دارد.

این مثال آزمون پذیرش خوبی هم می‌سازد: نسخه جدید ناقص باید کنار گذاشته شود، نسخه قبلی قابل‌خواندن بماند و گزارش اتلاف، ۶۰ گام را نشان دهد. اگر ابزار فقط تازه‌ترین نام فایل را انتخاب کند، همین آزمون ساده ضعف تصمیم آن را آشکار می‌کند.

بازگشت درست را از برابری عددی کامل جدا کنید

یادداشت بازتولیدپذیری PyTorch 2.15 برابری کامل نتایج را میان نسخه‌ها، سکوها یا اجرای پردازنده و GPU تضمین نمی‌کند، حتی با بذر یکسان. پس معیار آزمون را پیش از دیدن نتیجه تعیین کنید؛ هر تفاوت کوچکی خرابی بازیابی نیست و هر زیان نزدیک هم سلامت آن را ثابت نمی‌کند.

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

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

هزینه را به پیشرفت پذیرفته‌شده وصل کنید

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

در مثال بودجه‌ای فرض کنید اجرای عادی ۱۰ ساعت زمان می‌برد. برای یک پیشنهاد فرضی، نرخ ساعتی ظرفیت وقفه‌پذیر نصف است، اما ذخیره، راه‌اندازی و محاسبه تکراری زمان صورتحساب را به ۱۴ ساعت می‌رساند. هزینه محاسبه معادل ۷ ساعت با نرخ عادی خواهد بود، یعنی ۳۰ درصد کمتر، نه ۵۰ درصد. هزینه ذخیره و انتقال هنوز باید افزوده شود.

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

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

نتیجه آزمون باید انتخاب ظرفیت را تغییر دهد

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

پس از هر تغییر مهم، شاهد تازه بگیرید

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

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

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

یادداشت منابع — بازبینی ۲۹ اکتبر ۲۰۲۶

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

• PyTorch؛ ذخیره و بارگذاری مدل — آموزش زنده؛ وضعیت مدل و بهینه‌ساز.
• Hugging Face؛ Trainer نسخه ۵٫۰٫۰ — مثال نسخه‌دار برای گزینه‌های ذخیره و ادامه؛ نه ادعای آخرین نسخه.
• AWS؛ هشدار وقفه Spot — مستندات جاری؛ محدودیت هشدار.
• Google Cloud؛ ماشین‌های Spot — مستندات جاری؛ تنظیم اعلام وقفه، خاموشی و دسترسی به ظرفیت.
• PyTorch 2.15؛ بازتولیدپذیری — صفحه با تاریخ به‌روزرسانی ۱۴ مه ۲۰۲۶؛ حدود تکرارپذیری عددی.