Представляем набор инструментов для сравнительного анализа бессерверных логических выводов Amazon SageMaker

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

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

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

Чтобы определить, является ли бессерверная конечная точка правильным вариантом развертывания с точки зрения затрат и производительности, мы разработали SageMaker Serverless Inference Toolkit для сравнительного анализа, который тестирует различные конфигурации конечных точек и сравнивает наиболее оптимальную конфигурацию с сопоставимым экземпляром хостинга в реальном времени.

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

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

Вы можете загрузить набор инструментов и установить его с сайта Репо GitHub. Начать легко: просто установите библиотеку, создайте Модель SageMakerи укажите имя вашей модели вместе с файлом в формате строк JSON, содержащим образец набора параметров вызова, включая тело полезных данных и тип контента. Предусмотрена удобная функция для преобразования списка примеров аргументов вызова в файл строк JSON или файл Pickle для двоичных полезных данных, таких как изображения, видео или аудио.

Установите набор инструментов

Сначала установите библиотеку сравнительного анализа в свою среду Python с помощью pip:

pip install sm-serverless-benchmarking

Вы можете запустить следующий код из Студия Amazon SageMaker экземпляр, Экземпляр записной книжки SageMakerили любой экземпляр с программный доступ на AWS и соответствующие Управление идентификацией и доступом AWS (IAM) разрешения. Необходимые разрешения IAM описаны в документе Репо GitHub. Дополнительные рекомендации и примеры политик для IAM см. Как Amazon SageMaker работает с IAM. Этот код запускает тест с набором параметров по умолчанию для модели, которая ожидает входные данные CSV с двумя примерами записей. Хорошей практикой является предоставление репрезентативного набора примеров для анализа того, как конечная точка работает с различными входными полезными данными.

from sm_serverless_benchmarking import benchmark
from sm_serverless_benchmarking.utils import convert_invoke_args_to_jsonl
model_name = ""
example_invoke_args = [
        {'Body': '1,2,3,4,5', "ContentType": "text/csv"},
        {'Body': '6,7,8,9,10', "ContentType": "text/csv"}
        ]
example_args_file = convert_invoke_args_to_jsonl(example_invoke_args,
output_path=".")
r = benchmark.run_serverless_benchmarks(model_name, example_args_file)

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

from sm_serverless_benchmarking.sagemaker_runner import run_as_sagemaker_job
run_as_sagemaker_job(
                    role="",
                    model_name="",
                    invoke_args_examples_file="",
                    )

Обратите внимание, что это повлечет за собой дополнительные затраты на запуск экземпляра ml.m5.large SageMaker Processing на время тестирования.

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

Конфигурация бенчмаркинга

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

Существуют два ключевых варианта конфигурации: MemorySizeInMB и MaxConcurrency. MemorySizeInMB настраивает объем памяти, выделяемой экземпляру, и может составлять 1024 МБ, 2048 МБ, 3072 МБ, 4096 МБ, 5120 МБ или 6144 МБ. Количество виртуальных ЦП также масштабируется пропорционально объему выделенной памяти. MaxConcurrency Параметр регулирует количество одновременных запросов, которые может обслужить конечная точка. С MaxConcurrency Если значение равно 1, бессерверная конечная точка может обрабатывать только один запрос за раз.

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

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

Результаты бенчмаркинга

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

По умолчанию инструмент выполняет два теста. Первый — это тест стабильности, который развертывает конечную точку для каждой из указанных конфигураций памяти и вызывает каждую конечную точку с предоставленными образцами полезных данных. Цель этого теста — определить наиболее эффективную и стабильную настройку MemorySizeInMB. Тест фиксирует задержки вызовов и вычисляет ожидаемую стоимость каждого вызова для каждой конечной точки. Затем он сравнивает стоимость с аналогичным экземпляром хостинга в режиме реального времени.

По завершении сравнительного анализа инструмент генерирует несколько выходных данных в указанном формате. result_save_path каталог со следующей структурой каталогов:

├── benchmarking_report
├── concurrency_benchmark_raw_results
├── concurrency_benchmark_summary_results
├── cost_analysis_summary_results
├── stability_benchmark_raw_results
├── stability_benchmark_summary_results

Ассоциация benchmarking_report Каталог содержит консолидированный отчет со всеми сводными результатами, которые мы обрисовываем в этом посте. Дополнительные каталоги содержат необработанные и промежуточные выходные данные, которые можно использовать для дополнительного анализа. Обратитесь к Репо GitHub для более подробного описания каждого выходного артефакта.

Давайте рассмотрим несколько реальных результатов сравнительного тестирования для конечной точки, обслуживающей модель MobileNetV2 TensorFlow компьютерного зрения. Если вы хотите воспроизвести этот пример, обратитесь к примеры блокнотов каталог в репозитории GitHub.

