Обучить модель – половина задачи. Вторая половина начинается, когда модель уходит в продакшн и должна работать годами под нагрузкой, аудитом и регуляторными требованиями. В госсекторе и крупном бизнесе РФ это означает закрытый контур: данные не покидают периметр, внешние API недоступны, всё разворачивается on-premise. Здесь классические облачные практики MLOps не работают напрямую, а для LLM добавляется отдельный пласт проблем. Разберём, как выстроить промышленную эксплуатацию ИИ без выхода за границу периметра.

MLOps: воспроизводимость и контроль дрейфа

Промышленная эксплуатация начинается с воспроизводимости. Каждый артефакт – датасет, код препроцессинга, веса, гиперпараметры – версионируется и связывается в единую цепочку. В закрытом контуре это решается локальным реестром моделей и хранилищем артефактов: связка MLflow и DVC поверх собственного S3-совместимого объектного хранилища, образы в приватном registry. Внешние зеркала пакетов недоступны, поэтому зависимости заранее загружаются в локальный прокси-репозиторий.

Дальше – мониторинг. Модель в проде деградирует тихо: метрики обучения отличные, а на свежих данных падает точность. Отслеживаем два типа дрейфа – дрейф данных (распределение входов поплыло) и дрейф концепта (изменилась связь вход-выход). На каждый продакшн-инференс собираем статистику признаков и сравниваем с эталонным окном. При превышении порога – алерт и автоматический запуск переобучения по расписанию или по триггеру. Без этого контура любая модель за полгода превращается в генератор устаревших прогнозов.

LLMOps: специфика больших языковых моделей

С LLM правила меняются. Дообучать модель целиком дорого и редко оправдано, поэтому основная работа идёт вокруг промптов, RAG и LoRA-адаптеров. Это рождает новые сущности для версионирования: версии промпт-шаблонов, версии индексов знаний, версии адаптеров. Каждое изменение прокатывается через регресс-набор – фиксированный список вопросов с эталонными ответами, который ловит просадку качества до выката.

Оценка качества здесь сложнее, чем accuracy. Нужны метрики релевантности ответа, фактологичности и отсутствия галлюцинаций, плюс контроль латентности и потребления GPU-памяти. В закрытом контуре генеративный стек строится на отечественных или открытых моделях, развёрнутых локально, – например, при интеграции ИИ-агента в корпоративные процессы или при внедрении GigaChat 2 для бизнеса во внутренних on-premise-сценариях. Отдельный слой – guardrails: фильтрация промпт-инъекций, проверка вывода на утечку чувствительных данных, логирование всех запросов для последующего аудита.

Инфраструктура и эксплуатация

Под MLOps и LLMOps нужна предсказуемая инфраструктура. GPU-ресурсы дефицитны, поэтому инференс и обучение разводятся по разным пулам, а планировщик распределяет нагрузку по приоритетам. Контейнеризация и оркестрация в Kubernetes дают единый способ выката для классических моделей и LLM-сервисов. CI/CD-пайплайн прогоняет тесты модели так же, как код: data validation, проверка метрик на отложенной выборке, регресс LLM, нагрузочное тестирование, и только потом – выкат через canary.

Безопасность и комплаенс пронизывают весь конвейер: разграничение доступа к данным и моделям, шифрование артефактов, неизменяемые журналы операций. Для систем, работающих с персональными данными, это требование 152-ФЗ, а не опция. Проектирование такого контура начинается с сетевой сегментации, изоляции пулов ускорителей и отказоустойчивости on-premise, а сами принципы изоляции опираются на тот же подход, что и в мобильной архитектуре корпоративных систем.

Вывод

MLOps и LLMOps в закрытом контуре – это не набор инструментов, а дисциплина эксплуатации: версионируй всё, мониторь дрейф и качество, выкатывай через тесты, логируй для аудита. Тогда ИИ перестаёт быть демо и становится производственным активом, которому можно доверять годами.