vLLM bench serve: как измерить скорость локального API

Когда нужен vllm bench serve?

Этот инструмент отправляет запросы к уже запущенному HTTP-серверу и считает успешные/ошибочные запросы, скорость обработки и задержки у клиента. Он не заменяет проверку качества модели и не даёт универсальной цифры «сколько пользователей потянет любой GPU». Сам vLLM рекомендует GuideLLM, если нужен более гибкий бенчмарк production-сервера с различными форматами нагрузки; bench serve удобен для ограниченного воспроизводимого испытания собственного стенда. s1 s2

Маршрут решения: задача и длина реальных запросов → конкретная модель/ревизия → подходящее оборудование → vLLM/API → контролируемая нагрузка → сохранённые результаты. Начните с запуска vLLM и подтвердите один обычный ответ до нагрузки; размер файла весов не определяет сам по себе необходимую память. s8

Что подготовить перед первым прогоном?

Нужны установленный vLLM совместимой версии, рабочий сервер с известным именем модели, адресом и HTTP-портом, свободное место под JSON-результат и отдельное окно без чужой производственной нагрузки. API /v1/chat/completions требует генеративную модель с корректным chat template; /v1/completions — другой маршрут, которому нужен соответствующий backend. Не направляйте этот тест на публичный платный endpoint: 40 запросов и warmup могут расходовать деньги; используйте свой локальный стенд. s1 s4 s6

Зафиксируйте версию vLLM, точный идентификатор и ревизию модели/токенизатора, параметры сервера (включая prefix cache), GPU/CPU и память, число одновременных пользователей, длины входа и выхода, seed и температуру. Авторские примеры из документации — не результат Modelium и не минимальные аппаратные требования. При сравнении конфигураций меняйте одну переменную и храните остальные неизменными. s1 s3 s5

Как запустить безопасный тест локального chat API?

Сначала запустите совместимую с вашим железом модель по инструкции vLLM на 127.0.0.1:8000; пример ниже намеренно не подменяет ваш выбор модели и не скачивает веса на машине Modelium. Получите фактическое имя сервируемой модели из /v1/models и проверьте его в переменной MODEL. Не публикуйте API в интернет ради теста: документация vLLM прямо предупреждает, что --api-key не защищает все пути на HTTP-сервере. s4 s7 s8

curl -fsS http://127.0.0.1:8000/v1/models
MODEL='вставьте-точный-id-из-v1-models'
mkdir -p bench-results
vllm bench serve \
--backend openai-chat --endpoint /v1/chat/completions \
--host 127.0.0.1 --port 8000 --model "$MODEL" \
--dataset-name random --random-input-len 256 \
--random-output-len 64 --random-range-ratio 0 \
--num-prompts 40 --num-warmups 3 --seed 42 \
--request-rate 2 --max-concurrency 2 \
--temperature 0 --ignore-eos \
--percentile-metrics ttft,tpot,itl,e2el,client_queue_time,e2el_including_client_queue \
--metric-percentiles 50,95,99 \
--save-result --result-dir bench-results

Это пример малой синтетической нагрузки, а не рекомендованная интенсивность для вашего железа. --request-rate 2 задаёт целевое поступление запросов в секунду, --max-concurrency 2 ограничивает одновременно исполняемые запросы, --num-warmups 3 отправляет отдельные разогревающие запросы. В v0.30.0 по умолчанию request-rate=inf и лимит конкурентности отсутствует: без явных параметров 40 запросов фактически запускаются волной. Параметр --ignore-eos помогает удерживать задуманные длины выходов; проверяйте фактические токены, а не считайте их равными значению флага. s1 s2 s3

random воспроизводит случайные токеновые последовательности при фиксированном seed и длинах, но не имитирует фактуру ваших русских договоров, запросов к RAG или диалогов поддержки. Для испытания собственных данных vLLM поддерживает --dataset-name custom с локальным JSONL и полем prompt, однако путь рендеринга, chat template и приватность надо проверить отдельно. Не выгружайте коммерческие или персональные данные в результат и не добавляйте --save-detailed, пока не определены доступ и срок хранения: подробный режим сохраняет ответы и ошибки отдельных запросов. s1 s2 s3

Что считать успешным результатом и как сравнивать?

Убедитесь, что Successful requests соответствует ожидаемому числу тестовых запросов, Failed requests равен нулю, а JSON сохранился в bench-results/. Смотрите фактический Request throughput (req/s), Output token throughput (tok/s), входные и выходные токены, TTFT (время до первого потокового ответа), TPOT (среднее время на выходной токен, кроме первого), ITL (промежуток между потоковыми ответами) и E2E latency. Все эти задержки измеряются клиентом, не являются внутренней GPU-телеметрией. s1 s2 s6

TPOT для отдельного запроса в документации задан формулой (полная задержка − TTFT) / (число выходных токенов − 1), когда выходных токенов больше одного. ITL измеряет промежутки между поступившими потоковыми порциями; при speculative decoding одна порция может содержать несколько токенов, поэтому ITL и TPOT нельзя автоматически считать взаимозаменяемыми. client_queue_time отделяет ожидание клиентского лимита конкурентности от работы сервера; при конечном request rate можно смотреть e2el_including_client_queue. s1 s2

Сравнивайте одну модель, ревизию, железо, входные/выходные длины, seed, cache, режим генерации и одинаковый rate/concurrency. Повторите прогон и сохраните оба JSON вместе с конфигурацией, включая число ошибок; не делайте причинный вывод из одного p95 на 40 запросах. vLLM предупреждает, что повторение одинаковых prompt может использовать prefix cache прошлого прогона и повысить throughput: при необходимости меняйте seed, перезапускайте сервер или используйте vllm bench sweep serve с очисткой кеша между прогонами. Для систематического сравнения конфигураций sweep умеет повторять комбинации и хранить результаты, но это уже отдельный эксперимент. s1 s5

Где инструмент даёт ложную уверенность?

Пустые результаты, ошибки chat template или Failed requests > 0 — причина исправить маршрут и сервер, а не объявлять высокую скорость на выборке успешных. Тестовый seed не заменяет реальные запросы; увеличение throughput при ухудшении TTFT может быть неприемлемо для интерактивного чата. В прогоне --request-rate 2 и --max-concurrency 2 клиент сам ограничивает очередь; при перегрузке фактический темп может оказаться ниже целевого. Нельзя сопоставлять p95 из разных инструментов по одному имени метрики без определения точек отсчёта. s1 s2 s3

Если цель — выбрать сервер, прочитайте сравнение SGLang и vLLM; чужие цифры на иной модели и GPU не являются вашим результатом. Если модель не помещается или сервер не отвечает, сначала проверьте запуск vLLM и аппаратные условия, а не поднимайте нагрузку. Основной следующий шаг — получить свой первый рабочий локальный ответ, затем сохранить два сравнимых JSON-прогона с указанием всех условий и ограничений. s4 s8