Наблюдаемость систем LLM: метрики, трассировка, логи и тестирование в продакшене

Системы LLM терпят неудачи способами, которые традиционный мониторинг API не может выявить — очереди заполняются бесшумно, память GPU насыщается задолго до того, как CPU выглядит занятым, а задержки взрываются на уровне пакетирования, а не на уровне приложения. Это руководство охватывает стратегию наблюдаемости для инференса LLM и приложений LLM:

что измерять, как инструментировать с помощью Prometheus, OpenTelemetry и Grafana, и как развернуть телеметрическую трубу на масштабе.

TL;DR (Исполнительное резюме)

Системы LLM деградируют способами, которые классический мониторинг «задержка HTTP + уровень ошибок» не может объяснить. Производственная Наблюдаемость для систем LLM должна быстро и обоснованно отвечать на следующие вопросы:

• Ухудшается ли пользовательский опыт (хвостовая задержка, время до первого токена, задержка между токенами, ошибки и аборты).
• Где тратится время (очереди vs пакетирование vs выполнение модели; извлечение/инструменты/фильтры безопасности vs инференс).
• Что насыщается первым (использование GPU и давление памяти, давление KV-кэша/очереди, CPU токенизация).
• Как дрейфуют затраты и емкость (токены на запрос, токены/сек на GPU, частота попаданий в кэш, бесполезные генерации).
• Безопасно ли хранить телеметрию (промпты могут содержать ПДн; предотвращение утечки конфиденциальной информации в логи/атрибуты).

Наиболее устойчивый дизайн — это многосигнальная труба:

• Метрики для быстрого обнаружения и планирования емкости (Prometheus + PromQL; опциональное долгосрочное хранение через Thanos/Cortex/Mimir/VictoriaMetrics).
• Трейсы для причинно-следственной связи на уровне запросов (OpenTelemetry с OTLP; бэкенды такие как Tempo/Jaeger/Zipkin/Elastic APM).
• Логи для контекста, связанного с трейсами (Loki/Elastic/OpenSearch), разработанные для низкокардинальных метаданных.
• Профилирование для горячих точек CPU/памяти и хвостовой задержки (Grafana Pyroscope).
• Синтетические + нагрузочные тесты для обнаружения регрессий до того, как это сделают пользователи (Grafana k6; проба в стиле blackbox).
• SLOs для измерения пользовательских результатов и обеспечения действующих оповещений (бюджеты ошибок; стиль скорости сгорания).

Что делает наблюдаемость для систем LLM особенной

Примечание по охвату: целевой фреймворк LLM не указан. Примеры в этой статье охватывают распространенные серверы/фреймвормы (Triton, vLLM, TGI, LangChain/LangSmith) и остаются применимыми к другим стекам при замене эквивалентных метрик и спанов.

LLM вводят операционные поведения, которые отличаются от традиционных веб-сервисов:

• Переменная работа на запрос: количество токенов (вход/выход) сильно варьируется, поэтому «запросов в секунду» может выглядеть стабильно, в то время как пропускная способность токенов рушится. TGI и vLLM явно экспортируют телеметрию, связанную с токенами и задержками токенов, для поддержки этого стиля мониторинга.
• Очереди + непрерывное пакетирование: пропускная способность зависит от дисциплин пакетирования/очередей; размер очереди и размер пакета становятся первоклассными индикаторами (TGI предоставляет оба).
• Потоковый UX: пользователей интересует TTFT и задержка между токенами не менее, чем полное время ответа; OpenTelemetry даже стандартизирует метрики серверного TTFT/времени на токен под семантическими конвенциями GenAI.
• Давление на GPU доминирует в режимах отказов: использование GPU и память GPU (включая использованную память) являются центральными для надежности; экспортер DCGM от NVIDIA существует специально для предоставления телеметрии GPU на конечной точке Prometheus /metrics.
• Многоступенчатые конвейеры: извлечение, вызовы инструментов, фильтры безопасности и постобработка означают, что конечная задержка является композицией нескольких спанов/очередей — что делает распределенное трассирование и тщательный дизайн метрик обязательными.

Конкретные примеры из популярных серверов инференса подчеркивают это:

• NVIDIA Triton Inference Server предоставляет метрики в виде обычного текста через /metrics (обычно :8002/metrics) и предоставляет флаги для включения/отключения метрик и выбора порта метрик.
• vLLM предоставляет обширную конечную точку Prometheus /metrics с префиксом vllm:; его документация включает счетчики для токенов генерации и гистограммы, такие как время до первого токена.
• Hugging Face TGI документирует конечную точку /metrics с размером очереди, размером пакета, общей длительностью запроса, сгенерированными токенами и длительностью очереди.

Основные задачи наблюдаемости и необходимая телеметрия LLM

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

Метрики: Для систем онлайн-сервиса руководство по инструментации Prometheus выделяет количество запросов, ошибки и задержки как ключевые метрики; LLM расширяют это с TTFT, пропускной способностью/задержкой на токен, длиной очереди, размером пакета и использованием GPU.

Трейсы: Трейсы — это способ атрибуции задержек и сбоев на этапах извлечения/инструментов/безопасности/инференса; OpenTelemetry рассматривает трейсы/экспортеры как вендор-нейтральный способ эмиссии и отправки телеметрии в коллекторы или бэкенды.

Логи: Логи предоставляют человеко-читаемый контекст и «почему», но остаются применимыми на масштабе только если вы избегаете индексации неограниченных значений (пример: Loki индексирует только метки и хранит сжатые фрагменты логов в объектном хранилище).

Профилирование: Непрерывное профилирование захватывает поведение CPU/памяти в производстве с низконагрузочным выбором; Grafana Pyroscope специально позиционируется для этого.

Синтетические тесты и нагрузочные тесты: Grafana k6 — это инструмент нагрузочного тестирования с открытым исходным кодом, и Grafana отмечает, что Синтетический Мониторинг работает на основе k6 и выходит за рамки простых проверок протокола.

SLOs: Руководство Google SRE определяет SLO как целевое значение/диапазон для уровня обслуживания, измеряемого SLI, и предоставляет рекомендации по оповещению на основе SLOs (торговые компромиссы точности/полноты/времени обнаружения).

Ключевая схема метрик LLM

Семантические конвенции GenAI OpenTelemetry для стандартизации

OpenTelemetry предоставляет семантические конвенции GenAI (статус: «Разработка») со стандартными именами для метрик GenAI, такими как:

• gen_ai.client.token.usage и gen_ai.client.operation.duration
• gen_ai.server.request.duration, gen_ai.server.time_per_output_token, и gen_ai.server.time_to_first_token

Эта стандартизация является практическим рычагом для переносимых стратегий «мониторинг моделей LLM с OpenTelemetry»: эмитируйте один раз и маршрутизируйте ту же телеметрию в OSS или вендорские бэкенды позже.

Проектирование телеметрической трубы

Pull vs push

Prometheus — это pull-first. Процессы предоставляют метрики в поддерживаемом формате экспозиции, и Prometheus собирает их в соответствии с настроенными задачами сбора.

Push — для исключений. Руководство Prometheus «Когда использовать Pushgateway» явно рекомендует Pushgateway только в ограниченных случаях (не как общую замену push), и README Pushgateway подчеркивает, что он не может «превратить Prometheus в систему мониторинга на основе push».

LLM-специфичная практическая модель:

• Используйте pull для серверов инференса/экспортеров (конечные точки метрик Triton/vLLM/TGI; экспортер DCGM; метрики узлов).
• Используйте OTLP push для трейсов/логов/метрик OTel (OpenTelemetry Protocol определяет транспорт/кодирование/доставку между источниками, коллекторами и бэкендами).
• Используйте удаленное записывание, когда масштабируете за пределы одного Prometheus (Prometheus предоставляет руководство по настройке удаленного записывания; Mimir/Thanos/Cortex предоставляют долгосрочное и/или HA-хранение).

Агент vs sidecar vs gateway коллекторы

OpenTelemetry документирует шаблон развертывания агента, где телеметрия отправляется в Collector, работающий рядом с приложением или на том же хосте (sidecar/DaemonSet), а затем экспортируется.

Для Kubernetes sidecar-инъекция поддерживается через OpenTelemetry Operator (инъекция на основе аннотаций).

Прагматическое правило большого пальца для стеков LLM:

• Используйте DaemonSet agent для обогащения на уровне хоста и общих труб для многих подов.
• Используйте sidecar, когда вам нужна строгая изоляция на уровне рабочей нагрузки или локальное фильтрование (обычно, когда промпты могут содержать конфиденциальные данные).
• Используйте gateway коллектор для централизованного хвостового выборки, пакетирования, повторных попыток и экспорта веером.

