Сервер для распознавания речи в контакт-центре: Как рассчитать нагрузку

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

Если записи обрабатываются после звонка, инфраструктуру рассчитывают по объёму аудио, накопленной очереди и доступному времени обработки.

Если текст нужен прямо во время разговора, главными параметрами становятся пиковое число одновременных звонков и допустимая задержка.

Поэтому расчёт начинается не с выбора GPU, а с режима работы:

записи после звонка → часы аудио → очередь → окно обработки

или:

живые разговоры → одновременные потоки → задержка.

Почему количество операторов не определяет нагрузку ASR

Допустим, в контакт-центре работают 1000 операторов.

Это не означает, что сервер должен одновременно распознавать 1000 разговоров.

В одном проекте пиковая одновременная нагрузка может составлять 250 активных звонков, в другом — 700. Если же записи расшифровываются после завершения разговора, количество одновременно работающих операторов вообще перестаёт быть главным показателем.

Для расчёта сначала нужно определить режим.

ASR-платформы также обычно разделяют пакетное и потоковое распознавание. Например, NVIDIA Riva отдельно описывает offline и streaming ASR: Riva ASR Overview.

Для сервера это разные профили нагрузки, и измерять их нужно отдельно.

Какие данные собрать перед расчётом

До выбора GPU нужно описать реальный аудиовход и рабочий ASR-конвейер.

Минимальный набор данных:

Особенно важно не путать длительность звонков с объёмом аудио, который фактически получает ASR.

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

Эти варианты могут создавать разную вычислительную нагрузку.

Как рассчитать обработку записей после звонка

Для пакетной обработки сначала считаем объём аудио.

Если:

• N — количество звонков;

• D — средняя длительность звонка в минутах,

то предварительная оценка:

Часы аудио = N × D / 60

Пример

Контакт-центр обрабатывает 10 000 звонков в сутки.

Средняя длительность — 6 минут.

Получаем:

10 000 × 6 / 60 = 1000 часов разговоров.

Если доступны фактические длительности всех записей, для окончательного расчёта лучше суммировать их напрямую, а не использовать среднее значение.

Но даже 1000 часов аудио ещё не отвечают на вопрос, какой нужен сервер.

Нужно определить, за какое время весь требуемый объём должен быть обработан.

Допустим, расшифровки должны быть готовы за 10 часов:

1000 / 10 = 100

То есть ASR-инфраструктура должна совокупно обрабатывать около 100 часов такого аудио за один час реального времени.

Для удобства в этой статье обозначим такую скорость как xRT:

xRT показывает, сколько часов аудио обрабатывается за один час фактической работы системы.

Это внутреннее обозначение для расчёта, а не универсальное название отраслевой метрики.

В нашем примере требуется:

100 xRT.

Это уже полезное требование к производительности, но ещё не ответ «сколько нужно GPU».

Почему нужно считать очередь, а не только сутки

Средняя суточная нагрузка может скрывать реальную проблему.

Предположим, сервер способен обработать 1000 часов аудио за сутки. Формально этого достаточно для контакт-центра с тем же суточным объёмом.

Но записи могут поступать неравномерно.

Например:

• основная выгрузка начинается после окончания смены;

• телефония передаёт записи крупными пакетами;

• после сбоя накопилась большая очередь;

• аналитические отчёты должны быть готовы к определённому часу.

Поэтому практичнее считать максимальный объём очереди и время, за которое её нужно разобрать.

Если накопилось 600 часов аудио, которые должны быть обработаны за 4 часа:

Required xRT = 600 / 4 = 150

Требуемая производительность — 150 xRT.

Если во время этих четырёх часов продолжают поступать новые записи и они тоже должны быть обработаны в том же окне, их объём необходимо добавить к расчёту.

Основная формула:

Такой показатель намного полезнее для выбора сервера, чем просто «столько-то звонков в сутки».

RTF и xRT: почему метрики легко перепутать

В benchmark систем распознавания речи часто используется показатель RTF — Real-Time Factor.

Классическое определение выглядит так:

RTF = время обработки / длительность аудио

Допустим, один час записи обработан за 6 минут.

6 минут = 0,1 часа.

Получаем:

RTF = 0,1 / 1 = 0,1

То есть обработка идёт примерно в десять раз быстрее реального времени.

При таком определении:

• RTF = 1 — обработка в реальном времени;

• RTF < 1 — быстрее реального времени;

• RTF > 1 — медленнее.

Но можно встретить и обратную метрику.

Например, NVIDIA Riva использует в performance-тестах RTFX:

RTFX = длительность обработанного аудио / время вычисления

В том же примере:

RTFX = 1 / 0,1 = 10

Подробнее: Riva ASR Performance.

То есть значения 0,1 и 10 могут описывать одну и ту же производительность — просто в противоположных направлениях.

Поэтому перед использованием чужого benchmark всегда нужно проверить определение метрики у источника.

В дальнейшем для расчётов мы используем xRT именно как отношение:

Почему чужой benchmark ещё не определяет ваш сервер

Предположим, производитель показывает высокий RTFX на определённой GPU.

