# Goodput LLM и токены в секунду: считайте запросы в пределах цели

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

Автор: Команда Retrivium
Обновлено: 2026-11-03
Канонический URL: https://retrivium.ai/ru/journal/llm-goodput-vs-tokens-per-second/
Language: ru

Сервер способен генерировать больше токенов в секунду, но завершать меньше запросов в полезном бюджете времени. Goodput оценивает объём работы, соответствующей определённой цели сервиса. Для интерактивного LLM это часто одновременно ограничение первого токена и темпа генерации одного запроса, а не два красивых средних показателя. Без явного правила полезности само слово goodput не задаёт однозначной метрики.

## Определите успех до эксперимента

[Работа DistServe](https://arxiv.org/abs/2401.09670) рассматривает ёмкость при ограничениях задержки. Запишите правило приёмки сервиса: допустимые запросы, границы времени и необходимость успешного завершения. Разные продукты вправе использовать разные правила, если явно описывают их смысл.

Для интерактивного помощника быстрый первый токен с непригодным последующим потоком может означать провал. Пакетному извлечению данных важнее общий срок и корректный вывод. Нельзя переносить интерактивный SLO в пакетный отчёт и считать полученное число универсальной полезной ёмкостью.

## Примените условия к одному запросу

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

[Справочник benchmark сервинга vLLM](https://docs.vllm.ai/en/latest/cli/bench/serve/) содержит настройки goodput и определения метрик. Проверьте единицы и расчёт выбранного релиза. TPOT, отдельные межтокенные интервалы и полная задержка различаются: подпись критерия должна точно называть используемую величину и не подменять её похожим показателем.

## Не исключайте неуспешные обращения

Учитывайте отклонённые, просроченные, отменённые и незавершённые запросы по описанной политике. Их молчаливое удаление делает перегруженный сервис внешне эффективным. Где позволяет трасса, отделяйте намеренную отмену клиентом от ошибки обслуживания и потери связи.

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

## Найдите устойчивый режим

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

[Руководство vLLM по параллелизму](https://docs.vllm.ai/en/stable/serving/parallelism_scaling/) описывает раскладки с требующими измерения компромиссами. Сравнивайте их при равном учёте оборудования и одном правиле успеха. Высокий суммарный decode не компенсирует рост доли запросов, которые не укладываются в нужный срок.

## Публикуйте ёмкость вместе с контрактом

Укажите ревизию модели, топологию, распределения контекста и вывода, поступление, критерий успеха и продолжительность. Покажите сырой throughput рядом с goodput, а не вместо него. Оставьте достаточно временных сведений для объяснения причин неуспеха запросов.

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

## Материалы по теме

[Скорость потока и задержка: как выбрать рабочий режим GPU](/ru/journal/throughput-latency-tradeoff/), [Межтокенные паузы и throughput: не усреднять разные величины](/ru/journal/provider-intertoken-gap-throughput-metrics/).