Почему метрика TTFT обманчива при создании голосовых ИИ-агентов
По данным MarkTechPost, стандартная метрика Time to First Token (TTFT) вводит в заблуждение при выборе API для голосовых систем, так как отмечает лишь момент начала генерации, но не готовность модели к синтезу речи.
Савелий Попов·обновлено 06 сентября 2026 г.

Бенчмарк переосмысляет метрику TTFT для голосовых агентов
Опубликован анализ, который системно разбирает задержку инференса (latency) для голосовых агентов реального времени. По данным MarkTechPost, стандартная метрика Time to First Token (TTFT) вводит в заблуждение при выборе API для голосовых систем, так как отмечает лишь момент начала генерации, но не готовность модели к синтезу речи. Это критично для разработчиков конверсационных агентов, где ощущение скорости диалога определяет UX.
TTFT — лишь часть бюджета задержки
Анализ фиксирует ключевое отличие голосового пайплайна от текстового: TTS-модель не может начать синтез, получив первые токены; ей требуется целая фраза. В результате на первый план выходит метрика Time-to-First-Sentence (TTFS). Бюджет задержки в голосовом агенте складывается из нескольких этапов. LiveKit указывает на целевую сквозную задержку (voice-to-voice) 700–1200 мс. Практический таргет, рекомендуемый соавтором фреймворка Pipecat, — 800 мс медианной задержки, с допустимым потолком в 1500 мс для прототипов. Этот бюджет разбивается приблизительно равномерно между обработкой медиа/транспортом, STT с определением конца фразы, инференсом LLM и синтезом речи. Базовый ориентир от бенчмарка Daily — человеческое время реакции в диалоге около 500 мс; паузы свыше 800 мс уже воспринимаются как неестественные. Таким образом, бюджет TTFT для текстовой LLM внутри голосового конвейера составляет около 700 мс.
Методологические нюансы бенчмарка
Интерпретация данных требует поправок. Во-первых, профиль нагрузки критичен: с марта 2026 года Artificial Analysis использует промпт на 10k входных токенов вместо 1k, что повышает TTFT и замедляет вывод — это ближе к продакшену с загруженными системными инструкциями и RAG-контекстом. Во-вторых, локация сервера фиксирована (Google Cloud us-central1), что вносит сетевую задержку в измерения TTFT. Для reasoning-моделей TTFT считается от первого reasoning-токена, а не ответного. Наконец, провайдеры могут котировать TTFT изнутри своего стека, тогда как независимые замеры ведутся от отправки запроса до получения первого пригодного токена на клиенте. Эти факторы определяют, насколько результаты конкретного бенчмарка репрезентативны для целевого кейса.
Практический вывод для пайплайна
Выбор API по TTFT в вакууме бессмысленен. Необходимо оценивать TTFS и полный latency-бюджет пайплайна с учетом реальной длины контекста и архитектуры агента. В фокусе — суммарная задержка между репликами пользователя, а не скорость первого токена от LLM. Разработчики должны бенчмаркировать свои конвейеры целиком, моделируя нагрузку, близкую к продакшену, с типичными размерами системных промптов и RAG-данных. В параллельных новостях: вышел обзор голосового компаньона Ato для пожилых людей, а Lelapa AI анонсировала генерацию голоса с акцентом на рынки Африки — примеры нишевых применений, где latency-бюджет также критичен.