Pragmatic ML

Cloudflare — пример того, как нужно решать вопросики. Даже за вычетом их крутых продуктов, которыми пользуется весь мир, (например 1.1.1.1 и CDN), они идут в сторону своей миссии — открытого и безопасного интернета для всех. Они пишут очень крутые постмортемы (рекомендую прочитать последний), делают крутые партнерки (serverless деплой модельки с HF на CDN), а также сражаются с патентными троллями, о чем и сегодняшний пост восхищения. Семь лет Cloudflare судился с юристами, купившими пакет патентов закрывшейся компании. И вот наконец успех — они не только выиграли, но и аннулировали патент истца. Я работал с одним стартапом, основным конкурентным преимуществом которого было удерживание широкого патента на основных рынках продаж. Штош, удобно душить конкурентов, можно и не развиваться. Для меня патентная система в текущем виде выглядит как рудимент, который позволяет людям, неспособным на развитие, блокировать прогресс просто на корню. Компании, вместо того чтобы создавать конкурентное преимущество развитием, пытаются придушить конкурентом бумажкой. И я очень рад, что Cloudflare своим примером показывает, что с этим можно и нужно бороться.

В одной из первых домашек курса Efficient Deep Learning Systems предлагается порешать маленькие задачки, чтобы научить глубже понимать, как работает код на GPU – https://github.com/srush/GPU-Puzzles. 14 небольших задач на Python+NUMBA – несколько прекрасных вечеров, проведенных за решением этих головоломок, вам обеспечены. У srush много подобных занимательных задач, есть и про распределенное обучение, и про трансформеры Но если вам хочется еще глубже покопаться вокруг CUDA, то можно стартануть с источника, упомянутого недавно в LDT

На фоне того, что Цукерберг скупает сотни H100 для обучения новых версий LLama, все остальные начинают страдать от нехватки high-end видеокарт. А что делать бедным ресерчерам, у которых нет доступа к таким ресурсам? Ну например, пробовать дообучать большие модели через децентрализацию, как делают в Petals. Или, как предложили те же авторы Petals, обучать их, используя SWARM Parallelism. Сегодня разбор именно этого подхода. Ссылка на статью – SWARM Parallelism: Training Large Models Can Be Surprisingly Communication-Efficient У автора этой статьи в том числе есть прекрасный курс под названием “Efficient Deep Learning Systems”, который я однозначно рекомендую всем, кто хочет погрузиться в DL с инженерной стороны. Есть и про менеджмент экспериментов, и про деплой на сервера/девайсы, и про профайлинг/мониторинг кода.

Наверное, стоит отдельно рассказать про топ 1 решение Kaggle соревы из поста выше. Не буду вдаваться глубоко в детали моделей, так как победители одновременно являются сотрудниками компании Owkin, которая занимается почти такой же задачей. Так что они использовали обученный у себя ViT(Phikon) как backbone для генерации признаков. Идея понятная — несколько разных ViT-like моделей как генераторы эмбеддов из кусков большой картинки. Дальше, ансамбль MIL (Multiple Instance Learning) моделей (опять один из вариантов — их личная идея, даже статью написали 3 года назад, об этом ниже). А теперь о интересном: — Написали свою тулзу на C и libpng, чтобы быстро делать random access в png, выделять кусок картинки и сохранять его на диск в виде png картинки; — Заюзали Ray (такой низкоуровневый фреймворк для качественного распараллеливания python кода) внутри кернела, чтобы быстрее процессить картинки. Запускали 2 процесса, каждый использует по 0.5 P100, ускорили процессинг картинок с 10 часов до 7. Я дико топлю за Ray, в первую очередь как замену Spark, сделаю отдельный пост скоро; — Вспомнили, что вообще-то старый CV не сильно мертв, и определять, есть ли на картинки клетки или мы опять фон нарезали, можно с помощью Otsu thresholding в HSV space. Кстати, что такое MIL — часто бывает ситуация, что у нас дана одна метка на некоторую группу объектов. Это могут быть данные из разных источников, или, как в случае соревы, множество картинок, вырезанных из большой картинки. Авторы топ 1 решения еще в 2020 году написали статью об интерпретируемом подходе построения MIL модели (Chowder), который все еще является SoTA для медицинских срезов. В общем, супер молодцы, заслуженная победа, применили свой богатый опыт и свои же модели.

