Чеклист от создателей TorchServe по оптимизации инференса.
Забавно что первым пунктом рекомендуют обновить версии PyTorch и Nvidia ))0)

Тут ребята решили сделать линтер для PyTorch - TorchFix. Есть видео-презентация.

Зачем?
- Чтобы помочь нам не выстрелить себе в ногу опечаткой (например, param.require_grad вместо param.requires_grad)
- Чтобы отучать нас использовать deprecated функционал

Я как любитель линтеров приветствую такие инициативы. Но пока он весьма примитивен, например require_grad = condition не сработает. Не уверен, что он приживется, но было бы неплохо.

Во вторник буду выступать на PyterPy с докладом о сравнении фреймворков для сервинга. Так сказать, закрываю гештальт. Кстати, это мой дебют 👀.

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

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

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

P.S. мне дали промокод на скидку 25% на билеты для частных лиц - Shestopalov2023JRGpc. Вдруг кому пригодится.

Что-то я упустил, что в PyTorch появился inference_mode. Аналогичен no_grad, но не только выключает градиенты, но и disabling view tracking and version counter bumps.

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

Это мы пробуем

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

Занимаюсь сейчас сегментацией и решил попробовать какую-нибудь библиотечку для этого. Выбор пал на cleanlab

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

Понравилось что оно:
- Работает для сегментации (и кучи других задач)
- Очень легко завелось (документации и примера хватило + оно реально работает)

А вот не понравилось, что толку от тулзы для меня было мало ))0). Моделька пока далеко от идеала, и на определенных примерах сильно косячит. Тулза видит несоответствие и радостно мне рапортует, что вот, мол, у тебя тут в разметке косяки ))0).
Также они прямо в доке говорят, что их способ имеет смысл применять только на отложенных выборках (то бишь валидации и тесте), потому что на трейн мы можем быть затюнеными. Если хочешь всю датку почистить - будь добр сделать KFold и обучить K моделек. Этого делать мы, конечно, же не будем.

Поделитесь в комментариях своим опытом. Что вам реально помогло при поиске ошибок в разметке? Я вот слышал от коллеги, что он использовал методы, которые смотрят на поведение лосса во время обучения, и это неплохо работало

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

Так вот для ультимативного счастья, встройте декодинг картинок прямо в сетку. Это умеют как tf, так и torch (он вообще может сделать это на GPU).

torch.decode_image()
tf.decode_image()

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

Вроде простая мысль, а я вот не знал 🙂

Интересная статья про БАЗУ при оптимизации обучения - а именно про то, а чего такого происходит под капотом, когда мы на GPU обучение делаем.

Но оно нам вообще зачем, если можно stack more layers, fit, predict и все такое? Как бы можно и без этого, но до тех пор, пока все идет хорошо. Мне нравится аналогия с машинами.

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

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

Теперь TLDR статейки.

Проблема - обучение идет медленно. Как исправлять?

При обучении сеточек на GPU время тратится на:
1. Вычисления
Непосредственно выполнение подсчетов
2. Перессылку данных внутри GPU
В GPU есть две памяти DRAM (много, но долго) и SRAM (мало, но быстро). Чтобы выполнить операцию, нужно переместить данные из DRAM в SRAM и обратно
3. Работу питоновских фреймворков
Pytorch, Tensorflow и другие требуют времени на свою работу

В зависимости от того, что превалирует, обучение будет в одном из "режимов":
1. Compute - большую часть времени вычисляем
2. Memory - большую часть времени перемещаем данные
3. Overhead - большую часть времени тритим на работу питонячего фреймворка

Так вот автор предлагает постоянно пытаться определить, в каком вы режиме, и в оптимизации обучения/инференса отталкиваться от него:
1. Compute
Берем более быстрое железо (TPU или просто заменить GPU на более свежую)
2. Memory
Фьюзить операторы - то есть соединять несколько операций в одну (torch.script / tf.function)
3. Overhead
Фьюзить операторы, переписать на плюсы (ну или раст лол)

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

Блоки:
- Опенсорс
- RL
- Medical Imaging
- ML в промышленности
- LLM в бизнесе
- CV
- MLOps
- NLP
- Карьера в ML
- RecSys
- Python и библиотеки для данных

