TTFT, TPOT и throughput: как читать тесты LLM-серверов

Фраза «сервер выдаёт тысячу токенов в секунду» неполна. Это может быть суммарная скорость десятков запросов, скорость одного диалога или результат пакетного теста без ограничения задержки. Для закупки нужны определения метрик и условия измерения.

Три разных вопроса

TTFT, time to first token, показывает время до первого токена ответа. Оно может включать ожидание очереди, подготовку запроса и обработку входа в зависимости от точки измерения. TPOT, time per output token, описывает время на выходной токен после начала генерации. Throughput показывает выполненный объём за единицу времени.

MLCommons использует различные сценарии испытаний и ограничения задержки; это одна из причин, почему результаты разных сценариев нельзя смешивать. 1 vLLM отдельно публикует метрики первого токена, межтокенной задержки, очереди и полного запроса. 2

Посмотрите на опыт пользователя

Условный запрос начинает отвечать через 1 секунду и затем выдаёт ещё 199 токенов по 0,05 секунды на токен. При этих упрощённых условиях полный ответ занимает примерно 10,95 секунды. Другой сервер может начинать через 4 секунды, но завершать генерацию быстрее. Что лучше, зависит от интерфейса и задачи.

В потоковом чате ранний первый токен позволяет показать прогресс. Для API, которому нужен готовый JSON целиком, важнее время полного результата. Поэтому полезно измерять обе величины и не заменять одну другой.

Метрика	Практический смысл	Частая ошибка
TTFT	Как долго ждать начала	Не учитывать очередь
TPOT/ITL	Ритм продолжения ответа	Смешивать среднее по запросам и токенам
End-to-end	Когда готов весь результат	Сравнивать ответы разной длины
Throughput	Общий выполненный объём	Считать его скоростью каждого клиента
Error rate	Надёжность при нагрузке	Исключать ошибки из отчёта

Среднего значения недостаточно

Средняя задержка скрывает хвост распределения. Покажите p50, p95 и при достаточном числе наблюдений p99. Для малого теста экстремальные процентили могут быть нестабильными, поэтому рядом нужны объём выборки и длительность.

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

Сравнивайте одинаковые условия

В протокол включите модель и ревизию, формат весов, GPU и их число, длины входа и ответа, уровень нагрузки, ограничения контекста и версии ПО. Отдельно укажите, был ли cache прогрет и повторялись ли запросы.

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

Как сформулировать приёмку

Пример формулировки: на согласованной смеси запросов и заданном входном потоке не менее установленной доли ответов удовлетворяют критериям качества; p95 первого токена и полного ответа не превышают согласованных значений; доля ошибок ограничена. Числа определяет ваш процесс, поэтому здесь они не выдуманы.

Испытание должно продолжаться достаточно долго для оценки очереди и устойчивости. Добавьте период повышенной нагрузки и последующее восстановление. Укажите, что происходит с запросами сверх лимита: ожидают, отклоняются или маршрутизируются в резерв.

Для подготовки нагрузочного теста используйте эту структуру протокола. При аудите AI-инфраструктуры она помогает объяснить, что именно ограничивает текущий сервис и какую проблему должна решить закупка.