Про аугментации. Я довольно давно не копался в CV. Последнее, что я помнил — albumentations лучшие в плане скорости работы и ассортимента методов в API. С тех пор не сильно что-то изменилось, кроме того, что я успел подергать torchvision в Мете, и он мне реально понравился в плане удобства и скорости работы. В рамках соревы все-таки задался вопросом, что сейчас происходит в аугментациях. Рассказываю. Ну во-первых, все решили, что для foundational моделек аугментации не нужны, так как данных и так достаточно. Дальше появились интересные решения вида kornia и NVIDIA DALI с возможностью делать аугментации прямо на GPU, за счет чего получать весомый буст в производительности. Мне очень не нравится бенчмарк, предоставленный albumentations. Ровно потому что они: — сравнивают отдельно по операциям; — оценивают скорость в количестве обрабатываемых картинок в секунду. Это логично, если мы исходим из предположения, что весь пайплайн аугментаций работает со скоростью самой медленной операции в нем. Ну и, дополнительно, из предположения, что аугментации происходят сразу после загрузки, по одной картинке за раз (то есть MixUp и CutMix выпадают). Но кажется, что на самом деле первое утверждение не совсем корректно, так как не учитываются оверхед самого фреймворка аугментаций и вероятностная природа применения разных аугментаций в пайплайне. Дополнительно — техника развилась настолько, что уже выгоднее обрабатывать картинки батчом, а не по одной. Уже больше нравится бенч от Kornia, но они, таким образом, просто пытаются показаться свою главную фишку — аугментации батчей прямо на GPU. Короче, очень хочется собрать ultimate бенчмарк для аугментаций и посмотреть, кто из списка torchvision/albumentations/kornia/augmentor/solt/dali лучше, может быть вы что-нибудь подкинете из идей?