Получилось годно. Советую

Прикольный инструмент FiftyOne, если надо быстро визуализировать данные.

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

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

P.S. Люблю, когда в пару команд можно поднять такой большой комбайн. Опенсорс - это внатуре класс.

Уже с месяц пользуюсь git-worktree и это очень удобно для проведения экспериментов.

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

Но вот этот переход всегда вызывал дискомфорт. Код, который я поменял для обучения (выставил параметры, поправил пути, сделал небольшие твики) я либо комитил (а это банально не всегда удобно, потому что не факт, что я его захочу оставить в ветке), либо запихивал в stash (и у меня образовывается гора stash-ей для разных веток). Также я мог по невнимательности какой-то stash потереть.

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

Но потом я попробовал worktees 😱. Они позволяют вам иметь одновременно зачекаученными несколько веток. Больше не нужно переключаться между ними! Я работаю параллельно. Это такой кайф...

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

Но есть и минусы:
1. Для каждой ветки у вас по факту новая папка (так это реализовано в git). Поэтому для IDE каждый раз это как новый проект.
2. Если у вас есть локальные файлы, которых нет в ветках (у меня это папка со скриптами, личный pre-commit config и настройки VsCode), они не появятся в свеже отчекаученной ветке. Их нужно копировать. Я приноровился делать линки на них при создании ветки.
3. Нужно потратить время, чтобы понять команды git worktree. Я чет долго осознавал их 🙂

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

P.S. Если вбить в ютубе "git worktree", то вам выпадет такой видос на 200к просмотров. Там автор советует сделать bare репозиторий. Не совершайте моих ошибок ))0) Я сделал и долго не мог понять, а куда же у меня пропал origin 🙈

В итоге в обычном репозитории (не bare) создал папку .worktrees и добавляю ветки туда вот так: git worktree add .worktrees/your_branch_name

Там у Джереми Ховарда на Ютуб выходят лекции (1, 2) по программированию на CUDA (который fast.ai сделал и не последний человек в kaggle)

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

UPD: в комментах сказали, что это эдакий ридинг клуб, и вот канал и с другими лекциями

Open vocabulary detection докатилась и до YOLO! Имя ему - YOLO-World

То есть, теперь можно делать zero-shot детекцию (как в GLIP или Grounding DINO). Берем охапку текстовых описаний категорий, и суп готов. Всё это со скоростями йолки.

Как работает:
1. Тексты категорий прогоняется через CLIP
2. Картинка прогоняется через бекбон
3. Картиночные фичи атендятся на текстовые (T-CSPLayer)
4. Текстовые фичи атендятся на картиночные (I-Pooling Attention)
5. Оценивается похожесть объектов и текстов (text-contrastive head)

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

Рапортуют также, что это всё хорошо файнтьюнится

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

Выглядит интересно. Такое нам надо

Сегодня пост про статью моего любимого жанра - "если А, бери Б" 🌝

Встречайте - Battle of the Backbones. Ребята взялись найти лучший бекбоун для задачек Computer Vision. Искали для четырех задач - классификация, детекция, сегментация, image retrieval и определение out of distribustion. Подход прост - учили разные комбинация на разных датасетах, а потом смотрели, где метрики лучше.

Итого:

Топ средних по размеру бекбоунов:
- supervised ConvNeXt-Base
- supervised SwinV2-Base trained using ImageNet-21k
- CLIP ViT-Base

Топ маленьких бекбоунов:
- ConvNeXt-Tiny
- SwinV2-Tiny
- DINO ViT-Small

Более подробный топ по каждой задаче на картинке.

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

Пару интересных выводов от авторов:
- CNN часто опережает ванильный ViT (а неванильные заимствуют идеи у CNN - например, swin)
- при одинаковом количестве данных self-supervised претрейн (типа SimCLR, DINO) оказывается лучше

Выкатили pip на rust - называется uv

Зачем? Все просто - чтобы было быстро 👉👈

Тулза имеет совместимый с pip и pip-tools интерфейс. Типа просто приписал uv в начало любой команды - и получил прирост к скорости

Вот так

uv pip install torch
uv pip compile requirements.in

Попробовал и скажу, что это реальный кайф! Все летает. Торч заметно быстро поставился. Сильно быстрее стали pip compile, pip sync. Ультимативно рекомендую!

