Comment Snorkel AI a réalisé des économies de plus de 40 % en mettant à l'échelle les charges de travail de machine learning avec Amazon EKS

Les start-ups de machine learning (ML) ont souvent des besoins élevés en matière de capacité de calcul, car elles forment de grands modèles à l'aide de GPU haut de gamme et les déploient à grande échelle à des fins d'inférence. AWS Startups collabore avec les start-ups depuis leur création jusqu'à leur introduction en bourse, et a aidé des milliers de fondateurs et d'innovateurs dans le domaine de l'intelligence artificielle (IA) à développer leurs activités sur Amazon Elastic Kubernetes Service (Amazon EKS). Amazon EKS est idéal pour créer et héberger des modèles de ML, car il offre toute la flexibilité de Kubernetes associée à la sécurité et à la résilience d'un service géré AWS optimisé pour la création de charges de travail conteneurisées à haute disponibilité.

Snorkel AI est l'une de ces entreprises qui a recours aux services d'Amazon EKS. Snorkel AI permet aux entreprises du Fortune 500, aux organismes fédéraux et aux innovateurs dans le domaine de l'IA de créer, d'adapter et de distiller des des modèles de fondation (FM) et de grands modèles de langage (LLM) pour une exécution extrêmement précise dans des jeux de données issus de domaines spécifiques. Les entreprises tirent parti de l'approche axée sur les données de Snorkel en matière de développement de l'IA pour concevoir des services d'IA prêts à la production destinés à divers cas d'utilisation, notamment le traitement des réclamations d'assurance, l'extraction des données financières, l'analyse des essais cliniques et l'accélération de la gestion proactive des puits pour le forage en mer.

Au cours des derniers mois, l'équipe de Snorkel a travaillé d'arrache-pied pour relever les défis uniques liés à la conception d'une infrastructure efficace, capable de prendre en charge les charges de travail de développement du ML sans augmenter les factures liées à l'infrastructure, réduire la vitesse des développeurs ou nuire à l'expérience utilisateur. Son objectif ultime : réduire de plus de 40 % les dépenses de calcul en cluster pour Snorkel Flow, sa plateforme de ML de bout en bout.

Présentation de Snorkel Flow

La plateforme de développement de données d'IA Snorkel Flow de Snorkel permet aux équipes de données de créer rapidement des applications d'IA en utilisant une boucle itérative d'étiquetage programmatique, de formation rapide des modèles et d'analyse des erreurs. Chaque projet démarre lorsque les utilisateurs créent un petit nombre de fonctions d'étiquetage.

Les fonctions d'étiquetage utilisent des heuristiques simples, des bases de données externes, des modèles hérités ou même des appels à de grands modèles de langage pour appliquer des étiquettes à des groupes de données non étiquetés sur la base d'une intuition d'expert codée. L'algorithme de supervision faible de la plateforme associe ces fonctions basées sur des règles pour déterminer l'étiquette la plus probable de chaque dossier. Les utilisateurs forment ensuite un modèle simple basé sur ces points de données probabilistes et évaluent les conséquences de chaque fonction d'étiquetage. Au cours de la phase d'analyse, les utilisateurs étudient les tranches de données sur lesquelles le modèle présente des performances médiocres. Ils créent ou modifient ensuite les fonctions d'étiquetage, entraînent un autre modèle rapide et poursuivent la boucle. Lorsque les utilisateurs sont satisfaits de la qualité de leurs étiquettes, ils créent un modèle final sur une architecture issue de la bibliothèque de modèles (allant de la régression logistique aux FM) et l'exportent pour le déploiement.

En raison de la nature de ce flux de travail, l'infrastructure de Snorkel Flow traverse diverses périodes de forte utilisation des ressources de calcul. Les coûts d'exploitation ont naturellement augmenté à mesure de l'évolution de la clientèle et des capacités des produits de ML de Snorkel Flow. Pour réaliser une croissance efficace, Snorkel a tenté de comprendre comment améliorer ses marges tout en exploitant un logiciel de ML de pointe. Snorkel a mis en œuvre les pratiques suivantes pour réduire de plus de 40 % les coûts de calcul en cluster.

