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

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

В ноябре 2022, В MME добавлена ​​поддержка GPUs, что позволяет запускать несколько моделей на одном устройстве с графическим процессором и масштабировать экземпляры графического процессора за одной конечной точкой. Это удовлетворяет большой спрос MME на модели глубоких нейронных сетей (DNN), которые выигрывают от ускоренных вычислений с помощью графических процессоров. К ним относятся компьютерное зрение (CV), обработка естественного языка (NLP) и генеративные модели искусственного интеллекта. К причинам востребованности относятся следующие:

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

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

По этим причинам мы составили этот пост, чтобы помочь вам провести надлежащее нагрузочное тестирование MME с графическим процессором и найти наилучшую конфигурацию для вашего варианта использования машинного обучения. Мы делимся результатами нагрузочного тестирования некоторых из самых популярных моделей DNN в NLP и CV, размещенных с использованием MME на разных типах экземпляров. Мы обобщаем идеи и выводы из результатов нашего тестирования, чтобы помочь вам принять обоснованное решение о настройке собственных развертываний. Попутно мы также делимся рекомендуемым подходом к выполнению нагрузочного тестирования для MME на графическом процессоре. Рекомендуемые инструменты и методы определяют оптимальное количество моделей, которые можно загрузить для каждого типа экземпляра, и помогают достичь наилучшего соотношения цены и качества.

Обзор решения

Введение в MME и MME с GPU см. Создайте мультимодельную конечную точку и Запускайте несколько моделей глубокого обучения на графическом процессоре с помощью мультимодельных конечных точек Amazon SageMaker.. В контексте нагрузочного тестирования в этом посте вы можете загрузить наш пример кода с Репо GitHub чтобы воспроизвести результаты или использовать его в качестве шаблона для сравнения собственных моделей. В репозитории есть два блокнота: один для нагрузочного тестирования моделей CV, а другой — для NLP. Несколько моделей разных размеров и архитектур были протестированы на разных типах экземпляров GPU: ml.g4dn.2xlarge, ml.g5.2xlarge и ml.p3.2xlarge. Это должно обеспечить разумное сечение производительности по следующим показателям для каждого экземпляра и типа модели:

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

В следующей таблице перечислены протестированные модели.

В следующей таблице перечислены протестированные экземпляры GPU.

Как упоминалось ранее, пример кода могут быть адаптированы к другим моделям и типам экземпляров.

Обратите внимание, что в настоящее время MME поддерживают только один экземпляр GPU. Список поддерживаемых типов экземпляров см. Поддерживаемые алгоритмы, платформы и экземпляры.

Процедура бенчмаркинга состоит из следующих шагов:

1. Получите предварительно обученную модель из концентратора моделей.
2. Подготовьте артефакт модели для использования в SageMaker MME (см. Запускайте несколько моделей глубокого обучения на графическом процессоре с помощью мультимодельных конечных точек Amazon SageMaker. Больше подробностей).
3. Разверните SageMaker MME на экземпляре GPU.
4. Определите максимальное количество моделей, которые можно загрузить в память графического процессора в рамках заданного порога.
5. Используйте платформу нагрузочного тестирования Locust для имитации трафика, который случайным образом вызывает модели, загруженные в экземпляр.
6. Соберите данные и проанализируйте результаты.
7. При желании повторите шаги 2–6 после компиляции модели в TensorRT.

Шаги 4 и 5 требуют более глубокого изучения. Модели в SageMaker GPU MME загружаются в память динамически. Поэтому на шаге 4 мы загружаем исходный артефакт модели в Простой сервис хранения Amazon (Amazon S3) и вызовите модель, чтобы загрузить ее в память. После первоначального вызова мы измеряем объем потребляемой памяти графического процессора, делаем копию исходной модели, вызываем копию модели для ее загрузки в память и снова измеряем общий объем потребляемой памяти графического процессора. Этот процесс повторяется до тех пор, пока не будет достигнут заданный процент использования памяти графического процессора. Для эталонного теста мы установили пороговое значение 90%, чтобы обеспечить разумный буфер памяти для вывода на больших пакетах или оставить некоторое пространство для загрузки других менее часто используемых моделей.

Моделирование пользовательского трафика

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

Locust поддерживает пользовательские формы нагрузочных тестов, которые позволяют вам определять собственные шаблоны трафика. Форма, которая использовалась в этом тесте, показана на следующей диаграмме. В первые 30 секунд конечная точка прогревается 10 одновременными пользователями. Через 30 секунд новые пользователи появляются со скоростью два в секунду, достигая 20 одновременных пользователей на 40-секундной отметке. Затем конечная точка постоянно тестируется с 20 одновременными пользователями до 60-секундной отметки, после чего Locust снова начинает наращивать количество пользователей со скоростью два в секунду до 40 одновременных пользователей. Этот шаблон наращивания и стабильного тестирования повторяется до тех пор, пока конечная точка не будет увеличена до 200 одновременных пользователей. В зависимости от вашего варианта использования вы можете настроить форму нагрузочного теста в locust_benchmark_sm.py, чтобы более точно отражать ожидаемые модели трафика. Например, если вы собираетесь размещать более крупные языковые модели, нагрузочный тест с 200 одновременными пользователями может оказаться невозможным для модели, размещенной на одном экземпляре, и поэтому вы можете уменьшить количество пользователей или увеличить количество экземпляров. Вы также можете увеличить продолжительность нагрузочного теста, чтобы более точно оценить стабильность конечной точки в течение более длительного периода времени.

