Одно дело — создать блокнот Jupyter для обучения и тестирования моделей. И совсем другое — внедрить эти модели в производство.

Код грязный. Он объединяет элементы из огромного количества библиотек для создания конкретного решения. Не существует «одного размера для всех».

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

Техника, которую я собираюсь описать, подходит не для всех ситуаций. На самом деле, это хак на данный момент в 2022 году, когда машинное обучение все еще больше ориентировано на потребности специалиста по данным, а не инженера-программиста.

ВЫ БЫЛИ ПРЕДУПРЕЖДЕНЫ!

Среда разработки

Используйте интерфейс командной строки SAM для создания папки проекта с использованием шаблона AWS/MachineLearning/Python3.9.

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

Внутри VSCode используйте Dev Container для выполнения всех задач кодирования.

Я предлагаю использовать Pipfile как наименее плохое решение для зависимостей библиотеки Python в 2022 году, которое хорошо работает с VSCode. Обратите внимание, что использование некоторых библиотек потребует других решений, таких как Anaconda.

SAM CLI template.yaml интересные моменты:

  • Глобальные параметры/функции/тайм-аут
  • Globals/Function/MemorySize
  • Resources/InferenceFunction/Properties/Events/Inference/Properties/Metadata/DockerTag

Цикл развития

Я рекомендую создать простую функцию __main__, которая вызывает вашу основную функцию точки входа, а не использовать sam local invoke для большей части разработки. Это позволит вам комфортно находиться внутри Dev Container.

Помните, как обрабатываются данные lambda_handler события. Если ваша полезная нагрузка представляет собой строку JSON, она волшебным образом разберет строку в объект JSON внутри вашего кода Python. ИМХО плохой/запутанный дизайн, но такова жизнь.

Крупные активы

Почти наверняка кто-то будет использовать NLTK и/или Huggingface и/или другие подобные библиотеки/фреймворки.

ВАЖНО отметить, что эти библиотеки на 100% ориентированы на то, чтобы облегчить жизнь исследователям данных. К сожалению, это означает усложнение жизни инженера-программиста.

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

На самом деле каждая библиотека делает все возможное, чтобы скрыть существование этих больших объектов данных, автоматически загружая их по требованию только по мере необходимости. Самый надежный способ искоренить волшебство, который я обнаружил, — это наблюдать за папкой $ HOME, как ястреб, во время запуска кода. Затем изучите документацию каждой библиотеки о том, как «победить» магию и предварительно загрузить данные.

Вот фрагмент моего текущего шаблона Dockerfile:

# prevent __pycache__
ENV PYTHONDONTWRITEBYTECODE="1"

# Single home for all caches that can be saved in an asset layer
ENV XDG_CACHE_HOME="/cache"
ENV HF_HOME="/cache/huggingface"
ENV HF_DATASETS_CACHE="/cache/huggingface/datasets"
ENV TRANSFORMERS_CACHE="/cache/huggingface/transformers"
ENV HUGGINGFACE_HUB_CACHE="/cache/huggingface/hub"
ENV TORCH_HOME="/cache/torch"
RUN mkdir -p /cache/nltk_data
ENV NLTK_DATA="/cache/nltk_data"
RUN mkdir -p /cache/gensim-data
ENV GENSIM_DATA_DIR="/cache/gensim-data"

Ваша боль будет разной, но, возможно, это дает хорошую основу для начала / чего-то в Google.

Обратите внимание, что в комментарии говорится что-то о «слое ресурсов». Здесь я добавляю свою собственную частичку волшебства.

Путем проб и ошибок я обнаружил изящный шаблон для эффективной работы с большими данными активов в контексте образов Docker.

В этой статье я описываю паттерн Docker Image Asset Library. Я не претендую на то, чтобы быть первым, кто обнаружил эту закономерность, но я не вижу, чтобы о ней широко говорили.

Создайте архив всех соответствующих файлов (веса моделей, корпуса и т. д.) в папке $HOME, а затем создайте «Образ актива», который можно опубликовать в вашем репозитории докеров AWS с помощью этого архива.

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

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

Пример использования изображения актива:

COPY --from=<AWS ECR REPO>/foo-model-weights:latest / /

Использование AWS Lambda

Даже не думайте использовать для взаимодействия с Lambda что-либо, кроме вызова через AWS SDK. Использование API-интерфейса HTTP-шлюза просто требует боли и тайм-аутов.

Краткое содержание

Обслуживание пользовательских бессерверных конвейеров машинного обучения в 2022 году — проблема. Я надеюсь, что это немного улучшится с такими стандартами, как ONNX, что сделает, по крайней мере, модель обслуживания более стандартизированной.

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

Когда вы собираете все части вместе, это работает довольно хорошо, но требуется много «сборки». Удачи! :)

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