Comment Forethought économise plus de 66% sur les coûts des modèles d’IA générative en utilisant Amazon SageMaker

Forethought économise 66% sur les coûts des modèles d'IA générative avec Amazon SageMaker.

Cet article est co-écrit avec Jad Chamoun, Directeur de l’Ingénierie chez Forethought Technologies, Inc. et Salina Wu, Ingénieur Principal en ML chez Forethought Technologies, Inc.

Forethought est une suite d’IA générative leader pour le service client. Au coeur de sa suite se trouve la technologie innovante SupportGPT™ qui utilise l’apprentissage automatique pour transformer le cycle de vie du support client – en augmentant la déflection, en améliorant le CSAT et en augmentant la productivité des agents. SupportGPT™ exploite des systèmes de recherche d’informations (IR) de pointe et des modèles de langage volumineux (LLMs) pour alimenter plus de 30 millions d’interactions avec les clients chaque année.

Le cas d’utilisation principal de SupportGPT consiste à améliorer la qualité et l’efficacité des interactions et des opérations de support client. En utilisant des systèmes IR de pointe alimentés par des modèles de plongement et de classement, SupportGPT peut rapidement rechercher des informations pertinentes et fournir des réponses précises et concises aux requêtes des clients. Forethought utilise des modèles fins accordés par client pour détecter les intentions des clients afin de résoudre les interactions avec les clients. L’intégration de grands modèles de langage aide à humaniser l’interaction avec les agents automatisés, créant une expérience de support plus engageante et satisfaisante.

• AI Time Journal présente un eBook révolutionnaire sur les tendances de l’IA en 2023.
• Règles de base pour l’ère de la guerre de l’IA
• Robots de livraison de nourriture Uber Eats prêts à être utilisés dans plusieurs villes américaines.

SupportGPT assiste également les agents de support client en offrant des suggestions d’autocomplétion et en élaborant des réponses appropriées aux tickets des clients qui sont alignées sur les réponses précédentes de l’entreprise. En utilisant des modèles de langage avancés, les agents peuvent répondre aux préoccupations des clients plus rapidement et avec plus de précision, ce qui se traduit par une plus grande satisfaction client.

De plus, l’architecture de SupportGPT permet de détecter les lacunes dans les bases de connaissances de support, ce qui aide les agents à fournir des informations plus précises aux clients. Une fois ces lacunes identifiées, SupportGPT peut générer automatiquement des articles et d’autres contenus pour combler ces vides de connaissances, assurant que la base de connaissances de support reste axée sur le client et à jour.

Dans cet article, nous partageons comment Forethought utilise les points de terminaison multi-modèles d’Amazon SageMaker dans les cas d’utilisation de l’IA générative pour économiser plus de 66% de coûts.

Défis d’infrastructure

Pour aider à mettre ces capacités sur le marché, Forethought met efficacement à l’échelle ses charges de travail ML et fournit des solutions hyper-personnalisées adaptées à chaque cas d’utilisation spécifique du client. Cette hyper-personnalisation est obtenue en affinant les modèles de plongement et les classificateurs sur les données des clients, assurant des résultats de recherche d’informations précis et des connaissances de domaine qui répondent aux besoins uniques de chaque client. Les modèles d’autocomplétion personnalisés sont également affinés sur les données des clients pour améliorer encore l’exactitude et la pertinence des réponses générées.

Un des défis importants du traitement de l’IA est l’utilisation efficace des ressources matérielles telles que les GPU. Pour relever ce défi, Forethought utilise des points de terminaison multi-modèles (MMEs) de SageMaker pour exécuter plusieurs modèles d’IA sur un seul point de terminaison et les mettre à l’échelle. Comme l’hyper-personnalisation des modèles nécessite que des modèles uniques soient formés et déployés, le nombre de modèles augmente linéairement avec le nombre de clients, ce qui peut devenir coûteux.

