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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SageMaker ММЕ

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

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

Этот монорепозиторий интегрирован с инструментом непрерывной интеграции (CI). Для каждого нового добавления в репозиторий или новой модели выполняются следующие шаги:

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

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

Преимущества в стоимости и скорости развертывания

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

1. Создайте в монорепозитории ветку с новой моделью или версией модели.
2. Определите и запустите модульные тесты на машине разработки.
3. Отправьте ветку, когда модель будет готова к тестированию в промежуточной среде.
4. Объедините ветку с основной, когда модель будет готова к использованию в производстве.

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

Функции предоставления управляемой инфраструктуры и автоматического масштабирования SageMaker принесли Veriff дополнительные преимущества. Они использовали метрику InvocatsPerInstance CloudWatch для масштабирования в соответствии с шаблонами трафика, экономя затраты без ущерба для надежности. Чтобы определить пороговое значение метрики, они провели нагрузочное тестирование на промежуточной конечной точке, чтобы найти наилучший компромисс между задержкой и стоимостью.

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

Заключение

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

Об авторах

Рикар Боррас является старшим специалистом по машинному обучению в компании Veriff, где он руководит проектами MLOps в компании. Он помогает ученым, работающим с данными, создавать более быстрые и лучшие продукты AI/ML, создавая в компании платформу для обработки данных и объединяя несколько решений с открытым исходным кодом с сервисами AWS.

Жоао Моура — специалист по архитектуре решений AI/ML в AWS, Испания. Он помогает клиентам с помощью глубокого обучения моделировать крупномасштабное обучение и оптимизацию логических выводов, а также в более широком смысле создавать крупномасштабные платформы машинного обучения на AWS.

Мигель Феррейра работает старшим архитектором решений в AWS в Хельсинки, Финляндия. Искусственный интеллект и машинное обучение интересовали его на протяжении всей жизни, и он помог множеству клиентов интегрировать Amazon SageMaker в свои рабочие процессы машинного обучения.