Поясніть очікування, перш ніж шукати потужніший GPU.

Опишіть проблему через результат і проміжок часу

Замініть «GPU не працює» на перевірюване спостереження: перший результат надходить пізно, на етапах виникають паузи або кількість прийнятних виходів зменшується. Наведіть набір вхідних даних, версію застосунку, налаштування та спостережуваний період. Перший запуск може містити інші фази, ніж уже підготовлене виконання; не змішуйте їх без застереження.

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

Правильно читати відсотки та пам'ять

У NVIDIA SMI використання GPU вказує на частку інтервалу вибірки, протягом якої виконувався принаймні один ядро-процес. Це не оцінка продуктивності всіх компонентів. Використання пам'яті описує її активність читання або запису; його не слід плутати з обсягом зайнятої пам'яті. Документація також зазначає, що деякі поля можуть бути недоступними залежно від середовища.

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

Зібрати корельований і достатньо короткий запис

Виберіть репрезентативну послідовність і обмежте збір даними цією послідовністю. Зафіксуйте час, ідентифікатор GPU, активність, зайняту пам'ять і фази застосунку. Паралельно скористайтеся наявними у вашій системі інструментами, щоб спостерігати за процесом CPU, його очікуваннями, читанням і записом. Усереднення по всіх ядрах може приховати одне перевантажене потік; подивіться також на відповідні процеси.

Наведена нижче команда читання призначена для авторизованої цілі NVIDIA, яка вже має NVIDIA SMI. Її не запускали для цього посібника. Вона зберігає одиниці в CSV і виводить одне спостереження щосекунди до свого переривання. Перевірте поля, які підтримує ваша версія, і зупиніть збір даними наприкінці сценарію. Поле N/A залишається невідомим: не перетворюйте його на нуль.

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

nvidia-smi --version
nvidia-smi --query-gpu=timestamp,uuid,utilization.gpu,memory.used,memory.total --format=csv --loop=1

Відрізняти версію від висновку

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

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

Вигаданий приклад: аналіз циклу на сто секунд

Вигадана команда «Реview макетів» описує цикл без перекриття: шістдесят секунд підготовки на CPU, двадцять обчислення на GPU, потім двадцять експорту. Разом 100 секунд, а частка часу, відведена на обчислення GPU, становить 20/100, тобто 20 %. Це педагогічне обчислення не передбачає відсоток інструменту вибіркового спостереження і не відповідає жодному вимірюванню GPU з каталогу.

Припустімо, що підготовку можна скоротити до тридцяти секунд, не змінюючи обчислення чи виходи. Тоді цикл тривав би 30 + 20 + 20 = 70 секунд: на тридцять секунд менше, з часткою GPU 20/70, тобто приблизно 28,6 %. І навпаки, гіпотетичне зменшення вдвічі лише обчислення GPU дало б 60 + 10 + 20 = 90 секунд. Сценарій пояснює, чому робота над найдовшим очікуванням може важити більше, ніж заміна карти.

Поглибити фазу за допомогою профайлера

Якщо загальне спостереження визначає повільну зону, не пояснюючи її, скористайтеся профілювальником, придатним для застосунку, на короткому вікні. PyTorch Profiler може збирати події CPU та CUDA й упорядковувати вікна збору. Документація вказує на додаткові накладні витрати, коли ввімкнено запис форм або стеків. Детальна траса є інструментом діагностики; її загальний час не слід подавати без застережень як звичайний час роботи програми.

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

Уникати виправлень, які маскують проблему

Збільшення паралельності може заповнити GPU, водночас перевантажуючи диск, пам’ять хоста або виходи. Збільшення розміру пакетів може змінити затримку та потрібну пам’ять. Зниження точності може змінити результат. Ці рішення не заборонені, але їх слід оцінювати за тим самим бізнес-завданням, з їхніми побічними ефектами, а не обирати лише тому, що відсоток, який відображається, зростає.

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

Завершити діагностику корисною для рішення доказами

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

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