Мы наконец опубликовали наш набор высококачественных пре-тренированных моделей для распознавания речи (т.е. сравнимых по качеству с премиум-моделями Google) для следующих языков:

• Английский;
• Немецкий;
• Испанский;

Вы можете найти наши модели в нашем репозитории вместе с примерами и метриками качества и скорости. Мы также постарались сделать начало работы с нашими моделями как можно более простым выложили примеры на Collab и чекпойнты для PyTorch, ONNX и TensorFlow. Модели также можно загружать через TorchHub.

	PyTorch	ONNX	TensorFlow	Качество	Colab
Английский (en_v1)				ссылка
Немецкий (de_v1)				ссылка
Испанский (es_v1)				ссылка

Почему это Важно

Распознавание речи традиционно имело высокие барьеры на вход по ряду причин:

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

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

• Исследования в этой сфере обычно делаются на огромных вычислительных мощностях;
• Пре-тренированные модели и готовые рецепты обычно имеют сильные проблемы с генерализацией, их тяжело использовать "как есть", много зависимостей от устаревших технологий;
• До недавнего времени сообщество не имело доступа к простым в использовании, но качественным пре-тренированным моделям для распознавания речи;

Для начала мы попробовали решить какие-то из этих проблем, опубликовав самый большой в мире речевой корпус для русского языка (смотрите наш пост на Хабре тут). В этот раз мы делаем свой вклад в решение этих проблем следующим образом:

• Мы публикуем набор высококачественных пре-тренированных моделей для популярных языков;
• Наши модели быстрые и могут работать на обычном железе;
• Наши модели легко использовать;
• Наши модели пре-тренированы на огромных и разнообразных речевых корпусах;
• Мы строили наши модели так, чтобы они были устойчивы к разным доменам, насколько это возможно;

Сделать Просто Сложно

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

• Скорость и компактность;
• Генерализация между разными доменами. Должно существовать одно общее решение, которое незначительными усилиями настраивается на конкретные домены, а не наоборот;
• Максимальная простота в использовании ("1 строка кода");

Дальнейшие Планы

Сейчас наименьший размер, до которого мы смогли ужать наши модели в районе 50 мегабайт.
В среднесрочной перспективе планка сжатия до 10-20 мегабайт без потери качества кажется нам выполнимой.
Также мы планируем добавлять другие популярные языки.

Ссылки

• Наши модели на Github
• Вики
• Метрики скорости
• Метрики качества
• Примеры на Colab

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

Для решения задачи детекции голоса (Voice Activity Detector, VAD) существует довольно популярный инструмент от Google webRTC VAD. Он нетребовательный по ресурсам и компактный, но его основной минус состоит в неустойчивости к шуму, большом числе ложноположительных срабатываний и невозможности тонкой настройки. Понятно, что если переформулировать задачу не в детекцию голоса, а в детекцию тишины (тишина это отсутствие и голоса и шума), то она решается весьма тривиальными способами (порогом по энергии, например), но с теми же минусами и ограничениями. Что самое неприятное зачастую такие решения являются хрупкими и какие-то хардкодные пороги не переносятся на другие домены.

Изначально мы хотели сделать простой и быстрый внутренний инструмент для себя и наших партнеров для детекции произнесенных чисел без привлечения полноценного STT (фишка изначально была именно в портативности засчет использования современных фреймворков типа PyTorch и ONNX), но в итоге оказалось, что можно сделать не только детектор чисел, но и качественный, быстрый и портативный VAD и классификатор языков, который и опубликовали бесплатно для всех желающих тут под лицензией MIT. За подробностями прошу под кат.

Основные фишки нашего решения

Что же умеет делать наш "VAD"?

• Именно сам VAD находит в аудио участки, где люди говорят;
• Number detector находит в аудио участки, где люди произносят цифры;
• Language classifier классифицирует языки;
• Это все сейчас работает на 4 языках (Русский, Английский, Немецкий, Испанский), но с высокой степенью вероятности именно сам VAD будет работать и на других родственных им языках (небольшой квест для Хабра если вы говорите на каком-то экзотическом языке, запишите свой голос, прогоните VAD и поделитесь результатом!);

