MLOps

Инструкция по запуску пакета в чистом окружении:

git clone https://github.com/Natalka-Pro/myops_tools.git
cd myops_tools/

virtualenv -p /usr/bin/python3.11 venv_name
source venv_name/bin/activate

poetry install
pre-commit install
pre-commit run -a

Запуск сервера mlflow (создаёт mlruns):

mlflow server --host 127.0.0.1 --port 8080

Запуск сервера triton:

cd triton/
docker-compose up

Команды модели:

Обучение (логи в mlruns, checkpoints и на сервер mlflow):

python commands.py train

Предсказание, использует model.pth:

python commands.py infer

Предсказание, использует model.onnx (логи в mlruns, mlartifacts и на сервер mlflow):

python commands.py run_server

Клиент заходит на тритон-сервер (использует model.onnx):

python commands.py client

Системная конфигурация

• OS и версия: Ubuntu 20.04.6 LTS
• Модель CPU: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
• vCPU: 8
• RAM: 8 Gi

Описание ML задачи

Классификация рукописных цифр - датасет torchvision.datasets.MNIST.

60000 изображений для обучения и 10000 изображений для тестирования.

Задача решается очень упрощённой свёрточной нейронной сетью AlexNet.

Структура model_repository

model_repository
└── onnx-AlexNet
    ├── 1
    │   └── model.onnx
    └── config.pbtxt

SDK утилита perf_analyzer

бекенд: onnxruntime_onnx

docker run -it --rm --net=host nvcr.io/nvidia/tritonserver:23.04-py3-sdk
perf_analyzer -m onnx-AlexNet -u localhost:8500 --concurrency-range 8:8 --shape images:1,3,32,32 --measurement-interval 10000

До оптимизаций:

Request concurrency: 8
    Client:
        Request count: 279222
        Throughput: 7749.65 infer/sec
        Avg latency: 1031 usec (standard deviation 676 usec)
        p50 latency: 918 usec
        p90 latency: 1495 usec
        p95 latency: 1771 usec
        p99 latency: 3640 usec
        Avg HTTP time: 1023 usec (send/recv 92 usec + response wait 931 usec)
    Server:
        Inference count: 287303
        Execution count: 114492
        Successful request count: 287303
        Avg request latency: 424 usec (overhead 129 usec + queue 172 usec + compute input 24 usec + compute infer 85 usec + compute output 13 usec)

Inferences/Second vs. Client Average Batch Latency
Concurrency: 8, throughput: 7749.65 infer/sec, latency 1031 usec

После оптимизаций:

Request concurrency: 8
    Client:
        Request count: 291643
        Throughput: 8091.21 infer/sec
        Avg latency: 987 usec (standard deviation 455 usec)
        p50 latency: 917 usec
        p90 latency: 1341 usec
        p95 latency: 1513 usec
        p99 latency: 2016 usec
        Avg HTTP time: 981 usec (send/recv 90 usec + response wait 891 usec)
    Server:
        Inference count: 291647
        Execution count: 104061
        Successful request count: 291647
        Avg request latency: 367 usec (overhead 59 usec + queue 199 usec + compute input 23 usec + compute infer 74 usec + compute output 12 usec)

Inferences/Second vs. Client Average Batch Latency
Concurrency: 8, throughput: 8091.21 infer/sec, latency 987 usec

Мотивация выбора

dynamic_batching	-	4000	2000	1000	500	100	50
throughput	7749.65	1687.99	2975.24	4825.17	6944.01	8091.21	8033.21
latency	1031	4737	2687	1656	1150	987	994

Прочерк соответсвует dynamic_batching: { }, далее указаны значения параметра max_queue_delay_microseconds.

Из таблицы видно, что наибольший throughput и наименьший latency при max_queue_delay_microseconds = 100. Увеличение количества instance-ов приходит только к ухудшению этих метрик.

---

Первая домашняя работа

Текст задания:

Необходимо создать открытый репозиторий, в нём создать пакет на Python, который будет являться валидным с точки зрения пакетирования и решать какую-либо задачу машинного обучения (сейчас не так важно какую, для примера можете взять классификацию кошек против собак из нашего курса по МЛ). Выбирайте задачу, которая у вас будет обучаться не более 5 минут!!! Иначе и вы, и мы будем долго ждать.

Под "решать" понимается дву вещи:

1. есть файл train.py, в котором данные загружаются, модель тренируется и сохраняется на диск
2. есть файл infer.py, который считывает с диска модель из предыдущего пункта, загружает валидационный датасет, предсказывает моделью ответы для этих данных, записывает ответы на диск в .csv файл, выводит в stdout (print) необходимые метрики на этом датасете.

Как мы будем проверять ДЗ:

1. клонируем репозиторий
2. создаём новый чистый virtualenv
3. poetry install - нужна успешная установка (верная конфигурация)
4. pre-commit install - нужна успешная установка (верная конфигурация)
5. pre-commit run -a - не должно быть проваленных хуков (необходимые хуки это black, isort, flake8)
6. python train.py - ожидаем сохранённую модель
7. python infer.py - ожидаем печать метрик и файл с ответами

Технические подсказки:

1. Не забывайте про if _name_ == '_main_':
2. Пишите в вашу дефолтную ветку, мы не будем переключать, проверка скриптованная.

