Совершенно неожиданным образом с долгим перерывом без постов количество подписчиков выросло до 700 🐈‍⬛!
Будем надеятся, что не боты, хотя зачем им это.

Но раз такое дело, я принес сюда очень полезную штуку которую нашел только-что.


🔉Spotify Pedalboard 🎸

Все еще пользуетесь SciPy и Numpy для обработки аудио? Есть решение по-лучше.
Spotify pedalboard это что-то вроде Adobe Audition, только из питона. Эта штука умеет применять к звуку кучу готовых плагинов вроде реверберации, эха, дисторшена, и много что еще. Быстро удобно и из коробки! Я попробовал, очень понравилось, на много лучше того, что я видел раньше.
(Кстати есть не такие стандартные вещи, например сжимание в mp3 и разжимание обратно, чтобы получить испорченный звук)

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

А еще: Reads audio files up to 4x faster than librosa.load (in many cases)

https://github.com/spotify/pedalboard

🧑‍💻 Тестики 🪤️️️️️️

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

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

Последний год я только и занимаюсь тем, что ускоряю инференс моделей, часто приходится делать это полносьтю переписывая бекенд на какие-то более оптимальные вещи, делать инференс моделей на плюсах и cuda и многое другое.

НО! Всегда есть проблема соблюдения консистентности, вам жизненно необходимо делать так, чтобы модель на новом супер быстром бекенде выдавала тот же ответ, что и на обычном pytorch. И во время разработки это почти всегда не так, а учитывая размеры моделей и колличество слоев, найти место с ошибкой бывает не просто, приходится глубоко дебажить, чтобы найти злосчастную операцию, которая портит всю малину.

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

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

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

Расскажите про ваш опыт использования тестов

💻 Про мою работу💻

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

С первых статей на хабре мне очень понравился этот ваш машин лернинг, и я захотел им заниматься.
Сначала это было в рамках небольших соревнований, попыток крутить sklearn и xgboost, потом был keras, немного tensorflow, pytorch и все с ними.
Моя первая и последующие работы были связаны с исследованиями, но настоящие исследования (как их делают писатели пейперов), я делать не умел. Я примерно понимал принцип: генерируем идею, имплементируем, проводим точный эксперимент, сравниваем метрики, делаем выводы.

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

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

Но нашлось гениальное решение! Я начал делать то, что не умеют делать другие - оптимизировать инференс моделей. А ведь логично! У всех кто делает ML - есть модели (они же их и разрабатывают), и их нужно как-то гонять, чтобы получать за это деньги. А ML разработчики, часто не знают ничего дальше фреймворка с которым они работают, бекендеры же со своей стороны в душе не чают зачем нам столько разных видов перемножения матриц. И тут появляюсь я, который одинаково плохой ресерчер и плюсовик, но благодяря этому смешению что-то да рабочее завести смогу, да еще и денег с временем сэкономлю!

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

Самый главный и полезный навык который я нашел в себе, и который полезен в этой работе, не бояться залезть в самые глубины. Нет нужной имплементации attention layer'a для вашей диффузии? Не беда! Напишем на куде, основываясь на парочке примеров из интернета.
Не работает конвертер onnx->tensorrt? Да он нам и не нужен! Напишем сетку c нуля на network api!
Есть имплементация LLM на плюсах, но нет стриминга? Не беда, пошурудим с тредингами и мьютексами, и что-то да соберем.

В общем не бояться сложностей -- это самое главное.

Такие дела

📖 Читаем статьи правильно 📖

Пару недель назад ко мне пришел Денис @mixedenn с просьбой рассказать об их продукте. Рекламу я не даю, но о хороших вещах рассказваю, если они мне самому показались интересными. Я потратил какое-то время чтобы попользоваться их продуктом, отловил пару багов, отрепортил и теперь на правах абсолютно бесплатной и бескорыстной интеграции расскажу и вам.

Денис вместе со своей девушкой запустили synthical.com - по сути это то, как они видят идеальную читалку для статей. Это и удобный поиск, тренды, поиск похожих статей (с помощью хороших эмбеддингов), а так же встроенная LLM которая поможет вам объяснить определенные части статьи, которые вы не поняли.

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

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

