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

Вы можете подобрать 3CX AI Server под сегодняшнюю нагрузку и добавлять ресурсы по мере ее роста. Нет необходимости заранее закупать оборудование под все возможные будущие задачи.

Первый AI Server необязательно должен быть единственным, и каждой АТС PBX не нужен собственный сервер. Одна PBX может использовать один или несколько AI Server, а несколько PBX могут совместно использовать один сервер или пул.

Например, партнер может распределять ИИ-ресурсы между несколькими клиентами для лучшей загрузки, а затем добавлять серверы для роста и отказоустойчивости. Та же гибкость доступна компаниям с одной крупной PBX или несколькими системами.

При любом варианте развертывания метод расчета одинаков: определите объем записей для обработки, добавьте запас на ближайший рост, проверьте пропускную способность в часы пик и увеличивайте мощности по мере необходимости. Варианты подключения описаны в 3CX AI Server Upcoming Updates.

Рассчитайте фактическую рабочую нагрузку

Рассчитайте фактическую рабочую нагрузку

Условная временная шкала: один сервер транскрибации (AI Server) обрабатывает исходную нагрузку. Когда загрузка достигает 80% его пропускной способности, добавляется второй сервер, оставляя резерв для подключения новой PBX к общему пулу.

Подбирайте AI Server по количеству минут записей разговоров и голосовых сообщений, отправляемых на транскрибацию, а не по общему объему телефонного трафика.

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

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

В этом условном примере компания отправляет на транскрибацию 50,000 минут записей ежемесячно и хочет обрабатывать их за 12 часов каждого рабочего дня. Это соответствует средней почасовой нагрузке около 189 минут записей:

Исходные данные для расчета Пример расчета
Месячный объем записей 50,000 минут
Рабочих дней в месяце 22
Часов обработки в рабочий день 12
Доступное время обработки 22 x 12 = 264 часа/месяц
Средняя почасовая нагрузка 50,000 / 264 = 189.4 мин записей/час

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

Сравните нагрузку с измеренной производительностью

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

Общие характеристики оборудования не отражают длительность ваших вызовов или объем анализа. Поэтому измеряйте устойчивую скорость обработки на репрезентативных записях с учетом обоих факторов. Сравнение оборудования, а также пояснения Speed Factor и времени прохождения запроса туда и обратно приведены в 3CX AI Server – Speed and Response Time. Требования к оборудованию и платформам есть в руководстве по установке AI Server. Запас на рост покажет, сможет ли сервер обработать увеличившуюся нагрузку без немедленного расширения.

Продолжим пример: предположим, что измеренный Speed Factor оборудования составляет 10x, а запас на рост — 30%. Замените эти значения собственными измерениями и прогнозами.

Проверка производительности Расчет Результат
Измеренная производительность (Speed Factor 10x) 10 x 60mins 600 мин записей/час
Среднее + 30% роста 189.4 x 1.30 246.2 мин записей/час
Планируемое среднее использование мощности 246.2 / 600 x 100 41.0% мощности AI Server
Наблюдаемая нагрузка в час пик Измеренное значение 300 мин записей/час
Час пик + 30% роста 300 x 1.30 390 мин записей/час
Планируемое использование мощности в час пик 390 / 600 x 100 65.0% мощности AI Server

В этом примере планируемая средняя нагрузка составляет 41% измеренной пропускной способности, а в час пик — 65%. Сервер подходит и имеет запас. Но среднее значение — лишь первичная проверка, поскольку оно скрывает пиковые периоды. Эти проценты отражают соотношение объема записей и измеренной пропускной способности, а не загрузку CPU или GPU.

Проверьте пиковые нагрузки и оставьте резерв для восстановления

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

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

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

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

Увеличивайте мощности по мере роста спроса

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

Подключение новой PBX, расширение записи на другое подразделение или устойчивый рост повышают спрос. Общие серверы позволяют использовать свободные ресурсы между системами, а дополнительные серверы транскрибации (AI Servers) расширяют пул. Смешанный пул не обязательно масштабируется строго пропорционально количеству серверов, поэтому после каждого расширения измеряйте общую пропускную способность.

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

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

Присоединяйтесь к обсуждению

Обсуждайте 3CX на наших форумах для партнеров и клиентов. Подписывайтесь на нас в X и LinkedIn, чтобы узнавать о новостях и новых функциях.