Prefill — работа модели над входным контекстом, клиентский TTFT — наблюдаемый интервал до начала выхода. Очередь, передача и доставка первого результата могут увеличить TTFT без изменения времени prefill.
Практический смысл
Почему это важно
Человек замечает паузу до начала ответа раньше, чем общую скорость генерации. Быстрый prefill в изоляции ещё не обещает быстрый первый токен через очередь, сеть и потоковый интерфейс. Для сравнения систем нужны одинаковые события, нагрузка и обработка неуспешных запросов.
Доказательная часть
Что подтверждено
В клиентском договоре TTFT считают по одному монотонному времени: от начала отправки запроса до наблюдения первого учитываемого сгенерированного токена. Начало после приёма на сервере или конец на первом сетевом байте задают уже другую метрику.
Граница применимости: Явно выбранный договор измерения по принципу SLO и клиентского benchmark; не универсальная спецификация любого счётчика с именем TTFT.
Если отсчёт начинается в клиенте до отправки и заканчивается на первом выходном токене, в него попадают передача запроса, ожидание допуска, обработка входа и путь доставки начала ответа. Серверное время prefill не охватывает весь этот интервал.
Граница применимости: Вывод для указанных клиентских границ; очереди и фазы могут частично перекрываться, поэтому их локальные таймеры нельзя без проверки просто сложить.
HTTP-заголовок, служебное потоковое событие и первый байт соединения не подтверждают появление токена ответа. Если клиент видит только текстовые порции, отчёт должен назвать метрику временем до первой содержательной порции и раскрыть, как она сопоставляется с токенами.
Граница применимости: Вывод для потокового клиента; границы network chunk, события протокола и токена модели не объявляются одинаковыми.
Загрузка модели, прогрев используемого пути и повторное использование уже обработанного префикса задают разные условия первого ответа. Сравнение холодного запуска одной системы с прогретой другой не изолирует скорость обработки нового запроса.
Граница применимости: Вывод для явно описанного состояния runtime и кэша; наличие prefix cache у конкретного движка не предполагается и должно быть подтверждено отдельно.
Средний TTFT не показывает хвост ожидания. Вместе с выбранными перцентилями и окном нужно сообщать число запросов, не давших первого ответа: тихое исключение таймаутов делает успешную часть выборки похожей на весь сервис.
Граница применимости: Вывод для пользовательского SLO; неуспешные запросы учитывают отдельным исходом, а не выдуманным конечным значением задержки.
Когда следующий запрос отправляется лишь после завершения предыдущего, генератор нагрузки сам ограничивает поступление работы. Такой тест не заменяет испытание заданного потока независимых поступлений, при котором очередь и TTFT могут расти.
Граница применимости: Вывод о сравнении замкнутого и независимого поступления запросов; фиксируются закон поступления, интенсивность и предел клиентов, а не только среднее requests/s.
Низкий TTFT говорит только о начале вывода в выбранной точке наблюдения. Он не ограничивает паузы следующих токенов и время завершения всего ответа; эти условия нужно измерять и принимать отдельно.
Граница применимости: Вывод для потокового пользовательского SLO; заданные длины и правила окончания ответа одинаковы у сравниваемых систем.
Граница терминов
Не путать
TTFT измеряет ожидание первого результата, ITL — интервалы последующего вывода. Быстрый старт и ровное продолжение требуют разных наблюдений; одна метрика не подменяет другую.
Перед спецификацией
Что проверить
- Запишите точные события начала и конца TTFT и место их регистрации.
- Используйте один монотонный таймер для обеих клиентских отметок.
- Отделите первый токен или содержательную порцию от заголовков и служебных событий.
- Укажите состояние модели, прогрева и кэша префиксов перед серией запросов.
- Фиксируйте входные длины, темп поступления запросов и конкурентность.
- Публикуйте распределение TTFT и отдельно ошибки, таймауты и отмены.
- Проверьте ITL и время полного ответа тем же клиентом и на той же нагрузке.
Открытые основания
Первоисточники
vLLM online serving benchmark: benchmark_serving.py
vLLM Project · репозиторий vLLM, тег v0.5.4, страница открыта 7 сентября 2026 года
Открыт редактором 7 сентября 2026 года, заголовок документа сверен. Клиентские метрики; точные timestamps, chunks и знаменатели проверить в этой версии и её request adapter.
Открыть первоисточникService Level Objectives
Google Site Reliability Engineering · Site Reliability Engineering, Chapter 4
Определяет SLI, SLO и SLA и объясняет user-centric latency, error rate, throughput и percentiles.
Открыть первоисточникOrca: A Distributed Serving System for Transformer-Based Generative Models
USENIX · USENIX OSDI 2022, страница открыта 7 сентября 2026 года
Открыт редактором 7 сентября 2026 года, заголовок документа сверен. Iteration-level scheduling и selective batching; результат статьи не переносится на любой движок.
Открыть первоисточникTransformers 4.44.2: Generation
Hugging Face · документация Hugging Face Transformers v4.44.2, страница открыта 7 сентября 2026 года
Открыт редактором 7 сентября 2026 года, заголовок документа сверен.
Открыть первоисточникCUDA C++ Programming Guide
NVIDIA · CUDA C++ Programming Guide, CUDA 12.6, страница открыта 7 сентября 2026 года
Открыт редактором 7 сентября 2026 года, заголовок документа сверен.
Открыть первоисточникEfficient Memory Management for Large Language Model Serving with PagedAttention
Woosuk Kwon и соавторы · arXiv:2309.06180, страница открыта 7 сентября 2026 года
Открыт редактором 7 сентября 2026 года, заголовок документа сверен.
Открыть первоисточникHistograms and Summaries
Prometheus · Prometheus documentation, проверено 29 августа 2026 года
Определяет quantiles/percentiles, histogram buckets и ограничения aggregation precomputed quantiles.
Открыть первоисточник