Недавно появился гайд от ребят из гугла, как обучать модельки. Он большой, и поэтому я сделал свой TL;DR.

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

Знакома ситуация, когда вчера всё работало, а сегодня уже нет? Мне - да.

У меня уже собрался личный топ причин, что может сломаться, и наиболее частая - обновилась шальная зависимость.

В проекте на работе сейчас используется pip + requirements.txt, в котором зафиксированы все зависимости проекта. Однако у этих зависимостей тоже есть зависимости, которые любят обновиться и сломать вам сборку.

Что делать, чтобы не страдать?
- В дополнение к pip используйте pip-tools (узнал отсюда, но не пробовал)
Выглядит резонно. Вы также, как я, делаете файлик с зависимостями проекта, а pip-compile из pip-tools будет вам делать файлик с зависимостями зависимостей.
- Используйте Poetry
Пробовал. Даже привык и было удобно. Как-то раз были серьезные проблемы с установкой пакета с постфиксом (что-то типа torch==1.10.1cu106). У меня так знатно пригорело, что я его выпилил из проекта 🙂. Сейчас снова пробую, но уже в пет-прожекте.
- Используйте Pipenv
Внезапно, весь тот же функционал, что у Poetry (разве что не умеет публиковать пакеты в pypi). Не пробовал, но захотелось. Писали, что его забросили, но уже как два года стабильные релизы.

Есть ещё conda/miniconda, но что-то с ней у меня не задалось, хотя люди пользуются. Мб когда-нибудь попробую.

Поделитесь как вы управляете пакетами, чтобы в мире было меньше падений 🌝

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

Также нашёл прикольный сайтик, где генеративная музыка для той же цели.

Я считаю, что чтение чужого кода - это полезная практика. Так можно узнать другие подходы, подсмотреть что-то хорошее (ну и плохое тоже).

Наткнулся на пару (1, 2) шаблонов для датасаенс проекта.

Они построены вокруг менеджера конфигов hydra и фреймворка для экспериментов pytorch-lightning.

Гидра по идее позволяет красиво решить ситуацию, когда под каждый тип объекта у вас специфичные параметры (например, разные параметры для шедулеров или оптимизаторов). Пробовал её когда-то давно. Не прижилась, но уже не помню почему. Вообще выглядит красиво, когда конфиги разбиты по папкам и лежат в одном месте. Кажется, что гидра в проекте будет способствовать порядку в коде. Каждую модель/оптимизатор/шедулер вы будете класть в отдельное место, а трейнулпы будут унифицированы. Осталось понять, не будет ли эта красота мешать непосредственно вкручивать разнообразные твики 🌝

Лайтнинг же призван облегчить вам жизнь за счет того, что рыба трейнлупа со всякими свистелками в виде distributed learning/mixed precision/подсчета метрик уже реализована за вас. Два года назад решили использовать на работе в проекте. Не понравилось тогда. Было сыро, много мучались с тем, что и в каком формате надо откуда отдать, чтобы передать дальше. Сейчас же слышал лестные отзывы о нем. Думаю, что стоит внимания.

Что сказать, время идет, и фреймворки крепчают. Радует, что их не забросили и активно развивают.

Помните, астрологи объявляли неделю инференса? Так вот прошло две недели, и я сделал инференс модельки на Nvidia Triton Inference Server. Оформил это в туториал на хабре и репозиторий на гитхабе.

Постарался сделать так, чтобы можно было воспроизвести (Docker + Poetry), и было понятно, как этим воспользоваться (тесты).

Со следующей недели приступаю к реализации того же на TorchServe.

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

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

Если хочешь запустить со своей моделькой, то есть два варианта:
1. Перевести ее в onnx, что довольно замороченно (плюс fastdup будет ее инференсить на cpu);
2. Получить самостоятельно фичи, сложить их в numpy array и подать этой функции.

Кажется, что годная штука 👀

Увидел интересную книжку про то, как писать "чистый код" в мл проектах - Clean Machine Learning Code. Тут TLDR от автора.

По сути еще одна книжка про нейминг, солид, тестирование и тд, но с примерами из мл. Кажется, что если последовать всем советам, то получится очередной фреймворк для мл, по типу Pytorch Lightning.

Будет полезно, если хочется учить на примерах из своей сферы.

P.S. за pdf-кой можно в личку

Дочитал книжку Software Architect's handbook. Фундаментальный такой труд. По ней спокойно можно вести лекции целый семестр.

На мой взгляд, хорошо подходит для того, чтобы ознакомиться с разработкой архитекторы ПО. Раскрывает со всех сторон как процесс, так и скилы человека, который его двигает. Информация свежая.

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

Мне зашло. Читать, как я 🤓, от корки до корки не рекомендую, а вот просмотреть интересные вам главы - вполне. Точно пригодится, если вдруг обнаружите себя в роли архитектора какой-либо системы (даже маленькой).

