💸 За что мне платят деньги (Часть 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 и тогда на сайт можно будет заходить только прислонив палец.

💫 Магия 🪄