Як Veriff скоротив час розгортання на 80% за допомогою багатомодельних кінцевих точок Amazon SageMaker | Веб-сервіси Amazon

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

Veriff надає перевірену інфраструктуру, яка дозволяє клієнтам довіряти ідентифікаціям і особистим характеристикам своїх користувачів у всі відповідні моменти їхньої подорожі до клієнта. Veriff довіряють такі клієнти, як Bolt, Deel, Monese, Starship, Super Awesome, Trustpilot і Wise.

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

У цій публікації ми покажемо вам, як компанія Veriff стандартизувала свій робочий процес розгортання моделі за допомогою Amazon SageMaker, скорочення витрат і часу розробки.

Проблеми інфраструктури та розвитку

Архітектура серверної частини Veriff базується на шаблоні мікросервісів із службами, що працюють на різних кластерах Kubernetes, розміщених в інфраструктурі AWS. Цей підхід спочатку використовувався для всіх сервісів компанії, включаючи мікросервіси, які запускають дорогі моделі комп’ютерного бачення ML.

Деякі з цих моделей вимагали розгортання на примірниках GPU. Усвідомлюючи порівняно вищу вартість типів екземплярів із підтримкою GPU, Veriff розробив a нестандартне рішення на Kubernetes для спільного використання ресурсів певного GPU між різними репліками служби. Один графічний процесор зазвичай має достатньо відеопам’яті для зберігання кількох моделей комп’ютерного зору Veriff у пам’яті.

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

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

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

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

Veriff потребувало нового рішення, яке вирішувало дві проблеми:

• Дозвольте легко створювати обгортки REST API навколо моделей ML
• Дозволяє оптимально й, якщо можливо, автоматично керувати потужністю виділеного екземпляра GPU

Зрештою команда ML-платформи дійшла висновку про використання Мультимодельні кінцеві точки Sagemaker (ММЕ). Це рішення було зумовлене підтримкою MME для NVIDIA Сервер висновків Triton (сервер, орієнтований на ML, який дозволяє легко обернути моделі як REST API; Veriff також уже експериментував із Triton), а також його здатність нативно керувати автоматичним масштабуванням екземплярів GPU за допомогою простих політик автоматичного масштабування.

Два MME були створені у Veriff, один для постановки та один для виробництва. Такий підхід дозволяє їм запускати етапи тестування в проміжному середовищі, не впливаючи на робочі моделі.

SageMaker MME

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

Індивідуальні моделі ансамблю Triton

Було кілька причин, чому Veriff вирішила використовувати Triton Inference Server, основні з яких:

• Це дозволяє дослідникам даних створювати REST API з моделей, упорядковуючи файли артефактів моделей у стандартному форматі каталогу (без кодового рішення)
• Він сумісний з усіма основними фреймворками ШІ (PyTorch, Tensorflow, XGBoost тощо)
• Він забезпечує низький рівень і оптимізацію сервера, як-от динамічне пакетування запитів

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

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

Ось як виглядає типове сховище моделі Triton для цього робочого навантаження:

Команда model.py файл містить код попередньої та постобробки. Ваги тренованої моделі знаходяться в screen_detection_inferencer каталог, у версії моделі 1 (у цьому прикладі модель має формат ONNX, але також може мати формат TensorFlow, PyTorch або інші). Визначення моделі ансамблю міститься в screen_detection_pipeline каталог, де входи та виходи між кроками відображаються у файлі конфігурації.

Додаткові залежності, необхідні для запуску моделей Python, детально описано в a requirements.txt файл і потрібно запакувати в conda для створення середовища Conda (python_env.tar.gz). Для отримання додаткової інформації див Керування середовищем виконання Python і бібліотеками. Крім того, файли конфігурації для кроків Python повинні вказувати на python_env.tar.gz використання EXECUTION_ENV_PATH Директиви.

Потім папку моделі потрібно стиснути TAR і перейменувати за допомогою model_version.txt. Нарешті, результат <model_name>_<model_version>.tar.gz файл скопійовано в папку Служба простого зберігання Amazon (Amazon S3), під’єднаний до MME, що дозволяє SageMaker виявляти та обслуговувати модель.

Версії моделі та безперервне розгортання

Як було зрозуміло з попереднього розділу, створення репозиторію моделі Triton є простим. Однак виконання всіх необхідних кроків для його розгортання є нудним і загрожує помилками, якщо виконувати його вручну. Щоб подолати це, Veriff створив моносховище, що містить усі моделі для розгортання в MME, де дослідники даних співпрацюють у підході, подібному до Gitflow. Це монорепо має такі особливості:

• Це керується за допомогою ШТАНИ.
• Інструменти якості коду, такі як Black і MyPy, застосовуються за допомогою Pants.
• Для кожної моделі визначено модульні тести, які перевіряють, чи вихід моделі є очікуваним результатом для даної моделі.
• Вага моделей зберігається поряд із сховищами моделей. Ці ваги можуть бути великими бінарними файлами, отже ССЗ використовується для їх синхронізації з Git версійним способом.

