5.5 MLOps: как превратить модель в работающий сервис

Вы выбрали модель, посчитали TCO, получили добро от финансового директора. Теперь начинается самое сложное: заставить модель работать в продакшене 24/7, быстро, дёшево и без сбоев. Это область MLOps - инженерной дисциплины, которая находится на стыке ML и DevOps.

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

Инференс-серверы: как поднять модель

Просто запустить модель через model.generate() в Python-скрипте - плохая идея. Она будет медленной, не масштабируемой и сломается при первом же скачке нагрузки.

В продакшене используют специализированные инференс-серверы:

Пример

Если вы разворачиваете Llama-3-8B на арендованных GPU, вместо transformers из коробки используйте vLLM. Прирост скорости будет в 10–20 раз, а значит, вы сможете обслуживать в 10 раз больше пользователей на том же железе.

Почему это важно

Инференс-серверы - это не «опциональная оптимизация». Это стандарт индустрии. Без них ваша модель будет простаивать 80% времени, ожидая, пока CPU склеит батчи.

CI/CD для LLM: как тестировать то, что недетерминировано

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

Что делать

Статический анализ промтов

Проверяйте, что промт не содержит инъекций (например, «игнорируй предыдущие инструкции»). Используйте инструменты вроде rebuff или собственные regex-проверки.

Метрики качества

Заведите тестовый набор из 100–200 реальных запросов. При каждом изменении (новая версия модели, новый промт, новый роутер) прогоняйте этот набор и сравнивайте:

Процент правильных ответов (по заранее размеченной выборке).

Среднюю длину ответа (чтобы модель не начала «лить воду»).

Латенси (p50, p95, p99).

Регрессионное тестирование

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

A/B тестирование

Если вы меняете модель или роутер, не включайте новую версию на 100% пользователей сразу. Запускайте канареечный релиз: 1% → 10% → 50% → 100%. Сравнивайте метрики (удержание, количество повторов запроса, жалобы).

Почему это важно

LLM - это софт, который может «сломаться» незаметно. Вы обновили модель, она стала на 5% лучше проходить бенчмарк, но на ваших данных начала галлюцинировать в каждом третьем ответе. Без CI/CD вы узнаете об этом от клиентов, а не от мониторинга.

Мониторинг: что смотреть, чтобы не упасть

Когда модель работает в продакшене, она может деградировать незаметно. Мониторинг должен отслеживать:

Инструменты

· Prometheus + Grafana - сбор и визуализация метрик (стандарт в индустрии).

· Weights & Biases - для отслеживания экспериментов и версий моделей.

· LangSmith - специализированная платформа для мониторинга LLM-приложений (трассировка промтов, сравнение ответов).

Почему это важно

Модель не «умирает» внезапно. Она деградирует: растет латенси, падает throughput, начинаются галлюцинации. Мониторинг позволяет увидеть это за неделю до того, как позвонят клиенты.

Дрейф данных: когда данные «уходят» от модели

Даже если код не менялся, модель может начать работать хуже. Потому что изменились данные, которые она обрабатывает.

Виды дрейфа

Что делать

· Логируйте не только ответы, но и промты, и метаданные (язык, длина, домен).

· Раз в неделю стройте распределение этих метаданных и сравнивайте с эталоном (первая неделя после запуска).

· Если распределение изменилось статистически значимо - пересматривайте роутер, промты или дообучайте модель.

Почему это важно

Модель, которая отлично работала полгода, может сегодня начать «тупить», потому что аудитория изменилась. Дрейф данных - главная причина, по которой модели требуют постоянного внимания, а не «запустил и забыл».

Резюме: чек-лист MLOps для LLM

Перед тем как отправить модель в продакшен, убедитесь, что у вас есть:

· Инференс-сервер (vLLM или TGI), а не скрипт на Python.

· CI/CD пайплайн, который прогоняет тестовый набор при каждом изменении.

· Тестовый набор из 100–200 реальных запросов с размеченными правильными ответами.

· Мониторинг латенси, throughput, error rate, токенов в секунду.

· Логирование промтов и ответов (хотя бы для выборки) для анализа проблем.

· Автоматический алертинг при падении метрик на 20% за час.

· План отката на предыдущую версию модели за < 10 минут.

· Регулярный мониторинг дрейфа данных (раз в неделю).

Если чего-то из этого списка нет, ваша модель не готова к продакшену. Вернитесь к инженерам и добавьте.