Solutions pour l'optimisation des coûts du cloud 

Les startups proposant des logiciels en tant que service (SaaS) ont souvent la possibilité d'optimiser leurs dépenses liées au cloud ; il est crucial de bien comprendre les facteurs uniques à l'origine de ces coûts.

Dans le cas de Snorkel, deux facteurs importants entraient en jeu :

1. Les charges de travail liées au développement du ML exigent souvent du matériel spécialisé et coûteux, par exemple, des GPU. En règle générale, ces charges de travail sont transmises par paquets.
2. Les entreprises du Fortune 500 et les grands organismes fédéraux, y compris les principales institutions financières ayant mis en place des services informatiques sophistiqués avec des exigences spécifiques en matière de déploiement et de confidentialité des données, utilisent Snorkel en passant par une plateforme conteneurisée.

L'équipe de Snorkel souhaite créer des systèmes qui permettent une mise à l'échelle efficace sans augmentation linéaire des coûts liés à l'infrastructure. Snorkel a donc développé une solution complète de mise à l'échelle automatique adaptée à ses charges de travail de ML sur Amazon EKS afin de répondre aux problèmes découlant des dépenses liées au cloud. Cette solution a non seulement accéléré les charges de travail nécessitant un calcul par paquets, mais a également aidé l'entreprise à atteindre ses objectifs de réduction des coûts.

Outre la solution de mise à l'échelle automatique, Snorkel a mis en place d'autres stratégies qui ont contribué à diminuer de plus de 40 % ses dépenses liées au cloud. En voici les principales :

• Collaborer avec les responsables de l'ingénierie et l'équipe AWS pour adopter des Savings Plans en optimisant la configuration cloud.
• Adapter la taille des ressources en surveillant l'utilisation des nœuds avec Prometheus et en demandant conseil aux ingénieurs backend pour évaluer les besoins en composants de la plateforme.
• Passer à des types de machines virtuelles (VM) économiques sur Amazon EKS et utiliser des instances Amazon Elastic Compute Cloud (Amazon EC2) multi-GPU pour un meilleur rapport prix/performances.
• Mettre en place des modifications des processus internes dans le cadre desquelles les ingénieurs ont travaillé avec les équipes en contact avec les clients afin de réduire au maximum les calculs inexploités.

Dans cet article, Snorkel explique comment relever ces défis de mise à l'échelle afin de concevoir plus aisément une meilleure infrastructure destinée aux systèmes de ML. Si vous ne connaissez pas Kubernetes, nous vous recommandons l'article de présentation de Kubernetes rédigé par Snorkel pour en savoir plus sur les notions de base de ce service ainsi que leur article sur les leçons qu'ils ont tirées de l'utilisation du machine learning sur Kubernetes pour découvrir leur parcours avec Kubernetes jusqu'à présent.

Snorkel Flow sur AWS

Dans la pratique, l'interaction de Snorkel Flow avec AWS suit la séquence décrite ci-dessous. La plateforme Snorkel Flow reposant principalement sur des conteneurs, sa migration vers AWS s'est déroulée de manière quasi fluide.

• Les utilisateurs accèdent à leur instance Snorkel Flow depuis leur navigateur Web, qui pointe vers une règle d'Amazon Route 53.
• Route 53 transmet la demande à un Application Load Balancer.
• L'Application Load Balancer transmet ensuite la demande aux pods Snorkel Flow exécutés sur un cluster EKS partagé. Snorkel est passé du type d'instance EC2 m5 au type m6a afin d'optimiser les coûts, réalisant au passage des économies de calcul de 10 % avec une réduction négligeable des performances par rapport au coût horaire pour le même processeur et la même RAM.
• En outre, Snorkel est passée d'une seule instance GPU g4dn.8xlarge à une instance multi-GPU g4dn.12xlarge pour alimenter quatre fois plus de pods GPU.
• Chaque instance de Snorkel Flow utilise un volume Amazon Elastic File System (Amazon EFS) pour stocker des fichiers sur disque.
• Une file d'attente Redis autohébergée sur un pod de l'instance EC2 contient les tâches entrantes en attendant que les pods master les récupèrent.
• Les métriques EKS sont transmises à Amazon CloudWatch, et des scripts personnalisés surveillent les journaux afin de détecter d'éventuelles performances anormales du cluster.

