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

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

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

У листопаді 2021 року ми оголосили інтеграція Triton Inference Server на SageMaker. AWS тісно співпрацює з NVIDIA, щоб ви могли отримати найкраще з обох світів і спростити розгортання моделі з Triton на AWS.

У цій публікації ми розглянемо найкращі методи розгортання моделей трансформаторів у масштабі на графічних процесорах за допомогою Triton Inference Server на SageMaker. Спочатку ми почнемо з короткого викладу ключових концепцій щодо затримки в SageMaker та огляду рекомендацій щодо налаштування продуктивності. Далі ми надаємо огляд Triton та його функцій, а також приклад коду для розгортання на SageMaker. Нарешті, ми виконуємо навантажувальні тести за допомогою SageMaker Inference Recommender і узагальнити ідеї та висновки з навантажувального тестування популярної моделі трансформатора, наданої Hugging Face.

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

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

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

Якщо ви використовуєте SageMaker для розгортання моделей ML, вам потрібно вибрати екземпляр обчислення з найкращою ціною та продуктивністю, що є складним і повторюваним процесом, який може зайняти тижні експериментів. По-перше, вам потрібно вибрати правильний тип екземпляра ML із понад 70 варіантів на основі вимог до ресурсів ваших моделей та розміру вхідних даних. Далі потрібно оптимізувати модель для вибраного типу екземпляра. Нарешті, вам потрібно налаштувати інфраструктуру та керувати нею для виконання навантажувальних тестів і налаштування хмарної конфігурації для оптимальної продуктивності та вартості. Все це може затримати розгортання моделі та час виходу на ринок. Крім того, вам потрібно оцінити компроміс між затримкою, пропускною здатністю та вартістю, щоб вибрати оптимальну конфігурацію розгортання. SageMaker Inference Recommender автоматично вибирає правильний тип екземпляра обчислення, кількість екземплярів, параметри контейнера та оптимізацію моделі для висновку, щоб максимізувати пропускну здатність, зменшити затримку та мінімізувати витрати.

Висновок і затримка в режимі реального часу в SageMaker

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

• Затримка контейнера – Час, необхідний для відправки запиту, отримання відповіді з контейнера моделі та повного висновку в контейнері. Ця метрика доступна в Amazon CloudWatch як частина Метрики виклику опубліковано SageMaker.
• Затримка моделі – Загальний час, затрачений усіма контейнерами SageMaker в один конвеєр висновку. Ця метрика доступна в Amazon CloudWatch як частина Метрики виклику опубліковано SageMaker.
• Накладна затримка – Вимірюється з моменту отримання запиту SageMaker до повернення клієнту відповіді за вирахуванням затримки моделі. Ця метрика доступна в Amazon CloudWatch як частина Метрики виклику опубліковано SageMaker.
• Наскрізна затримка – Вимірюється з моменту відправлення клієнтом запиту на висновок до отримання відповіді. Клієнти можуть опублікувати це як спеціальний показник у Amazon CloudWatch.

Наступна діаграма ілюструє ці компоненти.

Затримка контейнера залежить від кількох факторів; серед найважливіших є такі:

• Базовий протокол (HTTP(s)/gRPC), що використовується для зв’язку з сервером висновку
• Накладні витрати, пов’язані зі створенням нових з’єднань TLS
• Час десеріалізації корисного навантаження запиту/відповіді
• Функції черги та пакетної обробки запитів, які надаються базовим сервером висновку
• Можливості планування запитів, які надаються базовим сервером висновку
• Основна продуктивність під час виконання сервера висновку
• Продуктивність бібліотек попередньої та постобробки перед викликом функції передбачення моделі
• Основна продуктивність платформи ML
• Оптимізація для конкретної моделі та обладнання

У цій публікації ми зосередимося насамперед на оптимізації затримки контейнера разом із загальною пропускною здатністю та вартістю. Зокрема, ми досліджуємо налаштування продуктивності Triton Inference Server, що працює всередині контейнера SageMaker.

