Comment faire évoluer l'inférence d'apprentissage automatique pour les cas d'utilisation SaaS multi-locataires

Republié par Platon

Suiveurs: 0

Cet article est co-écrit avec Sowmya Manusani, ingénieur senior en apprentissage machine chez Zendesk

Zendesk est une société SaaS qui crée des logiciels d'assistance, de vente et d'engagement client pour tous, avec la simplicité comme base. Il prospère en permettant à plus de 170,000 XNUMX entreprises dans le monde de servir efficacement leurs centaines de millions de clients. L'équipe d'apprentissage automatique de Zendcaesk est chargée d'améliorer les équipes d'expérience client pour qu'elles donnent le meilleur d'elles-mêmes. En combinant la puissance des données et des personnes, Zendesk propose des produits intelligents qui rendent leurs clients plus productifs en automatisant le travail manuel.

Zendesk développe des produits ML depuis 2015, notamment Bot de réponse, Prédiction de satisfaction, Signaux de contenu, Macros suggérées, et beaucoup plus. Au cours des dernières années, avec la croissance de l'apprentissage en profondeur, en particulier dans le NLP, ils ont vu de nombreuses opportunités d'automatiser les flux de travail et d'aider les agents à soutenir leurs clients avec les solutions Zendesk. Zendesk utilise actuellement TensorFlow et PyTorch pour créer des modèles d'apprentissage en profondeur.

Des clients comme Zendesk ont créé avec succès des entreprises de logiciel en tant que service (SaaS) à grande échelle sur Amazon Web Services (AWS). L'un des principaux moteurs d'un modèle commercial SaaS réussi est la capacité d'appliquer la multilocation dans l'application et l'infrastructure. Cela permet d'optimiser les coûts et l'efficacité opérationnelle, car l'application n'a besoin d'être créée qu'une seule fois, mais elle peut être utilisée plusieurs fois et l'infrastructure peut être partagée. Nous voyons de nombreux clients créer des systèmes sécurisés, rentables et mutualisés sur AWS à toutes les couches de la pile, du calcul, du stockage, de la base de données à la mise en réseau, et maintenant nous voyons des clients qui doivent l'appliquer à l'apprentissage automatique (ML ).

Faire le difficile compromis entre réutilisation de modèles et hyper-personnalisation

La multilocation pour les entreprises SaaS signifie généralement qu'une seule application est réutilisée par de nombreux utilisateurs (clients SaaS). Cela crée des économies de coûts et réduit les frais généraux opérationnels. Cependant, les modèles d'apprentissage automatique doivent parfois être personnalisés à un degré élevé de spécificité (hyper-personnalisés) pour faire des prédictions précises. Cela signifie que le paradigme SaaS "construire une fois, utiliser plusieurs fois" ne peut pas toujours être appliqué au ML si les modèles ont une spécificité. Prenons par exemple le cas d'utilisation des plateformes de support client. La langue que les utilisateurs incluent dans un ticket d'assistance varie selon qu'il s'agit d'un problème de covoiturage ("le trajet a pris trop de temps") ou d'un problème d'achat de vêtements ("décoloration au lavage"). Dans ce cas d'utilisation, l'amélioration de la précision de la prédiction de la meilleure action corrective peut nécessiter la formation d'un modèle de traitement du langage naturel (TAL) sur un ensemble de données spécifique à un domaine métier ou à un secteur vertical. Zendesk fait face à ce défi lorsqu'il essaie d'exploiter le ML dans ses solutions. Ils devaient créer des milliers de modèles de ML hautement personnalisés, chacun adapté à un client spécifique. Pour résoudre ce défi de déployer des milliers de modèles de manière rentable, Zendesk s'est tourné vers Amazon SageMaker.

Dans cet article, nous montrons comment utiliser certaines des nouvelles fonctionnalités de Amazon Sage Maker, un service de machine learning entièrement géré, pour créer une capacité d'inférence ML mutualisée. Nous partageons également un exemple concret de la façon dont Zendesk a réussi à obtenir le même résultat en déployant un juste milieu entre la capacité de prendre en charge l'hyper-personnalisation dans ses modèles ML et l'utilisation partagée et rentable de l'infrastructure à l'aide des points de terminaison multimodèles SageMaker ( MEM).

