Оптимізація витрат на ML-навчання: Spot і Preemptible VMs

Spot-інстанси: чому навчання впирається у простій прискорювачів

Виділені прискорювачі зазвичай замовляють наперед і на довгий інтервал, тому черга на прискорювачі вимірюється днями, а не хвилинами очікування.

Поки ресурс закріплений за одним експериментом, наступний чекає, хоча сам вузол половину вікна не рахує: підготовка даних, очікування попереднього етапу й розбір результатів з'їдають час, за який уже заплачено. Простій обчислювальних вузлів у такій схемі — норма, а не збій.

Переривані інстанси (Spot) знімають обмеження за ціною, але додають своє: платформа забирає вузол за зовнішнім сигналом, і вікно на коректне завершення коротке. Якщо задача не пише контрольні точки, навчання відкочується до останнього вдалого стану або починається заново.

У гіршому разі незавершені задачі навчання просто губляться, і їх перезапускають вручну, звіряючи логи та відновлюючи середовище.

Головна стаття втрат тут — не тариф, а ручний перезапуск. Інженер чергує біля консолі, час до відновлення залежить від того, хто першим помітив збій, а кілька паралельних експериментів конкурують за вузли, що звільнилися.

Вартість навчання моделей зростає через простій і повторно виконану роботу: той самий етап рахується двічі, а черга на прискорювачі при цьому не коротшає.

Розбираємо, як це закривається: керування чергою та пріоритетами між задачами, часте збереження стану, автоматичний перезапуск перерваних задач на вільних вузлах і розподіл ресурсів між експериментами так, щоб простій не оплачувався.

Що змінюється після переходу на переривані потужності

Перша зміна видно вже в першу добу: прискорювачі перестають простоювати в очікуванні, поки звільниться виділений вузол.

Частка прискорювачів, що простоюють, падає з третини до одиниць відсотків — задачі стоять у черзі та займають ємність, що звільнилася, за секунди, а не за години.

За кілька днів змінюється сам характер збоїв. Відкликання вузла перестає бути аварією: контрольні точки стану пишуться кожні кілька хвилин, і навчання продовжується з останньої, а не з нуля.

Планувальник Kubernetes перестворює задачу на іншій машині, розподілене навчання перезбирає робочі групи та підхоплює дані з останньої узгодженої ітерації.

До кінця другого тижня ручні перезапуски перестають бути роботою чергового.

Автоматичний перезапуск із перевіркою цілісності контрольної точки та поверненням у чергу закриває типові відмови без участі людини — кількість ручних втручань у штатних сценаріях падає до нуля, а частка задач, що втратили прогрес під час відкликання вузла, прямує до нуля.

До першого місяця проявляється головний ефект: пропускна здатність навчання зростає в рази на тому самому парку прискорювачів.

Час від гіпотези до метрики скорочується з тижнів до днів, і кількість паралельно запущених експериментів обмежує вже постановка задач, а не доступна інфраструктура.

Spot-інстанси, виділені вузли та гібридний пул

Навчання моделі — це багатогодинні прогони, де ціна простою складається з втраченого прогресу та повторно оплаченого часу. Ключовий параметр вибору майданчика — частота відкликання вузлів: у перериваних вона на порядок вища, у виділених близька до нуля. Далі питання лише в тому, як поєднати дешеву ємність із передбачуваним завершенням прогону.

Кластер Kubernetes розмічає пули: вузли з мітками відкликання приймають лише задачі, що вміють зберігати контрольні точки, виділені несуть стабільне ядро навчання, а черга сама переносить витіснену роботу.

Застосунок отримує сигнал про відкликання заздалегідь і встигає скинути стан в об'єктне сховище, тому доопрацювання коду моделі не потрібне — лише маніфести запуску та політики витіснення.

Основну економію дає гібрид: чорнова частина прогону йде на перериваних вузлах, а обсяг втрачених годин обмежений інтервалом між контрольними точками. Виділений резерв під пік тримає фінальний прогін і не дає зірвати строк, навіть якщо відкликання вузлів ідуть хвилею.

Як ми розгортаємо навчання на перериваних вузлах