Первым результатом консолидированного отчета является сводная таблица, в которой указаны минимальные, средние, средние и максимальные показатели задержки для каждого MemorySizeInMB успешная настройка размера памяти. Как показано в следующей таблице, средняя задержка вызова (invocation_latency_mean) продолжал улучшаться по мере увеличения конфигурации памяти до 3072 МБ, но после этого улучшения прекратились.

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

Amazon CloudWatch Также предоставляются метрики, связанные с каждой конфигурацией конечной точки. Одним из ключевых показателей здесь является ModelSetupTime, который измеряет, сколько времени потребовалось для загрузки модели, когда конечная точка была вызвана в холодном состоянии. Метрика может не всегда отображаться в отчете, поскольку конечная точка запускается в «горячем» состоянии. А cold_start_delay доступен параметр для указания количества секунд ожидания перед запуском теста на развернутой конечной точке. Установка для этого параметра более высокого значения, например 600 секунд, должна повысить вероятность вызова холодного состояния и повысить вероятность захвата этой метрики. Кроме того, эта метрика с гораздо большей вероятностью будет зафиксирована с помощью теста одновременного вызова, который мы обсудим позже в этом разделе.

В следующей таблице показаны метрики, собранные CloudWatch для каждой конфигурации памяти.

На следующей диаграмме показано соотношение производительности и стоимости различных конфигураций памяти. В одной строке показана расчетная стоимость вызова конечной точки 1 миллион раз, а в другой — средняя задержка ответа. Эти метрики могут помочь вам принять решение о том, какая конфигурация конечной точки является наиболее экономически эффективной. В этом примере мы видим, что средняя задержка стабилизируется после 2048 МБ, тогда как стоимость продолжает расти, что указывает на то, что для этой модели конфигурация объема памяти 2048 будет наиболее оптимальной.

Конечным результатом теста стоимости и стабильности является рекомендуемая конфигурация памяти, а также таблица, сравнивающая стоимость эксплуатации бессерверной конечной точки с сопоставимым экземпляром хостинга SageMaker. На основе собранных данных инструмент определил, что конфигурация 2048 МБ является наиболее оптимальной для данной модели. Хотя конфигурация 3072 обеспечивает примерно на 10 миллисекунд лучшую задержку, это приводит к увеличению стоимости на 30 %: с 4.55 до 5.95 долларов США за 1 миллион запросов. Кроме того, выходные данные показывают, что бессерверная конечная точка обеспечит экономию до 88.72 % по сравнению с сопоставимым экземпляром хостинга в реальном времени, когда количество запросов на вызов составляет менее 1 миллиона в месяц, и выходит на уровень безубыточности с конечной точкой реального времени после 8.5 миллионов запросов.

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

Например, установив concurrency_benchmark_max_conc parameter к [4, 8] и concurrency_num_clients_multiplier to [1, 1.5, 2] запускаются две конечные точки: одна с MaxConcurency из 4, а остальные 8. Затем каждая конечная точка оценивается с помощью (MaxConcurency множитель x) количество смоделированных одновременных клиентов, что для конечной точки с параллелизмом 4 соответствует тестам нагрузочного теста с 4, 6 и 8 одновременными клиентами.

Первым результатом этого теста является таблица, в которой показаны показатели задержки, исключения регулирования и показатели транзакций в секунду (TPS), связанные с каждым MaxConcurrency конфигурация с различным количеством одновременных клиентов. Эти показатели помогают определить подходящую MaxConcurrency настройка для обработки ожидаемой нагрузки трафика. В следующей таблице мы видим, что конечная точка, настроенная с максимальным уровнем параллелизма 8, могла обслуживать до 16 одновременных клиентов только с двумя исключениями регулирования из 2,500 вызовов, выполненных в среднем с 24 транзакциями в секунду.

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

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

Заключение

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

Дополнительные ресурсы

Об авторах

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

Дхавал Патель является главным архитектором машинного обучения в AWS. Он работал с организациями, начиная от крупных предприятий и заканчивая стартапами среднего размера, над проблемами, связанными с распределенными вычислениями и искусственным интеллектом. Он фокусируется на глубоком обучении, включая НЛП и области компьютерного зрения. Он помогает клиентам добиться высокопроизводительного логического вывода модели в SageMaker.

Ришаб Рэй Чаудхури — старший менеджер по продукту в Amazon SageMaker, специализирующийся на выводах машинного обучения. Он увлечен инновациями и созданием новых возможностей для клиентов машинного обучения на AWS, которые помогают масштабировать их рабочие нагрузки. В свободное время любит путешествовать и готовить. Вы можете найти его на LinkedIn.