Premiers pas avec le déploiement de modèles en temps réel sur Amazon SageMaker

Amazon Sage Maker est un service entièrement géré qui offre à chaque développeur et data scientist la possibilité de créer, former et déployer rapidement des modèles d'apprentissage automatique (ML) à grande échelle. ML est réalisé en inférence. SageMaker propose quatre options d'inférence :

1. Inférence en temps réel
2. Inférence sans serveur
3. Inférence asynchrone
4. Transformation par lots

Ces quatre options peuvent être largement classées en options d'inférence en ligne et par lots. Dans l'inférence en ligne, les demandes doivent être traitées au fur et à mesure de leur arrivée, et l'application consommatrice attend une réponse après le traitement de chaque demande. Cela peut se produire de manière synchrone (inférence en temps réel, sans serveur) ou de manière asynchrone (inférence asynchrone). Dans un modèle synchrone, l'application consommatrice est bloquée et ne peut pas continuer tant qu'elle n'a pas reçu de réponse. Ces charges de travail ont tendance à être des applications en temps réel, telles que la détection de fraude par carte de crédit en ligne, pour lesquelles les réponses sont attendues de l'ordre de quelques millisecondes à quelques secondes et les charges utiles des requêtes sont faibles (quelques Mo). Dans le modèle asynchrone, l'expérience de l'application n'est pas bloquée (par exemple, la soumission d'une réclamation d'assurance via une application mobile) et nécessite généralement des charges utiles plus importantes et/ou des temps de traitement plus longs. Dans l'inférence hors ligne, une agrégation (lot) de demandes d'inférence est traitée ensemble et les réponses ne sont fournies qu'une fois que l'intégralité du lot a été traitée. Généralement, ces charges de travail ne sont pas sensibles à la latence, impliquent de gros volumes (plusieurs Go) de données et sont planifiées à une cadence régulière (par exemple, exécuter une détection d'objet sur des images de caméras de sécurité à la fin de la journée ou traiter des données de paie à la fin de la journée). fin du mois).

Jusqu'aux os, Inférence en temps réel SageMaker se compose d'un ou plusieurs modèles, du framework/conteneur avec lequel vous travaillez et de l'infrastructure/des instances qui soutiennent votre point de terminaison déployé. Dans cet article, nous verrons comment créer et appeler un point de terminaison de modèle unique.

Choisir l'option de déploiement de modèle

Choisir le bon type d’inférence peut être difficile, et le guide simple suivant peut vous aider. Ce n'est pas un organigramme strict, donc si vous trouvez qu'une autre option vous convient mieux, n'hésitez pas à les utiliser. En particulier, l'inférence en temps réel est une excellente option pour héberger vos modèles lorsque vous disposez d'une latence faible et cohérente (de l'ordre de quelques millisecondes ou secondes) et de charges de travail sensibles au débit. Vous pouvez contrôler le type d'instance et compter derrière votre point de terminaison tout en configurant Mise à l'échelle automatique politique de gestion du trafic. Il existe deux autres options d'inférence SageMaker que vous pouvez également utiliser pour créer un point de terminaison. L'inférence asynchrone se produit lorsque vous disposez de charges utiles de grande taille et d'une bande passante de latence en temps quasi réel. C'est une bonne option, en particulier pour les modèles NLP et Computer Vision qui ont des temps de prétraitement plus longs. L'inférence sans serveur est une excellente option lorsque vous avez un trafic intermittent et que vous ne souhaitez pas gérer la mise à l'échelle de l'infrastructure. La recette pour créer un point de terminaison reste la même quel que soit le type d'inférence que vous choisissez. Dans cet article, nous nous concentrerons sur la création d'un point de terminaison basé sur une instance en temps réel, mais vous pouvez facilement l'adapter à l'une des autres options d'inférence en fonction de votre cas d'utilisation. Enfin, l'inférence par lots s'effectue hors ligne, vous pouvez donc fournir un ensemble de données à partir desquelles vous souhaitez obtenir une inférence et nous l'exécuterons. Ceci est également basé sur les instances, vous pouvez donc sélectionner l'instance optimale pour votre charge de travail. Comme aucun point final n’est opérationnel, vous ne payez que pour la durée du travail. C'est bon pour traiter des gigaoctets de données et la durée du travail peut atteindre plusieurs jours. Il existe des fonctionnalités intégrées pour faciliter le travail avec des données structurées et des optimisations pour distribuer automatiquement les données structurées. Quelques exemples de cas d'utilisation sont la modélisation de propension, la maintenance prédictive et la prévision du taux de désabonnement. Toutes ces opérations peuvent avoir lieu hors ligne en masse, car il n'est pas nécessaire de réagir à un événement spécifique.

