Разворачиваем ИИ в контейнерах: опыт интеграции LocalAI и Kubeflow

Мы — команда dBrain.cloud ^[1], и сегодня хотим поделиться нашим путем по внедрению ИИ-сервисов на нашей платформе контейнеризации. Искусственный интеллект ^[2] стремительно проникает практически в каждый цифровой продукт, будь то аналитика, корпоративные сервисы или клиентские приложения. В связи с этим перед нами встал важный вопрос: как обеспечить надежную и масштабируемую инфраструктуру для развертывания собственных и готовых ИИ-моделей?

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

LocalAI: швейцарский нож для ИИ-моделей

LocalAI — это, по сути, универсальный комбайн для запуска самых разных ИИ-моделей. С его помощью мы даем нашим пользователям возможность работать с:

• моделями для чат-ботов,

• генерацией изображений и видео,

• распознаванием и синтезом речи,

• мультимодальными моделями.

Платформа хороша тем, что поддерживает разные бэкэнды (включая ускорение на GPU или работу без него). Это позволяет динамически выгружать одни модели и загружать другие, что критически важно при ограниченных вычислительных ресурсах. А еще LocalAI реализует локальный endpoint, совместимый с OpenAI API, и это здорово упрощает жизнь разработчикам.

Внутри dBrain.cloud мы используем LocalAI как удобный инструмент для скачивания и запуска сторонних ИИ-моделей. Поскольку это open-source продукт, сама интеграция не вызвала больших проблем — понадобилась лишь адаптация манифестов под наши внутренние деплой-шаблоны.

Наши клиенты уже оценили LocalAI. Например, разработчик системы видеоаналитики использует QwenAI для авторазметки и WhisperAI для аудиоанализа. У другого клиента ИИ в корпоративном мессенджере тоже “поднят” на нашей платформе. LocalAI обеспечивает простой и гибкий способ запуска готовых моделей в контейнерах, экономя время и ресурсы.

Kubeflow: наш путь к полноценной MLOps-платформе

Kubeflow — это комплексная платформа для полного цикла разработки ИИ-моделей на чистом Kubernetes. Она предназначена для создания, обучения ^[3], оптимизации и развертывания собственных моделей и включает кучу компонентов. В отличие от LocalAI, внедрение Kubeflow оказалось куда более трудоемким. Размеры платформы, множество зависимостей и специфика работы каждого компонента заставили нас изрядно попотеть.

В dBrain мы интегрировали ключевые компоненты для работы с ИИ-сервисами:

• KServe – управление моделями и их хостинг.

• Trainer – обучение и оптимизация моделей.

• Notebooks – быстрое тестирование и дообучение нейронок.

• Katib – автоматический подбор гиперпараметров.

• Model Registry – локальный реестр моделей (как Hugging Face, но для KServe).

• Pipelines – автоматизация процессов обработки данных и обучения.

• Dashboard – визуализация и управление всей платформой.

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

Основные этапы интеграции Kubeflow в dBrain:

• Разбор манифестов и адаптация их под внутренний деплой dBrain.

• Интеграция компонентов с нашей инфраструктурой, замена стандартных сервисов Kubeflow на внутренние.

• Настройка взаимодействия всех сервисов для корректной работы.

Битва режимов KServe: Knative vs. Standard

Отдельный квест — это режимы работы KServe для инференса моделей: Knative mode и Standard mode.

В документации основной акцент сделан на Knative-режиме. Он построен на Knative Serving и дает удобную event-driven модель масштабирования. Сервисы могут “засыпать” до нуля при отсутствии трафика и быстро подниматься по запросу. Плюс Knative — это встроенное управление ревизиями, разделение трафика и удобные механизмы для канареечных релизов.

Но у такого подхода есть и жирный минус. Архитектура становится заметно сложнее: добавляются компоненты Knative, отдельный сетевой слой, queue-proxy контейнеры в подах и зависимость от конкретных gateway-реализаций (обычно это Istio или Kourier). Для продакшн-платформы, как наша, это означает рост операционной сложности и, увы, увеличение количества точек отказа.

Поэтому, хотя Knative mode и считается “каноничным”, мы приняли решение использовать Standard mode. Он опирается на стандартные ресурсы Kubernetes — Deployment и Service — и максимально предсказуем в эксплуатации. Масштабирование остается стандартным для K8s: через HPA (при необходимости можно подключить KEDA). Такой подход проще интегрируется в нашу существующую инфраструктуру и не требует разворачивать дополнительный стек сервисов.

Миграция на Gateway API

У Standard mode есть своя “фишка”: для работы с сетью он требует использования Gateway API. У нас работа над поддержкой Gateway API уже шла, и базовая реализация была. Но исторически все сервисы публиковались через Ingress — простую и привычную абстракцию.

Проблема в том, что Ingress-nginx фактически был в архиве, и его поддержка была приостановлена. Мы поняли, что миграция на другой ingress-контроллер — это лишь временное решение. Поэтому мы сразу решили перевести всю сетевую модель платформы на Gateway API, который постепенно становится новым стандартом для Kubernetes.

Ситуация усложнялась тем, что в нашей архитектуре KServe Standard mode не мог работать параллельно с ingress-моделью. Нам пришлось пойти до конца: провести полный путь миграции и перевести все сервисы платформы на Gateway API. Точечной настройкой обойтись не удалось.

Вместо заключения

Интеграция Kubeflow дала dBrain полноценный инструмент для разработки и обслуживания собственных ИИ-моделей на корпоративном уровне.

Платформа dBrain.cloud ^[1] представляет собой готовую инфраструктуру для развертывания и эксплуатации ИИ-решений любого формата: от запуска готовых моделей с LocalAI до полного цикла разработки и обучения собственных нейросетей с Kubeflow. Это делает ее универсальной средой как для команд, которые только начинают внедрять ИИ, так и для компаний, активно работающих над своими моделями.

Внедрение Kubeflow и LocalAI стало логичным шагом в развитии dBrain.cloud ^[1]. В сочетании с нашей инфраструктурой это формирует универсальную среду, в которой можно разрабатывать, тестировать и запускать ИИ-системы практически любого типа.

А какими ИИ-моделями пользуетесь вы? Где и как их разворачиваете? Делитесь своим опытом ^[4] в комментариях, нам очень интересно узнать ваше мнение.