Zesty automatise le partage des GPU pour l'IA sur Kubernetes

Pour la plupart des charges de travail d'IA, un processeur graphique, ou GPU, reste attribué dans sa totalité : une application, une puce, quelle que soit l'activité réelle de la puce. L'annonce part d'un chiffre : 66 % des organisations qui hébergent des modèles d'IA générative exécutent tout ou partie de leur inférence sur Kubernetes, le système open source qui planifie l'exécution de conteneurs sur un groupe de machines. L'inférence est l'étape où un modèle entraîné répond aux requêtes, et la capacité GPU qui lui est dédiée est, selon les termes de l'annonce, coûteuse et souvent contrainte.

Les équipes ont tenté de partager ces puces. L'annonce cite le time-slicing, le Multi-Process Service (MPS) de NVIDIA et le Multi-Instance GPU (MIG), qui divise chaque GPU en partitions matérielles fixes. Son diagnostic est que ces allocations ne peuvent pas suivre une demande d'IA qui monte et qui descend. La mémoire et le calcul finissent bloqués, et les équipes achètent davantage de GPU alors même que la capacité existante reste inutilisée.

La récente publication open source de Run:ai par NVIDIA apporte le fractionnement de GPU à Kubernetes grâce à un opérateur GPU Fractioning, qui impose une limite de mémoire à chaque charge de travail et fonctionne avec les ordonnanceurs de Kubernetes. Mais le fractionnement ne fait que définir la manière dont un GPU peut être divisé. Il ne décide pas qui obtient quoi, et l'annonce souligne que cela exige une couche de décision distincte. Automated Fractional GPUs de Zesty comble ce vide : la solution détermine en continu quelles charges de travail partagent chaque GPU, combien peuvent tourner ensemble en toute sécurité, quelle mémoire chacune reçoit, quel mode de partage convient, et quand les allocations doivent augmenter ou diminuer. Elle s'appuie sur la mémoire et l'utilisation mesurées, sur le comportement observé dans le temps, ainsi que sur les contraintes de latence et de ressources fixées à l'avance par les équipes, et chaque modification reste dans le cadre de ces politiques.

La couche se déploie sous forme d'agent léger à l'intérieur du cluster, aux côtés de l'opérateur de NVIDIA et de l'ordonnanceur de Kubernetes, et prend en charge le time-slicing et le MPS. Rien dans l'application ni dans le modèle n'a besoin de changer, et l'installation ne redémarre pas les charges de travail en cours. Sur une pile GPU prise en charge, Zesty affirme gérer lui-même la configuration de Kubernetes, sans modification manuelle des manifestes.

Les équipes plateforme qui exécutent déjà de l'inférence sur Kubernetes sont celles que cela vise, et elles peuvent l'utiliser dès maintenant, puisque le produit est disponible dans le cadre de la plateforme Zesty. Selon l'annonce, la couche permet de réduire le nombre de puces inutilisées, d'exécuter davantage de charges de travail sur du matériel déjà possédé, d'acheter moins de capacité de réserve pour les pics, et de baisser les coûts d'infrastructure tout en protégeant les performances des applications. L'annonce ne chiffre rien de tout cela : aucun gain d'utilisation, aucun pourcentage d'économies, aucun prix et aucun client. Ce sont là des affirmations du fournisseur, et le test qu'elle laisse ouvert est celui qu'une équipe peut mener elle-même : mesurer l'utilisation sur son propre cluster, avant et après.