Cette architecture a fourni une expérience stable et réactive aux utilisateurs de Snorkel Flow.

Repenser la mise à l'échelle

Avant la mise en place de l'architecture décrite dans l'illustration 1, les anciennes itérations de l'infrastructure de Snorkel utilisaient des ressources fixes, mais les utilisateurs de Snorkel trouvaient que ces charges de travail transmises par paquets étaient parfois trop lentes et nuisaient à la qualité de leur expérience sur la plateforme.

La mise à l'échelle manuelle des ressources de calcul s'est révélée impossible et source d'erreurs, et n'est pas parvenue à réduire les coûts liés au cloud même pendant les périodes de faible utilisation. Cette solution associait tous les inconvénients : une faible rentabilité du cloud et des performances beaucoup plus lentes que la normale.

Pour relever ces défis, Snorkel a appliqué la mise à l'échelle automatique sur plusieurs niveaux de son infrastructure, de la manière décrite dans les sections ci-dessous.

Concevoir une infrastructure évolutive et rentable

La distribution Kubernetes de Snorkel Flow implique un ensemble de déploiements exécutés dans un cluster EKS qui contient des pods responsables de l'exécution de divers composants de la plateforme.

Comme le montre l'illustration 2, l'équipe de Snorkel a introduit un nouveau concept pour les pods Kubernetes en vue de surmonter les difficultés uniques que représentait l'utilisation de charges de travail de calcul transmises par paquets : un classement sémantique dans deux catégories, « fixes » ou « flexibles ».

• Les pods fixes ne peuvent pas être déplacés en toute sécurité d'un nœud à l'autre, soit parce qu'ils perdront un état important en mémoire (comme des tâches de calcul en cours sans point de contrôle), soit pour réduire au maximum les interruptions évitables pour les composants fondamentaux de la plateforme (comme l'orchestrateur pour le cluster Ray).
• Les pods flexibles peuvent être déplacés en toute sécurité vers un nouveau nœud. Cette différence est cruciale dans un contexte de mise à l'échelle automatique, car la réduction de la taille des nœuds implique le déplacement des pods hors des nœuds sous-exploités lorsqu'ils sont résiliés.

Cette division en deux catégories offre à Snorkel un moyen spécifique au domaine de réduire automatiquement l'échelle des clusters, ce qui lui permet d'activer l'autoscaler de clusters sur Amazon EKS sans que son service financier ne lui envoie de message toutes les heures.

L'approche initiale de Snorkel consistait à déployer podDisruptionBudgets sur le cluster EKS afin de s'assurer que l'autoscaler de clusters ne déplace pas de pods flexibles pendant la journée et ne déplace aucun pod fixe. Bien qu'efficace, cette approche n'a pas satisfait l'équipe de Snorkel : elle a en effet réduit l'échelle de beaucoup moins de nœuds que le nombre théoriquement optimal.

Pour résoudre ce problème, Snorkel a opté pour l'optimisation de la planification des pods afin de séparer les pods fixes d'un petit groupe fixe de nœuds. Cette mesure planifiait des pods flexibles et des pods master (considérés comme des pods fixes, mais éphémères en raison de la mise à l'échelle automatique des composants master) dans le groupe de nœuds flexible restant.

Ces modifications ont permis à Snorkel de réduire efficacement l'échelle des nœuds flexibles la nuit, lorsqu'il est possible de déplacer en toute sécurité les nœuds flexibles et de réduire l'échelle de la plupart des pods master.

La réduction efficace de l'échelle de la plupart des nœuds du cluster (c'est-à-dire les nœuds flexibles) a permis à Snorkel d'atteindre son objectif de réduction de plus de 40 % des coûts liés au cloud découlant de l'hébergement de Snorkel Flow.

