Как построить идеальную «песочницу» для ML-моделей

Я Даниил Салман, техлид по контейнеризации. Эта статья написана по мотивам моего доклада для конференции DevOops. Разберёмся, как сделать такую ML-«песочницу», где Data Scientist пишет код, а всё остальное (установка драйверов, выделение ресурсов, деплой и тренировка модели, сбор метрик) уже настроено на бэкенде. Написали максимально просто и доступно, чтобы понять смог даже человек с минимальным погружением в тему. Идеи из этой статьи можно применять в любой инфраструктуре — важно лишь понимать основы: как работает k8s-кластер, Docker и python-фреймворки. Итак, поехали!

С какими болями сталкиваются ML-команды

Но прежде чем перейти к самому интересному, немного истории. Познакомьтесь с лирическим героем этого рассказа — DevOps-инженером Германом. Герман — опытный специалист, но однажды он столкнулся с типичной проблемой: как развернуть инфраструктуру для ML-моделей быстро и надёжно.

У Германа было несколько собственных k8s-кластеров — он их поддерживал, следил за метриками, решал инциденты. Обычная инженерная рутина. Но однажды после очередной IT-конференции его начальник пришёл с «гениальной идеей»:

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

С этого момента у Германа без остановки кипела голова. YouTube, сотни статей на Хабре, тысячи вкладок, непонятные аббревиатуры вроде MIG и MPS — а ясности всё меньше. Герман сидит перед экраном, читает и всё больше погружается в хаос.

В какой-то момент он вспоминает, что его знакомый Данила работает в интеграторе и занимается инфраструктурой для ML. Герман звонит, рассказывает о своей боли — и получает несколько ссылок на git-репозитории, пару статей и вендорскую документацию. Через пять дней он пишет: — Данила, ты что, крейзи? Где же ты был раньше?

Так начинается история, из которой стало ясно: путь к идеальной ML-песочнице начинается не с Kubernetes-кластера, а с понимания того, что именно ты строишь и зачем.

Вернёмся к проблемам, с которыми сталкиваются ML-инженеры.

1. Окружение. Подготовка среды часто занимает не пару дней, а недели. При открытии новой ветки внутри компании или проекта каждой команде требуются свои Kubernetes-кластеры и ресурсы, а без изначальной автоматизации всё снова разворачивается вручную. В итоге процесс, который должен занимать пару дней, растягивается до двух–четырёх недель.

2. Утилизация GPU. Чем она выше, тем лучше. За каждую GPU-карточку в облаке платят по полной стоимости, независимо от загрузки, поэтому важно использовать ресурсы максимально эффективно. В идеале утилизация должна стремиться к 100%, но на практике это, конечно, недостижимо, и без продуманного мониторинга часть ресурсов просто простаивает.

3. Среднее время восстановления (MTTR). Из-за отсутствия пайплайнов, версионирования моделей, устойчивой инфраструктуры и централизованных инструментов каждая новая итерация модели вносит хаос: теряются веса, гиперпараметры и артефакты, а повторное обучение превращается в очередной квест. Время на откат растёт в разы. А после сбоя — измеряется уже днями, а не часами.

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

Какой же должна быть песочница, чтобы наш герой с этими проблемами не столкнулся?

Какой стек нужен, чтобы собрать крепкий скелет ML-платформы

Базовая точка отсчёта. Есть четыре основных подхода к развёртыванию k8s: Kubeadm, Kubespray, KaaS в облаке, вендорские решения.

Каждый вариант — про разное, но имеются и пересечения.

Kubeadm — для энтузиастов и DevOps-гуру. Это надёжный, но трудоёмкий вариант: всё делается вручную, зато полный контроль и гибкость. Такой подход — для  опытных инженеров, готовых тратить время на поддержку и настройку. Из коробки нет буквально ничего. Если у вас будет два пода, которым надо как-то базово между собой взаимодействовать, то не выйдет — ведь не будет даже CNI для работы сети в этом кластере.

Kubespray — подходит любому DevOps-инженеру и даёт чуть больше автоматизации: есть CNI, рантайм и большое сообщество. Но всё равно многое придётся делать вручную, а ещё нет поддержки российских ОС. Поэтому чтобы развернуть k8s через Kubespray, например, на Astra OS, придётся писать костыли для Ansible самостоятельно.

KaaS (k8s as a Service) — это скорость, поддержка и удобство, но не все сервисы доступны «из коробки», многое зависит от конкретного облачного провайдера. У каждого облака — свой доступный набор инструментов.

