DeepSchool

Последний шанс записаться в осенний поток Помимо постов в этом канале, наша команда также создает курс по Computer Vision для практиков. Этот курс — повышение квалификации для Junior специалистов и возможность закрыть дыры в знаниях для Middle инженеров компьютерного зрения. На курсе Ракета в Computer Vision вы научитесь решать различные CV задачи, делать это в команде и проходить весь путь разработки полноценного сервиса: от сбора данных до автоматизации деплоя на сервер. Курс проходит в живом формате в виде zoom-вебинаров. На них спикеры - рассказывают лекции, - отвечают на вопросы, - проводят работу в группах - и обмениваются опытом со студентами. Последний пункт — отдельная ценность нашего курса, ведь большая часть студентов — практики с опытом в разных областях и направлениях. На 4 месяца они станут вашими коллегами вместе с кураторами курса. Старт ближайшего потока во вторник, 8 ноября. А следующего — в марте. Мы уже набрали полноценную группу, но осталось 4 места до лимита в 20 человек. Успейте записаться на консультацию, чтобы задать вопросы, познакомиться с одним из кураторов и принять решение об участии. Скажите на встрече, что вы наш подписчик, чтобы получить скидку :)

Виды сверток Собрали в одну статью различные виды сверток! Напомнили зачем существуют свертки 1х1, что такое Depthwise Separable Convolution, Spatialy Separable и другие. Не забыли и про нотку экзотики в виде Shuffled Grouped и Deformable. Читайте статью, чтобы вспомнить какие бывают свертки и чем они отличаются: https://telegra.ph/Vidy-2D-svertok-11-03

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

​​Вебинар по введению в разработку Недавно мы анонсировали вебинар и попросили вас заполнить гугл-форму. Спасибо всем за ваши ответы! Благодаря им мы уже скорректировали план лекции и выбрали оптимальное время. Решили не тянуть с обещанием и провести вебинар…

​​Вебинар по введению в разработку Недавно мы анонсировали вебинар и попросили вас заполнить гугл-форму. Спасибо всем за ваши ответы! Благодаря им мы уже скорректировали план лекции и выбрали оптимальное время. Решили не тянуть с обещанием и провести вебинар уже в этот вторник 1 ноября в 18:00 Мск🔥 Напомним, что вебинар расчитан на новичков, которые еще не знакомы с разработкой. На нем вы узнаете: - как обученную модель доставляют до клиентов, - как разворачивают приложение на сервере, - как автоматизируют доставку, - и как следят за ошибками и метриками. Чтобы зарегистрироваться, просто начните диалог с нашим ботом: @deepschool_webbot. До встречи на вебинаре!🚀

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

Вебинар по введению в разработку В посте про распределение нагрузки между GPU и CPU мы упомянули k8s. Еще тогда подумали рассказать что такое кубер в одном из постов, но тогда надо бы и докер упомянуть, да и CI/CD можно.. Плюс есть люди, которые вообще никогда не занимались разработкой. Поэтому мы решили провести вводную онлайн-лекцию, на которой расскажем как создают и поддерживают сервисы. Вебинар рассчитан на новичков, которые не сталкивались с разработкой. На нем мы обзорно рассмотрим что такое сервис, докер, кубер, мониторинг, ci/cd и другие базззворды🐝 За пару часов вебинара стать профи в этих темах нельзя, но понять, за что каждая из них отвечает — вполне :) Чтобы материал был еще полезнее, создали для вас короткую гугл-форму, через которую вы можете повлиять на содержание лекции и задать интересующие вас вопросы — на них мы ответим на вебинаре. Время вебинара сообщим на этой неделе! Кстати, в гугл-форме можно повлиять и на него :)

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

