В последние годы искусственный интеллект (ИИ) и машинное обучение (ML) стремительно входят в повседневную жизнь бизнеса. Однако, за громкими заявлениями о трансформации скрывается суровая реальность: у большинства российских компаний процессы MLOps остаются незрелыми, и каждая организация вынуждена «изобретать велосипед» для решения собственных задач.

В статье рассмотрим современное состояние рынка MLOps в России, его ключевые вызовы и перспективы развития. Раскроем проблемы, связанные с незрелостью процессов и фрагментацией инфраструктуры, а также рассмотрим варианты использования публичных облаков и частных инсталляций.

На сегодняшний день рынок MLOps в России характеризуется фрагментарностью и отсутствием единых стандартов к выстраиванию процессов и построению инфраструктуры под ИИ. Ряд компаний пользуется публичными облачными платформами, такими как Yandex, Selectel, VK, T1 Cloud.

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

Многие команды не имеют единого шаблона для развертывания ML-инструментов, что приводит к различным конфигурациям компонентов даже при решении схожих задач. В то же время текущие подходы создают дополнительные трудности при масштабировании и интеграции с другими решениями.

Для успешного внедрения необходим комплексный и системный подход, который позволит не только оптимизировать процессы и повысить производительность, но и обеспечить долгосрочное развитие построенной платформы для задач AI/ML. Это объясняет запрос на создание решения, объединяющего как специализированное ПО для ML, так и классические ИТ-сервисы.

Одним из ключевых компонентов ML-инфраструктуры являются видеокарты.

Сегодня на рынке доминируют решения от NVIDIA:

• Модели A30, A40, а также L4, L40 — для решения простых и «легковесных» задач;
• Модели A100, H100 и H200 — для более сложных задач;
• Комплексы NVIDIA HGX/DGX — для самых требовательных и сложных вычислений.

Видеокарты NVIDIA де-факто являются стандартом вычислений, однако использование этого оборудования сопряжено с рядом проблем:

• Высокая стоимость и длительные сроки поставки;
• Ограничения по лицензиям и проблемы с доступом из-за санкций.

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

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

Портфель китайских продуктов расширяется: такие компании, как Huawei, Iluvatar CoreX, Cambricon Technologies, Jingjia Micro и Moore Threads активно инвестируют в разработку собственных GPU-решений. Наращивание инженерного потенциала должно способствовать созданию конкурентоспособных продуктов, которые будут удовлетворять растущий спрос на вычислительные мощности для ML-задач.

Но получение и настройка графических ускорителей — лишь первый шаг. Для эффективного использования в задачах ИИ и ML необходимо научиться их применять.

Рассмотрим минимальный сценарий запуска Open Source LLM-модели для пользователей, в котором предполагается наличие полностью налаженной корпоративной инфраструктуры.

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

В таких условиях можно перейти непосредственно к развертыванию модели, не тратя время на интеграционные и регрессионные проверки.

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

Наконец, необходимо сформировать полноценное рабочее место, обладающее несколькими ключевыми возможностями:

• Предоставлять преднастроенные физические ресурсы; 
• Настраивать и модифицировать среду разработки, которая позволит оперативно дорабатывать функции «на ходу»;
• Обеспечить место для хранения данных;
• Включать конвейер для запуска экспериментов и хранения моделей.

В результате мы получили окружение, в котором можем разрабатывать и проверять гипотезы, но это только начало пути. Следующий шаг — обеспечить устойчивость и масштабируемость решения и устранить недостатки, мешающие продуктивной эксплуатации.

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

• Оптимизировать использование GPU: с ростом числа разработчиков один ускоритель перестанет удовлетворять их потребности; 
• Предоставить стабильный и защищенный сетевой доступ для пользователей;
• Решить задачу отслеживания качества данных и проблему inference моделей;
• Разработать меры по мониторингу состояния инфраструктурных сервисов и оборудования;
• Организовать сбор и хранение логов;
• Продумать интеграцию с другими системами в синхронном или асинхронном режимах;
• Решить проблему увеличивающейся нагрузки и обеспечить бесшовное обновление платформы.

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