Points de terminaison multimodèles SageMaker

Les points de terminaison multimodèles SageMaker vous permettent de déployer plusieurs modèles derrière un seul point de terminaison d'inférence pouvant contenir une ou plusieurs instances. Chaque instance est conçue pour charger et servir plusieurs modèles jusqu'à sa capacité de mémoire et de CPU. Avec cette architecture, une entreprise SaaS peut casser l'augmentation linéaire du coût de l'hébergement de plusieurs modèles et parvenir à une réutilisation de l'infrastructure cohérente avec le modèle multi-location appliqué ailleurs dans la pile d'applications.

Le diagramme suivant illustre l'architecture d'un point de terminaison multimodèle SageMaker.

Le point de terminaison multimodèle SageMaker charge dynamiquement les modèles à partir de Service de stockage simple Amazon (Amazon S3) lorsqu'il est appelé, au lieu de télécharger tous les modèles lors de la première création du point de terminaison. Par conséquent, un appel initial à un modèle peut entraîner une latence d'inférence plus élevée que les inférences suivantes, qui sont terminées avec une faible latence. Si le modèle est déjà chargé sur le conteneur lorsqu'il est invoqué, l'étape de téléchargement est ignorée et le modèle renvoie les inférences avec une faible latence. Par exemple, supposons que vous ayez un modèle qui n'est utilisé que quelques fois par jour. Il est automatiquement chargé à la demande, tandis que les modèles fréquemment consultés sont conservés en mémoire et invoqués avec une latence constamment faible.

Examinons de plus près comment Zendesk a utilisé SageMaker MME pour réaliser un déploiement ML hyper-évolutif et rentable avec sa fonctionnalité ML suggérée de macros.

Pourquoi Zendesk a créé des modèles hyper-personnalisés

Les clients de Zendesk sont répartis dans le monde entier dans différents secteurs verticaux avec différentes sémantiques de ticket de support. Par conséquent, pour servir au mieux leurs clients, ils doivent souvent créer des modèles personnalisés qui sont formés sur des données de ticket de support spécifiques au client pour identifier correctement l'intention, les macros, etc.

En octobre 2021, ils ont publié une nouvelle fonctionnalité NLP ML, Suggested Macros, qui recommande des macros (actions prédéfinies) basées sur des milliers de prédictions de modèles spécifiques au client. L'équipe ML de Zendesk a créé un modèle de classificateur NLP basé sur TensorFlow, formé à partir de l'historique précédent du contenu des tickets et des macros par client. Avec ces modèles disponibles, une prédiction de macro est recommandée chaque fois qu'un agent visualise le ticket (comme illustré dans la capture d'écran suivante), ce qui aide l'agent à servir rapidement les clients. Étant donné que les macros sont spécifiques aux clients, Zendesk a besoin de modèles spécifiques aux clients pour fournir des prédictions précises.

Sous le capot des macros suggérées de Zendesk

Les modèles de macros suggérés sont des réseaux de neurones basés sur la PNL d'une taille d'environ 7 à 15 Mo. Le principal défi consiste à mettre en production des milliers de ces modèles avec des solutions rentables, fiables et évolutives.

Chaque modèle a des modèles de trafic différents, avec un minimum de deux requêtes par seconde et un pic de centaines de requêtes par seconde, servant des millions de prédictions par jour avec une latence de modèle d'environ 100 millisecondes lorsque le modèle est disponible en mémoire. Les points de terminaison SageMaker sont déployés dans plusieurs régions AWS, traitant des milliers de demandes par minute et par point de terminaison.

Grâce à sa capacité à héberger plusieurs modèles sur un seul point de terminaison, SageMaker a aidé Zendesk à réduire les frais généraux de déploiement et à créer une solution rentable par rapport au déploiement d'un point de terminaison à modèle unique par client. Le compromis ici est moins de contrôle sur la gestion par modèle ; cependant, c'est un domaine dans lequel Zendesk collabore avec AWS pour améliorer les points de terminaison multimodèles.