Zoom sur la solution de mise à l'échelle automatique de Snorkel

Snorkel divise la mise en œuvre de la solution détaillée dans la section précédente en trois efforts séquentiels :

1. Snorkel a d'abord instauré la « mise à l'échelle automatique des pods master », un service de mise à l'échelle automatique personnalisé basé sur Redis qui permet à ses pods master d'augmenter ou de diminuer leur échelle en fonction des tâches dans les files d'attente des pods master.
2. L'entreprise a ensuite mis en œuvre la « mise à l'échelle automatique des clusters » en reconfigurant ses déploiements Kubernetes de manière à permettre à l'autoscaler de cluster Kubernetes de réduire l'échelle des nœuds, en plus de l'augmenter pour d'autres nœuds.
3. Enfin, Snorkel a mis en place des « optimisations de réduction de l'échelle des nœuds » en regroupant des pods fixes dans un petit groupe de nœuds fixes afin d'éviter que les pods fixes n'interfèrent avec la réduction de l'échelle des nœuds restants.

Mise à l'échelle automatique des master

La plateforme Snorkel Flow fait du calcul un modèle où les tâches attendent dans les files d'attente Redis et où les master s'exécutent sous forme de processus dans des pods master.

Snorkel a mis en place une solution de mise à l'échelle automatique (illustration 3) pour les pods master en exécutant une fonction récurrente dans l'API backend de Snorkel Flow. Toutes les quelques secondes, cette fonction vérifie la possibilité d'augmentation et de réduction de l'échelle du cluster Kubernetes et de Redis.

Si des tâches sont en attente dans une ou plusieurs files d'attente correspondantes basées sur Redis, la fonction demandera à l'API Kubernetes de fournir des pods master supplémentaires pour traiter ces tâches. Si la file d'attente Redis est vide et qu'aucune tâche n'est en cours d'exécution dans le registre des tâches, la fonction demandera à l'API Kubernetes d'éliminer les pods master afin de libérer des ressources CPU et RAM réservées.

Comme le montre l'illustration 4, le déploiement de cette mise à l'échelle automatique des master a rendu les pods master de Snorkel Flow éphémères, et ils n'apparaissaient plus dans le cluster que lorsque des tâches devaient être traitées.

Mise à l'échelle automatique du cluster

La ressource PodDisruptionBudget protège certains pods des interruptions (par exemple, les redémarrages délibérés) en permettant de spécifier le nombre maximum de réplicas de pods pouvant être indisponibles à un moment donné. Comme le montre l'illustration 5, la définition explicite de cette valeur sur 0 pour un déploiement garantit que l'autoscaler du cluster ne réduira pas l'échelle des nœuds exécutant les pods du déploiement.

La mise en œuvre de cette ressource sur des instances Snorkel Flow hébergées a permis à l'autoscaler de clusters de réduire la taille des nœuds sous-exploités en toute sécurité. Cependant, les économies réalisées par Snorkel étaient insignifiantes, et l'entreprise n'était toujours pas en mesure de réduire l'échelle de la majorité de ses nœuds, car tous les pods de Snorkel Flow étaient protégés par un podDisruptionBudget associé.

