vLLM bench serve: как прочитать результат командного теста

vllm bench serve проверяет уже запущенный сервер заданным потоком запросов. Результат имеет смысл только вместе с моделью, входной и выходной длиной, числом обращений, режимом отправки и состоянием прогрева. Один показатель tokens/s не объясняет, как долго отдельный пользователь ждёт начала и завершения ответа.

Сначала проверьте сам endpoint

До нагрузки получите /v1/models и выполните один короткий запрос. Убедитесь, что тест обращается к нужному процессу и использует фактическое имя API. Ошибка маршрута или шаблона сообщений не должна маскироваться под плохую производительность GPU.

Командный интерфейс описан в официальном справочнике bench serve. Версия клиента теста тоже важна: набор аргументов и расчёт отчёта меняются. Сохраните вывод справки своей установки рядом с командой, чтобы другой оператор мог повторить опыт.

Задайте учебную нагрузку явно

Пример для локального проверенного сервера:

vllm bench serve \
  --backend vllm \
  --base-url http://127.0.0.1:8000 \
  --model Qwen/Qwen3-0.6B \
  --dataset-name random \
  --random-input-len 512 \
  --random-output-len 128 \
  --num-prompts 40 \
  --request-rate 2

Числа в примере задают небольшой эксперимент, а не ожидаемый результат карты. Если сервер использует псевдоним, добавьте --served-model-name ИМЯ_API, сохраняя исходную модель для токенизатора. Случайный набор токенов удобен для контролируемой длины, но не проверяет смысловое качество, реальные документы или поведение клиентского интерфейса.

Сопоставьте поток и пользовательское ожидание

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

Не усредняйте успешные запросы так, чтобы исчезли неуспешные. Если часть обращений отклонена, результат описывает неполный поток. Запишите также фактические, а не только запрошенные длины выходов: раннее завершение меняет объём выполненной работы и делает прямое сравнение некорректным.

Разведите прогрев и основной прогон

Отдельно измерьте запуск и первый запрос. Затем выполните прогрев и основной тест с одинаковыми условиями. Кеширование общего префикса, компиляция и повторное использование данных способны повлиять на повторный прогон. Описание метрик сверяйте с документацией vLLM.

Практический набор включает короткий вход с коротким выходом, длинный вход и несколько уровней потока. Не смешивайте эти режимы в одно рекламное число. Для общей структуры эксперимента пригодится методика бенчмарка, а для интерпретации — компромисс задержки и потока.

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

Используйте отчёт при обсуждении оборудования

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

Для владельца такой отчёт превращает карту в измеренный ресурс. Финансовому партнёру он позволяет оценивать расширение относительно конкретной нагрузки.