Throughput и goodput LLM: какую метрику использовать?
Автоматический перевод
Эта статья была автоматически переведена с оригинальной английской версии.
Throughput LLM измеряет, сколько работы сервер выполняет за секунду. Goodput измеряет скорость выполнения работы, которая также соответствует заданным требованиям к сервису. При выборе конфигурации сервинга используйте throughput выходных токенов вместе с числом успешных запросов в секунду, которые выполняют ваши требования к латентности первого токена и генерации.
Сервер, который генерирует больше токенов, пока запросы завершаются по тайм-ауту, может иметь более высокий throughput и меньшую полезную производительность.
Определите запрос, который соответствует требованиям
Перед тестированием определите условия, которым должен соответствовать запрос. Например: успешное завершение, TTFT ниже 500 ms и средний TPOT ниже 50 ms. Затем подсчитайте завершённые запросы, которые соответствуют этим условиям, за интервал измерения:
request goodput = qualifying completed requests / measured seconds
output throughput = generated output tokens / measured secondsЭто пример SLO и два явных определения метрик. Если за десять секунд завершаются 100 запросов, но только 60 соответствуют требованиям, throughput завершённых запросов составляет десять запросов в секунду, а goodput — шесть. Также указывайте throughput выходных токенов, поскольку длина ответов может различаться.
DistServe использует goodput для оценки сервинга с требованиями к TTFT и генерации токенов. Всегда указывайте, что вы считаете: запросы или токены, соответствующие требованиям. Само слово не определяет ни знаменатель, ни правила отбора.
Сохраняйте сопоставимый профиль нагрузки
| Что записать | Почему это влияет на результат |
|---|---|
| Длина входа и выхода | Различаются объём работы при префилле, размер кэша и длительность декодирования |
| Модель, точность, GPU и версия рантайма | Они меняют стоимость выполнения |
| Число поступающих запросов в секунду | Определяет нагрузку на очередь |
| Одновременные запросы | Меняет формирование батчей и использование памяти |
| Политика кэширования | Повторяющиеся префиксы могут уменьшить объём работы при префилле |
| Ошибки и отмены | Успешное завершение входит в полезную производительность |
При небольших батчах декодирования добавление запросов может улучшить повторное использование весов. Более крупные батчи или рост интенсивности поступления запросов со временем могут повысить латентность или превысить ограничения памяти, вычислений или обмена данными. Вид кривой зависит от профиля нагрузки; линейное масштабирование не гарантировано.
Повышайте интенсивность поступления запросов поэтапно и стройте графики throughput, goodput, латентности P99, ошибок и длины очереди. Выберите нагрузку, при которой соблюдаются требования и оставляет запас на колебания трафика. Эксперимент Anyscale с continuous batching показывает, почему для сравнения нужно указать распределение запросов.
Инженерное руководство: throughput и компромисс с латентностью объясняет этот компромисс при сервинге в контексте.