Latency

Latency описывает, сколько времени проходит от отправки запроса до результата. У потоковой языковой модели отдельно измеряют ожидание первого токена, интервалы между следующими токенами и полное время ответа. На каждую часть влияют сеть, очередь, длина входа, вычисления и текущая нагрузка.

Коротко

Коротко. Latency — время ожидания результата. Для потоковой языковой модели полезно различать TTFT, задержку до первого токена; ITL или TPOT, интервал между последующими токенами; и end-to-end latency, время до полного ответа. Один показатель не заменяет остальные.

Что происходит после отправки запроса

Между нажатием кнопки и последним словом ответа есть несколько этапов:

1. клиент подготавливает и отправляет запрос;
2. данные проходят по сети;
3. сервер проверяет запрос и ставит его в очередь;
4. модель обрабатывает весь вход на этапе prefill;
5. создаётся первый выходной токен;
6. модель продолжает decode и выдаёт токены по одному;
7. клиент получает, декодирует и отображает поток;
8. завершаются дополнительные действия приложения.

Задержка любого этапа попадает в пользовательский опыт. Быстрая модель не спасает медленную сеть или длинную очередь, а быстрый сервер не сокращает время внешнего поиска и синтеза речи.

TTFT: время до первого токена

Time to First Token измеряется от отправки запроса до получения первого содержательного токена ответа.

Обычно TTFT включает:

• сетевую передачу запроса;
• проверку и маршрутизацию;
• ожидание в очереди;
• формирование batch;
• tokenization, если она выполняется на сервере;
• prefill всего входного контекста;
• вычисление первого выходного токена;
• передачу первого фрагмента клиенту.

Длинный промпт увеличивает работу prefill: модель должна обработать системные инструкции, историю, документы и текущий запрос, прежде чем начнёт decode. Точная зависимость от длины определяется архитектурой внимания, оптимизациями и аппаратурой, поэтому её нельзя свести к одной универсальной формуле.

Если ответ не передаётся потоково, пользователь не увидит первый токен сразу. Тогда наблюдаемое время начала ответа совпадает с ожиданием более крупного буфера или всего результата, хотя серверный TTFT мог быть небольшим.

ITL и TPOT: ритм после старта

После первого токена модель переходит в последовательный decode. Каждый новый токен зависит от уже обработанного входа и предыдущего выхода.

Inter-Token Latency, или ITL, — интервал между соседними выходными токенами. Близкое название Time per Output Token, TPOT, часто используют для среднего времени на токен после первого.

Средний ITL можно записать так:

ITL = (E2E - TTFT) / (число выходных токенов - 1)

Такая формула исключает первый токен и описывает именно decode. Но разные инструменты считают интервалы по-разному: учитывают или исключают сетевую доставку, пустые chunks, detokenization и последний служебный сигнал. Перед сравнением важно совпадение определений.

ITL влияет на ощущение потока. Даже короткий TTFT не делает ответ живым, если следующие слова приходят рывками с длинными паузами.

E2E: время до полного ответа

End-to-end latency охватывает весь путь от отправки запроса до последнего содержательного токена или завершённого результата.

Для простой потоковой генерации:

E2E = TTFT + время генерации после первого токена

Чем длиннее ответ, тем большую часть E2E занимает decode. Для короткой классификации почти всё время может приходиться на сеть, очередь и prefill. Поэтому одна и та же система выглядит по-разному на коротких и длинных задачах.

В приложении E2E иногда продолжается после модели. Форматирование, проверка схемы, выполнение инструмента, запись в базу, модерация или озвучивание добавляют собственные участки критического пути.

TPS: почему термин бывает неоднозначным

Tokens per second звучит просто, но встречается в двух смыслах.

TPS одного запроса описывает скорость, которую видит один пользователь. Для длинного выхода она близка к величине, обратной ITL.

Системный TPS — суммарное число выходных токенов всех одновременных запросов за секунду. Это уже throughput сервера.

Система может повысить общий TPS с помощью batching и одновременно замедлить отдельного пользователя. Больше запросов делят вычислительные ресурсы, а часть из них ждёт место в очереди. Поэтому цифра «токенов в секунду» без указания нагрузки и способа расчёта мало что говорит о latency одного диалога.

Prefill и decode нагружают систему по-разному

На этапе prefill модель обрабатывает вход параллельно по множеству токенов и строит KV cache. Здесь особенно заметны длина промпта, скорость вычислений и пропускная способность памяти.

На этапе decode новые токены появляются последовательно. Для каждого шага модель читает веса и обращается к накопленному KV cache. По мере роста ответа кэш занимает больше памяти, а attention работает с более длинной историей.

Эти различия объясняют, почему одна оптимизация улучшает TTFT, а другая — ITL. Быстрый prefill не гарантирует быстрый decode, и наоборот.

Очередь и одновременные запросы

При низкой нагрузке запрос может сразу попасть на выполнение. С ростом concurrency сервер объединяет запросы в batch или откладывает часть из них.

Batching повышает использование устройства и суммарный throughput. Цена — дополнительное ожидание и конкуренция за память. После насыщения системы новые запросы увеличивают очередь, а общий TPS перестаёт расти или начинает снижаться.

Поэтому измерение при одном клиенте не описывает рабочую систему. Нагрузочный профиль включает:

• частоту прихода запросов;
• число одновременных пользователей;
• длину входов и выходов;
• распределение коротких и длинных задач;
• ограничения очереди и batch;
• прогретое или холодное состояние сервера.

Сеть и география

Сетевая задержка участвует и в отправке запроса, и в доставке ответа. Для потоковой передачи важна не только первая поездка до сервера, но и стабильность соединения во время всех chunks.

На неё влияют:

• физическое расстояние;
• качество маршрута;
• установка TLS-соединения;
• прокси и шлюзы;
• размер запроса;
• повторные передачи пакетов;
• буферизация на промежуточных узлах;
• способ потоковой доставки.

Пинг до региона полезен как ориентир, но не равен TTFT: очередь и prefill могут занимать гораздо больше времени.

Streaming и воспринимаемая задержка

Streaming показывает частичный результат сразу после его появления. Пользователь видит начало ответа, пока модель продолжает генерацию.

Это меняет ощущение ожидания, но не обязано сокращать вычислительное время или E2E. Иногда потоковая обработка даже добавляет небольшие накладные расходы на упаковку, передачу и отрисовку множества chunks.

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

Кэширование

Если несколько запросов имеют общий длинный префикс, система может повторно использовать часть уже рассчитанного KV cache. Это уменьшает работу prefill и часто улучшает TTFT.

Кэш не помогает произвольным разным промптам и занимает память. Его польза зависит от точного совпадения префикса, политики хранения и текущей нагрузки. Изменение системной инструкции в начале контекста способно сделать прежний кэш неприменимым.

Обычный кэш готового ответа решает другую задачу: он возвращает сохранённый результат без новой генерации. Такой ответ очень быстрый, но подходит только тогда, когда повторное использование корректно по смыслу и безопасности.

Холодный старт

Первая генерация после простоя иногда включает загрузку весов, компиляцию kernels, выделение памяти или запуск контейнера. Это создаёт редкую, но большую задержку, которой нет в прогретом тесте.

Среднее значение легко скрывает холодные старты. В пользовательском продукте полезны перцентили:

• p50 показывает типичный запрос;
• p95 отражает медленную часть обычной нагрузки;
• p99 помогает увидеть редкие длинные хвосты.

Два сервиса с одинаковым средним TTFT могут сильно различаться по p95 и p99.

Как сравнивают системы

Сравнение имеет смысл при одинаковых условиях:

• одна и та же модель или сопоставимая задача;
• одинаковые длины входа и выхода;
• одинаковая точность и режим sampling;
• одинаковый concurrency или request rate;
• одинаковое определение TTFT и ITL;
• одинаковое положение измеряющего клиента;
• одинаковый режим streaming;
• отделённые прогрев и основная выборка.

Замер одного запроса показывает конкретный случай, а не распределение. Для реального приложения важнее профиль, похожий на его собственный трафик.

Что обычно влияет на задержку

• размер и архитектура модели;
• точность чисел и формат весов;
• скорость памяти и вычислительных устройств;
• распределение модели между устройствами;
• длина входа и ожидаемого выхода;
• размер KV cache;
• batching и scheduler запросов;
• очередь и предел concurrency;
• сетевой путь;
• prefix caching;
• speculative decoding;
• tokenization и detokenization;
• холодный старт;
• внешние инструменты и проверки.

Ни один фактор не объясняет результат в одиночку. Например, компактные веса уменьшают чтение из памяти, но неподдерживаемая операция может добавить распаковку и не дать ожидаемого ускорения.

С чем часто путают

• С throughput. Latency описывает время одного запроса, throughput — объём работы всей системы за период.
• С TTFT. TTFT заканчивается на первом токене и не включает весь длинный ответ.
• С TPS. Скорость токенов одного потока и суммарный TPS сервера — не одно и то же.
• С временем самой модели. Пользовательская задержка также включает сеть, очередь и логику приложения.
• С качеством. Скорость и качество могут быть связаны выбором модели или точности, но одна метрика не определяет другую.
• С perceived latency. Streaming способен улучшить ощущение скорости без изменения времени завершения.

Частые ошибки

• Показывать только среднее. Длинный хвост задержек остаётся невидимым.
• Сравнивать TPS с разными определениями. Один тест измеряет пользователя, другой — весь сервер.
• Тестировать только короткий промпт. Реальный prefill может быть намного тяжелее.
• Игнорировать очередь. Лабораторный запрос без конкурентов не похож на пиковую нагрузку.
• Смешивать TTFT и E2E. Быстрый старт не означает быстрого полного ответа.
• Считать streaming ускорением модели. Он прежде всего раньше показывает уже готовую часть.
• Не отмечать положение клиента. Серверный таймер исключает часть сетевого пути.
• Смешивать холодные и прогретые результаты. Они отвечают на разные вопросы.

Частые вопросы

Что важнее: TTFT или ITL?

Для короткого интерактивного ответа часто заметнее TTFT. Для длинного потока важны оба показателя: быстрый старт не компенсирует медленные интервалы между токенами.

Почему длинный промпт увеличивает TTFT?

До первого ответа модель выполняет prefill всего входа и строит KV cache. Чем больше контекст, тем больше данных нужно обработать.

Почему latency растёт при высокой нагрузке?

Запросы ждут очередь, объединяются в batch и делят вычислительные ресурсы. После насыщения системы throughput почти не растёт, а ожидание продолжает увеличиваться.

Streaming уменьшает E2E?

Сам по себе — обычно нет. Он раньше показывает частичный результат. E2E сокращается, если последующие этапы начинают полезную работу по этому потоку параллельно.

Как связаны ITL и tokens per second?

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

Зачем смотреть p95 и p99?

Они показывают медленные запросы, которые среднее и p50 скрывают. Именно длинный хвост часто формирует жалобы пользователей.

Можно ли измерять только на сервере?

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

Главное

Latency языковой модели состоит из нескольких времён. TTFT показывает ожидание первого токена, ITL или TPOT — ритм дальнейшей генерации, E2E — путь до полного ответа. Системный throughput описывает уже не одного пользователя, а общую работу сервера. Честное сравнение учитывает длину входа и выхода, concurrency, сеть, очередь, streaming и перцентили, а не сводит всё к одной красивой цифре.