В общем желаю успехов этому проекту!

💸 За что мне платят деньги (Часть 2) 💳

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

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

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

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

Важна и вторая метрика TTFB - time to firs byte, по сути как быстро пользователь начнет получать ответ, сколько он должен ждать, чтобы получить первый чанк. В целом и обычный прогон сети можно назвать стримингом, просто чанк большой и ждать его долго, а хочется поменьше и побыстрее, желательно меньше секунды, а вообще хорошо за 300 мс.

Настраиваю систему, запускаю тесты и вижу - 4 секунды... 🚬
Ну это вообще никуда не годится, стриминг с ожиданием в 4 секунды это какой-то прикол.

Начал копать в чем дело. Копал я на самом деле долго, но вам разложу сразу все карты на стол.

Первое что я нашел -- warmup. Для декодера оказался кретически важен прогрев. То есть если вы прогоните какой-то тензор через декодер в первый раз у вас это займет 2.1s а в третий уже 700ms. Причем зависеть это будет от размера вашего тензора, для нового размера warmup придется делать еще раз, чтобы замер был честным. Честно говоря я не до конца понимаю с чем связан этот процесс, предполагаю что это либо подрузка либо компиляция специфичных размеров кернелов под ваши входные данные, но да, модельку надо прогревать, прямо как Ладу в зимнее утро.

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

Урок уяснили, прогрели модель перед тем как делать тест, смотрим снова на метрики а там... 1.4s

Опять первый чанк уходит медленно, а все остальные улетают за 700ms, в чем беда?
С этим багом я копался дольше всего ставя различные эксперименты. В итоге причина нашлась.

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

Странным образом разделение моделей на разные CUDA Stream проблему не решили, это я еще выясняю с чем связано. Зато проблему решил магический sleep, а именно, когда генератор понимает, что у него готов первый чанк, он из благородных побуждений к декодеру решает немного вздремнуть и уступить ресурсы GPU декодеру, спит он не долго всего 500 ms, но этого хватает чтобы сбалансировать систему.

Как итог - TTFB = 700ms 💪

Уменьшил lantency добавив sleep, вот за это мне и платят деньги

😴 Я ЛЕНТЯЙ 😴

Ну реально, я буквально на следующий день после этого поста нашел решение гораздо лучше чем просто вставить sleep, которое изначально являлось костылем. Потому что стоит вам сменить систему или GPU где задержка того или иного треда поменяется, как ваши sleep'ы летят в тар-тара-ры, так случилось и со мной на следующий день, когда я протестировал это решение не на A100, а на A10.
Пришлось все таки искать правильный подход.

И после некоторых поисков я таки откопал вот такую презентацию. Где буквально говорится, что не важно как много у вас стримов, в CUDA есть четкая установка: НИЧТО И НИКОГДА не может перекрывать Stream 0, то есть стандартный стрим. А это значит, что если у вас есть два потока, один идет на stream 0, а второй на custom stream, то они никогда не будут идти параллельно, такая уж условность заложена. То есть cuda 0 выступает как своеобразный GIL, который не даст вам сделать настоящий параллелизм.

Решение? Запускать обе модели в разных стримах, но чтобы ни один из них не был нулевым. И после этого все стало чики-пуки. То есть буквально как написано в презентации: CUDA operations must be in different, non-0, streams

А почему я лентяй? Да потому что не смотря, что я это нашел буквально на следующий день, писать пост мне было лень почти месяц.
Я там еще пару занятных штук откопал, кто знает, может нас ждет новогодний пост!

😎 Github by touch id 😎️️️️️️

Я давно слышал про такую штуку, но сейчас впервые попробовал. Вход через "pass keys", вот как гитхаб описывает, что это такое Passkeys are a password replacement that validates your identity using touch, facial recognition, a device password, or a PIN..

В общем секьюрити настройках Github можно добавить этот passkey и тогда на сайт можно будет заходить только прислонив палец.

💫 Магия 🪄