stages = [
{"duration": 30, "users": 10, "spawn_rate": 5},
{"duration": 60, "users": 20, "spawn_rate": 1},
{"duration": 90, "users": 40, "spawn_rate": 2},
…
]

Обратите внимание, что мы сравнивали конечную точку только с однородными моделями, работающими на согласованных базах обслуживания с использованием PyTorch или TensorRT. Это связано с тем, что MME лучше всего подходят для размещения многих моделей со схожими характеристиками, такими как потребление памяти и время отклика. Шаблоны бенчмаркинга, представленные в Репо GitHub все еще можно использовать для определения того, приведет ли обслуживание разнородных моделей к MME к желаемой производительности и стабильности.

Сравнительные результаты для моделей CV

Используйте записную книжку cv-benchmark.ipynb для запуска нагрузочного тестирования моделей компьютерного зрения. Вы можете настроить имя предварительно обученной модели и параметры типа экземпляра для нагрузочного тестирования производительности на различных комбинациях модели и типа экземпляра. Мы специально протестировали три модели CV в разных диапазонах размеров от самых маленьких до самых больших: resnet50 (25 млн), convnext_base (88М) и vit_large_patch16_224 (304М). Возможно, вам придется изменить код, если вы выберете модель, не входящую в этот список. кроме того, ноутбук по умолчанию устанавливает форму входного изображения на тензор изображения 224x224x3. Не забудьте соответствующим образом настроить входную форму, если вам нужно сравнить модели, которые берут изображение другого размера.

После просмотра всей записной книжки вы получите несколько визуализаций анализа производительности. Первые два детализируют производительность модели по отношению к увеличению числа одновременных пользователей. На следующих рисунках показаны примеры визуализации, созданные для ResNet50 модель, работающая на ml.g4dn.2xlarge, сравнение PyTorch (слева) и TensorRT (справа). Верхние линейные графики показывают задержку и пропускную способность модели по оси Y с увеличением числа одновременных клиентских рабочих операций, отраженных по оси X. Нижние гистограммы показывают количество успешных и неудачных запросов.

Изучив все протестированные нами модели компьютерного зрения, мы заметили следующее:

• Задержка (в миллисекундах) выше, а пропускная способность (запросов в секунду) ниже для более крупных моделей (resnet50 > convnext_base > vit_large_patch16_224).
• Задержка увеличивается пропорционально количеству пользователей, так как на сервере логических выводов появляется больше запросов.
• Большие модели потребляют больше вычислительных ресурсов и могут достигать своих максимальных пределов пропускной способности при меньшем количестве пользователей, чем модели меньшего размера. Это наблюдается с vit_large_patch16_224 модель, которая зафиксировала первый неудачный запрос у 140 одновременных пользователей. Будучи значительно больше, чем две другие протестированные модели, она также имела наибольшее количество неудачных запросов при более высоком уровне параллелизма. Это четкий сигнал о том, что конечной точке потребуется масштабирование за пределы одного экземпляра, если намерение состоит в том, чтобы поддерживать более 140 одновременных пользователей.

В конце записной книжки вы также получите сводное сравнение моделей PyTorch и TensorRT для каждой из четырех ключевых метрик. Из нашего эталонного тестирования все модели CV показали повышение производительности модели после компиляции TensorRT. Принимая наши ResNet50 модели снова в качестве примера, задержка уменьшилась на 32%, а пропускная способность увеличилась на 18%. Хотя максимальное количество одновременных пользователей осталось прежним для ResNet50, обе другие модели показали увеличение числа одновременных пользователей, которых они могут поддерживать, на 14 %. Однако улучшение производительности TensorRT произошло за счет более высокого использования памяти, что привело к меньшему количеству моделей, загруженных MME. Влияние больше для моделей, использующих сверточные нейронные сети (CNN). Фактически, наша модель ResNet50 потребляла примерно в два раза больше памяти графического процессора при переходе от PyTorch к TensorRT, в результате чего загружалось на 50% меньше моделей (46 против 23). Мы диагностируем это поведение далее в следующем разделе.

Сравнительные результаты для моделей НЛП

Для моделей NLP используйте записную книжку nlp-benchmark.ipynb для запуска нагрузочного теста. Настройка ноутбука должна выглядеть очень похоже. Мы протестировали две модели NLP: bert-base-uncased (109M) и roberta-large (335M). Предварительно обученная модель и токенизатор загружаются из концентратора Hugging Face, а тестовая полезная нагрузка генерируется из токенизатора с использованием строки образца. Максимальная длина последовательности по умолчанию равна 128. Если вам нужно протестировать более длинные строки, не забудьте настроить этот параметр. При просмотре блокнота NLP создается тот же набор визуализаций: Pytorch (слева) и TensorRT (справа).