Перериваний вузол може піти в будь-який момент — у Spot-пулі це штатна подія, а не аварія. Інженерна задача в тому, щоб втрата вузла не перетворювалася на втрачений прогрес навчання та повторні прогони.

Ідемо послідовно: спочатку вимірюємо профіль навантаження, потім проєктуємо розміщення, далі перевіряємо, як система переживає реальні переривання.

1. Аудит профілю навантаження. Дивимося тривалість кроку, споживання пам'яті, частку часу на обмін даними та терпимість навчання до зупинки. На виході — карта ділянок, які можна віддати перериваній ємності без ризику для збіжності.

2. Схема розміщення задач. Розділяємо ролі: координація, сховище контрольних точок і критичні сервіси залишаються на стабільних вузлах, важкі обчислення — на перериваних. Тоді втрата вузла не зупиняє весь експеримент.

3. Механізм контрольних точок. Періодичність збереження підбираємо під тривалість кроку, стани пишемо атомарно та поза самим вузлом, версіонуємо. Після переривання навчання продовжується з найближчої валідної точки, а не з початку.

4. Регламент реакції на переривання. Визначаємо, скільки чекаємо повернення ємності, як перевикористовуємо вузли, що звільнилися, і коли перемикаємося на стабільний пул, щоб черга експериментів не зупинялася.

5. Перевірка відновлення. Навмисно гасимо вузли під час прогону та заміряємо втрату прогресу, час повернення на попередній темп і частку задач, завершених без ручного втручання.

6. Супровід навчання. Передаємо регламенти чергування та налаштування політики, далі коригуємо їх за фактом — у міру зміни профілю моделей і поведінки пулу.

Конфігурації, політики та регламенти, які ви отримуєте

На виході ви отримуєте не набір розрізнених скриптів, а описаний контур навчання. Його можна передати іншій команді, і вона продовжить роботу без усних пояснень: артефакти фіксують, що вважається нормою і як діяти, коли переривані вузли забирають пачкою.

• Схема пулів — скільки пулів, які типи вузлів у кожному, частки перериваних і постійних машин, розподіл за зонами. Видно, які етапи переживуть одночасне відкликання вузлів.
• Політики вибору вузлів — правила, за якими задача потрапляє на Spot-машини, а критичні кроки залишаються на постійних: пріоритети, обмеження за типом прискорювача, час очікування в черзі.
• Політики доступу — ролі інженерів і сервісних облікових записів, розподіл прав на зміну конфігурацій і на читання логів, порядок ротації ключів.
• Схема зберігання контрольних точок — інтервал збереження, глибина зберігання, розподіл швидкого локального та довгого об'єктного шару, правило очищення за кількістю та віком.
• Регламент відновлення — як навчання піднімається після відкликання вузла, з якої контрольної точки, скільки кроків прогресу втрачається і хто підтверджує повернення в роботу.
• Документація на інфраструктуру — описи пулів, квот, лімітів і точок відмови, порядок внесення змін; лежить у тому самому репозиторії, що й описи запусків.
• Спостережуваність — панель за часткою переривань, часом простою та завантаженням пулів, щоб схему змінювали за даними, а не за відчуттями.

Раз на квартал ці документи переглядаються разом зі змінами в доступності типів вузлів у провайдера — конфігурація не розходиться з реальністю.

Кейс: донавчання моделі ранжування на перериваних вузлах

Донавчання моделі ранжування йшло циклами: новий лог взаємодій, перезбирання ознак, прогін, валідація. Основні втрати були не в самому розрахунку — прискорювачі простоювали між запусками, а відкликання вузла оберталося втратою прогресу та ручним розбором ситуації.

Ми перевели прогони на переривані вузли: чекпоінти пишуться в об'єктне сховище кожні кілька сотень кроків, планувальник відстежує відкликані Spot-інстанси та піднімає заміну з того самого пулу, навчання продовжується з останньої збереженої точки.

Фінальну валідацію та пакування артефакту залишили на невеликому стабільному резерві — там переривання неприпустиме, а обсяг роботи малий. У Google Cloud такий пул збирається з перериваних і звичайних машин в одній групі.

Відкликання вузла перестало бути подією: прогін повертається в роботу сам, без чергового інженера. Частка простою впала вп'ятеро, час до релізу моделі скоротився більш ніж удвічі, а ручні втручання зведені до перевірок на фінальній валідації.