Выборка и контроль кардинальности

OpenTelemetry уточняет, что хвостовая выборка позволяет принимать решения о выборке на основе критериев, полученных из трейса (невозможно с использованием только головной выборки).

Руководство по инструментации Prometheus предупреждает против чрезмерного использования меток, предоставляет правило большого пальца для поддержания низкой кардинальности и рекомендует перепроектировать метрики, если потенциальная кардинальность превышает ~100.

LLM-специфичные «ловушки кардинальности», которые нужно запретить с самого начала:

• Текст промптов, текст ответов, идентификаторы разговоров, идентификаторы запросов как метки/атрибуты.
• Аргументы инструментов в виде блобов как атрибуты спанов.
• Неограниченные метки «user_id».

Предпочитайте ограниченные измерения: model, model_family, endpoint, region, status_code, deployment, tenant (только если ограничен).

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

Инструменты, сопоставленные с задачами наблюдения

Grafana vs альтернативы для визуализации

• Панели Grafana состоят из элементов, которые запрашивают источники данных (включая Loki и Mimir) для создания графиков и визуализаций.
• Kibana предоставляет панели/визуализации в качестве интерфейсного слоя в составе Elastic Stack.
• OpenSearch Dashboards предоставляет инструменты визуализации данных для OpenSearch.
• Документация InfluxData позиционирует Chronograf как компонент визуализации в экосистеме Influx.

Prometheus vs альтернативы для бэкендов метрик

• Локальное хранилище Prometheus по умолчанию: если флаги сохранения не установлены, сохранение по умолчанию составляет 15 дней (планируйте сохранение/стоимость заранее).
• Grafana Mimir описывается как горизонтально масштабируемое, HA, многотенантное долгосрочное хранилище для метрик Prometheus и OpenTelemetry.
• Thanos описывается как высокодоступная настройка Prometheus с возможностями долгосрочного хранения.
• Cortex описывает себя как горизонтально масштабируемое, HA, многотенантное долгосрочное решение для хранения метрик Prometheus и OpenTelemetry.
• VictoriaMetrics Cloud документирует интеграцию Prometheus remote write для долгосрочного хранения.
• Amazon Managed Service for Prometheus описывает управляемое предложение, которое масштабируется в соответствии с потребностями ввода/вывода и поддерживает PromQL и удаленную запись.

Практическое руководство по реализации

Имена и типы метрик для внедрения сегодня

Семантические конвенции GenAI OpenTelemetry (статус: Разработка) определяют имена метрик, на которых можно стандартизироваться немедленно:

• gen_ai.client.token.usage
• gen_ai.client.operation.duration
• gen_ai.server.request.duration
• gen_ai.server.time_per_output_token
• gen_ai.server.time_to_first_token

Примеры серверной стороны, которые можно сканировать сразу:

• Prometheus-конечная точка vLLM включает счетчики (например, общее количество токенов генерации) и гистограммы (TTFT) и документирует стратегию меток model_name.
• TGI документирует метрики, включая размер очереди, длительность запроса, сгенерированные токены и среднее время на токен.
• Triton документирует экспозицию /metrics и переключатели метрик.

Примеры PromQL для панелей задержки и пропускной способности LLM

# p95 конечная задержка для гистограммы приложения
histogram_quantile(
  0.95,
  sum(rate(llm_request_latency_seconds_bucket[5m])) by (le, model)
)

# Процент ошибок (5xx)
100 *
(
  sum(rate(llm_requests_total{status_code=~"5.."}[5m]))
  /
  sum(rate(llm_requests_total[5m]))
)

# Токены/сек (выход) по всем моделям
sum(rate(llm_tokens_total{direction="out"}[5m]))

# Размер очереди TGI (измеритель)
max(tgi_queue_size) by (instance)

# vLLM TTFT p95
histogram_quantile(
  0.95,
  sum(rate(vllm:time_to_first_token_seconds_bucket[5m])) by (le, model_name)
)

Руководство Prometheus по гистограммам объясняет, что квантили гистограмм вычисляются на сервере из корзин с использованием histogram_quantile().

Примечания по инструментации OpenTelemetry для систем LLM