Можно ли просто разделить требуемые 150 xRT на результат benchmark и получить число GPU?

Для грубой предварительной оценки — иногда. Для окончательного выбора — нет.

На производительность влияют:

• ASR-модель и её версия;

• версия среды выполнения;

• язык;

• формат аудио;

• длительность файлов;

• число параллельных запросов;

• способ пакетной обработки;

• дополнительные функции.

Например, официальный benchmark может быть получен на другом датасете, с другим количеством параллельных запросов и другими настройками.

Поэтому результат производителя лучше воспринимать как ориентир.

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

Почему важна длительность записей

100 часов аудио могут выглядеть одинаково только на уровне суммарной длительности.

На практике это могут быть:

• тысячи коротких звонков;

• несколько сотен длинных разговоров;

• смесь коротких и очень длинных записей.

Для конкретной модели и среды выполнения эффективность пакетной обработки может различаться.

Поэтому для benchmark лучше использовать репрезентативный набор данных, который отражает реальное распределение длительности звонков.

Если в системе встречаются длинные разговоры, они тоже должны присутствовать в тестовой выборке.

Как рассчитать потоковое распознавание речи

Для streaming ASR логика другая.

Здесь сервер должен обрабатывать разговоры по мере их поступления, поэтому главным входным параметром становится пиковое количество одновременных разговоров.

Допустим:

• в штате контакт-центра 1000 операторов;

• максимум одновременно разговаривают 320.

Исходное требование для streaming:

После этого проверяется:

может ли конкретная конфигурация устойчиво обслуживать не менее 320 потоков при заданном профиле аудио и допустимой задержке?

Именно поэтому нельзя считать:

1000 операторов = 1000 ASR-потоков.

Для инфраструктуры нужен показатель максимальной одновременной нагрузки.

Почему offline xRT нельзя превращать в число живых звонков

Представим, что сервер показывает:

300 xRT

при обработке заранее записанных файлов.

Можно ли заключить, что он выдержит 300 живых разговоров?

Нет.

В пакетном режиме система получает готовые записи и может эффективно распределять их между параллельными задачами.

В streaming:

• аудио приходит небольшими фрагментами;

• одновременно открыто много сессий;

• нужны промежуточные результаты;

• очередь сильно ограничена;

• задержка становится частью SLA.

Поэтому offline throughput и streaming capacity тестируют отдельно.

NVIDIA Riva, например, для streaming публикует одновременно число потоков, размер аудиофрагмента, показатели задержки и суммарную производительность: Riva ASR Performance.

Правильное правило:

xRT пакетной обработки используют для расчёта записей, а количество живых потоков подтверждают отдельным streaming-тестом.

Для streaming важна не только пропускная способность

Представим две конфигурации:

Обе формально обслуживают 300 потоков.

Но для приложения это могут быть совершенно разные результаты.

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

Поэтому критерий:

сервер поддерживает 300 потоков

неполон.

Нужно формулировать условие так:

сервер поддерживает не менее 300 потоков при заданном аудиопрофиле и установленном SLA по задержке.

Универсального значения допустимой задержки нет — оно определяется конкретным приложением.

Какую задержку измерять

При потоковом распознавании можно измерять разные события.

Например:

• задержку появления промежуточного текста;

• задержку финального результата после завершения фразы;

• общую end-to-end задержку приложения.

Эти показатели нельзя механически сравнивать между собой.

В инструментах Riva, например, могут отдельно измеряться intermediate и final latency, тогда как опубликованные performance-таблицы используют общую latency возвращаемых ответов.

Поэтому перед нагрузочным тестом нужно заранее определить:

Если критичен текст, появляющийся во время разговора, измеряется один показатель.

Если важен финальный результат после завершения фразы — другой.

Почему среднего latency недостаточно

Среднее значение может скрывать редкие, но большие задержки.

Допустим:

• большинство запросов выполняются быстро;

• небольшая часть периодически задерживается на несколько секунд.

Средняя величина при этом всё ещё может выглядеть приемлемой.

Поэтому в нагрузочных тестах полезно смотреть на процентили, например p95 или p99.

Если:

p95 = 300 мс

это означает, что примерно 95% измеренных значений не превысили 300 мс.

Для расчёта сервера не обязательно углубляться в статистику. Достаточно заранее определить:

• какой показатель latency измеряется;

• какой процент запросов должен соответствовать SLA.

Качество распознавания тоже входит в расчёт

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

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

Если качество вышло за пределы требований проекта, такой результат benchmark бесполезен.

Одна из распространённых метрик ASR — WER, Word Error Rate.

Упрощённо:

WER = (замены + удаления + вставки) / количество слов в эталонной расшифровке

Чем меньше WER, тем меньше ошибок относительно эталона.

Но WER из публичного benchmark нельзя автоматически переносить на конкретный контакт-центр.

Тестовый набор производителя может отличаться по:

• языку;

• качеству записи;

• кодеку;

• шуму;

• акцентам;

• терминологии;

• типам разговоров.

Поэтому качество нужно проверять на репрезентативной выборке собственных данных.

Для пакетного режима конфигурация должна одновременно пройти:

производительность + качество.

Для streaming:

Что меняют каналы и диаризация

В телефонной системе стороны разговора могут обрабатываться по-разному.

Стороны уже разделены

Телефония сохраняет оператора и клиента отдельно, а дальнейшая архитектура передаёт в ASR подготовленные самостоятельные аудиопотоки.

Используется один смешанный поток

В этом случае для определения говорящих может применяться диаризация.

Эти варианты нельзя считать одинаковыми по нагрузке.

Кроме того, возможности обработки каналов зависят от конкретного ASR-стека, поэтому их нужно проверить до benchmark.

Если диаризация является обязательной частью production-конвейера, тестировать сервер нужно с включённой диаризацией и с той моделью, которая действительно поддерживает выбранный режим.

NVIDIA Riva, например, документирует варианты speaker diarization, но доступность конкретных режимов зависит от используемой модели и версии ASR-стека: Riva ASR Overview.

Калькулятор нагрузки ASR

Для предварительного расчёта удобно использовать два режима.

1. Обработка записей после звонка

Расчёт

Сначала определяем фактический объём ASR-входа.

Для предварительной оценки:

Часы аудио = звонки × средняя длительность / 60

Затем определяем максимальный объём, который должен быть обработан в заданном временном окне:

Required xRT = объём ASR-входа / окно обработки

Например:

750 часов аудио нужно обработать за 5 часов.

Если за эти пять часов поступают дополнительные записи и их тоже нужно обработать, они включаются в объём расчёта.

После этого требуемые 150 xRT сравнивают с измеренной устойчивой производительностью конкретного ASR-конвейера.

2. Распознавание во время звонка

Расчёт

Основной вход:

Peak concurrent calls = необходимое число одновременных ASR-потоков

Например:

если одновременно разговаривают максимум 320 клиентов и операторов:

Required concurrency = 320 потоков.

После этого проводится streaming benchmark.

Конфигурация должна одновременно подтвердить:

• не менее 320 стабильных потоков;

• заданный SLA по задержке;

• требуемое качество распознавания.

Как проверить сервер перед выбором конфигурации

Пакетный и потоковый режимы лучше тестировать отдельно.

Для обработки записей

Возьмите репрезентативный набор аудио и зафиксируйте:

• суммарную длительность;

• распределение длительности файлов;

• формат и кодек;

• частоту дискретизации;

• способ обработки каналов;

• язык;

• ASR-модель и версию;

• среду выполнения;

• количество параллельных запросов;

• диаризацию и другие обязательные функции.

После теста измерьте:

• сколько часов аудио обработано;

• сколько заняло реального времени;

• фактический xRT;

• загрузку CPU и GPU;

• потребление памяти;

• WER.

Условие успеха:

измеренный xRT ≥ требуемого

и:

Для streaming

Используйте тот же аудиопрофиль, который будет поступать из телефонии.

Нагрузку увеличивайте ступенями:

1 поток → промежуточные уровни → проектный пик.

На каждой ступени проверяйте:

• число стабильных сессий;

• выбранную метрику задержки;

• p95/p99;

• ошибки;

• загрузку CPU и GPU;

• память;

• качество распознавания.

Условие успеха:

число стабильных потоков ≥ проектного пика

при одновременном выполнении:

latency ≤ SLA

и:

качество соответствует заданному порогу.

Даст ли вторая GPU вдвое больше производительности

Не обязательно.

Если приложение хорошо масштабируется, добавление GPU может заметно увеличить скорость обработки файлов или число одновременных потоков.

Но универсальная формула:

две GPU = вдвое больше звонков

не работает.

Результат зависит от:

• распределения запросов;

• ASR-модели;

• одновременно загруженных моделей;

• CPU;

• памяти;

• передачи данных;

• очередей;

• архитектуры приложения.

Поэтому конфигурацию с несколькими GPU нужно тестировать отдельно.

Особенно если один сервер одновременно обслуживает разные языки, модели или одновременно выполняет batch и streaming задачи.

Какие данные нужны для подбора сервера

До выбора конкретной конфигурации полезно собрать одну форму:

После заполнения этой таблицы вопрос:

Какую GPU поставить для 1000 операторов?

можно заменить на два измеримых требования.

Для записей:

Нужно обработать X часов ASR-входа за Y часов при заданном качестве.

Для живого распознавания:

Нужно одновременно обслуживать N потоков при заданной задержке и качестве.

Главное

Количество операторов само по себе не определяет необходимый ASR-сервер.

Для обработки записей нужно считать:

объём ASR-входа → максимальную очередь → окно обработки → требуемый xRT.

Для распознавания во время разговора:

пиковые одновременные звонки → число ASR-потоков → SLA по задержке.

После этого требования проверяются на конкретной модели, версии среды выполнения и реальном аудиопрофиле контакт-центра.

Причём одной скорости недостаточно.

Для пакетного режима должны одновременно выполняться:

производительность + качество.

Для streaming:

число потоков + задержка + качество.

Только после такой проверки можно обоснованно говорить, сколько записей или живых разговоров способен обслуживать конкретный GPU-сервер.