Pour atteindre le bon équilibre entre les performances pour l’inférence en temps réel et les coûts, Forethought a choisi d’utiliser des MME de SageMaker, qui prennent en charge l’accélération GPU. Les MME de SageMaker permettent à Forethought de fournir des solutions haute performance, évolutives et rentables avec une latence subseconde, traitant plusieurs scénarios de support client à grande échelle.

SageMaker et Forethought

SageMaker est un service entièrement géré qui offre aux développeurs et aux scientifiques des données la possibilité de construire, de former et de déployer rapidement des modèles ML. Les MME de SageMaker fournissent une solution évolutive et rentable pour déployer un grand nombre de modèles pour l’inférence en temps réel. Les MME utilisent un conteneur de service partagé et une flotte de ressources qui peuvent utiliser des instances accélérées telles que les GPU pour héberger tous vos modèles. Cela réduit les coûts d’hébergement en maximisant l’utilisation des points de terminaison par rapport à l’utilisation de points de terminaison à modèle unique. Il réduit également les frais généraux de déploiement car SageMaker gère le chargement et le déchargement des modèles en mémoire et les met à l’échelle en fonction des modèles de trafic de point de terminaison. De plus, tous les points de terminaison temps réel de SageMaker bénéficient de capacités intégrées de gestion et de surveillance des modèles, telles que l’inclusion de variantes d’ombre, l’auto-scaling et l’intégration native avec Amazon CloudWatch (pour plus d’informations, voir les métriques CloudWatch pour les déploiements de points de terminaison multi-modèles).

Comme Forethought a grandi pour héberger des centaines de modèles qui nécessitaient également des ressources GPU, nous avons vu une opportunité de créer une architecture plus rentable, fiable et gérable grâce aux MME de SageMaker. Avant de migrer vers les MME de SageMaker, nos modèles étaient déployés sur Kubernetes sur Amazon Elastic Kubernetes Service (Amazon EKS). Bien qu’Amazon EKS fournisse des capacités de gestion, il était immédiatement évident que nous gérions une infrastructure qui n’était pas spécifiquement adaptée à l’inférence. Forethought devait gérer l’inférence de modèle sur Amazon EKS lui-même, ce qui était un fardeau pour l’efficacité de l’ingénierie. Par exemple, afin de partager des ressources GPU coûteuses entre plusieurs modèles, nous étions responsables d’allouer des fractions de mémoire rigides aux modèles qui étaient spécifiées lors du déploiement. Nous voulions aborder les problèmes clés suivants avec notre infrastructure existante:

• Coût élevé – Pour nous assurer que chaque modèle disposait de suffisamment de ressources, nous étions très prudents quant au nombre de modèles à ajuster par instance. Cela a entraîné des coûts beaucoup plus élevés pour l’hébergement des modèles que nécessaire.
• Faible fiabilité – Malgré une allocation mémoire prudente, tous les modèles n’ont pas les mêmes exigences, et il arrivait parfois que certains modèles génèrent des erreurs de dépassement de mémoire (OOM).
• Gestion inefficace – Nous devions gérer différents manifestes de déploiement pour chaque type de modèle (tels que les classificateurs, les embeddings et l’autocomplétion), ce qui était chronophage et sujet aux erreurs. Nous devions également maintenir la logique pour déterminer l’allocation mémoire pour différents types de modèles.

En fin de compte, nous avions besoin d’une plate-forme d’inférence pour prendre en charge le travail lourd de la gestion de nos modèles en temps d’exécution afin d’améliorer le coût, la fiabilité et la gestion de la mise à disposition de nos modèles. Les MME de SageMaker nous ont permis de répondre à ces besoins.

Grâce à son chargement et déchargement de modèles intelligent et dynamique, et à ses capacités de mise à l’échelle, les MME de SageMaker ont fourni une solution considérablement moins coûteuse et plus fiable pour l’hébergement de nos modèles. Nous pouvons maintenant ajuster beaucoup plus de modèles par instance et ne pas avoir à nous soucier des erreurs OOM car les MME de SageMaker gèrent le chargement et le déchargement des modèles de manière dynamique. De plus, les déploiements sont maintenant aussi simples que d’appeler les API SageMaker de Boto3 et d’attacher les bonnes politiques de mise à l’échelle automatique.

