dBrain.cloud a intégré LocalAI et Kubeflow dans une plateforme de conteneurs pour l'AI d'entreprise

L'équipe dBrain a partagé comment elle a construit deux couches différentes pour le travail avec l'IA sur sa plateforme de conteneurs : LocalAI pour le déploiement rapide de modèles préconstruits et Kubeflow pour le cycle complet de développement. La pratique a montré que la majeure partie du travail n'était pas dans les modèles eux-mêmes, mais dans leur intégration à l'infrastructure et aux réseaux existants.

Deux Couches de Plateforme

Pour les modèles préconstruits, dBrain a choisi LocalAI. Cet outil open source permet les modèles de chat, la génération d'images et de vidéos, la reconnaissance et la synthèse vocales, ainsi que des scénarios multimodaux. Un avantage significatif pour une plateforme aux ressources limitées est la capacité à charger et décharger les modèles de manière flexible, utiliser le GPU là où il est nécessaire, tout en fournissant aux développeurs un point d'accès local compatible avec l'API OpenAI. C'est particulièrement important lorsque les ressources informatiques sont limitées et que la distribution de charge entre les services doit être rééquilibrée rapidement.

Au sein de la plateforme, LocalAI s'est avéré être l'étape la plus simple. L'intégration s'est essentiellement réduite à adapter les manifests aux modèles de déploiement internes. Cette couche est nécessaire pour les clients qui n'ont pas besoin de leur propre pipeline ML, mais qui ont besoin d'un déploiement rapide de modèles déjà prêts dans des conteneurs.

Pour ses propres modèles, l'équipe a adopté une approche plus lourde et a intégré des éléments clés de Kubeflow, transformant la plateforme en un circuit MLOps à part entière. Cette pile comprenait :

• KServe pour l'hébergement et la gestion des modèles
• Trainer pour l'entraînement et l'optimisation
• Notebooks pour l'expérimentation rapide et l'ajustement fin
• Katib pour l'optimisation des hyperparamètres
• Model Registry et Pipelines pour le stockage et l'automatisation des processus

Pourquoi Sans Knative

La partie la plus controversée de l'intégration a été KServe, qui dispose de deux modes d'inférence : le mode Knative et le mode Standard. La documentation oriente principalement les équipes vers Knative. Pour beaucoup, cela semble être l'option par défaut. Cette approche présente de solides avantages : les services peuvent passer à zéro sans trafic, puis se réveiller rapidement à la demande, et la plateforme gagne des mécanismes pratiques pour les révisions, la division du trafic et les lancements canary.

Mais dBrain a délibérément choisi un chemin différent. La raison n'était pas la performance, mais le coût opérationnel. Knative entraîne avec lui une couche de réseau séparée, des conteneurs de queue proxy supplémentaires à l'intérieur des pods, et une dépendance vis-à-vis des implémentations de gateway comme Istio ou Kourier. Pour une plateforme d'entreprise, cela signifie plus de composants à maintenir, plus d'endroits où les choses peuvent se casser, et un diagnostic plus complexe. En fin de compte, l'équipe a choisi le mode Standard, qui s'appuie sur les Deployments et Services Kubernetes ordinaires et s'adapte mieux au modèle opérationnel déjà existant.

Migration vers Gateway API

Le choix du mode Standard n'a pas résolu tous les problèmes—il les a simplement déplacés vers la couche réseau. Pour que ce mode fonctionne, Gateway API est requis. dBrain avait déjà un support basique pour cette norme, mais la plupart des services de la plateforme avaient historiquement été publiés via Ingress. Garder l'ancien schéma à côté du nouveau n'a pas fonctionné : dans son architecture, KServe en mode Standard ne pouvait pas coexister correctement avec le modèle ingress. L'équipe a envisagé une adaptation ciblée ou un changement du contrôleur ingress, mais l'a considéré comme une mesure temporaire.

À la place, elle a décidé de mener la migration à terme et de déplacer l'ensemble du modèle réseau de la plateforme vers Gateway API. C'était une étape plus coûteuse au départ, mais elle a éliminé les compromis intermédiaires et préparé l'infrastructure à la nouvelle norme de Kubernetes. En effet, l'intégration des services d'IA s'est transformée en une réforme infrastructurelle qui a affecté non seulement la pile ML, mais aussi la publication de tous les services.

Ce Que Cela Signifie

Le cas dBrain illustre bien la réalité actuelle de l'IA d'entreprise : choisir un modèle ou un framework ne suffit plus. Le vrai travail commence là où vous devez combiner le déploiement rapide de modèles prêts à l'emploi, un MLOps à part entière pour le développement interne, et une exploitation prévisible dans Kubernetes. Le succès ne revient pas à la pile la plus à la mode, mais à celle qui peut être maintenue de manière stable en production. C'est pourquoi les décisions d'infrastructure ici influencent les affaires autant que le choix des modèles eux-mêmes.