Обеспечьте хостинг с низкой задержкой для моделей машинного обучения на основе дерева решений на сервере NVIDIA Triton Inference Server в Amazon SageMaker.

Развертывание модели машинного обучения (ML) может иметь очень высокие требования к производительности и задержке для бизнеса. Случаи использования, такие как обнаружение мошенничества и размещение рекламы, являются примерами, когда миллисекунды имеют значение и имеют решающее значение для успеха бизнеса. Необходимо соблюдать строгие соглашения об уровне обслуживания (SLA), и для типичного запроса может потребоваться несколько шагов, таких как предварительная обработка, преобразование данных, логика выбора модели, объединение моделей и постобработка. В масштабе это часто означает поддержание огромного объема трафика при сохранении низкой задержки. Общие шаблоны проектирования включают конвейеры последовательного вывода, ансамбли (рассеивание-сбор) и рабочие процессы бизнес-логики, что приводит к реализации всего рабочего процесса запроса в виде направленного ациклического графа (DAG). Однако по мере усложнения рабочих процессов это может привести к увеличению общего времени отклика, что, в свою очередь, может негативно сказаться на опыте конечных пользователей и поставить под угрозу бизнес-цели. Triton может решить эти случаи использования, когда несколько моделей составляются в конвейере с входными и выходными тензорами, связанными между собой, помогая вам справляться с этими рабочими нагрузками.

Когда вы оцениваете свои цели в отношении вывода модели ML, можно рассмотреть множество вариантов, но немногие из них столь же эффективны и проверены, как Создатель мудреца Амазонки Сервер вывода Triton. SageMaker с Triton Inference Server был популярным выбором для многих клиентов, поскольку он специально разработан для максимального увеличения пропускной способности и использования оборудования при сверхнизкой (однозначное число миллисекунд) задержке логического вывода. Он имеет широкий спектр поддерживаемых платформ машинного обучения (включая TensorFlow, PyTorch, ONNX, XGBoost и NVIDIA TensorRT) и серверных частей инфраструктуры, включая графические процессоры NVIDIA, ЦП и Вывод AWS. Кроме того, Triton Inference Server интегрирован с SageMaker, полностью управляемой сквозной службой машинного обучения, предоставляющей возможности логического вывода в реальном времени для размещения моделей.

В этом посте мы рассмотрим развертывание рабочей нагрузки ансамбля обнаружения мошенничества в SageMaker с помощью Triton Inference Server.

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

Для любого проекта важно иметь список требований и оценку усилий, чтобы приблизительно оценить общую стоимость проекта. Важно оценить рентабельность инвестиций (ROI), которая поддерживает решение организации. При перемещении рабочей нагрузки в Triton необходимо учитывать следующие моменты:

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

• Бюджет задержки на стороне клиента – Он определяет максимально допустимое время ожидания ответа на запрос на вывод на стороне клиента, обычно выражаемое в процентилях. Для рабочих нагрузок, требующих бюджета задержки около десятков миллисекунд, сетевые передачи могут стать дорогими, поэтому лучше использовать модели на периферии.
• Размер распределения полезной нагрузки данных – Полезная нагрузка, часто называемая тело сообщения, — данные запроса, передаваемые от клиента к модели, а также данные ответа, передаваемые от модели к клиенту. Размер полезной нагрузки часто сильно влияет на задержку, и его следует учитывать.
• Формат данных – Это указывает, как полезная нагрузка отправляется в модель ML. Формат может быть удобочитаемым, например JSON и CSV, однако существуют также двоичные форматы, которые часто сжаты и имеют меньший размер. Это компромисс между накладными расходами на сжатие и размером передачи, означающий, что циклы ЦП и задержка добавляются для сжатия или распаковки, чтобы сохранить байты, передаваемые по сети. В этом посте показано, как использовать как JSON, так и двоичные форматы.
• Программный стек и необходимые компоненты – Стек — это набор компонентов, которые работают вместе для поддержки приложения машинного обучения, включая операционную систему, среды выполнения и уровни программного обеспечения. Triton поставляется со встроенными популярными платформами машинного обучения, называемыми бэкэнды, такие как ONNX, TensorFlow, FIL, OpenVINO, собственный Python и другие. Вы также можете создать настраиваемый бэкэнд для собственных доморощенных компонентов. В этом посте рассматривается модель XGBoost и предварительная обработка данных, которые мы переносим на предоставляемые NVIDIA серверные части FIL и Python Triton соответственно.

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

