Голосовой AI-агент: почему 800 мс — главное число в архитектуре
Голосовой агент — это не «текстовый бот плюс TTS». Это цепочка STT → LLM → TTS, которая должна успеть ответить за время, пока человек не начал говорить снова. Разбираем latency-бюджет, turn-taking, обработку прерываний и три типичные поломки streaming-пайплайна.
ПродвинутыйЭкспериментальное40 минLiveKit Agents, Deepgram, ElevenLabs, Claude Haiku
1
Голос — это latency, всё остальное вторично
В чат-боте задержка в три секунды неприятна, но терпима. В голосовом агенте те же три секунды — катастрофа: пользователь начинает говорить снова, думая, что его не услышали, и разговор разваливается.
Голосовой агент живёт в бюджете latency, который установлен человеческим слухом, а не инженером. Между последним словом и началом ответа должно пройти меньше 800 мс — иначе собеседник чувствует «что-то не так». Меньше 500 мс — живой разговор. Больше 1,5 секунд — ощущение рации.
Этот бюджет — главный ограничитель архитектуры. Модель побольше? Не влезет. Больше контекста? Не влезет. Latency — не метрика, а рамка, в которой живёт всё остальное.
💬 Текстовый чат
- Latency 1–3 с — приемлемо
- Главное — качество ответа
- Свобода выбора модели и контекста
🎙️ Голосовой агент
- Latency <800 мс — иначе UX ломается
- Главное — ритм разговора
- Архитектура диктуется бюджетом
Считайте latency первой, не последней. До всякого кода напишите: STT = X мс, LLM first token = Y мс, TTS first audio = Z мс, total. Если сумма больше секунды — архитектура не заработает как голос, и никакие оптимизации потом не спасут.
2
Три этапа, три источника задержки
Голосовой агент — три разных модели в цепочке: STT превращает голос в текст, LLM думает, TTS превращает ответ обратно в голос. У каждой свой бюджет, и сумма определяет, чувствует ли пользователь живой разговор.
STT: обычно 200–500 мс после конца реплики. Whisper или Deepgram, со streaming-режимом срезаем до 100 мс за счёт промежуточных гипотез.
LLM: time-to-first-token. Вот почему выбор модели критичен — Haiku выдаёт первый токен за ~200 мс, большие модели — 600+. Размер промпта тоже влияет, поэтому prompt caching здесь не опция, а обязательное условие.
TTS: первые слова должны звучать, пока ответ ещё генерируется. ElevenLabs, Cartesia отдают аудио после первых 40–50 символов от LLM.
STT — голос в текст
бюджет ~200–500 мс, streaming до 100 мс
LLM — мышление
TTFT 200–600 мс, зависит от модели + кэша
TTS — текст в голос
streaming после 40–50 символов ответа
Итого: <800 мс до первого звука
это тот самый целевой бюджет
Streaming на всех трёх этапах — это не оптимизация, это единственный способ уложиться в бюджет. Если хоть один этап в batch-режиме — архитектура уже проиграла. Выбирайте только streaming-совместимые модели и провайдеров.
3
Turn-taking: главная сложность не в моделях, а в тишине
Человек говорит, в какой-то момент замолкает, и агент должен ответить. Вопрос: как агент понимает, что человек ЗАКОНЧИЛ, а не просто сделал паузу между мыслями?
Этим занимается VAD (Voice Activity Detection). Простейший VAD меряет громкость: тишина N миллисекунд — конец реплики. Работает плохо: люди делают паузы посреди мысли («мне нужно … [1,5 секунды] … понять, сколько у нас заказов»). Агрессивный VAD прерывает, робкий молчит вечно.
Современные голосовые агенты используют семантический turn detection: отдельная маленькая модель смотрит на слова и интонацию и решает, закончена ли мысль. «Мне нужно понять» — точно не конец. «Сколько у нас заказов?» — конец с высокой вероятностью.
Настройте разные пороги для разных контекстов. «Записать встречу» — длинные паузы терпимы, «купить билет» — пауза 800 мс уже значит, что пользователь ждёт ответа. Один универсальный порог плох в обоих сценариях.
4
Прерывание — не обработка ошибок, а право пользователя
Представьте звонок в колл-центр. Оператор начал говорить, вы понимаете, что он идёт не туда, и перебиваете: «подождите, я про другое». Что делает голосовой агент без обработки прерываний? Продолжает вещать поверх вас, пока не договорит запланированное. Катастрофа: пользователь буквально не может с ним разговаривать.
Interruption handling — это три вещи, которые должны работать одновременно. Первая: VAD на входе работает всегда, даже когда говорит агент. Как только слышит голос пользователя — сигнал. Вторая: TTS должен уметь остановиться мгновенно, посреди слова. Не «доиграть предложение», а именно hard cut. Третья: LLM должен узнать не только о факте прерывания, но и о том, ЧТО успел сказать агент. Иначе в следующем ходе он начнёт с той точки, где закончился текст, а пользователь слышал только первые два предложения.
Это самый недооценённый кусок голосового UX. На демо всё выглядит красиво, потому что там тщательно говорят по очереди. В проде люди перебивают постоянно. Если прерывание не работает — агент не работает.
Сохраняйте в истории диалога не «что LLM сгенерировал», а «что пользователь реально услышал». Это разные вещи во время прерывания, и именно от этого зависит, поймёт ли следующий ход контекст предыдущего.
5
Три поломки streaming-пайплайна, о которых не пишут
Streaming всё ускоряет — но ломается тремя способами, которые надо знать заранее.
Первый: TTS читает «2026» то как «две тысячи двадцать шесть», то как «два ноль два шесть», потому что получает токены по одному и не видит число целиком. Лечение — нормализатор между LLM и TTS.
Второй: LLM зовёт инструмент посреди ответа. Вы уже озвучили «сейчас проверю заказ», а инструмент вернул ошибку, и продолжить нечем. Лечение — сначала отдавать filler-фразы, реальный ответ формировать после tool call.
Третий: эхо микрофона, когда агент слышит собственный TTS. Лечение — echo cancellation в SDK и игнор VAD, пока TTS активен.
| Симптом | Причина | Лечение |
|---|---|---|
| TTS читает «2026» по-разному | Streaming получает токены частями | Нормализатор чисел и дат |
| LLM зовёт инструмент посреди фразы | Streaming не видит будущее | Сначала filler, потом ответ |
| Агент отвечает сам себе | Эхо TTS в микрофон | Echo cancel + mute VAD при TTS |
Записывайте сессии и переслушивайте — читая логи, половины проблем не услышать. Странная интонация, неловкая пауза, эхо — всё это ловится только ухом. Одна запись за утро экономит день отладки.
Результат
Работающий голосовой агент с бюджетом меньше 800 мс от конца речи пользователя до первого слова ответа. Streaming на всех трёх этапах, семантический turn detection, корректная обработка прерываний — ощущение не «я разговариваю с ботом», а «я разговариваю с быстрым коллегой».