Latency
latency — время ожидания первого токена, следующих токенов и полного ответа
Latency описывает, сколько времени проходит от отправки запроса до результата. У потоковой языковой модели отдельно измеряют ожидание первого токена, интервалы между следующими токенами и полное время ответа. На каждую часть влияют сеть, очередь, длина входа, вычисления и текущая нагрузка.
Коротко
Latency — время ожидания результата. Для потоковой языковой модели полезно различать TTFT, задержку до первого токена; ITL или TPOT, интервал между последующими токенами; и end-to-end latency, время до полного ответа. Один показатель не заменяет остальные.
Что происходит после отправки запроса
Между нажатием кнопки и последним словом ответа есть несколько этапов:
- клиент подготавливает и отправляет запрос;
- данные проходят по сети;
- сервер проверяет запрос и ставит его в очередь;
- модель обрабатывает весь вход на этапе prefill;
- создаётся первый выходной токен;
- модель продолжает decode и выдаёт токены по одному;
- клиент получает, декодирует и отображает поток;
- завершаются дополнительные действия приложения.
Задержка любого этапа попадает в пользовательский опыт. Быстрая модель не спасает медленную сеть или длинную очередь, а быстрый сервер не сокращает время внешнего поиска и синтеза речи.
TTFT: время до первого токена
Time to First Token измеряется от отправки запроса до получения первого содержательного токена ответа.
Обычно TTFT включает:
- сетевую передачу запроса;
- проверку и маршрутизацию;
- ожидание в очереди;
- формирование пакета запросов (batch);
- разбиение текста на токены, если она выполняется на сервере;
- prefill всего входного контекста;
- вычисление первого выходного токена;
- передачу первого фрагмента клиенту.
Длинный промпт увеличивает работу prefill: модель должна обработать системные инструкции, историю, документы и текущий запрос, прежде чем начнёт decode. Точная зависимость от длины определяется архитектурой внимания, оптимизациями и аппаратурой, поэтому её нельзя свести к одной универсальной формуле.
Если ответ не передаётся потоково, пользователь не увидит первый токен сразу. Тогда наблюдаемое время начала ответа совпадает с ожиданием более крупного буфера или всего результата, хотя серверный TTFT мог быть небольшим.
У моделей с внутренним рассуждением до видимого ответа могут генерироваться служебные токены. Поиск и вызовы инструментов тоже откладывают первый полезный текст. Поэтому время до первого события API и время до первого слова, которое увидит человек, полезно измерять отдельно.
ITL и TPOT: ритм после старта
После первого токена модель переходит в последовательный decode. Каждый новый токен зависит от уже обработанного входа и предыдущего выхода.
Inter-Token Latency, или ITL, — интервал между соседними выходными токенами. Близкое название Time per Output Token, TPOT, часто используют для среднего времени на токен после первого.
Средний ITL можно записать так:
ITL = (E2E - TTFT) / (число выходных токенов - 1)
Формула применима, если выходных токенов больше одного и E2E заканчивается на последнем токене, без последующей обработки. Она исключает ожидание первого токена и описывает средний темп дальнейшей генерации. Но разные инструменты считают интервалы по-разному: учитывают или исключают сетевую доставку, пустые фрагменты потока, преобразование токенов в текст и последний служебный сигнал. Перед сравнением важно совпадение определений.
ITL влияет на ощущение потока. Даже короткий TTFT не делает ответ живым, если следующие слова приходят рывками с длинными паузами.
E2E: время до полного ответа
End-to-end latency охватывает весь путь от отправки запроса до последнего содержательного токена или завершённого результата.
Для простой потоковой генерации:
E2E = TTFT + время генерации после первого токена
Чем длиннее ответ, тем большую часть E2E занимает decode. Для короткой классификации почти всё время может приходиться на сеть, очередь и prefill. Поэтому одна и та же система выглядит по-разному на коротких и длинных задачах.
В приложении E2E иногда продолжается после модели. Форматирование, проверка схемы, выполнение инструмента, запись в базу, модерация или озвучивание добавляют собственные участки критического пути.
TPS: почему термин бывает неоднозначным
Tokens per second звучит просто, но встречается в двух смыслах.
TPS одного запроса описывает скорость, которую видит один пользователь. Для длинного выхода она близка к величине, обратной ITL.
Системный TPS — суммарное число выходных токенов всех одновременных запросов за секунду. Это уже пропускная способность сервера.
Система может повысить общий TPS объединяя запросы в пакеты и одновременно замедлить отдельного пользователя. Больше запросов делят вычислительные ресурсы, а часть из них ждёт место в очереди. Поэтому цифра «токенов в секунду» без указания нагрузки и способа расчёта мало что говорит о latency одного диалога.
Prefill и decode нагружают систему по-разному
На этапе prefill модель обрабатывает вход параллельно по множеству токенов и строит KV-кэш. Здесь особенно заметны длина промпта, скорость вычислений и пропускная способность памяти.
На этапе decode новые токены появляются последовательно. Для каждого шага модель читает веса и обращается к накопленному KV-кэш. При полном внимании с ростом ответа кэш занимает больше памяти, а модель учитывает более длинную историю. Для слоёв со скользящим окном рост ограничен размером окна; предварительно выделенный кэш может сразу занимать память под максимальную длину.
Эти различия объясняют, почему одна оптимизация улучшает TTFT, а другая — ITL. Быстрый prefill не гарантирует быстрый decode, и наоборот.
Очередь и одновременные запросы
При низкой нагрузке запрос может сразу попасть на выполнение. С ростом числа одновременных запросов сервер объединяет запросы в batch или откладывает часть из них.
Объединение запросов в пакеты может повысить загрузку устройства и общую пропускную способность. Цена — дополнительное ожидание и конкуренция за память. После насыщения системы новые запросы увеличивают очередь, а общий TPS перестаёт расти или начинает снижаться.
Поэтому измерение при одном клиенте не описывает рабочую систему. Нагрузочный профиль включает:
- частоту прихода запросов;
- число одновременных пользователей;
- длину входов и выходов;
- распределение коротких и длинных задач;
- ограничения очереди и batch;
- прогретое или холодное состояние сервера.
Сеть и география
Сетевая задержка участвует и в отправке запроса, и в доставке ответа. Для потоковой передачи важна не только первый обмен с сервером, но и стабильность соединения во время всего потока.
На неё влияют:
- физическое расстояние;
- качество маршрута;
- установка TLS-соединения;
- прокси и шлюзы;
- размер запроса;
- повторные передачи пакетов;
- буферизация на промежуточных узлах;
- способ потоковой доставки.
Пинг до региона полезен как ориентир, но не равен TTFT: очередь и prefill могут занимать гораздо больше времени.
Streaming и воспринимаемая задержка
Streaming показывает частичный результат сразу после его появления. Пользователь видит начало ответа, пока модель продолжает генерацию.
Это меняет ощущение ожидания, но не обязано сокращать вычислительное время или E2E. Иногда потоковая обработка даже добавляет небольшие накладные расходы на упаковку, передачу и отрисовку множества фрагментов.
В составных приложениях поток можно продолжить дальше. Синтез речи начинает работать по первым устойчивым фразам, интерфейс показывает найденные документы до финального вывода, а следующий этап обрабатывает уже готовую часть. Такое перекрытие сокращает критический путь продукта, хотя отдельные компоненты не стали быстрее.
Кэширование
Если несколько запросов имеют общий длинный префикс, система может повторно использовать часть уже рассчитанного KV-кэш. Это уменьшает работу prefill и часто улучшает TTFT.
Кэш не помогает произвольным разным промптам и занимает память. Его польза зависит от точного совпадения префикса, политики хранения и текущей нагрузки. Изменение системной инструкции в начале контекста способно сделать прежний кэш неприменимым.
Обычный кэш готового ответа решает другую задачу: он возвращает сохранённый результат без новой генерации. Такой ответ очень быстрый, но подходит только тогда, когда повторное использование корректно по смыслу и безопасности.
Холодный старт
Первая генерация после простоя иногда включает загрузку весов, компиляцию вычислительных операций, выделение памяти или запуск контейнера. Это создаёт редкую, но большую задержку, которой нет в прогретом тесте.
Среднее значение легко скрывает холодные старты. В пользовательском продукте полезны перцентили:
- p50 — медиана: примерно половина измеренных задержек не превышает это значение;
- p95 — граница, в которую укладываются около 95% измеренных задержек;
- p99 — аналогичная граница для 99%; для её устойчивой оценки нужна достаточно большая выборка.
Два сервиса с одинаковым средним TTFT могут сильно различаться по p95 и p99.
Как сравнивают системы
Сравнение имеет смысл при одинаковых условиях:
- одна и та же модель или сопоставимая задача;
- одинаковые длины входа и выхода;
- одинаковый формат чисел и настройки генерации;
- одинаковое число одновременных запросов или частота их поступления;
- одинаковое определение TTFT и ITL;
- одинаковое положение измеряющего клиента;
- одинаковый режим streaming;
- отделённые прогрев и основная выборка.
Замер одного запроса показывает конкретный случай, а не распределение. Для реального приложения важнее профиль, похожий на его собственный трафик.
При сравнении разных моделей одинаковое число токенов может означать разный объём текста: токенизаторы различаются. Для продуктового теста важен также результат одной и той же задачи, а не только скорость выдачи токенов.
Что обычно влияет на задержку
- размер и архитектура модели;
- точность чисел и формат весов;
- скорость памяти и вычислительных устройств;
- распределение модели между устройствами;
- длина входа и ожидаемого выхода;
- размер KV-кэш;
- объединение запросов и правила их планирования;
- очередь и предел одновременных запросов;
- сетевой путь;
- кэширование общего начала запросов;
- спекулятивное декодирование — проверка нескольких предложенных токенов за один проход основной модели;
- преобразование текста в токены и обратно;
- холодный старт;
- внешние инструменты и проверки.
Ни один фактор не объясняет результат в одиночку. Например, компактные веса уменьшают чтение из памяти, но неподдерживаемая операция может добавить распаковку и не дать ожидаемого ускорения.
С чем часто путают
- С пропускной способностью. Latency описывает время одного запроса, пропускная способность — объём работы всей системы за период.
- С TTFT. TTFT заканчивается на первом токене и не включает весь длинный ответ.
- С TPS. Скорость токенов одного потока и суммарный TPS сервера — не одно и то же.
- С временем самой модели. Пользовательская задержка также включает сеть, очередь и логику приложения.
- С качеством. Скорость и качество могут быть связаны выбором модели или точности, но одна метрика не определяет другую.
- С ощущением скорости. Streaming способен улучшить ощущение скорости без изменения времени завершения.
Частые ошибки
- Показывать только среднее. Длинный хвост задержек остаётся невидимым.
- Сравнивать TPS с разными определениями. Один тест измеряет пользователя, другой — весь сервер.
- Тестировать только короткий промпт. Реальный prefill может быть намного тяжелее.
- Игнорировать очередь. Лабораторный запрос без конкурентов не похож на пиковую нагрузку.
- Смешивать TTFT и E2E. Быстрый старт не означает быстрого полного ответа.
- Считать streaming ускорением модели. Он прежде всего раньше показывает уже готовую часть.
- Не отмечать положение клиента. Серверный таймер исключает часть сетевого пути.
- Смешивать холодные и прогретые результаты. Они отвечают на разные вопросы.
Частые вопросы
Что важнее: TTFT или ITL?
Для короткого интерактивного ответа часто заметнее TTFT. Для длинного потока важны оба показателя: быстрый старт не компенсирует медленные интервалы между токенами.
Почему длинный промпт увеличивает TTFT?
До первого ответа модель выполняет prefill всего входа и строит KV-кэш. Чем больше контекст, тем больше данных нужно обработать.
Почему latency растёт при высокой нагрузке?
Запросы ждут очередь, объединяются в batch и делят вычислительные ресурсы. После насыщения системы пропускная способность почти не растёт, а ожидание продолжает увеличиваться.
Streaming уменьшает E2E?
Сам по себе — обычно нет. Он раньше показывает частичный результат. E2E сокращается, если последующие этапы начинают полезную работу по этому потоку параллельно.
Как связаны ITL и tokens per second?
Для одного длинного потока TPS примерно обратно пропорционален среднему времени на выходной токен. Системный TPS с несколькими запросами рассчитывается иначе.
Зачем смотреть p95 и p99?
Они показывают медленные запросы, которые среднее и p50 скрывают. Именно длинный хвост часто формирует жалобы пользователей.
Можно ли измерять только на сервере?
Серверные метрики полезны для диагностики вычислений и очереди. Клиентский таймер дополнительно видит сеть, прокси, буферизацию и отрисовку — то, с чем сталкивается человек.
Главное
Latency языковой модели состоит из нескольких времён. TTFT показывает ожидание первого токена, ITL или TPOT — ритм дальнейшей генерации, E2E — путь до полного ответа. Системная пропускная способность описывает уже не одного пользователя, а общую работу сервера. Сопоставимое сравнение учитывает длину входа и выхода, число одновременных запросов, сеть, очередь, потоковую передачу и распределение задержек.
