Самые быстрые API для голосовых AI-агентов: бенчмарк задержки TTFT и полных диалоговых пайплайнов

Время получения первого токена (Time to First Token, TTFT) стало главной метрикой, на которую ориентируются разработчики при выборе инференс-API для голосовых AI-агентов. Однако слепое доверие этому показателю часто приводит к ложным выводам. TTFT фиксирует лишь момент начала генерации текста, в то время как модуль синтеза речи (TTS) не способен начать озвучку с обрывка слова — ему требуется законченная фраза или предложение. Именно в разрыве между первым токеном и готовым для воспроизведения аудио кроется разница между агентом, поддерживающим живую беседу, и системой, которую постоянно хочется перебить. В данном бенчмарке детально разбирается каждый уровень голосового стека: языковые модели (LLM), распознавание речи (STT), генерация аудио (TTS) и сквозные системы Speech-to-Speech.

Почему TTFT — хорошая стартовая метрика, но плохой итоговый ориентир

Голосовой AI-агент представляет собой строго ограниченный бюджет задержки, внутри которого функционирует языковая модель. Каждый этап обработки расходует ценные миллисекунды, которые напрямую воспринимаются пользователем на слух.

Метрика Time to First Token (TTFT) отражает временной интервал от отправки запроса к API до момента получения первого токена. В определении IBM это точка перехода системы из состояния ожидания в режим видимой активности.

В случае с текстовыми чатами TTFT практически полностью описывает производительность. Однако для голосовых интерфейсов это лишь одно из слагаемых в общей сумме. Причина чисто механическая: модуль синтеза речи не может озвучить половину слова. Ему необходимо полное предложение или законченная смысловая фраза. В компании LiveKit вводят термин «время до первого предложения» (Time-to-First-Sentence, TTFS) и подчеркивают, что именно этот параметр формирует реальное ощущение скорости у пользователя.

Таким образом, инженеру приходится управлять двумя рычагами одновременно. TTFT определяет, когда начнется генерация, а скорость вывода (число токенов в секунду) задает темп формирования первого предложения. Провайдер, лидирующий по TTFT, но проигрывающий по пропускной способности, в реальном разговоре будет казаться медленным.

Бюджет задержки: сколько на самом деле стоит одна реплика в диалоге

В обзоре архитектуры голосовых агентов от LiveKit диалоговый ход разбивается на следующие составляющие:

• STT (распознавание речи): около 100–200 мс;
• LLM (генерация текста с потоковой передачей): 300–500 мс;
• TTS (синтез речи): 100–200 мс;
• Сетевые задержки (WebRTC): 50–150 мс.

Это закладывает практический ориентир сквозной задержки в диапазоне от 700 мс до 1,2 секунды.

Квиндла Хултман Крамер, сосоздатель фреймворка Pipecat, рекомендует целить в медианную задержку «от голоса до голоса» на уровне 800 мс, тогда как планка в 1500 мс допустима лишь для базовых прототипов. Его сбалансированный бюджет делит диалоговый ход на четыре равных блока по 200 мс: передача данных и медиа-обработка, распознавание речи с фиксацией паузы, инференс LLM и генерация аудио через TTS.

Человеческий ориентир дают исследования компании Daily: стандартная пауза между репликами собеседников в естественной беседе составляет около 500 мс. Задержки свыше 800 мс начинают восприниматься как неестественное промедление. В бенчмарке Daily за февраль 2026 года эти требования сформулированы прямо: естественный диалог требует общего времени реакции менее 1500 мс, что оставляет на долю TTFT языковой модели не более 700 мс. Именно этот порог в 700 мс является главным критерием оценки всех API-провайдеров.

Как правильно читать бенчмарки TTFT и не попасться на уловки

Перед изучением сравнительных таблиц важно учитывать пять методологических факторов, определяющих значение итоговых цифр:

1. Объем и профиль нагрузки. В марте 2026 года платформа Artificial Analysis перешла со стандартных промптов объемом 1k токенов на промпты в 10k токенов. Длинный входной контекст увеличивает TTFT, но стимулирует более высокую скорость генерации. В LiveKit отмечают, что это ближе к реальным условиям голосовых агентов, куда заранее загружаются системные инструкции, сценарии, контекст и схемы функций.
2. Географическая привязка серверов. Тесты Artificial Analysis проводятся с виртуальной машины Google Cloud в зоне us-central1-a. Сетевая задержка включена в показатели TTFT, что создает преимущества или издержки для провайдеров в зависимости от локации их дата-центров.
3. Учет токенов рассуждения (reasoning). В методологии Artificial Analysis для рассуждающих моделей показатель TTFT фиксируется по первому токену мыслительного процесса, а не по первому токену финального ответа.
4. Замер на стороне получателя. По наблюдениям Daily, поставщики моделей часто декларируют внутренние задержки своих кластеров. Независимые тесты замеряют время строго от момента отправки запроса до получения первого готового токена из API.
5. Непостоянство результатов. Результаты тестов TTFT существенно варьируются от запуска к запуску, а провайдеры регулярно обновляют стек инференса и веса моделей без смены названий эндпоинтов.

