Записали для вас видео про ускорение инференса! 🚀

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

Это наш дебют на ютубе! Будем рады поддержке) Подписывайтесь и ставьте лайки если вам понравилось видео в подобном формате👍

Переходите по ссылке, чтобы посмотреть: https://youtu.be/6UJn0J1Sul4

Сегодня вторник, а значит в эфире рубрика “повторяем теорию”🤓

Вспомним про регуляризацию сетей, а именно про три популярных метода: L1, L2 и Dropout (ведь был популярен когда-то, надо отдать дань старичку). Статья в телеграфе 👉 Регуляризуем правильно!

#регуляризация #L1 #L2 #dropout

Хотели рассказать вам про Efficient Net, потому что многие путаются в этой архитектуре и не до конца понимают причем тут “efficient” то вообще) Взяли на себя ответственность поставить точку в этом вопросе. Чтобы в следующий раз, когда вас спросят что это за EffNet такой, вы без проблем могли ответить.

Изучать архитектуры — полезно. Эти знания позволят вам правильно подобрать сеть под ваши задачи и ограничения, а иногда даже помогут пропатчить какую-нибудь китайскую сетку, чтобы потом сконвертить ее в TRT))

Но рассказывая про EffNet, нельзя не упомянуть MBConv блоки из MobileNet. Объясняя Inverted Residual хорошо бы рассказать про обычный Residual и так далее. Поэтому логичнее уже пройтись по всей истории эволюции и начать с VGG😅

Вот и начали… Представляем вашему вниманию первую статью из серии “вспоминаем архитектуры”: разбираем VGG. Давайте вместе пройдемся по истории и вспомним/изучим/дополним_наши_знания: https://telegra.ph/VGG-10-10

Вы когда-нибудь путались в функциях потерь для классификации? BCE, log-loss, Cross Entropy, Focal Loss — одно является частным случаем другого, третье выражается через четвертое, еще и в разных статьях свапают названия между собой)

Если хотите вспомнить кто есть кто, то мы подготовили для вас статью Функции потерь для классификации.

В ней мы также напомним:
- кто такой Brier Score;
- когда в задаче классификации может сработать MSE;
- что можно сделать с функцией потерь при дисбалансе классов;
- да, в прошлом пункте нет интриги, можно взвесить классы — но что если в минорном классе есть простые примеры, которые сеть учит легко и быстро, а в мажорном сложные? В чем тут может быть проблема и как ее решить?

В общем, есть что вспомнить, давайте закрепим знания вместе: https://telegra.ph/Funkcii-poter-dlya-klassifikacii-10-12

​​Рубрика «Вопрос с собеседования»💼

У вас есть сетка, которая умеет на спутниковом снимке находить маски домиков. Затем эти маски нужно превратить в полигоны домиков.

Вряд ли ваша сетка умеет сегментировать pixel-perfect. Поэтому получится полигон как на картинке (b). У этого полигона слишком много вершин и такой рваный домик на карту не поставишь. Поэтому будем постпроцессить такой полигон. Нам нужно, чтобы было поменьше вершин и побольше прямых углов и параллельных сторон. Получим приятный полигон как на картинке (c).

На одной картинке могут быть сотни таких полигонов. Поэтому постпроцессинг может стать боттлнеком вашей системы.

Вопрос

Пусть в среднем нейросеть предсказывает маску за 100мс, а постпроцессинг в среднем занимает 2с. Вам нужно ускорить работу системы. Считаем, что сам код оптимизирован идеально. Поэтому для ускорения остается только заваливать задачу железом (масштабироваться). Ваши действия?

​​Ответ на вопрос с собеседования💼

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

Нашу систему можно упрощенно нарисовать как на рис. 1 (a). Есть сетка на GPU и выход из нее мы передаем в постпроцессинг, который молотит полигоны на CPU.

Первый вариант, который может прийти в голову: а давайте просто горизонтально масштабировать всю систему целиком (рис. 1(b)). Так делать плохо. По условию наша сетка работает в 20 раз быстрее, чем постпроцессинг. Т.е. почти всё время наши дорогущие GPU-мощности простаивают. Получается, при таком масштабировании мы вместо одной дорогущей простаивающей видеокарты получаем много дорогущих простаивающих видеокарт. Не дела.

​​Давайте масштабировать только CPU-часть. Для этого вынесем ее в отдельный HTTP-сервис и сделаем столько реплик сервиса постпроцессинга, сколько нужно, чтобы CUDA-часть не простаивала (рис. 2 (а)). При таком подходе у нас не простаивает GPU и мы масштабируемся за счет относительно дешевых CPU (дешевых относительно видеокарт).

