Классический пайплайн: STT — LLM — TTS

TTS и суммарная задержка пайплайна

Как работает синтез речи

Текстовый ответ LLM поступает в TTS-движок, который преобразует его в аудиопоток. Современные нейросетевые TTS-системы делают это быстро и качественно — на коротких фразах синтезированный голос практически неотличим от человеческого.

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

• Батчевый режим — движок получает весь текст, синтезирует полный аудиофайл, затем отдаёт его клиенту. Простой в реализации, добавляет задержку, пропорциональную длине текста. Для реплик длиннее 5–7 слов неприемлем в реальном времени.
• Потоковый режим (streaming) — движок начинает отдавать аудиочанки по мере синтеза, не дожидаясь конца текста. Клиент слышит начало фразы, пока синтезируется остаток. Снижает воспринимаемую задержку на 200–600 мс. Все продакшн-сервисы (Yandex TTS, ElevenLabs, OpenAI TTS) поддерживают streaming.

Что влияет на натуральность голоса

Качество синтезированной речи зависит от нескольких факторов:

• Архитектура модели. Старые TTS на основе склейки заранее записанных фрагментов звучат механически. Хорошие нейросетевые модели на коротких фразах дают речь, практически неотличимую от человеческой.
• Голос (voice). Коммерческие сервисы предлагают библиотеки готовых голосов — от нейтрального офисного до эмоционального. Yandex TTS позволяет клонировать голос по нескольким минутам записи.
• Просодия. Интонация, паузы, ударения. На длинных репликах нейросетевые TTS могут давать монотонность — особенно на числах, датах и перечислениях. Это одна из причин ограничивать длину реплик агента.
• Совместимость с телефонией. Телефонная линия работает с пониженным качеством звука. TTS должен отдавать аудио в совместимом формате или конвертироваться на лету — иначе возникнут проблемы со звуком на стороне клиента.

Суммарная задержка: предел, который нельзя превышать

Клиент заканчивает говорить — и ждёт ответа. Пауза складывается из трёх компонентов:

• STT + VAD: 200–600 мс
• LLM (время до первого токена, TTFT): 200–2000 мс
• TTS (время до первого аудиочанка): 100–400 мс

Итого: от 500 мс до 3 секунд до того, как клиент услышит первое слово ответа. Исследования UX-качества голосовых агентов показывают: паузы до 1,5 секунды воспринимаются как норма, 1,5–2,5 секунды — как замедленность, свыше 3 секунд — как сбой или зависание.

Этот предел — главный инженерный параметр при выборе стека. Быстрая дешёвая LLM с TTFT 300 мс и локальный TTS с минимальной задержкой могут дать суммарную паузу в 700–800 мс. Мощная модель с длинным временем генерации — 3+ секунды, даже при хорошем STT.

Каскадный пайплайн и realtime-агенты: два инструмента

Пока каскадный пайплайн собирает задержку на трёх стыках, существует другой класс решений — нативные realtime-агенты. Модели вроде GPT-Realtime-2 принимают аудиопоток напрямую и отвечают аудио, минуя отдельные STT и TTS. Суммарная задержка — 300–600 мс, модель держит состояние всей сессии, понимает прерывания клиента и может одновременно вызывать несколько инструментов.

С 2025 года Yandex предлагает Realtime API для голосовых агентов — первый российский сервис этого класса. Остальные российские провайдеры остаются на каскадной архитектуре.

У каскадного подхода при этом есть своя ниша, и она не маленькая. Когда данные не должны покидать российское облако — Yandex SpeechKit + YandexGPT + Yandex TTS работают в нём полностью, realtime-сессии OpenAI такого варианта не дают. Если нужен отраслевой словарь в STT или специфическое произношение в TTS — в каскаде каждый компонент меняется независимо. На исходящем автообзвоне с простым скриптом дешёвый STT + быстрая языковая модель + потоковый TTS зачастую дешевле realtime-сессий.

Это не вопрос «что лучше» — это два инструмента с разными применениями. GPT-Realtime-2 разбирается отдельно и подробно: архитектура сессий, события, tool calling и практика.

Что измерять при задержке голосового ответа

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

Для одной реплики составьте временную шкалу. В последовательном STT → LLM → TTS примере стадии складываются, а в потоковой реализации могут перекрываться. Поэтому нельзя просто сложить времена завершения всех потоков и объявить это задержкой первого звука.

Проверьте короткую и длинную реплику, паузу внутри фразы и перебивание во время ответа. При barge-in важно остановить воспроизведение старого ответа и не допустить, чтобы его поздние фрагменты снова попали в аудио. Хорошая средняя latency не заменяет анализ длинного хвоста и ошибок отмены.

Продолжите разбор: Barge-in и latency budget: человечный диалог.