La charge de travail liée à l'IA augmente-t-elle votre facture cloud ?

Nous sommes convaincus que chaque entreprise sera une entreprise d'apprentissage automatique (ML) dans les années à venir. Alors que les entreprises adoptent le machine learning, l'un des principaux défis auxquels elles sont confrontées est la gestion des coûts associés au cloud. L'exécution de charges de travail AI/ML dans le cloud peut rapidement devenir coûteuse, mais grâce à une planification et à une optimisation minutieuses, il est possible de réduire ces coûts de manière significative.

Dans cet article de blog, nous explorerons plusieurs stratégies pour vous aider à optimiser votre infrastructure d'IA, afin de réduire vos dépenses liées au cloud sans compromettre les performances ou l'évolutivité. Voici les grandes catégories à prendre en compte :

1. Mesure et attribut
2. Réduisez les coûts de calcul en utilisant des instances ponctuelles/réservées
3. Choisissez la bonne architecture de déploiement
4. Implémenter l'autoscaling
5. Colocation de calculs et de données
6. Passez à des blocs-notes hébergés à arrêt automatique au lieu de fournir une machine virtuelle dédiée à chaque développeur
7. Utilisez les points de contrôle dans la mesure du possible pour reprendre des emplois de formation de longue durée.
8. Utilisation efficace du GPU

Mesure et attribut

Après avoir travaillé avec de nombreuses organisations et selon notre propre expérience, une grande partie des coûts est due à des erreurs humaines liées à l'oubli de désactiver des machines virtuelles, des services ou à une conception d'architecture incorrecte, ce qui entraîne des coûts supplémentaires. Le fait d'avoir une visibilité complète sur qui est propriétaire de quoi et quels sont les coûts engagés par équipe/projet permet de mettre en évidence plus rapidement la gestion des coûts et permet à chacun d'être responsable de ses propres projets.

Vous ne pouvez pas améliorer ce que vous ne mesurez pas

La toute première étape de l'optimisation de la charge de travail du machine learning consiste à commencer à mesurer et à comptabiliser l'attribution. Voici quelques-unes des initiatives que vous pouvez entreprendre :

1. Suivez les coûts au niveau de chaque microservice, projet ou équipe.
2. Fournir une visibilité des coûts à tous les développeurs et veiller à ce qu'ils soient en mesure de comprendre et de réduire les coûts.
3. Configurez des alertes sur les coûts du cloud.
4. Utilisez des outils tels qu'Infracost.io pour mesurer le coût de l'infrastructure avant le provisionnement si vous utilisez Terraform.

Réduisez les coûts de calcul

Les charges de travail ML entraînent des coûts de calcul énormes, principalement parce qu'elles nécessitent des ressources de calcul élevées, qu'il s'agisse de processeurs ou de GPU, qui s'avèrent tous deux très coûteux. Vous trouverez ci-dessous certaines des mesures que vous pouvez prendre pour réduire les coûts de calcul :

1. Modèle de distillation et d'élagage pour réduire les besoins en ressources de votre modèle
2. Utiliser des instances réservées et ponctuelles pour réduire les coûts. Selon Amazon, les instances EC2 Spot peuvent potentiellement vous faire économiser jusqu'à 90 % de ce que vous dépenseriez autrement en instances à la demande.
3. Choisissez la bonne configuration de ressources: Nous avons souvent constaté que les équipes de machine learning surapprovisionnaient les ressources nécessaires aux services de machine learning et aux emplois de formation. Cela peut impliquer de choisir le mauvais type d'instance si vous travaillez avec des machines virtuelles ou de choisir les mauvaises exigences en matière de ressources de processeur et de mémoire. Il est important d'avoir une visibilité sur le CPU/la mémoire demandé et utilisé afin de pouvoir ajuster les valeurs pour un coût optimal.

👉

Instance ponctuelle : Une instance Spot vous permet d'accéder à la capacité EC2 inutilisée et de l'utiliser à un tarif fortement réduit.

Lorsque vous lancez une instance Spot, vous spécifiez un prix maximum que vous êtes prêt à payer par heure. Si le prix spot pour le type d'instance et la zone de disponibilité que vous demandez est inférieur à votre prix maximum, votre instance sera lancée. Toutefois, si le prix spot pour ce type d'instance et cette zone de disponibilité dépasse votre prix maximum, votre instance peut être résiliée avec un préavis de deux minutes.

👉

Instance réservée : Dans ce cadre, vous vous engagez à utiliser une certaine quantité de capacité EC2 pendant une certaine période. En retour, vous bénéficiez d'une réduction significative sur le prix à la demande de cette capacité.

Nous avons effectué une étude comparative entre les États-Unis et l'est (Virginie du Nord) et avons constaté que :

1. Des instances ponctuelles étaient disponibles pour Tarif 44 % à 62 % moins cher.
2. Des instances réservées d'un an sont disponibles pour Tarif 14 % à 37 % moins cher.

Choisissez l'architecture de déploiement optimale

Les différents cas d'utilisation du machine learning nécessitent des architectures différentes, et le choix d'une conception erronée peut entraîner des différences de coûts considérables. Voici certains des cas d'utilisation et des erreurs les plus courants que nous avons constatés :

