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

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

С первых статей на хабре мне очень понравился этот ваш машин лернинг, и я захотел им заниматься.
Сначала это было в рамках небольших соревнований, попыток крутить 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 и тогда на сайт можно будет заходить только прислонив палец.

💫 Магия 🪄