Сервер вывода NVIDIA Triton

Triton Inference Server был разработан с нуля, чтобы позволить командам развертывать, запускать и масштабировать обученные модели ИИ из любой среды в инфраструктуре на основе графического процессора или процессора. Кроме того, он был оптимизирован для обеспечения высокопроизводительного вывода в масштабе с такими функциями, как динамическая пакетная обработка, одновременные запуски, оптимальная конфигурация модели, ансамбль моделей и поддержка потоковых входных данных.

На следующей диаграмме показан пример конвейера ансамбля NVIDIA Triton.

Рабочие нагрузки должны учитывать возможности, которые Triton предоставляет вместе с хостингом SageMaker, чтобы максимизировать предлагаемые преимущества. Например, Triton поддерживает HTTP, а также C API, которые обеспечивают гибкость, а также оптимизацию полезной нагрузки при необходимости. Как упоминалось ранее, Triton поддерживает сразу несколько популярных фреймворков, включая TensorFlow, PyTorch, ONNX, XGBoost и NVIDIA TensorRT. Эти платформы поддерживаются через серверные части Triton, и в тех редких случаях, когда серверная часть не поддерживает ваш вариант использования, Triton позволяет вам реализовать собственное решение и легко его интегрировать..

На следующей диаграмме показан пример архитектуры NVIDIA Triton.

NVIDIA Triton на SageMaker

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

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

Эта широта возможностей, модульность и простота использования различных платформ обслуживания делают SageMaker и Triton мощной парой.

Поддержка серверной части NVIDIA FIL

Для Выпуск версии 22.05 Triton, NVIDIA теперь поддерживает модели леса, обученные несколькими популярными платформами машинного обучения, включая XGBoost, LightGBM, Scikit-learn и cuML. При использовании серверной части FIL для Triton вы должны убедиться, что предоставленные вами артефакты модели поддерживаются. Например, FIL поддерживает model_type xgboost, xgboost_json, lightgbmили treelite_checkpoint, указывающий, находится ли предоставленная модель в двоичном формате XGBoost, формате XGBoost JSON, текстовом формате LightGBM или двоичном формате Treelite соответственно.

Эта внутренняя поддержка необходима для использования в нашем примере, поскольку FIL поддерживает модели XGBoost. Единственное, что нужно проверить, — это убедиться, что модель, которую мы развертываем, поддерживает двоичные форматы или форматы JSON.

В дополнение к обеспечению правильного формата модели следует принять во внимание и другие соображения. Серверная часть FIL для Triton предоставляет разработчикам настраиваемые параметры для настройки своих рабочих нагрузок и оптимизации производительности запуска модели. Конфигурация dynamic_batching позволяет Triton удерживать запросы на стороне клиента и группировать их на стороне сервера, чтобы эффективно использовать параллельные вычисления FIL для вывода всего пакета вместе. Опция max_queue_delay_microseconds предлагает безотказный контроль того, как долго Triton ожидает формирования партии. FIL поставляется с эксплейнером Shapley, который можно активировать в конфигурации treeshap_output; однако вы должны иметь в виду, что выходные данные Shapley снижают производительность из-за размера вывода. Еще одним важным аспектом является storage_type чтобы найти компромисс между объемом памяти и временем выполнения. Например, использование хранилища в качестве SPARSE может снизить потребление памяти, тогда как DENSE может снизить производительность запуска вашей модели за счет более высокого использования памяти. Выбор наилучшего варианта для каждого из них зависит от вашей рабочей нагрузки и вашего бюджета задержки, поэтому мы рекомендуем более подробно изучить все варианты в Часто задаваемые вопросы о серверной части FIL и список конфигураций, доступных в FIL.

Шаги по размещению модели на тритоне

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

