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

Приложения машинного обучения (ML) сложны в развертывании и часто требуют нескольких моделей ML для обслуживания одного запроса на вывод. Типичный запрос может проходить через несколько моделей с такими этапами, как предварительная обработка, преобразование данных, логика выбора модели, объединение моделей и постобработка. Это привело к развитию общих шаблонов проектирования, таких как конвейеры последовательного вывода, ансамбли (разброс-сбор) и рабочие процессы бизнес-логики, что привело к реализации всего рабочего процесса запроса в виде направленного ациклического графа (DAG). Однако по мере усложнения рабочих процессов это приводит к увеличению общего времени отклика или задержки этих приложений, что, в свою очередь, влияет на общее взаимодействие с пользователем. Кроме того, если эти компоненты размещены в разных экземплярах, дополнительная сетевая задержка между этими экземплярами увеличивает общую задержку. Рассмотрим пример популярного варианта использования машинного обучения для виртуального помощника в службе поддержки клиентов. Типичный запрос может пройти несколько этапов, включая распознавание речи, обработку естественного языка (NLP), отслеживание состояния диалога, политику диалога, генерацию текста и, наконец, преобразование текста в речь. Кроме того, чтобы сделать взаимодействие с пользователем более персонализированным, вы также можете использовать современные модели НЛП на основе трансформеров, такие как различные версии БЕРТ, БАРТи GPT. Конечным результатом является длительное время отклика для этих ансамблей моделей и плохое качество обслуживания клиентов.

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

В ноябре 2021 года мы объявили интеграция Triton Inference Server в SageMaker. AWS тесно сотрудничала с NVIDIA, чтобы вы могли получить лучшее из обоих миров и упростить развертывание модели с помощью Triton на AWS.

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

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

Настройка производительности и оптимизация для обслуживания моделей в SageMaker

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

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

Вывод в реальном времени и задержка в SageMaker

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

• Задержка контейнера – время, необходимое для отправки запроса, получения ответа из контейнера модели и завершения логического вывода в контейнере. Эта метрика доступна в Amazon CloudWatch как часть Метрики вызова опубликовано SageMaker.
• Задержка модели – Общее время, затраченное всеми контейнерами SageMaker в конвейер вывода. Эта метрика доступна в Amazon CloudWatch как часть Метрики вызова опубликовано SageMaker.
• Накладная задержка – Измеряется с момента, когда SageMaker получает запрос, до момента, когда он возвращает ответ клиенту, за вычетом задержки модели. Эта метрика доступна в Amazon CloudWatch как часть Метрики вызова опубликовано SageMaker.
• Сквозная задержка – Измеряется с момента, когда клиент отправляет запрос на вывод, до получения ответа. Клиенты могут опубликовать это как пользовательскую метрику в Amazon CloudWatch.

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

Задержка контейнера зависит от нескольких факторов; следующие являются одними из наиболее важных:

• Базовый протокол (HTTP(s)/gRPC), используемый для связи с сервером логических выводов.
• Накладные расходы, связанные с созданием новых соединений TLS
• Время десериализации полезной нагрузки запроса/ответа
• Функции организации очереди и пакетной обработки запросов, предоставляемые базовым сервером логического вывода.
• Возможности планирования запросов, предоставляемые базовым сервером логического вывода.
• Базовая производительность сервера логических выводов во время выполнения
• Производительность библиотек предварительной и постобработки перед вызовом функции предсказания модели
• Базовая производительность серверной части платформы машинного обучения
• Оптимизация для конкретной модели и аппаратного обеспечения

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

Обзор вариантов использования

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

В этом посте мы сравним вариант использования NLP с использованием конечной точки SageMaker в реальном времени на основе контейнера Triton Inference Server и порекомендуем оптимизацию настройки производительности для нашего варианта использования ML. Мы используем большой, предварительно обученный трансформер на основе Hugging Face. БЕРТ большой без корпуса модель, которая имеет около 336 миллионов параметров модели. Входное предложение, используемое для модели двоичной классификации, дополняется и усекается до максимальной длины входной последовательности 512 токенов. Нагрузочный тест логического вывода имитирует 500 вызовов в секунду (максимум 30,000 XNUMX вызовов в минуту) и ModelLatency менее 0.5 секунды (500 миллисекунд).

В следующей таблице представлена ​​наша тестовая конфигурация.

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

Triton Inference Server специально разработан для обеспечения масштабируемого, быстрого и простого развертывания моделей в производстве. Triton поддерживает множество основных сред ИИ, включая TensorFlow, TensorRT, PyTorch, XGBoost и ONNX. Используя настраиваемый серверный модуль Python и C++, вы также можете реализовать свою рабочую нагрузку логического вывода для более настраиваемых вариантов использования.

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

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

Динамическое пакетирование

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

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

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

dynamic_batching { preferred_batch_size: 16 max_queue_delay_microseconds: 100 }

