LLM Ops: как управлять ИИ-моделями в продакшне

LLM Ops: набор практик и инструментов для управления языковыми моделями в продакшне. Когда модель отвечает реальным пользователям, каждый неудачный ответ виден в метриках, а каждые 10 000 лишних токенов превращаются в строку расходов. MLOps вырос из потребности управлять классическими моделями машинного обучения. LLM Ops появился из специфики LLM: недетерминированные ответы, высокая стоимость inference, сложность с версионированием промптов, чувствительность к дрейфу качества.

Что такое LLM Ops и чем он отличается от MLOps

MLOps управляет детерминированными моделями: обученная модель на одних входных данных всегда даёт одинаковый результат. Её можно протестировать unit-тестами, зафиксировать accuracy на тест-сете и спать спокойно до следующего переобучения.

LLM работает иначе. При temperature > 0 ответы недетерминированы. Промпт длиной 800 токенов даёт точный ответ, а добавление одного слова приводит к галлюцинации. Стоимость одного запроса зависит от длины входного и выходного текста. Подмена модели с GPT-4o на GPT-4o-mini меняет и качество, и цену одновременно.

Ключевые отличия LLM Ops от MLOps:

• Наблюдаемость. Нужны трейсы на уровне отдельного токена, а не только итоговая метрика. Важно знать, какой фрагмент промпта повлиял на ответ.
• Prompt management. Промпт меняется как код: нужны версионирование, A/B-тест и откат к предыдущей версии.
• Cost accounting. Каждый вызов LLM стоит денег. Без cost-per-token-учёта бюджет AI-функции превращается в чёрный ящик.
• Eval без метки. У MLOps есть labeled тест-сет. У LLM ответы субъективны: нужны LLM-as-judge или человеческая оценка.

Жизненный цикл LLM в продакшне: 5 этапов

Жизненный цикл LLM в продакшне состоит из пяти последовательных этапов. Пропустить любой из них значит накапливать технический долг, который проявится в виде неожиданных расходов или деградации качества.

1. Инициализация. Выбор модели, провайдера и базового промпта. Фиксируем версию модели (не просто «gpt-4o», а конкретный snapshot), параметры inference (temperature, max_tokens, top_p) и первоначальный system prompt. Всё это кладём в git с тегом релиза.

2. Мониторинг качества. Подключаем трассировку с первого дня. Langfuse или Phoenix собирают каждый вызов: входной промпт, ответ модели, latency, количество токенов. Это фундамент для последующего анализа.

3. Итерация промптов. На основе трейсов видим, где модель ошибается. Меняем промпт, деплоим новую версию в A/B-тест, сравниваем метрики качества между версиями.

4. Cost optimization. Когда система стабильна, смотрим на cost-per-request. Кешируем частые промпты через prompt caching (Anthropic) или semantic caching (GPTCache). Оцениваем, можно ли заменить GPT-4o на GPT-4o-mini для части запросов без потери качества.

5. Drift detection. LLM-провайдеры обновляют модели без предупреждения. GPT-4o в июле 2026 отвечает иначе, чем в январе 2025. Раз в месяц прогоняем регрессионный набор из 50-100 тестовых запросов и сравниваем с baseline.

Мониторинг и observability: как видеть, что происходит с моделью

Стандартный APM-мониторинг не подходит для LLM. Prometheus покажет latency и error rate, но не объяснит, почему модель начала давать короткие ответы или перестала следовать инструкциям в системном промпте.

Стандартные APM-метрики здесь не хватит: нужны данные на трёх уровнях детализации.

Уровень запроса. Каждый вызов модели записывается как трейс: timestamp, модель, версия промпта, input tokens, output tokens, latency, finish_reason. Это минимум, без которого нельзя отлаживать продакшн.

Уровень сессии. Цепочка запросов в рамках одного пользовательского диалога. Важно для RAG-систем: видим, какие документы были retrieved, какой контекст попал в промпт, насколько ответ опирался на извлечённые фрагменты. Подробнее об устройстве векторной базы данных для RAG.

Уровень оценки (evals). Автоматическая проверка качества ответа: корректность (LLM-as-judge), hallucination detection, соответствие инструкциям. Langfuse и Phoenix поддерживают встроенные eval-пайплайны.

Метрики, которые нужно отслеживать каждый день:

• P50/P95/P99 latency по вызовам модели
• Input tokens и output tokens по типам запросов
• Error rate (rate limit errors, timeout, content filter)
• Eval score по тестовому набору (запускать ночью через cron)
• Cost per request в разбивке по endpoints

Prompt management: версионирование и A/B-тест промптов

