LLMOps для self-hosted AI: мониторинг latency, токенов и галлюцинаций в проде
Как держать self-hosted LLM в работе после развёртывания. Что мерить: latency, ошибки токенизации, дрейф качества. Стек на Langfuse и Phoenix без облаков.
LLMOps для self-hosted AI — это операционная дисциплина, которая держит развёрнутую LLM в рабочем состоянии после релиза: непрерывный сбор latency, расхода токенов, частоты ошибок и сигналов галлюцинаций. Без неё корпоративный ассистент деградирует молча — пользователи перестают пользоваться, а команда узнаёт об этом из жалоб руководства. Открытый стек закрывает большую часть задач.
В этой статье — что такое LLMOps в отличие от обычного DevOps, какие шесть метрик мерить в проде, как собрать стек на Langfuse и Phoenix без облаков, и что ломалось у нас на первой версии. Опыт команды botAGI на типовых внедрениях для RU SMB и образовательных проектов — без клиентских имён и фабрикованных бенчмарков.
Что такое LLMOps и чем отличается от обычного DevOps
LLMOps растёт из MLOps, но добавляет четыре специфики, которых нет в классическом DevOps. Если игнорировать их, обычный мониторинг по uptime и CPU показывает «всё зелёное» — а ассистент при этом теряет пользователей.
Стохастичность ответов. Один и тот же промпт в одной и той же модели даёт разные ответы при ненулевой температуре. Поэтому стандартный SRE-подход «проверить healthcheck-эндпоинтом» не работает: 200 OK ничего не говорит о том, что в ответе — осмысленный текст или генерация поломалась после смены весов.
Дрейф качества модели. Веса не меняются сами, но контекст вокруг меняется: пользователи начинают задавать новые типы вопросов, корпус RAG растёт, появляются новые отделы. Модель, которая в день релиза отвечала корректно на 85% запросов, через три месяца может уйти к 70% — без единой строчки изменённого кода. См. подробный разбор топ-7 ошибок внедрения AI — пункт про «развернули и забыли» как раз про это.
Токеновый бюджет. В отличие от обычного API, у LLM стоимость ответа пропорциональна длине входа и выхода. Если кто-то случайно подключил в RAG-pipeline 50-страничный PDF в каждый запрос — latency и расход GPU вырастут в разы, а классический мониторинг не покажет ничего необычного.
Prompt-injection как continuous risk. Внешние данные (документы, веб-страницы, email) попадают в контекст модели — и каждый новый источник несёт риск инъекции. Это не одноразовый аудит безопасности, а постоянная задача, см. отдельный материал по безопасности RAG и prompt-injection.
Итог: LLMOps — это DevOps плюс непрерывная проверка качества и стоимости ответов, а не только up/down серверов.
Какие шесть метрик мерить в проде self-hosted LLM
Минимальный набор для команды 10–50 пользователей, который мы собираем на типовых внедрениях. Целевые SLO — ориентировочные, настраиваются по продуктовым требованиям.
1. Latency p50 / p95 / p99 (миллисекунды). Среднее бесполезно — пользователь страдает от хвостов. Ориентир для streaming-чата: p50 ≤ 800 мс до первого токена (TTFT), p95 ≤ 2000 мс, p99 ≤ 5000 мс. Для пакетной обработки документов другие пороги — там важна total latency на запрос, а не TTFT. Engine-выбор сильно влияет на цифры, см. vLLM vs Ollama vs llama.cpp.
2. Tokens per request (средний и максимум). Считаем input и output отдельно. Среднее показывает базовую стоимость запроса, максимум — выбросы. Если max начинает превышать avg в 20+ раз, это сигнал: где-то в pipeline неконтролируемо растёт контекст (раздулся системный промпт, в RAG попал гигантский документ).
3. Error rate. Сумма HTTP 5xx (engine упал или OOM) и parsing fails (JSON-вывод не парсится, structured output не валиден). Ориентир — 0.5% и ниже, поверх этого порога — пэйдж дежурного.
4. Prompt-injection detection rate. Доля запросов, на которые сработал input-фильтр. Само значение менее важно, чем динамика: резкий скачок означает либо новую атаку, либо ложные срабатывания после изменения фильтра.
5. Hallucination signal (eval-based). Самый сложный для измерения. На малом фиксированном наборе вопросов с известными ответами (golden set, 30–100 штук) гоняем периодически — раз в сутки или после каждого изменения промпта. Считаем долю ответов, которые судья-модель (Llama 3.3 70B или Qwen 3 32B как LLM-as-judge) помечает как корректные. Альтернатива — groundedness check: проверка, что каждое фактическое утверждение в ответе опирается на конкретный фрагмент из RAG-источников.
6. GPU utilization и VRAM headroom. Если GPU usage стабильно ниже 30%, batch-конфигурация неэффективна — деньги за железо тратятся вхолостую. Если headroom VRAM ниже 10%, OOM-падения вопрос времени.
Эти шесть метрик закрывают 90% операционных вопросов. Седьмую — стоимость per-request в рублях — обычно считают отдельно для отчётности; методика в материале про ROI внедрения AI и метрики.
Стек инструментов без облаков
Три кирпича, которые мы используем на типовых внедрениях. Все self-hosted, все open-source или с self-host-лицензией.
Langfuse (Apache 2.0, self-host). LLM-observability платформа: трейсы, prompt-management, evals, отчёты. В v3 (релиз апрель 2026, см. langfuse.com/changelog) сменили storage-backend на ClickHouse — это критично, потому что v2 на Postgres начинал захлёбываться на 10–20 миллионах трейсов. ClickHouse решает long-term storage и аналитические запросы. Минимальный self-host: 1 VM 4 vCPU / 16 GB RAM + ClickHouse, разворачивается через docker-compose из официального репозитория.
Phoenix (Arize, Elastic 2.0, OpenTelemetry-native). Открытая ML/LLM observability платформа, см. phoenix.arize.com. Сильная сторона — встроенная поддержка OpenTelemetry-семантики для GenAI и evals из коробки. Удобна, когда уже есть OTel-инфраструктура в компании. Минус — UI в основном на английском, что мы компенсируем внутренней документацией для команды.
LiteLLM proxy. Унифицированный прокси перед моделями — даёт единый OpenAI-совместимый эндпоинт поверх vLLM, Ollama, GigaChat, YandexGPT, см. docs.litellm.ai. Полезен по двум причинам: первое — централизованный логинг и rate-limiting в одной точке; второе — fail-over между движками без переписывания клиентского кода.
Что выбрать когда — три типовых сценария:
- Один сервер, до 50 пользователей. Phoenix self-host + Prometheus + Grafana. Минимум подвижных частей. Langfuse в этом масштабе избыточен.
- Два-три сервера за балансировщиком. Langfuse v3 + LiteLLM proxy + Prometheus. Langfuse даёт prompt-management и A/B-эксперименты, LiteLLM — единую точку входа.
- Multi-tenant с разделением отделов. Langfuse v3 (поддерживает projects/orgs из коробки) + LiteLLM + отдельный ClickHouse-кластер для долгосрочного хранения трейсов.
Prometheus и Grafana обязательны во всех трёх сценариях — для GPU-метрик и системного мониторинга самого ассистента. См. также общий разбор архитектуры в материале про корпоративный AI-помощник.
Архитектура: OpenTelemetry → коллектор → backend
Стандартная схема, которую мы рекомендуем как стартовую. Пути данных и форматы — без излишеств.
| Этап | Что | Формат | Куда |
|---|---|---|---|
| 1. Источник | vLLM / Ollama / LiteLLM | OTLP gRPC (порт 4317) | OTel Collector |
| 2. Коллектор | OpenTelemetry Collector | внутренний pipeline | split на 3 backend |
| 3a. Traces | Langfuse v3 ingest | OTLP | ClickHouse |
| 3b. Metrics | Prometheus scrape | text exposition | Prometheus TSDB |
| 3c. Long-term | ClickHouse partitioned by day | columnar | retention 90+ дней |
Что важно в этом флоу.
Источник пишет в OTel-формате — это снимает зависимость от конкретного backend. Если завтра выйдет инструмент мониторинга получше, переезд не потребует менять инструментацию в самом vLLM.
OTel Collector в середине — это точка отказа и точка стоимости. Если он падает, теряются трейсы; если он недосайзен, начинает дропать пакеты. Мы держим его на отдельной VM с buffer-памятью 2–4 GB и алертом на queue depth.
Split на три backend — оправдан тем, что у трейсов, метрик и long-term-хранения разные характеристики нагрузки. Prometheus отлично работает с time-series метриками, но плох на full-text trace-поиск. ClickHouse — наоборот.
Точки отказа, которые мы видели на типовых внедрениях:
- OTLP gRPC TLS-handshake падает между сервисами в Kubernetes — самая частая причина «пропали трейсы за 4 часа». Решение — health-check на TLS-соединении в коллекторе и алерт.
- ClickHouse partition не пересоздан — раздел кончился, новые трейсы не пишутся. TTL и automatic partitioning по дню обязательны.
- Prometheus retention заполнен — по умолчанию 15 дней; для LLM этого мало, потому что дрейф качества проявляется на горизонте недель. Поднимаем до 90 дней.
Если в инфраструктуре есть требования по 152-ФЗ и корпоративному AI — трейсы с фрагментами ПДн в промптах должны быть в отдельном zone storage с access-логированием и retention по регламенту. Часть метаданных лучше анонимизировать на уровне коллектора, до записи в backend.
Что не сработало в первой версии
Раздел, ради которого пишут такие статьи. Четыре specific pain points, которые мы поймали и переделали — без выдуманных бенчмарков и клиентских имён.
Сохраняли промпты в Postgres → таблица выросла за месяц до неконтролируемого размера → перешли на ClickHouse с partition by day. Первая версия мониторинга у нас была написана как примитив — небольшая Postgres-таблица с полями request_id, prompt, response, latency_ms, tokens. На пилоте 20 пользователей выглядело отлично. После раскатки на 200 — рост на сотни мегабайт в день, индексы перестали помещаться в кэше, аналитические запросы стали занимать минуты. Решение — перенос в ClickHouse с partition by toDate(created_at) и retention 90 дней. Это та же причина, по которой Langfuse v3 ушёл с Postgres-default на ClickHouse как основной storage.
Trace-sampling 100% забивал диск → перешли на head-based 10% с error-up-sampling. На старте логировали все трейсы — «чтобы ничего не потерять». На объёмах ассистента, который отвечает в Telegram-бот и через MCP-интеграцию с 1С/Bitrix24/amoCRM, это быстро стало неподъёмным по storage. Перешли на head-based sampling 10% (десятая часть трейсов) + 100% для всех ответов с ошибками и для всех ответов с user-feedback «👎». Покрытие критичных событий не пострадало, объём данных упал в 8 раз.
Phoenix UI в EN → команда не пользовалась → пришлось писать RU-стайл-гайд. Объективный минус Phoenix — англоязычный интерфейс. Часть техкоманды на стороне заказчика просто переставала открывать дашборд, и регресс качества ловился с недельным опозданием. Решение оказалось не техническим, а организационным: написали краткий внутренний RU-гайд «где в Phoenix смотреть что» с скриншотами и закрепили в Confluence. На следующих внедрениях рассматриваем Langfuse как первичный UI по этой же причине.
Алерты на p99 latency срабатывали ночью → переписали на сравнение с rolling baseline. Жёсткий порог «p99 > 5s = алерт» давал ложные срабатывания: ночью при низком трафике одна длинная генерация заводила хвост. Перешли на алерт «p99 текущего часа выше rolling baseline за последние 7 дней более чем на 50%» — это убирает false positives при low-traffic окнах и при этом ловит реальные деградации. Похожая логика применима к мониторингу GPU-серверов на RTX 4090 или Mac Studio M3 Ultra и к плановым проверкам бэкапов из материала про backup и disaster recovery self-hosted AI.
Общий вывод по этим четырём кейсам — типовая LLM-инфраструктура в первой версии всегда переоценивает важность «полноты данных» и недооценивает важность «удобства просмотра». Метрика, которую никто не смотрит, бесполезна.
Когда LLMOps окупается
Не на каждом внедрении нужен полный стек. Минимальный мониторинг — uptime, latency, error rate через Prometheus и Grafana — обязателен везде. Langfuse / Phoenix + eval-инфраструктуру с golden set имеет смысл разворачивать, когда у ассистента ≥ 30 активных пользователей в день или когда он обслуживает регуляторно чувствительные сценарии (медицина, юриспруденция, госконтракт, см. self-hosted AI и госзаказ или AI в клинике и 152-ФЗ).
Если бюджет пилота не позволяет сразу полный стек — стартовая конфигурация это Prometheus + Grafana + ручной weekly eval по 30 вопросам с золотыми ответами. Дальше — итеративно добавлять trace-сбор и автоматизацию evals по мере роста нагрузки.
Хотите развернуть LLMOps-стек на собственной инфраструктуре или провести аудит существующего? Команда botAGI делает это под ключ за 4–8 недель на типовом внедрении. Напишите в Telegram — обсудим, что подходит под вашу нагрузку и compliance-требования.