Огляд варіантів використання

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

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

У наведеній нижче таблиці підсумовано нашу конфігурацію контрольного тесту.

Сервер NVIDIA Triton Inference

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

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

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

Динамічне дозування

Багато практиків мають тенденцію виконувати висновки послідовно, коли сервер викликається з кількома незалежними запитами. Хоча це простіше в налаштуванні, зазвичай не найкраща практика використовувати обчислювальні потужності графічного процесора. Для вирішення цієї проблеми Triton пропонує вбудовані оптимізації динамічне пакетування щоб об’єднати ці незалежні запити висновку на стороні сервера, щоб динамічно сформувати більший пакет для збільшення пропускної здатності. Наступна діаграма ілюструє архітектуру часу виконання Triton.

У попередній архітектурі всі запити спочатку надходять до динамічного дозатора, перш ніж увійти в черги планувальника фактичної моделі, щоб чекати висновку. Ви можете встановити бажані розміри пакетів для динамічного пакетування за допомогою preferred_batch_size налаштування в конфігурації моделі. (Зверніть увагу, що розмір сформованої партії має бути меншим за максимальний_розмір_партії модель підтримує.) Ви також можете налаштувати max_queue_delay_microseconds щоб вказати максимальний час затримки в пакеті для очікування інших запитів на приєднання до пакету відповідно до ваших вимог до затримки.

У наведеному нижче фрагменті коду показано, як можна додати цю функцію до файлів конфігурації моделі, щоб встановити динамічне пакетування з бажаним розміром пакету 16 для фактичного висновку. З поточними налаштуваннями екземпляр моделі викликається миттєво, коли досягається бажаний розмір пакету 16 або минув час затримки в 100 мікросекунд з моменту досягнення першого запиту до динамічного дозатора.

dynamic_batching { preferred_batch_size: 16 max_queue_delay_microseconds: 100 }

Одночасне запуск моделей

Ще одна важлива оптимізація, запропонована в Triton для максимального використання обладнання без додаткових накладних витрат на затримку одночасне виконання моделі, що дозволяє кільком моделям або кільком копіям однієї моделі працювати паралельно. Ця функція дозволяє Triton обробляти кілька запитів на висновок одночасно, що збільшує пропускну здатність висновку за рахунок використання неактивної обчислювальної потужності апаратного забезпечення.

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

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

TensorRT

NVIDIA TensorRT — це пакет SDK для високопродуктивного глибокого навчання, який безперебійно працює з Triton. TensorRT, який підтримує будь-яку основну структуру глибокого навчання, включає оптимізатор висновку та час виконання, що забезпечує низьку затримку та високу пропускну здатність для виконання висновків із величезними обсягами даних за допомогою потужних оптимізацій.

TensorRT оптимізує графік, щоб мінімізувати обсяг пам’яті, звільняючи непотрібну пам’ять та ефективно повторно використовуючи її. Крім того, компіляція TensorRT об’єднує розріджені операції всередині графіка моделі, щоб сформувати більше ядро, щоб уникнути накладних витрат на кілька запусків невеликого ядра. Автоналаштування ядра допомагає повністю використовувати апаратне забезпечення, вибираючи найкращий алгоритм для цільового графічного процесора. Потоки CUDA дозволяють моделям працювати паралельно, щоб максимізувати використання графічного процесора для найкращої продуктивності. І останнє, але не менш важливе, техніка квантування може повністю використовувати прискорення змішаної точності ядер Tensor для запуску моделі в FP32, TF32, FP16 і INT8 для досягнення найкращої продуктивності висновку.

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

Хостинг SageMaker послуги — це набір функцій SageMaker, спрямованих на полегшення розгортання та обслуговування моделі. Він надає різноманітні варіанти для легкого розгортання, автоматичного масштабування, моніторингу й оптимізації моделей машинного навчання, призначених для різних випадків використання. Це означає, що ви можете оптимізувати свої розгортання для всіх типів моделей використання, від постійних і завжди доступних з безсерверними параметрами до тимчасових, довготривалих або пакетних потреб.

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

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

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

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

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

