В большинстве своем при поиске latency метрик мы находим общую latency =
написал текст/сказал текст и получил аудио обратно. Однако за этим стоит не только большая доля инженерии, но и модули модели. Метрики, которые мы здесь рассмотрим:
• FTL - first packet latency
• TPP - first packet decode
• DEC - mean packet decode
• FPL - first packet latency
• RTFx - audio_duration / processing time - общий throughput пайплайна
Чаще всего работаем с пайплайном:
текст -> LM based TTS - - - > audio codebook tokens - - - -> Codebook based Vocoder
FTL - это путь от текста к первому audio codebook token. Это может быть как и один токен, который генерит большая модель, так и sequence токенов, которые генерит какой-то depth transformer, а может быть вообще multi-token generation от главной модели. Так или иначе на выходе только дискретный токен / латентный вектор.
На эту метрику влияют кроме всех прочих приколюх модели и параметры интеренса. Например, сколько буковок вообще нужно ждать, чтобы начать генерить. Или сколько буковок передавать как lookahead, чтобы аудиотокены получались лучше.
TPP - это путь только вокодера. Получили аудио токены - получили первый audio patch. У этого пути может быть отдельный cuda stream.
Здесь также главную роль играют "accumulation" параметры. Например, сколько токенов нужно подсобрать чтобы сделать один pass вокодера?
——
Но также именно здесь есть важный дизайнхук, который всегда люди делают по-разному. Как декодировать последовательность, чтобы не было странных звуков между патчами😒 Многие это делают декодируя всю предыдущую последовательность. Кто-то собирает n прошлых секунд и отправляет именно их. Кто-то использует kv cache, что часто идентично. Каждый из них влияет на latency. Именно это design choices отражаются на
DEC метрики, так как один пасс через vocoder может потом линейно вырости и будет казаться, что вокодер вместо 50ms почему-то стал тратить 200ms, а все потому что мы передали ему весь предыдущий контекст.
——
Все метрики выше влияют на
FPL, как раз то, что большинство юзеров называют latency. Или вот эта задержка между тем как вы что-то сказали и бот ответил вам в ответ (здесь мы считали только TTS часть). Большинство компаний стремятся к тому, чтобы это значение latency было меньшее 100ms 😌 В борьбе за этим что только можно и нельзя использовать. При этом важно и смотреть на общий RTF, так как многие (в том числе и я) могут занижать FPL с помощью более маленького контекста, lookeahead'a и тд, а потом уже кормить модель нормальным контекстом🙂. Ну и конечно мы оставляем за большими скобками хитрые вещи по типу filler words или заготовленные фразы, чтобы не казалось что модель долго думает.
А с каким latency говорите вы? Я иногда с 300ms, а иногда с -100ms (ну знаете когда собеседник уже слишком тянет и ты все уже понял)