Чому автомасштабування GPU не тримає пікове навантаження
Класична схема автомасштабування GPU спирається на середнє завантаження прискорювачів за вікно у кілька хвилин. Поки трафік рівний, метрика встигає відреагувати, і пул зростає вслід за попитом.
Але щойно з’являється черга завдань на навчання, середня утилізація перестає відображати реальний дефіцит: завдання чекають, частина прискорювачів зайнята підготовкою даних, і пороги просто не спрацьовують.
Звідси друге джерело втрат — простій прискорювачів між піками.
Пул тримають за нижньою межею, щоб ресурси не висіли без діла, тому в спокійні години черга розбирається майже миттєво, а за одночасного запуску кількох експериментів вона зростає швидше, ніж планувальник встигає додати вузли. Масштабування запізнюється саме на той інтервал, де навантаження максимальне.
Ручне розширення пулу додає до цього затримку в години: заявка, погодження, підняття вузлів, прогрів образів і кешу ваг, перевірка доступності прискорювачів у потрібному регіоні.
Поки це триває, пікове навантаження на інференс уже деградує — відповіді розтягуються, частина запитів відпадає за таймаутом, а навчання зсувається на наступний цикл.
Ззовні це виглядає як нестача потужностей, хоча вузли є — просто вони не там і не тоді, де потрібні. Розбираємо, як це закривається: які сигнали мають керувати пулом замість середньої утилізації та як пов’язати чергу завдань, прогрів і відкат в одну керовану схему.
Що дає автомасштабування GPU: час, ємність, стійкість
Автомасштабування GPU починається з черги. Поки завдань більше, ніж вільних прискорювачів, кожне нове стає в очікування, і хвіст черги зростає швидше за середнє.
Тому першим ділом ми вимірюємо час очікування завдання до старту навчання й розподіл завантаження прискорювачів по пулу: за ручного керування про перевантаження дізнаються зі скарг, а не з графіка.
Кероване масштабування тримає завантаження в робочому коридорі. Під пік пул розгортається заздалегідь за сигналом довжини черги, у спокійні години стискається до мінімуму — ємність під пік з’являється на момент запуску, а не через годину після нього.
Резерв при цьому не гріється марно: частка простоюючих прискорювачів падає в рази, а вартість простою кластера перестає бути постійним рядком.
Відмовостійкість пулу — другий ефект. Автоматика знімає вузол, що випав, з балансування, перезапускає завдання з останньої контрольної точки на здоровому прискорювачі й не віддає планувальнику неробочі ресурси, тож завислі завдання перестають займати ємність до ручного втручання. Телеметрію беремо ту саму, що віддають штатні засоби NVIDIA, — окремий агент для цього не потрібен.
На виході замовник отримує передбачувану чергу замість ручних чергувань. Пікові вікна закриваються без заявок на розширення, нічні прогони не чекають звільнення прискорювачів, а поведінка кластера перестає залежати від того, хто сьогодні на зміні.
Порівняння режимів масштабування обчислювального пулу
Ємність обчислювального пулу змінюють чотирма способами, і вони не взаємозамінні — у кожного своя затримка реакції на пік і своя ціна помилки. Вибір залежить від профілю навантаження: рівний потік запитів, передбачувані вікна або різкі сплески від зовнішніх подій.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Масштабування за метрикою | Навантаження корелює із завантаженням прискорювачів або обсягом зайнятої пам’яті; потік рівний | Затримка реакції на пік — одиниці хвилин: метрика усереднюється за вікном, вузол ще піднімається й прогрівається. Різкий сплеск встигає стати в чергу |
| Масштабування за довжиною черги (поріг черги) | Сервіси з явною чергою завдань: пакетний інференс, обробка файлів, фонові прогони | Поріг добирається під профіль: низький — пул смикається на кожному залпі, високий — зростає час очікування для всіх |
| Масштабування за розкладом | Передбачувані піки: робочі години, вікна вивантажень, регулярні перерахунки | Не витримує незапланованого сплеску — ємність упирається в стелю розкладу |
| Статичний резервний пул | Критичні сервіси з жорстким лімітом часу відповіді | Простоюючі прискорювачі; потрібна верхня межа й політика повернення до загального пулу |
На практиці режими комбінують: розклад закриває базову криву, метрика або поріг черги добирає залишок, резервний пул тримає мінімальну гарячу ємність.
Ключова величина під час вибору — затримка реакції на пік: вона складається з вікна усереднення метрики, часу запуску вузла й прогріву моделі.
Етапи впровадження: від аудиту навантаження до передачі регламентів
Профіль навантаження на GPU рідко буває рівним: нічні пакетні розрахунки, денні інтерактивні запити й короткі піки вкладаються в добу з різною амплітудою.
Правила, виставлені на око, дають або простій дорогих карт, або черги, у яких користувач чекає відповіді довше, ніж вважає прийнятним. Тому йдемо від вимірювань до схеми і лише потім до порогів.
- Аудит профілю навантаження — знімаємо метрики за характерний період: утилізація по кожній карті, довжина черги, час очікування завдання, форма піків, частка простоюючих карт у спокійні години.
- Схема пулу — скільки вузлів тримаємо в постійному резерві, скільки віддаємо в еластичну частину, як завдання розподіляються між картами й де вузьке місце: пам’ять карти, обмін між вузлами або підготовка даних.
- Правила масштабування — цільова метрика, пороги спрацьовування, крок додавання й зняття вузлів, час стабілізації, пріоритети черг, запас під термінові запити.
- Навантажувальна перевірка — прогін реального профілю з піками й відмовою одного вузла: чи встигає система добрати ресурси, скільки триває запуск нової карти, що відбувається з чергою в цей момент.
- Передача в експлуатацію — регламенти, панелі моніторингу, оповіщення про деградацію, сценарії ручного втручання й зрозумілий черговій зміні відкат правил.
Після передачі автомасштабування GPU не заморожують: профіль змінюється, і пороги переглядають за тими самими метриками — інакше через пару місяців налаштування знову починає працювати проти навантаження.
Конфігурації, схеми й регламенти: комплект документів
Працююче автомасштабування — це не лише пули, які зростають під навантаження.
Без комплекту документів будь-яка зміна конфігурації перетворюється на ризик: пороги спрацьовування пам’ятає один інженер, чергова зміна не знає, які оповіщення потребують втручання, а відкат робиться з пам’яті.
Тому ми передаємо замовнику набір артефактів, за якими інфраструктуру можна обслуговувати власними силами.
- Конфігурація пулу — файли з порогами спрацьовування, мінімальним і максимальним розміром, часом прогріву й охолодження вузлів, прив’язкою класів завдань до типів прискорювачів. Правки йдуть через репозиторій, а не руками на живій системі.
- Схема інфраструктури — розміщення пулів, зони, канали до сховищ моделей і даних, точки відмови та їхній вплив на масштабування. Оновлюється за кожної зміни топології.
- Матриця доступу — які ролі змінюють ліміти, піднімають вузли, читають метрики й логи. Прив’язка до корпоративних груп: під час звільнення співробітника доступ відкликається однією операцією.
- Регламент чергування — що перевіряти на початку зміни, які оповіщення критичні, що можна робити без погодження і куди ескалювати. Окремо перелічено заборонені дії, як-от ручне зниження лімітів «щоб не шуміло».
- Інструкція з відкату — покрокове повернення попередніх порогів і розмірів пулу, перевірка, що навантаження знову йде за старим сценарієм, і контрольні метрики, що підтверджують результат.
- Журнал змін — що змінювали, за чиєю заявкою і з яким ефектом: через місяць видно, який поріг прибрав черги, а який лише додав простій.
Комплект лежить поруч із конфігурацією, проходить рев’ю і версіонується — за наступної правки видно, що й навіщо змінювали.
Розбір впровадження: зняття черг на пікових навантаженнях
Що було
Пул прискорювачів виділявся під піковий попит і стояв цілком: уночі простій тримався на 60–70%, а вдень черга на навчання зростала до 9 годин.
Завдання дослідників чекали в загальній черзі без пріоритетів — дрібний експеримент на одному прискорювачі міг простояти за великим навчанням понад добу.
Інцидентів із нестачею ємності набиралося 4–6 на місяць, і майже кожен закривали вручну: шукали вільні вузли, домовлялися із сусідньою командою, зупиняли чужі завдання.
Що зробили
Звели розрізнені пули в загальний і вивели метрики завантаження кожного вузла в автоскейлер: масштабування йде за довжиною черги та утилізацією пам’яті, а не за середнім за період.
Правила й пріоритети описали в KEDA: окремі черги на навчання та інференс, ліміт вузлів на команду, звільнення вузла одразу після завершення завдання.
Образи прогріваємо заздалегідь — новий вузол входить у роботу без очікування завантаження, тому масштабування не впирається в підготовку середовища.
Що стало
Очікування в черзі на навчання скоротилося з 9 годин до 20–40 хвилин на тих самих піках, частка простою впала з 65% до 18%. Інциденти з нестачею ємності — 0–1 на квартал замість 4–6 на місяць, ручний розбір більше не потрібен.
Відкат передбачено: правила автомасштабування знімаються, і пул повертається до статичного режиму за один крок, без перезбирання завдань і втрати запущених навчань.
Що робити, якщо пул прискорювачів уже розгорнуто вручну?
Розгорнутий вручну пул зазвичай тримається на фіксованих мітках: конкретні завдання закріплені за конкретними машинами, а зростання й скорочення робить інженер за заявкою.
Поки навантаження передбачуване, схема працює; за першого сплеску між «потрібно більше прискорювачів» і «прискорювачі з’явилися» минає час, і весь цей час черга завдань зростає, а частина запитів не дочікується відповіді.
Перевести такий парк під кероване масштабування можна без зупинки сервісів. Наявний пул описується декларативно — як є, з поточними мітками, іменами й розподілом завдань: опис стає джерелом істини, але на цьому етапі нічого не змінює.
Зворотна сумісність зберігається: звичні способи звернення до вузлів і ручні команди продовжують працювати, нічого не ламається в момент увімкнення.
Увімкнення йде поступово. Спочатку — режим спостереження: правила рахують цільову кількість вузлів, але не застосовують її, а ми порівнюємо розрахунок із фактичною поведінкою пулу й уточнюємо пороги за реальною утилізацією.
Потім правила працюють на одному пулі або в непікові години, і лише після цього виводяться в загальні: рішення, які інженер ухвалював руками — коли додати вузол, коли звільнити простоюючий, — стають формалізованими умовами.
Переведення без простою будується на акуратному виведенні вузлів: машина залишає пул, лише коли на ній не залишилося активних завдань, а нове навантаження туди вже не планується. Завдання при цьому не перезапускаються, черги не втрачають позицій. Повернутися до ручного керування можна будь-якої миті, не розбираючи пул заново.
Технічні сумніви: черги, холодний старт, відмовостійкість
Інженерні питання до старту зазвичай одні й ті самі: чи встигне ємність з’явитися до пікового завдання, що буде з навчанням під час виведення вузла і чи доведеться чіпати код.
Холодний старт вузла затримає запуск завдання?
Вузол не готовий миттєво: потрібно виділити машину, підняти середовище, підтягнути образ і кеш моделі.
Тримаємо мінімальний резерв під профіль типового завдання й прогріваємо образ заздалегідь, а інтерактив і пакетні завдання розносимо по різних пулах — черга не простоює в очікуванні заліза.
Що як квота на ємність закінчиться в піку?
Верхню межу задаємо заздалегідь і розставляємо пріоритети: інтерактивні завдання отримують ресурс першими, пакетні чекають або вирушають в окремий пул. Якщо провайдер не дає потрібний обсяг, частина роботи йде на резервний профіль — повільніше, але без відмови.
Переривані вузли й виведення на обслуговування — що з навчанням?
Можливо, якщо навантаження можна перезапустити. Навчальний цикл пише контрольні точки за розкладом: переривання або виведення вузла відкочує завдання на останню точку, а не на початок.
Перед обслуговуванням вузол перестає отримувати нові завдання, зберігає стан і лише потім вимикається.
Чи доведеться переписувати код навчання?
Як правило, ні — автомасштабування живе на рівні інфраструктури. Правки точкові: шлях для контрольних точок, реакція на сигнал про завершення вузла, таймаути очікування. Це десятки рядків, а не переробка моделі.
Обговоримо задачу: зберемо схему масштабування під ваш профіль
Щоб оцінка спиралася на ваш профіль навантаження, а не на середні цифри, розбір починається з даних. Надішліть те, що вже збираєте, — схему пулу й порядок робіт зберемо ми.
- Профіль навантаження: добові й тижневі піки, співвідношення тривалих завдань і коротких запитів, допустимий час очікування в черзі.
- Поточна схема пулу: як згруповано вузли, чим запускаються завдання, де впирається — в утилізацію прискорювачів, пам’ять або пропускну здатність мережі.
- Метрики за типовий тиждень: завантаження прискорювачів, довжина черги, частка відхилених завдань, час виходу нового вузла в робочий режим.
- Обмеження середовища: регіони розміщення, вимоги до ізоляції, доступні квоти, вікна обслуговування.
- Цільові показники: пікове навантаження, яке потрібно тримати, допустимий час простою за зміни кількості вузлів, клас відмов, який неприпустимий.
- Точки інтеграції: моніторинг, планувальник, реєстр образів, інструменти керування конфігурацією.
Далі працюємо так. Спочатку разом із вашими інженерами розбираємо профіль навантаження й знаходимо, що саме обмежує масштабування — прогрів вузлів, брак квот або відсутність зворотного зв’язку від черги.
Потім пропонуємо схему пулу: які групи вузлів виділити, за якими метриками ухвалювати рішення про зростання й зниження, за який час вузол має входити в роботу і як налаштувати відкат.
За підсумками розбору повертаємося з оцінкою й планом: етапи, що робимо ми, що залишається на вашому боці, які ризики закриваємо на кожному кроці.
Опишіть задачу — що масштабуємо, з якими піками і в яких обмеженнях. Якщо частина метрик ще не збирається, так і скажіть: уточнимо на розборі й подивимося на доступні логи.