Определите свою рабочую нагрузку

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

Определите текущие и целевые показатели эффективности и другие цели, которые могут применяться

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

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

Чтобы определить, может ли Triton удовлетворить ваши требования, вы должны обратить внимание на две основные проблемы. Во-первых, убедиться, что Triton может работать с приемлемым интерфейсом, таким как HTTP или C API.

Как упоминалось ранее, также важно определить, поддерживает ли Triton серверную часть, которая может обслуживать ваши артефакты. Triton поддерживает ряд бэкэнды специально созданные для поддержки различных фреймворков, таких как PyTorch и TensorFlow. Убедитесь, что ваши модели поддерживаются и что у вас правильный формат модели, который ожидает Triton. Для этого сначала проверьте, какие форматы моделей поддерживает серверная часть Triton. Во многих случаях это не требует никаких изменений в модели. В других случаях ваша модель может потребовать преобразования в другой формат. В зависимости от исходного и целевого формата существуют различные варианты, такие как преобразование Файл рассола Python для использования двоичного формата контрольной точки Treelite.

Для этого варианта использования мы определяем Серверная часть FIL может поддерживать модель XGBoost без каких-либо изменений, и что мы можем использовать Серверная часть Python для предварительной обработки. Благодаря функции ансамбля Triton вы можете еще больше оптимизировать свою рабочую нагрузку, избегая дорогостоящих сетевых вызовов между экземплярами хостинга.

Создайте план и оцените усилия, необходимые для использования Triton для хостинга

Давайте поговорим о плане переноса ваших моделей на Тритон. Для каждого развертывания Triton требуется следующее:

• Артефакты модели, необходимые для серверных частей Triton
• Конфигурационные файлы Тритона
• Папка репозитория модели с правильной структурой

Мы покажем пример того, как создать эти зависимости развертывания позже в этом посте.

Запустите план и проверьте результаты

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

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

Реализация

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

Первая записная книжка показывает существующую записную книжку вашей организации, которая использует БЫСТРЫЕ набор библиотек и ядро ​​RAPIDS Conda. Этот инстанс работает на инстансе типа G4DN, предоставленном AWS, который ускоряется с помощью графического процессора с использованием процессоров NVIDIA T4.

Задачи предварительной обработки в этом примере выигрывают от ускорения графического процессора и интенсивно используют библиотеки cuML и cuDF. Примером этого является следующий код, где показано кодирование меток категорий с использованием cuML. Мы также генерируем label_encoders.pkl файл, который мы можем использовать для сериализации кодировщиков и использования их для предварительной обработки во время вывода.

Первая записная книжка завершается обучением нашей модели XGBoost и соответствующим сохранением артефактов.

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

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

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

• Артефакты предварительной обработки (model.py, label_encoders.pkl)
• Артефакты модели XGBoost (xgboost.json)

Серверная часть Python в Triton требует, чтобы мы использовали среду Conda в качестве зависимости. В этом случае мы используем серверную часть Python для предварительной обработки необработанных данных перед их подачей в модель XGBoost, запускаемую в серверной части FIL. Несмотря на то, что изначально мы использовали библиотеки RAPIDS cuDF и cuML для предварительной обработки данных (как упоминалось ранее с использованием нашего графического процессора), здесь мы используем Pandas и Scikit-learn в качестве зависимостей предварительной обработки для времени вывода (с использованием нашего ЦП). Мы делаем это по трем причинам:

• Чтобы показать, как создать среду Conda для ваших зависимостей и как упаковать ее в ожидаемый формат бэкендом Triton Python.
• Показывая модель предварительной обработки, работающую в бэкэнде Python на ЦП, в то время как модель XGBoost работает на графическом процессоре в бэкэнде FIL, мы показываем, как каждая модель в ансамблевом конвейере Triton может работать на другом бэкэнде фреймворка и работать на различном оборудовании с разными конфигурации.
• В нем показано, как библиотеки RAPIDS (cuDF, cuML) совместимы с их аналогами для ЦП (Pandas, Scikit-learn). Таким образом, мы можем показать, как LabelEncoders созданный в cuML, можно использовать в Scikit-learn и наоборот. Обратите внимание: если вы планируете предварительно обрабатывать большие объемы табличных данных во время логического вывода, вы все равно можете использовать RAPIDS для ускорения их с помощью графического процессора.

