Бенчмарк vLLM: воспроизведите задержку, пропускную способность и стоимость GPU перед развертыванием

Бенчмарк vLLM полезен только тогда, когда он похож на трафик, который ваше приложение действительно будет отправлять. Рекордное число токенов в секунду может скрывать медленный первый токен, перегруженную очередь или распределение промптов, которое никогда не встречается в продакшене. Это руководство предлагает воспроизводимый бенчмарк обслуживания: выберите рабочую нагрузку, варьируйте предлагаемую нагрузку, записывайте распределение задержки и пропускную способность вместе, а также сравнивайте конфигурации GPU при одинаковом целевом качестве.

Краткий ответ: Используйте vllm bench serve с закреплёнными версией vLLM и моделью на выделенном GPU-сервере. Сохраняйте неизменными модель, точность, длины промптов и выходных данных, параметры сэмплирования, состояние кэша и расположение клиента. Запустите несколько скоростей запросов, соберите TTFT, TPOT, сквозную задержку, скорость успешных запросов и выходные токены в секунду, затем выберите наименее дорогую конфигурацию, которая выполняет целевой показатель сервиса при пиковой нагрузке. Один запуск с максимальной пропускной способностью — не план ёмкости.

Что измерять в бенчмарке vLLM

Документация по бенчмаркам vLLM определяет TTFT, межтокенную задержку и TPOT по точкам их измерения. Используйте эти определения при сравнении инструментов. В частности, клиентский TTFT включает транспортные и frontend-операции; необязательные серверные метрики могут отделить ожидание планировщика от выполнения модели, но их включение добавляет накладные расходы. Отделяйте диагностические запуски от основных результатов.

Зафиксируйте корректное сравнение перед запуском

Запишите ревизию модели и токенизатор, версию vLLM, тип и количество GPU, размер tensor parallelism, флаги обслуживания, формат квантования, длину контекста и программное окружение. Используйте одинаковые промпты и целевые выходные данные для каждого кандидата. Если вы одновременно меняете модель, точность и GPU, результат не позволит определить, какое изменение помогло.

Выберите как минимум две рабочие нагрузки. Синтетическая нагрузка с фиксированной длиной полезна для контролируемых прогонов; очищенная трасса реальных длин запросов лучше подходит для решения о продакшене. Сохраняйте распределение длинных промптов, коротких ответов и всплесков. Для чат-продукта измеряйте чат- эндпоинт с соответствующим backend бенчмарка. Для нагрузки completions используйте backend completions. Не сравнивайте их показатели так, будто форматирование запросов идентично.

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

Проведите контролируемый тест обслуживания

В актуальном руководстве по CLI vLLM указана команда vllm bench serve для измерений онлайн-обслуживания, а для её зависимостей рекомендуется дополнительный пакет bench. В следующем плане используется документированный пример completions от vLLM. Замените модель и датасет ресурсами, на запуск которых у вас есть лицензия и которые подходят для вашего оборудования. Эти команды являются воспроизводимым шаблоном, а не измеренными результатами Flatkey.

python -m pip install 'vllm[bench]'
vllm serve YOUR_MODEL_ID

Во второй оболочке, после готовности сервера:

vllm bench serve \
  --backend vllm \
  --model YOUR_MODEL_ID \
  --endpoint /v1/completions \
  --dataset-name sharegpt \
  --dataset-path /path/to/ShareGPT_V3_unfiltered_cleaned_split.json \
  --num-prompts 1000 \
  --request-rate 1 \
  --save-result \
  --save-detailed

Затем повторите тест с короткой серией более высоких значений --request-rate, сохраняя остальные входные параметры неизменными. Используйте достаточно промптов, чтобы не принимать несколько запросов за распределение хвостовой задержки. Сохраняйте исходные результаты и точную команду для каждого запуска. Официальный онлайн-пример бенчмарка показывает поля вывода и объясняет, как --save-result и --save-detailed сохраняют подтверждающие данные. Для чат-запросов используйте документированный бэкенд openai-chat и эндпоинт /v1/chat/completions с датасетом и моделью, поддерживающими форматирование чата.

