Официальный блог PyTorch: подробный профилировщик PyTorch v1.9

Улучшения в Profiler v1.9 сосредоточены на этапах выполнения, которые являются наиболее энергоемкими во время выполнения и/или в памяти, и коллеги визуализируют распределение рабочей нагрузки между графическими и центральными процессорами.

Profiler v1.9 добавляет пять основных новых функций, в том числе:

1. Распределенное представление обучения:Это поможет вам оценить потребление времени и памяти распределенными задачами обучения. Предположим, у вас есть обучающая модель, когда вы хотите разделить нагрузку на рабочие узлы для параллельной работы, это может быть как черный ящик, и возникнут различные проблемы. Общая цель модели — увеличить скорость обучения. Это распределенное учебное представление помогает диагностировать и устранять проблемы в одном узле.

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

3. Визуализация приложения GPU:Этот инструмент обеспечивает полное использование графического процессора.

4. Поддержка облачного хранилища:Подключаемый модуль Tensorboard теперь может считывать проанализированные данные из хранилища BLOB-объектов Azure, Amazon S3 и Google Cloud Platform.

5. Перейти к исходному коду:Эта функция поддерживает визуализацию информации о трассировке стека и обеспечивает прямой переход к исходному коду. Это поможет вам быстро оптимизировать и повторять код на основе результатов анализа.

Портал Colab Profiler PyTorch

Китайская версия портала Colab

Содержание Colab с первого взгляда:

• Подготовка данных и моделей

• Регистрировать события выполнения с помощью Profiler

• запустить профайлер

• Используйте TensorBoard для просмотра результатов и анализа производительности модели.

• Повысьте производительность с помощью Profiler

• Анализ производительности с помощью других расширенных функций

Начало работы с инструментом профилирования PyTorch

Во-первых:

$ pip install torch-tb-profiler

import torch.profiler as profiler
With profiler.profile(XXXX)

Примечание:Для анализа CUDA и ЦП см.Here

