Systèmes : les avantages et les inconvénients d’exécuter des IA sur Kubernetes

Les avantages de Kubernetes pour l’IA

La popularité de Kubernetes pour les charges de travail liées à l’IA n’est pas le fruit du hasard. Kubernetes offre plusieurs avantages pour des utilisations telles que l’entraînement et l’inférence de modèles d’IA.

L’allocation efficace des ressources. L’un des principaux objectifs de Kubernetes est d’allouer efficacement les ressources CPU, mémoire et réseau. Pour ce faire, il déploie dynamiquement les traitements sur des clusters de serveurs en fonction des besoins en ressources de chaque charge de travail et des serveurs disponibles disposant de ressources suffisantes à un moment donné. L’objectif est d’éviter les situations où certains serveurs sont sous-utilisés tandis que d’autres sont saturés en termes de consommation de ressources en raison d’un placement inefficace des charges de travail.

Une utilisation efficace des ressources est précieuse dans tous les contextes. Elle est particulièrement importante pour l’IA, compte tenu de la forte consommation de ressources des traitements liées à l’IA.

Une grande élasticité. Dans le même ordre d’idées, Kubernetes facilite l’augmentation ou la réduction rapide de l’infrastructure — un autre avantage important pour les traitements d’IA, où les besoins en ressources peuvent varier considérablement au fil du temps.

Par exemple, lors de l’entraînement d’un modèle d’IA, une équipe d’ingénieurs peut avoir besoin d’accéder à une quantité considérable de ressources de calcul et de stockage pour entraîner des modèles. Pendant cette période, elle peut augmenter la capacité de son cluster Kubernetes en ajoutant davantage de serveurs. Une fois l’entraînement terminé, le cluster peut être réduit pour éviter de gaspiller de l’argent en ressources inutiles.

Il est également possible de faire évoluer l’infrastructure à l’aide d’autres types de plateformes d’hébergement. Mais avec Kubernetes, l’évolutivité est simple, car il suffit d’ajouter ou de retirer des serveurs d’un cluster.

L’accès direct au GPU. Grâce à des extensions telles que le Nvidia GPU Operator (un module complémentaire de Kubernetes qui gère les ressources GPU au sein d’un cluster), il est relativement simple d’attribuer un accès GPU aux charges de travail basées sur Kubernetes. Cela vaut non seulement pour les traitements exécutés sur des serveurs « bare-metal » au sein d’un cluster Kubernetes, mais également pour celles hébergées sur des machines virtuelles.

Pour de nombreuses charges de travail d’IA, l’accès au GPU est crucial, car l’énorme puissance de calcul parallèle des GPU est indispensable pour l’entraînement des modèles et l’inférence à grande échelle.

La cohérence entre les environnements de développement/test et ceux de production. Les entreprises peuvent utiliser Kubernetes aussi bien pour développer et tester des traitements que pour les exécuter en production. Le fait de tout réaliser sur la même plateforme garantit la parité des environnements, c’est-à-dire la cohérence entre les environnements de développement/test et de production. Par extension, cela réduit le risque que des différences de configuration entre les environnements entraînent des bogues, des failles de sécurité ou des problèmes de performances que les ingénieurs ne détectent qu’une fois le logiciel en production et accessible aux utilisateurs finaux.

Là encore, la parité des environnements est avantageuse pour la plupart des types de traitements, mais elle s’avère particulièrement précieuse lors du déploiement de modèles d’IA très complexes dont le comportement peut être radicalement modifié par des changements de configuration, tels que des modifications des poids des modèles.

La réduction des risques de dépendance vis-à-vis d’un fournisseur. En tant que plateforme open source, Kubernetes présente moins de risques de dépendance vis-à-vis d’un fournisseur que la plupart des plateformes propriétaires.

Il est important de noter qu’il existe de nombreuses distributions Kubernetes, et que certaines intègrent des outils ou des modules complémentaires propriétaires susceptibles de compliquer la migration entre différents environnements Kubernetes. De ce fait, il serait erroné de supposer que Kubernetes est totalement exempt de problèmes liés à la dépendance vis-à-vis d’un fournisseur. Cependant, il reste plus flexible que l’hébergement de traitements d’IA à l’aide d’un service cloud propriétaire, par exemple.

Cette flexibilité est particulièrement avantageuse pour les entreprises qui en sont aux premières étapes de l’adoption de l’IA. Par exemple, ces utilisateurs peuvent modifier leur technologie d’IA ou passer à d’autres modèles tout en conservant la même infrastructure d’hébergement sous-jacente.