Hébergement d'un modèle sur SageMaker Endpoints

À l'essentiel, SageMaker Real-Time Endpoints se compose d'un modèle et de l'infrastructure avec lesquels vous choisissez de sauvegarder le point de terminaison. SageMaker utilise des conteneurs pour héberger des modèles, ce qui signifie que vous avez besoin d'un conteneur qui configure correctement l'environnement du framework que vous utilisez pour chaque modèle que vous fournissez. Par exemple, si vous travaillez avec un modèle Sklearn, vous devez transmettre vos scripts/données de modèle dans un conteneur qui configure correctement Sklearn. Heureusement, SageMaker propose images gérées pour les frameworks populaires, tels que TensorFlow, PyTorch, Sklearn et HuggingFace. Vous pouvez récupérer et utiliser ces images à l'aide du haut niveau Kit de développement logiciel (SDK) SageMaker Python et injectez vos scripts de modèle et vos données dans ces conteneurs. Dans le cas où SageMaker ne dispose pas d'un conteneur pris en charge, vous pouvez également Construisez votre propre conteneur et transmettez votre propre image personnalisée, en installant les dépendances nécessaires à votre modèle.

SageMaker prend en charge les modèles formés et pré-entraînés. Dans le paragraphe précédent, lorsque nous parlons de scripts/données de modèle, nous faisons référence à ce sujet. Vous pouvez soit monter un script sur votre conteneur, soit si vous disposez d'un artefact de modèle pré-entraîné (par exemple, `modèle.joblib` pour SKLearn), vous pouvez alors le fournir avec votre image à SageMaker. Pour comprendre SageMaker Inference, vous allez créer trois entités principales lors du processus de création du point de terminaison :

1. Entité de modèle SageMaker – Ici, vous pouvez transmettre vos données de modèle/script de modèle formés et votre image avec laquelle vous travaillez, qu'elle appartienne à AWS ou qu'elle ait été créée par vous.
2. Création de configuration de point de terminaison – Ici, vous définissez votre infrastructure, ce qui signifie que vous sélectionnez le type d'instance, le nombre, etc.
3. Création de point de terminaison – Il s'agit du point de terminaison REST qui héberge votre modèle que vous appelez pour obtenir une réponse. Voyons comment vous pouvez utiliser une image SageMaker gérée et votre propre image personnalisée pour déployer un point de terminaison.

Exigences relatives aux points de terminaison en temps réel

1. Avant de créer un point de terminaison, vous devez comprendre quel type de modèle vous souhaitez héberger. S'il s'agit d'un modèle Framework, tel que TensorFlow, PyTorch ou MXNet, vous pouvez utiliser l'un des images de framework prédéfinies.
   S'il s'agit d'un modèle personnalisé ou si vous souhaitez une flexibilité totale dans la création du conteneur que SageMaker exécutera pour l'inférence, vous pouvez créer votre propre conteneur.

Points de terminaison SageMaker sont constitués d'un Modèle Sage Maker ainsi que Configuration du point de terminaison.
Si vous utilisez Boto3, vous créerez les deux objets. Sinon, si vous utilisez le SDK SageMaker Python, la configuration du point de terminaison est créée en votre nom lorsque vous utilisez le .deploy(..) la fonction.

Entités SageMaker :