Це монорепо інтегровано з інструментом безперервної інтеграції (CI). Для кожного нового надсилання до репо чи нової моделі виконуються такі кроки:

1. Пройдіть перевірку якості коду.
2. Завантажте моделі ваг.
3. Створіть середовище Conda.
4. Розкрутіть сервер Triton за допомогою середовища Conda та використовуйте його для обробки запитів, визначених у модульних тестах.
5. Створіть файл TAR остаточної моделі (<model_name>_<model_version>.tar.gz).

Ці кроки гарантують, що моделі мають якість, необхідну для розгортання, тому для кожного надсилання до гілки репо отриманий файл TAR копіюється (на іншому кроці CI) у проміжне відро S3. Коли надсилання виконується в основній гілці, файл моделі копіюється до робочого сегмента S3. На наступній діаграмі зображено цю систему CI/CD.

Переваги у вартості та швидкості розгортання

Використання MME дозволяє Veriff використовувати підхід монорепо для розгортання моделей у виробництві. Підсумовуючи, робочий процес розгортання нової моделі Veriff складається з таких кроків:

1. Створіть гілку в монорепо з новою моделлю або версією моделі.
2. Визначте та запустіть модульні тести на машині розробки.
3. Проштовхніть гілку, коли модель буде готова до тестування в проміжному середовищі.
4. Об’єднайте гілку в основну, коли модель буде готова до використання у виробництві.

З цим новим рішенням розгортання моделі на Veriff є простою частиною процесу розробки. Термін розробки нової моделі скоротився з 10 днів до середнього 2 днів.

Керована інфраструктура і функції автоматичного масштабування SageMaker принесли Veriff додаткові переваги. Вони використовували InvocationsPerInstance Метрика CloudWatch для масштабування відповідно до моделей трафіку, заощаджуючи витрати без шкоди для надійності. Щоб визначити порогове значення для метрики, вони провели навантажувальне тестування на кінцевій точці проміжної роботи, щоб знайти найкращий компроміс між затримкою та вартістю.

Після розгортання семи виробничих моделей для MME та аналізу витрат Veriff повідомив про зниження вартості на 75% у обслуговуванні моделі GPU порівняно з оригінальним рішенням на основі Kubernetes. Операційні витрати також були зменшені, оскільки з інженерів DevOps компанії було знято тягар надання інстанцій вручну.

Висновок

У цій публікації ми розглянули, чому Veriff вибрав MME Sagemaker замість самостійного розгортання моделі на Kubernetes. SageMaker бере на себе недиференційовану важку роботу, дозволяючи Veriff скоротити час розробки моделі, підвищити ефективність проектування та значно знизити вартість висновків у реальному часі, зберігаючи продуктивність, необхідну для критично важливих для бізнесу операцій. Нарешті, ми продемонстрували простий, але ефективний конвеєр CI/CD для розгортання моделі Veriff і механізм версії моделі, який можна використовувати як еталонну реалізацію поєднання найкращих практик розробки програмного забезпечення та MME SageMaker. Ви можете знайти зразки коду для розміщення кількох моделей за допомогою MME SageMaker на GitHub.

---

Про авторів

Рікард Боррас є старшим відділом машинного навчання у Veriff, де він керує роботою MLOps у компанії. Він допомагає науковцям створювати швидші та кращі продукти штучного інтелекту та машинного навчання, створюючи Data Science Platform у компанії та поєднуючи декілька рішень з відкритим кодом із сервісами AWS.

Жоао Моура є архітектором AI/ML Specialist Solutions в AWS, що базується в Іспанії. Він допомагає клієнтам із моделюванням глибокого навчання, широкомасштабним навчанням і оптимізацією логічного висновку, а також, загалом, створюючи масштабні платформи машинного навчання на AWS.

Мігель Феррейра працює старшим архітектором рішень в AWS у Гельсінкі, Фінляндія. AI/ML цікавився протягом усього життя, і він допоміг багатьом клієнтам інтегрувати Amazon SageMaker у їхні робочі процеси ML.

• Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
• PlatoData.Network Vertical Generative Ai. Додайте собі сили. Доступ тут.
• PlatoAiStream. Web3 Intelligence. Розширення знань. Доступ тут.
• ПлатонЕСГ. вуглець, CleanTech, Енергія, Навколишнє середовище, Сонячна, Поводження з відходами. Доступ тут.
• PlatoHealth. Розвідка про біотехнології та клінічні випробування. Доступ тут.
• джерело: https://aws.amazon.com/blogs/machine-learning/how-veriff-decreased-deployment-time-by-80-using-amazon-sagemaker-multi-model-endpoints/