Основные "фишки" на данный момент:

• Поддержка 4 языков;
• Именно VAD сильно выигрывает у WebRTC по качеству;
• Натренирован на огромных речевых и шумовых корпусах;
• Ест мало ресурсов и памяти, работает на 1 потоке процессора;
• Его скорости достаточно для edge и мобильных применений;
• Построен на базе современных и портативных технологий (PyTorch, ONNX);
• В отличие от WebRTC скорее является детектором голоса, а не детектором тишины;
• Мы выложили чекпойнты как для PyTorch (JIT), так и для ONNX;

Возможные применения

• Детекция конца фразы;
• Подготовка и очистка голосовых корпусов;
• Часть пайплайна для анонимизации речевых корпусов (по-хорошему еще надо уметь искать имена, но это совсем другая проблема, и она довольно специфична для решаемой задачи и требует наличия и тонкой настройки STT);
• Детекция наличия голоса для применения на мобильных и edge устройствах;
• Компактность и наличие ONNX позволяет запускать его с большим количеством доступных бекендов;
• VAD кушает данные с частотой дискретизации 16 kHz, но он научен не бояться и данных с 8 kHz;

Примеры

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

• Все примеры есть как для PyTorch так и для ONNX;
• Для самого важного алгоритма VAD мы привели примеры как для работы с целыми отдельными файлами, так и для однопоточного / многопоточного стриминга;
• Для остальных приведены только примеры по работе с отдельными файлами. Но имея VAD уже несложно длинные файлы разделить на короткие;
• Примеры специально приводятся в виде простейшего тулкита, который легко будет адаптировать на свой язык с минимальными усилиями (обработка целых файлов тривиальна, стриминг в 1 поток несложный, несколько потоков немного сложноват из-за механизма окон);

Самый просто пример, где мы натравливаем VAD на файл:

import torchtorch.set_num_threads(1)model, utils = torch.hub.load(repo_or_dir='snakers4/silero-vad',                              model='silero_vad',                              force_reload=True)(get_speech_ts, _, read_audio, _, _, _) = utilsfiles_dir = torch.hub.get_dir() + '/snakers4_silero-vad_master/files'wav = read_audio(f'{files_dir}/en.wav')speech_timestamps = get_speech_ts(wav, model,                                  num_steps=4)print(speech_timestamps)

Как работает VAD

Тут кратко опишем, как данные кормятся в VAD. Для остальных алгоритмов заинтересовавшиеся просто найдут информацию в коде.

• Аудио разделяется на кусочки длиной например 250 мс. Можно конечно порезать и короче, но по нашему опыту все паузы менее 100 мс являются малозначимыми и получается очень много шума, если пытаться поделить по 30-50мс. По просьбам интересующихся мы также привели график зависимости качества от длины кусочка тут (мы сравнили 100 мс и 250 мс);
• VAD держит в памяти прошлый кусочек (или нули в начале стрима);
• Эти кусочки по 500 мс (или по 200 мс) делятся на 4 или 8 окон внахлест и модель применяется к каждому такому окну;
• Вероятности выдаваемые моделью усредняются по всем таким окнам;
• Дальше эта вероятность используется, чтобы или "войти" в речь или из нее "выйти". Базовые оптимальные гипер-параметры приведены в коде примеров;

Скорость и задержка

Все замеры скорости мы делали на 1 потоке процессора AMD Ryzen Threadripper 3960X. Для этого мы использовали такие настройки:

torch.set_num_threads(1) # pytorchort_session.intra_op_num_threads = 1 # onnxort_session.inter_op_num_threads = 1 # onnx

Подробнее вы можете просто посмотреть в коде, но задежка зависит от следующих параметров:

• num_steps число таких окон "внахлест";
• number of audio streams число одновременно обрабатываемых потоков аудио;
• По сути получается, что модель всегда видит батч длины равной num_steps * number of audio streams;

Получаются такие задержки:

Попробуем теперь измерить пропускную способность в секундах аудио, обрабатываемых за одну секунду на 1 потоке процессора:

Качество

По логике процесса, описанного выше, мы измеряли качество нашего VAD по сути просто присваивая некую усредненную вероятность каждому кусочку аудио и сравнивая ее с истинными метками. Но как добавить к сравнению WebRTС, он же выдает просто 0 или 1?

WebRTC принимает на вход фреймы аудио и отдает 0 или 1. По-умолчанию используется длина фрейма в 30 мс, то есть каждый кусочек аудио в 250 мс мы делится примерно на 8 таких фреймов. Это неидеально, но мы просто интерпретируем среднее из таких 0 и 1 как вероятность.

В итоге получается вот такой результат:

Тонкая настройка и остальные алгоритмы

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

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

Прошло некоторое время и пора обновить наше исследование, сделав его по-настоящему ультимативным. По сравнению с прошлыми исследованиями изменилось или добавилось следующее:

• Добавилось много валидационных сетов из разных реальных доменов;
• На рынок вышел Сбер, в первую очередь интересно протестировать именно его;
• Для чистоты эксперимента, мы не предупреждали разработчиков систем о доменах и факте проведения тестов;
• Мы также попробовали немного протестировать пропускную способность сервисов (понятно, что мы не знаем какое железо и ограничения стоят в облаке);
• Мы рассматриваем только коммерческие системы, к которым у нас получилось получить доступ и которые показали хоть какой-то намек на "всеядность", работу с холодного старта и "энтерпрайзность";

Методология

Мы старались следовать нашей стандартной методологии (см. ссылки выше) с небольшими изменениями:

• Тестируем одни и те же данные в формате wav (или просто PCM);
• Мы слали запросы во все системы в 8 параллельных потоков (если было очень много таймаутов или все было медленно, то снижали);
• Расчет скорости делался отдельным небольшим прогоном без всяческой пред- или пост-обработки, чтобы не "загрязнять" метрики, допустим, нормализацией или ресемплингом;
• Считаем основную метрику WER. Не пугайтесь высоких показателей в районе 20% WER, нужно понимать что в самой разметке заложено порядка 5% WER и что иногда система получает штраф за неверную форму слова (но корень сохраняется, подробнее писал по ссылке в начале статьи);
• По причине большого количества доменов в этот раз на каждый домен случайно выбрали по 1 часу аудио. Стабильные результаты как правило получаются с 2-3 часов аудио (поэтому некоторые метрики могут визуально быть "хуже" прошлых тестов). За тесты в Гугле нам пришлось заплатить почти 500 долларов!;
• Метрики считаются на нормализованных текстах (то есть без цифр, "как слышится так и пишется"), так как системы нормализации могут быть разными и строго говоря к качеству распознавания имеют непрямое отношение и зачастую делаются под домен;
• Если у системы нет такого функционала, то мы нормализуем тексты самостоятельно. В любом случае это влияет в рамках 1 п.п. WER, мы проверяли;
• Сначала мы пробовали слать ogg/opus в системы, которые его поддерживают, но потом отказались от такой идеи, потом что резко вырос процент "пустых" ответов;
• Все данные по умолчанию отправляются с родной частотой дискретизации (8 или 16 kHz), но мы не записывали исходную частоту дискретизации всех оригинальных аудио до обработки;

Сухие метрики

Все модели, кроме Silero bleeding egde, это модели упакованные в production сервисы.

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

Качественный анализ и интерпретация метрик