Коробочные вендорские решения — самые дорогие, но и самые production-ready решения: высокая скорость развёртывания, поддержка, интеграция, встроенный мониторинг и безопасность.

Пример такого решения — NOVA, почти всё есть в формате из коробки: мониторинг, логирование, безопасность, сетевая подсистема, скейлинг и так далее. Как раз ниже на картинке приведен технологический стек, согласитесь, «из коробки» есть гораздо больше сервисов, чем у того же kubespray.

На данном этапе мы только готовим инфраструктуру для нашей ML-модели, но выбор правильного инструмента для развёртывания k8s может существенно сократить путь к непосредственной работе с ML-моделью. Если вы выбираете вендорское решение, то платите много денег, но не тратите недели на интеграцию базовых вещей друг с другом.

Строим «песочницу»

Перейдём к практике: как построить песочницу для ML-моделей внутри Kubernetes и не утонуть в ручной рутине. Я разделяю платформу на уровни. 

Аппаратный, он даёт драйверы, сеть и хранилище:

• NVIDIA GPU Operator — автоматическая установка/обновление драйверов и runtime для GPU.

• NVIDIA Network Operator — настройка высокопроизводительной сети (RDMA/RoCE).

• Longhorn — отказоустойчивое блочное хранилище для PVC подов. 

Этот слой обеспечивает базу для дальнейших сервисов: без него нельзя гарантировать работу GPU-задач, стабильную сеть и персистентные данные.

NVIDIA GPU Operator — сервис, который автоматизирует весь «низкий» слой для работы GPU в Kubernetes: ставит совместимые драйверы, NVIDIA Container Toolkit (runtime), device plugin и dcgm-exporter для метрик. В результате узлы с видеокартами становятся готовыми к запуску подов, использующих GPU, без ручной сборки окружения.

Оператор использует компонент Node Feature Discovery (NFD), который предварительно сканирует ваш bare metal хост, определяет компоненты внутри — наличие GPU и сетевых infiniband карт, их модели и вешает соответствующие лейблы, подтягивает нужные компоненты. Примерно так это выглядит логически: «обнаружена T4 → проставили метки на ноду → установили совместимые драйверы и плагин».

Если ваша операционная система не входит в поддерживаемые (или отличается по критичным пакетам/ядру), автоустановка может не сработать: не будут совпадать метки, не подтянутся правильные образы, драйвер не соберётся модулем. Тогда остаются два пути:

• собрать контейнеры/образы с драйверами самостоятельно;

• установить драйверы вручную на узел и скорректировать конфигурацию GPU-оператора до деплоя в k8s-кластера.

С dcgm-exporter вы получаете метрики загрузки и состояния GPU (для Prometheus/Grafana), что помогает контролировать утилизацию и искать узкие места ваших GPU и базовые метрики вроде температуры и утилизации.

Оператор поддерживает несколько подходов к разделению ресурсов GPU, но нас интересуют лишь два основных подхода:

• Time-Slicing — временные квоты без строгой аппаратной изоляции. Подходит, если нужно «поделиться» GPU между несколькими подами и вы готовы к конкуренции за ресурсы.

• MIG (Multi-Instance GPU) — аппаратные «слайсы» с предсказуемой производительностью и изоляцией. Доступно на картах поколения Ampere и новее (минимум, A30).

NVIDIA Network Operator — опциональный, но важный компонент. Это дополнительный сервис, который отвечает за настройку и оптимизацию сетевой подсистемы при работе с GPU. Он не обязателен для базового запуска Kubernetes-кластера под ML-нагрузки, но становится критичным, если вы работаете с тяжёлыми ML-моделями, распределённым обучением или большими объёмами данных.

Главная цель оператора — повысить пропускную способность сети и снизить задержки за счёт использования протоколов InfiniBand и RoCE (RDMA over Converged Ethernet). Это особенно важно, например, для задач, когда модель не помещается на одной видеокарте и требуется быстрая межузловая коммуникация.

По сути, Network Operator выполняет те же функции, что и GPU Operator, но в сетевом контексте:

• автоматически устанавливает драйверы и компоненты RDMA с теми же ограничениями по ОС, что и у GPU-оператора. Не все дистрибутивы Linux официально поддерживаются, и при нестандартных системах драйверы придётся собирать вручную.

• настраивает сетевые плагины и интерфейсы под Kubernetes.

Также он дает две ключевые функции:

1. GPU Direct RDMA (Remote Direct Memory Access) — позволяет объединять физические GPU (например, A100) в единый k8s-кластер, где данные передаются напрямую между видеокартами, минуя процессор. Это даёт возможность обучать очень большие модели, не умещающиеся на одной карте.

2. GPU Direct Storage (GDS) — обеспечивает прямой доступ GPU к NVMe-дискам без участия CPU и системной памяти. Это резко ускоряет загрузку данных при обучении, устраняя узкое место в I/O и повышая общую производительность.

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

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

Начиная с версии 1.8, Longhorn использует новый движок v2, оптимизированный под работу с NVMe-дисками. Это повышает скорость операций ввода-вывода и общую производительность хранения — особенно при обучении ML-моделей, где критичны скорость доступа и стабильность.

Как это выглядит на практике?

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

1. Подключение узлов. Сначала вы устанавливаете Kubernetes и добавляете эти хосты как worker-ноды к Kubernetes-кластеру.

2. Развёртывание операторов. После этого устанавливаются необходимые операторы — GPU Operator, Network Operator. Они автоматически сканируют железо:

   • Компонент Node Feature Discovery (NFD) проходит по всем нодам, собирает информацию о железе (GPU, CPU, диски, сеть) и проставляет лейблы, по которым Kubernetes затем распределяет поды. Это даёт системе понимание, какие ресурсы доступны и куда можно планировать задачи с GPU или высокоскоростным хранилищем.

   • GPU Operator определяет модели видеокарт, устанавливает драйверы и другие необходимые компоненты, перечисленные ранее;

   • Network Operator настраивает сетевые интерфейсы и RDMA;

3. Настройка хранилища. После этого вы разворачиваете Longhorn. Он создаёт распределённое хранилище между вашими, в данном случае трёмя, хостами. Все сервисы, которым нужно физическое пространство — будь то артефакты, данные ML-моделей или датасеты, — получают доступ к томам через Longhorn.

Уровень хранилищ

Следующий уровень — уровень хранилищ, который объединяет три основных компонента: MinIO, PostgreSQL и Gitea.

Достаточно всем знакомые компоненты, но давайте рассмотрим, как они работают в контексте нашей платформы:

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

• PostgreSQL отвечает за хранение служебной информации — метаданных сервисов, рабочих процессов, задач и параметров выполнения. Почему именно PostgreSQL? Потому что это единственная база данных, которая нативно интегрируется со всеми сервисами платформы. Мы проводили исследование по выбору production-ready решения в open source, и Zalando PostgreSQL-оператор показал себя оптимально: он прост в установке, гибко настраивается и хорошо работает в Kubernetes, в том числе при интеграции с S3 и балансировщиками.

• Gitea используется как внутренний репозиторий для хранения кода, конфигураций и пайплайнов, что упрощает версионирование и интеграцию с CI/CD процессами.

Сервисный слой

Следующий уровень — сервисный слой, в который входят три ключевых компонента: Apache Airflow, MLflow и KServe. Они уже не такие типичные и именно они превращают нашу k8s-инфраструктуру в полноценную ML-платформу, где можно управлять пайплайнами, экспериментами и развёртыванием ML-моделей.

Apache Airflow — это мощный оркестратор задач, который можно считать сердцем всей платформы. Он управляет последовательностью действий через так называемые DAG’и (Directed Acyclic Graphs) — графы задач, описывающие, что, в каком порядке и где должно быть выполнено Airflow. Как раз DAG’и лежат в Gitea, с которой Airflow периодически синхронизируется через контейнер git-sync.

Примерно это выглядит так:

«Возьми датасет из MinIO → запусти обработку данных → запусти обучение ML модели → сохрани артефакты → сделай запуск stage по инференсу модели».

Airflow интегрируется с Kubernetes и для каждой задачи запускает отдельный под через тот оператор, который был выбран пользователем для его задачи, например, KubernetesPodOperator (на самом деле их, конечно, больше – более подробно можно ознакомиться в документации)

MLflow — это open-source фреймворк для управления жизненным циклом ML-моделей: от экспериментов, реестра моделей до регистрации моделей в прод. Он включает в себя четыре ключевых компонента:

• Tracking — отслеживание экспериментов, гиперпараметров и метрик;

• Projects — определение и воспроизводимость сред выполнения;

• Models — реестр версий моделей;

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

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

KServe отвечает за развёртывание и масштабирование ML-моделей в Kubernetes. Это компонент, который автоматизирует весь процесс инференса: от подготовки окружения в k8s до создания эндпойнта модели.

Главная идея — инженер описывает модель всего в одном YAML-файле (пример такого файла посмотрим в следующем разделе практики), указывая:

• фреймворк (например, PyTorch, TensorFlow, Sklearn, vLLM);

• путь к артефакту модели в S3/MinIO или к registry с контейнером;

• ресурсы (GPU, CPU, память);

• параметры инференса и сетевые настройки.

После применения манифеста KServe автоматически создаёт все необходимые сущности — Deployment, Service, InferenceService — и поднимает endpoint, доступный для запросов к ML-модели. При этом под капотом KServe использует готовые образы популярных фреймворков, что исключает необходимость ручной настройки контейнеров.

Дополнительно в KServe есть секция Transformer — она позволяет описать pre- и post-processing данных. Например, можно заранее преобразовать изображение перед подачей в модель или разметить результаты инференса после получения ответа. Итог: инженер кладёт модель в хранилище, описывает её в YAML-файле — и примерно через несколько минут (в зависимости от того что он деплоит) получает работающий endpoint, за которым скрыты все базовые сущности в Kubernetes. В базовом варианте это нужно было делать вручную.

Интерфейс

Завершает архитектуру нашей песочницы JupyterHub — многопользовательский сервер, который позволяет запускать Jupyter Notebook буквально в один клик. JupyterHub идеально подходит для ML-инженеров, аналитиков и дата-сайентистов, которым важен быстрый доступ к интерактивной среде. Всё, что им требуется — браузер. Не нужно устанавливать Python, пакеты, драйверы или решать проблемы совместимости: окружение создаётся централизованно и одинаково для всех пользователей.

JupyterHub разворачивается поверх Kubernetes и создаёт изолированные контейнеры для каждого пользователя. Это позволяет:

• запускать ноутбуки с заданными ресурсами (CPU, GPU, память);

• управлять версиями окружения;

• интегрировать рабочие сессии с внутренним хранилищем и репозиторием кода (например, MinIO или Gitea).

Стандартный образ ноутбука не включает в себя гитлаб-плагин, чтобы сделать его удобнее, необходимо пересобрать контейнер и доустановить в него необходимые пакеты git и jupyterlab-git.

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

Архитектура ML-песочницы: как всё связано между собой

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

Интеграция с внешними системами

В большинстве компаний уже есть собственная инфраструктура:

• registry для хранения контейнеров (например, Harbor или GitLab Container Registry),

• GitLab или Gitea для хранения кода DAG’ов,

• S3-совместимые хранилища для данных и артефактов.

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

Архитектура условно разделена на три зоны, каждая из которых отвечает за свой уровень работы:

1. Инфраструктурная зона
   Здесь расположены базовые сервисы:

   • MinIO — объектное хранилище для датасетов и моделей,

   • PostgreSQL — база данных для хранения метаданных и служебной информации,

   • Longhorn — storage-сервис для выделения PVC подам.

Эта зона обеспечивает фундамент: хранение, устойчивость и консистентность данных.

2. Рабочая зона инженера
   Здесь работают основные инструменты ML-разработки:

   • Airflow — оркестрация пайплайнов,

   • MLflow — управление экспериментами и версиями моделей,

   • JupyterHub — централизованная работа в jupyter-ноутбуках DS/ML-инженерами.

Это — пространство, где инженер проводит исследования, обучает и тестирует модели, не покидая платформу.

3. Сервисная зона
   Отвечает за контроль, мониторинг и доставку:

   • FluxCD — GitOps-деплой и автоматизация поставки;

   • Harbor — registry для контейнеров;

   • Prometheus и Grafana — мониторинг и визуализация метрик;

   • Gitea — внутренний git-репозиторий (в данном случае зеркало для Gitlab) для пайплайнов и конфигураций;

   • KServe — взаимодействие с моделями, деплой и инференс.

   • Gitlab  — внешний сервер для хранения пайплайнов/DAG

Здесь сосредоточены инструменты, которые следят за стабильностью и обновляемостью системы.

Поток данных в платформе устроен прозрачно и линейно — от обучения до продакшн-инференса:

1. Инженер потестировал что-то в JupyterHub и через Airflow запускает процесс обучения.

2. Данные и модели хранятся в MinIO, а метаданные и результаты экспериментов — в MLflow и PostgreSQL.

3. После обучения модель передаётся в KServe, где создаётся endpoint для инференса.

4. FluxCD отслеживает изменения и автоматически обновляет деплой.

5. Prometheus собирает метрики, а Grafana визуализирует состояние сервисов и ML-моделей.

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

