Une équipe de 2 personnes au service de 1,5 million de personnes avec TrueFoundry

Au cours des derniers mois, nous avons eu l'occasion de travailler avec une équipe peu nombreuse. Ils ont développé un modèle d'apprentissage profond de pointe et créé des partenariats pour le proposer avec talent à plus de 10 millions d'utilisateurs.

La dernière pièce manquante de leur histoire d'impact était la gestion de l'ingénierie nécessaire pour y parvenir. Le modèle exigeait beaucoup de ressources de calcul et, à l'échelle nécessaire pour proposer ce modèle à ses utilisateurs finaux, ils avaient besoin d'une infrastructure fiable et performante qu'ils pouvaient gérer à deux (1 ingénieur DevOps et 1 ingénieur ML).

Nécessité d'un déploiement asynchrone

Le modèle a été conçu pour traiter des entrées audio de différentes tailles. Étant donné que le modèle avait un temps de traitement élevé (environ 5 secondes en moyenne), il avait besoin d'une inférence asynchrone pour chaque demande afin de traiter ces demandes et d'y répondre.

L'équipe avait développé une pile sur AWS Sagemaker

L'équipe a construit sa pile initiale pour servir le modèle sur Sagemaker. Cependant, lorsqu'ils ont réalisé leur premier projet pilote en utilisant cette conception, ils se sont rendu compte qu'il serait difficile de servir le modèle de manière fiable à l'échelle souhaitée avec cette pile.

Les utilisateurs ont été confrontés à des retards de 8 à 10 minutes

Même après avoir utilisé la configuration asynchrone, étant donné que les instances mettaient du temps à évoluer (8 à 10 minutes par machine), l'expérience de l'utilisateur final était compromise lorsqu'il a dû supporter ce décalage.

Cependant, pendant le PoC, ils ont dû faire face à d'énormes retards dans les temps de réponse. Comme la plupart des commandes liées à SageMaker étaient novices, ils ont perdu un temps critique pour trouver la raison de ces retards. Certains des défis auxquels ils ont été confrontés étaient les suivants :

1. Difficile à apprendre : En tant que DS/MLE, ils ont eu du mal à comprendre les nouveaux concepts nécessaires à l'utilisation de Sagemaker.
2. Visibilité limitée : L'analyse des causes profondes des problèmes, en particulier en production, s'est révélée difficile en raison de tableaux de bord et d'interfaces peu intuitifs.
3. Difficile à dimensionner : La mise à l'échelle de Sagamaker a été lente, ce qui a entraîné des retards dans les réponses des utilisateurs et une mauvaise expérience client.
4. Quota distinct : AWS vous demande de présenter un argument distinct pour obtenir de la capacité pour les instances GPU réservées à SageMaker. L'équipe a trouvé ce processus lent et restrictif.
5. Coûteux : L'utilisation de GPU avec Sagemaker a coûté cher à l'équipe, car Sagemaker up note ces instances de 25 à 40 % par rapport à l'EKS brut.

Après le PoC, l'équipe a perdu confiance en Sagemaker et a décidé qu'elle avait besoin d'une solution que les deux (un ingénieur ML et un ingénieur DevOps) pourraient proposer à leur public cible de plus de 10 millions d'utilisateurs.

Déploiement du système sur TrueFoundry en moins de 2 jours

Lorsque nous avons commencé à collaborer avec l'équipe, leur projet pilote était dans environ 7 jours. Nous avons assuré à l'équipe que nous pouvions les aider à migrer l'ensemble de la pile et à la reconstruire à l'aide des modules TrueFoundry en moins de 2 jours, afin qu'ils aient suffisamment de temps pour tester avant que leur pilote ne passe en production.

Mise à l'échelle beaucoup plus rapide

L'équipe a effectué des benchmarks en envoyant une rafale de 88 requêtes au modèle pour comparer les performances par rapport à Sagemaker. True Foundry à grande échelle 78 % plus rapide que Sagemaker, ce qui donne à l'utilisateur des réponses beaucoup plus rapides. Le le temps nécessaire pour répondre à la requête de bout en bout était 40 % plus rapide avec TrueFoundry.

‍

‍

‍

Mise à l'échelle fiable jusqu'à plus de 150 nœuds

L'équipe a simplement pu étendre l'application à plus de 150 nœuds GPU pour les raisons suivantes :

1. Facile à configurer : Il leur suffisait de modifier un argument sur l'interface utilisateur et pouvaient facilement configurer des règles de dimensionnement automatique en fonction de l'arriéré des demandes entrantes. Cela aurait autrement nécessité de multiples allers-retours avec l'équipe d'ingénierie.

2. Quota GPU augmenté : Avec TrueFoundry, ils pouvaient utiliser à la fois Spot et Raw ECS. En raison de la pénurie de GPU chez les fournisseurs de cloud, TrueFoundry a également donné à l'équipe la possibilité de s'adapter à différents fournisseurs de GPU et à différentes régions.

3. Utilisation ponctuelle et mise à l'échelle automatique : L'équipe n'a dû déployer aucun effort supplémentaire pour configurer l'utilisation d'instances ponctuelles pour ses services. Les instances ont également été réduites lorsque le trafic était faible. En utilisant le mécanisme de fiabilité de TrueFoundry pour l'utilisation ponctuelle et les paramètres de mise à l'échelle automatique, l'équipe a économisé plus de 100 000 dollars pendant la période pilote.
4. Environnement de développement et de démonstration : L'équipe a également déployé un service de développement et de démonstration du modèle pour recueillir des commentaires tout en réduisant la taille des machines lorsqu'elles ne sont pas utilisées.

1,5 million d'utilisateurs sont déjà servis et ce chiffre augmente de jour en jour !

En utilisant True Foundry, les 2 membres de l'équipe peuvent gérer l'intégralité de leur charge de travail, qui s'étend souvent à plus de 150 nœuds GPU ! par eux-mêmes. En travaillant avec nous, l'élément le plus remarquable qui a retenu l'attention de l'équipe a été notre service client et nos faibles temps de réponse. TrueFoundry investit dans le succès de ses clients et espère que tous nos clients pourront évoluer et créer un impact à des échelles similaires à celles de ce projet !