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