Исходя из этого, мы заметили еще большее преимущество TensorRT в производительности для моделей NLP. Принимая roberta-large модели на экземпляре ml.g4dn.2xlarge, например, задержка логического вывода резко сократилась со 180 миллисекунд до 56 миллисекунд (улучшение на 70 %), а пропускная способность увеличилась на 406 % с 33 запросов в секунду до 167. Кроме того, максимальное количество одновременных количество пользователей увеличилось на 50%; неудачные запросы не наблюдались, пока мы не достигли 180 одновременных пользователей по сравнению со 120 для исходной модели PyTorch. Что касается использования памяти, мы увидели, что для TensorRT загружено на одну модель меньше (с девяти моделей до восьми). Однако негативное влияние намного меньше по сравнению с тем, что мы наблюдали с моделями на основе CNN.

Анализ использования памяти

В следующей таблице показан полный анализ влияния использования памяти при переходе от PyTorch к TensorRT. Ранее мы упоминали, что модели на основе CNN подвержены более негативному влиянию. ResNet50 model сократилось более чем на 50 % в количестве моделей, загружаемых во все три типа инстансов GPU. Convnext_base было еще большее снижение примерно на 70% по всем направлениям. С другой стороны, влияние на модели-трансформеры небольшое или смешанное. vit_large_patch16_224 и roberta-large среднее снижение составило примерно 20% и 3% соответственно, в то время как bert-base-uncased было улучшение примерно на 40%.

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

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

В следующей таблице приведены результаты для всех типов экземпляров. Экземпляр ml.g5.2xlarge обеспечивает наилучшую производительность, в то время как экземпляр ml.p3.2xlarge обычно уступает по производительности, несмотря на то, что является самым дорогим из трех. Экземпляры g5 и g4dn демонстрируют наилучшее значение для рабочих нагрузок логических выводов.

Убирать

После завершения нагрузочного теста очистите сгенерированные ресурсы, чтобы избежать дополнительных расходов. Основными ресурсами являются конечные точки SageMaker и файлы артефактов модели в Amazon S3. Чтобы облегчить вам задачу, файлы записной книжки имеют следующий код очистки, который поможет вам их удалить:

delete_endpoint(sm_client, sm_model_name, endpoint_config_name, endpoint_name) ! aws s3 rm --recursive {trt_mme_path}

Заключение

В этом посте мы поделились результатами тестирования и анализом различных моделей глубоких нейронных сетей, работающих на мультимодельных конечных точках SageMaker с графическим процессором. Результаты и идеи, которыми мы поделились, должны обеспечить разумное сечение производительности по различным показателям и типам экземпляров. В процессе мы также представили рекомендуемый нами подход к проведению эталонного тестирования MME SageMaker с графическим процессором. Предоставленные нами инструменты и образцы кода помогут вам быстро приступить к сравнительному тестированию и принять более обоснованное решение о том, как экономично разместить сотни моделей DNN на аппаратном обеспечении с ускоренными вычислениями. Чтобы начать тестирование собственных моделей с поддержкой MME для GPU, см. Поддерживаемые алгоритмы, платформы и экземпляры и Репо GitHub дополнительные примеры и документацию.

Об авторах

Джеймс Ву является старшим специалистом по архитектуре решений AI/ML в AWS. помогая клиентам разрабатывать и создавать решения AI/ML. Работа Джеймса охватывает широкий спектр вариантов использования машинного обучения, в первую очередь интересуясь компьютерным зрением, глубоким обучением и масштабированием машинного обучения на предприятии. До прихода в AWS Джеймс более 10 лет был архитектором, разработчиком и руководителем технологий, в том числе 6 лет в области проектирования и 4 года в сфере маркетинга и рекламы.

Викрам Эланго является архитектором решений специалиста по искусственному интеллекту и машинному обучению в Amazon Web Services, базирующейся в Вирджинии, США. Vikram помогает клиентам из финансовой и страховой отрасли с проектированием и интеллектуальным лидерством для создания и развертывания приложений машинного обучения в масштабе. В настоящее время он занимается обработкой естественного языка, ответственным искусственным интеллектом, оптимизацией логических выводов и масштабированием машинного обучения на предприятии. В свободное время он любит путешествовать, ходить в походы, готовить и отдыхать со своей семьей.

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

Саураб Триканде является старшим менеджером по продуктам Amazon SageMaker Inference. Он увлечен работой с клиентами и мотивирован целью демократизации машинного обучения. Он фокусируется на основных проблемах, связанных с развертыванием сложных приложений машинного обучения, мультитенантных моделей машинного обучения, оптимизацией затрат и обеспечением более доступного развертывания моделей глубокого обучения. В свободное время Саураб любит ходить в походы, узнавать об инновационных технологиях, следить за TechCrunch и проводить время со своей семьей.

• SEO-контент и PR-распределение. Получите усиление сегодня.
• Платоблокчейн. Интеллект метавселенной Web3. Расширение знаний. Доступ здесь.
• Источник: https://aws.amazon.com/blogs/machine-learning/achieve-high-performance-at-scale-for-model-serving-using-amazon-sagemaker-multi-model-endpoints-with-gpu/