Exécutez et optimisez l'inférence multimodèle avec les points de terminaison multimodèle Amazon SageMaker

Amazon Sage Maker le point de terminaison multi-modèle (MME) vous permet de déployer et d'héberger de manière rentable plusieurs modèles dans un seul point de terminaison, puis de mettre à l'échelle horizontalement le point de terminaison pour atteindre l'échelle. Comme l'illustre la figure suivante, il s'agit d'une technique efficace pour implémenter la multilocation de modèles au sein de votre infrastructure d'apprentissage automatique (ML). Nous avons vu des entreprises de logiciels en tant que service (SaaS) utiliser cette fonctionnalité pour appliquer l'hyper-personnalisation dans leurs modèles ML tout en réduisant les coûts.

Pour un aperçu de haut niveau du fonctionnement de MME, consultez la vidéo AWS Summit Faire passer le ML au niveau supérieur : héberger des milliers de modèles sur SageMaker. Pour en savoir plus sur les cas d'utilisation multi-locataires hyper-personnalisés que MME permet, reportez-vous à Comment mettre à l'échelle l'inférence d'apprentissage automatique pour les cas d'utilisation SaaS multi-locataires.

Dans le reste de cet article, nous approfondissons l'architecture technique de SageMaker MME et partageons les meilleures pratiques pour optimiser vos terminaux multi-modèles.

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 que vous pouvez servir via un conteneur de service partagé et vous n'avez pas besoin d'accéder à tous les modèles en même temps. En fonction de la taille de la mémoire de l'instance de point de terminaison, un modèle peut parfois être déchargé de la mémoire au profit du chargement d'un nouveau modèle pour optimiser l'utilisation efficace de la mémoire. Par conséquent, votre application doit être tolérante aux pics de latence occasionnels sur les modèles déchargés.

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 sont chargés lors de la première invocation et les modèles peu utilisés peuvent être déchargés de la mémoire au profit du chargement de nouveaux modèles. Par conséquent, si vous disposez d'un mélange de modèles fréquemment et rarement consultés, un point de terminaison multimodèle peut traiter efficacement ce trafic avec moins de ressources et des économies de coûts plus importantes.

Nous avons également vu certains scénarios dans lesquels les clients déploient un cluster MME avec une capacité de mémoire agrégée suffisante pour s'adapter à tous leurs modèles, évitant ainsi complètement les déchargements de modèles tout en réalisant des économies de coûts grâce à l'infrastructure d'inférence partagée.

Modèle de contenants de service

Lorsque vous utilisez la boîte à outils d'inférence SageMaker ou un conteneur de service de modèle SageMaker pré-construit compatible avec MME, votre conteneur a le Serveur multimodèle (processus JVM) en cours d'exécution. Le moyen le plus simple d'intégrer Multi Model Server (MMS) dans votre conteneur de service de modèle consiste à utiliser Conteneurs de service modèle SageMaker compatible avec MME (recherchez ceux avec Job Type=inference et CPU/GPU=CPU). MMS est un outil open source facile à utiliser pour servir des modèles d'apprentissage en profondeur. Il fournit une API REST avec un serveur Web pour servir et gérer plusieurs modèles sur un seul hôte. Cependant, il n'est pas obligatoire d'utiliser le MMS ; vous pouvez implémenter votre propre serveur de modèles tant qu'il implémente le API requises par MME.

Lorsqu'ils sont utilisés dans le cadre de la plate-forme MME, tous les appels d'API de prédiction, de chargement et de déchargement vers MMS ou votre propre serveur de modèles sont acheminés via le contrôleur de plan de données MME. Les appels d'API du contrôleur de plan de données sont effectués sur l'hôte local uniquement pour empêcher tout accès non autorisé depuis l'extérieur de l'instance. L'un des principaux avantages de MMS est qu'il permet une interface standardisée pour le chargement, le déchargement et l'appel de modèles avec une compatibilité sur un large éventail de cadres d'apprentissage en profondeur.