Практика от запуска обучения через Airflow до деплоя и инференса модели в k8s

Перейдём к практике и исходным условиям. Мы — интегратор с широкой экосистемой технологических партнёров. Как уже отмечалось, для полноценной ML-платформы недостаточно «затащить» только ML-сервисы: нужны также мониторинг, логирование, безопасность, реестры контейнеров, GitOps-поставка и т.д.

Чтобы сократить время на развёртывания и избежать лишней рутины, я взял платформу Nova, где ключевые сервисы уже идут из коробки. Это сняло массу головной боли и позволило быстрее выйти на рабочий минимум. При этом важно понимать: в таких платформах основа — open source k8s. Всё можно развернуть самостоятельно, но это займет заметно больше времени на установку и настройку различных интеграций.

В качестве воркеров я использовал два сервера Dell с GPU NVIDIA T4, а также внешний GitLab, зеркалом которого была Gitea для интеграции с Airflow. В демо-кейсе задача была простой и показательной: классифицировать изображения моего кота на базе датасета CIFAR-100 с помощью модели ResNet-18. Цель — пройти полный цикл без погружения в бэкенд в роли ML-инженера: подготовка данных, обучение, логирование метрик и артефактов, инференс ML-модели в мою демо-среду. С точки зрения инженера это сводилось к написанию нескольких Python-пайплайнов (stages) и сборке из них DAG для Airflow — платформенные компоненты делали всё остальное.

Всего в пайплайне было пять задач или стейджей, каждая отвечала за свой этап жизненного цикла модели: сбор и подготовка данных (fetch_data), обучение модели на датасете (train_model), проверка метрик и качества обученной модели (check_metrics), тестовый запуск модели на новых данных (infer_gradio). Последняя — utils.py— служебная задача-уведомление об окончании обучения моей ML-модели. Telegram-бот отправляет сообщение о завершении обучения и результатах.

Итак, всё просто: push — и код улетает в GitLab. Наши пайплайны версионируются в git-репозитории. После этого Airflow синхронизируется с Gitea, куда зеркалируется весь репозиторий. Через 10–20 секунд новый DAG автоматически подтягивается в Airflow и становится доступным для запуска.

В интерфейсе Airflow справа появляются action-кнопки — через них можно управлять задачами: запускать DAG вручную, ставить на паузу, пересоздавать определённые стадии или смотреть логи выполнения. В общем, можно настроить так, что всё будет работать без дополнительных ручных действий.

После старта первым создаётся под data_preparation — этап подготовки данных. На этом шаге:

• выполняется выгрузка сырого дата-сета в S3-хранилище,

• производится базовая предобработка: очистка, разметка, приведение формата, разделение на выборки.

После завершения этапа подготовки данных Airflow автоматически переходит к следующей стадии DAG — обучению модели.

Запускается новый под, в котором происходит цикл обучения: установка зависимостей, инициализация окружения (например, загрузка библиотек PyTorch или TensorFlow) и запуск основного скрипта, написанного мною для демо. Процесс занял в среднем 7–10 минут, но это, конечно, зависит от объёма данных и мощности GPU.

 В процессе работы под логирует всё — от загрузки данных до расчёта метрик — а результаты (веса модели, артефакты и логи) сохраняются в S3-хранилище и postgresql. А на картинке ниже вы можете видеть, как в поде ставятся необходимые пакеты для выполнения задачи.

На картинке ниже представлен граф DAG в интерфейсе Apache Airflow — визуальное отображение всех стадий пайплайна.
Если рассматривать его подробнее, то можно увидеть следующее:

• полный список задач (стейджей) и их последовательность;

• текущие статусы выполнения (в ожидании, выполняется, успешно завершено, ошибка);

• на базе каких операторов выполняются задачи (например, PythonOperator);

• возможность перейти в логи каждой стадии для анализа деталей выполнения.

Если какая-то стадия завершилась с ошибкой, Airflow позволяет точечно перезапустить только её, не проходя заново весь конвейер. Это удобно при отладке или повторных экспериментах.

Когда обучение завершается, система автоматически переходит к следующему шагу — проверке метрик.
Airflow запускает новый pod, который оценивает, соответствуют ли полученные результаты (например, accuracy и loss) заданным порогам. Если метрики удовлетворяют условиям, пайплайн продолжает выполнение и переходит к этапу инференса.

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

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

https://github.com/kserve/kserve

Перед тем как перейти непосредственно к инференсу модели через Kserve, давайте разберёмся, как заполнить манифест InferenceService — ключевой компонент, отвечающий за развёртывание модели в Kubernetes (см. картинку выше).

