Как Veriff уменьшил время развертывания на 80% с помощью многофункциональных конечных точек Amazon SageMaker

Как Veriff сократил время разворачивания на 80% с помощью многофункциональных конечных точек Amazon SageMaker

Veriff – это партнерская платформа по проверке личности инновационных компаний, включая пионеры в финансовых услугах, FinTech, криптовалюте, играх, мобильности и онлайн-рынках. Они предоставляют передовую технологию, объединяющую автоматизацию с помощью искусственного интеллекта, человеческой обратной связью, глубокими исследованиями и экспертизой.

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

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

• Практические соображения в проектировании приложения RAG
• От 2D к 3D улучшение согласованности генерации текста в 3D с выравненными геометрическими условиями.
• Раскрытие прозрачности ИИ как группировка функций Anthropic улучшает интерпретируемость нейронных сетей

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

Инфраструктура и вызовы разработки

Backend-архитектура Veriff основана на шаблоне микросервисов, с сервисами, работающими на различных кластерах Kubernetes, размещенных на инфраструктуре AWS. Изначально такой подход использовался для всех служб компании, включая микросервисы, выполняющие затратные модели компьютерного зрения на основе машинного обучения.

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

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

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

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

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

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

• Обеспечить легкую обертку REST API для моделей машинного обучения
• Обеспечить оптимальное и, если возможно, автоматическое управление объемом выделенных ресурсов графических процессоров

В конечном итоге, команда платформы машинного обучения сходилась на решении использовать много-модельные конечные точки Sagemaker (MME). Это решение было обусловлено поддержкой MME сервером Triton Inference Server компании NVIDIA (сервер, ориентированный на машинное обучение, который облегчает создание обертки моделей в виде REST API; Veriff также уже экспериментировал с Triton), а также его способностью управлять автоматическим масштабированием экземпляров с графическими процессорами с помощью простых политик автомасштабирования.

У Veriff были созданы две MME, одна для промежуточного тестирования и одна для производс-тва. Этот подход позволяет им запускать этапы тестирования в среде промежуточного тестирования, не затрагивая производственные модели.

SageMaker MMEы

SageMaker – это полностью управляемый сервис, который предоставляет разработчикам и специалистам по обработке данных возможность быстро создавать, обучать и развертывать модели машинного обучения. SageMaker MMEы предоставляют масштабируемое и экономически эффективное решение для развертывания большого количества моделей для реального времени вывода. MMEы используют общий контейнер обслуживания и группу ресурсов, которые могут использовать ускоренные экземпляры, такие как GPU, для размещения всех ваших моделей. Это позволяет снизить затраты на размещение, максимизируя использование конечной точки по сравнению с использованием конечных точек с одной моделью. Он также сокращает затраты на развертывание, поскольку SageMaker управляет загрузкой и выгрузкой моделей в память и их масштабированием на основе трафика конечной точки. Кроме того, все конечные точки реального времени SageMaker имеют встроенные возможности для управления и мониторинга моделей, такие как включение теневых вариантов, автомасштабирование и нативная интеграция с Amazon CloudWatch (дополнительную информацию см. в разделе Метрики CloudWatch для развертывания конечной точки с несколькими моделями).

Пользовательские ансамблированные модели Triton

Что касается использования Triton Inference Server, у Veriff было несколько причин:

• Он позволяет специалистам по обработке данных создавать REST API из моделей, расположив файлы артефактов моделей в стандартном формате каталога (решение без написания кода)
• Он совместим со всеми основными фреймворками ИИ (PyTorch, Tensorflow, XGBoost и другие)
• Он предоставляет специфичные для МО оптимизации на низком уровне и настройки на уровне сервера, такие как динамическое пакетирование запросов

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

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

Следующее представляет собой типичное хранилище моделей Triton для этой рабочей нагрузки:

Файл model.py содержит код предварительной обработки и постобработки. Обученные веса модели находятся в каталоге screen_detection_inferencer в версии модели 1 (в этом примере модель представлена в формате ONNX, но может быть также в формате TensorFlow, PyTorch или других). Описание ансамблевой модели находится в каталоге screen_detection_pipeline, где в конфигурационном файле отображаются входы и выходы между шагами.

Дополнительные зависимости, необходимые для запуска Python моделей, описаны в файле 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 Simple Storage Service (Amazon S3), подключенное к MME, позволяя SageMaker обнаруживать и обслуживать модель.

Версионирование модели и непрерывное развертывание

Как было показано в предыдущем разделе, создание репозитория моделей Triton – дело простое. Однако выполнение всех необходимых шагов для развертывания является утомительным и подверженным ошибкам при ручном выполнении. Чтобы избежать этого, Veriff создала монорепо, содержащую все модели, которые должны быть развернуты на MME, где специалисты по данным сотрудничают в подходе, аналогичном Gitflow. Это монорепо имеет следующие особенности:

• Управляется с помощью Pants.
• Используются инструменты для проверки качества кода, такие как Black и MyPy, с применением Pants.
• Определены модульные тесты для каждой модели, которые проверяют, что выход модели – ожидаемый выход для заданного входа модели.
• Веса моделей хранятся вместе с репозиториями моделей. Эти веса могут быть большими двоичными файлами, поэтому для их синхронизации с Git в версионируемом режиме используется DVC.

Это монорепо интегрировано с инструментом непрерывной интеграции (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 дополнительные преимущества. Они использовали метрику CloudWatch InvocationsPerInstance, чтобы масштабировать в соответствии с шаблонами трафика, экономя на затратах без ущерба надежности. Для определения порогового значения метрики они проводили нагрузочное тестирование на подготовительном конечной точке для нахождения наилучшего соотношения между задержкой и стоимостью.

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

Заключение

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