Промпт в продакшне меняется часто: команда тестирует новые инструкции, добавляет примеры few-shot, сокращает длину для экономии токенов. Без version control это превращается в хаос: непонятно, какая версия промпта сейчас в проде, кто и когда её менял, и почему качество упало три дня назад.

Минимальная система управления промптами включает три компонента.

Хранилище версий. Langfuse Prompt Management хранит промпты с версиями: откат к любой предыдущей занимает пару кликов, релизы тегируются как staging или production. Альтернатива: обычный git с промптами в виде .txt или .jinja2 файлов. Второй вариант проще интегрируется в существующий CI/CD.

A/B-тест. Два варианта промпта получают трафик в соотношении 90/10 или 80/20. Через 2-3 дня сравниваем eval score, latency и cost. Победивший вариант становится основным. Langfuse поддерживает это через labels: один промпт тегируется как production, другой как experiment.

Мониторинг деградации. При смене версии промпта автоматически запускается baseline-тест на 50 эталонных запросов. Если eval score падает больше чем на 5%, деплой блокируется или уходит алерт. Для оркестрации этих проверок удобен LangChain для оркестрации тестовых пайплайнов.

Управление стоимостью: как считать cost-per-token

Без токен-учёта даже небольшой сервис может потратить в 10 раз больше запланированного. Причины: длинные system prompts в каждом запросе, отсутствие кеширования, выбор слишком дорогой модели для простых задач.

Тарифы актуальных моделей (июль 2026):

• GPT-4o: $5 за млн input токенов, $15 за млн output токенов.
• GPT-4o mini: $0.15 за млн input, $0.60 за млн output.
• YandexGPT Pro: около 1 ₽ за 1 000 токенов (input + output).
• GigaChat Pro: от 0.10 до 1.50 ₽ за 1 000 токенов в зависимости от тарифного плана.

Пример расчёта для типичного B2B-сервиса на YandexGPT Pro:

• 1 000 запросов/день
• 1 500 токенов на запрос (system prompt + контекст + ответ)
• 1 500 ₽/день
• 45 000 ₽/мес при постоянной нагрузке

Для сравнения: тот же трафик на GPT-4o при 1 500 токенах на запрос обойдётся примерно в $11 250/мес (input: 1M × $5 + output: 0.5M × $15). Выбор провайдера существенно влияет на экономику продукта.

Расходы можно сократить без деградации качества на любом из этих трёх уровней.

Prompt caching. Anthropic поддерживает кеширование prefix-токенов: если system prompt одинаковый в 90% запросов, платить за него нужно только при первом вызове. Экономия до 90% стоимости input-токенов для длинных system prompts.

Маршрутизация по сложности. Простые запросы (классификация, короткое суммирование) уходят на GPT-4o-mini ($0.15/млн). Сложные (аналитика, генерация кода) идут на GPT-4o ($5/млн). Классификатор сложности на LightGBM или даже простом if-else по длине запроса снижает средний cost-per-request на 40-60%.

Semantic caching. GPTCache или Redis с embedding-поиском перехватывают семантически идентичные запросы и возвращают кешированный ответ без обращения к LLM. Полезно для FAQ-ботов и поддержки клиентов.

Инструменты LLM Ops: Langfuse, Phoenix, MLflow

На рынке сложились три категории инструментов: observability-платформы, prompt registries и experiment tracking. Они не исключают друг друга: типичный стек включает один инструмент из каждой категории.

Langfuse. Open-source LLM observability платформа. Self-hosted вариант бесплатен: разворачивается через docker compose за 10 минут. Cloud-тариф: от $29/мес для команд. Поддерживает Python и JS SDK, интеграцию с LangChain, LlamaIndex и OpenAI напрямую. Собирает трейсы, spans, оценки качества и scores. Prompt Management встроен в платформу. Подходит для стартапов и небольших команд, которым нужно всё в одном инструменте.

Phoenix (Arize). Open-source инструмент для трассировки и оценки LLM-приложений. Специализируется на evals: hallucination detection, Q&A correctness, toxicity. Развёртывается локально, не требует облака. Хорошо работает в паре с Arize Cloud для продакшн-мониторинга, но автономный режим полностью функционален. Особенно удобен для дебаггинга RAG-систем: визуализирует retrieval-chain и показывает, какие документы повлияли на ответ.