Неудивительно, что каждый силен в том домене, на котором фокусируется. Tinkoff на звонках в банк, справочную, финансовые сервисы. Сбер имеет ультимативно лучшие результаты на своей "умной колонке" (спекулирую, что они поделились в лучшем случае 1/10 своих данных) и в среднем неплохие показатели. IVR модель Сбера на доменах, где оригинальные данные лежат у нас в 8 kHz, показывает себя достойно, но она не ультимативно лучшая. Приятно удивил Яндекс в прошлых рейтингах их модели были не в списке лидеров, а сейчас точно лучше, чем в среднем по больнице. Другой сюрприз Google, который является аутсайдером данного исследования вместе с Ашмановым.

Также интересно посчитать количество доменов, где production модели поставщика лучшие / худшие (допустим с неким "послаблением" в 10% от лучшего или худшего результата):

Как и ожидалось наша модель показывает в среднем неплохие показатели на всех доменах, заметно отставая на банках и финансах. Также если смотреть по формальной метрике "на каком числе доменов модель лучшая или почти лучшая" то наша модель как минимум лучше всех генерализуется. Если включить в забег нашу bleeding edge модель (мы пока не выкатили ее еще), то она отстает только на "умной колонке" и банковских датасетах, лидируя уже на 17 доменах из 21. Это логично, так как у нас нет своей колонки и банки очень неохотно делятся своими данными даже приватно.

Удобство использования

У Сбера на момент тестирования было только gRPC API. Это не самое удачное решение для SMB клиентов с точки зрения удобства, имеющее более высокий порог на вход. Также в их реализации вообще не прокидываются важные ошибки (или отсутствуют в принципе, чем часто грешат корпоративные сервисы). Документация запрятана внутри портала их экосистемы, но в целом кроме лишней "сложности" проблем особо там нет, читать приятно. 40 страниц на два метода это конечно сильно (мы читали сначала в PDF), но документация хотя бы подробная и с примерами и пояснениями.

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

У Tinkoff само распознавание работает по умолчанию также через gRPC, а поверх написаны клиенты (в тех, которые мы разбирали было много лишнего). С учетом фокуса на enterprise (оставим за скобками этические, правовые и финансовые последствия монетизации банком ваших данных без явного согласия и возможности отказаться) это имеет больше смысла, чем то, что сделал Сбер. Это уже мои спекуляции, но скорее всего это в первую очередь артефакт разработки решения под свои нужды.

У сервиса Ашманова вообще нет документации, примеры не работают из коробки, пришлось немного позаниматься перебором для запуска. Отдельно отмечу, что обычно b2b сервисы не славятся читаемыми ошибками и читаемой документацией, но тут вообще не было ни ошибок, ни документации. Или 500-я ошибка или 200 с пустым ответом. Это создает легкий когнитивный диссонанс с учетом проработки анимации девушки-маскота, количества маркетинговых материалов и "успешных" кейсов.

У нашего сервиса само публичное АПИ весьма минималистичное и состоит из 2 методов (синтеза и gRPC нет еще в публичной документации) с примерами. Есть также gRPC АПИ, которое сейчас проходит обкатку. Наверное я тут не лучший судья, но основная ценность как мне кажется состоит в радикальной простоте для публичного АПИ и детальных инструкциях / сайзингах / опциях конфигурирования для более крупных клиентов.

Пропускная способность

Все АПИ, которые мы протестировали (кроме Ашманова) показали себя довольно бодро по скорости (это баг или фича решать вам). Для измерения пропускной способности мы считаем показатель секунд аудио в секунду на 1 поток распознавания (RTS = 1 / RTF):

Поскольку никто не публикует сайзинги облачных и даже иногда коробочных (тут поправьте меня, если пропустил) версий своих систем публично (кстати прошлая версия нашего сайзинга например доступна по ссылке), то довольно сложно оценить адекватность работы систем по ресурсам. Ведь за АПИ может скрываться как одна VDS, так и сотни карт Nvidia Tesla, которыми любят хвастаться корпорации в своих пресс-релизах (что кстати частично подтверждается результатами Сбера пропускная способность там не падает от роста нагрузки совсем). Расчеты выше не являются заменой полноценным сайзингам.

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