Тут, кстати, список прочтенных мной книг, если кому интересно.

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

вместо этого

docker-compose up --build

делай это
docker-compose build --parallel
docker-compose up

Нашел интересную статью с антипатернами организации работы мл команд.
Ребята пошарили по MLops community (по подкастам и слаку) и систематизировали обсуждаемые там боли и их причины, а также предложили способы решения. На мой взгляд соответствует действительности.

Получилось 4 категории:
1. Проблемы с организацией работы
1.1 Долгие циклы релиза. Вызывается тем, что бывает сложно заставить работать код, который нужен для работы модели. Решается с помощью использования model registry.
1.2 Недопонимание между датасаентистами и теми, кто модельки использует (например, бекендеры). Вторые сетуют на говнокод. Решается объединением ребят в одну продуктовую команду и более тесным взаимодействием (код-ревью, парное программирование)
1.3 Блоки датасаентистов, которые вызваны необходимостью помочь бекендерам разобраться, как использовать вашу модель. Решается за счет введения model registry, стандартизации и тестирования.

2. Взаимодействие поставщиков и потребителей данных
2.1 Сложно получить данные. Поставщики данных не желают делать лишних действий, чтобы предоставить нужные данные. Возникает потому что запросы специфических данных могут потребовать реализации дополнительного функционала, который может и не понадобиться в будущем. Решается более тесным взаимодействием и объединением единой целью.
2.2 Сильная связанность между поставщиком и потребителем. Часть ответственности датасаентиста переносится на поставщика (например, расчет векторных представлений данных на уровне бд). Решается четким распределением зон ответственности и определения контрактов между командами.

3. Взаимодействие
3.1 Не шарятся фичи. Команды могут создавать разные фичи, которые могут быть полезны и другим. Решается за счет повышения доверия к работе других (тесты, документация, воспроизводимость) и шаринга знаний.
3.2 Разношерстная инфраструктура вокруг моделей. Для обучения модели нужна вспомогательная инфраструктура, которая перекликается у разных команд. Решается за счет шаринга знаний между командами, написания кода с прицелом на хотя бы минимальное переиспользование и унификацию процессов.

4. Руководство
4.1 Бездумный найм. Найм датасаентиста, когда для него нет продукта или не на ту роль (например, нужен был датаинженер). Решается четкого определения ролей. Также лучше отталкиваться от того, что человек умеет, а не кем себя называет.
4.2 Гонка за технологиями. Выбор технологий для проекта не из их целесообразности (экспертизы в команде, зрелости, числа кандидатов на рынке), а из-за интереса разработчика.
4.3 Хайпожорство. Засунуть мл везде, даже где не нужно или пока невозможно. Решается за счет повышения мл грамотности руководства, выбора правильной бизнес-метрики.

Одной строкой

Бот, который переводит pdf с архива в веб версию, чтобы было удобно смотреть с мобилки. Еще умеет отдельно показывать abstract, findings и делать summary

Cog
Еще один обертыватель моделек для продакшена.

Мы пишем класс предиктора и автомагически получаем докерфайл, апишку и очередь.

Звёздочек много, выглядит прикольно, но я бы сказал, что есть нюансы:
1. Моделька определяется в одном классе. Я не нашел примеров с более чем одной моделью. Исходя из текущего положения дел, там только последовательное выполнение.
2. Самописная очередь на редисе. Наверняка будут вылезать баги в реализации, пока решение не станет достаточно зрелым.

Выглядит, как штука, которая дает то же самое, что и более зрелые фреймворки для инференса (TorchServe, Triton) в плане обвязки, но не умеет скейлить модели, написано на питоне (против java и c++ соответственно) и менее зрелое.

Время покажет, но я не особо верю.

Единственное, поизучаю, как у них реализована очередь, так как я все в поиске идеального (на мой взгляд) решения.

Фух, я осилил распознавание номеров на TorchScript. Выложил статью на хабр 🙃.

Честно скажу, что Triton мне понравился больше. Как по мне, zip в качестве формата моделей - неудачное решение, так как сильно замедляет разработку. Сколько нервов было потрачено из-за того, что я банально забывал переконвертировать модели при внесении изменений в код... Также завести удаленный дебагер в докере в zip архиве было еще той задачкой. У меня получилось, но стек в нем так и не заработал.

Также мне не хватило гибкости при объединении моделек в пайплайн. В тритоне у тебя просто питоновский код, в котором ты волен накручивать любые конструкции из циклов и ифов. В торчскрипте с этим посложнее, так как у тебя нет возможности управлять ходом вызова моделей.

В общем, моим фаворитом все еще остается Triton.

P.S. на этой статье я завершаю свой затянувшийся цикл реализации одной задачи разными фреймворками. Дальше хочу поизучать, как сделать оптимизированный, скейлящийся под нагрузку сервинг моделей. Stay tuned!