L'une des fonctionnalités multi-modèles de SageMaker est le chargement différé des modèles, c'est-à-dire que les modèles sont chargés en mémoire lorsqu'ils sont invoqués pour la première fois. Il s'agit d'optimiser l'utilisation de la mémoire ; cependant, cela provoque des pics de temps de réponse lors du premier chargement, ce qui peut être considéré comme un problème de démarrage à froid. Pour les macros suggérées, c'était un défi ; Cependant, Zendesk a surmonté ce problème en implémentant une fonctionnalité de préchargement en plus du provisionnement du point de terminaison SageMaker pour charger les modèles en mémoire avant de servir le trafic de production. Deuxièmement, MME décharge les modèles peu utilisés de la mémoire, donc pour obtenir une faible latence constante sur tous les modèles et éviter que les «voisins bruyants» n'affectent d'autres modèles moins actifs, Zendesk collabore avec AWS pour ajouter de nouvelles fonctionnalités, discutées plus loin dans le post, pour permettre une gestion par modèle plus explicite. De plus, comme solution provisoire, Zendesk a adapté la flotte MME pour minimiser le déchargement d'un trop grand nombre de modèles. Grâce à cela, Zendesk est en mesure de fournir des prédictions à tous ses clients avec une faible latence, environ 100 millisecondes, tout en réalisant 90 % d'économies par rapport aux terminaux dédiés.

