Modèles de conception pour l'inférence série sur Amazon SageMaker

À mesure que l’apprentissage automatique (ML) se généralise et est de plus en plus adopté, les applications basées sur le ML deviennent de plus en plus courantes pour résoudre une série de problèmes commerciaux complexes. La solution à ces problèmes commerciaux complexes nécessite souvent l’utilisation de plusieurs modèles de ML. Ces modèles peuvent être combinés séquentiellement pour effectuer diverses tâches, telles que le prétraitement, la transformation des données, la sélection de modèles, la génération d'inférences, la consolidation d'inférences et le post-traitement. Les organisations ont besoin d'options flexibles pour orchestrer ces flux de travail de ML complexes. Les pipelines d'inférence en série constituent l'un de ces modèles de conception permettant d'organiser ces flux de travail en une série d'étapes, chaque étape enrichissant ou traitant davantage la sortie générée par les étapes précédentes et transmettant la sortie à l'étape suivante du pipeline.

De plus, ces pipelines d'inférence série doivent fournir les éléments suivants :

• Implémentation flexible et personnalisée (dépendances, algorithmes, logique métier, etc.)
• Répétable et cohérent pour la mise en œuvre en production
• Travaux lourds indifférenciés en minimisant la gestion des infrastructures

Dans cet article, nous examinons quelques cas d'utilisation courants des pipelines d'inférence série et passons en revue quelques options d'implémentation pour chacun de ces cas d'utilisation en utilisant Amazon Sage Maker. Nous discutons également des considérations pour chacune de ces options de mise en œuvre.

Le tableau suivant résume les différents cas d'utilisation de l'inférence série, les considérations de mise en œuvre et les options. Ceux-ci sont discutés dans cet article.

Dans les sections suivantes, nous discutons de chaque cas d'utilisation plus en détail.

Pipeline d'inférence série utilisant des conteneurs d'inférence

Les cas d'utilisation de pipeline d'inférence en série nécessitent de prétraiter les données entrantes avant d'appeler un modèle ML pré-entraîné pour générer des inférences. De plus, dans certains cas, les inférences générées peuvent devoir être traitées davantage, afin qu'elles puissent être facilement utilisées par les applications en aval. Il s'agit d'un scénario courant pour les cas d'utilisation dans lesquels une source de données en streaming doit être traitée en temps réel avant de pouvoir y adapter un modèle. Cependant, ce cas d’utilisation peut également se manifester pour l’inférence par lots.

SageMaker fournit une option pour personnaliser les conteneurs d'inférence et les utiliser pour créer un pipeline d'inférence en série. Les conteneurs d'inférence utilisent le Boîte à outils d'inférence SageMaker et sont construits sur Serveur multimodèle SageMaker (MMS), qui fournit un mécanisme flexible pour servir les modèles ML. Le diagramme suivant illustre un modèle de référence sur la façon d'implémenter un pipeline d'inférence série à l'aide de conteneurs d'inférence.

SageMaker MMS attend un script Python qui implémente les fonctions suivantes pour charger le modèle, prétraiter les données d'entrée, obtenir des prédictions du modèle et post-traiter les données de sortie :

• input_fn () – Responsable de la désérialisation et du prétraitement des données d’entrée
• modèle_fn() – Responsable du chargement du modèle formé à partir des artefacts dans Service de stockage simple Amazon (Amazon S3)
• prédire_fn () – Responsable de générer des inférences à partir du modèle
• sortie_fn() – Responsable de la sérialisation et du post-traitement des données de sortie (inférences)

Pour connaître les étapes détaillées de personnalisation d'un conteneur d'inférence, reportez-vous à Adapter votre propre conteneur d'inférence.

Les conteneurs d'inférence constituent un modèle de conception idéal pour les cas d'utilisation de pipelines d'inférence en série avec les principales considérations suivantes :