Уровень 1: Время до первого токена LLM

Данные ниже получены из рейтинга API-провайдеров Artificial Analysis (по состоянию на конец августа 2026 года) для промпта объемом 10k токенов (медиана за 72 часа).

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

Ловушка пропускной способности

Создатели специализированных чипов часто оптимизируют системы под высокие показатели пропускной способности, а не под параметры, критичные для диалоговых агентов.

Наглядным примером служит Mercury 2 от Inception. Это диффузионная языковая модель со скоростью 770 токенов в секунду, однако ее первый токен появляется только через 3,07 секунды. Это в четыре раза превосходит весь допустимый бюджет времени LLM для нормального разговора.

Cerebras и Groq демонстрируют иной подход: у них приемлемый TTFT сочетается с высокой генерацией токенов. Для итогового показателя TTFS это выигрышное сочетание, так как первое предложение формируется почти мгновенно вслед за появлением стартового токена.

Флагманские и проприетарные эндпоинты

Заметьте разницу для одной и той же модели на разных площадках. GPT-5.6 Luna без функций рассуждения выдает TTFT 0,59 с на Amazon Bedrock против 0,74 с на собственном API OpenAI. Серверная инфраструктура и маршрутизация влияют на скорость не меньше, чем архитектура модели.

Аномальные показатели от разработчиков

Компания LiveKit публикует данные собственного сервиса инференса. Модель Gemma 4 31B на LiveKit Inference продемонстрировала TTFT в 192 мс, тогда как Gemini 2.5 Flash показала 911 мс, GPT-5.5 — 966 мс, GPT-4.1 — 1006 мс, а та же Gemma 4 31B через OpenRouter — 1876 мс.

LiveKit аргументирует свои результаты архитектурным устройством: Gemma развернута с использованием SGLang и спекулятивного декодирования, а вычислительные узлы GPU сознательно недогружаются по плотности запросов во избежание образования очередей. Горячий запрос начинает выдавать токены примерно через 100 мс (при стоимости $1,20 за 1 млн выходных токенов).

В тестах полного цикла беседы показатель TTFS у Gemma 4 31B на LiveKit составил 354 мс против 1034 мс у Gemini 2.5 Flash и 1404 мс у GPT-5.5. На бенчмарке инструкций IFBench модель Gemma 4 31B набрала 75,6% (против 75,9% у GPT-5.5 и 39% у Gemini 2.5 Flash).

Уровень 2: Распознавание речи и определение окончания реплики

В контексте диалоговых агентов задержка STT — это не скорость перевода аудио в текст, а время, за которое система понимает, что пользователь завершил свою фразовую реплику.

Artificial Analysis замеряет два параметра на стриминговом лидерборде STT после фиксации окончания речи с помощью SileroVAD: время до получения первого частичного транскрипта и время до финального текста.

Заявленные разработчиками параметры задержек:

• Deepgram Flux: около 260 мс (p50) при стандартных настройках определения конца реплики;
• Deepgram Nova-3: менее 300 мс стриминговой задержки;
• AssemblyAI Universal-Streaming: около 300 мс до отдачи неизменяемых слов;
• Cartesia Ink-2: 100 мс задержки транскрипции;
• Speechmatics Voice SDK: 0,451 ± 0,022 с от конца речи до финального текста.

Архитектура Deepgram Flux выделяется тем, что детектор завершения реплики встроен непосредственно в модель распознавания речи, а не подключен поверх в виде внешнего модуля VAD. Это экономит 200–600 мс. Параметры eot_threshold, eager_eot_threshold и событие EagerEndOfTurn позволяют инициировать запрос к LLM заранее.

AssemblyAI Universal-Streaming вместо классической схемы «частичные транскрипты — финальный текст» генерирует сразу неизменяемые фрагменты. В собственных тестах AssemblyAI зафиксировала медианную задержку выдачи слова в 307 мс против 516 мс у Deepgram Nova-3. Документация рекомендует отправлять в LLM текст без форматирования, так как форматирование поступает позже и практически не влияет на ответ языковой модели.

В тестах точности (WER) AssemblyAI заявляет для Universal-3.5 Pro Realtime показатель ошибок 6,99% на бенчмарке Pipecat против 9,04% у Google Chirp3, 9,76% у ElevenLabs Scribe v2 и 15,58% у Deepgram Flux.

LiveKit также поддерживает опережающую генерацию (preemptive generation) на базе частичных транскриптов. Однако если финальный текст меняет смысл и запрос приходится перезапускать, это приводит к бесполезной трате токенов.

Уровень 3: Синтез речи — время до первого звука

В сегменте TTS официальные заявления провайдеров сильнее всего расходятся с реальным пользовательским опытом.

ElevenLabs заявляет для Flash v2.5 задержку в районе 75 мс. Однако в документации указано, что речь идет исключительно про инференс самой модели. Сетевой маршрут добавляет от 20 до 200 мс, а клиенты и аудиоплееры используют буферизацию перед воспроизведением (стандартный буфер составляет около 500 мс).