Configuration avancée du MMS

Si vous choisissez d'utiliser MMS pour la diffusion de modèles, envisagez les configurations avancées suivantes pour optimiser l'évolutivité et le débit de vos instances MME.

Augmenter le parallélisme d'inférence par modèle

MMS crée un ou plusieurs processus de travail Python par modèle en fonction de la valeur du default_workers_per_model paramètre de configuration. Ces travailleurs Python gèrent chaque demande d'inférence individuelle en exécutant toutes les fonctions de prétraitement, de prédiction et de post-traitement que vous fournissez. Pour plus d'informations, consultez le gestionnaire de service personnalisé Repo GitHub.

Avoir plus d'un model worker augmente le parallélisme des prédictions qui peuvent être servies par un modèle donné. Cependant, lorsqu'un grand nombre de modèles sont hébergés sur une instance avec un grand nombre de processeurs, vous devez effectuer un test de charge de votre MME pour trouver la valeur optimale pour default_workers_per_model pour éviter tout épuisement des ressources mémoire ou CPU.

Conception pour les pics de trafic

Chaque processus MMS au sein d'une instance de point de terminaison a une file d'attente de demandes qui peut être configurée avec le job_queue_size paramètre (la valeur par défaut est 100). Cela détermine le nombre de demandes que MMS mettra en file d'attente lorsque tous les processus de travail sont occupés. Utilisez ce paramètre pour affiner la réactivité de vos instances de point de terminaison après avoir décidé du nombre optimal de nœuds de calcul par modèle.

Dans un ratio optimal de travailleur par modèle, la valeur par défaut de 100 devrait suffire dans la plupart des cas. Cependant, dans les cas où le trafic de demandes vers le point de terminaison augmente de manière inhabituelle, vous pouvez réduire la taille de la file d'attente si vous voulez que le point de terminaison échoue rapidement pour passer le contrôle à l'application ou augmenter la taille de la file d'attente si vous voulez que le point de terminaison absorbe le pic .

Maximiser les ressources mémoire par instance