Вообще меня очень приятно удивили результаты Сбера. На текущих версиях моделей у нас например сайзинг на 12 ядерном процессоре + GPU рассчитан на ~150 RTS. По идее это означает, что если мы поднимем тестовый и сервис на 12+ ядрах процессора на чуть более новой карточке, мы должны получить результаты более близкие к Сберу. У нас все равно не получается получить такие же высокие показатели без просадки от нагрузки, но какие-то выводы уже можно строить и получается все равно весьма достойно. Снимаем шляпу перед инженерами Сбера и ставим aspirational цель сделать наш сервис еще в 2-3 раза быстрее.

На цене мы останавливаться особо не будем (большая часть серьезных клиентов все равно не использует облако), но в очередной раз неприятный сюрприз преподнес Гугл выставив круглый счет за смешной (как нам кажется) объем. А ответ прост зачастую облачные корпоративные сервисы распознавания имеют не только крутой ценник (и в случае Гугла еще и в долларах), но и неочевидные системы округления вверх. В начале своего пути мы тестировали какой-то сервис из Великобритании который округлял до 60 секунд!

Небольшая ложка дегтя

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

Нам приходилось слышать абсолютно разные оценки скорости (ну или наоборот оценки потребности в железе) систем распознавания речи, отличающиеся даже на порядок. Особенно радует, когда указаны системные требования из которых следует, что метрики сильно лучше, чем лучшие state-of-the-art системы из bleeding edge статей, а на практике иногда оказывается, что метрики рассчитаны в надежде, что "покупают для галочки и никто пользоваться не будет и так сойдет". Также не помогает то, что некоторые системы работают на GPU, а некоторые нет, равно как и то, что ядра процессоров могут отличаться в разы по производительности (например старые серверные процессора с тактовой частотой 2 2.5 GHz против современных решений от AMD с 4+ GHz на ядро имеющие до 64 ядер). Давайте в этом вместе разберемся, на самом деле, все не так уж и сложно!

Как правило люди начинают задумываться о скорости в 3 случаях:

• Когда ее не хватает или когда она является узким горлышком;
• Когда со скоростью нет проблем, но есть проблемы с ценой железа;
• Когда есть жесткое SLA по качеству сервиса от конечного заказчика;
• Когда есть жесткие требования по скорости "первого ответа" от конечного заказчика;

В этой статье мы постараемся ответить на несколько вопросов:

• Что вообще значит скорость?
• Какой скорости можно добиться в теории?
• Какой скорости можно добиться на практике и желательно без потери качества?

Определения

Но давайте для начала определимся с понятиями. Такой пример скорее является исключением в западном STT комьюнити, но лаборатория Facebook AI Research в последнее время активно наращивает свои позиции в распознавании речи и зачастую публикует интересные исследования, а в частности в качестве отправной точки по скорости интересна относительно недавняя статья, где они публикуют кроме всего прочего оценки скорости работы своих систем распознавания речи. Но как вы понимаете, обычно в таких статьях очень мало пишут про скорость и все всегда в духе "как все классно".

В частности, в статье приводятся 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 сугубо теоретическими, или туда уже включены потери на оборачивание алгоритмов в продакшен сервис;

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

Практические Сайзинги

Мы потратили довольно много времени на оптимизацию гипер-параметров для продакшена и пришли к следующим цифрам.

Пара слов о методологии:

• Метрики рассчитаны для файлов длиной 1 7 секунд, которые "кормятся" в сервис в 4 8 16 потоков;
• Распределение длин файлов соответствует распределению длин файлов в реальных диалогах людей по телефону;
• Метрики рассчитаны для многопоточного веб-сервиса, что немного абстрагируется от сценария реального использования. Ну то есть если мы можем держать условно 8 потоков с условной гарантией в latency в 500 мс, то это значит, что правильно настроив конечную бизнес-логику, можно обрабатывать сильно больше, чем 8 одновременных звонков;
• Реальные люди не говорят одновременно, пока человек заканчивает вторую фразу мы уже успеваем обработать первую итд итп. Поэтому на реальном проекте можно опять же держать еще более высокую нагрузку. Но это уже сильно зависит от реального бизнес-кейса;