Concernant le bon dimensionnement de MME, Zendesk a observé lors des tests de charge qu'avoir un nombre plus élevé d'instances plus petites (biais sur la mise à l'échelle horizontale) derrière MME était un meilleur choix que d'avoir moins d'instances de mémoire plus grandes (mise à l'échelle verticale). Zendesk a observé que le regroupement de trop de modèles (au-delà de 500 modèles TensorFlow dans leur cas) sur une seule grande instance de mémoire ne fonctionnait pas bien car la mémoire n'est pas la seule ressource sur une instance qui peut être un goulot d'étranglement. Plus précisément, ils ont observé que TensorFlow générait plusieurs threads (3 x vCPU d'instance au total) par modèle, de sorte que le chargement de plus de 500 modèles sur une seule instance entraînait le dépassement des limites au niveau du noyau sur le nombre maximal de threads pouvant être générés sur une instance. Un autre problème lié à l'utilisation d'instances moins nombreuses et plus volumineuses s'est produit lorsque Zendesk a rencontré une limitation (en tant que mécanisme de sécurité) sur certaines instances derrière MME, car le taux d'appel de modèle unique par seconde dépassait ce que le Serveur multimodèle (MMS) sur une seule instance pourrait gérer en toute sécurité sans brunir l'instance. C'était un autre problème qui a été résolu avec l'utilisation d'instances plus nombreuses et plus petites.

Du point de vue de l'observabilité, qui est un élément crucial de toute application de production, Amazon Cloud Watch les métriques telles que les appels, le processeur, l'utilisation de la mémoire et les métriques multi-modèles spécifiques telles que les modèles chargés en mémoire, le temps de chargement du modèle, le temps d'attente de chargement du modèle et l'accès au cache du modèle sont instructifs. Plus précisément, la ventilation de la latence du modèle a aidé Zendesk à comprendre le problème du démarrage à froid et son impact.

Sous le capot de la mise à l'échelle automatique MME

Derrière chaque point de terminaison multimodèle, il y a des instances d'hébergement de modèles, comme illustré dans le diagramme suivant. Ces instances chargent et expulsent plusieurs modèles vers et depuis la mémoire en fonction des modèles de trafic vers les modèles.

SageMaker continue d'acheminer les demandes d'inférence pour un modèle vers l'instance où le modèle est déjà chargé de sorte que les demandes soient servies à partir de la copie du modèle mis en cache (voir le diagramme suivant, qui montre le chemin de la demande pour la première demande de prédiction par rapport à la demande de prédiction mise en cache chemin). Toutefois, si le modèle reçoit de nombreuses demandes d'appel et qu'il existe des instances supplémentaires pour le point de terminaison multimodèle, SageMaker achemine certaines demandes vers une autre instance pour s'adapter à l'augmentation. Pour tirer parti de la mise à l'échelle automatique des modèles dans SageMaker, assurez-vous d'avoir configuration de la mise à l'échelle automatique de l'instance pour provisionner une capacité d'instance supplémentaire. Configurez votre stratégie de mise à l'échelle au niveau du point de terminaison avec des paramètres personnalisés ou des appels par minute (recommandé) pour ajouter plus d'instances au parc de points de terminaison.

Cas d'utilisation les mieux adaptés pour MME

Les points de terminaison multimodèles SageMaker sont bien adaptés pour héberger un grand nombre de modèles similaires que vous pouvez servir via un conteneur de service partagé et n'avez pas besoin d'accéder à tous les modèles en même temps. MME convient mieux aux modèles dont la taille et les latences d'appel sont similaires. Une certaine variation dans la taille du modèle est acceptable ; par exemple, les modèles de Zendesk vont de 10 à 50 Mo, ce qui fonctionne bien, mais des variations de taille 10, 50 ou 100 fois plus importantes ne conviennent pas. Les modèles plus grands peuvent entraîner un nombre plus élevé de chargements et de déchargements de modèles plus petits pour accueillir un espace mémoire suffisant, ce qui peut entraîner une latence supplémentaire sur le point de terminaison. Les différences dans les caractéristiques de performances des modèles plus grands peuvent également consommer des ressources telles que le processeur de manière inégale, ce qui peut avoir un impact sur d'autres modèles de l'instance.

MME est également conçu pour co-héberger des modèles qui utilisent le même framework ML, car ils utilisent le conteneur partagé pour charger plusieurs modèles. Par conséquent, si vous avez un mélange de frameworks ML dans votre flotte de modèles (tels que PyTorch et TensorFlow), les points de terminaison dédiés SageMaker ou l'hébergement multi-conteneurs constituent un meilleur choix. Enfin, MME convient aux applications qui peuvent tolérer une pénalité occasionnelle de latence de démarrage à froid, car les modèles peu utilisés peuvent être déchargés au profit des modèles fréquemment invoqués. Si vous disposez d'une longue traîne de modèles rarement consultés, un point de terminaison multimodèle peut traiter efficacement ce trafic et permettre des économies importantes.

Résumé

Dans cet article, vous avez appris comment le SaaS et la multilocation sont liés au ML et comment les points de terminaison multimodèles SageMaker permettent la multilocation et la rentabilité pour l'inférence ML. Vous avez découvert le cas d'utilisation mutualisé de modèles ML par client de Zendesk et comment ils ont hébergé des milliers de modèles ML dans SageMaker MME pour leur fonctionnalité de macros suggérées et réalisé 90 % d'économies sur l'inférence par rapport aux points de terminaison dédiés. Les cas d'utilisation d'hyper-personnalisation peuvent nécessiter des milliers de modèles ML, et MME est un choix rentable pour ce cas d'utilisation. Nous continuerons d'apporter des améliorations à MME pour vous permettre d'héberger des modèles avec une faible latence et avec des contrôles plus granulaires pour chaque modèle personnalisé. Pour commencer avec MME, voir Hébergez plusieurs modèles dans un conteneur derrière un point de terminaison.

À propos des auteurs

Syed Jaffry est un architecte de solutions senior avec AWS. Il travaille avec une gamme d'entreprises allant des moyennes aux grandes entreprises, des services financiers aux ISV, pour les aider à créer et à exploiter des applications sécurisées, résilientes, évolutives et hautes performances dans le cloud.

Sowmya Manusani est ingénieur principal en apprentissage automatique chez Zendesk. Elle travaille sur la production de fonctionnalités d'apprentissage automatique basées sur le NLP qui se concentrent sur l'amélioration de la productivité des agents pour des milliers de clients Zendesk Enterprise. Elle a de l'expérience dans la création de pipelines de formation automatisés pour des milliers de modèles personnalisés et les sert à l'aide d'applications sécurisées, résilientes, évolutives et hautes performances. Pendant son temps libre, elle aime résoudre des énigmes et s'essayer à la peinture.

Saurabh Trikandé est chef de produit senior pour Amazon SageMaker Inference. Il est passionné par le travail avec les clients et rend l'apprentissage automatique plus accessible. Dans ses temps libres, Saurabh aime faire de la randonnée, découvrir des technologies innovantes, suivre TechCrunch et passer du temps avec sa famille.

Deepti Ragha est ingénieur en développement logiciel au sein de l'équipe Amazon SageMaker. Son travail actuel se concentre sur la création de fonctionnalités pour héberger efficacement des modèles d'apprentissage automatique. Dans ses temps libres, elle aime voyager, faire de la randonnée et cultiver des plantes.