Le diagramme suivant illustre notre architecture héritée.

Pour commencer notre migration vers les MME de SageMaker, nous avons identifié les meilleurs cas d’utilisation pour les MME et les modèles qui bénéficieraient le plus de ce changement. Les MME sont mieux utilisés pour les éléments suivants:

• Les modèles qui sont censés avoir une faible latence mais peuvent supporter un temps de démarrage à froid (lorsqu’ils sont chargés pour la première fois)
• Les modèles qui sont appelés souvent et de manière cohérente
• Les modèles qui ont besoin de ressources GPU partielles
• Les modèles qui partagent des exigences communes et une logique d’inférence

Nous avons identifié nos modèles d’embedding et nos modèles de langage d’autocomplétion comme les meilleurs candidats pour notre migration. Pour organiser ces modèles sous les MME, nous créerions une MME par type de modèle ou de tâche, une pour nos modèles d’embedding, et une autre pour nos modèles de langage d’autocomplétion.

Nous avions déjà une couche API au-dessus de nos modèles pour la gestion et l’inférence de modèles. Notre tâche consistait à retravailler la façon dont cette API déployait et gérait l’inférence sur les modèles sous le capot avec SageMaker, avec des modifications minimales de la façon dont les clients et les équipes de produits interagissaient avec l’API. Nous devions également empaqueter nos modèles et notre logique d’inférence personnalisée pour être compatibles avec le serveur d’inférence NVIDIA Triton en utilisant les MME de SageMaker.

Le diagramme suivant illustre notre nouvelle architecture.

Logique d’inférence personnalisée

Avant de migrer vers SageMaker, le code d’inférence personnalisé (prétraitement et post-traitement) de Forethought s’exécutait dans la couche API lorsqu’un modèle était invoqué. L’objectif était de transférer cette fonctionnalité au modèle lui-même pour clarifier la séparation des responsabilités, modulariser et simplifier leur code, et réduire la charge sur l’API.

Embeddings

Les modèles d’embedding de Forethought se composent de deux artefacts de modèle PyTorch, et la demande d’inférence détermine quel modèle appeler. Chaque modèle nécessite du texte prétraité en entrée. Les principaux défis étaient d’intégrer une étape de prétraitement et d’accommoder deux artefacts de modèle par définition de modèle. Pour répondre au besoin de plusieurs étapes dans la logique d’inférence, Forethought a développé un modèle d’ensemble Triton avec deux étapes : un processus de prétraitement de backend Python et un appel de modèle de backend PyTorch. Les modèles d’ensemble permettent de définir et d’ordonner les étapes de la logique d’inférence, chaque étape étant représentée par un modèle Triton de n’importe quel type de backend. Pour assurer la compatibilité avec le backend PyTorch de Triton, les artefacts de modèle existants ont été convertis en format TorchScript. Des modèles Triton distincts ont été créés pour chaque définition de modèle, et la couche API de Forethought était responsable de déterminer le TargetModel approprié à invoquer en fonction de la demande entrante.

Autocomplete

Les modèles d’autocomplétion (séquence à séquence) présentaient un ensemble distinct d’exigences. En particulier, nous devions permettre la capacité de boucler à travers plusieurs appels de modèles et de mettre en cache des entrées substantielles pour chaque appel, tout en maintenant une faible latence. De plus, ces modèles nécessitaient des étapes de prétraitement et de post-traitement. Pour répondre à ces exigences et atteindre la flexibilité souhaitée, Forethought a développé des modèles MME d’autocomplétion utilisant le backend Python de Triton, qui offre l’avantage d’écrire le modèle en tant que code Python.

Benchmarking