• OTLP - это протокол OpenTelemetry, который определяет, как телеметрия кодируется/передается между источниками, коллекторами и бэкендами.
• Конфигурация SDK OpenTelemetry документирует переменные окружения, такие как OTEL_EXPORTER_OTLP_ENDPOINT (и варианты протокола) для экспорта телеметрии.
• OpenTelemetry Python contrib документирует поддержку инструментации FastAPI для автоматической и ручной инструментации.
• Семантические конвенции GenAI включают механизм опциональной стабильности через OTEL_SEMCONV_STABILITY_OPT_IN для миграции конвенций GenAI.

Короткий пример на Python: метрики + трассировки + логи

Нижеприведенный фрагмент демонстрирует:

• Экспозицию метрик Prometheus (/metrics) для “мониторинга LLM-инференса с Prometheus”
• Трассировки OpenTelemetry, экспортируемые через OTLP (нейтральные к поставщику)
• Структурированные логи, коррелированные с контекстом трассировки, с безопасным по умолчанию режимом (не логируйте сырые запросы)

import logging
import time

from fastapi import FastAPI, Request
from pydantic import BaseModel

# Prometheus (метрики pull-based)
from prometheus_client import Counter, Histogram, generate_latest, CONTENT_TYPE_LATEST
from starlette.responses import Response

# OpenTelemetry (трассировки OTLP)
from opentelemetry import trace
from opentelemetry.instrumentation.fastapi import FastAPIInstrumentor
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter

app = FastAPI(title="LLM Inference API", version="1.0.0")
FastAPIInstrumentor.instrument_app(app)

# --- Логирование (безопасный по умолчанию) ---
logger = logging.getLogger("llm")
logging.basicConfig(level=logging.INFO, format="%(message)s")

def trace_id_hex() -> str:
    span = trace.get_current_span()
    ctx = span.get_span_context()
    return format(ctx.trace_id, "032x") if ctx.is_valid else ""

# --- Метрики Prometheus ---
LLM_REQUESTS = Counter(
    "llm_requests_total",
    "Общее количество запросов LLM",
    ["route", "status_code", "model"],
)
LLM_LATENCY = Histogram(
    "llm_request_latency_seconds",
    "Конечная задержка запроса LLM (секунды)",
    ["route", "model"],
    buckets=(0.1, 0.2, 0.35, 0.5, 0.75, 1, 1.5, 2, 3, 5, 8, 13),
)

# --- Провайдер трассировок OpenTelemetry ---
resource = Resource.create({"service.name": "llm-inference-api"})
trace.set_tracer_provider(TracerProvider(resource=resource))
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter())  # настройка через переменные OTEL_EXPORTER_OTLP_*
)
tracer = trace.get_tracer(__name__)

class GenerateRequest(BaseModel):
    prompt: str
    model: str = "unspecified"
    max_tokens: int = 256

class GenerateResponse(BaseModel):
    model: str
    output: str
    latency_ms: int

@app.post("/v1/generate", response_model=GenerateResponse)
async def generate(req: GenerateRequest, request: Request):
    route = "/v1/generate"
    start = time.perf_counter()

    with tracer.start_as_current_span("llm.generate") as span:
        # Избегайте логирования полного запроса; отправляйте безопасные метаданные
        span.set_attribute("gen_ai.request.model", req.model)
        span.set_attribute("gen_ai.request.max_tokens", req.max_tokens)

        # Замените на реальный вызов LLM (клиент Triton/vLLM/TGI)
        time.sleep(0.15)
        output = "Привет от модели."

        latency_s = time.perf_counter() - start
        LLM_LATENCY.labels(route=route, model=req.model).observe(latency_s)
        LLM_REQUESTS.labels(route=route, status_code="200", model=req.model).inc()

        logger.info(
            {
                "msg": "llm_request_complete",
                "trace_id": trace_id_hex(),
                "model": req.model,
                "latency_ms": int(latency_s * 1000),
                # НЕ включайте сырые запросы/ответы, если это не разрешено политикой.
            }
        )

        return GenerateResponse(model=req.model, output=output, latency_ms=int(latency_s * 1000))

@app.get("/metrics")
def metrics():
    return Response(generate_latest(), media_type=CONTENT_TYPE_LATEST)

Развертывание, масштабирование, безопасность и устранение неполадок

Варианты развертывания

Масштабирование и хранение: практические ограничения