Розширене завдання пропонує більше елементів керування для подальшого точного налаштування продуктивності. Ці елементи керування моделюють реальне середовище та вимоги виробництва. Серед цих елементів керування є шаблон трафіку, який має на меті створити шаблон запиту для контрольних показників. Ви можете встановити пандуси або постійний рух, використовуючи кілька етапів схеми руху. Наприклад, an InitialNumberOfUsers 1, SpawnRate з 1 і Тривалість в секундах 600 може призвести до збільшення трафіку на 10 хвилин з 1 одночасним користувачем на початку і 10 в кінці. Крім того, на елементах керування, MaxInvocations та Модель LatencyThresholds встановити поріг виробництва, тож коли один із порогів перевищено, порівняльний аналіз припиняється.

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

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

Налаштування експерименту

Ми використовуємо спеціальну функцію тестування навантаження SageMaker Inference Recommender для порівняння профілю NLP, описаного в нашому випадку використання. Спочатку ми визначаємо наступні передумови, пов’язані з моделлю НЛП та завданням ML. SageMaker Inference Recommender використовує цю інформацію для отримання зображення Docker для висновку Реєстр контейнерів Amazon Elastic (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 другого покоління. Логіка вибору типів екземплярів полягала в тому, щоб мати як екземпляр з доступним лише одним графічним процесором, так і екземпляр з доступом до кількох графічних процесорів — чотирьох у випадку ml.g2dn.4xlarge. Крім того, ми хотіли перевірити, чи приведе збільшення потужності vCPU на екземплярі лише з одним доступним графічним процесором, щоб покращити співвідношення ціни та продуктивності.

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

За допомогою динамічного пакетного пакетування ми можемо отримати майже 2-кратне підвищення пропускної здатності, використовуючи ту саму апаратну архітектуру для всіх експериментальних екземплярів ml.g4dn.xlarge, ml.g4dn.2xlarge і ml.g4dn.12xlarge без помітного збільшення затримки.

Аналогічно, одночасне виконання моделі дозволяє нам отримати приблизно 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, та їх впливом на продуктивність у моделях ML та екземплярах ML SageMaker.

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

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

Про авторів

Вікрам Еланго є архітектором-спеціалістом з рішень AI/ML у Amazon Web Services, що базується у Вірджинії, США. Vikram допомагає клієнтам фінансової та страхової індустрії з дизайном, лідерством у розробці та розгортанні програм машинного навчання в масштабі. Наразі він зосереджений на обробці природної мови, відповідальному штучному інтелекті, оптимізації висновку та масштабуванні машинного навчання на підприємстві. У вільний час він любить подорожувати, ходити в походи, готувати та відпочивати разом із сім’єю.

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

Мохан Ганді є старшим інженером з програмного забезпечення в AWS. Він працює в AWS протягом останніх 9 років і працював над різними сервісами AWS, такими як EMR, EFA та RDS на Outposts. Зараз він зосереджений на покращенні досвіду висновку SageMaker. У вільний час захоплюється походами та бігає марафонами.

Дхавал Патель є головним архітектором машинного навчання в AWS. Він працював з організаціями, починаючи від великих підприємств і закінчуючи стартапами середнього розміру, над проблемами, пов’язаними з розподіленими обчисленнями та штучним інтелектом. Він зосереджується на глибокому навчанні, включаючи домени НЛП та комп’ютерного зору. Він допомагає клієнтам досягти високопродуктивної моделі висновку на SageMaker.

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

Цзяхон Лю є архітектором рішень у команді постачальників хмарних послуг у NVIDIA. Він допомагає клієнтам у прийнятті рішень машинного навчання та штучного інтелекту, які використовують прискорені обчислення NVIDIA для вирішення їхніх проблем навчання та висновків. У вільний час він любить орігамі, DIY-проекти та грає в баскетбол.

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