Дедлайн (жёсткий): суббота, 7 октября, 12.00 по Мск

---

Вторая домашняя работа

Текст задания:

Следующий этап развития проекта это добавление системы управления данными, в нашем случае это dvc, конфигурации экспериментов на основе hydra, а также логирование на основе mlflow. Для тех, кто делает проекты с нейросетями будет плюсом использование фреймворка для обучения модели (catalyst, lightning, hugging face). Напоследок сконфигурировать простой сервер предсказаний модели используя mlflow models.

1. DVC Для dvc в качестве бекенда проще и доступнее всего использовать гугл диск (проверьте, что папка доступна по ссылке на чтение всем, иначе мы не сможем проверить), можно использовать и любой другой бекенд, но тут возникает такой же вопрос с доступностью. Скачивание данных с помощью dvc необходимо встроить в имеющиеся команды train и infer, для этого у dvc есть python api (на крайний случай можно дёрнуть CLI).

2. Hydra Переведите основные гиперпараметры препроцессинга, обучения и постпроцессинга в yaml конфиги hydra. Сами конфиги лучше всего расположить в папке configs в корне репозитория.

3. Logging Необходимо добавить логирование ваших основных метрик и функций потерь (всего не менее 3 графиков). Также в эксперимент записывать использованные гиперпараметры и версию кода (git commit id). Считайте, что сервер mlflow уже поднят, его адрес добавьте в поле конфига.

4. Inference Экспортируйте модель в onnx и добавьте команду run_server (либо в fire, либо отдельным .py файлом), в которой используя mlflow models запустите инференс модели из onnx файла.

Результат работы оформите в виде тега с названием ‘hw2’ в git репозитории.

Дедлайн (жёсткий): вскр, 3 декабря, 23.59 по Мск

Репозиторий у вас остаётся прежний, поэтому формы заполнять не нужно, достаточно создать тег в git репозитории. Для тех, кто ещё не отправлял нам адрес репы - это можно сделать в той же форме

---

Третья домашняя работа

Текст задания:

Следующий этап - оптимизация деплоя модели. Для успешного выполнения этого задания вам потребуется только докер. Основная часть - поднять Nvidia Triton Server с вашей моделью/моделями. Две доп части: одна на TensorRT (потребуется гпу), вторая теоретическая (ничего сверху того что есть не потребуется).

1. Определитесь с выбором бекенда:

• ONNX - если в HW2 модель экспортировалась в этот формат
• FIL (Forest Inference LIbrary) - будет плюсом если у вас что-то из XGBoost, LightGBM, Scikit-Learn, cuML
• Python - если модель не подходит ни в один из форматов a, b P.S. Если у вас onnx модель, но вы вставите ее в Python бекенд, то это минус.

2. При помощи SDK утилиты perf_analyzer найдите оптимальные параметры для config.pbtxt (варианты на что стоит обратить внимание, мы обсуждали на 9ом семинаре, еще можно почитать тут). Запишите в .md отчете мотивацию выбора тех или иных параметров (про формат отчета будет ниже). Минимум в этом пункте - настроить dynamic batching и instance groups

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

4. Форма текстового отчета:

• Ваша системная конфигурация
  • OS и версия
  • Модель CPU
  • Количество vCPU и RAM при котором собирались метрики
• Описание решаемой задачи
• Описание структуры вашего model_repository (в формате “$ tree”)
• Секция с метриками по throughput и latency которые вы замерили до всех оптимизаций и после всех оптимизаций
• Объяснение мотивации выбора или не выбора той или иной оптимизации

5. Что точно должно быть в коде:

• Скрипт для конвертации вашей модели в формат выбранного бекенда
• Дерево model_repository (P.S. кладите .gitkeep в директории с весами моделей и добавляйте в .gitignore пути до весов)
• Тесты для задеплоенной модели (P.S. не делайте случайные тесты, они должны быть воспроизводимыми)

6. Что точно должно быть в dvc:

• Веса моделей

На доп плюсик: Если у вас есть гпу, то можете поэксперементировать с конвертацией в tensorrt. Добавьте в отчет команду для конвертации и объясните набор флагов который выставите в trtexec (желательно не только мотивация попавших флагов, но так же объяснение отсутствующих флагов). Так же добавьте замеры throughput и latency для trt модели, сравните с метриками для onnx. В таком случае ОБЯЗАТЕЛЬНО: в итоговом model_repository должна быть как onnx модель так и trt модель. Клиента пишите под onnx модель (так как вероятно мы будем запускать в окружении без гпу).

На еще один доп плюсик: Если модель может выполняться на гпу (теоретически), то выясните для каждого слоя является ли он ограниченным арифметикой либо ограниченным памятью (соответствующие темы разбирались на 7-8 лекциях). Для этого выясните количество флопс в каждом слое модели (можно автоматизировать через библиотеку thop) и количество байт памяти для выполнения forward pass слоя, затем переведите в #ops/#bytes и сравните с пиковыми #ops/#bytes для вашей видеокарты и сделайте вывод. Попробуйте подобрать оптимальный размер батча для достижения максмальной арифметической интенсивности для вашей видеокарты. Все это (+ модель вашей видеокарты) занесите в текстовый отчет.

Дедлайн (жёсткий): 23 декабря 23:59