Lorsque vous utilisez plusieurs processus de travail par modèle, par défaut, chaque processus de travail charge sa propre copie du modèle. Cela peut réduire la mémoire d'instance disponible pour d'autres modèles. Vous pouvez optimiser l'utilisation de la mémoire en partageant un modèle unique entre les processus de travail en définissant le paramètre de configuration preload_model=vrai. Ici, vous échangez un parallélisme d'inférence réduit (en raison d'une seule instance de modèle) avec une plus grande efficacité de la mémoire. Ce paramètre, associé à plusieurs processus de travail, peut être un bon choix pour les cas d'utilisation où la latence du modèle est faible, mais où vous avez un prétraitement et un post-traitement plus lourds (effectués par les processus de travail) par demande d'inférence.

Définir des valeurs pour les configurations avancées MMS

MMS utilise un fichier config.properties pour stocker les configurations. MMS utilise l'ordre suivant pour localiser ce fichier config.properties :

1. Si la MMS_CONFIG_FILE variable d'environnement est définie, MMS charge la configuration à partir de la variable d'environnement.
2. Si la --mms-config est passé à MMS, il charge la configuration à partir du paramètre.
3. S'il y a un config.properties dans le dossier courant où l'utilisateur démarre MMS, il charge le config.properties fichier du répertoire de travail courant.

Si aucun des éléments ci-dessus n'est spécifié, MMS charge la configuration intégrée avec les valeurs par défaut.

Voici un exemple de ligne de commande de démarrage de MMS avec un fichier de configuration explicite :

multi-model-server --start --mms-config /home/mms/config.properties

Indicateurs clés pour surveiller les performances de vos terminaux

Les mesures clés qui peuvent vous aider à optimiser votre MME sont généralement liées à l'utilisation du processeur et de la mémoire et à la latence d'inférence. Les métriques au niveau de l'instance sont émises par MMS, tandis que les métriques de latence proviennent du MME. Dans cette section, nous discutons des métriques typiques que vous pouvez utiliser pour comprendre et optimiser votre MME.

Métriques au niveau de l'instance de point de terminaison (métriques MMS)

Extrait du liste des métriques MMS, CPUUtilization et MemoryUtilization peuvent vous aider à évaluer si votre instance ou le cluster MME est correctement dimensionné. Si les deux mesures ont des pourcentages compris entre 50 et 80 %, votre MME est de la bonne taille.

En règle générale, une CPUUtilization faible et une MemoryUtilization élevée indiquent un cluster MME surapprovisionné, car elles indiquent que les modèles rarement invoqués ne sont pas déchargés. Cela peut être dû à un nombre supérieur à l'optimum d'instances de point de terminaison provisionnées pour le MME et, par conséquent, une mémoire agrégée supérieure à l'optimum est disponible pour que les modèles rarement consultés restent en mémoire. Inversement, une utilisation proche de 100 % de ces métriques signifie que votre cluster est sous-provisionné, vous devez donc ajuster votre stratégie de mise à l'échelle automatique du cluster.

Métriques au niveau de la plateforme (métriques MME)

Extrait du liste complète des métriques MME, une métrique clé qui peut vous aider à comprendre la latence de votre demande d'inférence est ModelCacheHit. Cette métrique affiche le taux moyen de requêtes d'appel pour lesquelles le modèle a déjà été chargé en mémoire. Si ce rapport est faible, cela indique que votre cluster MME est sous-approvisionné car il n'y a probablement pas assez de capacité de mémoire agrégée dans le cluster MME pour le nombre d'appels de modèles uniques, ce qui entraîne le déchargement fréquent des modèles de la mémoire.

Leçons du terrain et stratégies d'optimisation du MME

Nous avons vu les recommandations suivantes de certaines des utilisations à grande échelle de MME chez un certain nombre de clients.

La mise à l'échelle horizontale avec des instances plus petites est meilleure que la mise à l'échelle verticale avec des instances plus grandes

Vous pouvez rencontrer une limitation des appels de modèle lors de l'exécution d'un nombre élevé de demandes par seconde (RPS) sur moins d'instances de point de terminaison. Il existe des limites internes au nombre d'appels par seconde (chargements et déchargements pouvant se produire simultanément sur une instance), et il est donc toujours préférable d'avoir un nombre plus élevé d'instances plus petites. L'exécution d'un nombre plus élevé d'instances plus petites signifie une capacité totale agrégée plus élevée de ces limites pour le point de terminaison.

Un autre avantage de la mise à l'échelle horizontale avec des instances plus petites est que vous réduisez le risque d'épuiser les ressources CPU et mémoire de l'instance lors de l'exécution de MMS avec des niveaux de parallélisme plus élevés, ainsi qu'un plus grand nombre de modèles en mémoire (comme décrit précédemment dans cet article).

Éviter les coups est une responsabilité partagée

Raclée dans MME, c'est lorsque les modèles sont fréquemment déchargés de la mémoire et rechargés en raison d'une mémoire insuffisante, soit dans une instance individuelle, soit globalement dans le cluster.

Du point de vue de l'utilisation, vous devez dimensionner correctement les instances de point de terminaison individuelles et dimensionner correctement la taille globale du cluster MME pour vous assurer qu'une capacité de mémoire suffisante est disponible par instance et également globalement pour le cluster pour votre cas d'utilisation. La flotte de routeurs de la plate-forme MME maximisera également le succès du cache.

Ne soyez pas agressif avec trop de modèles sur des instances de mémoire moins nombreuses et plus grandes

La mémoire n'est pas la seule ressource de l'instance à connaître. D'autres ressources telles que le processeur peuvent être un facteur contraignant, comme le montrent les résultats des tests de charge suivants. Dans d'autres cas, nous avons également observé que d'autres ressources du noyau, telles que les ID de processus, étaient épuisées sur une instance, en raison d'une combinaison de trop de modèles chargés et du framework ML sous-jacent (tel que TensorFlow) engendrant des threads par modèle qui étaient des multiples de disponibles. vCPU.

Le test de performances suivant illustre un exemple de contrainte de processeur affectant la latence du modèle. Dans ce test, un point de terminaison d'instance unique avec une grande instance, tout en ayant plus qu'assez de mémoire pour conserver les quatre modèles en mémoire, a produit des latences de modèle comparativement pires sous charge par rapport à un point de terminaison avec quatre instances plus petites.

latence du modèle de point de terminaison d'instance unique

Utilisation du processeur et de la mémoire du point de terminaison d'une instance unique

latence du modèle de point de terminaison à quatre instances

Utilisation du processeur et de la mémoire sur quatre points de terminaison d'instance

Pour obtenir à la fois performances et rentabilité, dimensionnez correctement votre cluster MME avec un nombre plus élevé d'instances plus petites qui, dans l'ensemble, vous offrent la mémoire et la capacité de processeur optimales tout en étant relativement au même niveau de coût avec des instances de mémoire moins nombreuses mais plus grandes.

Modèle mental pour optimiser MME

Il y a quatre métriques clés que vous devez toujours prendre en compte lors du dimensionnement correct de votre MME :

• Le nombre et la taille des modèles
• Le nombre de modèles uniques invoqués à un moment donné
• Le type et la taille de l'instance
• Le nombre d'instances derrière le point de terminaison

Commencez par les deux premiers points, car ils informent les troisième et quatrième. Par exemple, s'il n'y a pas assez d'instances derrière le point de terminaison pour le nombre ou la taille des modèles uniques que vous avez, la mémoire agrégée pour le point de terminaison sera faible et vous verrez un taux d'accès au cache inférieur et une agitation au niveau du point de terminaison car le MME chargera et déchargera fréquemment des modèles dans et hors de la mémoire.

De même, si les appels pour les modèles uniques sont supérieurs à la mémoire agrégée de toutes les instances derrière le point de terminaison, vous verrez un accès au cache inférieur. Cela peut également se produire si la taille des instances (en particulier la capacité mémoire) est trop petite.

La mise à l'échelle verticale avec des instances de mémoire très volumineuses peut également entraîner des problèmes, car bien que les modèles puissent tenir dans la mémoire, d'autres ressources telles que les processus du processeur et du noyau et les limites de thread peuvent être épuisées. Testez la charge de la mise à l'échelle horizontale en pré-production pour obtenir le nombre et la taille optimaux d'instances pour votre MME.

Résumé

Dans cet article, vous avez une meilleure compréhension de la plate-forme MME. Vous avez appris à quels cas d'utilisation techniques MME est adapté et examiné l'architecture de la plate-forme MME. Vous avez acquis une meilleure compréhension du rôle de chaque composant au sein de l'architecture MME et des composants dont vous pouvez directement influencer les performances. Enfin, vous avez approfondi les paramètres de configuration que vous pouvez ajuster pour optimiser MME pour votre cas d'utilisation et les métriques que vous devez surveiller pour maintenir des performances optimales.

Pour commencer avec MME, passez en revue Points de terminaison multimodèle Amazon SageMaker utilisant XGBoost ainsi que Hébergez plusieurs modèles dans un conteneur derrière un point de terminaison.

À propos de l’auteur

Syed Jaffry est architecte principal de solutions chez AWS. Il travaille avec un éventail d'entreprises de taille moyenne, de grandes entreprises, de services financiers et d'ISV pour les aider à créer et à exploiter des applications AI/ML rentables et évolutives dans le cloud.

Saurabh Trikandé est chef de produit senior pour Amazon SageMaker Inference. Il est passionné par le travail avec les clients et est motivé par l'objectif de démocratiser l'apprentissage automatique. Il se concentre sur les principaux défis liés au déploiement d'applications ML complexes, de modèles ML multi-locataires, d'optimisations de coûts et de rendre le déploiement de modèles d'apprentissage en profondeur 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.