Après s'être penchée sur le problème, l'équipe de Snorkel a déterminé que cette protection n'était pas nécessaire en permanence. Les charges de travail étant transmises par paquets, et la plupart des interactions des utilisateurs avec Snorkel Flow ayant lieu pendant les heures de travail du client, il est possible d'assouplir cette mesure de protection en dehors des heures de bureau sans nuire à la sécurité globale. À l'instar de la mise à l'échelle automatique des master, Snorkel a mis en œuvre une fonction récurrente qui « désactivait » podDisruptionBudgets pendant la nuit pour les pods flexibles d'une instance en fixant le nombre maximal de réplicas de pods indisponibles à 1 au lieu de 0 (illustration 6). L'ancienne solution de mise à l'échelle automatique des master, combinée aux fonctionnalités ClusterAutoscaler et PodDisruptionBudget, a permis de réduire l'échelle de plus de composants master sous-exploités qu'auparavant. Les clients qui déploient Snorkel Flow dans leur cloud peuvent configurer cette solution selon leurs besoins.

Optimisations de la réduction de l'échelle des nœuds

Malgré ces améliorations, Snorkel a constaté que l'échelle de la majorité des nœuds sous-exploités n'était pas du tout réduite.

Après avoir examiné le problème de plus près, Snorkel s'est aperçu qu'il provenait du fait que des pods fixes et flexibles occupaient le même nœud. Cela était gênant dans la mesure où un pod fixe, attribué de manière pseudo-aléatoire à un nœud contenant des pods flexibles, « bloquait » ce nœud et empêchait la réduction de son échelle, même s'il était sous-exploité. Ce manque de contrôle sur la planification des pods fixes a entraîné des périodes pendant lesquelles la grande majorité des nœuds du cluster ne pouvaient pas faire l'objet d'une réduction d'échelle, même s'ils représentaient une puissance de calcul bien supérieure à ce qui était nécessaire à l'époque.

Snorkel a utilisé la ressource Kubernetes podAffinities pour résoudre ce problème, ce qui lui a permis de limiter les nœuds sur lesquels un pod pouvait être exécuté en fonction des étiquettes des autres pods déjà exécutés sur un nœud donné. L'équipe a étiqueté les pods pour différencier les pods fixes des pods flexibles, et a ajouté un groupe de lignes de code podAntiAffinity à la configuration de ses déploiements pour garantir que les pods fixes ne sont pas planifiés sur des nœuds exécutant des pods flexibles, et vice versa.

Cette mise en œuvre de podAffinities a permis à Snorkel AI de répartir les nœuds en deux groupes fonctionnels : le groupe fixe de nœuds contenant des pods fixes ne pouvant jamais être déplacés en toute sécurité entre les nœuds (par exemple, Redis en raison du cache), et le groupe flexible de nœuds contenant des pods « flexibles » qui sont soit éphémères (tels que les modules réservés aux travailleurs), soit déplaçables en toute sécurité en dehors des heures de bureau (par exemple, pendant la nuit).

Bien que cela puisse être effectué manuellement pendant la maintenance de la plateforme, Snorkel ne peut pas réduire automatiquement l'échelle des nœuds fixes. Cette solution permet toutefois à l'équipe de réduire automatiquement l'échelle des nœuds flexibles, car les pods impossibles à déplacer sont désormais isolés dans les nœuds fixes.

Conclusion

En partageant ce processus de réflexion et ces solutions, les équipes Snorkel et AWS Startups espèrent aider d'autres start-ups à créer une meilleure infrastructure pour les charges de travail de ML, qui deviennent rapidement prévalentes à mesure que le ML, les grands modèles de langage et les autres FM entrent en phase de production pour les organisations du monde entier.

Assisterez-vous à la conférence AWS re:Invent 2023 ? Ce déploiement sera présenté dans le cadre de la session animée par Snorkel intitulée Se tourner vers l'avenir de l'IA : déploiement de modèles génératifs sur Amazon EKS (session CON312).Ne la manquez pas !

Nous remercions chaleureusement David Hao, Edmond Liu et Alec Xiang d'avoir contribué à concrétiser cette vision technique pour Snorkel. Nous souhaitons également remercier tout particulièrement les personnes susmentionnées ainsi que Matt Casey, Henry Ehrenberg, Anthony Bishopric et l'équipe d'ingénierie des infrastructures de Snorkel au complet pour leurs commentaires pertinents sur cet article.