Часто приходится поднимать API для моделей. Чтобы другим командам было удобнее подвязываться к ним (на самом деле, чтобы не донимали вопросами 🤫) необходима документация.

Как я делал быструю интерактивную документацию:

1. Использовал FastAPI
Как следует из названия, FastAPI позволяет быстро сделать апишку. Одна из его киллер-фич - это автогенерируемый свагер. Советую для новых проектов.

2. Добавлял свагер к Flask
В паре проектов апи написано на Flask. Я использовал Flasgger. Описываешь openapi в докстринге, и свагер готов. Не очень удобно, но работало. Однако, судя по истории коммитов, проект перестали поддерживать.

Вот этот проект выглядит поживее, и там не нужно вручную все прописывать. Похож чем-то на FastApi - нужно сначала определить схему данных, и свагер сгенерируется по ней.

3. Генерировал интерактивную json-схему
json-схема - это формат, который описывает json. То есть мы говорим, что это поле имеет такое-то имя, является числом и не может быть меньше нуля. Такую схему я задавал с помощью Pydantic. Дальше при каждом запуске при помощи JsonSchemaForHumans создавал статическую страничку с интерактивной документацией и добавлял ее к апи (например, так для FastApi). Получается дешево и сердито.

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

Наконец-то дошли руки почитать разбор Stable Diffusion. Всем советую разборы от этого дядечки. Его посты из серии Illustrated smth (Diffusion/Transformer/GPT/etc) - просто сказка.

Интересный видосик про то, как дебажить докер.

А вот мой топ советов по дебагу:
- docker compose config
Позволяет посмотреть получающийся конфиг компоуза. В нем, например, все пути абсолютные, что поможет понять, правильно ли примонтировали вольюмы. Также пишутся все переменные окружения.
- command: sleep
Если контейнер падает на этапе запуска, то меняем команду в конфиге компоуза на sleep и заходим внутрь него. Там уже экспериментируем.
- docker logs
Чтобы посмотреть логи контейнера. Для упавших контейнеров тоже можно их смотреть .
- docker exec -it container_name bash
Чтобы запустить bash в контейнере.
- progress —plain
Чтобы команды билда не исчезали.

Да прибудет с нами докер 😅

Что-то я пропустил видео о том, какие нейронки используются в автопилоте теслы. Там монструозная конструкция, которая по сути строит абстрактную карту местности «внутри сетки».

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

Из интересных млных моментов их архитектуры:
- Переиспользуют один backbone, чтобы ускорить как инференс, так и обучение.
- Backbone у них весьма простой (regnet - родственник resnet)
- FPN, чтобы смешать фичи с разных слоев
- Фичи с разных кадров кладут в очередь. Причем есть несколько очередей - по времени, по позиции в пространстве. Смешивают это через трансформер.
- Поверх всего какой-то заумный RNN, который и строит «ментальную карту»

Недурно 👏

Внезапно, но в редисе можно сервить модельки 😧

Для этого есть RedisAI. Поддерживает TorchServe, TensorFlow, TensorFlow Lite и Onnx. Умеет в CPU и GPU. Можно объявлять даги (графы, то бишь).

Нафига, а главное зачем? 🌝

Аргументы разработчиков:
1. Редис прошел огонь, воду и медные трубы. Проверенное временем решение
2. Если данные уже лежат в редисе, то не будете терять на чтении из БД

На мой взгляд спорная вещь. Даги простецкие и питоновский код не добавить, чтобы рулить ими. Как сделать несколько реплик одной модели тоже не понял. Решению уже три года и релизы стабильные, но все равно не внушает доверия. Кажется, что это весьма нишевая штука, если нужна супер-скорость, а данные все в редисе (хотя мне интересно, сохраняется ли эта скорость, если модель на GPU).

Меня не убедило, и редис все также в моей душе остается штукой для кеша.

Стандартизация - двигатель прогресса!

Оказывается, можно перегонять тензоры из одного фреймоворка в другой без копирования данных. Для этого придумали опенсорсное общее представление DLPack. Поддерживается много фреймворков (NumPy, CuPy, PyTorch, Tensorflow и др) и железа (CPU, CUDA, OpenCL, Vulkan и др.)

Пригодится, если вам вдруг приспичило перевести лежащий на GPU PyTorch тензор в Tensorflow без копирования. Выглядеть это будет как-то так:

import torch
import tensorflow as tf
pt_tensor = torch.randn(10).cuda()
tf_tensor = tf.experimental.dlpack.from_dlpack(torch.utils.dlpack.to_dlpack(pt_tensor))

Из более реальных примеров применения - копирование тензоров в моем любимом Triton.

Что-то я упустил Ray (хотя у них аж 25к звезд на гитхабе)

Судя по их описаию себя - они ну уж очень хороши. Поизучаю и приду с обзором 🙂