• Локальное хранилище Prometheus: без явных флагов размера/времени время хранения по умолчанию составляет 15d.
• Удаленная запись Prometheus: Prometheus документирует настройку удаленной записи для масштабирования за пределами «разумных» значений по умолчанию.
• Grafana Tempo: позиционируется как высокомасштабируемый бэкенд для трассировки и может генерировать метрики из спанов с помощью метрического генератора (удаленные записи в источник данных Prometheus).
• Хранилище Loki: документация Loki подчеркивает индексирование только по меткам и сжатое хранение чанков (объектное хранилище), что делает стратегию меток центральной для масштабирования и стоимости.

Безопасность и конфиденциальность: запросы могут содержать ПДн

Руководство по безопасности OpenTelemetry подчеркивает, что сбор телеметрии может случайно захватывать конфиденциальную/персональную информацию; вы несете ответственность за ее соответствующее обработку.

Модель безопасности Prometheus предупреждает, что конечные точки Prometheus не следует открывать в публично доступных сетях (например, интернет), так как они предоставляют информацию о мониторинге систем.

Операционные меры по конфиденциальности, которые сохраняют «наблюдаемость для систем LLM» в безопасности:

• По умолчанию не регистрируйте сырые запросы/ответы; регистрируйте вместо этого количество токенов, имя модели, задержку и идентификаторы трассировки.
• Редактируйте/удаляйте конфиденциальные атрибуты в коллекторах/конвейерах (фильтрация на уровне коллектора — распространенный подход в экосистемах).
• Обеспечьте RBAC и политики хранения для логов/трассировок; при необходимости рассмотрите сканеры конфиденциальных данных (например, поставщики документируют сканеры для телеметрии).

Проверочный список для устранения неполадок

Если ваш дашборд Grafana для задержки LLM выглядит неправильно, отладьте в следующем порядке:

• Здоровье инжекции
  • Prometheus: проверьте успешность сбора и семантику конфигурации (конфигурация Prometheus определяет задания/экземпляры сбора).
  • OTLP: подтвердите конфигурацию конечной точки экспортера (SDK использует OTEL_EXPORTER_OTLP_ENDPOINT, настройки протокола).
• Несоответствие схемы
  • Дашборд ожидает model, но ваш сервер отправляет model_name (vLLM явно документирует метки model_name).
• Взрыв кардинальности
  • Кто-то пометил запросами идентификаторами/хешами запросов; Prometheus предупреждает, что наборы меток увеличивают затраты на ОЗУ/ЦП/диск/сеть, и предоставляет рекомендации по кардинальности.
• Неправильное использование гистограмм
  • Убедитесь, что вы вычисляете квантили из серий _bucket с помощью rate() и le; Prometheus объясняет компромиссы расчета квантилей гистограмм.
• Пробелы в выборке трассировок
  • Если вы слишком агрессивно используете head-выборку, редкие медленные/ошибочные трассировки исчезают; tail-выборка сохраняет «важные» трассировки на основе полных критериев трассировки.
• Проблемы с метриками Tempo span
  • Если вы используете генератор метрик Tempo и метрики span, подтвердите, что он включен и настроен (Tempo документирует процессоры генератора метрик и span-метрик; существует отладка проблем генератора).
• Отсутствие метрик GPU
  • Подтвердите, что экспортер DCGM развернут и /metrics доступен (экспортер DCGM предоставляет метрики GPU через HTTP для Prometheus).

Полезные ссылки

• Наблюдаемость: Руководство по мониторингу, метрикам, Prometheus & Grafana
• Мониторинг Prometheus: Настройка и лучшие практики
• Производительность LLM: Бенчмарки, узкие места и оптимизация
• Хостинг LLM: Локальный, самоуправляемый и облачный инфраструктурный сравнение
• Пошаговое руководство по RAG
• Документация по конфигурации Prometheus
• Форматы экспозиции Prometheus
• Лучшие практики инструментации Prometheus
• Именование метрик Prometheus
• Гистограммы и сводки Prometheus
• Правила оповещений Prometheus
• Обзор оповещений Prometheus
• Конфигурация Alertmanager
• JSON-модель дашборда Grafana
• Предоставление Grafana
• Метрики NVIDIA Triton Inference Server
• API метрик TorchServe
• Экспортер NVIDIA DCGM
• Helm-чарт kube-prometheus-stack
• Начало работы с Prometheus Operator
• Спецификация экспортера Prometheus OpenTelemetry
• Руководство Prometheus по получению OTLP
• Трассировка LangSmith с OpenTelemetry