IA générative et Kubernetes : ces défis que l’écosystème doit relever

Un manque de standardisation

Pour autant, les concepteurs de modèles et leurs partenaires fournisseurs cloud obfusquent l’infrastructure sous-jacente en proposant de les consommer via des API.

« Les retours de notre communauté d’usagers finaux indiquent un fort besoin d’adopter une pile technologique d’IA la plus optimisée possible, mais ils font face à la prévalence des solutions cloud propriétaire », lance Priyanka Sharma, directrice générale de la CNCF.

« La tendance actuelle consiste à développer des prototypes utilisant des services payants accessibles via des API, ce qui dissimule les spécifications matérielles. J’aimerais voir la communauté élaborer des modèles permettant de reproduire l’expérience offerte par ces services payants, mais avec des solutions open source complètes », avance Page Bailey, Lead Product Manager Generative Models chez Google.

« Les jardins clos ne sont pas pour tout le monde ».

« Ce n’est pas nouveau. Les solutions propriétaires ou moins ouvertes peuvent être plus rapides à adopter et à déployer, mais il y a un coût. Vous investissez dans une solution dirigiste qui offre moins de possibilités de configuration et d’interopérabilité. Les jardins clos ne sont pas pour tout le monde », ajoute Priyanka Sharma.

Selon une étude de la FinOps Foundation, 60 % des grandes entreprises ont vécu ou s’attendent à subir une augmentation rapide des coûts à cause des charges de travail AI/ML, en partie dû à l’explosion du nombre de prototypes.

« C’est inquiétant, mais compréhensible. Nous essayons de déployer le plus rapidement possible des modèles ou de nouvelles versions de modèles, sans qu’il y ait de standards », signale Priyanka Sharma.

« Chaque fois, c’est un énorme effort pour packager et déployer [des modèles ou des composants] en production. Cette histoire est familière. Dans le monde du cloud, nous avons bénéficié d’une forme de standardisation avec l’Open Container Initiative (ou OCI) ».

« Dans le monde de l’IA, l’ordre de grandeur des données et les choix de matériel étant beaucoup plus importants, nous avons également besoin que des normes émergent et qu’elles contribuent à encourager la même interopérabilité et la même cohérence dans la manière dont les charges de travail sont construites, exécutées et déployées », poursuit-elle.

En ce sens, la CNCF a produit un livre blanc pour évaluer l’état de l’art de l’écosystème open source Cloud native en matière d’entraînement et d’inférence de modèles d’IA.

Capacité à gérer une grande quantité de données, distribution des charges de travail sur les GPU, reproductibilité et interprétabilité des modèles d’IA, expérience utilisateur, voilà les défis signalés par la CNCF.

« Kubernetes est largement devenu la référence en matière de plateforme IT, mais je crois qu’il reste des ajustements à apporter », analyse Arun Gupta, vice-président et directeur général de l’écosystème open source chez Intel, lors d’un point presse. « Dans le cadre du cycle de vie de l’apprentissage automatique (ML), il est crucial de se pencher sur des aspects tels que la collecte, le nettoyage, le stockage, les tests et la validation des données. Comment le concept de “cloud native” s’intègre-t-il dans ce cycle continu ? », s’interroge-t-il. « Chacun de ces éléments pourrait-il être envisagé comme un microservice ? Et si oui, cela entraînerait-il une surcharge supplémentaire en matière de communication entre ces services ? Il est essentiel que les acteurs de l’écosystème cloud native comprennent pleinement ces questions pour être des acteurs de premier plan. Bien sûr, nous fournissons déjà l’infrastructure nécessaire, mais pouvons-nous aller plus loin dans notre prise en charge [de l’IA] ? ».

Une plus grande simplicité d’utilisation pour les développeurs

Toutefois, les auteurs du rapport pour la CNCF sont confiants quant aux capacités de l’écosystème à s’adapter à la nouvelle donne induite par l’IA générative.

« Des projets tels que Kubeflow, Ray et KubeRay ouvrent la voie à une expérience plus unifiée et plus conviviale pour l’exécution de charges de travail d’IA dans le cloud. En outre, les recherches en cours sur la planification des GPU, les bases de données vectorielles et la durabilité offrent des solutions prometteuses pour surmonter les limitations », écrivent-ils.

« Nous voyons de plus en plus d’entreprises qui veulent tirer parti des modèles d’IA open source. Elles ont besoin de moyens pour les utiliser en production, mais en général, les personnes qui utilisent ces modèles ne sont pas des spécialistes de l’IA ».

