Для голосового агента задержка — это не просто время до первого токена. Пока модель генерирует ответ, пользователь уже слышит паузу. Новый бенчмарк, опубликованный MarkTechPost 30 августа 2026 года, детально разбирает, почему TTFT (time to first token) — лишь один из элементов в уравнении, и вводит метрику TTFS (time to first sentence) как более релевантную для голосовых сценариев.
В основе анализа — данные от Artificial Analysis, LiveKit, Daily и Deepgram, собранные и верифицированные по состоянию на 30 августа 2026 года. Каждая цифра помечена как независимо измеренная, опубликованная вендором или полученная от провайдера на его собственном продукте.
Почему TTFT обманчив для голоса
TTFT измеряет интервал между отправкой запроса на инференс и получением первого токена. Для текстового чата этой метрики достаточно: пользователь видит символы по мере их появления. Но голосовой синтез не может начать воспроизведение с половины слова. TTS-модели требуется законченная клауза или предложение, прежде чем будет сгенерирован аудиофрагмент.
LiveKit в своем посте о развертывании Gemma 4 называет этот интервал «временем до первого предложения» (TTFS) и утверждает, что именно его ощущает пользователь. Таким образом, у разработчика два рычага: TTFT контролирует начало генерации, а скорость выдачи токенов (tokens per second) — скорость завершения первого предложения. Провайдер, выигрывающий по одному показателю и проигрывающий по другому, не будет восприниматься как быстрый.
Целевые значения и бюджет задержки
LiveKit в обзоре голосовых агентов разбивает один раунд диалога на этапы: STT — примерно 100–200 мс, LLM — 300–500 мс с потоковой выдачей, TTS — 100–200 мс, сеть — 50–150 мс через WebRTC. Практический целевой диапазон end-to-end — 700 мс – 1,2 с.
Квиндла Хультман Крамер, сооснователь Pipecat, рекомендует ориентироваться на медианную задержку голос-голос в 800 мс, с допустимым максимумом в 1500 мс для прототипа. Его примерное распределение: по 200 мс на транспорт и обработку медиа, STT с определением конца фразы, инференс LLM и TTS.
Daily в более ранней работе «The Fastest Voice Bot» приводит человеческий базовый уровень: типичное время реакции в разговоре — около 500 мс. Паузы более 800 мс начинают ощущаться неестественными. Из этого следует, что для естественного диалога задержка голос-голос должна быть менее 1500 мс, что дает бюджет примерно в 700 мс TTFT для текстовой LLM в связке с транскрипцией и синтезом.
Методология: пять важных оговорок
Перед сравнением провайдеров авторы бенчмарка перечисляют пять факторов, меняющих интерпретацию цифр.
Во-первых, форма рабочей нагрузки. Artificial Analysis в марте 2026 года сменил дефолтный промпт с 1 тыс. на 10 тыс. входных токенов. Более длинные промпты увеличивают как TTFT, так и скорость генерации. LiveKit утверждает, что это ближе к реальности для голоса, так как продакшн-агенты загружают политики, персону, правила эскалации, извлеченные данные и схемы инструментов.
Во-вторых, расположение сервера. Artificial Analysis тестирует из виртуальной машины в зоне us-central1-a Google Cloud. TTFT включает сетевую задержку, что может давать преимущество или недостаток провайдерам в зависимости от их географического размещения.
В-третьих, токены рассуждений. В определении Artificial Analysis TTFT для reasoning-модели — это первый токен рассуждения, а не первый ответный токен. Это разные колонки в таблицах.
В-четвертых, измерение со стороны получателя. Daily отмечает, что провайдеры иногда публикуют TTFT, замеренный внутри их стека инференса. Daily же измеряет от отправки запроса до первого полезного токена, полученного от API.
В-пятых, результаты не повторяемы. TTFT существенно варьируется между запусками, а провайдеры меняют стеки инференса и иногда веса без изменения названий моделей.
Ключевые цифры по провайдерам
Данные Artificial Analysis по состоянию на 30 августа 2026 года, рабочая нагрузка — 10 тыс. входных токенов, одиночный промпт, медиана за 72 часа.
Ключевые факты
| Параметр | Данные |
|---|---|
| Лучший TTFT среди LLM | Gemma 4 31B на LiveKit Inference — 192 мс |
| TTFT Gemini 2.5 Flash | 911 мс |
| TTFT GPT-5.5 | 966 мс |
| TTFT GPT-4.1 | 1006 мс |
| TTFS (полный раунд) Gemma 4 31B на LiveKit | 354 мс |
| TTFS GPT-4.1 | 1088 мс |
Mercury 2 — диффузионная языковая модель — генерирует 770 токенов в секунду, но ее первый чанк появляется через 3,07 с. Это в четыре раза превышает весь LLM-бюджет для естественного разговора. Cerebras и Groq, напротив, показывают приемлемый TTFT и исключительную пропускную способность, что делает их сильными кандидатами для TTFS.
Один и тот же модель на разных хостах дает разные результаты. GPT-5.6 Luna (non-reasoning) показывает 0,59 с на Amazon Bedrock и 0,74 с на собственном API OpenAI. Хостинг и маршрутизация имеют значение не меньшее, чем сами веса.
LiveKit публикует собственные цифры TTFT для своего продукта. Gemma 4 31B на LiveKit Inference — 192 мс, против 911 мс у Gemini 2.5 Flash, 966 мс у GPT-5.5 и 1006 мс у GPT-4.1. Та же Gemma 4 31B через OpenRouter — 1876 мс. LiveKit объясняет механизм: модель работает на SGLang со спекулятивным декодингом, а GPU намеренно недозагружены, чтобы минимизировать задержки в очереди. Цена — $1,20 за 1 млн выходных токенов.
STT: не скорость, а определение паузы
Для речи задержка STT — это не скорость транскрипции, а время, через которое система понимает, что пользователь закончил говорить. Artificial Analysis измеряет два показателя на своем стриминговом лидерборде STT, начиная отсчет от момента, когда SileroVAD зафиксировал конец речи: время до первого частичного транскрипта и время до финального транскрипта.
Deepgram Flux — самый архитектурно интересный вариант. Он встраивает определение конца реплики прямо в модель распознавания, а не использует отдельный VAD. Deepgram утверждает, что это может сократить задержку ответа агента на 200–600 мс по сравнению с традиционным пайплайном STT + VAD. Модель выставляет параметры eot_threshold (0,5–0,9) и eager_eot_threshold (0,3–0,9), а также событие EagerEndOfTurn, которое позволяет запустить LLM раньше.
Что это меняет для разработчиков
Главный практический вывод: выбор провайдера инференса для голосового агента не может опираться только на TTFT. Необходимо учитывать TTFS, который складывается из TTFT и скорости генерации токенов. Провайдеры, оптимизирующие под пакетную обработку (как Mercury 2), могут показывать отличную пропускную способность, но быть непригодными для real-time голоса.
LiveKit демонстрирует, что специализированная инфраструктура со спекулятивным декодингом и контролем загрузки GPU способна достичь TTFT в районе 200 мс, что укладывается в бюджет естественного диалога. Однако цена такого решения выше, и не все провайдеры готовы раскрывать детали своей архитектуры.
Разработчикам стоит учитывать, что цифры TTFT сильно зависят от длины промпта, расположения сервера и методологии измерения. Рекомендуется проводить собственные тесты с реальной рабочей нагрузкой и измерять задержку со стороны клиента, а не полагаться на опубликованные вендорами данные.
Источник: MarkTechPost — «Lowest-Latency Inference APIs for Voice and Realtime Agents: A Time to First Token TTFT-First Benchmark»