• Haute cohésion – La logique de traitement et le modèle correspondant pilotent une fonctionnalité métier unique et doivent être colocalisés
• Faible latence globale – Le temps écoulé entre le moment où une demande d'inférence est faite et la réponse est reçue

Dans un pipeline d'inférence série, la logique de traitement et le modèle sont encapsulés dans le même conteneur unique, de sorte qu'une grande partie des appels d'appel restent dans le conteneur. Cela permet de réduire le nombre total de sauts, ce qui se traduit par une meilleure latence globale et une meilleure réactivité du pipeline.

De plus, pour les cas d'utilisation où la facilité de mise en œuvre est un critère important, les conteneurs d'inférence peuvent être utiles, les différentes étapes de traitement du pipeline étant regroupées dans le même conteneur.

Pipeline d'inférence série utilisant un pipeline d'inférence SageMaker

Une autre variante du cas d'utilisation du pipeline d'inférence série nécessite un découplage plus clair entre les différentes étapes du pipeline (telles que le prétraitement des données, la génération d'inférence, le post-traitement des données, ainsi que le formatage et la sérialisation). Cela peut être dû à diverses raisons :

• Découplage – Différentes étapes du pipeline ont un objectif clairement défini et doivent être exécutées sur des conteneurs séparés en raison des dépendances sous-jacentes impliquées. Cela permet également de garder le pipeline bien structuré.
• Cadres – Différentes étapes du pipeline utilisent des cadres spécifiques adaptés à l'objectif (tels que scikit ou Spark ML) et doivent donc être exécutés sur des conteneurs distincts.
• Isolement des ressources – Différentes étapes du pipeline ont des exigences de consommation de ressources variables et doivent donc être exécutées sur des conteneurs séparés pour plus de flexibilité et de contrôle.

De plus, pour les pipelines d'inférence série légèrement plus complexes, plusieurs étapes peuvent être impliquées pour traiter une demande et générer une inférence. Par conséquent, d’un point de vue opérationnel, il peut être avantageux d’héberger ces étapes sur des conteneurs séparés pour une meilleure isolation fonctionnelle et faciliter les mises à niveau et les améliorations (modifier une étape sans affecter les autres modèles ou étapes de traitement).

Si votre cas d'utilisation correspond à certaines de ces considérations, un Pipeline d'inférence SageMaker fournit une option simple et flexible pour créer un pipeline d'inférence série. Le diagramme suivant illustre un modèle de référence sur la façon d'implémenter un pipeline d'inférence série à l'aide de plusieurs étapes hébergées sur des conteneurs dédiés à l'aide d'un pipeline d'inférence SageMaker.

Un pipeline d'inférence SageMaker se compose d'une séquence linéaire de 2 à 15 conteneurs qui traitent les demandes d'inférences sur les données. Le pipeline d'inférence offre la possibilité d'utiliser des algorithmes intégrés SageMaker pré-entraînés ou des algorithmes personnalisés regroupés dans des conteneurs Docker. Les conteneurs sont hébergés sur la même instance sous-jacente, ce qui permet de réduire la latence globale et de minimiser les coûts.

L'extrait de code suivant montre comment plusieurs étapes et modèles de traitement peuvent être combinés pour créer un pipeline d'inférence en série.

Nous commençons par créer et spécifier les modèles basés sur Spark ML et XGBoost que nous avons l'intention d'utiliser dans le cadre du pipeline :

from sagemaker.model import Model
from sagemaker.pipeline_model import PipelineModel
from sagemaker.sparkml.model import SparkMLModel
sparkml_data = 's3://{}/{}/{}'.format(s3_model_bucket, s3_model_key_prefix, 'model.tar.gz')
sparkml_model = SparkMLModel(model_data=sparkml_data)
xgb_model = Model(model_data=xgb_model.model_data, image=training_image)

Les modèles sont ensuite organisés séquentiellement dans la définition du modèle de pipeline :

model_name = 'serial-inference-' + timestamp_prefix
endpoint_name = 'serial-inference-ep-' + timestamp_prefix
sm_model = PipelineModel(name=model_name, role=role, models=[sparkml_model, xgb_model])

Le pipeline d'inférence est ensuite déployé derrière un point de terminaison pour une inférence en temps réel en spécifiant le type et le nombre d'instances ML hôtes :

sm_model.deploy(initial_instance_count=1, instance_type='ml.c4.xlarge', endpoint_name=endpoint_name)

L'ensemble du pipeline d'inférence assemblé peut être considéré comme un modèle SageMaker que vous pouvez utiliser pour effectuer des prédictions en temps réel ou traiter directement des transformations par lots, sans aucun prétraitement externe. Dans un modèle de pipeline d'inférence, SageMaker gère les invocations comme une séquence de requêtes HTTP provenant d'une application externe. Le premier conteneur du pipeline gère la requête initiale, effectue certains traitements, puis distribue la réponse intermédiaire sous forme de requête au deuxième conteneur du pipeline. Cela se produit pour chaque conteneur du pipeline et renvoie finalement la réponse finale à l'application cliente appelante.

Les pipelines d'inférence SageMaker sont entièrement gérés. Lorsque le pipeline est déployé, SageMaker installe et exécute tous les conteneurs définis sur chacun des Cloud de calcul élastique Amazon (Amazon EC2) provisionnées dans le cadre de la tâche de point de terminaison ou de transformation par lots. De plus, étant donné que les conteneurs sont colocalisés et hébergés sur la même instance EC2, la latence globale du pipeline est réduite.

Ensemble de modèles en série utilisant un pipeline d'inférence SageMaker

Un modèle d'ensemble est une approche en ML dans laquelle plusieurs modèles ML sont combinés et utilisés dans le cadre du processus d'inférence pour générer des inférences finales. Les motivations pour les modèles d'ensemble pourraient inclure l'amélioration de la précision, la réduction de la sensibilité du modèle à des caractéristiques d'entrée spécifiques et la réduction du biais d'un modèle unique, entre autres. Dans cet article, nous nous concentrons sur les cas d'utilisation liés à un ensemble de modèles en série, où plusieurs modèles ML sont combinés séquentiellement dans le cadre d'un pipeline d'inférence en série.

Prenons un exemple spécifique lié à un ensemble de modèles en série dans lequel nous devons regrouper les images téléchargées par un utilisateur en fonction de certains thèmes ou sujets. Ce pipeline pourrait être composé de trois modèles ML :

• Modèle 1 – Accepte une image en entrée et évalue la qualité de l’image en fonction de la résolution, de l’orientation, etc. Ce modèle tente ensuite d'améliorer la qualité de l'image et envoie les images traitées qui répondent à un certain seuil de qualité au modèle suivant (modèle 2).
• Modèle 2 – Accepte les images validées via le modèle 1 et effectue reconnaissance d'image pour identifier des objets, des lieux, des personnes, du texte et d'autres actions et concepts personnalisés dans les images. La sortie du modèle 2 qui contient les objets identifiés est envoyée au modèle 3.
• Modèle 3 – Accepte la sortie du modèle 2 et effectue des tâches de traitement du langage naturel (NLP) telles que la modélisation de sujets pour regrouper des images en fonction de thèmes. Par exemple, les images pourraient être regroupées en fonction du lieu ou des personnes identifiées. La sortie (regroupements) est renvoyée à l'application client.

Le diagramme suivant illustre un modèle de référence sur la façon d'implémenter plusieurs modèles ML hébergés sur un ensemble de modèles en série à l'aide d'un pipeline d'inférence SageMaker.

Comme indiqué précédemment, le pipeline d'inférence SageMaker est géré, ce qui vous permet de vous concentrer sur la sélection et le développement du modèle ML, tout en réduisant les tâches lourdes indifférenciées associées à la construction du pipeline d'ensemble en série.

De plus, certaines des considérations évoquées précédemment concernant le découplage, le choix d’algorithmes et de cadres pour le développement et le déploiement de modèles sont également pertinentes ici. Par exemple, étant donné que chaque modèle est hébergé sur un conteneur distinct, vous disposez de la flexibilité nécessaire pour sélectionner le framework ML qui correspond le mieux à chaque modèle et à votre cas d'utilisation global. De plus, du point de vue du découplage et du fonctionnement, vous pouvez continuer à mettre à niveau ou modifier des étapes individuelles beaucoup plus facilement, sans affecter les autres modèles.

Le pipeline d'inférence SageMaker est également intégré au Registre de modèles SageMaker pour le catalogage de modèles, la gestion des versions, la gestion des métadonnées et le déploiement gouverné dans des environnements de production afin de prendre en charge les meilleures pratiques opérationnelles cohérentes. Le pipeline d'inférence SageMaker est également intégré à Amazon Cloud Watch pour permettre la surveillance des modèles multi-conteneurs dans les pipelines d'inférence. Vous pouvez également obtenir une visibilité sur métriques en temps réel pour mieux comprendre les appels et la latence pour chaque conteneur du pipeline, ce qui facilite le dépannage et l'optimisation des ressources.

Pipeline d'inférence série (avec appel de modèle ciblé à partir d'un groupe) à l'aide d'un pipeline d'inférence SageMaker