Запуск моделей одновременно

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

На следующем рисунке показано, как легко настроить различные политики развертывания модели, изменив всего несколько строк кода. Например, конфигурация A (слева) показывает, что вы можете транслировать одну и ту же конфигурацию двух экземпляров модели bert-large-uncased для всех доступных графических процессоров. Напротив, конфигурация B (в центре) показывает другую конфигурацию только для графического процессора 0 без изменения политик для других графических процессоров. Вы также можете развернуть экземпляры разных моделей на одном графическом процессоре, как показано в конфигурации C (справа).

В конфигурации C вычислительный экземпляр может обрабатывать два одновременных запроса для модели DistilGPT-2 и семь одновременных запросов для модели DistilGPT-XNUMX. bert-large-uncased модель параллельно. С помощью этих оптимизаций можно лучше использовать аппаратные ресурсы для процесса обслуживания, тем самым повышая пропускную способность и обеспечивая более высокую экономическую эффективность для вашей рабочей нагрузки.

ТензорРТ

NVIDIA ТензорРТ — это SDK для высокопроизводительного вывода на основе глубокого обучения, который без проблем работает с Triton. TensorRT, который поддерживает все основные фреймворки глубокого обучения, включает в себя оптимизатор выводов и среду выполнения, которая обеспечивает низкую задержку и высокую пропускную способность для выполнения выводов с огромными объемами данных с помощью мощных оптимизаций.

TensorRT оптимизирует граф, чтобы свести к минимуму объем памяти, освобождая ненужную память и эффективно повторно используя ее. Кроме того, компиляция TensorRT объединяет разреженные операции внутри графа модели, чтобы сформировать более крупное ядро, чтобы избежать накладных расходов на несколько запусков небольшого ядра. Автонастройка ядра помогает вам полностью использовать аппаратное обеспечение, выбирая лучший алгоритм на вашем целевом графическом процессоре. Потоки CUDA позволяют моделям работать параллельно, чтобы максимизировать использование вашего графического процессора для достижения наилучшей производительности. И последнее, но не менее важное: метод квантования может полностью использовать ускорение ядер Tensor со смешанной точностью для запуска модели в FP32, TF32, FP16 и INT8 для достижения наилучшей производительности логического вывода.

Triton на хостинге SageMaker

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

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

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

SageMaker Inference Recommender для сравнительного анализа результатов тестирования

Мы используем SageMaker Inference Recommender для проведения наших экспериментов. SageMaker Inference Recommender предлагает два типа заданий: стандартное и расширенное, как показано на следующей диаграмме.

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

Расширенное задание предлагает больше элементов управления для дальнейшей точной настройки производительности. Эти элементы управления имитируют реальную среду и производственные требования. Среди этих элементов управления — шаблон трафика, цель которого — подготовить шаблон запроса для эталонных тестов. Вы можете установить рампы или постоянный трафик, используя несколько фаз схемы движения. Например, Инициалнумберофусерс 1, Спаунрейт 1, и Длительность в секундах 600 может привести к увеличению трафика в течение 10 минут с 1 одновременным пользователем в начале и 10 в конце. Кроме того, на элементах управления МаксВызовы и ModelLatencyThresholds установить порог производства, чтобы при превышении одного из порогов бенчмаркинг останавливался.

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

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

Настройка эксперимента

Мы используем пользовательскую функцию нагрузочного теста SageMaker Inference Recommender для сравнения профиля NLP, описанного в нашем примере использования. Сначала мы определяем следующие предпосылки, связанные с моделью NLP и задачей ML. SageMaker Inference Recommender использует эту информацию для извлечения образа Docker для вывода из Реестр Amazon Elastic Container (Amazon ECR) и зарегистрируйте модель в реестре моделей SageMaker.

Конфигурации шаблонов трафика в SageMaker Inference Recommender позволяют нам определять различные этапы пользовательского нагрузочного теста. Нагрузочный тест начинается с двух начальных пользователей и порождает двух новых пользователей каждую минуту в течение 25 минут (1500 секунд), как показано в следующем коде:

"TrafficPattern": { "TrafficType": "PHASES", "Phases": [ { "InitialNumberOfUsers": 2, "SpawnRate": 2, "DurationInSeconds": 1500 }, ],
}

Мы экспериментируем с нагрузочным тестированием одной и той же модели в двух разных состояниях. В экспериментах на основе PyTorch используется стандартная неизмененная модель PyTorch. Для экспериментов на основе TensorRT мы заранее конвертируем модель PyTorch в механизм TensorRT.

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

Результаты испытаний и наблюдения