Рабочее место ML-разработчика — это не просто набор инструментов кодинга, а комплексная система, которая должна удовлетворять широкому спектру требований: от подготовки данных до развертывания и мониторинга моделей.

Основная цель — сократить время на настройку среды и pipeline, обеспечив разработчику удобный и эффективный процесс работы. Опираясь на опыт ведущих специалистов и клиентов, можно выделить несколько ключевых аспектов.

• Инфраструктура вычислительных ресурсов
  Практически все команды требуют наличия IaaS с GPU. В условиях растущей нагрузки и необходимости быстрого реагирования критически важна возможность использовать виртуальные GPU (vGPU) и «слайсинг» видеокарт. Разработчики отмечают, что готовых решений для HaaS с GPU пока немного, а ручное управление ресурсами, в том числе необходимость вмешательства инженеров для включения или перераспределения GPU, приводит к потерям времени и снижению оперативности. 
• Интегрированная среда разработки
  Базовыми инструментами остаются Jupyter Notebook или его расширенные версии — Jupyter Hub и Jupyter Lab, которые дают разработчикам возможность сразу работать с популярными библиотеками (PyTorch, TensorFlow, и др.). Многие команды также используют VSCode для работы с исходным кодом, хотя для большинства пользователей Jupyter является основой. Важно, чтобы среда была преднастроена.
• Управление данными и хранение
  Для эффективной работы с большими объемами данных разработчики используют объектные хранилища на базе S3 (построенного на базе Ceph или MiniO), где данные могут храниться в формате Parquet, либо, в зависимости от вида решения, в любом другом структурированном формате. Помимо этого, широко применяются реляционные базы данных, а также инструменты для работы с Big Data. Важно отметить, что комплексное управление должно включать мониторинг качества входных и выходных данных моделей.
• Оркестрация ML-процессов
  Большинство команд используют MLFlow и Kubeflow для трекинга экспериментов, версионирования моделей и управления пайплайнами. Однако возникает необходимость в унифицированном шаблоне для развертывания, позволяющем избежать копирования решений из проекта в проект.
• Инструменты для совместной работы и управления версиями
  Интеграция систем контроля версий (например, GitLab или аналогичные решения) и биллинговых инструментов для централизованного управления ресурсами помогает эффективно распределять вычислительную мощность между командами. Использование готовых pipeline-шаблонов существенно ускоряет процессы развертывания и упрощает эксплуатацию ML-платформы.
• Гибкость и адаптивность к задачам
  Каждая команда имеет свои особенности: кто-то работает с готовыми моделями и дата-сетами, а кто-то создает и дообучает модели с использованием LLama или других современных архитектур. Единицы проводят обучение моделей с нуля. Важна поддержка и адаптация платформы под специфические требования отрасли — будь то видеоконтент, медицина или банковские услуги. Специалисты отмечают, что идеальный набор инструментов должен представлять собой не жестко фиксированный стек, а конструктор, который позволит легко подключать и настраивать PaaS-сервисы для инференса и обучения.

Таким образом, современное рабочее место ML-разработчика должно быть максимально интегрированным, автоматизированным и адаптивным, чтобы не только ускорять процессы разработки, но и снижать time to market, тем самым быстрее приносить ценность для бизнеса.

Помимо базового набора инструментов, рабочее место ML-разработчика требует надежной поддержки инфраструктурными сервисами.

Опыт отрасли и существующие решения свидетельствуют о том, что для продуктивной разработки сервисов и продуктов в сфере ML/AI необходим полный классический технический стек, основные элементы которого можно упрощенно представить следующим образом:

Сервисы можно условно разделить на две категории:

• Open Source

Современные инструменты для управления контейнерами, такие как Docker и Kubernetes, позволяют организовать автоматизированное развертывание и обновление приложений, что значительно сокращает время вывода проекта на рынок. 

Программное обеспечение для мониторинга и логирования, например, Prometheus и Grafana, помогает не только отслеживать состояние инфраструктуры, но и оперативно реагировать на возможные сбои.

Критически важен мониторинг самих моделей — их производительности, качества входных данных и стабильности работы. Здесь на помощь приходят специализированные решения для мониторинга физических параметров GPU и пользовательских метрик.

