dBrain.cloud integrou LocalAI e Kubeflow a uma plataforma de contêineres para AI empresarial

A equipe dBrain compartilhou como construiu duas camadas diferentes para trabalho com IA em sua plataforma de contêineres: LocalAI para implantação rápida de modelos pré-construídos e Kubeflow para o ciclo completo de desenvolvimento. A prática mostrou que a maior parte do trabalho não estava nos modelos em si, mas em integrá-los à infraestrutura e redes existentes.

Duas Camadas de Plataforma

Para modelos pré-construídos, dBrain escolheu LocalAI. Esta ferramenta open source permite modelos de chat, geração de imagens e vídeos, reconhecimento e síntese de fala, bem como cenários multimodais. Uma vantagem significativa para uma plataforma com recursos limitados é a capacidade de carregar e descarregar modelos com flexibilidade, usar GPU onde necessário, enquanto oferece aos desenvolvedores um endpoint local compatível com a API OpenAI. Isso é especialmente importante quando os recursos computacionais são limitados e a distribuição de carga entre serviços precisa ser rebalanceada rapidamente.

Dentro da plataforma, LocalAI se mostrou o estágio mais simples. A integração se resumiu principalmente a adaptar manifests aos templates de implantação internos. Esta camada é necessária para clientes que não precisam de seu próprio pipeline ML, mas precisam de implantação rápida de modelos prontos em contêineres.

Para seus próprios modelos, a equipe adotou uma abordagem mais pesada e integrou partes-chave do Kubeflow, transformando a plataforma em um circuito MLOps completo. Esta pilha incluiu:

• KServe para hospedagem e gerenciamento de modelos
• Trainer para treinamento e otimização
• Notebooks para experimentação rápida e ajuste fino
• Katib para sintonização de hiperparâmetros
• Model Registry e Pipelines para armazenamento e automação de processos

Por Que Sem Knative

A parte mais controversa da integração foi KServe, que possui dois modos de inferência: modo Knative e modo Standard. A documentação orienta principalmente as equipes em direção ao Knative. Para muitos, isso parece ser a opção padrão. Esta abordagem tem fortes vantagens: serviços podem escalar para zero sem tráfego, depois acordar rapidamente sob demanda, e a plataforma ganha mecanismos convenientes para revisões, divisão de tráfego e lançamentos canários.

Mas dBrain deliberadamente escolheu um caminho diferente. O motivo não era performance, mas custo operacional. Knative traz consigo uma camada de rede separada, contêineres queue proxy adicionais dentro de pods, e dependência de implementações de gateway como Istio ou Kourier. Para uma plataforma corporativa, isso significa mais componentes para manter, mais lugares onde as coisas podem quebrar, e diagnósticos mais complexos. No final, a equipe escolheu o modo Standard, que se baseia em Deployments e Services regulares do Kubernetes e se encaixa melhor no modelo operacional já existente.

Migração para Gateway API

Escolher o modo Standard não resolveu todos os problemas—apenas os deslocou para a camada de rede. Para este modo funcionar, Gateway API é necessário. dBrain já tinha suporte básico para este padrão, mas a maioria dos serviços da plataforma historicamente havia sido publicada via Ingress. Manter o esquema antigo ao lado do novo não funcionou: em sua arquitetura, KServe no modo Standard não podia coexistir adequadamente com o modelo ingress. A equipe considerou adaptação direcionada ou alternância do controlador ingress, mas considerou isso uma medida temporária.

Em vez disso, decidiu concluir a migração e mover todo o modelo de rede da plataforma para Gateway API. Este foi um passo mais caro no início, mas eliminou compromissos intermediários e preparou a infraestrutura para o novo padrão do Kubernetes. Na prática, integrar serviços de IA se tornou uma reforma infraestrutural que afetou não apenas a pilha ML, mas a publicação de todos os serviços.

O Que Significa

O caso dBrain ilustra bem a realidade atual da IA corporativa: escolher um modelo ou framework não é mais suficiente. O trabalho real começa onde você precisa combinar implantação rápida de modelos prontos, MLOps completo para desenvolvimento interno, e operação previsível em Kubernetes. O sucesso vai não para a pilha mais na moda, mas para a que pode ser mantida estavelmente em produção. É por isso que decisões infraestruturais aqui influenciam os negócios tanto quanto a escolha dos modelos em si.