Не запускайте этот бенчмарк на общем production-эндпоинте без плана управления трафиком. Он намеренно создаёт нагрузку. Используйте изолированное тестовое развертывание или контролируемое окно обслуживания и фиксируйте любую фоновую работу, которая может повлиять на результат.

Перебирайте значения, пока не найдёте точку перегиба задержки

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

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

Когда запуск не достигает цели, изучите последовательность событий. Рост TTFT при увеличивающейся очереди может указывать на насыщение или контроль допуска. Низкий TPOT при стабильном времени в очереди может указывать на декодирование, пропускную способность памяти, параллелизм или неэффективный выбор точности. Если число сбоев растёт, проверьте тайм-ауты, OOM и логи сервера, прежде чем менять настройки модели. Одновременное изменение нескольких переменных скрывает причину.

Сравнивайте варианты GPU по принятой работе, а не по чистой скорости

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

GPU cost per 1,000 successful requests = hourly GPU cost ÷ successful requests per hour × 1,000

Используйте актуальную цену для точного региона и типа обязательств, а также учитывайте инфраструктуру, не связанную с GPU, или минимальные интервалы тарификации, если они важны. Сравнивайте только запуски, соответствующие вашим целевым показателям задержки и ошибок. Более дешёвая конфигурация, не проходящая p95 TTFT, не является более дешёвым способом предоставить ту же услугу.

Для первоначального облачного сравнения зафиксируйте модель и конфигурацию обслуживания, меняя только тип GPU. Затем протестируйте небольшое число изменений настройки, например параметры батча и памяти, по одному за раз. Собирайте данные об утилизации, запасе VRAM, глубине очереди, доле успешных запросов и артефакте бенчмарка. Flatkey Compute может быть одним из вариантов мощности для оценки; прежде чем использовать его в сравнении стоимости, проверьте предлагаемый GPU, регион и актуальную цену. В этом руководстве не утверждается, что какой-либо конкретный GPU всегда быстрее или дешевле.

Результат бенчмарка vLLM, который можно передать проверяющему

Для каждого запуска фиксируйте: модель и ревизию; версии vLLM и драйвера; GPU и топологию; команду и контрольную сумму датасета; распределение длины ввода/вывода; расположение клиента; политику кэширования; частоту запросов; число завершённых и неудачных запросов; p50/p95/p99 TTFT; сквозную задержку p50/p95/p99; пропускную способность выходных токенов; утилизацию GPU и VRAM; почасовую цену; стоимость на принятый запрос; а также прохождение или непрохождение заранее определённой цели.

На этом этапе также важно не упускать из виду безопасность и качество. Из промптов для бенчмарка следует удалить данные клиентов, а при сравнении квантованных моделей или разных ревизий моделей необходимо проверять качество вывода. Кажущийся прирост скорости, меняющий качество выполнения задач, не является корректным сравнением.

Распространённые вопросы

Эквивалентен ли vllm bench throughput команде vllm bench serve?

Нет. Первый предназначен для оценки пропускной способности офлайн-инференса; второй отправляет онлайн-запросы на работающий сервер и измеряет поведение обслуживания с точки зрения клиента. Используйте bench serve для планирования задержки и ёмкости при развертывании API. В справочнике CLI vLLM перечислены обе команды.

Какой показатель следует оптимизировать в первую очередь?

Начните с целевого уровня сервиса: коэффициента успеха и хвостовой задержки при ожидаемом пиковом трафике. Затем минимизируйте стоимость среди конфигураций, которые проходят критерии. Совокупная пропускная способность по токенам полезна для диагностики ёмкости, но не может заменить целевой показатель задержки, ориентированный на пользователя.

Можно ли сравнивать опубликованные результаты бенчмарков разных поставщиков?

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

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