Мониторинг инференса LLM в продакшене (2026): Prometheus и Grafana для vLLM, TGI и llama.cpp

Инференс LLM выглядит как «еще один API» — до тех пор, пока не возникнут скачки задержки, не начнут накапливаться очереди, а ваши GPU не окажутся загружены по памяти на 95% без очевидной причины.

Мониторинг становится критически важным в тот момент, когда вы переходите от одноузловой конфигурации или начинаете оптимизацию пропускной способности. В этот момент традиционных метрик API недостаточно. Вам нужна видимость токенов, поведения пакетной обработки (batching), времени ожидания в очереди и давления на кэш ключей-значений (KV cache) — это настоящие узкие места современных систем LLM.

Эта статья является частью моего более широкого руководства по наблюдаемости и мониторингу, где я рассматриваю основы мониторинга и наблюдаемости, архитектуру Prometheus и лучшие практики для продакшена. Здесь мы сосредоточимся конкретно на мониторинге инференс-нагрузок LLM.

(Если вы выбираете инфраструктуру, ознакомьтесь с моим руководством по размещению LLM в 2026 году. Если вы хотите глубоко погрузиться в механику пакетной обработки, ограничения VRAM и компромиссы между пропускной способностью и задержкой, см. руководство по оптимизации производительности LLM.)

В отличие от типичных REST-сервисов, серфинг LLM определяется токенами, непрерывной пакетной обработкой, использованием кэша KV, насыщением GPU/CPU и динамикой очередей. Два запроса с одинаковым размером полезной нагрузки могут иметь радикально разную задержку в зависимости от max_new_tokens, конкурентности и повторного использования кэша.

Это руководство представляет собой практическое пошаговое руководство, ориентированное на продакшен, по созданию мониторинга инференса LLM с помощью Prometheus и Grafana:

• Что измерять (задержка p95/p99, токены/сек, длительность ожидания в очереди, использование кэша, уровень ошибок)
• Как собирать метрики /metrics от типичных серверов (vLLM, Hugging Face TGI, llama.cpp)
• Примеры PromQL для перцентилей, насыщения и пропускной способности
• Паттерны развертывания с Docker Compose и Kubernetes
• Диагностика проблем, которые проявляются только под реальной нагрузкой

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

Почему инференс LLM нужно мониторить по-другому

Традиционный мониторинг API (RPS, задержка p95, уровень ошибок) необходим, но недостаточен. Серфинг LLM добавляет дополнительные оси:

1) Задержка имеет два значения

• Задержка E2E: время от получения запроса до возврата финального токена.
• Задержка между токенами: время на генерацию токена во время декодирования (критично для UX потоковой передачи).

Некоторые серверы экспонируют обе метрики. Например, TGI экспонирует длительность запроса и среднее время на токен в виде гистограмм.

2) Пропускная способность измеряется в токенах, а не в запросах

«Быстрый» сервис, возвращающий 5 токенов, не сопоставим с тем, что возвращает 500 токенов. Ваша «RPS» часто должна быть «токенов/сек».

3) Очередь — это продукт

Если вы используете непрерывную пакетную обработку, глубина очереди — это то, что вы продаете. Отслеживание длительности ожидания в очереди и размера очереди говорит вам, соответствуете ли вы ожиданиям пользователей.

4) Давление на кэш — предвестник сбоя

Истощение (или фрагментация) кэша KV часто проявляется как внезапные скачки задержки и таймауты. vLLM экспонирует использование кэша KV в виде датчика (gauge).

Чек-лист метрик для мониторинга инференса LLM

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

Золотые сигналы (в стиле LLM)

• Трафик: запросы/сек, токены/сек
• Ошибки: уровень ошибок, таймауты, OOM (нехватка памяти), 429 (ограничение частоты)
• Задержка: длительность запроса p50/p95/p99; задержка предзаполнения vs декодирования; задержка между токенами
• Насыщение: загрузка GPU, использование памяти, использование кэша KV, размер очереди

Если вам нужна низкоуровневая видимость использования памяти GPU, температуры и загрузки вне Prometheus (для отладки или одноузловых установок), см. мое руководство по приложениям для мониторинга GPU в Linux / Ubuntu.

Для более широкого взгляда на наблюдаемость LLM за пределами метрик — включая трассировку, структурированные логи, синтетическое тестирование, профилирование GPU и проектирование SLO — см. мое подробное руководство по наблюдаемости для систем LLM.

Полезные измерения (лейблы)

Держите кардинальность лейблов низкой. Хорошие лейблы:

• model, endpoint, method (prefill/decode), status (success/error), instance

Избегайте лейблов, таких как:

• сырой prompt, сырой user_id, id запросов — это взрывает количество серий.

Экспонирование метрик: встроенные эндпоинты /metrics (vLLM, TGI, llama.cpp)

Самый простой путь: используйте метрики, которые сервер уже экспонирует.

vLLM: Prometheus-совместимый /metrics

vLLM экспонирует Prometheus-совместимый эндпоинт /metrics (через свой логгер метрик Prometheus) и публикует серверные/запросные метрики с префиксом vllm:, включая датчики, такие как количество активных запросов и использование кэша KV.

Для настройки контейнеров, совместимости с API OpenAI и настройки времени выполнения, ориентированной на пропускную способность, см. Быстрый старт vLLM: высокопроизводительный серфинг LLM.

Примеры метрик, которые вы обычно увидите:

• vllm:num_requests_running
• vllm:num_requests_waiting
• vllm:kv_cache_usage_perc

Hugging Face TGI: /metrics с гистограммами очереди и запросов

TGI экспонирует множество метрик производственного уровня на /metrics, включая размер очереди, длительность запроса, длительность ожидания в очереди и среднее время на токен.

Заметные из них:

• tgi_queue_size (gauge)
• tgi_request_duration (histogram, задержка E2E)
• tgi_request_queue_duration (histogram)
• tgi_request_mean_time_per_token_duration (histogram)

Операционная настройка — Docker, GPU, флаги запуска и сбои, которые проявляются как пустые или вводящие в заблуждение сборы — описана в TGI - Text Generation Inference - Установка, конфигурация, устранение неполадок.

Сервер llama.cpp: включение эндпоинта метрик

Сервер llama.cpp поддерживает Prometheus-совместимый эндпоинт метрик, который должен быть включен флагом (например, --metrics).

Для путей установки, ключевых флагов времени выполнения и использования сервера, совместимого с OpenAI, см. Быстрый старт llama.cpp с CLI и сервером.

Если вы запускаете llama.cpp через прокси, собирайте метрики напрямую с сервера, когда это возможно (чтобы избежать скрытия реальной задержки инференса на уровне прокси).

Конфигурация Prometheus: сбор метрик ваших серверов инференса

В этом примере предполагается:

• vLLM на http://vllm:8000/metrics
• TGI на http://tgi:8080/metrics
• llama.cpp на http://llama:8080/metrics
• интервал сбора настроен для быстрой обратной связи

prometheus.yml

global:
  scrape_interval: 5s
  evaluation_interval: 15s

scrape_configs:
  - job_name: "vllm"
    metrics_path: /metrics
    static_configs:
      - targets: ["vllm:8000"]

  - job_name: "tgi"
    metrics_path: /metrics
    static_configs:
      - targets: ["tgi:8080"]

  - job_name: "llama_cpp"
    metrics_path: /metrics
    static_configs:
      - targets: ["llama:8080"]

Если вы новичок в Prometheus или хотите более подробное объяснение конфигураций сбора, экспортеров, переназначения лейблов и правил оповещения, см. мое полное руководство по настройке мониторинга Prometheus.

Про-совет: добавьте «лейбл сервиса»

Если вы запускаете несколько моделей/реплик, добавьте переназначение лейблов, чтобы включить стабильный лейбл service для дашбордов.

relabel_configs:
  - target_label: service
    replacement: "llm-inference"

Примеры PromQL, которые можно копировать/вставлять

Скорость запросов (RPS)

sum(rate(tgi_request_count[5m]))

Для vLLM используйте его счетчики запросов (названия могут различаться в зависимости от версии), но паттерн тот же: sum(rate(<counter>[5m])).

Уровень ошибок (%)

Если у вас есть счетчики *_success, вычислите коэффициент неудач:

1 - (
  sum(rate(tgi_request_success[5m]))
  /
  sum(rate(tgi_request_count[5m]))
)

Задержка p95 для метрик гистограммы (Prometheus)

Гистограммы Prometheus — это подсчеты в баках; используйте histogram_quantile() над rate() баков. Prometheus документирует эту модель и компромиссы между гистограммой и сводкой.

histogram_quantile(
  0.95,
  sum by (le) (rate(tgi_request_duration_bucket[5m]))
)

Время ожидания в очереди p99

histogram_quantile(
  0.99,
  sum by (le) (rate(tgi_request_queue_duration_bucket[5m]))
)

Среднее время на токен (задержка между токенами)

