Настройка мониторинга latency AI-инференса
Пользователь отправляет запрос к LLM и ждёт первый токен. Если TTFT превышает две секунды, UX резко падает — клиенты уходят. Мы, MLOps-инженеры с опытом работы с vLLM и TGI, настраиваем мониторинг latency под ключ: от сбора метрик до алертов в Grafana. Пишите — оценим ваш проект.
Что такое P50, P95, P99 latency и как их интерпретировать?
Latency LLM-инференса измеряется в перцентилях. P50 — медианная задержка, P95 — 95% запросов быстрее этого значения, P99 — 99%. Для real-time сервисов критичен P99, для batch — достаточно P95. Пример: если P99 total latency > 30s, 1% пользователей испытывают недопустимую задержку. Мониторинг перцентилей позволяет выявить выбросы и long-tail.
| Перцентиль | Назначение | Типичный порог |
|---|---|---|
| P50 | Медианное качество | < 2s для TTFT |
| P95 | Большинство пользователей | < 5s для TTFT |
| P99 | Граничные случаи | < 10s для TTFT |
Проблемы, которые решаем
Latency LLM-инференса складывается из трёх компонентов: Queuing time (время в очереди рантайма), Prefill time (обработка входного контекста) и Decode time (генерация токенов). Каждый требует своей метрики и порога алерта. Например, при длинных системных промптах prefill time растёт, и нужно кэширование KV-cache. Сравнение: vLLM с PagedAttention снижает decode latency до 2 раз по сравнению с наивной реализацией.
Почему мониторинг TTFT критичен для LLM-сервисов?
TTFT — первый сигнал проблем с инференсом. Если p50 TTFT > 1s, пользователи массово покидают сервис. Мы настраиваем алерты на p95 > 3s. Эмпирически: при TTFT > 5s падение конверсии достигает 40%.
Как настроить алерты на P99 latency в Grafana?
Используем Prometheus Alertmanager с правилами на основе histogram_quantile. Пример алерта:
- alert: LLMHighTTFT expr: histogram_quantile(0.95, rate(llm_time_to_first_token_seconds_bucket[5m])) > 3 for: 5m annotations: summary: "TTFT p95 > 3 секунды" - alert: LLMHighTotalLatency expr: histogram_quantile(0.99, rate(llm_total_latency_seconds_bucket[5m])) > 30 for: 5m annotations: summary: "Total latency p99 > 30 секунд" Как мы это делаем: стек и конфиги
Ключевой инструмент — гистограммы Prometheus. buckets подбираются под типичную latency:
from prometheus_client import Histogram, Summary import time # Гистограммы latency TTFT_HISTOGRAM = Histogram( "llm_time_to_first_token_seconds", "Time to first token", buckets=[0.1, 0.3, 0.5, 1.0, 2.0, 5.0, 10.0] ) TOTAL_LATENCY = Histogram( "llm_total_latency_seconds", "Total request latency", labelnames=["model", "endpoint"], buckets=[0.5, 1.0, 2.0, 5.0, 10.0, 30.0, 60.0] ) TPOT_HISTOGRAM = Histogram( "llm_time_per_output_token_ms", "Time per output token in milliseconds", buckets=[5, 10, 20, 50, 100, 200] ) class LatencyTracker: def track_streaming_request(self, request_id: str, model: str): start = time.time() first_token_time = None def on_first_token(): nonlocal first_token_time first_token_time = time.time() TTFT_HISTOGRAM.observe(first_token_time - start) def on_complete(total_tokens: int): end = time.time() total_latency = end - start TOTAL_LATENCY.labels(model=model, endpoint="/v1/chat").observe(total_latency) if first_token_time and total_tokens > 1: decode_time = end - first_token_time tpot_ms = (decode_time / (total_tokens - 1)) * 1000 TPOT_HISTOGRAM.observe(tpot_ms) return on_first_token, on_complete Дополнительно собираем метрики vLLM: vllm:time_to_first_token_seconds, vllm:time_per_output_token_seconds, vllm:e2e_request_latency_seconds — они уже разбиты по percentiles.
Сравнение типов метрик
| Метрика | Что измеряет | Типичные buckets | Рекомендуемый алерт |
|---|---|---|---|
| TTFT | Время до первого токена | [0.1,0.3,0.5,1,2,5,10] | p95 > 3s |
| TPOT | Время на токен (ms) | [5,10,20,50,100,200] | p99 > 200ms |
| Total | Полное время запроса | [0.5,1,2,5,10,30,60] | p99 > 30s |
Сравнение runtime: vLLM vs TGI
| Параметр | vLLM | TGI |
|---|---|---|
| TTFT (p50) | ~0.3s | ~0.5s |
| Decode speed | До 2x быстрее | Стабильный |
| Поддержка LoRA | Да | Да |
| Мониторинг | Встроенные метрики | Prometheus exporter |
Что входит в работу
- Документация по всем настроенным метрикам и дашбордам.
- Код дашбордов Grafana (экспорт в JSON).
- Инструкция по деплою и алертам.
- Обучение команды: как читать дашборды и реагировать на алерты.
- Пост-релизная поддержка 2 недели.
Сроки ориентировочно
От 5 до 15 рабочих дней в зависимости от сложности инфраструктуры и количества моделей.
Типичные ошибки
Подробнее о типичных ошибках
- Использование Summary вместо Histogram — невозможно вычислить p99.
- Игнорирование queuing time — рост QPS маскируется под prefill.
- Неправильный выбор buckets: слишком широкие -> потеря точности, слишком узкие -> кардинальность.
Детекция деградации инференса: скользящие окна и аномалии
Разовый выброс latency — не повод для паники. Устойчивый тренд — повод для действий. Мы настраиваем детекцию деградации через скользящие окна:
- 7-дневное vs 30-дневное окно: если средний p95 TTFT за неделю вырос на 30% относительно месяца — автоматический алерт уровня warning.
- Почасовые аномалии: isolation forest на метриках каждого часа выявляет аномальные периоды (рост после деплоя новой версии модели, деградация при смене батч-размера).
- Корреляция с метриками GPU: при росте TTFT проверяем GPU utilization и memory. Рост latency + низкий GPU utilization = проблема в очереди. Рост latency + высокий GPU memory = модель не помещается.
Автоматическая корреляция этих метрик позволяет находить первопричину инцидента в 5 раз быстрее ручного анализа.
Мы гарантируем SLA: время отклика алертов — не более 30 секунд. Опыт нашей команды — 5+ лет в MLOps, более 20 проектов по мониторингу inference. Сертифицированные специалисты AWS и GCP. Получите консультацию — оценим ваш проект. Закажите аудит мониторинга — мы подготовим план.