Cartesia заявляет о задержке TTS менее 90 мс для Sonic-3.6 (архитектура State Space Models) и 100 мс для Ink-2. Ранее для Sonic 3.5 заявлялись 82 мс сквозной задержки до первого звука.

Показатели качества голосовых моделей в blind-test арене Artificial Analysis (оценка Elo):

Разрыв между Sonic 3.6 (1288 Elo) и Flash v2.5 (1083 Elo) демонстрирует компромисс по качеству, на который приходится идти ради снижения задержки.

Уровень 4: Модели «речь-в-речь» — время до первого аудио

Модели формата Speech-to-Speech (S2S) объединяют STT, LLM и TTS в единый проход. Теоретически уменьшение числа промежуточных этапов должно снижать задержку.

Тем не менее данные Artificial Analysis показывают, что сквозные модели не всегда выигрывают по скорости у оптимизированных каскадных систем.

Лучший результат показывает Grok Voice Think Fast 2.0 High: TTFA 0,70 с при 97% точности голосовых рассуждений и 94,7% успешности задач.

Плата за глубину рассуждений хорошо заметна внутри единых семейств моделей. Gemini 3.1 Flash Live увеличивает TTFA с 0,96 с до 2,99 с при переходе от уровня Minimal к High. У GPT-Realtime-2.1 рост задержки с 0,97 с до 1,21 с обеспечивает прирост успешности выполнения задач на 2,1 процентного пункта.

Выпуск OpenAI моделей gpt-realtime-2.1 и gpt-realtime-2.1-mini в июле 2026 года принес сокращение задержки 95-го перцентиля (p95) минимум на 25% благодаря оптимизации кэширования.

Разрыв в функциональных возможностях

Бенчмарк Daily показывает причины, по которым в продакшене чаще применяются каскадные пайплайны. На тесте aiwf_medium_context модель GPT Realtime показала точность 86,7% против 94,9% у каскада с GPT-4.1. Модель Ultravox 0.7 с открытыми весами стала одной из первых S2S-систем, показавших стабильность в длинных многоходовых диалогах.

Из четырех готовых каскадных платформ, протестированных Artificial Analysis (Deepgram Voice Agent, ElevenLabs Agents, Cartesia Line, Inworld Realtime), три используют Gemini 2.5 Flash в качестве базовой языковой модели.

Эталонные бюджеты задержки

Ориентировочные расчеты для планирования архитектурных решений:

Оптимизированный каскадный пайплайн (США, единый дата-центр):

• Транспорт и медиа (WebRTC): 50–150 мс;
• STT + определение конца фразы (Deepgram Flux): ~260 мс;
• LLM первый токен (быстрый сегмент): 230–500 мс;
• Завершение предложения (при 250+ tok/s): ~100 мс;
• TTS первый звук + сеть: 150–300 мс;
• Итого: ~790 мс – 1,3 с.

Сквозная модель Speech-to-Speech:

• Транспорт и медиа: 50–150 мс;
• Модель TTFA (минимальный уровень рассуждений): 700 мс – 1,0 с;
• Итого: ~750 мс – 1,15 с (ограничение по функциональности и вызову инструментов).

Практические рекомендации по оптимизации

• Выбирайте профильную метрику. Если цепочка содержит модуль TTS, оценивайте TTFS, сочетающий TTFT и скорость генерации токенов.
• Размещайте сервисы рядом. Единая геолокация кода агента и API моделей снижает задержку эффективнее, чем смена модели. При использовании SIP-телефонии держите транк близко к серверу.
• Ограничивайте глубину рассуждений. Настройка уровня reasoning — самый простой способ снизить TTFT.
• Учитывайте вызовы инструментов (tool calls). Каждое обращение к внешнему API удваивает задержку хода. Ограничивайте max_tool_steps и включайте фоновые звуки ожидания.
• Внедряйте телеметрию. Логируйте параметры e2e_latency, TTFT и TTS time-to-first-byte для каждого хода. Отслеживайте 95-й перцентиль (p95), а не только медиану.
• Избегайте проблем с виртуализацией. Использование burstable-инстансов (например, AWS t3/t4g) при самостоятельной сборке агентов приводит к сбоям в таймингах распознавания речи.

Главные выводы

• Минимальный независимый TTFT на промпте 10k: Baseten с моделью gpt-oss-120b (0,23 с).
• Пропускная способность не гарантирует быстрый запуск: Mercury 2 отдает 770 tok/s, но ее TTFT составляет 3,07 с.
• Заявления вендоров о задержках TTS (75 мс у ElevenLabs, <90 мс у Cartesia) относятся только к чистой генерации модели без учета сети и буферизации.
• Параметр рассуждений существенно меняет TTFA: Gemini 3.1 Flash Live увеличивает время отклика с 0,96 с до 2,99 с при переходе от Minimal к High.
• Ключевой ориентир для голосового агента — показатель TTFS (время до первого предложения), поскольку модулю синтеза речи требуется целая смысловая фраза.

Источник: www.marktechpost.com