dBrain.cloud встроила LocalAI и Kubeflow в контейнерную платформу для корпоративного ИИ

Команда dBrain рассказала, как собрала на своей контейнерной платформе два разных слоя для работы с ИИ: LocalAI для быстрого запуска готовых моделей и Kubeflow для полного цикла разработки. Практика показала, что главный объем работы оказался не в самих моделях, а в том, как встроить их в существующую инфраструктуру и сеть.

Два слоя платформы Для готовых моделей dBrain выбрала LocalAI.

Этот open source инструмент позволяет поднимать чат модели, генерацию изображений и видео, распознавание и синтез речи, а также мультимодальные сценарии. Важный плюс для платформы с ограниченными ресурсами — возможность гибко загружать и выгружать модели, использовать GPU там, где он нужен, и при этом отдавать разработчикам локальный endpoint, совместимый с API OpenAI. Это особенно важно, когда вычислительные ресурсы ограничены и нагрузку между сервисами приходится быстро перераспределять.

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

Для собственных моделей команда пошла по более тяжелому пути и встроила ключевые части Kubeflow, превратив платформу в полноценный MLOps контур. В этот стек вошли: KServe для хостинга и управления моделями Trainer для обучения и оптимизации Notebooks для быстрых экспериментов и дообучения Katib для подбора гиперпараметров * Model Registry и Pipelines для хранения и автоматизации процессов ## Почему без Knative Самой спорной частью интеграции стал KServe, у которого есть два режима инференса: Knative mode и Standard mode. Документация в первую очередь ориентирует команды на Knative.

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

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

В итоге команда выбрала Standard mode, который опирается на обычные Deployment и Service в Kubernetes и лучше вписывается в уже существующую эксплуатационную модель.

Переезд на Gateway API Выбор Standard mode не снял все проблемы, а просто перенес их в сетевой слой.

Для работы этому режиму нужен Gateway API. У dBrain уже была базовая поддержка этого стандарта, но большая часть сервисов платформы исторически публиковалась через Ingress. Оставить старую схему рядом с новой не получилось: в их архитектуре KServe Standard mode не мог нормально жить параллельно с ingress моделью. Команда рассматривала вариант точечной адаптации или смены ingress контроллера, но посчитала его временной мерой. Вместо этого она решила довести миграцию до конца и перевести всю сетевую модель платформы на Gateway API. Это был более дорогой шаг на старте, зато он убрал промежуточные компромиссы и подготовил инфраструктуру к новому стандарту Kubernetes. Фактически интеграция ИИ сервисов превратилась в инфраструктурную реформу, затронувшую не только ML стек, но и публикацию всех сервисов.

Что это значит

Кейс dBrain хорошо показывает текущую реальность корпоративного ИИ: выбрать модель или фреймворк уже недостаточно. Главная работа начинается там, где нужно совместить быстрый запуск готовых моделей, полноценный MLOps для собственных разработок и предсказуемую эксплуатацию в Kubernetes. Побеждает не самый модный стек, а тот, который можно стабильно поддерживать в продакшене. Именно поэтому инфраструктурные решения здесь влияют на бизнес не меньше, чем выбор самих моделей.