VoiSar: архитектурный спринт для голосовых AI-сессий

Размер кластера для voice AI нельзя выбирать отдельно от длительности звонков, пиковой одновременной нагрузки, задержки внешних моделей и правил хранения данных. Для VoiSar архитектурная задача началась с модели сессии и полного пути аудио. Архитектор связал телефонию, streaming ASR, LLM и streaming TTS с бюджетом задержки, режимами деградации, стоимостью и критериями пилота, чтобы первый запуск имел понятные границы до выбора размера кластера.

Спринт до расчета кластера

• Направление: Real-time, voice AI, инфраструктура.
• Задача: Спроектировать инфраструктуру для одновременных голосовых сессий с управляемой задержкой, стоимостью и деградацией внешних AI-компонентов.
• Роль AIFlowPoint: Поиск инфраструктурного архитектора, архитектурный спринт по голосовой сессии и подготовка первого нагрузочного испытания
• Продолжительность: 3 недели на архитектурный спринт с поддержкой пилота.
• Команда: Infrastructure architect, real-time voice engineer, DevOps/SRE, security reviewer частично и delivery manager.

Задержка, нагрузка и стоимость в одной модели

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

У voice AI полный пользовательский отклик складывается из нескольких зависимых участков. Телефония и потоковая передача аудио влияют на доставку реплики, streaming ASR на появление текста, LLM API на формирование ответа, а streaming TTS на начало воспроизведения. Если выбрать инфраструктуру без общей модели, можно оптимизировать один компонент и не уложиться в p95 всей сессии. Кроме задержки требовалось учитывать аварийное завершение звонков, перегрузку, медленный ответ внешней модели, стоимость пилота и хранение аудио и транскриптов.

Какие решения нельзя было принимать вслепую

Подход был зафиксирован четырьмя решениями:

• Заменили общий запрос на модель нагрузки с количеством сессий, длительностью, пиками, задержкой и сроком хранения записей.
• Разделили зависимости от телефонии, распознавания речи, LLM и синтеза голоса.
• Разложили полный путь аудио и рассчитали бюджет задержки по участкам.
• Заранее определили горизонтальное масштабирование, привязку сессии, ограничение перегрузки и режимы деградации.

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

Полный путь аудио и бюджет задержки

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

В ходе работы:

• Архитектор описал путь сессии через SIP или WebRTC, WebSocket и потоковое аудио.
• Разделил границы телефонии, streaming ASR, LLM и streaming TTS.
• Построил модель нагрузки, бюджета задержки и стоимости из согласованных параметров.
• Определил горизонтальное масштабирование, привязку сессии и инфраструктурный контур Kubernetes.
• Спроектировал backpressure, таймауты, circuit breaker, очереди и режим перевода на оператора.
• Зафиксировал требования к хранению аудио, транскриптов, ключей и персональных данных.
• Согласовал план пилота, критерии нагрузочного испытания и передачу решений команде.

Технический контур включал WebRTC, SIP, WebSocket, RTP, Streaming ASR, LLM API, Streaming TTS, Kubernetes, Helm, Terraform, GPU workloads, Redis, PostgreSQL, Kafka, Object storage, OpenTelemetry, Prometheus, Grafana, Loki, load testing, threat modeling и cost modeling. Каждый элемент должен был объяснять часть пути сессии, состояния или доказательства, а не служить декоративным списком технологий.

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

Спринт отдельно рассматривал перегрузку и медленный ответ внешней модели. Backpressure ограничивает прием работы, которую система уже не может обработать в целевом режиме. Таймауты и circuit breaker задают контролируемую реакцию на зависимый сервис. Очереди помогают отделить части процесса, где допустима отложенная обработка. Для разговора также был предусмотрен режим перевода на оператора.

Другой класс риска относился к состоянию сессии. Горизонтальное масштабирование требует определить, где нужна привязка сессии и какие данные нельзя потерять при смене экземпляра. Отдельно фиксировались требования к аудио, транскриптам, ключам и персональным данным, потому что производительность не отменяет threat model и ограничения хранения.

Как архитектуру готовили к первому испытанию

Критерии были сформулированы заранее:

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

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

Измеримые границы пилота

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

Критерии пилота: p95 от конца реплики пользователя до начала ответа TTS от 1,2 до 1,8 секунды; от 100 до 300 одновременных сессий; менее 1% аварийно завершенных звонков; расхождение расчетной и фактической стоимости пилота не более 15%.

Эффект: Архитектор связал инфраструктуру с нагрузкой, задержкой и стоимостью и подготовил применимый план масштабирования.

От модели к следующему масштабу

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

Переданные материалы:

• Архитектурная схема с границами компонентов и владельцами данных
• Модель нагрузки, задержки и стоимости
• Матрица отказов и режимов деградации
• Threat model и требования к хранению
• План пилота и критерии перехода к следующему масштабу
• Сценарий нагрузочного испытания
• Runbook частичного отказа AI-провайдера
• Сессия передачи решений внутренней команде

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

Артефакты проекта: архитектурная схема, бюджет задержки, OpenTelemetry traces, нагрузочный отчет, расчет стоимости и журнал проверки отказных режимов. Публичный набор включает обезличенный полный путь сессии, распределение бюджета задержки и фрагмент результатов нагрузочного испытания. Ключи, персональные данные, внутренние адреса, записи разговоров и чувствительная конфигурация в него не входят.

Кому релевантен этот опыт

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

Планируете voice AI и не хотите выбирать инфраструктуру вслепую? Зафиксируем модель нагрузки, бюджет задержки, режимы деградации и критерии первого пилота до расчета кластера.