Одно дело — создать блокнот Jupyter для обучения и тестирования моделей. И совсем другое — внедрить эти модели в производство.
Код грязный. Он объединяет элементы из огромного количества библиотек для создания конкретного решения. Не существует «одного размера для всех».
Конвейеры машинного обучения — это не просто веса моделей. Может потребоваться значительная предварительная и последующая обработка, чтобы привести входные данные в правильную форму, а выходные данные сделать так, чтобы с ними было легко работать.
Техника, которую я собираюсь описать, подходит не для всех ситуаций. На самом деле, это хак на данный момент в 2022 году, когда машинное обучение все еще больше ориентировано на потребности специалиста по данным, а не инженера-программиста.
ВЫ БЫЛИ ПРЕДУПРЕЖДЕНЫ!
Среда разработки
- Используйте VSCode
- Используйте Докер
- Используйте AWS SAM CLI
Используйте интерфейс командной строки 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.