Après que les formes du modèle Triton ont été déterminées, nous avons déployé des modèles sur des points de terminaison de mise en scène et effectué des tests de référence de ressources et de performances. Notre objectif principal était de déterminer la latence pour les modèles de démarrage à froid par rapport aux modèles en mémoire, et comment la latence était affectée par la taille de requête et la concurrence. Nous voulions également savoir combien de modèles pouvaient être installés sur chaque instance, combien de modèles causeraient le dimensionnement des instances avec notre politique de dimensionnement automatique et à quelle vitesse le dimensionnement se produirait. En suivant les types d’instances que nous utilisions déjà, nous avons effectué nos tests de référence avec les instances ml.g4dn.xlarge et ml.g4dn.2xlarge.

Résultats

Le tableau suivant résume nos résultats.

Taille de la requête	Latence de démarrage à froid	Latence d’inférence en cache	Latence de concurrence (5 requêtes)
Petite (30 jetons)	12,7 secondes	0,03 seconde	0,12 seconde
IPGirl (250 jetons)	12,7 secondes	0,05 seconde	0,12 seconde
Grande (550 jetons)	12,7 secondes	0,13 seconde	0,12 seconde

Remarquablement, la latence pour les requêtes de démarrage à froid est significativement plus élevée que la latence pour les requêtes d’inférence en cache. Cela est dû au fait que le modèle doit être chargé à partir du disque ou d’Amazon Simple Storage Service (Amazon S3) lorsqu’une requête de démarrage à froid est effectuée. La latence pour les requêtes concurrentes est également plus élevée que la latence pour les requêtes simples. Cela est dû au fait que le modèle doit être partagé entre des requêtes concurrentes, ce qui peut entraîner une contention.

Le tableau suivant compare la latence des anciens modèles et des modèles SageMaker.

Taille de la requête	Anciens modèles	Modèles SageMaker
Petite (30 jetons)	0,74 seconde	0,24 seconde
IPGirl (250 jetons)	0,74 seconde	0,24 seconde
Grande (550 jetons)	0,80 seconde	0,32 seconde

Dans l’ensemble, les modèles SageMaker sont un meilleur choix pour l’hébergement de modèles d’autocomplétion que les anciens modèles. Ils offrent une latence plus faible, une évolutivité, une fiabilité et une sécurité supérieures.

Utilisation des ressources

Dans notre quête pour déterminer le nombre optimal de modèles qui pourraient être installés sur chaque instance, nous avons effectué une série de tests. Notre expérience consistait à charger les modèles dans nos points de terminaison en utilisant un type d’instance ml.g4dn.xlarge, sans aucune politique de dimensionnement automatique.

Ces instances particulières offrent 15,5 Go de mémoire, et nous avons visé à atteindre environ 80 % d’utilisation de mémoire GPU par instance. Compte tenu de la taille de chaque artefact de modèle d’encodeur, nous avons réussi à trouver le nombre optimal d’encodeurs Triton à charger sur une instance pour atteindre notre utilisation ciblée de mémoire GPU. De plus, étant donné que chacun de nos modèles d’incorporation correspond à deux modèles d’encodeur Triton, nous avons pu héberger un nombre défini de modèles d’incorporation par instance. En conséquence, nous avons calculé le nombre total d’instances nécessaires pour servir tous nos modèles d’incorporation. Cette expérience a été cruciale pour optimiser notre utilisation des ressources et améliorer l’efficacité de nos modèles.

Nous avons effectué des tests de référence similaires pour nos modèles d’autocomplétion. Ces modèles avaient chacun une taille d’environ 292,0 Mo. Lorsque nous avons testé combien de modèles pourraient tenir sur une seule instance ml.g4dn.xlarge, nous avons remarqué que nous ne pouvions en charger que quatre avant que notre instance ne commence à décharger des modèles, malgré leur petite taille. Nos principales préoccupations étaient :

• Raison de la forte utilisation de la mémoire CPU
• Raison du déchargement des modèles lorsque nous avons essayé d’en charger un autre au lieu du modèle utilisé le moins récemment (LRU)

