Разработка ML-моделей в лабораторной среде Jupyter-ноутбука и эксплуатация в реальном продукте — разные вещи, но не все учитывают это в процессе разработки. Поэтому перенос наработок в продуктив часто оказывается сложнее, чем предполагалось. Дата-сайентисты сталкиваются с «потерянными» весами, несовпадающими библиотеками, простаивающими мощностями и неделями ждут выделения дополнительных ресурсов. Чтобы бизнес не тратил бюджет на GPU, инженеры «K2Tex» построили собственную ML-платформу на базе Kubernetes и автоматизировали путь от идеи до деплоя. Подробности — в этом кейсе.
Как R&D сжигает бюджет
Если вы пытаетесь управлять ML-процессами с помощью инструментов для обычных stateless-приложений, то неизбежно упретесь в потолок. В этом сценарии разработчики быстро сталкиваются с целым набором проблем:
- Time-to-first-training может достигать 2–4 недель, так как каждой новой команде приходится вручную поднимать кластера, а это долго и дорого.
- Низкая утилизация GPU. Если для физических видеокарт это еще не так критично, то арендовав видеокарту в облаке, приходится платить за нее целиком, даже если ML-модель использует 10% полной мощности. В результате деньги просто сгорают.
- Без пайплайна и версионирования каждая ошибка требует целого расследования. В результате восстановление работы после сбоя может занимать несколько дней.
- Низкая воспроизводимость результатов экспериментов после переноса и масштабирования. Так, на ноутбуке разработчика все может работать прекрасно, а в проде модель падает по необъяснимым причинам. До трети экспериментов могут оказаться невоспроизводимы.
Почему не использовали готовый Kubeflow?
Первый вопрос, который задаст любой ML-энтузиаст: «Почему бы не задействовать Kubeflow?». Это мощный комбайн с UI, пайплайнами и трекингом.
Дело в том, что Kubeflow — это, по сути, операционная система поверх Kubernetes. Попытка заменить в нем один компонент на другой (например, бэкенд для инференса) превращается в сложную операцию с непредсказуемым результатом. Выбрав это решение, вы фактически оказываетесь заперты в экосистеме. Поэтому инженеры K2Tex решили собрать кастомный ML-конвейер, где каждый компонент можно настроить под конкретную задачу.
Архитектура решения
Чтобы добиться необходимой гибкости, платформу разделили на логические уровни.
Аппаратный уровень
На этом уровне главная задача — управление ресурсами. Необходимо заставить GPU работать на 100%. Для этого используются инструменты NVIDIA с поправкой на особенности российских операционных систем:
- NVIDIA GPU Operator, который автоматически находит видеокарту, подготавливает драйверы и экспортер метрик (DCGM).
- Time Slicing и MIG, отвечающие за оптимальное распределение ресурсов. Time Slicing — нарезает GPU для множества легких подов, которые хорошо подходят для R&D и экспериментов. MIG (Multi-Instance GPU) — изолирует ресурсы карты на уровне железа, обеспечивая надежную работу в условиях высоких нагрузок на проде.
- Longhorn выбрали для хранения данных. Это блочное хранилище стало заменой Ceph, потому что дает 80% функциональности при 20% сложности настройки. А с новым движком v2 оно эффективно работает с NVMe-дисками.
Уровень данных
Чтобы система была отказоустойчивой и безопасной, ее компоненты не должны зависеть от внешних сервисов. В качестве S3-совместимого хранилища для датасетов и моделей и Postgres (с оператором Zalando), который отвечает за хранение метаданных всех процессов, выбрали SeaweedFS. Как альтернативу можно использовать Garage.
Кроме того, в архитектуру нового ML-конвейера добавили локальное зеркало для GitLab. Если отключится внешний канал связи, разработка не встанет, можно будет использовать репозитории Gitea.
Сервисный слой
В качестве ядра новой платформы выступили три известных open-source продукта:
- Airflow управляет всем жизненным циклом через DAG-файлы, направленные ациклические графы, содержащие готовые наборы инструкций. Благодаря KubernetesPodOperator, каждая задача запускается в изолированном поде.
- MLflow записывает все: гиперпараметры, метрики, артефакты. Позволяет сравнивать эксперименты и решать проблему воспроизводимости.
- KServe предназначен для инференса моделей. С его помощью мы решаем проблему написания простыней YAML-кода. KServe под капотом сам создает Deployment, Service, Ingress и даже настраивает автоскейлинг для новых моделей.
Пайплайн глазами пользователя
Благодаря глубокой бесшовной интеграции весь этот конвейер работает незаметно для конечного пользователя.
Предположим, инженеру необходимо классифицировать изображение:
- Сначала он пушит код и DAG-файл в репозиторий. Gitea зеркалирует код, Airflow подхватывает DAG. В графическом интерфейсе появляется кнопка Play.
- Далее идет этап обучения: Airflow поднимает под, запрашивает GPU (GPU Operator тут же выдает нужный ресурс), скачивает датасет из SeaweedFS и тренирует модель.
- Если метрики в норме, то KServe создает эндпоинт для инференса, а по итогу система отправляет в Telegram уведомление: «Обучение завершено. Модель в проде».
Результаты внедрения
Этот простой и удобный в использовании механизм сильно изменил культуру взаимодействия между DevOps и ML. ML-инженеры получают свободу экспериментировать в рамках понятных правил и ответственность за результат. ML-команда перестает тратить ресурсы не на профильные задачи — больше не нужно постоянно настраивать и кастомизировать не предназначенные для этого инструменты.
В результате компания получает предсказуемость и контроль над процессом разработки. Переход на кастомный стек на базе K8s дал «К2Тех» ощутимый экономический и операционный эффект:
- Time-to-market (или Time-to-demo) сократился в 5–7 раз. То, на что уходили недели ручной настройки, теперь занимает пару дней.
- Утилизация GPU выросла на 40%. Технологии шеринга ресурсов (MIG/Time Slicing) позволили не платить за простой видеокарт.
- Онбординг за 2 дня. Новичку не нужно долго настраивать библиотеки. Ему дают доступ к JupyterHub, и он готов к работе.
- MTTR — минуты вместо часов. Благодаря DCGM-экспортеру проблемы с видеокартами видны в Grafana мгновенно.
- Воспроизводимость 99%. MLflow хранит историю всех экспериментов и позволяет без проблем восстановить параметры любой запущенной модели и повторить эксперимент.
Конечно, эту платформу можно (и нужно) развивать: внедрять умные шедулеры (Kueue, Volcano) для оптимизации очереди задач, усиливать безопасность (SSO, сканирование образов через Trivy) и подключать BI-инструменты (Superset) для создания красивых и информативных отчетов.
Однако основной залог успеха не в конкретном наборе софта, а в подходе к процессу, ведь лучшая инфраструктура — та, которую ML-инженер не замечает.