Установка простейшая - просто как pip пакет.

P.S. 1 - тулза пока не поддерживает всех всех возможностей pip, так что повнимательнее изучите вопрос, если будете затаскивать ее к себе в проект

P.S. 2 - интересно, как разработчики (ASTRAL) будут монетизировать проект. Хотелось бы верить что, ни в ruff, ни в uv не затянут часть фич в платную версию

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

В итоге моя любимая - это imagededup. Оставлю ее здесь (даже с кодом в комменте)

Вот бы кто-нибудь переписал на раст ))0)

#tool

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

Вообще не раз сталкивался с задачей, что нужен хеш, который учитывает контекст. Но каждый раз забывал, а что же я использовал в прошлый раз 🤡. Как понимаете - чтобы не забыть в следующий раз - я пишу сюда пост ))0)

Чего мы хотим?
- Найти дубликаты картинок
Что мы для этого сделаем?
- Возьмем Perceptual hashes

Perceptual - это такие, которые при изменении одного пикселя должны практически не поменяться (в отличие от хешей криптографических - sha256, md5 и тд)

В нашем распоряжении есть:
- Average hash
- Perceptual hash
- Wavelet hash
- Difference hash
- Color hash
- Crop-resistant hash

Первые 4 похожи:
1. Ресайзим картинку, чтобы быстрее считать хеш (обычно 8х8)
2. Переводим в ч/б (тоже для скорости)
3. Находим число, с которым будем сравниваться
- Для Average hash - это просто среднее всех пикселей
- Для Perceptual hash - считаем дискретное косинусное преобразование (типа того, что делается в JPEG) и считаем среднее от части его низких компонент
- Для Wavelet hash - то же самое, что для предыдущего, но вместо косинусного - вейвлет
- Для Difference hash - не берем среднее, а сравниваем каждый пиксель с соседом справа
4. Делаем хеш из h*w чисел (64 если мы ресайзили в 8x8). Ставим 1, если больше среднего (или правого соседа для Difference hash), 0 - если меньше

Color hash - переводит картинку в HSV и учитывает в хеше отдельно каждую компоненту
Crop-resistant hash - разделяет картинку на несколько сегментов и считает хеш от каждого. Далее сравнивает с каждым их хешей

Чтобы сравнить два хеша - считаем число отличающихся битов (расстояние Хэмминга)

Ну собственно выбираем хеш под задачу. Можно комбинировать - например сначала считать быстрые хеши (Difference hash, Average hash), а в случае позитива считать медленный.

Использовать можно либку imagehash

#tool

Недавно смотрел код ultralytics, и мне понравился их класс для взаимодействия с тритоном.
Инкапсулирует взаимодействие - подаешь numpy -> получаешь numpy. Удобно

У меня много подписок на каналы компаний, куда выкладывают записи докладов с митапов.

Подъехала пачка от МТС. Вот плейлист. Мне понравился доклад про карьеру в мл. Ещё из интересного три доклада про мл в Авито, Ламоде и Кион. Также неплохой вводный про адаптацию ллм под домен.

P.S. Если интересно узнавать о новых поступлениях записей, поставьте 👍 (иначе - палец вниз)

Обещанная презентация с доклада. Спасибо всем, кто пришел!

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

Чтобы после дообучения CLIP на вашем домене не терять способность на других данных, нужно всего лишь...

Линейно объединить дообученые и оригинальные веса. Работает как на end2end дообучении, так когда только последний линейный слой. Назвали это wise-ft. При этом меняя коэффициент alpha, можно настраивать баланс (лучше в OOD, либо в нашем домене)

Код оооооочень сложной реализации:

# Load models
zeroshot, finetuned = ImageClassifier.load(zeroshot_checkpoint), ImageClassifier.load(finetuned_checkpoint)
theta_0, theta_1 = zeroshot.state_dict(), finetuned.state_dict()

# interpolate between checkpoints with mixing coefficient alpha
theta = {
    key: (1-alpha) * theta_0[key] + alpha * theta_1[key]
    for key in theta_0.keys()
}

# update the model acccording to the new weights
finetuned.load_state_dict(theta)

Вот такая вот простая идея 🌝

#trick