​​Давайте масштабировать только CPU-часть. Для этого вынесем ее в отдельный HTTP-сервис и сделаем столько реплик сервиса постпроцессинга, сколько нужно, чтобы CUDA-часть не простаивала (рис. 2 (а)). При таком подходе у нас не простаивает GPU и мы масштабируемся за счет относительно дешевых CPU (дешевых относительно видеокарт). Можно посылать все полигоны (по условию их сотни) с картинки в сервис постпроцессинга. Но лучше разбивать полигоны на батчи и уже батчи асинхронно слать в сервис постпроцессинга (рис. 2 (б)). Такой подход позволит нам лучше утилизировать CPU-часть и лучше масштабироваться. Это легко понять на простом примере: пусть к нам пришла только одна картинка и на ней 100 полигонов. Если мы пошлем все полигоны одним запросом, то будем ждать, пока один из зеленых сервисов их прожует. То есть мы вообще ничего не получили от масштабирования CPU-части. Но если мы разбили на пять батчей и каждый послали отдельным запросом, то над ними будут трудиться уже пять зеленых сервисов и мы ускоримся в пять раз. Далее, когда докидывание CPU-сервисов перестает давать прирост к производительности, мы начнем докидывать еще и GPU-сервисы (рис. 2 (c)). Можно заметить, что у нас появились накладные расходы на сеть, но будем считать, что они малы по сравнению с временем работы постпроцессинга. Скорее всего, нагрузка на такой сервис не будет равномерной. Это значит, например, что в одно время суток нам нужно будет сто зеленых сервисов, а в другое время мы обошлись бы и десятью. Здесь, например, нас может выручить HPA. Он позволит нам автоматически разворачивать новые зеленые сервисы, например, тогда, когда утилизация CPU становится больше некоторого порога. Еще можно сказать, что подход с HTTP-запросами и сервисами может быть заменен на подход с промежуточной очередью и воркерами. Он будет спасать нас, например, от резких всплесков нагрузки. Но в условиях несложной задачки будем считать этот пункт не очень важным 😉

​​Ответ на вопрос с собеседования💼 Будем считать, что у нас есть условный k8s и нам не нужно греть голову над балансировкой запросов между репликами, оно как-то само заработает 🙂. И пусть картинки к нам приходят по HTTP. Нашу систему можно упрощенно нарисовать как на рис. 1 (a). Есть сетка на GPU и выход из нее мы передаем в постпроцессинг, который молотит полигоны на CPU. Первый вариант, который может прийти в голову: а давайте просто горизонтально масштабировать всю систему целиком (рис. 1(b)). Так делать плохо. По условию наша сетка работает в 20 раз быстрее, чем постпроцессинг. Т.е. почти всё время наши дорогущие GPU-мощности простаивают. Получается, при таком масштабировании мы вместо одной дорогущей простаивающей видеокарты получаем много дорогущих простаивающих видеокарт. Не дела.

​​Рубрика «Вопрос с собеседования»💼 У вас есть сетка, которая умеет на спутниковом снимке находить маски домиков. Затем эти маски нужно превратить в полигоны домиков. Вряд ли ваша сетка умеет сегментировать pixel-perfect. Поэтому получится полигон как на картинке (b). У этого полигона слишком много вершин и такой рваный домик на карту не поставишь. Поэтому будем постпроцессить такой полигон. Нам нужно, чтобы было поменьше вершин и побольше прямых углов и параллельных сторон. Получим приятный полигон как на картинке (c). На одной картинке могут быть сотни таких полигонов. Поэтому постпроцессинг может стать боттлнеком вашей системы. Вопрос Пусть в среднем нейросеть предсказывает маску за 100мс, а постпроцессинг в среднем занимает 2с. Вам нужно ускорить работу системы. Считаем, что сам код оптимизирован идеально. Поэтому для ускорения остается только заваливать задачу железом (масштабироваться). Ваши действия?

Вы когда-нибудь путались в функциях потерь для классификации? BCE, log-loss, Cross Entropy, Focal Loss — одно является частным случаем другого, третье выражается через четвертое, еще и в разных статьях свапают названия между собой) Если хотите вспомнить кто есть кто, то мы подготовили для вас статью Функции потерь для классификации. В ней мы также напомним: - кто такой Brier Score; - когда в задаче классификации может сработать MSE; - что можно сделать с функцией потерь при дисбалансе классов; - да, в прошлом пункте нет интриги, можно взвесить классы — но что если в минорном классе есть простые примеры, которые сеть учит легко и быстро, а в мажорном сложные? В чем тут может быть проблема и как ее решить? В общем, есть что вспомнить, давайте закрепим знания вместе: https://telegra.ph/Funkcii-poter-dlya-klassifikacii-10-12