with torch.profiler.profile( 
activities=[ 
torch.profiler.ProfilerActivity.CPU, 
torch.profiler.ProfilerActivity.CUDA],

• profiler.record_function("$NAME"): позволяет добавлять декораторы (декораторы, ссылающиеся на метки, связанные с именем) для функциональных блоков.

• Параметр Profile_memory=True в profiler.profile может анализировать использование памяти CPU и GPU.

Визуализация производительности модели PyTorch

Распределенное обучение

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

Распределенный параллелизм данных (DDP) и NVIDIA Multi-Card Communication Framework (NCCL) — широко распространенные парадигмы в PyTorch для ускорения обучения глубокому обучению.

В этом выпуске PyTorch Profiler теперь поддерживается DDP для серверной части NCCL.

Обзор вычислений/коммуникаций

В «Обзоре вычислений/коммуникаций» в представлении распределенного обучения пользователи могут наблюдать за расчетным и коммуникационным соотношением узла «балансировщик нагрузки» среди всех рабочих процессов, которое измеряется степенью детализации.

Ссылки, связанные с балансировщиком нагрузки:Here

Сценарий 1:

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

Чем больше время перекрытия, тем лучше параллелизм между вычислениями и обменом данными.В идеале вычисления и связь полностью перекрывают друг друга. Коммуникация – это общее время коммуникации минус время перекрытия.

В следующем примере показано, как эта ситуация ведет себя на Tensorboard. пример отставшего

Сценарий 2:

Если размер пакета невелик (т. е. вычисление по всем рабочим процессам относительно невелико) или данные, которые необходимо передать, велики, то коэффициент связи вычислений также может быть небольшим, и вы можете видеть в Профилировщике, что Использование графического процессора низкое, а время ожидания долгое.

Пользователи могут просматривать код в соответствии с этим представлением вычислений/коммуникаций, сокращая обмен данными, используя накопление градиентов, или уменьшая долю обмена данными, увеличивая размер пакета. Время связи DDP зависит от размера модели. Размер партии не зависит от размера модели. Следовательно, увеличение размера пакета может привести к увеличению времени вычислений и увеличению количества вычислительных взаимодействий.

Обзор синхронизации/связи

В представлении синхронизации/связи пользователь может наблюдать за эффективностью связи. Это вычисляется путем вычитания времени вычисления и связи из времени шага. Время синхронизации является частью общего времени ожидания связи и синхронизации с другими рабочими процессами. Представление синхронизации/связи включает в себя инициализацию, загрузчики данных, расчеты ЦП и многое другое.

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

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

Из вышеприведенной таблицы вы можете узнать подробную статистику всех операторов связи в каждом узле. С помощью этой таблицы вы можете узнать, какие типы операторов вызываются, сколько раз вызывается каждый оператор, каков размер данных, передаваемых каждым оператором, и так далее.

просмотр памяти

Используя этот инструмент, вы можете понять потребление аппаратных ресурсов операторами в модели. Информация о потреблении времени и памяти на уровне оператора может помочь устранить узкие места в производительности и, таким образом, ускорить выполнение модели.Учитывая ограниченный объем памяти графических процессоров, оптимизация эффективности использования памяти помогает:

• Позволяет запускать крупномасштабные модели и лучше выполнять задачи на уровне терминала.

• Позволяет увеличить размер партии, увеличивая скорость обучения.

Профилировщик записывает все выделения памяти в течение интервала Профилировщика. Выберите «Устройство», чтобы просмотреть сведения об использовании памяти каждым оператором на стороне графического процессора или на стороне хоста.

Примечание. Параметр profile_memory=True должен быть включен для создания следующих данных памяти.

Ссылки по теме:Here

With torch.profiler.profile(
Profiler_memory=True # this will take 1 – 2 minutes to complete. 
)

Важные определения:

• «Увеличение размера» показывает сумму всех выделенных байтов за вычетом всех байтов освобожденной памяти.

• «Размер выделения» показывает сумму всех выделенных байтов, исключая освобождение памяти.

• «Сам» означает, что выделенная память не исходит от какого-либо дочернего оператора, а выделяется самим оператором.

Метрики GPU на временной шкале

С помощью этой функции вы можете легко устранять проблемы с производительностью, когда один или несколько графических процессоров используются недостаточно. В идеале ваша программа должна иметь высокую загрузку графического процессора (если возможно, 100% загрузку графического процессора), минимальную стоимость связи между процессорами и не потреблять энергию.

Обзор:На странице обзора представлены результаты на разных уровнях по трем важным показателям использования графического процессора (т. е. использование графического процессора, расчетная эффективность SM и расчетная достигнутая занятость).

По сути, каждый GPU имеет множество SM, каждый SM имеет множество Warps и может выполнять множество потоков одновременно. Warp выполняет много потоков, потому что их количество зависит от GPU. С точки зрения высокого уровня показатели графического процессора на временной шкале могут помочь разработчикам получить общую картину всего стека, что очень важно.

Если использование графического процессора низкое, в модели есть основная проблема. Общие причины следующие:

• Недостаточный параллелизм в ядре, т.е. слишком маленький размер пакета

• Небольшие ядра вызываются в цикле, т. е. затраты на запуск не амортизируются.

• Узкие места процессора или ввода-вывода приводят к недостаточному рабочему контенту и низкому использованию графического процессора.

На странице «Обзор» раздел «Рекомендации по производительности» представляет собой список практических предложений по улучшению использования графического процессора. В этом примере загрузка графического процессора низкая, поэтому рекомендуется увеличить размер пакета. Согласно рекомендациям по производительности, увеличение размера пакета с 4 до 32 увеличило загрузку графического процессора на 60,68%.

Использование графического процессора:В Profiler время интервала шага возникает, когда ядро ​​графического процессора выполняет рабочую нагрузку. Чем выше процент использования, тем лучше. Определение узких мест производительности только по использованию графического процессора не является точным. У вас нет возможности узнать, сколько запущено потоковых мультипроцессоров.

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

Est. SM Efficiency — это более детальный индикатор.Он представляет собой процент SM, которые используются во время трассировки, процент времени, который представляет хотя бы один активный перенос на SM, и тех, которые простаивают.

Документация NVIDIA:Here

Est. SM Efficiency также имеет ограничения. Ядро с одним потоком на блок не может полностью использовать все SM. Невозможно узнать использование каждого SM только на основе эффективности SM, а только то, что делает каждый SM, включая паузы в ожидании результатов загрузки памяти.

Чтобы поддерживать высокий уровень использования SM, необходимо гарантировать выполнение достаточного количества готовых циклов до тех пор, пока происходят задержки.

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

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

Документация NVIDIA:Here

Чем выше значение Расчетной загрузки, тем лучше.

Подробности: Resnet50_batchsize4

Подробности: Resnet50_batchsize32

Представление ядра: в ядре есть «Блоки на SM» и «Приблизительная достигнутая занятость».

Est.Achieved Occupancy — полезный инструмент для сравнения работоспособности модели.

Среднее количество блоков на SM:

Блоки на SM = блоки для этого ядра / SM для этого графического процессора. Если это число меньше 1, мультипроцессор GPU используется не полностью. «Среднее количество блоков на SM» — это средневзвешенное значение всех запусков этого имени ядра с использованием продолжительности каждого запуска в качестве веса.

Средняя расчетная заполняемость:

Определение расчетной достигнутой занятости такое же, как указано выше. Среднее достигнутое значение занятости — это средневзвешенное значение всех запусков для этого имени ядра с использованием продолжительности каждого запуска в качестве веса.

Просмотр трека:

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

В приведенном выше примере «ProfilerStep5» имеет более высокую загрузку графического процессора во время потока 28022, чем во время «Optimizer.step». Вы можете увеличить масштаб, чтобы увидеть, почему.

Как видно из приведенного выше рисунка, ядро ​​первого длиннее ядра второго. Время выполнения ядра последнего слишком мало, что приводит к снижению загрузки графического процессора.

Расчетная эффективность SM:Каждое ядро ​​имеет расчетную эффективность EST.SM в диапазоне от 0 до 100%. Например, приведенное ниже ядро ​​имеет только 64 блока, а SM этого GPU равен 80, поэтому его «Оценочная эффективность SM» составляет 64/80, или 0,8.

Поддержка облачного хранилища

После запуска pip install tensorboard для чтения данных через облачного провайдера вы можете запустить:

torch-tb-profiler[blob] 
torch-tb-profiler[gs] 
torch-tb-profiler[s3]

С помощью pip install torch-tb-profiler[blob], pip install torch-tb-profiler[gs] или pip install torch-tb-profiler[S3] данные можно прочитать через поставщика облачных услуг.

Для получения дополнительной информации см.:Here

Перейти к исходному коду

Одним из больших преимуществ интеграции TensorBoard и PyTorch Profiler непосредственно в Visual Studio Code (VS Code) является возможность прямого перехода к исходному коду (файлам и строкам) из трассировки стека Profiler. Расширение VS Code Python теперь поддерживает интеграцию с TensorBoard.

Переход к исходному коду доступен только тогда, когда Tensorboard работает в VS Code. Если профилирование with_stack=True, трассировка стека появится в пользовательском интерфейсе плагина. Щелкните трассировку стека в PyTorch Profiler, и VS Code откроет соответствующий файл и перейдет непосредственно к соответствующему коду для отладки. Это дает возможность быстро оптимизировать и модифицировать код на основе результатов анализа и рекомендаций.

Переход к исходному коду с помощью пользовательского интерфейса подключаемого модуля Visual Studio Code

Ознакомьтесь с подробным руководством о том, как оптимизировать производительность размера пакета:Here

PyTorch Profiler также можно интегрировать с PyTorch Lightning, просто запустите задачу обучения молнии с train.profiler=pytorch для создания трассировок.

Подробный пример:Here

Оригинальный адрес:Here