Nous avons pu identifier la cause première de la flambée de l’utilisation de la mémoire venant de l’initialisation de notre environnement d’exécution CUDA dans notre modèle Python, ce qui était nécessaire pour déplacer nos modèles et données sur et hors du dispositif GPU. CUDA charge de nombreuses dépendances externes dans la mémoire CPU lors de l’initialisation de l’environnement d’exécution. Comme le backend Triton PyTorch gère et abstrait le déplacement des données sur et hors du dispositif GPU, nous n’avons pas rencontré ce problème pour nos modèles d’insertion. Pour remédier à cela, nous avons essayé d’utiliser des instances ml.g4dn.2xlarge, qui avaient la même quantité de mémoire GPU mais deux fois plus de mémoire CPU. De plus, nous avons ajouté plusieurs optimisations mineures dans notre code backend Python, notamment la suppression des tenseurs après utilisation, la vidange du cache, la désactivation des gradients et la collecte des déchets. Avec le type d’instance plus grand, nous avons pu charger 10 modèles par instance, et l’utilisation de la mémoire CPU et GPU est devenue beaucoup plus alignée.

Le diagramme suivant illustre cette architecture.

Mise à l’échelle automatique

Nous avons attaché des stratégies de mise à l’échelle automatique à la fois pour nos MME d’insertion et d’autocomplétion. Notre stratégie pour notre point de terminaison d’insertion visait une utilisation moyenne de la mémoire GPU de 80 % en utilisant des mesures personnalisées. Nos modèles d’autocomplétion ont connu un pic de trafic élevé pendant les heures de bureau et un trafic minimal pendant la nuit. Pour cette raison, nous avons créé une politique de mise à l’échelle automatique basée sur InvocationsPerInstance afin de pouvoir nous adapter aux modèles de trafic, économiser sur les coûts sans sacrifier la fiabilité. Sur la base de nos tests de référence d’utilisation des ressources, nous avons configuré nos politiques de mise à l’échelle avec une cible de 225 InvocationsPerInstance.

Déployer la logique et le pipeline

Créer un MME sur SageMaker est simple et similaire à la création de tout autre point de terminaison sur SageMaker. Après la création du point de terminaison, l’ajout de modèles supplémentaires au point de terminaison est aussi simple que de déplacer l’artefact du modèle vers le chemin S3 que le point de terminaison cible ; à ce stade, nous pouvons effectuer des demandes d’inférence sur notre nouveau modèle.

Nous avons défini une logique qui prendrait en compte les métadonnées du modèle, formaterait le point de terminaison de manière déterministe en fonction des métadonnées et vérifierait si le point de terminaison existait. S’il n’existait pas, nous créions le point de terminaison et ajoutions l’artefact du modèle Triton au chemin S3 pour le point de terminaison (également formaté de manière déterministe). Par exemple, si les métadonnées du modèle indiquaient qu’il s’agit d’un modèle d’autocomplétion, il créerait un point de terminaison pour les modèles d’autocomplétion et un chemin S3 associé pour les artefacts de modèle d’autocomplétion. Si le point de terminaison existait, nous copiions l’artefact du modèle vers le chemin S3.

Maintenant que nous avions les formes de nos modèles MME et la fonctionnalité pour déployer nos modèles sur MME, nous avions besoin d’un moyen d’automatiser le déploiement. Nos utilisateurs doivent spécifier quel modèle ils veulent déployer ; nous gérons l’emballage et le déploiement du modèle. Le code d’inférence personnalisé empaqueté avec le modèle est versionné et poussé sur Amazon S3 ; dans l’étape d’emballage, nous extrayons le code d’inférence selon la version spécifiée (ou la dernière version) et utilisons des fichiers YAML qui indiquent les structures de fichier des modèles Triton.

