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

Источник: https://modelium.tech/zhurnal/vllm-bench-serve/

`vllm bench serve` отправляет запросы к уже работающему API и измеряет успешные ответы, throughput и задержки с точки зрения клиента. Для осмысленного сравнения зафиксируйте модель, оборудование, набор и длины запросов, интенсивность, конкурентность и состояние prefix cache. Синтетический тест не доказывает качество ответа или производительность на реальных русских документах.

**Проверено по документации и коду vLLM v0.30.0 на Git-коммите **`**ced6857**`**, 28 сентября 2026 года.** Modelium не запускал сервер, не загружал веса и не измерял производительность: команды ниже — протокол для вашего стенда, а не отчёт о нашем эксперименте. [s1](#src-s1) [s2](#src-s2)

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

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

Маршрут решения: **задача и длина реальных запросов → конкретная модель/ревизия → подходящее оборудование → vLLM/API → контролируемая нагрузка → сохранённые результаты**. Начните с [запуска vLLM](/zhurnal/vllm/) и подтвердите один обычный ответ до нагрузки; размер файла весов не определяет сам по себе необходимую память. [s8](#src-s8)

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

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

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

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

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

curl -fsS http://127.0.0.1:8000/v1/modelsMODEL='вставьте-точный-id-из-v1-models'mkdir -p bench-resultsvllm 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](#src-s1) [s2](#src-s2) [s3](#src-s3)

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

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

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

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

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

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

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

Если цель — выбрать сервер, прочитайте [сравнение SGLang и vLLM](/zhurnal/sglang-ili-vllm/); чужие цифры на иной модели и GPU не являются вашим результатом. Если модель не помещается или сервер не отвечает, сначала проверьте [запуск vLLM](/zhurnal/vllm/) и [аппаратные условия](/zhurnal/videokarta-dlya-llm/), а не поднимайте нагрузку. Основной следующий шаг — получить **свой первый рабочий локальный ответ**, затем сохранить два сравнимых JSON-прогона с указанием всех условий и ограничений. [s4](#src-s4) [s8](#src-s8)

## Источники

1. [vLLM v0.30.0 — Benchmark CLI](https://github.com/vllm-project/vllm/blob/ced6857afa0ea7b2e3f0846a62e1394e90f15607/docs/benchmarking/cli.md) — получено 2026-09-28
2. [vLLM v0.30.0 — bench serve CLI implementation](https://github.com/vllm-project/vllm/blob/ced6857afa0ea7b2e3f0846a62e1394e90f15607/vllm/benchmarks/serve.py) — получено 2026-09-28
3. [vLLM v0.30.0 — benchmark datasets implementation](https://github.com/vllm-project/vllm/blob/ced6857afa0ea7b2e3f0846a62e1394e90f15607/vllm/benchmarks/datasets/datasets.py) — получено 2026-09-28
4. [vLLM v0.30.0 — OpenAI-compatible serving API](https://github.com/vllm-project/vllm/blob/ced6857afa0ea7b2e3f0846a62e1394e90f15607/docs/serving/online_serving/openai_compatible_server.md) — получено 2026-09-28
5. [vLLM v0.30.0 — parameter sweeps](https://github.com/vllm-project/vllm/blob/ced6857afa0ea7b2e3f0846a62e1394e90f15607/docs/benchmarking/sweeps.md) — получено 2026-09-28
6. [vLLM v0.30.0 — benchmark endpoint request implementation](https://github.com/vllm-project/vllm/blob/ced6857afa0ea7b2e3f0846a62e1394e90f15607/vllm/benchmarks/lib/endpoint_request_func.py) — получено 2026-09-28
7. [vLLM v0.30.0 — security guidance](https://github.com/vllm-project/vllm/blob/ced6857afa0ea7b2e3f0846a62e1394e90f15607/docs/usage/security.md) — получено 2026-09-28
8. [vLLM v0.30.0 — server quickstart](https://github.com/vllm-project/vllm/blob/ced6857afa0ea7b2e3f0846a62e1394e90f15607/docs/getting_started/quickstart.md) — получено 2026-09-28