Для хранения и обработки больших объемов информации используются различные базы данных: как SQL, так и NoSQL. Это обеспечивает высокую скорость доступа и надежное хранение информации.

Преимущество Open Source подхода заключается в его гибкости и возможности снизить затраты, однако данные решения требуют наличия квалифицированных экспертов, способных интегрировать и оптимизировать компоненты в единую систему, и что не менее важно — качественно ее эксплуатировать и поддерживать. 

• Проприетарные и вендорские решения

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

Проприетарные продукты также идут в комплекте с дополнительными услугами по настройке, мониторингу и сопровождению, что позволяет снизить нагрузку на внутренние ИТ-ресурсы компании.

Выпуск моделей для пользователя — это процесс, в котором участвует множество компонентов и техник. Для обеспечения стабильной работы системы необходимо построить непрерывный цикл, позволяющий регулярно оптимизировать производительность, повышать точность модели и внедрять новые функциональные возможности.

Типовой жизненный цикл ML-модели можно разбить на несколько этапов.

1. Сбор и подготовка данных 

На этом этапе происходит извлечение данных из различных источников (базы данных, файловые хранилища, API и т.д.) и их предварительная обработка. Важным аспектом является приведение данных к единому формату и обеспечение их качества для последующего использования.

Кроме того, лучшей практикой на этом этапе считается интеграция с инструментами ИБ для проверки на наличие вредоносного кода, вирусов и других угроз, которые могут повлиять на безопасность данных и всей организации.

2. Анализ и исследование данных

После первичной обработки проводится подробный анализ данных: выявляются ключевые признаки, изучается распределение значений, ищутся скрытые зависимости. Этот этап позволяет определить, какие данные будут наиболее полезны для обучения модели, и сформулировать гипотезы для дальнейшего тестирования.

3. Разработка и обучение модели

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

4. Управление экспериментами и трекинг модели

Здесь применяются инструменты для регистрации экспериментов, отслеживания параметров и версий модели. Это позволяет сохранять историю изменений, анализировать результаты экспериментов и выбирать оптимальные настройки для финальной модели.

5. Информационная безопасность

Опыт отрасли и нормативные стандарты подтверждают, что создание прототипа, исправление ошибок и доработка функционала — лишь часть процесса. Важно также обеспечить защиту данных и предотвратить возможные утечки. Как правило, перед запуском в промышленную эксплуатацию решение проходит дополнительные проверки со стороны ИБ, а установленные организационно-технические стандарты накладывают дополнительные ограничения на его использование.

6. Развертывание в продуктиве

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

7. Мониторинг и поддержка

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

Таким образом, формируется технологический стек, который необходимо разворачивать, мониторить, отлаживать и выполнять операции второго дня. В этом контексте облачные платформы способны упростить разработку, автоматизируя рутинные задачи — от развертывания виртуальных машин до управления контейнерами.

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

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

Если нужно быстро проверить гипотезу и нет жестких требований к размещению данных внутри компании, имеет смысл арендовать облачные ресурсы. Если же речь идет о долгосрочной стратегии с существенными вычислительными мощностями и сформированной командой специалистов, предпочтительнее строить on‑premise инфраструктуру, а облако применять точечно для пиковых нагрузок или оперативной проверки идей.

Внедрение MLOps — это комплексный и многогранный процесс, требующий глубокого понимания технологий, процессов и инфраструктуры. Это не просто запуск модели, а построение целой системы, обеспечивающей стабильную и эффективную работу ML-приложений на протяжении всего их жизненного цикла.

Успешное развитие MLOps в России требует системного подхода и интеграции инструментов разработчиков с базовыми ИТ-сервисами. Сегодня бизнесу необходимо не только инвестировать в современное оборудование и ПО, но и выстраивать процессы, способные обеспечить стабильное и масштабируемое функционирование ML-решений в условиях текущих технологических изменений и ограничений.

«Серебряной пули» в виде готового решения не существует. Каждая компания должна пройти свой путь, адаптируя лучшие практики и решения под уникальные потребности и условия.

В этом помогает обмен опытом и сотрудничество с экспертами отрасли. Такие практики позволяют минимизировать операционные риски, оптимизировать расходы и создать условия для устойчивого развития MLOps