Une de nos exigences était que tous nos modèles MME soient chargés en mémoire pour éviter toute latence de démarrage à froid lors des demandes d’inférence de production pour charger les modèles. Pour ce faire, nous provisionnons suffisamment de ressources pour contenir tous nos modèles (selon les tests de référence précédents) et appelons chaque modèle dans notre MME à un rythme horaire.

Le diagramme suivant illustre le pipeline de déploiement de modèle.

Le diagramme suivant illustre le pipeline de préchauffage du modèle.

Invocation du modèle

Notre couche API existante fournit une abstraction aux appelants pour effectuer des inférences sur tous nos modèles d’IA. Cela signifie que nous avons seulement eu à ajouter des fonctionnalités à la couche API pour appeler le SageMaker MME avec le modèle cible approprié en fonction de la demande d’inférence, sans aucun changement dans le code d’appel. Le code d’inférence SageMaker prend la demande d’inférence, formate les entrées Triton définies dans nos modèles Triton et appelle les MME en utilisant Boto3.

Avantages économiques

Forethought a réalisé des progrès significatifs pour réduire les coûts d’hébergement de modèle et atténuer les erreurs de mémoire insuffisante grâce à la migration vers les MME SageMaker. Avant ce changement, nous utilisions des instances ml.g4dn.xlarge exécutées dans Amazon EKS. Avec la transition vers les MME, nous avons découvert que nous pouvions héberger 12 modèles d’intégration par instance tout en atteignant une utilisation de mémoire GPU de 80 %. Cela a conduit à une baisse significative de nos dépenses mensuelles. Pour mettre les choses en perspective, nous avons réalisé une économie de coûts allant jusqu’à 80 %. De plus, pour gérer un trafic plus élevé, nous avons envisagé de mettre à l’échelle les répliques. En supposant un scénario où nous employons trois répliques, nous avons constaté que nos économies de coûts seraient toujours importantes même dans ces conditions, se situant autour de 43 %.

Le parcours avec les MME SageMaker s’est avéré financièrement avantageux, réduisant nos dépenses tout en assurant une performance de modèle optimale. Auparavant, nos modèles de langue d’autocomplétion étaient déployés dans Amazon EKS, nécessitant un nombre variable d’instances ml.g4dn.xlarge en fonction de l’allocation de mémoire par modèle. Cela a entraîné un coût mensuel considérable. Cependant, avec notre récente migration vers les MME SageMaker, nous avons pu réduire considérablement ces coûts. Nous hébergeons maintenant tous nos modèles sur des instances ml.g4dn.2xlarge, ce qui nous donne la capacité de packager les modèles de manière plus efficace. Cela a considérablement réduit nos dépenses mensuelles et nous avons maintenant réalisé des économies de coûts dans une fourchette de 66 à 74 %. Ce changement a démontré comment une utilisation efficace des ressources peut conduire à des économies financières significatives en utilisant les MME SageMaker.

Conclusion

Dans ce billet, nous avons examiné comment Forethought utilise les points de terminaison multi-modèles SageMaker pour réduire les coûts pour l’inférence en temps réel. SageMaker prend en charge la partie lourde non différenciée, de sorte que Forethought peut augmenter l’efficacité de l’ingénierie. Cela permet également à Forethought de réduire considérablement le coût pour l’inférence en temps réel tout en maintenant les performances nécessaires pour les opérations critiques pour l’entreprise. En le faisant, Forethought est capable de fournir une offre différenciée pour ses clients en utilisant des modèles hyper-personnalisés. Utilisez SageMaker MME pour héberger vos modèles à grande échelle et réduire les coûts d’hébergement en améliorant l’utilisation des points de terminaison. Cela réduit également les frais généraux de déploiement car Amazon SageMaker gère le chargement des modèles en mémoire et les met à l’échelle en fonction des modèles de trafic pour votre point de terminaison. Vous pouvez trouver des exemples de code sur l’hébergement de plusieurs modèles en utilisant les MME SageMaker sur GitHub.

We will continue to update IPGirl; if you have any questions or suggestions, please contact us!