Гайд · TNWS AI
Как найти очередь запросов vLLM по метрикам /metrics
Разделяем очередь и генерацию через метрики ожидающих запросов и времени ожидания; строим контрольный замер.
Задача и применимость
Вопрос читателя: «почему vLLM медленно отвечает очередь num requests waiting metrics». Для online serving vLLM с доступным /metrics на закрытой инфраструктуре; официальная таблица метрик актуальна на 20 сентября 2026 года. Набор метрик может меняться между версиями, закрепите их в тестах мониторинга.
Для воспроизводимости запишите фактическую версию установленного vLLM, модельный checkpoint и параметры запуска. Путь /models/your-chat-checkpoint либо /models/your-embedding-checkpoint в команде ниже — заполнитель, а не реальный файл. Наличие GPU, объём памяти и условия лицензии весов проверяются до запуска. Демонстрация не утверждает, что ответ модели заранее известен по буквам.
Проверенные возможности
Документация описывает метрики vllm:num_requests_waiting как gauge ожидающих задач и vllm:request_queue_time_seconds как histogram времени в состоянии WAITING. Показатели running, prefill и token generation позволяют не смешивать очередь с медленным декодированием. Суммарные счётчики и моментальные gauges интерпретируются по-разному.
Пошаговая процедура
- Запустите сервер и снимите базовый ответ /metrics без пользовательской нагрузки.
- Подготовьте ограниченную безопасную серию коротких запросов.
- Повторите сбор, найдите waiting и queue time, наблюдайте running.
- Сопоставьте их с клиентским временем до первого токена и общим временем ответа.
- После изменения конфигурации проведите тот же опыт при той же нагрузке.
Команда для тестового запуска на локальном адресе (подставьте законно полученный checkpoint):
vllm serve /models/your-chat-checkpoint --host 127.0.0.1 --port 8000
Готовый запрос и контроль ответа
В приведённом фрагменте используется стандартная библиотека Python и простой общий помощник для отправки JSON. Подставьте при необходимости Bearer-токен через защищённую переменную окружения и проверьте, что ваш сервер его ожидает.
import json, urllib.request
BASE = "http://127.0.0.1:8000"
def call(path, payload):
data = json.dumps(payload, ensure_ascii=False).encode("utf-8")
request = urllib.request.Request(BASE + path, data=data,
headers={"Content-Type": "application/json"}, method="POST")
with urllib.request.urlopen(request, timeout=120) as reply:
return json.load(reply)
with urllib.request.urlopen("http://127.0.0.1:8000/metrics", timeout=10) as reply:
raw = reply.read().decode("utf-8")
names = ("vllm:num_requests_waiting", "vllm:request_queue_time_seconds")
for name in names:
matching = [line for line in raw.splitlines()
if line.startswith(name) and not line.startswith("#")]
print(name, "строк:", len(matching))
if matching:
print(matching[0][:180])
Пример входа и ожидаемого результата
Вход — текстовый Prometheus-ответ от локального сервера. Ожидаемая проверка — наличие строк с именами двух метрик, либо явное сообщение об их отсутствии. Без искусственной конкурентной нагрузки значение waiting может быть нулём; это не ошибка. Конкретную задержку без запуска модели не выдумываем.
Как интерпретировать результат
Пользователь видит лишь «ответ медленный», однако причин как минимум несколько: обработка длинного входа, ожидание ресурса и генерация большого вывода. vllm:num_requests_waiting помогает обнаружить очередь в конкретный момент, а histogram request_queue_time_seconds отражает распределение длительности ожидания. Чтобы диагностировать p95, анализируйте временное окно, а не единичный снимок. Если клиентская задержка растёт, а очередь остаётся пустой, смотрите prefill и token generation, а также сетевой путь.
Развёртывание без потери контекста
Не путайте числовые типы Prometheus: gauge текущей очереди может снизиться к нулю, хотя в предыдущую минуту пользователи ждали долго. Histogram включает buckets, сумму и count, поэтому вывод первой строки — только проверка доступности, не готовый расчёт p95. Настоящую панель строят на временных рядах и корректных метках. При обновлении версии vLLM имя отдельной метрики может поменяться; сверяйте именно выпущенную документацию и проверяйте важные алерты тестовым запросом.
Проверки качества и границы метода
Нагрузочный тест делайте на тестовом контуре и не выводите из строя другие процессы. Ограничьте число одновременных клиентов, длительность и max_tokens. Сравнивайте одинаковые модели, контекст и аппаратные ресурсы до/после конфигурации; иначе вывод будет ложным. Доступ к /metrics ограничьте внутренней сетью: текст метрик может раскрывать сведения о конфигурации и шаблоне трафика. В логах нагрузки используйте синтетические запросы без персональной информации.
Если очередь есть только при пике, оцените не только среднее, но и время до первого токена для самых медленных запросов. Проследите, не выросли ли входные документы в RAG: увеличение размера контекста изменит prefill даже при неизменном числе запросов. Сначала устраните ошибочно длинные промпты и верхние лимиты ответа, затем оцените серверное масштабирование. Метрики показывают симптом, а решение определяется проверенным профилем нагрузки, не одним числом waiting.
Критерии готовности
- Отслеживаются очередь и время WAITING.
- Снимки сопоставлены с клиентскими задержками.
- Histogram не принят за одиночный gauge.
Типичные ошибки и чего не делать
- Не делать p95 из первой строки метрики.
- Не нагружать продакшен тестом без ограничений.
- Не считать пустую очередь доказательством быстрой генерации.
Частые вопросы
Что показывает num_requests_waiting?
Число ожидающих задач в момент измерения.
Что измеряет queue_time?
Время ожидания запроса в состоянии WAITING.
Достаточно ли одного снимка?
Нет, нужны временные ряды.
Официальные источники
Частые вопросы
Что показывает num_requests_waiting?
Число ожидающих задач в момент измерения.
Что измеряет queue_time?
Время ожидания запроса в состоянии WAITING.
Достаточно ли одного снимка?
Нет, нужны временные ряды.
Читайте также
Как извлечь JSON по схеме в vLLM через response_format
Схема для извлечения артикула и количества из текста: разбираем ответ и проверяем значения против исходника.
Как обработать named tool call в vLLM без произвольного выполнения кода
Требуем вызов одной безопасной функции, валидируем аргументы и не отдаём модели право запускать произвольные команды.
Как ограничить ответ vLLM вариантами choice при классификации заявок
Получаем одну из заранее разрешённых меток и отдельно проверяем, что классификация совпала с текстом обращения.
Комментарии
Пока тихо. Скажите первое слово