В этом материале
Полезная ёмкость сервинга по завершённым запросам с нужным первым токеном и темпом вывода, отдельно от сырого количества токенов в секунду.
Сервер способен генерировать больше токенов в секунду, но завершать меньше запросов в полезном бюджете времени. Goodput оценивает объём работы, соответствующей определённой цели сервиса. Для интерактивного LLM это часто одновременно ограничение первого токена и темпа генерации одного запроса, а не два красивых средних показателя. Без явного правила полезности само слово goodput не задаёт однозначной метрики.
Определите успех до эксперимента
Работа DistServe рассматривает ёмкость при ограничениях задержки. Запишите правило приёмки сервиса: допустимые запросы, границы времени и необходимость успешного завершения. Разные продукты вправе использовать разные правила, если явно описывают их смысл.
Для интерактивного помощника быстрый первый токен с непригодным последующим потоком может означать провал. Пакетному извлечению данных важнее общий срок и корректный вывод. Нельзя переносить интерактивный SLO в пакетный отчёт и считать полученное число универсальной полезной ёмкостью.
Примените условия к одному запросу
Храните результат завершения и нужные временные измерения каждого запроса. Засчитывайте запрос только при выполнении всех выбранных условий. Приемлемый первый токен одной группы и темп другой группы не означают, что хотя бы одна из них удовлетворяет совместной цели.
Справочник benchmark сервинга vLLM содержит настройки goodput и определения метрик. Проверьте единицы и расчёт выбранного релиза. TPOT, отдельные межтокенные интервалы и полная задержка различаются: подпись критерия должна точно называть используемую величину и не подменять её похожим показателем.
Не исключайте неуспешные обращения
Учитывайте отклонённые, просроченные, отменённые и незавершённые запросы по описанной политике. Их молчаливое удаление делает перегруженный сервис внешне эффективным. Где позволяет трасса, отделяйте намеренную отмену клиентом от ошибки обслуживания и потери связи.
Сохраняйте распределение длины вывода. Запросы в секунду и токены в секунду отвечают на разные вопросы при разной длине ответов. Разделите классы нагрузки, если одна конфигурация завершает преимущественно короткие задачи, а другая также обслуживает необходимые продукту длинные задачи, которые иначе исчезают из сравнения.
Найдите устойчивый режим
Постепенно увеличивайте предлагаемую работу, явно сохраняя трассу и модель поступления. Наблюдайте точку остановки роста полезных завершений и нарушения цели хвостом задержки. Одновременный всплеск и равномерное поступление нельзя публиковать как одинаковую нагрузку только по общему числу обращений.
Руководство vLLM по параллелизму описывает раскладки с требующими измерения компромиссами. Сравнивайте их при равном учёте оборудования и одном правиле успеха. Высокий суммарный decode не компенсирует рост доли запросов, которые не укладываются в нужный срок.
Публикуйте ёмкость вместе с контрактом
Укажите ревизию модели, топологию, распределения контекста и вывода, поступление, критерий успеха и продолжительность. Покажите сырой throughput рядом с goodput, а не вместо него. Оставьте достаточно временных сведений для объяснения причин неуспеха запросов.
Goodput не доказывает истинность ответа, если качество явно не включено в приёмку. Это определённая метрика полезной работы. Ясная граница делает инфраструктурный результат воспроизводимым и не позволяет спутать самый занятый момент движка с надёжной ёмкостью обслуживаемого сервиса.
Материалы по теме
Скорость потока и задержка: как выбрать рабочий режим GPU, Межтокенные паузы и throughput: не усреднять разные величины.