• Modèle Sage Maker:
  • Contient les détails de l'image d'inférence, l'emplacement des artefacts du modèle dans Service de stockage simple d'Amazon (Amazon S3), configuration du réseau, et Gestion des identités et des accès AWS (IAM) rôle à utiliser par le point de terminaison.
    • SageMaker nécessite que vos artefacts de modèle soient compressés dans un .tar.gz déposer. SageMaker extrait automatiquement ceci .tar.gz déposer dans le /opt/ml/model/ répertoire dans votre conteneur. Si vous utilisez l'un des conteneurs de framework, tels que TensorFlow, PyTorch ou MXNet, le conteneur s'attend à ce que votre structure TAR soit la suivante :
      • TensorFlow
        

        model.tar.gz/
        |--[model_version_number]/
        |--variables
        |--saved_model.pb
        code/
        |--inference.py
        |--requirements.txt

      • PyTorch
        

        model.tar.gz/
        |- model.pth
        |- code/
        |- inference.py
        |- requirements.txt # only for versions 1.3.1 and higher

      • MXNet
        

        model.tar.gz/
        |- model-symbol.json
        |- model-shapes.json
        |- model-0000.params
        |- code/
            |- inference.py
            |- requirements.txt # only for versions 1.6.0 and higher

      • Apprendre
        

        model.tar.gz/
        |- model.joblib
        | code/ 
        |- inference.py

    • Lorsque vous utilisez une image Framework, nous pouvons fournir un script de point d'entrée personnalisé, dans lequel nous pouvons implémenter notre propre pré et post-traitement. Dans notre cas, le script d'inférence est empaqueté dans model.tar.gz sous le répertoire /code.

• • Configuration du point de terminaison
    • Contient les informations d'infrastructure requises pour déployer le modèle SageMaker sur le point de terminaison.
    • Par exemple, le modèle SageMaker que nous avons créé est spécifié ici ainsi que le type d'instance et le nombre d'instances initial.

Cadres et BYOC

