Проблема латентності
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%.