Time to First Token (TTFT)

Time to first token — задержка между отправкой запроса LLM и получением первого токена ответа. В ней доминирует фаза prefill: модель обязана обработать весь входной промпт, прежде чем сможет что-то генерировать, поэтому TTFT растёт с длиной промпта — вопрос на 50 токенов отвечается почти мгновенно, а контекст на 100 тысяч токенов может занять многие секунды до появления первого слова. TTFT измеряют отдельно от межтокенной задержки (темпа токенов после первого), и они по-разному формируют опыт пользователя: TTFT определяет, как долго интерфейс кажется зависшим, а межтокенная скорость — насколько плавным ощущается стриминг. Практические рычаги снижения TTFT: кэширование промптов (пропуск повторной обработки общего префикса), урезание извлечённого контекста, маршрутизация коротких запросов в меньшие модели и стриминг, чтобы пользователь видел вывод в момент его появления. Воспринимаемая скорость часто важнее общего времени ответа. Два уточнения удерживают TTFT от неверного прочтения. Это не то же самое, что общая задержка ответа: модель может начать быстро и всё равно долго дописывать длинный ответ, а может начать медленно и завершить стремительно — поэтому продуктовое решение, принятое по одной лишь общей задержке, часто оптимизирует не ту половину опыта. И это не чистая функция размера модели. Инфраструктурные решения — стратегия батчинга, поколение железа, доступен ли для переиспользования KV-кэш предыдущего хода — сдвигают TTFT существенно и независимо от того, какую модель вы выбрали; поэтому одна и та же модель у одного провайдера кажется вязкой, а у другого мгновенной. Практический рычаг — связь с фазой prefill: раз весь промпт должен быть обработан до появления первого токена, TTFT растёт с длиной ввода, и переиспользование кэшированного состояния префикса — самый действенный способ не платить за prefill дважды. Именно эта связь и объясняет, почему кэширование промпта и контекста существует как платная функция продукта, а не как невидимая оптимизация. Для диалоговых и голосовых интерфейсов метрика близка к решающей: пауза до появления хоть какого-то вывода читается как неотзывчивость так, как медленный, но уже начавшийся вывод не читается никогда. Поэтому ей место в ваших дашбордах задержки отдельной строкой от сквозного времени, причём измерять её стоит по высокому перцентилю, а не по среднему: восприятие функции формирует именно медленный хвост запросов. На продуктовой стороне помогают и дешёвые приёмы: показать вместо спиннера осмысленное сообщение о статусе, заранее прогреть длинный контекст в фоне или отдать первую фразу меньшей модели, передав остальное большой. Всё это улучшает воспринимаемый TTFT независимо от измеренного. Измеренная и воспринимаемая задержка — не одно и то же, а пользователь переживает только вторую.