Больше, чем просто AWS Lambda

Стоимость логического вывода может составлять значительную часть стоимости вычислений. Чтобы решить эту проблему и снизить высокую стоимость логического вывода, AWS уже предлагает несколько решений для логического вывода моделей для широкого спектра сценариев:

Но что, если вы ищете более гибкое, настраиваемое бессерверное решение с еще более низкой стоимостью? и, что наиболее важно, потенциально может быть «поднят и перенесен» на другие облачные платформы, если ваша организация имеет дело с мультиоблачной инфраструктурой. или беспокоитесь о том, чтобы решение было привязано к одному конкретному поставщику?

Добро пожаловать в рассказ BGL о том, как внедрить AWS Lambda в качестве сервиса вывода моделей для обработки большого объема запросов на вывод в производственной среде.

Контекст

Наша команда инженеров создает продукт ИИ для автоматизации нескольких бизнес-процессов. Оба фреймворка Hugging Face Transformer (для задач НЛП) и YOLOv5 (для задач обнаружения объектов) интегрированы, и несколько моделей были обучены на основе бизнес-кейсов и наборов данных. Inference API интегрирован с существующим бизнес-процессом для автоматизации процесса, чтобы организация могла отвлекать ресурсы от утомительной и малоценной работы и сокращать эксплуатационные расходы.

Текущая система обрабатывает более 1000 запросов на вывод в день с 50-кратным увеличением объема в ближайшем будущем. Как только модель-кандидат будет развернута в рабочей среде и станет стабильной, основные затраты будут связаны с выводом модели.

Дизайн решения

Решение использует несколько сервисов AWS для следующих целей (в контексте решения):

  • Sagemaker: Обучение пользовательской модели
  • EFS: хранение артефактов обученной модели в качестве основного источника загрузки модели.
  • S3: Хранение артефактов обученной модели в качестве вторичного источника загрузки модели.
  • ECR: размещение образа докера Lambda
  • EventBridge: «Планировщик» для вызова Lambda
  • Диспетчер системы: сохранение пути к модели в хранилище параметров

Обучение

  1. Sagemaker обычно сжимает и выводит артефакты модели в S3. В этом случае дополнительно одна копия также сохраняется в EFS (поясняется в 3.2) путем добавления дополнительного имени канала Sagemaker.

Развертывание Lambda

2.1 Serverless Framework используется для управления конфигурациями Lambda со всеми необходимыми пакетами и скриптом Lambda, встроенным через Jenkins и Docker в образ докера, который далее передается в ECR.

Примечание. Артефакты модели не встроены в этот образ, они остаются как в S3, так и в EFS.

Вот пример файла докера для сборки образа Lambda:

  • Общедоступный базовый образ лямбды из AWS (public.ecr.aws/lambda/python:3.8.2021.11.04.16)
  • Копирование лямбда-логики, написанной в awslambda.py
  • Копирование проекта YOLOv5 (первоначально клонированного из YOLOv5), поскольку для загрузки обученной модели YOLOv5 локально в Lambda потребуется это
  • Все необходимые пакеты определены в отдельном файле с именем lambda-requirements.txt, который находится в том же каталоге.

2.2 Для каждой Lambda настроено соответствующее правило EventBridge (в файле Serverless YAML). EventBridge вызывает Lambda каждые 5 минут с двумя важными целями:

  • Сохранение Lambda в горячем состоянии, чтобы избежать холодного запуска без запуска фактического запроса логического вывода.
  • Предварительная загрузка желаемой модели в первом запросе на прогрев, а затем ее кэширование (через глобальную переменную) значительно сократит время выполнения вывода, вызванное загрузкой модели для последующих фактических запросов вывода.

Фрагмент кода выше показывает структуру конфигурации Lambda, используемой в файле Serverless YAML. Подробности см. в Документации по Serverless Framework, основные моменты:

  • ephemeralStorageSize 5120 настроит размер папки «/tmp» Lambda на 5120 МБ (объяснено в 3.2)
  • Ведро модели и путь как входные параметры вызова EventBridge (поясняется в 3.1)

Вывод

На приведенной ниже диаграмме объясняется логика обработки Lambda, принцип которой заключается в проверке того, срабатывает ли вызов:

  • По запросу лямбда-прогрева (через EventBridge) -> загрузить режим (в первый раз) и кэшировать -> вернуть без обработки вывода, или
  • По фактическому запросу вывода —> процесс вывода —> возврат результата вывода

3.1 Корзина S3 и соответствующий путь к модели сохраняются в хранилище параметров System Manager, поэтому они не связаны с развертыванием Lambda. Инженеры могут указать Lambda на любую желаемую модель, изменив параметр без повторного развертывания этой Lambda.

3.2 EFS — это файловая система, поэтому монтирование и загрузка модели напрямую из EFS будет намного быстрее (пожалуйста, внимательно следите за пропускной способностью EFS). В случае сбоя загрузки EFS (неверный путь, ограничение полосы пропускания и т. д.) Lambda загружает артефакты модели из S3 в локальный каталог «/tmp» и загружает модель оттуда. Важно убедиться, что в Lambda достаточно места для «/tmp» (в нашем случае для параметра ephemeralStorageSize установлено значение 5120 МБ)!

Загрузить модель YOLOv5 локально в Lambda очень просто:

  • Убедитесь, что вы скопировали каталог проекта yolov5 (упомянутый в 2.1) и установили путь к каталогу в repo_or_dir.
  • Используйте model= ‘custom’ и source= ‘local’
  • Путь указывает на допустимую обученную модель *.pt YOLOv5.

Ограничения

Все модели ошибочны, но некоторые из них полезны — Джордж Бокс.

Все решения неправильные, но есть и полезные - Автор этой статьи :)

Нет идеальных решений, все сопряжено с компромиссами и ограничениями, некоторые из ограничений предлагаемого решения:

  • Лямбда-вывод не настроен для вывода в реальном времени, который требует обработки в реальном времени и очень низкой задержки.
  • Lambda имеет 15-минутное ограничение времени выполнения, если вывод займет слишком много времени, произойдет сбой.
  • За пропускную способность EFS взимается дополнительная плата, но вы можете переключиться на загрузку и загрузку S3 в качестве основного метода с установкой и загрузкой EFS в качестве дополнительного. Это медленнее, но дешевле, и пакетный вывод в целом не чувствителен к задержке.

Потенциальный подъем и сдвиг

Некоторые функции/шаблоны проектирования этого решения потенциально могут быть подняты и перенесены на другие облачные платформы (например, Azure, GCP), поскольку они предлагают такие же услуги, как и AWS, два ценных из них:

  • Использование недорогих бессерверных компьютерных служб (Azure Functions, GCP Functions) для обслуживания пакетного вывода модели и интеграции с «планировщиком», чтобы поддерживать «теплый» сервис.
  • Разработка логики для предварительной загрузки и кэширования модели для сокращения времени обработки логического вывода.

Сводка

Спасибо за прочтение и надеюсь, вам понравилась эта статья, вот несколько ключевых моментов:

  • AWS Lambda, EFS и S3 можно объединить в экономичный, масштабируемый и надежный сервис для пакетного вывода моделей (до 15 минут).
  • Правильная реализация триггера AWS EventBridge Lambda может помочь свести к минимуму холодный запуск Lambda.
  • Реализация логики предварительной загрузки и кэширования модели в Lambda поможет сократить время выполнения вывода модели.
  • Передача пути к модели в качестве системного параметра вместо встраивания модели в лямбда-образ обеспечивает большую гибкость (развязку).
  • Существуют потенциальные возможности подъема и смещения для применения аналогичной концепции на других облачных платформах.