Налаштування GPU-кластера: де ламається навчання моделей
Зібраний власними силами контур на папері рахує все правильно, а на першому довгому тренуванні починає розвалюватися. Налаштування GPU-кластера — це не купівля прискорювачів і драйверів, а режими планування, охолодження та відмовостійкість. Саме вони визначають, скільки епох на добу ви отримуєте насправді.
Перепідписка прискорювачів — перше джерело втрат. Коли на одну карту планувальник кладе кілька завдань, вони конкурують за пам'ять і такти, крок навчання зростає, а за щільного укладання додаються перегрівання та тротлінг. Формально всі прискорювачі зайняті, фактично пропускна здатність падає в рази.
Другий збій — простій черги навчання. Завдання чекають, поки вузол утримує процес, який завис або чекає дані, а розподіл по картах задано статично. Прискорювачі простоюють, і дослідники запускають експерименти вручну, в обхід черги.
Третій — втрата контрольних точок під час падіння вузла. Якщо контрольні точки записуються лише на локальний диск і недостатньо часто, відмова однієї машини обнуляє багатогодинний прогін. На власних потужностях це найдорожча категорія збоїв: вона б'є не по залізу, а по часу команди.
Усі три проблеми вирішуються на рівні архітектури кластера, а не заміною прискорювачів. Розбираємо, як це закривається.
Що дає виділений кластер під навчання моделей
Коли навчання йде на розрізнених машинах, цикл експерименту розтягується: частина прискорювачів простоює в очікуванні даних, частина зайнята чужим завданням, а результат відтворюється лише на конкретному вузлі.
Виділений кластер під навчання прибирає ці гойдалки — ресурси розподіляються між завданнями явно, а не за фактом вивільненого заліза.
Швидкість циклу експериментів визначається не піковою продуктивністю одного вузла, а часом від запуску до метрики.
Підготовку даних і навчання ми розводимо по різних групах вузлів, щоб читання даних не конкурувало з розрахунком, а черга налаштована так, що короткі перевірки гіпотез не чекають у хвості довгих завдань. Цикл, який раніше займав добу, вкладається в кілька годин.
Відмовостійкість навчання — наслідок контролю середовища, а не везіння.
Температуру, живлення та обмін між вузлами ми відстежуємо постійно, тому відхилення видно до того, як завдання впаде на середині прогону; контрольні точки зберігаються автоматично, і перезапуск іде з останньої, а не з нуля.
Клас відмов через перегрівання та просідання живлення зникає разом із запасом з охолодження та коректними лімітами за потужністю.
Завантаження прискорювачів перетворюється на вимірювану величину: видно, скільки часу вузол зайнятий корисною роботою, хто тримає ресурс даремно і де завдання впираються в підготовку даних.
Звідси передбачуване планування — розширення рахують за фактичною зайнятістю вузлів, а не на око, і воно не перетворюється на простій купленого заліза.
Варіанти організації обчислень: власний контур, оренда, хмара
Режим обчислень обирають не за зручністю, а за профілем навантаження: скільки триває навчання, наскільки рваний графік, чи є вимоги до периметра даних.
Один і той самий проєкт часто стартує на оренді й переїжджає у власний контур — критично, щоб перехід не вимагав переписувати код запуску й перезбирати середовища.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Власний обчислювальний контур | Цілодобове завантаження, дані не виходять за периметр, потрібен передбачуваний графік | Розгортання та охолодження займають тижні, між піками прискорювачі простоюють |
| Оренда обчислювальних потужностей | Потрібен ізольований контур на термін проєкту або під разовий пік навчання | Доступ за розкладом майданчика, обмежений вибір конфігурацій, залежність від чужих термінів |
| Хмара з оплатою за споживання | Рваний графік: експерименти, перенавчання, рідкісні сплески | За безперервного завантаження дорожче за власний контур, чутливі дані потребують окремого контуру |
| Гібридний режим обчислень | Важке навчання на боці майданчика, виведення моделей поруч із даними | Потрібен єдиний шар керування запусками та спільний реєстр артефактів |
Власний кластер не потрібен, поки навантаження не вийшло на стабільне плато або поки дані можна вивозити. Тоді оренда чи хмара дешевші не лише на старті, а й у супроводі: не потрібно тримати зміну, стежити за охолодженням і запасати залізо під пік.
Гібридний режим обчислень закриває випадок, коли навчання йде назовні, а сервіс має відповідати поруч із джерелом даних. Ми розводимо ці контури за одним шаблоном запуску, тому переведення етапу з одного середовища в інше залишається зміною параметрів, а не окремим проєктом.
Вибір режиму фіксуємо за виміряним завантаженням за два-три тижні: де прискорювачі простоюють, де вузьке місце в передачі даних, який етап можна винести без ризику для периметра.
Порядок впровадження: від аудиту навантаження до передачі в роботу
Кластер не збирають «під ML загалом» — його збирають під конкретний профіль навантаження. Тому починаємо із замірів: без цифр щодо завантаження та часу очікування в чергах схема залишається здогадкою, а переробка після введення в експлуатацію коштує дорожче за проєктування.
-
Аудит навантаження на навчання. Знімаємо профіль завдань: частку простою прискорювачів в очікуванні даних, час обміну градієнтами між вузлами, місце, де впирається читання датасетів. Результат — модель профілю з піковою кількістю одночасних запусків.
-
Проєктування інфраструктури навчання. За профілем визначаємо кількість вузлів і щільність прискорювачів, топологію зв'язків, обсяг сховища під датасети й контрольні точки. Тут же фіксуємо, як завдання розкладаються між вузлами.
-
Налаштування планувальника та сховища. Черга з пріоритетами за проєктами й квотами на ресурси, щоб одна команда не виїдала кластер. Сховище готуємо під паралельне читання: кеш гарячих датасетів, окремий том під контрольні точки та політика їхньої ротації.
-
Перевірка відмовостійкості. Гасимо по черзі вузол, мережевий лінк і сегмент сховища прямо під час навчання. Дивимося, чи переживає завдання перезапуск сегмента без втрати прогресу і за який час відновлюється.
-
Замір на еталонному завданні. Звіряємо реальну швидкість навчання з розрахунковою й шукаємо розсинхрон: повільний вузол, неправильні параметри пакетної обробки, перегрівання.
-
Передача кластера в експлуатацію. Віддаємо конфігурації як код, панелі моніторингу, регламенти реагування та інструкції для інженерів замовника.
Артефакти передачі: конфігурації, схеми, регламенти
Передача кластера — це не усна розповідь «як тут усе влаштовано», а пакет артефактів, який живе в репозиторії замовника та версіонується разом зі змінами.
Якщо знання залишається в одного інженера, будь-яке оновлення драйвера або вихід вузла з ладу перетворюється на простій, який ніхто не вміє закрити.
- Конфігурації інфраструктури — декларативний опис вузлів, мереж, сховищ і черги завдань. Розгортання з нуля та відновлення після збою відтворюються без ручних правок і «доналаштування з пам'яті».
- Схеми обчислювального контуру — топологія вузлів, шлях даних від сховища до прискорювачів, точки відмови та вузькі місця. Новий інженер бачить, де межа за пропускною здатністю, до того як щось змінювати.
- Політики доступу до ресурсів — ролі, квоти, ізоляція команд, правила пріоритетів. Одна група завдань не витісняє іншу, а спірні випадки вирішуються за записаним правилом, а не в листуванні.
- Документація ML-інфраструктури — склад образів, версії драйверів і бібліотек, порядок підключення, каталоги наборів даних і проміжних станів навчання. Запуск нової моделі не перетворюється на археологію.
- Регламенти обслуговування — вікна планових робіт, порядок оновлення драйверів, виведення та заміна вузлів, перевірки цілісності сховища. Простій стає передбачуваним замість аварійного.
- Інструкції з інцидентів — сценарії «вузол випав із черги», «завдання зависло», «закінчилося місце» з покроковими діями та точками ескалації.
Пакет оновлюється за кожної зміни контуру: артефакти, що розходяться з реальністю, перестають бути опорою й починають вводити в оману.
Кейс: як розподілене навчання перестало простоювати
Кластер на кілька десятків вузлів із прискорювачами NVIDIA обслуговував потік завдань розподіленого навчання — від коротких експериментів до багатоденних прогонів на всіх вузлах одразу.
Формально відмовостійкість була: завдання видавалися через планувальник, дані лежали на спільній файловій системі, у кожного завдання був свій набір контрольних точок. На практиці падіння одного вузла зупиняло всю групу, а прогрес епохи втрачався повністю.
Що показували метрики до
Частка корисної завантаженості прискорювачів трималася близько 40%: решту часу залізо чекало повторного запуску, вивільнення вузла або ручного розбору інциденту.
Відновлення після збою займало години — інженер піднімав середовище заново, переносив завдання й запускав навчання з останньої збереженої точки, яка на той момент відставала на кілька епох.
Частина завдань не відновлювалася взагалі: контрольні точки лежали на локальному диску машини, що впала.
Що змінили
Рознесли зберігання та обчислення: контрольні точки записуються в об'єктне сховище із заданою періодичністю, тому прогрес переживає втрату вузла повністю.
Планувальник налаштували на автоматичний перезапуск групи з останньої контрольної точки та на перевірку живучості — завислий процес знімається й переїжджає на здоровий вузол, не чекаючи, поки розвалиться вся група. Окремо вирівняли доступ до даних, щоб відновлений вузол не забирав всю смугу в інших.
Після правок частка корисної завантаженості зросла з 40% до 87%, час відновлення після збою скоротився з годин до одиниць хвилин, а частка завдань, втрачених без можливості продовження, впала до нуля.
З'явився й облік за кожним запуском: видно, скільки часу пішло на обчислення, скільки на очікування в черзі й скільки на перезапуски — деградація помічається до того, як її побачить дослідник.
Чим відрізняється один вузол від розподіленого запуску навчання?
Один вузол — це кілька прискорювачів із спільною швидкою шиною та пам'яттю, обмін усередині якої йде напряму.
Поки ваги моделі, стани оптимізатора та проміжні активації вміщаються в цю пам'ять, розподілений запуск частіше програє: кожен крок починається й закінчується синхронізацією.
Межа проходить не за кількістю прискорювачів, а за тим, що обмежує крок навчання. Якщо вузьке місце — обчислення, а пам'ять не переповнюється, другий вузол не прискорить роботу, а додасть очікування на пересиланні.
Розподілений запуск потрібен, коли модель або пакет даних перестають вміщатися або коли потрібен обсяг обчислень, недосяжний на одному вузлі.
Спосіб розпаралелювання підбирається під причину нестачі. За даними навантаження ділять між вузлами й синхронізують градієнти — масштабується найпростіше, але потребує повної копії моделі на кожному вузлі.
За моделлю ваги та шари розрізають між прискорювачами: так навчають моделі, що не вміщаються в пам'ять одного вузла, ціною помітно більшого обміну.
Обмін даними між вузлами — головне джерело втрат під час масштабування. Колективна синхронізація градієнтів дорожчає з кількістю учасників, а її частка в кроці залежить від топології мережі та розкладки шарів по вузлах. Вісім вузлів дають прискорення не у вісім разів, а в п'ять-шість — це нормальний результат.
Тому рішення ухвалюють за замірами, а не за кількістю карт: знімаємо профіль кроку на одному вузлі, дивимося частку часу на обмін і очікування, рахуємо, який приріст дасть другий ступінь.
Якщо приріст не покриває ускладнення відмовостійкості та контрольних точок — залишаємо один вузол і вичавлюємо з нього.
Технічні сумніви: відмовостійкість, доступи, підтримка
Перш ніж обговорювати економіку, замовник перевіряє поведінку кластера в реальній експлуатації: навчання на кількох вузлах, планові оновлення, передача контуру своїй команді. Ці сценарії закладаються в проєкт одразу — доопрацьовувати їх на живому контурі дорожче й ризикованіше.
Планувальник бачить стан кожного вузла, а навчання йде з контрольними точками: вузол, що випав, не обнуляє прогін. Доступи видаються ролями, оновлення йдуть хвилями по групах вузлів, тому робочі завдання не зупиняються повністю. Нижче — відповіді на сумніви, які найчастіше лунають до старту.
Що станеться, якщо один вузол вийде з ладу?
Завдання зберігає контрольні точки із заданим кроком, планувальник виключає вузол із пулу й продовжує навчання з останньої точки — втрачаються хвилини замість доби. Для виведення моделей тримаємо резерв ємності: відмова одного вузла не обвалює сервіс, трафік перерозподіляється. Сповіщення про деградацію надходять раніше, ніж відмовить другий вузол.
Як розділяються доступи між командами?
Права будуємо за мінімально необхідним рівнем: дослідник працює у своїх просторах імен і чергах, але не змінює конфігурацію; черговий керує перезапусками та лімітами; адміністраторський доступ — у вас або в нас за регламентом. Секрети зберігаються окремо від коду, а дії записуються в журнал аудиту.
Як оновлюється контур без простою?
Оновлюємо хвилями: спочатку керуючий вузол, потім групи робочих із перевіркою завдань після кожної хвилі. Драйвери та бібліотеки фіксуються в образах, тому відкат — це повернення на попередній образ, а не ручне перевстановлення. Для перевірки нових версій залишається окремий стенд.
Що входить у підтримку після передачі?
Передаємо конфігурацію як код, схеми розміщення та регламенти: масштабування пулу, додавання користувачів, дії під час деградації. Далі — супровід з обумовленим часом реакції, оновлення під актуальні гілки бібліотек і планові перевірки стану разом із вашою командою.
Обговоримо завдання — повернемося з оцінкою та планом робіт
Щоб оцінка була предметною, а не «на око», достатньо кількох вступних: поточна конфігурація заліза й мережі, профіль навантаження — які моделі навчаються і скількома прискорювачами, цільовий час запуску та вимоги до відмовостійкості.
Чого не вистачає — уточнимо на дзвінку: розберемо завдання, пройдемося топологією та повернемося з планом.
- Опишіть завдання: що навчаєте або обслуговуєте, який обсяг даних, скільки команд ділитимуть кластер.
- Надішліть конфігурацію вузлів, мережі та сховища — або скажіть, що ще не закуплено й перебуває на виборі.
- Укажіть профіль навантаження: розмір моделей, кількість паралельних експериментів, вимоги до ізоляції середовищ.
- Позначте обмеження: доступи, регламенти, вікна простою, до якого терміну потрібен робочий контур.
- Сформулюйте критерій успіху: час запуску завдання, завантаження прискорювачів, кількість одночасних навчань.
- Узгодимо рівень відмовостійкості: що резервуємо, що допускаємо втратити, як відновлюємося.
Розбір займає кілька робочих днів. Повертаємося не презентацією, а планом робіт: етапи, склад конфігурацій і політик, схема кластера та строки впровадження — від монтажу й налаштування до приймання під навантаженням. Етапи узгодимо разом, щоб строки були реальними, а не оптимістичними.
Опишіть завдання зручним способом — повернемося з оцінкою та планом робіт.
