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