Сокращение задержки голосовых ИИ-агентов: потоковая передача аудио через Kokoro TTS на Amazon SageMaker ИИ
AWS Machine Learning · оригинал
Материал подготовлен автоматизированной редакционной системой. Факты можно сверить по указанному первоисточнику.
AWS представила метод снижения задержки в голосовых интерфейсах, позволяющий начинать синтез речи сразу после генерации первого предложения агентом. Использование двунаправленного WebSocket-транспорта и модели Kokoro-82M сокращает время до первого аудиокадра на 52% по сравнению с пакетной обработкой.
Снижение латентности критически важно для пользовательского опыта в голосовых ассистентах. Описанный подход демонстрирует, как архитектурные решения на уровне транспорта и выбора модели влияют на скорость отклика реальных систем.
Взаимодействие с голосовыми ИИ-агентами часто страдает от скрытой задержки: пользователь ожидает ответа, пока система генерирует весь текст целиком, прежде чем начать синтез речи. Даже если первое предложение готово за миллисекунды, интеграция может ждать завершения всего многословного ответа, что приводит к паузе в несколько секунд и потере внимания клиента. В материале описывается решение этой проблемы путем потоковой передачи каждого сгенерированного предложения непосредственно в модель синтеза речи Kokoro-82M, размещенную на Amazon SageMaker AI.
Ключевым элементом архитектуры является использование модели Kokoro-82M, содержащей всего 82 миллиона параметров. Это позволяет запускать ее на одном среднем GPU-инстансе (ml.g5.xlarge), что снижает как стоимость инференса, так и задержку. Модель работает в кастомном контейнере на реальном эндпоинте SageMaker AI, предоставляя два маршрута: стандартный POST для пакетной обработки и WebSocket-маршрут для двунаправленного стриминга. Последний позволяет поддерживать одно соединение открытым для множества сообщений, избегая накладных расходов на повторное подключение между фразами.
Реализация требует внимания к деталям протокола. Например, SageMaker AI передает сообщения клиента как бинарные WebSocket-кадры, что приводит к ошибкам KeyError('text') при использовании стандартных обработчиков текстовых сообщений в Starlette. Разработчикам необходимо явно декодировать байты как UTF-8, если поле 'text' отсутствует. Кроме того, сессия не должна закрываться после каждой фразы; соединение остается активным до явного сигнала закрытия от клиента, что обеспечивает непрерывность потока.
Выбор транспорта для возврата аудио в браузер также влияет на производительность. Если фронтенд уже использует Server-Sent Events (SSE) для текста, наиболее практичным решением является кодирование аудио в base64 внутри JSON-событий. Однако это увеличивает размер полезной нагрузки примерно на 33% и требует буферизации данных для корректной сборки MP3-кадров, которые могут разрываться произвольно при передаче. Альтернативный подход — мультиплексирование сырых бинарных данных аудио и JSON-контрольных кадров в одном WebSocket-соединении. Это устраняет необходимость в кодировании и выравнивании кадров, но требует более сложной логики на стороне клиента.
Тестирование показало значительный выигрыш во времени отклика. При изолированном тесте транспорта TTS отправка только первого предложения сократила среднее время до первого аудиокадра с 329,3 мс до 156,7 мс, что составляет улучшение на 52,4%. В полном цикле с использованием языковой модели из Amazon Bedrock режим двунаправленного стриминга (bidi) оказался в 2,4 раза быстрее пакетного режима (batch) при работе с локальным контейнером и в 3,5 раза быстрее при развертывании на AgentCore runtime. Разрыв во времени увеличивается при добавлении сетевых задержек, так как пакетный режим не может перекрывать время генерации текста временем синтеза речи.
Для внедрения этого паттерна необходимы AWS CDK v2, Python 3.12 и Docker для сборки образов. Важно учитывать, что примерный код использует версию PyTorch с известным уязвимостью (PYSEC-2026-2286), которую следует обновить перед использованием в продакшене. Разработчикам рекомендуется начать с base64/SSE подхода, если инфраструктура уже существует, и переходить к унифицированному бинарному транспорту, когда приоритетом становится минимальная задержка.