Проблема латентности
У Voice AI жёсткий latency-бюджет. Всё, что свыше 500мс, ощущается как задержка. Свыше 1 секунды — как поломка. Наш v1 pipeline был в среднем 600мс: нормально для продукта, но не круто для планки, которую мы хотели взять.
Latency в voice-pipeline-ах определяется цепочкой сервисов: ASR → LLM → TTS, плюс сетевые round trips. Каждый этап ждёт завершения предыдущего. При 200мс ASR + 250мс LLM + 200мс TTS вы уже на 650мс.
Streaming partials между каждым этапом
Самый большой выигрыш — никогда не ждать, пока этап завершится. ASR стримит partial-транскрипты, пока пользователь говорит. LLM получает partials и начинает генерировать. TTS стримит аудио-chunks ещё до того, как LLM закончит.
У этого есть компромиссы. ASR partials шумные, они пересматриваются по мере поступления аудио. LLM должна обрабатывать это корректно. Мы добавили тонкий слой, который буферизует последние 150 мс partials перед передачей в LLM, что поглощает большинство ревизий.
Выбор правильной модели на каждую реплику
Не каждому turn нужна 400B-param модель. Большинству, нет. Мы классифицируем входящие turns в 4 buckets, small-talk, factual lookup, reasoning, complex multi-step, и маршрутизируем в модель подходящего размера для каждого.
Small-talk идёт на 7B модель с 80мс inference. Reasoning, на 70B. Complex multi-step, на самую большую. Сам наш классификатор имеет 200M params и работает меньше чем за 10мс.
Конечный результат
Медианная задержка первого токена: 180мс. P95: 280мс. P99: 420мс. Самый медленный тир разговоров всё ещё ниже перцептивного порога для большинства пользователей.
Стоимость тоже упала: мы используем малую модель 70% времени, среднюю — 25%, большую — только 5%.