Сайзинги для GPU

Есть 3 типа подходящих GPU:

• Любые игровые GPU Nvidia выше чем 1070 8+GB RAM с турбиной;
• Любые однослотовые GPU Nvidia серии Quadro 8+GB RAM (TDP 100 150W) с турбиной или пассивные;
• Nvidia Tesla T4, пассивная, TDP 75W;

Мы часто сталкиваемся с тем, что заказчики не понимают и иррационально боятся использовать GPU в продакшене мотивируя это все разного рода отговорками (типичное "отдел закупок не одобрит"). Приведем топ мнений, которые мы слышали:

• "Карты слишком мощные (300 ватт) и горячие". Это не так. У игровых и карт для исследований TDP реально такой. Но TDP решений для продакшена в пике от 75 до 150 ватт, а на практике с нашими сетями будет где-то 50-75% от пиковых значений;
• "Карты очень греют сервер и серверную". Это конечно зависит от их количества, но с нашими сайзингами даже на крупные проекты хватит 2 карт (+ резерв);
• "Карты нарушают идеально продуманную циркуляцию воздуха в серверной". В идеальном мире вообще для серверных "предназначены" только пассивные карты Tesla согласно SLA от Nvidia. Но понятно почему монополист в SLA указывает это, т.к. карты Tesla в 2-3 раза дороже. Но если вам так надо "гарантий" просто купите пассивные карты и оптимизируйте воздушные потоки сколько угодно;
• "Карты занимают только 2+ слота и не влазят в серверные шасси". Это не так. Карты Quadro и T4 занимают 1 слот;
• "Карты слишком дорогие". Топовые карты Tesla A100 действительно стоят US$12,500 в России. Но карты Quadro и T4 (я уже молчу про игровые) в рамках крупных проектов стоят уже вообще копейки;
• "Карты недолговечные и ломаются". Как и любой "силикон" если карта не бракованная она будет служить 3-4 года, плюс никто не отменял гарантию. Если не хочется иметь точку отказа в виде охлаждения всегда есть пассивные карты. Тут отмечу, что карты Nvidia с пробегом купленные с Авито прекрасно служат несколько лет в режиме 24/7 и сказки про "майнеров" это просто сказки, майнеры очень бережно относятся к технике. Знакомый майнер давно купил 100 карт Nvidia и AMD и за 3 года из строя не вышла ни одна зеленая карта;

Одна из целей данной статьи развеять эти заблуждения. Забегая вперед деплой на GPU примерно в 2-3 раза дешевле.

Сайзинги для CPU

Комментарии по Cайзингам

• В реальности со всем фаршем даже у сервиса с GPU получается только 10 15 RTS на одно ядро процессора (хотя теоретический RTS самой модели на GPU находится где-то в районе 500 1,000). В теории число воркеров CPU на 1 GPU можно наращивать больше (тем самым наращивая нагрузку на карту и пропускную способность), чем мы пробовали, но мы упираемся в удорожание процессоров. В какой-то момент горизонтальное резервирование становится важнее;
• CPU-версия сервиса показывает только в районе 5 честных RTS, что немало, но она скорее оптимизирована как баланс между гарантиями по latency и throughput;
• Метрики настоящие и честные и подбор параметров стоил много боли и страданий. Если честно я вообще не видел, чтобы кто-то вообще показывал перцентили реальных систем;
• Многие крупные проекты просят 50 одновременных разговоров, поэтому иметь возможность покрыть такой проект используя всего 2 GPU (+ резервирование) это довольно круто;
• Использование GPU сервиса где-то в 2-3 раза дешевле, чем если считать все только на CPU;

Выводы

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

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

А что дальше? У нас большие планы на релиз некоторых комплиментарных распознаванию голоса технологий под довольно свободной лицензией MIT.