Про бенчмарки загрузки png картинок. Ужасно сгорел, перебирая разные способы загрузки png картинок. Настолько, что сел искать разные замены PIL. Так я наткнулся на бенч из поста выше и решил немного допилить его под png. Сводные результаты для картинок размером около imagenet (300х300) и огромных (10к х 10к) прикрепил. Ссылку на код закину в комменты. Из интересного: — Torchvision стабильно аутперформит всех и вся (почти) для jpeg и png. Кажется, что вместе с аугментациями из torchvision.transforms вообще имба; — Pyspng (обертка над libpng) — тоже хорош для png, но ограничен в плане API, только чтение/запись и все; — Pyvips расстроил совсем; насколько сильно я наслаждался удобством и скоростью работы imgproxy (под капотом libvips), настолько же сильно я расстроился от скорости работы pyvips :(

Поучаствовал в прошлом месяце в UBC-Ocean сореве вместе с Димой. Больше ради того, чтобы вспомнить (а где-то и узнать), что там такого в компьютерном зрении происходит. Суть соревнования простая — есть снимки проб человеческих тканей, надо распознавать тип рака. Но, конечно, есть несколько нюансов: — Есть два типа картинок: WSI (whole slide images) и TMA (tissue microarrays). TMA — это 40-кратный зум среза, при этом картинки “небольшого” размера — 4к на 4к. WSI же без зума, но и размер дичайший — в среднем 40к на 40к пикселей, самая большая — 50к на 105к, 4.7 Гб в uncompressed png. Довольно часто 50% картинки просто фон, надо было еще поискать, где на картинке клетки; — Жуткий перекос распределения типа картинок в трейне (95% WSI и 5% TMA). При этом в тесте 50/50 соответственно. Несколько мыслей по этому поводу: — Не используйте PNG для хранения картинок в проде. Никогда. Это зло во плоти. Дорого, тяжело по памяти, не оптимизировано под современные реалии. Хотите сжатие без потерь — возьмите лучше tiff вместо PNG. Да, возможно, больше будет диска жрать, но скорость загрузки сильно приятнее; — Всегда задавайтесь вопросом, насколько быстро работает ваш код, пройдитесь по нему профилировщиком. Если что-то, по вашему мнению, работает медленно — выясняйте, почему. Пара полезных ссылок: — прекрасный рассказ от бывшего коллеги про transforms второй версии в torchvision. Пользуйтесь активнее, они вышли в стейбл, быстрее, чем первая версия, и, по моему субъективному мнению, быстрее, чем albumentations; — хороший бенчмарк по загрузке больших картинок, разобраны jpeg и tiff, я дописал этот бенч для png формата.

Я потихоньку копаю историю про затачивание LLM-ок под свои задачи, желательно с инференсом на ноутбуке/смартфоне. Очень зацепила история про то, как дообучать большие модели меньшими ресурсами. Собственно, про LoRa и QLoRa сейчас из каждого утюга, я вам принес разбор первой. LoRA (Low-Rank Adaptation of Large Language Models) — это один из способов дообучать любую большую модель меньшим ресурсом (впрочем, можно применять и для большой линейной регрессии). Активно используется в файнтюнинге LLM-ок и диффузионных моделей. К тому же это прекрасное обобщение самой идеи дообучения моделей, ведь, если сложить все шаги градиентного спуска в процессе, мы получим такого же размера матрицу, агрегирующую все изменения. Ссылка на статью Мой разбор

Этот год был тяжелым во всех смыслах. Но в то же время он был вдохновляющим и интересным. В отпуске в Шотландии у меня было время поразмышлять о том, каким будет следующий год. И вот к каким мыслям я пришёл: — мы все больше будем видеть применение больших моделек на персональных девайсах. Вычислительная фотография там уже давно, ждём звук и текст. Мне нравится движение вокруг ollama comfyui. Компании медленно начинают выпускать статьи про дешевый инференс моделей (Apple — про shared memory , китайцы про cpu+gpu инференс). В общем, я лично жду суммаризацию текста или локальный перевод в следующем релизе айоси; — рыночек видеокарт наконец-то разрешится, и Nvidia начнет делать свое облако. Что-нибудь на уровне цен vast.ai, но sla получше. Кто, как не Nvidia, знает, как правильно настраивать сеть/вычисления? — все больше крупных компаний будет стараться вкладываться в опенсорс. При этом мы чаще будем видеть мелкие модели, заточенные под определенные задачки (вроде поиска по налоговому кодексу РФ). Кстати, из ближайших примеров Ferret — свежий дроп от Apple, мультимодальная ллмка, по сути другая опенсорсная моделька (Vicuna), немного дообученная; — также мы увидим много новых продуктов, выстроенных вокруг опенсорса. В целом это новый старый тренд, строить продукт вокруг открытого кода. Посмотрим, что из этого получится, мы уже проходили Nginx, Aerospike, Databricks, Hortonworks; — больше продуктов, использующих большие модельки, перейдёт из стадии ресерча в продакшн. Жду генерацию дашбордов в Tableau по одному сообщению продакта в телеге или автоматический Speech to Text в Goodnotes; — уже к маю рассчитываю на несколько исков по новоиспеченному EU AI Act. Возможно, даже попробуют подушить TikTok на раскрытие работы их рекомендательной системы, под предлогом влияния на человеческое поведение; — больше всего я радуюсь тренду на MLOps тулзы, надеюсь, он продолжится. MLOps сейчас будто те самые лопаты во времена золотой лихорадки. Хотите MLOps платформу как расширение к Postgres — держите PostgresML. Может вам хочется удобный мониторинг для своих фичей/моделек — держите Evidently. Мы в sanas.ai сделали свой cli для запуска распределенного обучения/сервинга моделей, но даже под такое есть стартап — dstack. В общем, я безумно рад такому усиленному вниманию к вопросам продуктивности и психологического здоровья ML инженеров. Для меня следующий год — год новых открытий и безумного внимания к области, которой я посвятил уже много лет, чему я очень рад. Надеюсь, что вы ждете 2024 так же, как и я.

Коротко про навыки ML инженера Я считаю, что каждый ML инженер, кроме своей области ML, должен разбираться еще в двух вещах: - алгоритмах; - инфраструктуре, которую он использует. В целом это верно в том числе и для дата инженеров. Понимание алгоритмов дает вам интуицию при оценке скорости работы вашего кода (а еще иногда идеи для ускорения). Однажды я увидел в продакшене код составления драфта рекомендаций, который при добавлении нового объекта, проверял вхождение категории этого объекта в список уже добавленных категорий. Список. Не хэшмапа, не множество, список. Теперь я считаю, что обязательно собеседовать человека на алгоритмы. Даже если ты лид — будь добр, тебе еще потом код ревью делать. Инфраструктура обычно скользкий вопрос. Авг ответ: а зачем я должен разбираться в этом, есть же специально обученные люди? Ну в целом и ответ тоже базированный: может быть тогда проще научить девопса запускать фитпредикт? Заодно сэкономим на ФОТ. Если вы понимаете, как работает инфра — вы можете быть более продуктивны. В целом считаю, что написать Gitlab CI пайплайн — это не так сложно. Уметь писать докерфайлы — базовый навык инженера уже. В общем, теперь всегда на собесах спрашиваю что-то наподобие: - в чем разница между cmd и run в dockerfile? run описывает как надо собирать образ, а cmd — что нужно по дефолту запускать при старте контейнера; - в чем разница между докер образом и докер контейнером? Образ — описание, как нужно будет запускать исполняемую «виртуальную» среду, а контейнер — сама исполняемая среда. Если хочется детальнее поизучать про Docker и Kubernetes, рекомендую почитать «Kubernetes в действии» Марко Лукша. Книга не первой свежести (2018 год), но все еще актуальная, хорошо описывает базу.