Можно посылать все полигоны (по условию их сотни) с картинки в сервис постпроцессинга. Но лучше разбивать полигоны на батчи и уже батчи асинхронно слать в сервис постпроцессинга (рис. 2 (б)). Такой подход позволит нам лучше утилизировать CPU-часть и лучше масштабироваться.
Это легко понять на простом примере: пусть к нам пришла только одна картинка и на ней 100 полигонов. Если мы пошлем все полигоны одним запросом, то будем ждать, пока один из зеленых сервисов их прожует. То есть мы вообще ничего не получили от масштабирования CPU-части. Но если мы разбили на пять батчей и каждый послали отдельным запросом, то над ними будут трудиться уже пять зеленых сервисов и мы ускоримся в пять раз.

Далее, когда докидывание CPU-сервисов перестает давать прирост к производительности, мы начнем докидывать еще и GPU-сервисы (рис. 2 (c)).

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

Скорее всего, нагрузка на такой сервис не будет равномерной. Это значит, например, что в одно время суток нам нужно будет сто зеленых сервисов, а в другое время мы обошлись бы и десятью. Здесь, например, нас может выручить HPA. Он позволит нам автоматически разворачивать новые зеленые сервисы, например, тогда, когда утилизация CPU становится больше некоторого порога.

Еще можно сказать, что подход с HTTP-запросами и сервисами может быть заменен на подход с промежуточной очередью и воркерами. Он будет спасать нас, например, от резких всплесков нагрузки. Но в условиях несложной задачки будем считать этот пункт не очень важным 😉

Как понять где ваш код тормозит
⠀
Недавно мы рассказали про два простых метода ускорения сетей: фьюзинг и дистилляция. Но не архитектурными трюками едины! Эффективно написанный код может также бустануть ваш инференс или тренировку.

Но как понять что код эффективен? Использовать профилировщики! В новой статье мы рассказали про вариант, который хорошо подойдет под специфику DL: Профилировщик torch.profiler — читайте и пишите эффективный код✌️

Вебинар по введению в разработку

В посте про распределение нагрузки между GPU и CPU мы упомянули k8s. Еще тогда подумали рассказать что такое кубер в одном из постов, но тогда надо бы и докер упомянуть, да и CI/CD можно.. Плюс есть люди, которые вообще никогда не занимались разработкой. Поэтому мы решили провести вводную онлайн-лекцию, на которой расскажем как создают и поддерживают сервисы.

Вебинар рассчитан на новичков, которые не сталкивались с разработкой. На нем мы обзорно рассмотрим что такое сервис, докер, кубер, мониторинг, ci/cd и другие базззворды🐝 За пару часов вебинара стать профи в этих темах нельзя, но понять, за что каждая из них отвечает — вполне :)

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

Время вебинара сообщим на этой неделе! Кстати, в гугл-форме можно повлиять и на него :)

Продолжаем ликбез по архитектурам

В прошлый раз мы рассказывали про VGG, теперь вспоминаем как зародилось семейство ResNet.

В отличии от VGG, ResNet не стыдно использовать в привычных CV задачах даже в 2022 году. Надо лишь знать как ее учить — об мы, кстати, рассказывали в серии предыдущих постов.

В новой же статье отдаем дань старичку и вспоминаем:
- изначальную идею,
- пользу ботлнек блоков
- и основной вклад identity веток в deep learning

​​Вебинар по введению в разработку

Недавно мы анонсировали вебинар и попросили вас заполнить гугл-форму. Спасибо всем за ваши ответы! Благодаря им мы уже скорректировали план лекции и выбрали оптимальное время. Решили не тянуть с обещанием и провести вебинар уже в этот вторник 1 ноября в 18:00 Мск🔥

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

Чтобы зарегистрироваться, просто начните диалог с нашим ботом: @deepschool_webbot. До встречи на вебинаре!🚀

Провели наш первый вебинар! Спасибо всем кто заполнял формы, оставлял вопросы, участвовал в вебинаре и предлагал новые темы❤️

Получили несколько сообщений с просьбой повторить вебинар, поэтому хотим оценить количество желающих. Поставьте, пожалуйста, китенка в реакцию, если хотите повтор🐳 Наберем 30 китов — повторим!

Однако, не ожидали, что за 30 минут наберем 30 китов😅
Повтору — быть!

Анонсируем дату позднее в этом канале

Виды сверток

Собрали в одну статью различные виды сверток!
Напомнили зачем существуют свертки 1х1, что такое Depthwise Separable Convolution, Spatialy Separable и другие. Не забыли и про нотку экзотики в виде Shuffled Grouped и Deformable.

Читайте статью, чтобы вспомнить какие бывают свертки и чем они отличаются: https://telegra.ph/Vidy-2D-svertok-11-03

Последний шанс записаться в осенний поток

Помимо постов в этом канале, наша команда также создает курс по Computer Vision для практиков. Этот курс — повышение квалификации для Junior специалистов и возможность закрыть дыры в знаниях для Middle инженеров компьютерного зрения.

На курсе Ракета в Computer Vision вы научитесь решать различные CV задачи, делать это в команде и проходить весь путь разработки полноценного сервиса: от сбора данных до автоматизации деплоя на сервер.

