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

Вы были предупреждены. :)

Это решение предполагает модель использования с шипами, ориентированную на пакетную обработку, когда модель достаточно хорошо обслуживается ЦП.

Это во многом проблема, которая не имеет универсального решения. Ландшафт провайдеров меняется быстрыми темпами. AWS, вероятно, не будет лучшим решением для всех. Я бы также взглянул на SageMaker, если кто-то думает об AWS/ML и имеет достаточно большой вариант использования.

В конце концов, речь идет о балансе затрат/производительности, который также включает затраты на разработку/поддержку (время разработки/операции).

Шаги

  1. Создайте AWS Lambda Function с помощью AWS SAM CLI
  2. Напишите немного Python, который выполняет выводы
  3. Разверните свой код + модели, используя sam deploy --guided
  4. Сражайтесь в битвах за разрешения AWS
  5. Вызов Lambda с помощью вызова AWS SDK на выбранном языке

Легко, верно? Дьявол кроется в деталях.

Проблемы реального мира

Модель — это не начало и не конец истории. Это середина.

Четверть сражения заключается в том, чтобы вставить данные в модель (предварительная обработка).

Полдела — сделать вывод из модели (вывод/прогноз).

Последняя четверть битвы — это передача данных из модели во внешний мир (постобработка).

Дисциплина науки о данных больше связана со статистическим анализом, а не с разработкой программного обеспечения. Это важно помнить.

Нынешние инструменты науки о данных больше ориентированы на исследования, чем на производство.

В 2022 году задачей станет преодоление разрыва между исследованиями и производством для любого нетривиального приложения.

Тяжелые зависимости

В дополнение к весам модели «основной модели» вполне вероятно, что будут использоваться различные другие сторонние модели и данные.

Управление зависимостями означает больше, чем просто зависимости кода для ML.

Мы все еще немного в начале эпохи науки о данных, используемой в производстве, поэтому проблема зависимостей довольно запутана.

Я отмечаю, что существует не так много общепринятых «чистых» стратегий разрешения данных (пока) для ML.

Быстрый и грязный метод, принятый в большинстве проектов ML: выгружать данные в домашнюю папку пользователей в их собственном подкаталоге, управляемом их собственными уникальными и особыми способами. Пусть цветут тысячи тайников.

Размагничивание магии

Huggingface — замечательный ресурс для знакомства и работы с моделями.

НТЛК — замечательная библиотека для выполнения разнообразных задач на естественном языке.

gensim — замечательная библиотека для тематического моделирования.

Список можно продолжать и продолжать. Если у вас есть проблемная область, связанная с ML, скорее всего, есть по крайней мере одна библиотека/ресурс Python, который вы рассмотрели (возможно, несколько).

Проблема всех этих замечательных бесплатных ресурсов заключается в том, что все они написаны и разработаны с точки зрения исследования и изучения данных. Они не предназначены для развертывания в производственной среде.

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

Я считаю, что самый простой и наивный подход, как правило, самый надежный.

Моя текущая рекомендация заключается в следующем:

  1. Запустите код проекта внутри контейнера Docker.
  2. Осмотрите папку /root или $HOME, чтобы увидеть, что туда попало.
  3. Беги tar -cvf filename <cache-folder-name>
  4. Скопируйте архив куда-нибудь за пределы контейнера
  5. Добавьте в Dockerfile ADD cache-file.tar /cache по мере необходимости
  6. Установите `ENV = "/cache/" по мере необходимости.

Примеры папок кеша, часто встречающихся в $HOME:

  • .cache/huggingface
  • ntlk_data
  • gensim-data

Dockerfile Пример установки переменных окружения (у каждого будет свой путь)

ENV HUGGINGFACE_HUB_CACHE="/cache/.cache/huggingface/hub"
ENV NLTK_DATA="/cache/nltk_data"
ENV GENSIM_DATA_DIR="/cache/gensim-data"

ПРИМЕЧАНИЕ. $HOME в Lambda, работающем внутри AWS, НЕ будет /root и не будет доступен для записи.

Обратите внимание, что это беспорядочный, громоздкий, подверженный сбоям, специальный процесс. Такова жизнь сегодня. Удачи авантюрист!

Как получить выводы

НЕ ИСПОЛЬЗУЙТЕ ШЛЮЗ AWS API!

На этом шлюзе существует жесткое ограничение в 29 секунд, и, по моему опыту, он, кроме того, ненадежный с большим временем прогрева.

Безусловно, лучший метод — использовать вызов через AWS SDK.

Вероятно, в наши дни лучше представить себе, что AWS не имеет прямой поддержки https для своего огромного набора API и сервисов. Это слишком большой зверь, и ему нужен специальный переводчик/посол, чтобы вести переговоры от своего имени.

Резюме и прогноз

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

Наука о данных != ML Ops или разработка приложений.

Мы находимся на самом раннем этапе использования машинного обучения в производственных средах, и с этого момента ситуация может стать только лучше.

Прогнозы:

  • Появится централизованный / стандартизированный победитель, который сможет решить текущую путаницу проблемы зависимости от данных «у каждого проекта есть свое решение». Что-то вроде npm или maven для организованных больших данных/моделей. Моя ставка была бы на обнимание лица.
  • Появится независимый от языка язык ассемблера ML, который позволит включать обработку до и после конвейера в дополнение к чистой обработке ML.
  • AWS Lambda скоро будет иметь возможности GPU/TPU.

Первоначально опубликовано на https://github.com.