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

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

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

У цій публікації ми розглянемо розгортання робочого навантаження ансамблю виявлення шахрайства в SageMaker із Triton Inference Server.

Огляд рішення

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

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

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

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

Сервер NVIDIA Triton Inference

Triton Inference Server був розроблений з нуля, щоб дати можливість командам розгортати, запускати та масштабувати навчені моделі штучного інтелекту з будь-якої структури на інфраструктурі на основі GPU або CPU. Крім того, його було оптимізовано, щоб запропонувати високопродуктивний висновок у масштабі з такими функціями, як динамічне пакетування, одночасні прогони, оптимальна конфігурація моделі, модельний ансамбль і підтримка потокових вхідних даних.

На наступній діаграмі показано приклад конвеєра NVIDIA Triton ensemble.

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

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

NVIDIA Triton на SageMaker

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

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

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

Підтримка NVIDIA FIL

З Випуск версії Triton 22.05, тепер NVIDIA підтримує моделі лісу, навчені кількома популярними фреймворками ML, включаючи 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. У багатьох випадках для цього не потрібно змінювати модель. В інших випадках ваша модель може потребувати перетворення в інший формат. Залежно від вихідного та цільового форматів існують різні варіанти, наприклад перетворення a Файл pickle Python для використання двійкового формату контрольних точок Treelite.

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

Створіть план і оцініть зусилля, необхідні для використання Triton для хостингу

Давайте поговоримо про план переміщення ваших моделей на Triton. Кожне розгортання Triton вимагає наступного:

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

Далі в цій публікації ми покажемо приклад того, як створити ці залежності розгортання.

Виконайте план і перевірте результати

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

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

Реалізація

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

Перший блокнот показує наявний у вашій організації блокнот, який використовує ШВИДКИ набір бібліотек і ядро ​​RAPIDS Conda. Цей екземпляр працює на типі екземпляра G4DN, наданого AWS, який прискорюється GPU за допомогою процесорів NVIDIA T4.

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

Перший блокнот завершується навчанням нашої моделі XGBoost і відповідним збереженням артефактів.

У цьому сценарії навчальний код уже існував, і не потрібно змінювати модель під час навчання. Крім того, хоча ми використовували прискорення GPU для попередньої обробки під час навчання, ми плануємо використовувати CPU для попередньої обробки під час висновку. Ми пояснимо більше далі в публікації.

А тепер перейдемо до другого ноутбука і згадаємо, що нам потрібно для успішного розгортання Triton.

По-перше, нам потрібні артефакти моделі, необхідні для серверних програм. Файли, які нам потрібно створити для цього ансамблю, включають:

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

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

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

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

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

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

Далі нам потрібні конфігураційні файли Triton. Кожна модель в ансамблі Triton вимагає a config.pbtxt файл. Крім того, ми також створюємо a 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 для вирішення їхніх проблем навчання та висновків. У вільний час він любить орігамі, DIY-проекти та грає в баскетбол.

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

Бруно Агіар де Мело є інженером із розробки програмного забезпечення на Amazon.com, де він допомагає науковим групам створювати, розгортати та випускати робочі навантаження ML. Він цікавиться приладами та керованими аспектами на етапі моделювання/проектування машинного навчання, які необхідно розглядати та вимірювати з розумінням того, що продуктивність виконання моделі є такою ж важливою, як і якість моделі, особливо у випадках використання з обмеженнями затримки. У вільний час він любить вино, настільні ігри та кулінарію.

Еліут Тріана є менеджером зі зв'язків з розробниками в NVIDIA. Він об’єднує лідерів продуктів, розробників і науковців Amazon і AWS з технологами та лідерами продуктів NVIDIA для прискорення робочих навантажень Amazon ML/DL, продуктів EC2 і служб AWS AI. Крім того, Еліут — пристрасний гірський велосипедист, лижник і гравець у покер.