Що робити, якщо частина потужностей уже зайнята постійним навантаженням?

Постійні сервіси — обробники запитів, черги, кеш, бази даних — тримають завантаження цілодобово, а навчання приходить піками: то йому потрібен весь парк, то половина простоює.

Якщо все живе в одному пулі, виграш від витіснюваних машин перетворюється на гойдалки: або навчання вибиває сервісні процеси з вузлів, або під нього резервується залізо, яке більшу частину доби не працює.

Робоча схема — розподіл пулів на три частини. Стійкий пул під постійне навантаження закриває його із запасом на пік, витіснюваний відданий навчанню та не впливає на сервіси, а буферний перемикається між ними за розкладом.

Якщо вузли все одно спільні, вводять пріоритети задач і класи витіснення: сервісні процеси позначені як непереривані, навчальні — як ті, що поступаються першими.

Мітки та допуски планувальника не пускають навчання на вузли з критичними сервісами, тому спільне використання не перетворюється на бійку за пам'ять і дисковий ввід-вивід.

Планування потужностей будують на замірах, а не на інтуїції: беруть верхній перцентиль завантаження сервісів за довгий період, додають запас на пік і лише залишок оголошують доступним навчанню.

Навчання стартує у вікна низького навантаження та ведеться з чекпоінтами — перерваний процес продовжується з останньої точки, а не з нуля.

Так постійне навантаження залишається в передбачуваних умовах, а навчання забирає все, що справді вільно: утилізація парку зростає без ризику для сервісів.

Технічні сумніви та відповіді щодо перериваних вузлів

Відкликання вузла — не збій, а штатна подія з попередженням: середовище отримує сигнал, встигає завершити поточний крок і вивантажити стан. Частота відкликання залежить від класу ресурсу та регіону — на практиці це одиниці відсотків доби, а не «вузол гасне щогодини».

Планувальник перезапускає задачу на новому вузлі та підхоплює останню контрольну точку, тому прогін продовжується, а не починається заново. Саме на цій механіці й будується розрахунок, чи вигідні Spot-інстанси під конкретну задачу.

Втрата прогресу обмежена інтервалом між контрольними точками, а не довжиною прогону: за збереження кожні кілька хвилин відкат коштує хвилини обчислень.

Точки пишемо в об'єктне сховище з версіонуванням і політикою життєвого циклу — свіжі версії залишаються для відкату, старі видаляються, і обсяг сховища не зростає нескінченно.

Що під час донавчання великої моделі?

Критично, що саме потрапляє в контрольну точку. Якщо зберігати лише ваги без стану оптимізатора, після перезапуску збіжність просідає. Ми пишемо повний стан і перевіряємо відновлення на тестовому прогоні до старту.

Обговоримо задачу навчання та повернемося з планом і оцінкою

Щоб розмова була предметною, корисно прийти з ввідними щодо навантаження.

Достатньо поточного профілю навчання: які моделі та на якому наборі даних навчаються, скільки епох, як часто запускаються задачі, яка частка часу йде на очікування прискорювачів і що відбувається у разі раптового відкликання машини.

• Постановка задачі. Які навчання хочете прискорити насамперед і де зараз вузьке місце — черга, простій прискорювачів чи надлишковий запас машин.
• Ввідні щодо навантаження. Профіль задач, вимоги до пам'яті, тривалість одного запуску, готовність до переривання та перезапуску з останньої контрольної точки.
• Поточний контур. Як влаштовані запуски, де лежать дані та артефакти моделей, чи є спостережуваність і облік споживання за командами.
• План впровадження. Покажемо, як частину парку переводимо на Spot-інстанси з автоматичним поверненням у стабільний пул у разі нестачі ємності.
• Склад робіт. Розмітка завдань за допуском до переривання, політика відбору ємності, збереження контрольних точок, автоматичне масштабування черги.
• Оцінка строків. Діапазон за етапами — від пробного переведення одного типу задач до повного розгортання з планом відкату.

Далі — коротка розмова по суті: опишіть задачу та поточний профіль навчання, і ми повернемося з планом, складом робіт і строками.