Asterisk dialplan — extensions.conf

Определения

В частности, в статье приводятся 3 основные метрики, которыми обычно оценивается «скорость»:

• Throughput (пропускная способность) — сколько потоков распознавания система может обрабатывать параллельно. Для простоты назовем это «потоками»;
• Real Time Factor (RTF) (на знаю как кратко перевести) — насколько каждый поток распознавания распознается быстрее, чем реальное время. Давайте также для простоты определим Real Time Speed (RTS) как 1 / RTF, то есть количество секунд аудио, которое можно обработать за 1 секунду;
• Latency (задержка) — какую реальную задержку чувствует конечный пользователь прежде чем ему начинают приходить какие-то ответы системы;

Еще прежде чем оценивать скорость от FAIR, нужно понимать ряд вещей:

Все тесты FAIR гоняют на процессоре Intel Skylake c 18 физическими ядрами (информации о тактовой частоте и наличии 2 потоков на ядро нет, но по числу ядер попробую предположить это какой-то мощный топовый процессор);
Это результаты end-to-end алгоритма реализованного на C++ с «встроенным» декодингом;
Скорее всего вероятно используются кастомные низкоуровневые реализации из wav2letter++;
Важно понимать, что такие статьи это в первую очередь пиар и результаты тут пере-оптимизированы на маленькие чистые академические датасеты;

Интересные моменты:

• Общая «скорость» (RTS * число потоков) быстро выходит на плато. Также видно, что для получения гарантий по скорости работы системы нужно снижать размер чанка;
• FAIR потратили существенное время на оптимизацию своей нейросети, т.к. этой статьей они продолжают по сути целое направление своих исследований, где они пиарят так называемые TDS-слои;
• В этой статье их ноу-хау по сути является несколько технических оптимизаций по скорости и квантизация;
• С определенной натяжкой, можно сказать, что они сделали что-то близкое к state-of-the-art для быстрых и практичных сетей (конечно как обычно близко без гарантий, что вы сможете это повторить и что это пошло в реальный продакшен);
• В статье FAIR пишут, что их «оптимальные» характеристики это 40 потоков, 0.26 RTF и задержка в районе одной секунды (вообще на самом деле можно выбрать любые точки на графиках выше). Понятное дело, всегда можно перенастроить такую систему допустим на больше потоков ценой задержки, ну или допустим на меньшую задержку ценой общей пропускной способности;
• Быстро на коленке Пересчитаем 40 * 1 / 0.26 и разделим на 18 физических ядер процессора. Получаем, что за 1 секунду на 1 ядре серверного процессора они могут распознать где-то в районе 8-9 секунд аудио;

Выпишем теперь самое важное для сравнения:

• Чанки: равные чанки длиной в районе 750 мс (оптимальное значение);
• Пропускная способность: Оптимальные метрики 8-9 секунд аудио на ядро процессора, 40 потоков на 18 физических ядер процессора;
• Задержка: от 500 мс до 1000 мс, для заявленного оптимального чанка в 750 мс — скорее ближе к секунде;
• Низкоуровневая реализация на C++ со встроенным пост-процессингом;

Теоретические Лимиты

Наша лучшая система сейчас не является полностью end-to-end системой, как система от FAIR, потому что мы сначала поставили задачу достижения высоких показателей на реальных данных, а уже потом миниатюризации. Поэтому сначала мы озаботились оптимизацией акустической модели, потом всего сервиса в целом, и уже потом мы будем заниматься интеграцией всего end-2-end (желательно чтобы еще работало на мобильниках).

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

Это и проклятие и благословение одновременно. Очевидно, что батчами все процессится быстрее, но это очень сильно усложняет архитектуру и требования к прямоте рук при проектировании сервиса. Я даже слышал мнения, что с батчами «непонятно как» или «невозможно» сделать нормальный продакшен (на самом деле просто нужны прямые руки). Тем не менее после всех изысканий у нас получилось получить вот такие цифры (это количество секунд аудио обрабатываемых в секунду в расчете на одно ядро процессора):

Тут не надо ходить к бабке, чтобы понять, что миниатюризация и квантизация модели очень сильно докидывает. Докидывает настолько, что задержка перестает быть критичной даже для CPU модели. Этого к сожалению нельзя сказать про пропускную способность. В сравнении с FAIR или другими системами может показаться, что последние цифры нереалистичны, но тут надо понять ряд вещей:

• Это только одна часть пайплайна без пост-процессинга;
• Это не включает потери в реальной жизни на транспорт, сериализацию, коммуникацию, итд итп;
• Мы не знаем являются ли цифры FAIR сугубо теоретическими, или туда уже включены потери на оборачивание алгоритмов в продакшен сервис;

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

Выводы

Если статья от FAIR показывание реальные продакшен показатели, то у нас получилось используя только открытые и свободные библиотеки достичь 50% их показателей. Но скорее всего конечно цифры там — теоретические. Это конечно не 20-30 RTS как у акустической модели, но как правило после упаковки в дистрибутив где-то теряется 40-50% показателей. В таком случае мы показали ряд вещей:

• Продакшен на GPU быстрее, удобнее и дешевле;
• Мы как минимум приблизились к цифрам от FAIR;
• Мы наглядно показали, что деплой на GPU с батчами не только возможен, но и прекрасно работает;
• Если грамотно прикрутить бизнес-логику к такому распознаванию, то можно держать достаточную нагрузку даже для высоконагруженных реальных проектов;