Объясните ожидания, прежде чем искать более мощный 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, изучите эту фазу и её реальный параллелизм. Если устройства ждут других участников распределённого задания, проверьте балансировку нагрузки и коммуникации. Несколько симптомов могут проявляться одновременно; их корреляция ещё не доказывает причинно-следственную связь.

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

Вымышленный пример: анализ цикла в сто секунд

Вымышленная команда «Revue des maquettes» описывает цикл без перекрытия: шестьдесят секунд подготовки на 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, перегружая при этом диск, память хоста или выходные потоки. Увеличение размера пакетов может изменить задержку и требуемую память. Снижение точности может изменить результат. Эти решения не запрещены, но их следует оценивать по той же бизнес-цели с учётом их побочных эффектов, а не выбирать только потому, что отображаемый процент растёт.

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

Завершите диагностику полезным для решения доказательством

Итоговое дело должно указывать симптом, принятую гипотезу, испробованное изменение, его условия и наблюдаемый результат. Сохраните как минимум одно сравнение до/после на одном и том же наборе входов, с тем же качеством и тем же определением завершения. Если результат неубедителен, напишите, что было исключено и какое наблюдение необходимо следующим. Задокументированная отклонённая версия не даёт другому человеку начать заново наугад.

Низкая нормальная активность не всегда требует исправления. Если задача укладывается в срок, качество и бюджет, снижение сложности может быть предпочтительнее хрупкой оптимизации. Если рассматривается новая конфигурация, передайте доказанные ограничения в дело о приёмке. Ни одно отдельное измерение не классифицирует каталог, и никакое значение из этого примера не является обещанной производительностью.