Напомним, что мы создали label_encoders.pkl файл в первой записной книжке. Для кодировки категорий больше ничего не нужно делать, кроме как включить ее в наш model.py файл для предварительной обработки.

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

Для модели XGBoost больше ничего делать не нужно. Мы обучили модель на первом ноутбуке, и серверная часть Triton FIL не требует дополнительных усилий для моделей XGBoost.

Далее нам понадобятся файлы конфигурации Triton. Для каждой модели в ансамбле Triton требуется config.pbtxt файл. Кроме того, мы также создаем config.pbtxt файл для ансамбля в целом. Эти файлы позволяют Triton знать метаданные об ансамбле с такой информацией, как входные и выходные данные, которые мы ожидаем, а также помогают определить DAG, связанный с ансамблем.

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

После того, как у нас есть эти три предварительных условия, мы создаем сжатый файл в качестве пакета для развертывания и загружаем его в Простой сервис хранения Amazon (Amazon S3).

Теперь мы можем создать модель SageMaker из репозитория моделей, который мы загрузили в Amazon S3 на предыдущем шаге.

На этом шаге мы также предоставляем дополнительную переменную среды SAGEMAKER_TRITON_DEFAULT_MODEL_NAME, который указывает имя модели, которую Triton загружает. Значение этого ключа должно соответствовать имени папки в пакете модели, загруженном в Amazon S3. Эта переменная необязательна в случае одной модели. В случае ансамблевых моделей этот ключ необходимо указать для запуска Triton в SageMaker.

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

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

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

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

Обзор

В этом посте мы познакомили вас с развертыванием рабочей нагрузки ансамбля XGBoost в SageMaker с помощью Triton Inference Server. Перенос рабочих нагрузок в Triton на SageMaker может окупиться. Как и при любом внедрении технологии, процесс проверки и план являются ключевыми, и мы подробно описали пятиэтапный процесс, который поможет вам понять, что следует учитывать при перемещении ваших рабочих нагрузок. Кроме того, мы подробно рассмотрели шаги, необходимые для развертывания ансамбля, использующего предварительную обработку Python и модель XGBoost на Triton в SageMaker.

SageMaker предоставляет инструменты для устранения недифференцированной тяжелой работы на каждом этапе жизненного цикла машинного обучения, тем самым облегчая быстрые эксперименты и исследования, необходимые для полной оптимизации развертывания вашей модели. Поддержка хостинга SageMaker для Triton Inference Server обеспечивает рабочие нагрузки с низкой задержкой и высоким количеством транзакций в секунду (TPS).

Вы можете найти записные книжки, использованные для этого примера, на GitHub.

---

Об авторе

Джеймс Парк работает архитектором решений в Amazon Web Services. Он работает с Amazon.com над проектированием, созданием и развертыванием технологических решений на AWS и проявляет особый интерес к искусственному интеллекту и машинному обучению. В свободное время он любит искать новые культуры, новый опыт и быть в курсе последних технологических тенденций.

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

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

Бруно Агиар де Мело является инженером по разработке программного обеспечения в Amazon.com, где он помогает научным группам создавать, развертывать и выпускать рабочие нагрузки машинного обучения. Он интересуется инструментами и контролируемыми аспектами на этапе моделирования/проектирования машинного обучения, которые необходимо учитывать и измерять с пониманием того, что производительность выполнения модели так же важна, как и качество модели, особенно в случаях использования с ограничениями по задержке. В свободное время любит вино, настольные игры и готовку.

Элиут Триана является менеджером по связям с разработчиками в NVIDIA. Он связывает руководителей продуктов, разработчиков и ученых Amazon и AWS с технологами и руководителями продуктов NVIDIA, чтобы ускорить рабочие нагрузки Amazon ML/DL, продукты EC2 и сервисы AWS AI. Кроме того, Элиут страстный байкер, лыжник и игрок в покер.