1. Inférence en temps réel : dans ce cas, la latence d'inférence du modèle est inférieure à 1 à 2 secondes (souvent de l'ordre de la milliseconde) et le volume de trafic est élevé. Le modèle doit être déployé en tant que API de dimensionnement automatique en temps réel et nous avons généralement trouvé requêtes/seconde pour une meilleure métrique pour une mise à l'échelle automatique du processeur ou de la mémoire dans de nombreux cas d'utilisation du ML. Si le le volume de trafic est élevé (environ 2 à 3 heures par jour) et le modèle est un petit déploiement sans serveur (AWS Lambda) s'avère être un mode de déploiement plus rentable.
2. Inférence asynchrone : dans ce cas, la logique de traitement peut prendre quelques secondes et une file d'attente doit être provisionnée pour une meilleure fiabilité. Dans le cas contraire, cela entraîne des défaillances et une perte de résultats commerciaux. Pour mise à l'échelle automatique, la longueur de la file d'attente est une bonne métrique dans ces cas d'utilisation.
3. Plusieurs petits modèles avec un trafic intense : il s'agit d'un cas d'utilisation courant dans de nombreuses entreprises où les modèles sont spécifiques au client. Dans ce cas, il existe un grand nombre de modèles et chacun d'entre eux reçoit une faible quantité de trafic et les attentes de latence sont assez faibles. Dans ce cas, un conteneur héberge plusieurs modèles et les modèles sont chargés et déchargés dynamiquement en mémoire en fonction des besoins. Il existe ici des défis liés aux modèles déjà chargés dans quels pods et aux demandes doivent être acheminées en conséquence.
4. Traitements/tâches cron peu fréquentes et gourmandes en ressources : cela peut être le cas si les modèles sont entraînés dynamiquement en fonction de certaines actions de l'utilisateur. Dans ce cas, l'inférence asynchrone risque de ne pas fonctionner car la tâche de traitement peut prendre quelques minutes. Dans ce cas, le traitement doit être soumis sous forme de tâches à un orchestrateur de flux de travail et les mises à jour en temps réel de la tâche doivent être mises à jour dans une file de notifications.

Souvent, la modélisation de l'un des cas d'utilisation dans une architecture différente peut entraîner une perte de fiabilité, une latence supplémentaire ou des factures de cloud élevées.

Implémenter l'autoscaling

Les utilisateurs pensent que la mise à l'échelle automatique n'est utile que lorsqu'il y a un volume de trafic élevé et que les machines doivent être augmentées ou réduites en fonction du trafic entrant. Cependant, nous souhaitons également étendre le concept de mise à l'échelle automatique aux environnements de développement de développement afin de réduire les coûts. Certains domaines dans lesquels la mise à l'échelle automatique peut contribuer à réduire considérablement les coûts sont les suivants :

1. Adaptez automatiquement vos besoins de calcul en fonction de la demande: Tirez parti des fonctionnalités de dimensionnement automatique pour ajuster dynamiquement la taille de votre infrastructure en fonction des demandes de charge de travail. En augmentant ou en réduisant automatiquement l'échelle, vous pouvez optimiser l'utilisation des ressources et réduire les coûts pendant les périodes de faible activité. Identifiez les seuils de dimensionnement et les déclencheurs appropriés en fonction de vos modèles de charge de travail afin de garantir une allocation optimale des ressources.
2. Réduisez la valeur infra à zéro lorsqu'elle n'est pas utilisée (par exemple, les instances de développement la nuit) : une partie de l'infra d'une organisation n'est pas nécessaire lorsqu'il n'y a pas d'utilisateurs. La mise en œuvre d'un système permettant de réduire à zéro l'infrastructure informatique lorsque cela n'est pas nécessaire peut générer des économies importantes pour une organisation.
3. Faites une demande de réservation d'instance auprès de votre fournisseur de cloud: en demandant des instances réservées auprès de votre fournisseur de cloud, vous pouvez bénéficier de remises intéressantes lorsque vos besoins en matière de calcul sont plus prévisibles.
4. Imposez l'utilisation d'instances ponctuelles pour les charges de travail sans état : Tirez parti des instances ponctuelles (AWS) ou des machines virtuelles préemptives (Google Cloud) pour les charges de travail ML tolérantes aux pannes. Ces instances sont nettement moins chères que les instances à la demande, ce qui vous permet de réduire les coûts en enchérissant sur la capacité inutilisée. Cependant, soyez conscient du risque de résiliation, par exemple, et concevez votre infrastructure de manière à gérer les interruptions avec élégance. Pour montrer les différences de prix entre les instances à la demande et les instances ponctuelles, comparons les prix du GPU T4 par mois sur AWS et Azure.

g4dn.xlarge : 383$ (sur demande) contre 115$ (au comptant)

NC4 en tant que T4 v3: 383$ (sur demande) contre 49$ (au comptant)

Colocation de calculs et de données

Il est important de colocaliser les données et de les calculer afin de ne pas encourir de coûts d'entrée/sortie importants. Les processus de formation impliquent généralement le téléchargement des données sur les machines sur lesquelles le modèle est entraîné. Voici quelques points à prendre en compte pour éviter des coûts imprévus :