MLflow. Открытый инструмент от Databricks, изначально созданный для классических ML-экспериментов. В MLflow 2.x добавили поддержку LLM: logging prompts, parameters и metrics через mlflow.log_param(). Не замена Langfuse по observability, но хорошо подходит командам, которые уже используют MLflow для других моделей и хотят единый реестр экспериментов. Поддерживает дообучение LLM и хранение fine-tuned моделей в Model Registry. Интеграция с YandexML и управление версиями дообучения или RAG: отдельная тема, но MLflow покрывает оба сценария.

Сравнение по ключевым параметрам:

• Self-hosted без лицензии: Langfuse, Phoenix, MLflow: все три.
• Встроенный prompt management: Langfuse. В остальных нужен отдельный инструмент.
• LLM evals из коробки: Phoenix. Langfuse требует написания кастомных scorer-функций.
• Experiment tracking для fine-tuning: MLflow. Langfuse и Phoenix под это не заточены.
• Интеграция с LangChain: Langfuse и Phoenix оба поддерживают через callbacks.

LLM Ops с российскими моделями: YandexGPT, GigaChat и 152-ФЗ

Российские компании, работающие с персональными данными пользователей, сталкиваются с требованием 152-ФЗ: данные российских пользователей нельзя передавать на зарубежные серверы. Это напрямую влияет на выбор модели и архитектуру LLM Ops.

На практике это означает выбор одного из вариантов.

Вариант 1: YandexGPT через Yandex Cloud. API находится на серверах Яндекса в России. Запросы с персональными данными пользователей идут на российскую инфраструктуру. Тариф YandexGPT Pro: около 1 ₽ за 1 000 токенов. Langfuse self-hosted разворачивается на том же VPS и собирает трейсы локально, без передачи данных за рубеж.

Вариант 2: GigaChat от Сбера. API Сбера на gigachat.devices.sberbank.ru. GigaChat Pro: от 0.10 до 1.50 ₽ за 1 000 токенов. Бесплатный Developer-тариф: 1 000 000 токенов/мес. Подходит для прототипирования и небольших нагрузок.

Вариант 3: Self-hosted open-source модель. Llama 3, Qwen 2.5, Mistral на собственном GPU-сервере. Стоимость inference: стоимость электричества и аренды железа. Для юридических, медицинских или финансовых данных это единственный вариант с полным контролем над тем, куда уходит каждый токен. Phoenix для observability разворачивается рядом на том же кластере.

Важный нюанс: сам мониторинг тоже должен оставаться на российской инфраструктуре. Langfuse Cloud ($29/мес) хранит трейсы на серверах в Европе. При работе с персональными данными использовать self-hosted Langfuse на российском VPS.

Типичные ошибки при запуске LLM в прод

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

Ошибка 1: нет трассировки с первого дня. Команда запускает LLM-фичу без observability, а через две недели получает жалобы от пользователей. Разобраться в причинах без трейсов невозможно: логи показывают HTTP 200, но что передавалось в модель, не зафиксировано. Langfuse или Phoenix добавляют за один вечер.

Ошибка 2: промпт хранится в коде как строковая константа. При изменении промпта нужен новый деплой. Нет истории версий. Тестировать два варианта промпта одновременно невозможно. Выносите промпты в Langfuse Prompt Management или хотя бы в отдельные .jinja2 файлы с версионированием в git.

Ошибка 3: не считают стоимость до запуска. Команда оценивает нагрузку в запросах/сек, но не считает токены. Средний ответ GPT-4o с RAG-контекстом: 3 000-5 000 токенов. При 500 запросах/день на GPT-4o это $22.50-37.50/день только за output. Перед деплоем: посчитать ожидаемые токены на запрос, умножить на прогнозируемый трафик, сравнить варианты моделей по цене.

Ошибка 4: не тестируют деградацию при обновлении модели провайдером. OpenAI и Яндекс обновляют модели в рамках одного и того же model-id. GPT-4o сегодня и через три месяца имеет разные веса. Без регрессионного тест-набора деградация остаётся незамеченной неделями.

Ошибка 5: игнорируют rate limits при проектировании архитектуры. YandexGPT Pro: 20 запросов/сек на стандартном тарифе. GPT-4o: 10 000 RPM на Tier 1. При пиковой нагрузке без очереди (Redis Queue, Celery) сервис начинает роняться с 429 ошибками. Queue + exponential backoff: стандарт для любого продакшн LLM-сервиса.

Ошибка 6: переход сразу к сложной архитектуре. Multi-agent с 8 инструментами, semantic routing, dynamic prompt assembly, custom eval pipeline: всё одновременно. Правильный порядок: простой LLM-вызов с логированием, потом RAG через векторную базу данных, потом агенты через ИИ-агенты. Каждый шаг добавляет сложность, которую нужно научиться обслуживать.