• • Récupération d'images SageMaker
    • Cette partie n'est pas toujours nécessaire et extraite par le SDK SageMaker Python via des estimateurs. Cependant, si vous souhaitez pouvoir récupérer une image gérée par SageMaker pour l'étendre, vous pouvez obtenir les images disponibles via le SDK. Ce qui suit est un exemple de récupération d’une image TF 2.2 à des fins d’inférence.

      import sagemaker
      tf_image = sagemaker.image_uris.retreive(framework="tensorflow", region="us-east-1",
      image_scope = "inference", version = "2.2", instance_type = "ml.c5.xlarge)
      print(tf_image)

  • Cadres
    • Dans le cas où vous souhaitez déployer un modèle de framework, tel que TensorFlow, PyTorch ou MXNet, vous n'avez besoin que des artefacts du modèle.
    • Consultez la documentation sur le déploiement de modèles directement à partir d'artefacts de modèle pour TensorFlow, PyTorchou MXNet.

• • Choisir entre 1P et BYOC
    • Le SDK SageMaker résume également la gestion de l'image, comme vous l'avez vu dans la section Frameworks précédente. Il contient des estimateurs prêts à l'emploi pour Sklearn, TensorFlow et PyTorch qui sélectionnent automatiquement l'image pour vous en fonction de la version que vous avez sélectionnée. Ensuite, vous pouvez transmettre un script de formation/inférence via Mode script dans ces estimateurs.

      from sagemaker.pytorch import PyTorch #PyTorch Estimator within SageMaker SDK
      estimator_parameters = {"entry_point": "train_deploy_pytorch_without_dependencies.py",
      "source_dir": "pytorch_script","instance_type": train_instance_type,
      "instance_count": 1,"hyperparameters": hyperparameters,
      "role": role,"base_job_name": "pytorch-model","framework_version": "1.5",
      "py_version": "py3",}
      
      ## Model Training
      estimator = PyTorch(**estimator_parameters)estimator.fit(inputs)
      
      ## Deploy Trained model
      pytorch_predictor = estimator.deploy(initial_instance_count=1, instance_type="ml.m5.xlarge", endpoint_name=pytorch_endpoint_name)

    • Tous les packages et images ne sont pas pris en charge par SageMaker, et dans ce cas, vous devez apportez votre propre conteneur (BYOC). Cela signifie créer un Dockerfile qui configurera l'environnement approprié pour la diffusion de votre modèle. Un exemple de ceci est le module Spacy NLP, et il n'existe aucun conteneur SageMaker géré pour ce framework. Par conséquent, vous devez fournir un Dockerfile qui installe Spacy. Dans le conteneur, vous montez également vos scripts d'inférence de modèle. Discutons rapidement des composants que vous fournissez dans un format Bring Your Own Container, car ils restent cohérents pour la plupart des exemples.
      • "nginx.conf" est le fichier de configuration du front-end nginx. Vous n'aurez pas besoin de modifier ce fichier, sauf si vous souhaitez régler ces parties.
      • "prédicteur.py" est le programme qui implémente réellement le serveur Web Flask et le code modèle pour votre application. Vous pouvez avoir d'autres fichiers ou fonctions Python dans votre conteneur que vous pouvez appeler dans ce fichier.
      • "servir" est le programme démarré lorsque le conteneur est démarré pour l'hébergement. Il lance simplement le serveur gunicorn, qui exécute plusieurs instances de l'application Flask définie dans Predictor.py. Comme nginx.conf, vous n'avez pas besoin de modifier ce fichier, sauf si vous souhaitez effectuer des réglages supplémentaires.
      • "former" est le programme appelé lorsque le conteneur est exécuté pour la formation. Vous allez modifier ce programme pour implémenter votre algorithme d'entraînement. Si vous apportez un modèle ou un framework pré-entraîné comme Spacy, vous n'avez pas besoin de ce fichier.
      • "wsgi.py" est un petit wrapper utilisé pour appeler l'application Flask. Vous devriez pouvoir prendre ce fichier tel quel, sauf si vous avez modifié le nom de votre fichier prédicteur.py. Dans ce cas, assurez-vous que la carte est correctement affichée ici.

• • Script d'inférence personnalisé
    • Les conteneurs SageMaker Framework vous offrent la flexibilité de gérer le pré/post-traitement de la requête et le chargement du modèle à l'aide d'un script/inference.py de point d'entrée personnalisé.
    • Consultez la documentation pour créer un script inference.py personnalisé pour TensorFlow, PyTorch ainsi que MXNet.
  • Conteneur personnalisé

Différentes manières d'interagir avec SageMaker Endpoints

Il existe de nombreuses options pour utiliser SageMaker par programme afin que vous puissiez appeler vos modèles déployés pour obtenir une inférence. Le Interface de ligne de commande AWS (AWS CLI), API REST, AWS CloudFormation, Kit de développement cloud AWS (AWS CDK), et les SDK AWS sont des outils courants proposés par AWS et largement pris en charge par d'autres services AWS. Pour SageMaker, nous disposons également d'un SDK SageMaker Python. Comparons maintenant les différentes options pour créer, appeler et gérer SageMaker Endpoints.

En plus des CLI SageMaker, vous pouvez interagir par programmation de deux manières avec les points de terminaison dans SageMaker via les SDK. Examinons quelques différences entre Kit de développement logiciel (SDK) SageMaker Python ainsi que Kit de développement Python Boto3:

1. SDK SageMaker « Python » de haut niveau – Ce SDK est une bibliothèque open source qui fournit une abstraction de niveau supérieur spécifiquement destinée à appeler les API SageMaker par programme à l’aide de Python. La bonne partie de ce SDK est qu'il est très facile d'appeler les API sagemaker, beaucoup de travail est déjà fait comme appeler les API de manière synchrone/asynchrone (permet d'éviter les interrogations), un schéma de requête/réponse plus simple, beaucoup moins de code et bien plus encore. code plus simple. Le SDK SageMaker Python fournit plusieurs abstractions de haut niveau pour travailler avec SageMaker. Le package est destiné à simplifier différents processus ML sur SageMaker.
2. SDK AWS de bas niveau (SDK Boto3) – Ce SDK fonctionne au niveau inférieur en permettant à l'utilisateur de choisir parmi les langages de programmation pris en charge et d'appeler n'importe quel service AWS par programme. Ce n'est pas seulement spécifique à SageMaker mais peut être utilisé de manière générale pour tous les services AWS. Les SDK AWS de bas niveau sont disponibles dans divers langages de programmation, tels que .NET, Python, Java, Node.js, etc. L'un des SDK les plus utilisés est le SDK boto3 python, qui est populaire dans la communauté des scientifiques de données pour le ML. L'avantage de ce SDK est qu'il est très léger et disponible par défaut installé sur AWS Lambda Durée. De plus, vous pouvez utiliser ce SDK pour interagir avec n'importe quel service AWS en dehors de SageMaker.

Ces deux SDK peuvent être utilisés pour les mêmes tâches, mais dans certains cas, il est plus intuitif d'utiliser l'un plus que l'autre. Le SDK SageMaker Python est recommandé pour des tests faciles, tandis que le SDK AWS/Boto3 est recommandé pour les cas d'utilisation en production afin de mieux contrôler les performances. Par exemple, SageMaker en tant que service fournit des images prédéfinies et maintenues pour les frameworks populaires, tels que Sklearn, PyTorch et TensorFlow. Il peut être particulièrement utile d'utiliser le SDK SageMaker pour récupérer des images de deep learning, former des modèles à l'aide de Estimateurset déployez facilement le modèle à l'aide d'un simple appel d'API. Un exemple pour illustrer cela en action peut être trouvé ici.

D'un autre côté, vous disposez parfois de modèles pré-entraînés ou de différents frameworks que vous utilisez. Cela nécessite une plus grande personnalisation et le SDK SageMaker ne l'offre pas toujours. Nous avons trois étapes importantes et les appels d'API boto3 correspondants que nous devons exécuter pour déployer un point de terminaison : Création de modèle, Création de configuration de point de terminaisonet Création de point de terminaison. Les deux premières entités ont été extraites avec le SDK SageMaker avec nos frameworks pris en charge, mais nous voyons ces détails avec le SDK Boto3. Un exemple détaillé illustrant les étapes impliquées dans l'utilisation d'un SDK Boto3 pour créer et gérer un point de terminaison peut être trouvé. ici.

Considérations sur l'hébergement SageMaker

SageMaker Real-Time Inference propose deux optimisations principales que vous pouvez envisager : 1/ Optimisation des performances et 2/ Optimisation des coûts. Regardons d'abord Optimisation des performances, comme lorsque nous traitons de charges de travail sensibles à la latence, chaque milliseconde est cruciale. Il existe différents boutons que vous pouvez régler pour optimiser votre latence et votre débit. Au niveau de l'instance, vous pouvez utiliser Recommandateur d'inférence, notre outil de test de charge intégré, pour vous aider à sélectionner le bon type d'instance et à compter pour votre charge de travail. Utiliser la bonne combinaison de calcul vous aidera à la fois en termes de performances et de coûts. Vous pouvez également effectuer des réglages au niveau du conteneur et du framework.
Les questions à vous poser incluent :

1. Quel framework utilisez-vous ?
2. Existe-t-il des variables d'environnement que vous pouvez régler dans votre conteneur ?

Un exemple de ceci est la maximisation Performances TensorFlow avec les conteneurs SageMaker. Un autre exemple d'optimisation au niveau du conteneur est utiliser gRPC plutôt que de REPOS derrière votre point de terminaison. Enfin, vous pouvez également optimiser au niveau du script. Votre code d'inférence prend-il plus de temps sur certains blocs ? Chronométrer chaque ligne de votre script vous aidera à capturer les goulots d'étranglement dans votre code.

Il y a trois façons de voir améliorer l'utilisation de votre point de terminaison en temps réel :

1. Points de terminaison multimodèles (MME)
   • Vous pouvez héberger des milliers de modèles derrière un seul point de terminaison. C'est parfait pour les cas d'utilisation où vous n'avez pas besoin d'un point de terminaison dédié pour chacun de vos modèles. MME fonctionne mieux lorsque les modèles ont une taille et une latence similaires et appartiennent au même framework ML. Ceux-ci peuvent être généralement utilisés lorsque vous n'avez pas besoin d'appeler le même modèle à tout moment. Vous pouvez charger dynamiquement le modèle respectif sur le point de terminaison SageMaker pour répondre à votre demande. Un exemple qui présente MME en action peut être trouvé ici. Si vous souhaitez en savoir plus sur les différentes mises en garde et les meilleures pratiques concernant l'hébergement de modèles sur MME, reportez-vous à l'article ici.
2. Points de terminaison multi-conteneurs (MCE)
   • Au lieu d'utiliser plusieurs points de terminaison pour héberger plusieurs conteneurs, vous pouvez envisager d'héberger jusqu'à 15 conteneurs sur un seul point de terminaison. Chacun de ces conteneurs peut être invoqué directement. Par conséquent, vous pouvez envisager d’héberger des modèles disparates de différents frameworks sur un seul point de terminaison. Cette option est la meilleure lorsque les conteneurs présentent des caractéristiques d’utilisation et de performances similaires. Un exemple qui présente MCE peut être trouvé ici. Si vous souhaitez en savoir plus sur les différentes mises en garde et les meilleures pratiques concernant l'hébergement de modèles sur MCE, reportez-vous à l'article ici.
3. Pipeline d'inférence série (SIP)
   • Si vous disposez d'un pipeline d'étapes dans votre logique d'inférence, vous pouvez utiliser le pipeline d'inférence série (SIP). SIP vous permet de chaîner 2 à 15 conteneurs derrière un seul point de terminaison. SIP fonctionne bien lorsque vous avez des étapes de prétraitement et de post-traitement. Si vous souhaitez en savoir plus sur les modèles de conception des pipelines d'inférence en série, reportez-vous à l'article ici.

La deuxième optimisation principale à garder à l’esprit est sables moins coûteux. L'inférence en temps réel est l'une des trois options de création de points de terminaison SageMaker. Les points de terminaison SageMaker sont exécutés à tout moment, sauf suppression. Par conséquent, vous devez envisager d’améliorer l’utilisation du point de terminaison, ce qui en retour offre un avantage en termes de coûts.

SageMaker propose également Plans d'épargne. Les plans d'épargne peuvent réduire vos coûts jusqu'à 64 %. Il s'agit d'un engagement à terme de 1 ou 3 ans pour une quantité d'utilisation constante ($/heure). Regarde ça lien pour plus d'informations. Et vois ça lien pour optimiser au mieux les coûts d'inférence sur Amazon SageMaker.

Conclusion

Dans cet article, nous vous avons montré quelques-unes des meilleures pratiques pour choisir entre différentes options d'hébergement de modèles sur SageMaker. Nous avons discuté des exigences de SageMaker Endpoint, ainsi que des exigences et des fonctionnalités contrastées du Framework et du BYOC. De plus, nous avons parlé des différentes façons dont vous pouvez exploiter les points de terminaison en temps réel pour héberger vos modèles ML en production. de manière rentable et avoir des performances élevées.

Voir le correspondant GitHub référentiel et essayez les exemples.

---

À propos des auteurs

Raghu Ramesha est un architecte de solutions ML au sein de l'équipe Amazon SageMaker Service. Il se concentre sur l'aide aux clients pour créer, déployer et migrer les charges de travail de production ML vers SageMaker à grande échelle. Il est spécialisé dans les domaines de l'apprentissage automatique, de l'IA et de la vision par ordinateur, et est titulaire d'une maîtrise en informatique de l'UT Dallas. Pendant son temps libre, il aime voyager et photographier.

Ram Végiraju est un architecte ML au sein de l'équipe SageMaker Service. Il se concentre sur l'aide aux clients pour créer et optimiser leurs solutions d'IA/ML sur Amazon SageMaker. Dans ses temps libres, il aime voyager et écrire.

Marc Karpe est un architecte ML au sein de l'équipe SageMaker Service. Il se concentre sur l'aide aux clients pour la conception, le déploiement et la gestion des charges de travail ML à grande échelle. Dans ses temps libres, il aime voyager et explorer de nouveaux endroits.

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 hautes performances sur Amazon SageMaker.

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.