Давайте еще раз посмотри, что нужно, чтобы его применить. Во-первых, необходимо создать заранее две сущности в Kubernetes-кластере, если их еще нет:

1. Secret — хранит учётные данные для доступа к S3-хранилищу (MinIO), где лежит обученная модель и артефакты.

2. ServiceAccount — сервисный аккаунт, который привязывается к этому Secret и используется для аутентификации подов при работе с S3.

После этого можно описывать сам InferenceService в виде YAML-манифеста.
В нём указываются:

• путь к модели в s3;

• используемый inference-backend (например, Triton);

• параметры ресурсов (GPU, CPU, RAM);

• а также аннотации, где прописаны ссылки на Secret и нужный сервисный аккаунт.

После применения манифеста KServe создаёт под капотом все необходимые сущности k8s: Deployment, Service, Pod и связанные конфигурации.

Я выбрал Triton в качестве backend, указал его версию, задал путь к модели в S3, а также прописал ресурсные параметры — requests и limits, выделив под задачу одну GPU-карту.

После применения манифеста модель успешно задеплоилась: в Kubernetes появились два пода.

• Первый — это под, в котором выполняется сам ML-инференс.

• Второй — под с Gradio, лёгкий Python-фреймворк, который разворачивает веб-интерфейс для тестирования модели.

Gradio позволяет создать тестовый WEB-интерфейс, кнопку загрузки и увидеть результат работы модели (выглядит это примерно как на картинке ниже).

Знакомьтесь — это мой кот Мелкумян. Именно на нём я решил проверить, как работает модель. Я загрузил его фотографию в интерфейс Gradio и задал у себя в голове простой вопрос: «Что модель видит на этом изображении?» ииииии, барабанная дробь, модель увидела «камбалу». Да, звучит странно и смешно, но в её защиту скажу: кот действительно очень худой, так что ошибка частично объяснима.

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

В интерфейсе MLflow удобно просматривать и сравнивать результаты экспериментов.

Слева видны две таблицы:

• первая содержит метрики (например, accuracy, loss, precision и recall),

• вторая — параметры обучения (количество эпох, размер батча и т.д.).

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

Справа на слайде показано уведомление в Telegram (как раз тот самый utils.py), которое приходит после завершения обучения. В нём указано:

• название модели,

• параметры/эпохи запуска,

• ключевые метрики.

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

Результаты или почему песочница — идеальная

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

1. Время до первого демо (time-to-first-demo) сократилось в 5–7 раз. Теперь первые результаты обучения и инференса можно увидеть через пару дней, а не через недели, как раньше.

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

3. Утилизация GPU выросла на 30–40% благодаря использованию технологий MIG (Multi-Instance GPU) и time-slicing, доступных «из коробки» в NVIDIA GPU Operator. Эти механизмы позволяют эффективно делить ресурсы видеокарты между задачами. В результате время простоя GPU снижается почти вдвое, и вычислительные мощности используются максимально эффективно. Это напрямую влияет на экономику проекта: меньше неиспользованных карточек — меньше лишних расходов.

4. Цикл от эксперимента до продакшн-эндпойнта сократился примерно в три раза. Раньше на это уходили недели: подготовка среды, ручной деплой, тестирование. Теперь большинство процессов автоматизировано — инфраструктура создаётся через KServe InferenceService, а инженеру достаточно описать модель в одном YAML-файле. Все скрытые сущности (под, сервис и прочие) создаются автоматически, что радикально ускоряет поставку результатов. Кроме того, все эксперименты централизованно отслеживаются в MLflow. Инженеры могут сравнивать метрики разных запусков, анализировать параметры и находить оптимальные конфигурации ML-моделей. Это повышает прозрачность, воспроизводимость и качество исследований.

5. Благодаря DCGM-экспортеру из GPU Operator можно следить за состоянием видеокарт: температурой, утилизацией, производительностью, возможными узкими местами. Все эти данные собираются в Prometheus и визуализируются в Grafana, что позволяет сократить время обнаружения инцидента с часов до минут.

6. В итоге, за счёт прозрачного конвейера и автоматизированного флоу, скорость релизов ML-пайплайнов увеличилась на 60–70%. Команда получает предсказуемые, стабильные результаты, а эксперименты становятся не только быстрее, но и значительно понятнее для анализа и масштабирования.

Все имеющиеся вопросы по содержанию статьи можно задать в комментариях под статьей либо мне в Telegram: https://t.me/DV_Salman