Pour Shaun O’Meara, directeur technique de Mirantis, ces briques s’adressent aux experts de l’IA, aux data scientists et aux ingénieurs ML. « Nous voyons de plus en plus d’entreprises qui veulent tirer parti des modèles d’IA open source. Elles ont besoin de moyens pour les utiliser en production, mais en général, les personnes qui utilisent ces modèles ne sont pas des spécialistes de l’IA », observe-t-il auprès du MagIT. « Nous commençons donc également à nous concentrer sur la manière dont nous pouvons aider les clients à construire des architectures RAG et à héberger cette couche d’inférence, mais en utilisant uniquement des capacités open source ».

De même, le CTO de Mirantis évoque des projets en cours avec des clients européens de l’entreprise, pour déployer des modèles d’IA générative sur site. « Nous faisons du mieux possible, mais il n’y a pas de méthode standardisée, unifiée pour le faire ».

Lors des sessions consacrées à Kubeflow, Christian Kadner, développeur logiciel chez IBM, a évoqué les évolutions de Kserve, le serveur d’inférence rattaché au framework. L’outil a notamment été choisi pour déployer vLLM, un framework optimisé pour l’inférence de grands modèles de langage. IBM a également travaillé sur le projet Text Generation Inference (TGI) d’Hugging Face avant que ce dernier décide d’en restreindre la licence. Depuis, IBM propose un fork optimisé pour KServe et Red Hat OpenShift. « KServe, TGI et vLLM sont très efficaces pour exécuter des LLMs, mais, en tant que développeurs, c’est toujours difficile d’intégrer ces grands modèles de langage dans vos applications, parce que les dévs n’ont pas les connaissances suffisantes pour régler les problèmes ».

Les développeurs d’IBM participent au projet open source (sous licence Apache 2.0) Caikit, censé offrir une couche d’abstraction pour que les développeurs consomment les modèles à travers des API, comme ils le feraient avec ceux d’OpenAI, de Mistral AI ou de GCP. « Caikit permet de gérer les processus de TGIS, de la plateforme Kubernetes – dans notre cas OpenShift – et de profiter d’Istio et de Knative », déclare Christian Kadner.

Mieux prendre en charge les GPU avec Kubernetes

De son côté, Timothée Lacroix évoque la complexité, même pour un spécialiste de l’IA, de comprendre comment et pourquoi un GPU rencontre un problème. « Je me sens comme un utilisateur final [de l’infrastructure]. Cela fait un an environ que j’exploite Kubernetes. Quand je déploie quelque chose en production, je ne veux pas me soucier si le GPU que j’utilise “meurt” de manière étrange. Tous les aspects de vérification de la santé des clusters devraient être présents dans un projet tenu par la communauté cloud native ».

Pour Lachlan Evenson, Principal Program Manager chez Microsoft et membre du comité de gouvernance de la CNCF, le fait qu’OpenAI, Mistral AI et d’autres exploitent Kubernetes à large échelle est le témoignage de « sa grande flexibilité ». « Nous avons réussi à exécuter ces nouvelles charges de travail en production pour lesquelles [Kubernetes] n’a pas été conçu. Cela témoigne non seulement de la pertinence de cette communauté [open source], mais aussi de l’extensibilité que nous avons intégrée dans cette plateforme ».

« Nous avons encore beaucoup de travail à faire pour rendre le matériel, les logiciels et la scalabilité, la planification et la tolérance aux pannes bien meilleurs. Cela viendra avec le temps ».

« Nous avons encore beaucoup de travail à faire pour rendre le matériel, les logiciels et la scalabilité, la planification et la tolérance aux pannes bien meilleurs. Cela viendra avec le temps », estime le responsable de programmes open source chez Microsoft.

Avant que le déploiement d’infrastructure soit transparent pour les développeurs ou que la surveillance des pods s’exécutant sur des GPU s’améliore, il faut régler un certain nombre de problèmes, explique Kevin Klues, ingénieur distingué chez Nvidia. « Il faut changer le mécanisme de règles dans Kubernetes pour demander l’accès à des GPU, et permettre un meilleur partage des ressources GPU au niveau d’un nœud », résume-t-il lors d’une session.

Si plusieurs techniques de partage de ressources existent (time-slicing, Multi Process Service Multi-Instance, vGPU, CUDA Streams), il faut idéalement les combiner, sachant que certaines de ces techniques ne permettent pas de récupérer l’ensemble des métriques nécessaires au suivi du fonctionnement des clusters de GPU. Une fonctionnalité nommée Dynamic Resource Allocation (DRA), en alpha depuis Kubernetes 1.26, doit résoudre ces deux difficultés, mais la tolérance aux pannes restera en grande partie dépendante de logiciels et d’équipements propriétaires.