Points de terminaison multimodèles SageMaker (MME) offrent une solution rentable pour déployer un grand nombre de modèles ML derrière un seul point de terminaison. Les motivations pour utiliser des points de terminaison multimodèles peuvent inclure l'invocation d'un modèle personnalisé spécifique en fonction des caractéristiques de la demande (telles que l'origine, l'emplacement géographique, la personnalisation de l'utilisateur, etc.) ou simplement l'hébergement de plusieurs modèles derrière le même point de terminaison pour obtenir une optimisation des coûts.

Lorsque vous déployez plusieurs modèles sur un seul point de terminaison multimodèle, tous les modèles partagent les ressources de calcul et le conteneur de diffusion de modèles. Le pipeline d'inférence SageMaker peut être déployé sur une MME, où l'un des conteneurs du pipeline peut répondre dynamiquement aux requêtes en fonction du modèle spécifique invoqué. Du point de vue du pipeline, les modèles ont des exigences de prétraitement identiques et attendent le même ensemble de fonctionnalités, mais sont formés pour s'aligner sur un comportement spécifique. Le diagramme suivant illustre un modèle de référence sur le fonctionnement de ce pipeline intégré.

Avec les MME, la demande d'inférence provenant de l'application client doit spécifier le modèle cible qui doit être invoqué. Le premier conteneur du pipeline gère la requête initiale, effectue certains traitements, puis distribue la réponse intermédiaire sous forme de requête au deuxième conteneur du pipeline, qui héberge plusieurs modèles. Sur la base du modèle cible spécifié dans la demande d'inférence, le modèle est invoqué pour générer une inférence. L'inférence générée est envoyée au conteneur suivant dans le pipeline pour un traitement ultérieur. Cela se produit pour chaque conteneur suivant dans le pipeline, et finalement SageMaker renvoie la réponse finale à l'application cliente appelante.

Plusieurs artefacts de modèle sont conservés dans un compartiment S3. Lorsqu'un modèle spécifique est invoqué, SageMaker le charge dynamiquement sur le conteneur hébergeant le point de terminaison. Si le modèle est déjà chargé dans la mémoire du conteneur, l'appel est plus rapide car SageMaker n'a pas besoin de télécharger le modèle depuis Amazon S3. Si l'utilisation de la mémoire de l'instance est élevée et qu'un nouveau modèle est invoqué et doit donc être chargé, les modèles inutilisés sont déchargés de la mémoire. Les modèles déchargés restent cependant dans le volume de stockage de l'instance et peuvent être à nouveau chargés ultérieurement dans la mémoire du conteneur, sans être à nouveau téléchargés depuis le compartiment S3.

L'une des principales considérations lors de l'utilisation des MME est de comprendre le comportement de latence d'appel du modèle. Comme indiqué précédemment, les modèles sont chargés dynamiquement dans la mémoire du conteneur de l'instance hébergeant le point de terminaison lorsqu'ils sont invoqués. Par conséquent, l’invocation du modèle peut prendre plus de temps lorsqu’il est invoqué pour la première fois. Lorsque le modèle est déjà dans la mémoire du conteneur d'instance, les appels suivants sont plus rapides. Si l'utilisation de la mémoire d'une instance est élevée et qu'un nouveau modèle doit être chargé, les modèles inutilisés sont déchargés. Si le volume de stockage de l'instance est plein, les modèles inutilisés sont supprimés du volume de stockage. SageMaker gère entièrement le chargement et le déchargement des modèles, sans que vous ayez à entreprendre d'actions spécifiques. Cependant, il est important de comprendre ce comportement car il a des implications sur la latence d'appel du modèle et donc sur la latence globale de bout en bout.

Options d'hébergement de pipelines

SageMaker fournit plusieurs type d'instance options parmi lesquelles choisir pour déployer des modèles ML et créer des pipelines d'inférence, en fonction de votre cas d'utilisation, de votre débit et de vos exigences en matière de coûts. Par exemple, vous pouvez choisir des instances optimisées pour le CPU ou le GPU pour créer des pipelines d'inférence série, sur un seul conteneur ou sur plusieurs conteneurs. Cependant, il existe parfois des exigences pour lesquelles il est souhaité de disposer de flexibilité et de prise en charge pour exécuter des modèles sur des instances basées sur CPU ou GPU au sein du même pipeline pour une flexibilité supplémentaire.

Vous pouvez désormais utiliser NVIDIA Triton Inference Server pour servir des modèles d'inférence sur SageMaker pour des exigences de calcul hétérogènes. Vérifier Déployez une IA rapide et évolutive avec NVIDIA Triton Inference Server dans Amazon SageMaker pour plus de détails.

Conclusion

À mesure que les organisations découvrent et créent de nouvelles solutions basées sur le ML, les outils requis pour orchestrer ces pipelines doivent être suffisamment flexibles pour être pris en charge en fonction d'un cas d'utilisation donné, tout en simplifiant et en réduisant les frais opérationnels continus. SageMaker propose plusieurs options pour concevoir et créer ces flux de travail d'inférence en série, en fonction de vos besoins.

Nous sommes impatients de connaître votre avis sur les cas d'utilisation que vous créez à l'aide de pipelines d'inférence en série. Si vous avez des questions ou des commentaires, partagez-les dans les commentaires.

À propos des auteurs

Rahul Sharma est architecte de solutions senior chez AWS Data Lab, aidant les clients AWS à concevoir et à créer des solutions IA/ML. Avant de rejoindre AWS, Rahul a passé plusieurs années dans le secteur de la finance et des assurances, aidant les clients à créer des plateformes de données et d'analyse.

Anand Prakash est architecte de solutions senior chez AWS Data Lab. Anand se concentre sur l'aide aux clients pour concevoir et créer des solutions d'IA/ML, d'analyse de données et de bases de données pour accélérer leur chemin vers la production.

Dhawal Patel est architecte principal en apprentissage machine chez AWS. Il a travaillé avec des organisations allant des grandes entreprises aux startups de taille moyenne sur des problèmes liés à l'informatique distribuée et à l'intelligence artificielle. Il se concentre sur l'apprentissage en profondeur, y compris les domaines de la PNL et de la vision par ordinateur. Il aide les clients à obtenir une inférence de modèle haute performance sur SageMaker.

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.