Мы провели нагрузочные тесты для трех типов экземпляров в одном семействе g4dn: ml.g4dn.xlarge, ml.g4dn.2xlarge и ml.g4dn.12xlarge. Все типы инстансов g4dn имеют доступ к графическим процессорам NVIDIA T4 Tensor Core и процессорам Intel Cascade Lake 2-го поколения. Логика выбора типов инстансов заключалась в том, чтобы иметь как инстанс с одним доступным GPU, так и инстанс с доступом к нескольким GPU — четырем в случае ml.g4dn.12xlarge. Кроме того, мы хотели проверить, приведет ли увеличение емкости виртуального ЦП в экземпляре только с одним доступным графическим процессором к улучшению соотношения цены и производительности.

Давайте сначала рассмотрим ускорение индивидуальной оптимизации. На следующем графике показано, что оптимизация TensorRT обеспечивает снижение задержки модели на 50 % по сравнению с нативной задержкой в ​​PyTorch на экземпляре ml.g4dn.xlarge. Это сокращение задержки увеличивается более чем в три раза на экземплярах ml.g4dn.12xlarge с несколькими графическими процессорами. Между тем, повышение пропускной способности на 30% одинаково для обоих экземпляров, что приводит к повышению экономической эффективности после применения оптимизаций TensorRT.

С динамической пакетной обработкой мы можем добиться двукратного увеличения пропускной способности, используя одну и ту же аппаратную архитектуру во всех экспериментальных экземплярах ml.g2dn.xlarge, ml.g4dn.4xlarge и ml.g2dn.4xlarge без заметного увеличения задержки.

Точно так же параллельное выполнение модели позволяет нам получить повышение пропускной способности примерно в 3-4 раза за счет максимального использования графического процессора на экземпляре ml.g4dn.xlarge и примерно в 2 раза на экземпляре ml.g4dn.2xlarge и экземпляре ml с несколькими графическими процессорами. g4dn.12xlarge. Это увеличение пропускной способности происходит без каких-либо накладных расходов на задержку.

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

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

[2] Стоимость часа в приведенной выше таблице рассчитывается на основе начального количества экземпляров и цены для типа экземпляра.

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

• Компиляция TensorRT оказывает наиболее надежное влияние на все типы инстансов. Количество транзакций в минуту на инстанс увеличилось на 30–35 % при постоянном снижении затрат примерно на 25 % по сравнению с производительностью движка TensorRT по сравнению с PyTorch BERT по умолчанию (pt-base). Повышенная производительность движка TensorRT усугубляется и используется другими протестированными функциями настройки производительности.
• Загрузка двух моделей на каждый GPU (экземплярную группу) почти строго удваивала все измеренные метрики. Количество вызовов в минуту на экземпляр увеличилось примерно на 80–90 %, что привело к снижению стоимости в диапазоне 50 %, почти как если бы мы использовали два графических процессора. Фактически, Amazon CloudWatch метрики для наших экспериментов на g4dn.2xlarge (в качестве примера) подтверждают, что загрузка ЦП и ГП удваивается, когда мы настраиваем группу экземпляров из двух моделей.

Дополнительные советы по производительности и оптимизации затрат

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

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

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

Заключение

В этом посте мы рассмотрели несколько параметров, которые вы можете использовать, чтобы максимизировать производительность вашей конечной точки SageMaker в реальном времени для обслуживания моделей PyTorch BERT с Triton Inference Server. Мы использовали SageMaker Inference Recommender для проведения эталонных тестов для точной настройки этих параметров. Эти параметры, по сути, связаны с оптимизацией модели на основе TensorRT, что приводит к улучшению времени отклика почти на 50% по сравнению с неоптимизированной версией. Кроме того, одновременный запуск моделей и использование динамической пакетной обработки Triton привело к увеличению производительности почти на 70%. Точная настройка этих параметров также привела к общему снижению стоимости логического вывода.

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

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

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

Об авторах

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

Жоао Моура является специалистом по архитектуре решений AI/ML в Amazon Web Services. В основном он фокусируется на примерах использования НЛП и помогает клиентам оптимизировать обучение и развертывание модели глубокого обучения. Он также является активным сторонником решений машинного обучения с низким кодом и специализированного оборудования для машинного обучения.

Мохан Ганди является старшим инженером-программистом в AWS. Он работал с AWS последние 9 лет и работал над различными сервисами AWS, такими как EMR, EFA и RDS на Outposts. В настоящее время он сосредоточен на улучшении SageMaker Inference Experience. В свободное время любит ходить в походы и бегать марафоны.

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

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

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

• Коинсмарт. Лучшая в Европе биржа биткойнов и криптовалют.
• Платоблокчейн. Интеллект метавселенной Web3. Расширение знаний. БЕСПЛАТНЫЙ ДОСТУП.
• КриптоХок. Альткоин Радар. Бесплатная пробная версия.
• Источник: https://aws.amazon.com/blogs/machine-learning/achieve-hyperscale-performance-for-model-serving-using-nvidia-triton-inference-server-on-amazon-sagemaker/