1. Partagez des données entre plusieurs spécialistes des données : Il est important de conserver une copie unique des données d'entraînement d'entrée qui peuvent être utilisées par différents spécialistes des données au lieu de créer une copie pour chaque data cientist. Cela peut être réalisé en installant un volume en lecture seule contenant les données de toutes les machines d'entraînement.
2. Supprimez les volumes inutilisés : Souvent, nous oublions de supprimer les volumes que nous avons pu créer, ce qui entraîne des coûts pour les volumes en suspens.

Arrêt automatique des ordinateurs portables en cas d'inactivité

Souvent, les data scientists démarrent une machine virtuelle, y configurent Jupyter Notebook ou l'utilisent via SSH dans VSCode. Bien que cette approche fonctionne, elle amène souvent les développeurs à oublier d'arrêter les machines virtuelles lorsqu'elles ont fini de fonctionner. Cela entraîne une augmentation des coûts. Il vaut la peine d'investir dans des ordinateurs portables hébergés à arrêt automatique une fois que l'équipe DS compte plus de 5 membres.

‍

Hosted Jupyter Notebooks and VS Code on Kubernetes

Host Jupyter Notebooks and VS Code on Kubernetes for a collaborative and accessible environment to develop, share and test codes.

TrueFoundry Blog Truefoundry

Utilisation efficace du GPU

Les GPU sont largement utilisés dans le ML, mais dans de très rares cas, les GPU sont utilisés efficacement. Cet article jette un excellent éclairage sur la façon dont les GPU sont principalement utilisés aujourd'hui et sur leurs inefficacités. Le partage du GPU entre les charges de travail et des techniques de traitement par lots efficaces sont essentiels pour utiliser efficacement le GPU.

‍

The hidden world of GPU inefficiency

In the last post, we explored how near-future business transformation is threatened by a GPU supply pinch. We know that GPU is a critical resource for rising technologies, that the expense is already…

Towards Data Science Steve Golik

‍

Comment TrueFoundry peut-il contribuer à réduire les coûts ?

TrueFoundry a permis à tous ses clients d'économiser au moins 40 % sur les coûts d'infrastructure.

Nous utilisons Kubernetes

Kubernetes contribue à réduire les coûts en regroupant efficacement les charges de travail entre les nœuds et en s'assurant que le cluster est utilisé efficacement. Il s'agit d'un excellent article qui explique comment Kubernetes contribue à réduire les coûts

‍

The hidden world of GPU inefficiency

In the last post, we explored how near-future business transformation is threatened by a GPU supply pinch. We know that GPU is a critical resource for rising technologies, that the expense is already…

Supergiant.io Kirill Goltsman

‍

Réduisez les coûts de développement de 60 % grâce à la mise à l'échelle automatique basée sur le temps

TrueFoundry permet d'arrêter très facilement vos instances de développement à l'aide de la fonction de dimensionnement automatique basée sur le temps. Les développeurs travaillent principalement environ 40 heures par semaine, alors que les machines fonctionnent près de 128 heures par semaine. Si nous arrêtions les machines de manière efficace, nous pourrions économiser environ 60 % des coûts.

Arrêt automatique des ordinateurs portables en cas d'inactivité

Truefoundry permet aux data scientists de configurer une période d'inactivité sur chaque ordinateur portable, après laquelle celui-ci sera automatiquement éteint.

Cela permet d'économiser de nombreux coûts, en particulier si les ordinateurs portables fonctionnent sur des GPU.

Instances ponctuelles faciles à utiliser

Truefoundry permet aux développeurs d'utiliser très facilement des instances ponctuelles/à la demande. Les développeurs et les data scientists sont ceux qui connaissent le mieux leurs applications. C'est pourquoi nous leur laissons le soin de choisir le meilleur choix pour leurs applications.

Il vous montre également les compromis en termes de coûts entre une instance ponctuelle et une instance à la demande afin que vous puissiez faire le bon choix en fonction de votre cas d'utilisation.

Quotas de ressources pour les équipes et les développeurs

Truefoundry vous permet de définir des quotas de CPU, de mémoire et de GPU pour différentes équipes et développeurs, ce qui permet aux dirigeants d'avoir une idée de la répartition des coûts entre les équipes et de se prémunir contre les erreurs des développeurs en ne leur permettant pas de dépasser les limites allouées.

Informations liées à l'optimisation des coûts

Truefoundry vous indique automatiquement les ressources de processeur et de mémoire recommandées pour votre service en analysant la consommation du service au cours des derniers jours. Il vous recommande actuellement le processeur suggéré, ainsi que les demandes et les limites de mémoire. Cependant, nous prévoyons également de vous recommander automatiquement la stratégie de dimensionnement automatique et l'architecture correcte à l'avenir.

Effectuez l'évaluation

Si vous souhaitez évaluer comment optimiser les coûts de charge de travail liés à l'IA, nous avons créé une évaluation facile à réaliser en 5 minutes.

‍

Nous nous engageons à partager le rapport personnalisé avec vous.