histogram_quantile(
  0.95,
  sum by (le) (rate(tgi_request_mean_time_per_token_duration_bucket[5m]))
)

Задержка между токенами часто ограничена узкими местами декодирования и пропускной способностью памяти — темами, подробно рассмотренными в руководстве по оптимизации производительности LLM.

Глубина очереди (мгновенная)

max(tgi_queue_size)

Использование кэша KV vLLM (мгновенное)

max(vllm:kv_cache_usage_perc)

Дашборды Grafana: панели, которые действительно помогают дежурным

Grafana может визуализировать гистограммы несколькими способами (перцентили, тепловые карты, распределение баков). Grafana Labs имеет подробное руководство по визуализации гистограмм Prometheus.

Минимальная компоновка дашборда с высоким сигналом:

Строка 1 — Пользовательский опыт

1. Задержка запроса p95 (временной ряд)
2. Задержка между токенами p95 (временной ряд)
3. Уровень ошибок (временной ряд + статистика)

Строка 2 — Емкость и насыщение

4. Размер очереди (временной ряд)
5. Активные vs ожидающие запросы (стакан)
6. Использование кэша KV % (датчик)

Строка 3 — Пропускная способность

7. Запросы/сек
8. Сгенерированные токены/запрос (p50/p95)

Если у вас есть потоковая передача, добавьте панель для «задержки первого токена» (TTFT), когда это возможно.

Примеры запросов Grafana

• Панель задержки p95: запрос histogram_quantile(0.95, …) выше
• Панель тепловой карты: график скоростей баков (*_bucket) как тепловая карта (Grafana поддерживает этот подход)

Вариант развертывания 1: Docker Compose (быстрая локальная + одноузловая)

Если вы выбираете между локальной, self-hosted или облачной архитектурой инференса, см. полный разбор в моем руководстве по сравнению размещения LLM.

Создайте папку, например:

monitoring/
  docker-compose.yml
  prometheus/
    prometheus.yml
  grafana/
    provisioning/
      datasources/datasource.yml
      dashboards/dashboards.yml
    dashboards/
      llm-inference.json

docker-compose.yml

services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana:latest
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=admin
    volumes:
      - ./grafana/provisioning:/etc/grafana/provisioning
      - ./grafana/dashboards:/var/lib/grafana/dashboards
    ports:
      - "3000:3000"
    depends_on:
      - prometheus

Если вы предпочитаете ручную установку Grafana вместо Docker, см. мое пошаговое руководство по установке и использованию Grafana на Ubuntu.

Проvisioning источника данных Grafana (grafana/provisioning/datasources/datasource.yml)

apiVersion: 1
datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true

Проvisioning дашбордов (grafana/provisioning/dashboards/dashboards.yml)

apiVersion: 1
providers:
  - name: "LLM"
    folder: "LLM"
    type: file
    disableDeletion: true
    options:
      path: /var/lib/grafana/dashboards

Вариант развертывания 2: Kubernetes (Prometheus Operator + ServiceMonitor)

Если вы используете kube-prometheus-stack (Prometheus Operator), собирайте цели через ServiceMonitor.

Для компромиссов инфраструктуры между Kubernetes, одноузловым Docker и управляемыми провайдерами инференса, см. мое руководство по размещению LLM в 2026 году.

1) Экспонируйте свое развертывание инференса через Service

apiVersion: v1
kind: Service
metadata:
  name: tgi
  labels:
    app: tgi
spec:
  selector:
    app: tgi
  ports:
    - name: http
      port: 8080
      targetPort: 8080

2) Создайте ServiceMonitor

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: tgi
  labels:
    release: kube-prometheus-stack
spec:
  selector:
    matchLabels:
      app: tgi
  endpoints:
    - port: http
      path: /metrics
      interval: 5s

Повторите для сервисов vLLM и llama.cpp. Это масштабируется чисто при добавлении реплик.

3) Оповещения: правила в стиле SLO (пример)

Вот хорошие стартовые оповещения:

• Высокая задержка p95 (скорость сгорания)
• Время ожидания в очереди p99 слишком высокое (пользователи ждут)
• Уровень ошибок > 1%
• Использование кэша KV > 90% устойчиво (обрыв емкости)

Пример правила (длительность запроса p95):

- alert: LLMHighP95Latency
  expr: histogram_quantile(0.95, sum by (le) (rate(tgi_request_duration_bucket[5m]))) > 3
  for: 10m
  labels:
    severity: page
  annotations:
    summary: "TGI p95 latency > 3s (10m)"

Устранение неполадок: общие сбои Prometheus + Grafana в стеках LLM