Les inconvénients de Kubernetes pour l’IA

L’hébergement de l’IA sur Kubernetes peut également poser des défis. Parmi les principaux obstacles figurent une complexité accrue, une charge importante, des exigences en matière de modules complémentaires et une optimisation limitée des ressources.

Une complexité accrue. Kubernetes ajoute une couche supplémentaire aux piles d’hébergement qui n’existerait pas si les traitements s’exécutaient directement sur les serveurs, sans orchestrateur. En ce sens, il accroît la complexité technique à laquelle les ingénieurs doivent faire face.

Un surcoût en ressources. Kubernetes augmente également la quantité de ressources nécessaires pour héberger une charge de travail. Le logiciel d’orchestration consomme du CPU, de la mémoire et de l’espace de stockage, ce qui réduit les ressources disponibles pour les charges de travail d’IA proprement dites.

L’allocation des GPU nécessite des modules complémentaires. Dans la plupart des cas, Kubernetes a besoin de modules complémentaires pour allouer les GPU, ce qui ajoute encore à la complexité de l’hébergement des traitements d’IA. Cependant, les entreprises qui exécutent l’IA directement sur des serveurs « bare-metal » équipés de GPU éviteraient ce problème.

Une capacité d’optimisation limitée. Comme indiqué précédemment, Kubernetes peut planifier dynamiquement les traitements de manière à favoriser une utilisation efficace des ressources. Cependant, cette capacité est limitée, principalement parce que Kubernetes ne dispose d’aucun moyen intrinsèque de déterminer avec précision la quantité de CPU, de mémoire ou de GPU dont une charge de travail donnée aura besoin.

Il s'appuie sur les administrateurs pour définir des plages d'allocation des ressources. Si ces plages sont mal définies (ou absentes), les traitements d'IA risquent de ne pas fonctionner de manière optimale par manque de ressources, ou d'entraîner un gaspillage d'argent en raison d'un surprovisionnement.

Quelles alternatives à Kubernetes pour exécuter des traitements d’IA ?

Si Kubernetes ne correspond pas aux besoins d’une entreprise en matière d’IA, d’autres stratégies d’infrastructure sont envisageables, notamment les serveurs autogérés, les fonctions « serverless » et les services d’IA entièrement gérés. Les DSI doivent passer en revue toutes les options afin de déterminer la stratégie la mieux adaptée à leur entreprise.

Des serveurs gérés à la main. L’IA peut s’exécuter directement sur des serveurs, sans faire appel à des capacités d’orchestration. Cela nécessite que les ingénieurs déploient et gèrent manuellement les charges de travail, une approche qui peut convenir aux entreprises qui n’ont qu’une poignée de traitements d’IA à gérer et qui n’ont pas besoin d’augmenter ou de réduire fréquemment la capacité de leur infrastructure d’hébergement.

Des fonctions Serverless. Les traitements d’IA qui s’exécutent périodiquement, comme un agent d’IA qui n’est actif que quelques fois par jour, se prêtent particulièrement bien à l’hébergement via un service de fonctionnalités où toute la partie serveur sous-jacente est masquée, alias serverless. Ces services simplifient la configuration et la gestion pour les entreprises, tout en permettant une utilisation très efficace des ressources. En effet, l’entreprise ne paie les coûts d’infrastructure que lorsque la charge de travail est active.

Des services d’IA en cloud. Pour les traitements d’IA qui doivent fonctionner en continu ou quasi continuellement, une option d’hébergement simple consiste à recourir à des services cloud spécialement conçus pour l’exploitation de modèles d’IA et/ou d’agents. Citons par exemple Amazon Bedrock d’AWS et la plateforme Gemini Enterprise Agent de Google. Ces services fournissent souvent des outils de développement d’IA intégrés, ce qui en fait essentiellement des offres de type « plateforme en tant que service » (PaaS) pour l’IA.

Des services d’IA entièrement gérés par des tiers. Les entreprises qui souhaitent éviter toute la complexité liée à la gestion des traitements d’IA peuvent opter pour des services tiers entièrement gérés. Dans le cadre de cette stratégie, un fournisseur externe héberge les modèles, les agents ou d’autres types de charges de travail et les met à la disposition des clients via des interfaces web ou des API.

Cet article est initialement paru en anglais sur TechTarget.com, une publication sœur du MagIT.