dBrain.cloud integró LocalAI y Kubeflow en una plataforma de contenedores para AI empresarial

El equipo de dBrain compartió cómo construyó dos capas diferentes para el trabajo con IA en su plataforma de contenedores: LocalAI para implementación rápida de modelos preconstructuidos y Kubeflow para el ciclo completo de desarrollo. La práctica mostró que la mayor parte del trabajo no estaba en los propios modelos, sino en integrarlos en infraestructura y redes existentes.

Dos Capas de Plataforma

Para modelos preconstructuidos, dBrain eligió LocalAI. Esta herramienta de código abierto permite modelos de chat, generación de imágenes y videos, reconocimiento y síntesis de voz, así como escenarios multimodales. Una ventaja significativa para una plataforma con recursos limitados es la capacidad de cargar y descargar modelos de manera flexible, usar GPU donde sea necesario, mientras se proporciona a los desarrolladores un punto final local compatible con la API de OpenAI. Esto es especialmente importante cuando los recursos computacionales son limitados y la distribución de carga entre servicios debe reequilibrarse rápidamente.

Dentro de la plataforma, LocalAI resultó ser la etapa más simple. La integración se redujo principalmente a adaptar manifests a plantillas de implementación internas. Esta capa es necesaria para clientes que no requieren su propio pipeline de ML, pero necesitan implementación rápida de modelos ya listos en contenedores.

Para sus propios modelos, el equipo adoptó un enfoque más pesado e integró partes clave de Kubeflow, convirtiendo la plataforma en un circuito MLOps completo. Este stack incluyó:

• KServe para alojamiento y gestión de modelos
• Trainer para entrenamiento y optimización
• Notebooks para experimentación rápida y ajuste fino
• Katib para sintonización de hiperparámetros
• Model Registry y Pipelines para almacenamiento y automatización de procesos

Por Qué Sin Knative

La parte más controvertida de la integración fue KServe, que tiene dos modos de inferencia: modo Knative y modo Standard. La documentación orienta principalmente a los equipos hacia Knative. Para muchos, esto parece ser la opción predeterminada. Este enfoque tiene fuertes ventajas: los servicios pueden escalar a cero sin tráfico, luego despertarse rápidamente bajo demanda, y la plataforma obtiene mecanismos convenientes para revisiones, división de tráfico y lanzamientos canarios.

Pero dBrain deliberadamente eligió un camino diferente. La razón no fue el rendimiento, sino el costo operacional. Knative trae consigo una capa de red separada, contenedores de queue proxy adicionales dentro de pods, y dependencia de implementaciones de gateway como Istio o Kourier. Para una plataforma empresarial, esto significa más componentes que mantener, más lugares donde las cosas pueden romperse, y diagnósticos más complejos. En última instancia, el equipo eligió el modo Standard, que se basa en Deployments y Services normales de Kubernetes y se ajusta mejor al modelo operacional ya existente.

Migración a Gateway API

Elegir el modo Standard no resolvió todos los problemas—simplemente los desplazó a la capa de red. Para que funcione este modo, se requiere Gateway API. dBrain ya tenía soporte básico para este estándar, pero la mayoría de los servicios de la plataforma históricamente se habían publicado a través de Ingress. Mantener el esquema antiguo junto con el nuevo no funcionó: en su arquitectura, KServe en modo Standard no podía coexistir adecuadamente con el modelo ingress. El equipo consideró adaptación dirigida o cambio del controlador ingress, pero lo consideró una medida temporal.

En su lugar, decidió completar la migración y mover el modelo de red completo de la plataforma a Gateway API. Este fue un paso más caro al principio, pero eliminó compromisos intermedios y preparó la infraestructura para el nuevo estándar de Kubernetes. En efecto, integrar servicios de IA se convirtió en una reforma de infraestructura que afectó no solo a la pila de ML, sino a la publicación de todos los servicios.

Qué Significa

El caso de dBrain ilustra bien la realidad actual de la IA empresarial: elegir un modelo o framework ya no es suficiente. El trabajo real comienza donde necesita combinar implementación rápida de modelos ya listos, MLOps completo para desarrollo interno, y operación predecible en Kubernetes. El éxito no va al stack más de moda, sino al que puede mantenerse establemente en producción. Por eso las decisiones de infraestructura aquí influyen en el negocio tanto como la elección de los modelos mismos.