1) Цель Prometheus «DOWN»

Симптомы

• UI Prometheus → Targets показывает DOWN
• «context deadline exceeded» или отказ в соединении

Чек-лист

• Сервер действительно экспонирует /metrics?
• Неправильный порт? Неправильная схема (http vs https)?
• Kubernetes: сервис выбирает поды? Правильно ли лейбл release в ServiceMonitor?

Быстрый тест

curl -sS http://tgi:8080/metrics | head

2) Метрики собираются, но панели пустые

Наиболее частые причины

• Неправильное имя метрики (версия сервера изменилась)
• Дашборд ожидает _bucket, но у вас только датчик/счетчик
• Интервал сбора Prometheus слишком велик для коротких окон (например, [1m] при сборе каждые 30с может быть шумным)

Решение

• Используйте Explore в Grafana для поиска префиксов метрик (например, tgi_ / vllm:)
• Увеличьте окно диапазона с [1m] → [5m]

3) Перцентили гистограмм выглядят «плоскими» или неправильными

Гистограммы Prometheus требуют правильной агрегации:

• используйте rate(metric_bucket[5m])
• затем sum by (le) (и опционально другие стабильные лейблы)
• затем histogram_quantile()

Prometheus документирует модель баков и серверный расчет перцентилей.
Руководство по визуализации гистограмм Grafana включает практические паттерны панелей.

4) Взрыв кардинальности (пик памяти Prometheus)

Симптомы

• Использование RAM Prometheus растет
• Ошибки «too many series»

Типичная корневая причина

• Вы добавили prompt, user_id или id запросов в качестве лейблов в кастомном экспортере.

Решение

• Удалите лейблы с высокой кардинальностью
• Преагрегируйте в лейблы с низкой кардинальностью (model, endpoint, status)
• Рассмотрите использование логов/трассировок для отладки на уровне запроса вместо лейблов

5) «У нас есть метрики, но нет понятия, почему это медленно»

Метрики необходимы, но иногда нужна корреляция:

• Добавьте структурированные логи с метаданными запроса (модель, количество токенов, TTFT)
• Добавьте трассировку (OpenTelemetry) вокруг вашего шлюза + сервера инференса
• Используйте примеры (exemplars) (когда поддерживается), чтобы перейти от скачка задержки к трассировке

Хороший рабочий процесс: скачок на дашборде Grafana -> клик в Explore -> сузить по instance/model -> проверить логи/трассировки за этот период.

Это следует классической модели метрики -> логи -> трассировки, описанной в руководстве по архитектуре наблюдаемости и мониторинга.

6) vLLM / странности метрик многопроцессорных систем

Если ваш стек серфинга работает в нескольких процессах, вам может потребоваться конфигурация Prometheus для нескольких процессов (зависит от того, как процесс экспонирует метрики). Документация vLLM подчеркивает экспонирование метрик через /metrics для опроса Prometheus; проверьте режим метрик сервера при развертывании.

Практический набор дашборда и оповещений на «первый день»

Если вы хотите стройную настройку, которая все еще работает в продакшене, начните с:

Панели дашборда

1. Задержка запроса p95
2. Среднее время на токен p95
3. Размер очереди
4. Длительность ожидания в очереди p95
5. Уровень ошибок
6. Использование кэша KV %

Оповещения

• Задержка запроса p95 > X в течение 10 мин
• Длительность ожидания в очереди p99 > Y в течение 10 мин
• Уровень ошибок > 1% в течение 5 мин
• Использование кэша KV > 90% в течение 15 мин
• Цель Prometheus down (всегда)

Связанные руководства по наблюдаемости

• Руководство по наблюдаемости: Prometheus, Grafana & Мониторинг продакшена
• Мониторинг Prometheus: настройка & лучшие практики
• Установка и использование Grafana на Ubuntu: полное руководство

Связанные руководства по инфраструктуре LLM

• Размещение LLM в 2026: локальное, self-hosted & облако в сравнении
• Производительность LLM в 2026: бенчмарки & оптимизация

Заключительные заметки

Prometheus + Grafana дает вам вид «всегда включено» на здоровье инференса. Как только у вас есть основы, следующие большие победы обычно приходят от:

• SLO для каждой модели / арендатора
• формирования запросов (макс. токенов, лимиты конкурентности)
• автоматического масштабирования, привязанного к времени ожидания в очереди и запасу кэша KV

Для более широкого объяснения мониторинга vs наблюдаемости, основ Prometheus и паттернов продакшена, см. мое полное руководство по наблюдаемости.