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

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

Эта статья является частью моего более широкого руководства по наблюдаемости и мониторингу, где я рассматриваю основы мониторинга vs наблюдаемости, архитектуру Prometheus и лучшие практики для продакшена. Здесь мы сосредоточимся specifically на мониторинге нагрузок инференса 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) Задержка имеет два значения

• Общая задержка: время от получения запроса до возврата последнего токена.
• Межтокеновая задержка: время на токен во время декодирования (критично для потокового UX).

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

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

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

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

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

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

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

Чек-лист метрик для мониторинга инференса 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 (успех/ошибка), instance

Избегайте меток вроде:

• сырые prompt, сырые user_id, идентификаторы запросов — они увеличивают количество серий.

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

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

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

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

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

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

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

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

Заметные метрики:

• tgi_queue_size (датчик)
• tgi_request_duration (гистограмма, общая задержка)
• tgi_request_queue_duration (гистограмма)
• tgi_request_mean_time_per_token_duration (гистограмма)

Сервер llama.cpp: включите конечную точку метрик

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

Если вы запускаете 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”

Если вы запускаете несколько моделей/реплик, добавьте переименование для включения стабильной метки 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 (быстрый локальный + одноузловой)

Если вы выбираете между локальными, самоуправляемыми или облачными архитектурами инференса, ознакомьтесь с полным сравнением в моем руководстве по хостингу 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.

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

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

Настройка панели Grafana (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”

Симптомы

• Интерфейс Prometheus → Targets показывает DOWN
• “context deadline exceeded” или отказ в подключении

Чек-лист

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

Быстрый тест

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

2) Вы собираете метрики, но панели пустые

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

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

Исправление

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

3) Гистограммы процентных соотношений выглядят “плоскими” или неправильными

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

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

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

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

Симптомы

• Увеличение использования RAM Prometheus
• Ошибки “слишком много серий”

Типичная причина

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

Исправление

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

5) “У нас есть метрики, но мы не знаем, почему это медленно”

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

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

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

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

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 не доступен (всегда)

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

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

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

• Хостинг LLM в 2026 году: Локальный, самоуправляемый и облачный сравнение
• Производительность LLM в 2026 году: Бенчмарки и оптимизация

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

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

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

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