Курс проходит в живом формате в виде zoom-вебинаров. На них спикеры
- рассказывают лекции,
- отвечают на вопросы,
- проводят работу в группах
- и обмениваются опытом со студентами.
Последний пункт — отдельная ценность нашего курса, ведь большая часть студентов — практики с опытом в разных областях и направлениях. На 4 месяца они станут вашими коллегами вместе с кураторами курса.

Старт ближайшего потока во вторник, 8 ноября. А следующего — в марте. Мы уже набрали полноценную группу, но осталось 4 места до лимита в 20 человек. Успейте записаться на консультацию, чтобы задать вопросы, познакомиться с одним из кураторов и принять решение об участии. Скажите на встрече, что вы наш подписчик, чтобы получить скидку :)

С началом нового потока курса пришлось отвлечься от написания статей в телеграм) Но теперь мы снова встали на рельсы и уже подготовили несколько интересных постов для вас! Начнем с одной довольно популярной задачки…

​​Задачка на подумать:

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

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

В итоге может получиться такой словарик (рис. 1):

{
'img1': {'img2', 'img10', 'img15'},
'img2': {'img1', 'img10', 'img15', 'img20'},
...
}

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

В таком подходе возникнет следующая проблема: получившееся отношение дублируемости не транзитивно. Это значит, что по расстоянию между эмбеддингами может получиться что-то такое (рис. 2):

{
'img1': {'img2', 'img3'},
'img2': {'img1'},
'img3': {'img1'},
}

т.е. img2 и img3 дублируют img1, но не дублируют друг друга. Кажется, в такой ситуации мы хотим сказать, что все картинки (img1, img2, img3) являются дубликатами друг друга. Ситуацию, при которой из-за такого подхода мы начнем даже очень непохожие картинки называть дублями, мы не рассматриваем, она малореалистична.

Как этого достичь?

Ответ опубликуем завтра

​​Решение

Первое решение, которое может прийти в голову: для каждой картинки в словаре пройдемся по ее дубликатам. И объединим множество дубликатов картинки с множествами дубликатов для каждого дубликата этой картинки. Но такое решение будет работать долго и неправильно. Долго потому что операция объединения множеств имеет линейную сложность, т.е. мы получим итоговую квадратичную сложность. А неправильно потому что может быть такая ситуация (рис. 1):

# input
{
'img2': {'img1'},
'img3': {'img1', 'img4'},
'img1': {'img2', 'img3'},

}

# output
{
'img2': {'img1', 'img3'},
'img3': {'img1', 'img4', 'img2'},
'img1': {'img2', 'img3', 'img4'},

}

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

Корректное и быстрое решение можно сделать при помощи структуры данных система непересекающихся множеств (Disjoint-set). Библиотечка для python. Но там буквально несколько строк, можно и самим написать.

В этой структуре данных все объекты хранятся в непересекающихся множествах.

У нее есть две операции:

- get(x) — возвращает некоторого представителя из множества, которому принадлежит объект x
- union(x, y) — объединяет два множества, в которых лежат объекты x и y

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

{img1, img2, img3}, {img4, img5}, {img6, img7}

get(img1) вернет нам одно из значений из множества {img1, img2, img3}. Т.е. некоторого представителя этого множества
union(img2, img4) преобразует систему множеств к такому виду:

{img1, img2, img3, img4, img5}, {img6, img7}

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

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

MobileNet v1-v3

Разобрали для вас сразу три статьи в одной! В ней мы рассказали про революционное семейство архитектур MobileNet и выписали все трюки, которые использовали авторы в каждой из версий архитектуры.

Как можно догадаться из названия, MobileNet — отличная архитектура для инференса на мобильных устройствах. Статьи о ней принесли в мир CV несколько ключевых идей по ускорению и облегчению сетей. Многие из этих идей используются до сих пор и наследуются в других работах (в той же EfficientNet). Поэтому очень сложно переоценить важность этих архитектур.

Очень рекомендуем к прочтению! Изложили все идеи простым языком и подчеркнули несколько интересных нюансов.

Например, вы знали, зачем в MobileNet v2 убрали нелинейность между некоторыми свертками? Или помните почему свертки 1х1 считаются быстрее других (даже с поправкой на кол-во параметров)? Если нет и хотите узнать или вспомнить, читайте нашу новую статью: https://telegra.ph/MobileNet-v1-v3-11-24 🔥

Вспоминаем статистику!

Начинаем серию постов про проверку статистических гипотез.

В новой статье рассказали о том, что такое статистические тесты и зачем они вообще нужны. Напомнили что значит «репрезентативная выборка», стат. критерий, стат. значимость, ошибки первого/второго рода и другое.
Читайте подробнее в статье: https://telegra.ph/Proverka-statisticheskih-gipotez-Vvedenie-12-05