Les applications d'apprentissage automatique (ML) sont complexes à déployer et nécessitent souvent une capacité d'hyper-évolutivité, et ont des exigences de latence ultra-faibles et des budgets de coûts stricts. Les cas d'utilisation tels que la détection des fraudes, les recommandations de produits et la prévision du trafic sont des exemples où les millisecondes comptent et sont essentielles au succès de l'entreprise. Des accords de niveau de service (SLA) stricts doivent être respectés, et une demande typique peut nécessiter plusieurs étapes telles que le prétraitement, la transformation des données, l'ingénierie des fonctionnalités, la logique de sélection des modèles, l'agrégation des modèles et le post-traitement.
Le déploiement de modèles ML à grande échelle avec des coûts et une efficacité de calcul optimisés peut être une tâche ardue et fastidieuse. Chaque modèle a ses propres mérites et dépendances en fonction des sources de données externes ainsi que de l'environnement d'exécution tel que la puissance CPU/GPU des ressources de calcul sous-jacentes. Une application peut nécessiter plusieurs modèles ML pour répondre à une seule demande d'inférence. Dans certains scénarios, une demande peut circuler sur plusieurs modèles. Il n'existe pas d'approche unique et il est important que les praticiens du ML recherchent des méthodes éprouvées pour résoudre les problèmes récurrents d'hébergement de ML. Cela a conduit à l'évolution des modèles de conception pour l'hébergement de modèles ML.
Dans cet article, nous explorons les modèles de conception courants pour créer des applications ML sur Amazon Sage Maker.
Modèles de conception pour la création d'applications de ML
Examinons les modèles de conception suivants à utiliser pour héberger des applications ML.
Applications ML basées sur un modèle unique
Il s'agit d'une excellente option lorsque votre cas d'utilisation ML nécessite un seul modèle pour répondre à une demande. Le modèle est déployé sur une infrastructure de calcul dédiée avec la possibilité d'évoluer en fonction du trafic d'entrée. Cette option est également idéale lorsque l'application cliente a une exigence d'inférence à faible latence (de l'ordre de quelques millisecondes ou secondes).
Applications ML basées sur plusieurs modèles
Pour rendre l'hébergement plus rentable, ce modèle de conception vous permet d'héberger plusieurs modèles sur la même infrastructure de locataire. Plusieurs modèles ML peuvent partager les ressources de l'hôte ou du conteneur, y compris la mise en cache des modèles ML les plus utilisés dans la mémoire, ce qui permet une meilleure utilisation de la mémoire et des ressources de calcul. Selon les types de modèles que vous avez choisi de déployer, le co-hébergement de modèles peut utiliser les méthodes suivantes :
- Hébergement multi-modèle – Cette option vous permet d'héberger plusieurs modèles à l'aide d'un conteneur de service partagé sur un seul point de terminaison. Cette fonctionnalité est idéale lorsque vous disposez d'un grand nombre de modèles similaires que vous pouvez servir via un conteneur de service partagé et que vous n'avez pas besoin d'accéder à tous les modèles en même temps.
- Hébergement multi-conteneurs – Cette option est idéale lorsque plusieurs modèles s'exécutent sur différentes piles de service avec des besoins en ressources similaires, et lorsque les modèles individuels n'ont pas suffisamment de trafic pour utiliser la pleine capacité des instances de point de terminaison. L'hébergement multi-conteneurs vous permet de déployer plusieurs conteneurs qui utilisent différents modèles ou frameworks sur un seul point de terminaison. Les modèles peuvent être complètement hétérogènes, avec leur propre pile de service indépendante.
- Ensembles modèles – Dans de nombreux cas d'utilisation en production, il peut souvent y avoir de nombreux modèles en amont qui alimentent un modèle en aval donné. C'est là que les ensembles sont utiles. Les modèles d'ensemble impliquent de mélanger la sortie d'un ou plusieurs modèles de base afin de réduire la erreur de généralisation de la prédiction. Les modèles de base peuvent être divers et entraînés par différents algorithmes. Les ensembles de modèles peuvent surpasser les modèles uniques car l'erreur de prédiction du modèle diminue lorsque l'approche d'ensemble est utilisée.
Voici les cas d'utilisation courants des modèles d'ensemble et leurs diagrammes de modèles de conception correspondants :
- Éparpiller-rassembler – Dans un modèle de dispersion-regroupement, une demande d'inférence est acheminée vers un certain nombre de modèles. Un agrégateur est ensuite utilisé pour collecter les réponses et les distiller en une seule réponse d'inférence. Par exemple, un cas d'utilisation de classification d'images peut utiliser trois modèles différents pour effectuer la tâche. Le modèle de dispersion-regroupement vous permet de combiner les résultats d'inférences exécutées sur trois modèles différents et de choisir le modèle de classification le plus probable.
- Agrégat de modèle – Dans un modèle d'agrégation, les sorties de plusieurs modèles sont moyennées. Pour les modèles de classification, les prédictions de plusieurs modèles sont évaluées pour déterminer la classe qui a reçu le plus de votes et est traitée comme la sortie finale de l'ensemble. Par exemple, dans un problème de classification à deux classes pour classer un ensemble de fruits comme des oranges ou des pommes, si deux modèles votent pour une orange et un modèle vote pour une pomme, alors la sortie agrégée sera une orange. L'agrégation aide à lutter contre l'imprécision dans les modèles individuels et rend la sortie plus précise.
- Sélection dynamique – Un autre modèle pour les modèles d'ensemble consiste à effectuer dynamiquement une sélection de modèle pour les attributs d'entrée donnés. Par exemple, dans une entrée donnée d'images de fruits, si l'entrée contient une orange, le modèle A sera utilisé car il est spécialisé pour les oranges. Si l'entrée contient une pomme, le modèle B sera utilisé car il est spécialisé pour les pommes.
- Applications ML d'inférence série – Avec un modèle d'inférence en série, également appelé pipeline d'inférence, les cas d'utilisation doivent prétraiter les données entrantes avant d'appeler un modèle ML pré-formé 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 consommées par les applications en aval. Un pipeline d'inférence vous permet de réutiliser le même code de prétraitement utilisé lors de la formation du modèle pour traiter les données de demande d'inférence utilisées pour les prédictions.
- Logique métier – La production de ML implique toujours une logique métier. Les modèles de logique métier impliquent tout ce qui est nécessaire pour effectuer une tâche ML qui n'est pas une inférence de modèle ML. Cela inclut le chargement du modèle à partir de Service de stockage simple Amazon (Amazon S3), par exemple, des recherches dans la base de données pour valider l'entrée, l'obtention de fonctionnalités précalculées à partir du magasin de fonctionnalités, etc. Une fois ces étapes de logique métier terminées, les entrées sont transmises aux modèles ML.
Options d'inférence ML
Pour le déploiement du modèle, il est important de travailler en arrière à partir de votre cas d'utilisation. Quelle est la fréquence de la prédiction ? Vous attendez-vous à un trafic en direct vers votre application et à une réponse en temps réel de vos clients ? Avez-vous de nombreux modèles entraînés pour différents sous-ensembles de données pour le même cas d'utilisation ? Le trafic de prédiction fluctue-t-il ? La latence de l'inférence est-elle un problème ? Sur la base de ces détails, tous les modèles de conception précédents peuvent être implémentés à l'aide des options de déploiement suivantes :
- Inférence en temps réel – L'inférence en temps réel est idéale pour les charges de travail d'inférence où vous avez des exigences en temps réel, interactives et à faible latence. Les charges de travail d'inférence ML en temps réel peuvent inclure une application ML basée sur un seul modèle, dans laquelle une application ne nécessite qu'un seul modèle ML pour traiter une seule requête, ou une application ML basée sur plusieurs modèles, dans laquelle une application nécessite plusieurs modèles ML pour traiter une seule requête. demande.
- Inférence en temps quasi réel (asynchrone) – Avec l'inférence en temps quasi réel, vous pouvez mettre en file d'attente les requêtes entrantes. Cela peut être utilisé pour exécuter des inférences sur des entrées de plusieurs centaines de Mo. Il fonctionne en temps quasi réel et permet aux utilisateurs d'utiliser l'entrée pour l'inférence et de lire la sortie du point de terminaison à partir d'un compartiment S3. Cela peut être particulièrement utile dans les cas de NLP et de vision par ordinateur, où il existe de grandes charges utiles qui nécessitent des temps de prétraitement plus longs.
- Inférence par lots – L'inférence par lots peut être utilisée pour exécuter l'inférence hors ligne sur un grand ensemble de données. Comme elle s'exécute hors ligne, l'inférence par lots n'offre pas la latence la plus faible. Ici, la demande d'inférence est traitée avec un déclencheur planifié ou basé sur un événement d'une tâche d'inférence par lots.
- Inférence sans serveur – L'inférence sans serveur est idéale pour les charges de travail qui ont des périodes d'inactivité entre les pics de trafic et peuvent tolérer quelques secondes supplémentaires de latence (démarrage à froid) pour la première invocation après une période d'inactivité. Par exemple, un service de chatbot ou une application pour traiter des formulaires ou analyser des données à partir de documents. Dans ce cas, vous souhaiterez peut-être une option d'inférence en ligne capable de provisionner et d'adapter automatiquement la capacité de calcul en fonction du volume de demandes d'inférence. Et pendant les périodes d'inactivité, il devrait pouvoir désactiver complètement la capacité de calcul afin que vous ne soyez pas facturé. L'inférence sans serveur élimine la lourde charge indifférenciée de la sélection et de la gestion des serveurs en lançant automatiquement les ressources de calcul et en les échelonnant en fonction du trafic.
Utiliser les fonctions de fitness pour sélectionner la bonne option d'inférence ML
Décider de la bonne option d'hébergement est important car cela a un impact sur les utilisateurs finaux rendus par vos applications. Pour cela, nous empruntons le concept de fonctions de remise en forme, qui a été inventé par Neal Ford et ses collègues d'AWS Partner ThoughtWorks dans leur travail Construire des architectures évolutives. Les fonctions de remise en forme fournissent une évaluation prescriptive des différentes options d'hébergement en fonction des objectifs du client. Les fonctions de mise en forme vous aident à obtenir les données nécessaires pour permettre l'évolution prévue de votre architecture. Ils définissent des valeurs mesurables pour évaluer dans quelle mesure votre solution est proche d'atteindre les objectifs que vous vous êtes fixés. Les fonctions de fitness peuvent et doivent être adaptées à mesure que l'architecture évolue pour guider un processus de changement souhaité. Cela fournit aux architectes un outil pour guider leurs équipes tout en maintenant leur autonomie.
Les clients se soucient de cinq fonctions de mise en forme principales lorsqu'il s'agit de sélectionner la bonne option d'inférence ML pour héberger leurs modèles et applications ML.
Fonction de remise en forme | Description |
Prix |
Le déploiement et la maintenance d'un modèle ML et d'une application ML sur un framework évolutif est un processus métier critique, et les coûts peuvent varier considérablement en fonction des choix effectués concernant l'infrastructure d'hébergement du modèle, l'option d'hébergement, les frameworks ML, les caractéristiques du modèle ML, les optimisations, la politique de mise à l'échelle, et plus. Les charges de travail doivent utiliser l'infrastructure matérielle de manière optimale pour s'assurer que les coûts restent sous contrôle. Cette fonction de remise en forme fait spécifiquement référence au coût de l'infrastructure, qui fait partie du coût total de possession (TCO) global. Les coûts d'infrastructure sont les coûts combinés du stockage, du réseau et du calcul. Il est également essentiel de comprendre les autres composants du TCO, y compris les coûts opérationnels et les coûts de sécurité et de conformité. Les coûts opérationnels sont les coûts combinés d'exploitation, de surveillance et de maintenance de l'infrastructure ML. Les coûts opérationnels sont calculés comme le nombre d'ingénieurs requis en fonction de chaque scénario et le salaire annuel des ingénieurs, agrégés sur une période spécifique. Clients utilisant des solutions de ML autogérées sur Cloud de calcul élastique Amazon (Amazon EC2), Service de conteneur élastique Amazon (Amazon ECS), et Service Amazon Elastic Kubernetes (Amazon EKS) doivent créer eux-mêmes des outils opérationnels. Les clients utilisant SageMaker encourent un coût total de possession nettement inférieur. L'inférence SageMaker est un service entièrement géré et fournit des fonctionnalités prêtes à l'emploi pour le déploiement de modèles ML pour l'inférence. Vous n'avez pas besoin de provisionner des instances, de surveiller l'intégrité des instances, de gérer les mises à jour ou les correctifs de sécurité, d'émettre des métriques opérationnelles ou de créer une surveillance pour vos charges de travail d'inférence ML. Il dispose de fonctionnalités intégrées pour garantir une disponibilité et une résilience élevées. SageMaker prend en charge la sécurité avec un chiffrement de bout en bout au repos et en transit, y compris le chiffrement du volume racine et Boutique de blocs élastiques Amazon (Amazon EBS), Cloud privé virtuel Amazon (Amazon VPC), Lien privé AWS, clés gérées par le client, Gestion des identités et des accès AWS (IAM) contrôle d'accès fin, AWS CloudTrail audits, chiffrement entre les nœuds pour la formation, contrôle d'accès basé sur des balises, isolation du réseau et proxy d'application interactif. Toutes ces fonctionnalités de sécurité sont fournies prêtes à l'emploi dans SageMaker et peuvent faire économiser aux entreprises des dizaines de mois de développement d'efforts d'ingénierie sur une période de 3 ans. SageMaker est un service éligible HIPAA et est certifié PCI, SOC, GDPR et ISO. SageMaker prend également en charge les terminaux FIPS. Pour plus d'informations sur le coût total de possession, reportez-vous à Le coût total de possession d'Amazon SageMaker. |
Latence d'inférence | De nombreux modèles et applications ML sont critiques pour la latence, dans lesquels la latence d'inférence doit être dans les limites spécifiées par un objectif de niveau de service. La latence d'inférence dépend d'une multitude de facteurs, notamment la taille et la complexité du modèle, la plate-forme matérielle, l'environnement logiciel et l'architecture du réseau. Par exemple, des modèles plus grands et plus complexes peuvent prendre plus de temps pour exécuter l'inférence. |
Débit (transactions par seconde) | Pour l'inférence de modèle, l'optimisation du débit est cruciale pour le réglage des performances et la réalisation de l'objectif commercial de l'application ML. Alors que nous continuons à progresser rapidement dans tous les aspects du ML, y compris les implémentations de bas niveau d'opérations mathématiques dans la conception de puces, les bibliothèques spécifiques au matériel jouent un rôle plus important dans l'optimisation des performances. Divers facteurs tels que la taille de la charge utile, les sauts de réseau, la nature des sauts, les fonctionnalités de graphe de modèle, les opérateurs dans le modèle et le profil CPU, GPU et mémoire des instances d'hébergement de modèle affectent le débit du modèle ML. |
Mise à l'échelle de la complexité de la configuration | Il est essentiel que les modèles ou les applications ML s'exécutent sur une infrastructure évolutive capable de gérer la demande d'un trafic variable. Il permet également une utilisation maximale des ressources CPU et GPU et empêche le sur-approvisionnement des ressources de calcul. |
Modèle de trafic attendu | Les modèles ou applications ML peuvent avoir différents modèles de trafic, allant du trafic en temps réel continu aux pics périodiques de milliers de requêtes par seconde, et des modèles de requête peu fréquents et imprévisibles aux requêtes par lots hors ligne sur des ensembles de données plus volumineux. Il est recommandé de revenir en arrière à partir du modèle de trafic attendu afin de sélectionner la bonne option d'hébergement pour votre modèle ML. |
Déployer des modèles avec SageMaker
SageMaker est un service AWS entièrement géré qui offre à chaque développeur et scientifique des données la possibilité de créer, former et déployer rapidement des modèles ML à grande échelle. Avec l'inférence SageMaker, vous pouvez déployer vos modèles ML sur des points de terminaison hébergés et obtenir des résultats d'inférence. SageMaker propose une large sélection de matériel et de fonctionnalités pour répondre aux exigences de votre charge de travail, vous permettant de sélectionner plus de 70 types d'instances avec accélération matérielle. SageMaker peut également fournir une recommandation de type d'instance d'inférence à l'aide d'une nouvelle fonctionnalité appelée SageMaker Inference Recommender, au cas où vous n'êtes pas sûr de celle qui serait la plus optimale pour votre charge de travail.
Vous pouvez choisir des options de déploiement pour répondre au mieux à vos cas d'utilisation, tels que l'inférence en temps réel, les points de terminaison asynchrones, par lots et même sans serveur. De plus, SageMaker propose diverses stratégies de déploiement telles que canary, bleu vert, ombre, et des tests A/B pour le déploiement de modèles, ainsi qu'un déploiement rentable avec des points de terminaison multi-modèles et multi-conteneurs et une mise à l'échelle élastique. Avec l'inférence SageMaker, vous pouvez afficher les mesures de performances de vos terminaux dans Amazon Cloud Watch, dimensionner automatiquement les points de terminaison en fonction du trafic, et mettez à jour vos modèles en production sans perdre de disponibilité.
SageMaker propose quatre options pour déployer votre modèle afin que vous puissiez commencer à faire des prédictions :
- Inférence en temps réel – Cela convient aux charges de travail avec des exigences de latence en millisecondes, des tailles de charge utile allant jusqu'à 6 Mo et des temps de traitement allant jusqu'à 60 secondes.
- Transformation par lots – Ceci est idéal pour les prédictions hors ligne sur de grands lots de données disponibles à l'avance.
- Inférence asynchrone – Ceci est conçu pour les charges de travail qui n'ont pas d'exigences de latence inférieure à la seconde, des tailles de charge utile allant jusqu'à 1 Go et des temps de traitement allant jusqu'à 15 minutes.
- Inférence sans serveur – Avec l'inférence sans serveur, vous pouvez rapidement déployer des modèles ML pour l'inférence sans avoir à configurer ou à gérer l'infrastructure sous-jacente. De plus, vous ne payez que pour la capacité de calcul utilisée pour traiter les demandes d'inférence, ce qui est idéal pour les charges de travail intermittentes.
Le diagramme suivant peut vous aider à comprendre les options de déploiement du modèle d'hébergement SageMaker ainsi que les évaluations de fonction de fitness associées.
Explorons chacune des options de déploiement plus en détail.
Inférence en temps réel dans SageMaker
L'inférence en temps réel SageMaker est recommandée si vous avez un trafic soutenu et avez besoin d'une latence plus faible et cohérente pour vos demandes avec des tailles de charge utile allant jusqu'à 6 Mo et des temps de traitement allant jusqu'à 60 secondes. Vous déployez votre modèle sur les services d'hébergement SageMaker et obtenez un point de terminaison qui peut être utilisé pour l'inférence. Ces points de terminaison sont entièrement gérés et prennent en charge la mise à l'échelle automatique. L'inférence en temps réel est populaire pour les cas d'utilisation où vous attendez une réponse synchrone à faible latence avec des modèles de trafic prévisibles, tels que des recommandations personnalisées pour des produits et services ou des cas d'utilisation de détection de fraude transactionnelle.
En règle générale, une application cliente envoie des requêtes au point de terminaison HTTPS SageMaker pour obtenir des inférences à partir d'un modèle déployé. Vous pouvez déployer plusieurs variantes d'un modèle sur le même point de terminaison HTTPS SageMaker. Ceci est utile pour tester les variations d'un modèle en production. La mise à l'échelle automatique vous permet d'ajuster dynamiquement le nombre d'instances provisionnées pour un modèle en réponse aux modifications de votre charge de travail.
Le tableau suivant fournit des conseils sur l'évaluation de l'inférence en temps réel SageMaker basée sur les fonctions de fitness.
Fonction de remise en forme | Description |
Prix |
Les points de terminaison en temps réel offrent une réponse synchrone aux demandes d'inférence. Étant donné que le point de terminaison est toujours en cours d'exécution et disponible pour fournir une réponse d'inférence synchrone en temps réel, vous payez pour l'utilisation de l'instance. Les coûts peuvent rapidement s'accumuler lorsque vous déployez plusieurs points de terminaison, en particulier si les points de terminaison n'utilisent pas pleinement les instances sous-jacentes. Choisir la bonne instance pour votre modèle vous permet de vous assurer que vous disposez de l'instance la plus performante au coût le plus bas pour vos modèles. La mise à l'échelle automatique est recommandée pour ajuster dynamiquement la capacité en fonction du trafic afin de maintenir des performances stables et prévisibles au moindre coût possible. SageMaker étend l'accès aux familles d'instances ML basées sur Graviton2 et Graviton3. AWS Graviton Les processeurs sont conçus sur mesure par Amazon Web Services à l'aide de cœurs Arm Neoverse 64 bits pour offrir les meilleures performances de prix pour vos charges de travail cloud exécutées sur Amazon EC2. Avec les instances basées sur Graviton, vous disposez de plus d'options pour optimiser les coûts et les performances lors du déploiement de vos modèles ML sur SageMaker. SageMaker prend également en charge Instances Inf1, offrant une inférence ML performante et économique. Avec 1–16 Puces AWS Inferentia par instance, les instances Inf1 peuvent évoluer en termes de performances et offrir un débit jusqu'à trois fois supérieur et un coût par inférence jusqu'à 50 % inférieur à celui des instances AWS basées sur GPU. Pour utiliser les instances Inf1 dans SageMaker, vous pouvez compiler vos modèles entraînés à l'aide de Amazon Sage Maker Neo et sélectionnez les instances Inf1 pour déployer le modèle compilé sur SageMaker. Vous pouvez également explorer Plans d'épargne pour SageMaker pour bénéficier d'économies jusqu'à 64% par rapport au prix à la demande. Lorsque vous créez un point de terminaison, SageMaker attache un volume de stockage EBS à chaque instance de calcul ML qui héberge le point de terminaison. La taille du volume de stockage dépend du type d'instance. Le coût supplémentaire pour les points de terminaison en temps réel comprend le coût du Go-mois de stockage provisionné, plus les données en Go traitées dans et les données en Go traitées hors de l'instance de point de terminaison. |
Latence d'inférence | L'inférence en temps réel est idéale lorsque vous avez besoin d'un point de terminaison persistant avec des exigences de latence en millisecondes. Il prend en charge des tailles de charge utile allant jusqu'à 6 Mo et des temps de traitement allant jusqu'à 60 secondes. |
Cadence de production |
Une valeur idéale du débit d'inférence dépend de facteurs tels que le modèle, la taille d'entrée du modèle, la taille du lot et le type d'instance de point de terminaison. Comme bonne pratique, passez en revue les métriques CloudWatch pour les demandes d'entrée et l'utilisation des ressources, et sélectionnez le type d'instance approprié pour obtenir un débit optimal. Une application métier peut être optimisée en débit ou en latence. Par exemple, le traitement par lots dynamique peut aider à augmenter le débit des applications sensibles à la latence en utilisant l'inférence en temps réel. Cependant, il existe des limites à la taille des lots, sans lesquelles la latence d'inférence pourrait être affectée. La latence d'inférence augmentera à mesure que vous augmentez la taille du lot pour améliorer le débit. Par conséquent, l'inférence en temps réel est une option idéale pour les applications sensibles à la latence. SageMaker fournit des options d'inférence asynchrone et de transformation par lots, qui sont optimisées pour donner un débit plus élevé par rapport à l'inférence en temps réel si les applications métier peuvent tolérer une latence légèrement plus élevée. |
Mise à l'échelle de la complexité de la configuration |
Prise en charge des terminaux SageMaker en temps réel mise à l'échelle automatique hors de la boîte. Lorsque la charge de travail augmente, la mise à l'échelle automatique met davantage d'instances en ligne. Lorsque la charge de travail diminue, la mise à l'échelle automatique supprime les instances inutiles, ce qui vous aide à réduire vos coûts de calcul. Sans mise à l'échelle automatique, vous devez provisionner les pics de trafic ou l'indisponibilité du modèle de risque. À moins que le trafic vers votre modèle ne soit stable tout au long de la journée, il y aura un excès de capacité inutilisée. Cela entraîne une faible utilisation et un gaspillage des ressources. Avec SageMaker, vous pouvez configurer différentes options de mise à l'échelle en fonction du modèle de trafic attendu. La mise à l'échelle simple ou la mise à l'échelle du suivi des cibles est idéale lorsque vous souhaitez effectuer une mise à l'échelle en fonction d'une métrique CloudWatch spécifique. Vous pouvez le faire en choisissant une métrique spécifique et en définissant des valeurs de seuil. Les mesures recommandées pour cette option sont moyennes Si vous avez besoin d'une configuration avancée, vous pouvez définir une stratégie de mise à l'échelle par étapes pour ajuster dynamiquement le nombre d'instances à mettre à l'échelle en fonction de la taille de la violation d'alarme. Cela vous aide à configurer une réponse plus agressive lorsque la demande atteint un certain niveau. Vous pouvez utiliser une option de mise à l'échelle planifiée lorsque vous savez que la demande suit un calendrier particulier dans la journée, la semaine, le mois ou l'année. Cela vous aide à spécifier une planification unique ou récurrente ou des expressions cron ainsi que des heures de début et de fin, qui forment les limites du démarrage et de l'arrêt de l'action de mise à l'échelle automatique. Pour plus de détails, reportez-vous à Configuration des points de terminaison d'inférence d'autoscaling dans Amazon SageMaker ainsi que Test de charge et optimisation d'un point de terminaison Amazon SageMaker à l'aide de la mise à l'échelle automatique. |
Modèle de trafic | L'inférence en temps réel est idéale pour les charges de travail avec un modèle de trafic continu ou régulier. |
Inférence asynchrone dans SageMaker
L'inférence asynchrone SageMaker est une nouvelle fonctionnalité de SageMaker qui met en file d'attente les demandes entrantes et les traite de manière asynchrone. Cette option est idéale pour les demandes avec de grandes tailles de charge utile (jusqu'à 1 Go), des temps de traitement longs (jusqu'à 15 minutes) et des exigences de latence en temps quasi réel. Les exemples de charges de travail pour l'inférence asynchrone incluent les entreprises de soins de santé qui traitent des images ou des vidéos biomédicales haute résolution telles que des échocardiogrammes pour détecter des anomalies. Ces applications reçoivent des rafales de trafic entrant à différents moments de la journée et nécessitent un traitement en temps quasi réel à faible coût. Les temps de traitement de ces demandes peuvent varier de l'ordre de quelques minutes, éliminant ainsi la nécessité d'exécuter une inférence en temps réel. Au lieu de cela, les charges utiles d'entrée peuvent être traitées de manière asynchrone à partir d'un magasin d'objets comme Amazon S3 avec une mise en file d'attente automatique et un seuil de simultanéité prédéfini. Lors du traitement, SageMaker place la réponse d'inférence dans l'emplacement Amazon S3 précédemment renvoyé. Vous pouvez éventuellement choisir de recevoir des notifications de réussite ou d'erreur via Service de notification simple d'Amazon (Amazon SNS).
Le tableau suivant fournit des conseils sur l'évaluation de l'inférence asynchrone SageMaker basée sur les fonctions de fitness.
Fonction de remise en forme | Description |
Prix | L'inférence asynchrone est un excellent choix pour les charges de travail sensibles aux coûts avec des charges utiles importantes et un trafic en rafale. L'inférence asynchrone vous permet de réduire les coûts en mettant à l'échelle automatiquement le nombre d'instances à zéro lorsqu'il n'y a pas de requêtes à traiter, de sorte que vous ne payez que lorsque votre point de terminaison traite les requêtes. Les demandes reçues lorsqu'il n'y a aucune instance sont mises en file d'attente pour traitement après la mise à l'échelle du point de terminaison. |
Latence d'inférence | L'inférence asynchrone est idéale pour les exigences de latence en temps quasi réel. Les demandes sont placées dans une file d'attente et traitées dès que le calcul est disponible. Cela se traduit généralement par des dizaines de millisecondes de latence. |
Cadence de production | L'inférence asynchrone est idéale pour les cas d'utilisation non sensibles à la latence, car les applications n'ont pas à faire de compromis sur le débit. Les requêtes ne sont pas supprimées pendant les pics de trafic, car le point de terminaison d'inférence asynchrone met les requêtes en file d'attente au lieu de les supprimer. |
Mise à l'échelle de la complexité de la configuration |
SageMaker prend en charge mise à l'échelle automatique pour point de terminaison asynchrone. Contrairement aux points de terminaison hébergés en temps réel, les points de terminaison d'inférence asynchrone prennent en charge la réduction des instances à zéro en définissant la capacité minimale sur zéro. Pour les points de terminaison asynchrones, SageMaker vous recommande vivement de créer une configuration de politique pour la mise à l'échelle du suivi de la cible pour un modèle déployé (variante). Pour les cas d'utilisation qui peuvent tolérer une pénalité de démarrage à froid de quelques minutes, vous pouvez éventuellement réduire le nombre d'instances de point de terminaison à zéro lorsqu'il n'y a pas de requêtes en attente et remonter à mesure que de nouvelles requêtes arrivent afin de ne payer que pour la durée pendant laquelle le les points de terminaison traitent activement les demandes. |
Modèle de trafic | Les points de terminaison asynchrones mettent en file d'attente les demandes entrantes et les traitent de manière asynchrone. Ils constituent une bonne option pour les modèles de trafic intermittents ou peu fréquents. |
Inférence par lots dans SageMaker
La transformation par lots SageMaker est idéale pour les prédictions hors ligne sur de grands lots de données disponibles à l'avance. La fonction de transformation par lots est une méthode hautes performances et à haut débit pour transformer des données et générer des inférences. Il est idéal pour les scénarios où vous traitez de gros lots de données, n'avez pas besoin d'une latence inférieure à une seconde ou avez besoin à la fois de prétraiter et de transformer les données de formation. Les clients de certains domaines tels que la publicité et le marketing ou les soins de santé ont souvent besoin de faire des prédictions hors ligne sur des ensembles de données à grande échelle où le débit élevé est souvent l'objectif du cas d'utilisation et la latence n'est pas un problème.
Lorsqu'une tâche de transformation par lots démarre, SageMaker initialise les instances de calcul et distribue la charge de travail d'inférence entre elles. Il libère les ressources lorsque les travaux sont terminés, de sorte que vous ne payez que ce qui a été utilisé pendant l'exécution de votre travail. Lorsque la tâche est terminée, SageMaker enregistre les résultats de la prédiction dans un compartiment S3 que vous spécifiez. Les tâches d'inférence par lots sont généralement de bons candidats pour la mise à l'échelle horizontale. Chaque travailleur au sein d'un cluster peut opérer sur un sous-ensemble de données différent sans avoir besoin d'échanger des informations avec d'autres travailleurs. AWS propose plusieurs options de stockage et de calcul qui permettent une mise à l'échelle horizontale. Les exemples de charges de travail pour la transformation par lots SageMaker incluent des applications hors ligne telles que des applications bancaires pour prédire l'attrition des clients où une tâche hors ligne peut être planifiée pour s'exécuter périodiquement.
Le tableau suivant fournit des conseils sur l'évaluation de la transformation par lots SageMaker en fonction des fonctions de remise en forme.
Fonction de remise en forme | Description |
Prix | La transformation par lots SageMaker vous permet d'exécuter des prédictions sur de grands ou petits ensembles de données par lots. Vous êtes facturé pour le type d'instance que vous choisissez, en fonction de la durée d'utilisation. SageMaker gère le provisionnement des ressources au début du travail et les libère lorsque le travail est terminé. Il n'y a pas de coût supplémentaire de traitement des données. |
Latence d'inférence | Vous pouvez utiliser un appel basé sur un événement ou planifié. La latence peut varier en fonction de la taille des données d'inférence, de la simultanéité des tâches, de la complexité du modèle et de la capacité de l'instance de calcul. |
Cadence de production |
Les tâches de transformation par lots peuvent être effectuées sur une gamme d'ensembles de données, allant de pétaoctets de données à de très petits ensembles de données. Il n'est pas nécessaire de redimensionner des ensembles de données plus volumineux en petits blocs de données. Vous pouvez accélérer les tâches de transformation par lots en utilisant des valeurs optimales pour des paramètres tels que MaxPayloadInMo, MaxConcurrentTransformsou Stratégie par lots. La valeur idéale pour Le traitement par lots peut augmenter le débit et optimiser vos ressources car il permet de réaliser un plus grand nombre d'inférences dans un certain laps de temps au détriment de la latence. Pour optimiser le déploiement du modèle pour un débit plus élevé, la règle générale consiste à augmenter la taille du lot jusqu'à ce que le débit diminue. |
Mise à l'échelle de la complexité de la configuration | La transformation par lots SageMaker est utilisée pour l'inférence hors ligne qui n'est pas sensible à la latence. |
Modèle de trafic | Pour l'inférence hors ligne, une tâche de transformation par lots est planifiée ou démarrée à l'aide d'un déclencheur basé sur un événement. |
Inférence sans serveur dans SageMaker
L'inférence sans serveur SageMaker vous permet de déployer des modèles ML pour l'inférence sans avoir à configurer ou à gérer l'infrastructure sous-jacente. En fonction du volume de demandes d'inférence reçues par votre modèle, l'inférence sans serveur SageMaker provisionne, dimensionne et désactive automatiquement la capacité de calcul. Par conséquent, vous ne payez que le temps de calcul pour exécuter votre code d'inférence et la quantité de données traitées, et non le temps d'inactivité. Vous pouvez utiliser les algorithmes intégrés de SageMaker et les conteneurs de service de framework ML pour déployer votre modèle sur un point de terminaison d'inférence sans serveur ou choisir d'apporter votre propre conteneur. Si le trafic devient prévisible et stable, vous pouvez facilement passer d'un point de terminaison d'inférence sans serveur à un point de terminaison en temps réel SageMaker sans avoir à modifier votre image de conteneur. Avec l'inférence sans serveur, vous bénéficiez également d'autres fonctionnalités de SageMaker, notamment des métriques intégrées telles que le nombre d'appels, les pannes, la latence, les métriques de l'hôte et les erreurs dans CloudWatch.
Le tableau suivant fournit des conseils sur l'évaluation de l'inférence sans serveur SageMaker en fonction des fonctions de fitness.
Fonction de remise en forme | Description |
Prix | Avec un modèle de paiement à l'utilisation, l'inférence sans serveur est une option rentable si vous avez des modèles de trafic peu fréquents ou intermittents. Vous ne payez que pour la durée pendant laquelle le point de terminaison traite la demande, et vous pouvez donc réduire les coûts si le modèle de trafic est intermittent. |
Latence d'inférence |
Les points de terminaison sans serveur offrent une faible latence d'inférence (de l'ordre de quelques millisecondes à quelques secondes), avec la possibilité de passer instantanément de dizaines à des milliers d'inférences en quelques secondes en fonction des modèles d'utilisation, ce qui le rend idéal pour les applications ML avec un trafic intermittent ou imprévisible. Étant donné que les points de terminaison sans serveur fournissent des ressources de calcul à la demande, votre point de terminaison peut subir quelques secondes supplémentaires de latence (démarrage à froid) pour le premier appel après une période d'inactivité. Le temps de démarrage à froid dépend de la taille de votre modèle, du temps nécessaire pour télécharger votre modèle et du temps de démarrage de votre conteneur. |
Cadence de production | Lors de la configuration de votre point de terminaison sans serveur, vous pouvez spécifier la taille de la mémoire et le nombre maximal d'appels simultanés. L'inférence sans serveur SageMaker attribue automatiquement des ressources de calcul proportionnelles à la mémoire que vous sélectionnez. Si vous choisissez une taille de mémoire supérieure, votre conteneur a accès à davantage de vCPU. En règle générale, la taille de la mémoire doit être au moins aussi grande que la taille de votre modèle. Les tailles de mémoire que vous pouvez choisir sont 1024 Mo, 2048 Mo, 3072 Mo, 4096 Mo, 5120 Mo et 6144 Mo. Quelle que soit la taille de mémoire que vous choisissez, les terminaux sans serveur disposent de 5 Go de stockage sur disque éphémère. |
Mise à l'échelle de la complexité de la configuration | Les points de terminaison sans serveur lancent automatiquement les ressources de calcul et les augmentent et diminuent en fonction du trafic, éliminant ainsi le besoin de choisir des types d'instance ou de gérer des politiques de mise à l'échelle. Cela enlève le poids indifférencié de la sélection et de la gestion des serveurs. |
Modèle de trafic | L'inférence sans serveur est idéale pour les charges de travail avec des modèles de trafic peu fréquents ou intermittents. |
Modèle hébergeant des modèles de conception dans SageMaker
Les points de terminaison d'inférence SageMaker utilisent des conteneurs Docker pour héberger des modèles ML. Les conteneurs vous permettent de regrouper des logiciels dans des unités standardisées qui s'exécutent de manière cohérente sur n'importe quelle plate-forme prenant en charge Docker. Cela garantit la portabilité entre les plates-formes, des déploiements d'infrastructure immuables et une gestion des changements et des implémentations CI/CD plus faciles. SageMaker fournit des conteneurs gérés prédéfinis pour les frameworks populaires tels que Apache MXNet, TensorFlow, PyTorch, Sklearn et Hugging Face. Pour une liste complète des images de conteneur SageMaker disponibles, reportez-vous à Images de conteneurs de Deep Learning disponibles. Dans le cas où SageMaker n'a pas de conteneur pris en charge, vous pouvez également créer votre propre conteneur (BYOC) et pousser votre propre image personnalisée, en installant les dépendances nécessaires à votre modèle.
Pour déployer un modèle sur SageMaker, vous avez besoin d'un conteneur (conteneurs de framework gérés SageMaker ou BYOC) et d'une instance de calcul pour héberger le conteneur. SageMaker prend en charge plusieurs options avancées pour les modèles de conception d'hébergement de modèles ML courants où les modèles peuvent être hébergés sur un seul conteneur ou co-hébergés sur un conteneur partagé.
Une application ML en temps réel peut utiliser un seul modèle ou plusieurs modèles pour répondre à une seule requête de prédiction. Le diagramme suivant montre divers scénarios d'inférence pour une application ML.
Explorons une option d'hébergement SageMaker appropriée pour chacun des scénarios d'inférence précédents. Vous pouvez vous référer aux fonctions de fitness pour évaluer si c'est la bonne option pour le cas d'utilisation donné.
Hébergement d'une application ML basée sur un modèle unique
Il existe plusieurs options pour héberger des applications ML basées sur un modèle unique à l'aide des services d'hébergement SageMaker en fonction du scénario de déploiement.
Point de terminaison à modèle unique
Les points de terminaison à modèle unique SageMaker vous permettent d'héberger un modèle sur un conteneur hébergé sur des instances dédiées pour une faible latence et un débit élevé. Ces points de terminaison sont entièrement gérés et prennent en charge la mise à l'échelle automatique. Vous pouvez configurer le point de terminaison à modèle unique en tant que point de terminaison provisionné où vous transmettez la configuration de l'infrastructure de point de terminaison telle que le type et le nombre d'instances, ou un point de terminaison sans serveur où SageMaker lance automatiquement les ressources de calcul et les fait évoluer en fonction du trafic, éliminant ainsi le besoin pour choisir les types d'instance ou gérer les politiques de mise à l'échelle. Les points de terminaison sans serveur sont destinés aux applications avec un trafic intermittent ou imprévisible.
Le diagramme suivant montre des scénarios d'inférence de point de terminaison à modèle unique.
Le tableau suivant fournit des conseils sur l'évaluation des fonctions de remise en forme pour un point de terminaison à modèle unique provisionné. Pour les évaluations de la fonction de remise en forme des points de terminaison sans serveur, reportez-vous à la section sur les points de terminaison sans serveur de cet article.
Fonction de remise en forme | Description |
Prix | Vous êtes facturé pour l'utilisation du type d'instance que vous choisissez. Étant donné que le point de terminaison est toujours en cours d'exécution et disponible, les coûts peuvent rapidement s'accumuler. Choisir la bonne instance pour votre modèle vous permet de vous assurer que vous disposez de l'instance la plus performante au coût le plus bas pour vos modèles. La mise à l'échelle automatique est recommandée pour ajuster dynamiquement la capacité en fonction du trafic afin de maintenir des performances stables et prévisibles au moindre coût possible. |
Latence d'inférence | Un point de terminaison à modèle unique fournit une inférence synchrone interactive en temps réel avec des exigences de latence de l'ordre de la milliseconde. |
Cadence de production | Le débit peut être affecté par divers facteurs, tels que la taille d'entrée du modèle, la taille du lot, le type d'instance de point de terminaison, etc. Il est recommandé d'examiner les métriques CloudWatch pour les demandes d'entrée et l'utilisation des ressources, et de sélectionner le type d'instance approprié pour obtenir un débit optimal. SageMaker fournit des fonctionnalités pour gérer les ressources et optimiser les performances d'inférence lors du déploiement de modèles ML. Vous pouvez optimiser les performances du modèle avec Neo, ou utilisez des instances Inf1 pour un meilleur débit de vos modèles hébergés SageMaker à l'aide d'une instance GPU pour votre point de terminaison. |
Mise à l'échelle de la complexité de la configuration | La mise à l'échelle automatique est prise en charge par défaut. SageMaker recommande de choisir un configuration de mise à l'échelle en effectuant tests de charge. |
Modèle de trafic | Un point de terminaison à modèle unique est idéal pour les charges de travail avec des modèles de trafic prévisibles. |
Co-hébergement de plusieurs modèles
Lorsque vous traitez un grand nombre de modèles, le déploiement de chacun sur un point de terminaison individuel avec un conteneur et une instance dédiés peut entraîner une augmentation significative des coûts. De plus, il devient également difficile de gérer autant de modèles en production, en particulier lorsque vous n'avez pas besoin d'invoquer tous les modèles en même temps mais que vous avez toujours besoin qu'ils soient disponibles à tout moment. Le co-hébergement de plusieurs modèles sur les mêmes ressources de calcul sous-jacentes facilite la gestion des déploiements ML à grande échelle et réduit vos coûts d'hébergement grâce à une utilisation accrue du point de terminaison et de ses ressources de calcul sous-jacentes. SageMaker prend en charge les options avancées de co-hébergement de modèles telles que le point de terminaison multi-modèle (MME) pour les modèles homogènes et le point de terminaison multi-conteneurs (MCE) pour les modèles hétérogènes. Les modèles homogènes utilisent le même framework ML sur un conteneur de service partagé, tandis que les modèles hétérogènes vous permettent de déployer plusieurs conteneurs de service qui utilisent différents modèles ou frameworks sur un seul point de terminaison.
Le schéma suivant montre les options de co-hébergement de modèles à l'aide de SageMaker.
Points de terminaison multimodèles SageMaker
SageMaker MME vous permettent d'héberger plusieurs modèles à l'aide d'un conteneur de service partagé sur un seul point de terminaison. Il s'agit d'une solution évolutive et rentable pour déployer un grand nombre de modèles qui répondent au même cas d'utilisation, cadre ou logique d'inférence. Les MME peuvent répondre dynamiquement aux requêtes en fonction du modèle invoqué par l'appelant. Cela réduit également les frais généraux de déploiement, car SageMaker gère le chargement des modèles en mémoire et les met à l'échelle en fonction des modèles de trafic vers eux. Cette fonctionnalité est idéale lorsque vous disposez d'un grand nombre de modèles similaires que vous pouvez servir via un conteneur de service partagé et que vous n'avez pas besoin d'accéder à tous les modèles en même temps. Les points de terminaison multimodèles permettent également le partage du temps des ressources mémoire entre vos modèles. Cela fonctionne mieux lorsque les modèles sont assez similaires en taille et en latence d'invocation, ce qui permet aux MME d'utiliser efficacement les instances sur tous les modèles. Les MME SageMaker prennent en charge l'hébergement de modèles basés sur CPU et GPU. En utilisant des modèles basés sur GPU, vous pouvez réduire les coûts de déploiement de votre modèle grâce à une utilisation accrue du point de terminaison et de ses instances de calcul accéléré sous-jacentes. Pour un cas d'utilisation réel des MME, reportez-vous à Comment mettre à l'échelle l'inférence d'apprentissage automatique pour les cas d'utilisation SaaS multi-locataires.
Le tableau suivant fournit des conseils sur l'évaluation des fonctions de fitness pour les MME.
Fonction de remise en forme | Description |
Prix |
Les MME permettent d'utiliser un conteneur de service partagé pour héberger des milliers de modèles sur un seul point de terminaison. Cela réduit considérablement les coûts d'hébergement en améliorant l'utilisation des points de terminaison par rapport à l'utilisation de points de terminaison à modèle unique. Par exemple, si vous avez 10 modèles à déployer à l'aide d'une instance ml.c5.large, basée sur Tarification SageMaker, le coût d'avoir 10 points de terminaison persistants à modèle unique est : 10 x 0.102 USD = 1.02 USD par heure. Alors qu'avec un MME hébergeant les 10 modèles, nous réalisons 10 fois plus d'économies : 1 * 0.102 $ = 0.102 $ par heure. |
Latence d'inférence |
Par défaut, les MME mettent en cache les modèles fréquemment utilisés en mémoire et sur disque pour fournir une inférence à faible latence. Les modèles mis en cache sont déchargés ou supprimés du disque uniquement lorsqu'un conteneur manque de mémoire ou d'espace disque pour accueillir un modèle nouvellement ciblé. Les MME permettent le chargement paresseux des modèles, ce qui signifie que les modèles sont chargés en mémoire lorsqu'ils sont invoqués pour la première fois. Cela optimise l'utilisation de la mémoire ; cependant, cela provoque des pics de temps de réponse lors du premier chargement, ce qui entraîne un problème de démarrage à froid. Par conséquent, les MME sont également bien adaptés aux scénarios qui peuvent tolérer des pénalités de latence occasionnelles liées au démarrage à froid qui se produisent lors de l'appel de modèles peu utilisés. Pour atteindre les objectifs de latence et de débit des applications ML, les instances GPU sont préférées aux instances CPU (compte tenu de la puissance de calcul offerte par les GPU). Grâce à la prise en charge de MME pour GPU, vous pouvez déployer des milliers de modèles d'apprentissage en profondeur derrière un point de terminaison SageMaker. Les MME peuvent exécuter plusieurs modèles sur un cœur de GPU, partager des instances de GPU derrière un point de terminaison sur plusieurs modèles et charger et décharger dynamiquement des modèles en fonction du trafic entrant. Avec cela, vous pouvez réduire considérablement les coûts et obtenir les meilleures performances de prix. Si votre cas d'utilisation exige des transactions par seconde (TPS) ou des exigences de latence nettement plus élevées, nous vous recommandons d'héberger les modèles sur des points de terminaison dédiés. |
Cadence de production |
Une valeur idéale du débit d'inférence MME dépend de facteurs tels que le modèle, la taille de la charge utile et le type d'instance de point de terminaison. Une plus grande quantité de mémoire d'instance vous permet d'avoir plus de modèles chargés et prêts à répondre aux demandes d'inférence. Vous n'avez pas besoin de perdre du temps à charger le modèle. Une plus grande quantité de vCPU vous permet d'invoquer plusieurs modèles uniques simultanément. Les MME chargent et déchargent dynamiquement le modèle vers et depuis la mémoire d'instance, ce qui peut avoir un impact sur les performances d'E/S. Les MME SageMaker avec GPU fonctionnent avec Serveur d'inférence NVIDIA Triton, qui est un logiciel de service d'inférence open source qui simplifie le processus de service d'inférence et offre des performances d'inférence élevées. SageMaker charge le modèle dans la mémoire du conteneur NVIDIA Triton sur une instance accélérée par GPU et sert la demande d'inférence. Le cœur du GPU est partagé par tous les modèles d'une instance. Si le modèle est déjà chargé dans la mémoire du conteneur, les requêtes suivantes sont servies plus rapidement car SageMaker n'a pas besoin de le télécharger et de le charger à nouveau. Un test et une analyse des performances appropriés sont recommandés pour des déploiements de production réussis. SageMaker fournit des métriques CloudWatch pour les points de terminaison multimodèles afin que vous puissiez déterminer l'utilisation des points de terminaison et le taux d'accès au cache pour vous aider à optimiser votre point de terminaison. |
Mise à l'échelle de la complexité de la configuration | Les points de terminaison multimodèles SageMaker prennent entièrement en charge la mise à l'échelle automatique, qui gère les répliques de modèles pour garantir que les modèles évoluent en fonction des modèles de trafic. Cependant, un test de charge approprié est recommandé pour déterminer la taille optimale des instances pour la mise à l'échelle automatique du point de terminaison. Il est important de dimensionner correctement la flotte MME pour éviter le déchargement d'un trop grand nombre de modèles. Le chargement de centaines de modèles sur quelques instances plus grandes peut entraîner une limitation dans certains cas, et l'utilisation d'instances plus nombreuses et plus petites peut être préférable. 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. Les taux d'appel utilisés pour déclencher un événement de mise à l'échelle automatique sont basés sur l'ensemble agrégé de prédictions sur l'ensemble complet de modèles servis par le point de terminaison. |
Modèle de trafic | Les MME sont idéales lorsque vous avez un grand nombre de modèles de taille similaire 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. |
Points de terminaison multi-conteneurs SageMaker
SageMaker MCE prend en charge le déploiement de jusqu'à 15 conteneurs qui utilisent différents modèles ou cadres sur un seul point de terminaison, et les appelle indépendamment ou en séquence pour une inférence à faible latence et des économies de coûts. Les modèles peuvent être complètement hétérogènes, avec leur propre pile de service indépendante. L'hébergement sécurisé de plusieurs modèles à partir de différents frameworks sur une seule instance peut vous faire économiser jusqu'à 90 % des coûts.
Les modèles d'appel MCE sont les suivants :
- Pipelines d'inférence – Les conteneurs d'un MME peuvent être appelés dans une séquence linéaire, également appelée pipeline d'inférence série. Ils sont généralement utilisés pour séparer le prétraitement, l'inférence de modèle et le post-traitement dans des conteneurs indépendants. La sortie du conteneur actuel est transmise en entrée au suivant. Ils sont représentés sous la forme d'un modèle de pipeline unique dans SageMaker. Un pipeline d'inférence peut être déployé en tant que MME, où l'un des conteneurs du pipeline peut répondre dynamiquement aux demandes en fonction du modèle invoqué.
- Appel direct - Avec invocation directe, une requête peut être envoyée à un conteneur d'inférence spécifique hébergé sur un MCE.
Le tableau suivant fournit des conseils sur l'évaluation des fonctions de fitness pour les MCE.
Fonction de remise en forme | Description |
Prix | Les MCE vous permettent d'exécuter jusqu'à 15 conteneurs ML différents sur un seul point de terminaison et de les appeler indépendamment, ce qui permet de réduire les coûts. Cette option est idéale lorsque plusieurs modèles s'exécutent sur différentes piles de service avec des besoins en ressources similaires, et lorsque les modèles individuels n'ont pas suffisamment de trafic pour utiliser la pleine capacité des instances de point de terminaison. Les MCE sont donc plus rentables qu'un point final à modèle unique. Les MCE offrent une réponse d'inférence synchrone, ce qui signifie que le point de terminaison est toujours disponible et que vous payez pour la disponibilité de l'instance. Le coût peut s'additionner en fonction du nombre et du type d'instances. |
Latence d'inférence | Les MCE sont idéaux pour exécuter des applications ML avec différents frameworks et algorithmes ML pour chaque modèle auxquels on accède rarement mais qui nécessitent toujours une inférence à faible latence. Les modèles sont toujours disponibles pour l'inférence à faible latence et il n'y a pas de problème de démarrage à froid. |
Cadence de production | Les MCE sont limités à 15 conteneurs maximum sur un point de terminaison multi-conteneurs, et l'inférence GPU n'est pas prise en charge en raison d'un conflit de ressources. Pour les points de terminaison multi-conteneurs utilisant le mode d'appel direct, SageMaker fournit non seulement des métriques au niveau de l'instance comme il le fait avec d'autres points de terminaison courants, mais prend également en charge les métriques par conteneur. Comme bonne pratique, examinez les métriques CloudWatch pour les demandes d'entrée et l'utilisation des ressources, et sélectionnez le type d'instance approprié pour obtenir un débit optimal. |
Mise à l'échelle de la complexité de la configuration | Les MCE prennent en charge la mise à l'échelle automatique. Toutefois, afin de configurer la mise à l'échelle automatique, il est recommandé que le modèle de chaque conteneur présente une utilisation du processeur et une latence similaires à chaque demande d'inférence. Ceci est recommandé car si le trafic vers le point de terminaison multi-conteneurs passe d'un modèle à faible utilisation du processeur à un modèle à utilisation élevée du processeur, mais que le volume d'appels global reste le même, le point de terminaison n'évolue pas et il se peut qu'il n'y ait pas assez d'instances pour gérer toutes les demandes adressées au modèle d'utilisation élevée du processeur. |
Modèle de trafic | Les MCE sont idéaux pour les charges de travail avec des modèles de trafic continus ou réguliers, pour héberger des modèles sur différents frameworks (tels que TensorFlow, PyTorch ou Sklearn) qui peuvent ne pas avoir un trafic suffisant pour saturer la pleine capacité d'une instance de point de terminaison. |
Hébergement d'une application ML basée sur plusieurs modèles
De nombreuses applications métier doivent utiliser plusieurs modèles ML pour servir une seule requête de prédiction à leurs consommateurs. Par exemple, une entreprise de vente au détail qui souhaite fournir des recommandations à ses utilisateurs. L'application ML dans ce cas d'utilisation peut souhaiter utiliser différents modèles personnalisés pour recommander différentes catégories de produits. Si l'entreprise souhaite ajouter une personnalisation aux recommandations en utilisant des informations utilisateur individuelles, le nombre de modèles personnalisés augmente encore. L'hébergement de chaque modèle personnalisé sur une instance de calcul distincte est non seulement coûteux, mais entraîne également une sous-utilisation des ressources d'hébergement si tous les modèles ne sont pas fréquemment utilisés. SageMaker offre des options d'hébergement efficaces pour les applications ML basées sur plusieurs modèles.
Le schéma suivant montre les options d'hébergement multimodèle pour un point de terminaison unique à l'aide de SageMaker.
Pipeline d'inférence en série
Un pipeline d'inférence est un modèle SageMaker composé d'une séquence linéaire de 2 à 15 conteneurs qui traitent les demandes d'inférences sur les données. Vous utilisez un pipeline d'inférence pour définir et déployer n'importe quelle combinaison d'algorithmes intégrés SageMaker pré-entraînés et vos propres algorithmes personnalisés conditionnés dans des conteneurs Docker. Vous pouvez utiliser un pipeline d'inférence pour combiner des tâches de science des données de prétraitement, de prédiction et de post-traitement. La sortie d'un conteneur est transmise en entrée au suivant. Lors de la définition des conteneurs pour un modèle de pipeline, vous spécifiez également l'ordre dans lequel les conteneurs sont exécutés. Ils sont représentés sous la forme d'un modèle de pipeline unique dans SageMaker. Le pipeline d'inférence peut être déployé en tant que MME, où l'un des conteneurs du pipeline peut répondre dynamiquement aux demandes en fonction du modèle invoqué. Vous pouvez également exécuter un transformation par lots travail avec un pipeline d'inférence. Les pipelines d'inférence sont entièrement gérés.
Le tableau suivant fournit des conseils sur l'évaluation des fonctions d'adaptation pour l'hébergement de modèles ML à l'aide d'un pipeline d'inférence en série.
Fonction de remise en forme | Description |
Prix | Le pipeline d'inférence en série vous permet d'exécuter jusqu'à 15 conteneurs ML différents sur un seul point de terminaison, ce qui permet de rentabiliser l'hébergement des conteneurs d'inférence. Il n'y a pas de frais supplémentaires pour l'utilisation de cette fonctionnalité. Vous ne payez que pour les instances exécutées sur un point de terminaison. Le coût peut s'additionner en fonction du nombre et du type d'instances. |
Latence d'inférence | Lorsqu'une application ML est déployée en tant que pipeline d'inférence, les données entre différents modèles ne quittent pas l'espace du conteneur. Le traitement des fonctionnalités et les inférences s'exécutent avec une faible latence, car les conteneurs sont colocalisés sur les mêmes instances EC2. |
Cadence de production | Dans un modèle de pipeline d'inférence, SageMaker gère les appels comme une séquence de requêtes HTTP. Le premier conteneur du pipeline gère la demande initiale, puis la réponse intermédiaire est envoyée sous forme de demande au deuxième conteneur, et ainsi de suite, pour chaque conteneur du pipeline. SageMaker renvoie la réponse finale au client. Le débit dépend de facteurs tels que le modèle, la taille d'entrée du modèle, la taille du lot et le type d'instance de point de terminaison. Comme bonne pratique, passez en revue les métriques CloudWatch pour les demandes d'entrée et l'utilisation des ressources, et sélectionnez le type d'instance approprié pour obtenir un débit optimal. |
Mise à l'échelle de la complexité de la configuration | Les pipelines d'inférence série prennent en charge la mise à l'échelle automatique. Toutefois, afin de configurer la mise à l'échelle automatique, il est recommandé que le modèle de chaque conteneur présente une utilisation du processeur et une latence similaires à chaque demande d'inférence. Ceci est recommandé car si le trafic vers le point de terminaison multi-conteneurs passe d'un modèle à faible utilisation du processeur à un modèle à utilisation élevée du processeur, mais que le volume d'appels global reste le même, le point de terminaison n'évolue pas et il se peut qu'il n'y ait pas assez d'instances pour gérer toutes les demandes adressées au modèle d'utilisation élevée du processeur. |
Modèle de trafic |
Les pipelines d'inférence série sont idéaux pour les modèles de trafic prévisibles avec des modèles qui s'exécutent de manière séquentielle sur le même point de terminaison. |
Déploiement d'ensembles de modèles (Triton DAG) :
SageMaker offre une intégration avec Serveur d'inférence NVIDIA Triton à travers Conteneurs de serveur d'inférence Triton. Ces conteneurs incluent NVIDIA Triton Inference Server, la prise en charge des frameworks ML courants et des variables d'environnement utiles qui vous permettent d'optimiser les performances sur SageMaker. Avec les images de conteneur NVIDIA Triton, vous pouvez facilement servir des modèles ML et bénéficier des optimisations de performances, du traitement par lots dynamique et de la prise en charge multi-framework fournies par NVIDIA Triton. Triton aide à maximiser l'utilisation du GPU et du CPU, réduisant encore le coût de l'inférence.
Dans les cas d'utilisation professionnelle où les applications ML utilisent plusieurs modèles pour répondre à une demande de prédiction, si chaque modèle utilise un framework différent ou est hébergé sur une instance distincte, cela peut entraîner une augmentation de la charge de travail et des coûts, ainsi qu'une augmentation de la latence globale. SageMaker NVIDIA Triton Inference Server prend en charge le déploiement de modèles à partir de tous les principaux frameworks, tels que TensorFlow GraphDef, TensorFlow SavedModel, ONNX, PyTorch TorchScript, TensorRT et les formats de modèle Python/C++, etc. L'ensemble de modèles Triton représente un pipeline d'un ou plusieurs modèles ou une logique de prétraitement et de post-traitement, et la connexion des tenseurs d'entrée et de sortie entre eux. Une seule demande d'inférence à un ensemble déclenche l'exécution de l'ensemble du pipeline. Triton dispose également de plusieurs algorithmes de planification et de traitement par lots intégrés qui combinent des demandes d'inférence individuelles pour améliorer le débit d'inférence. Ces décisions de planification et de regroupement sont transparentes pour le client qui demande l'inférence. Les modèles peuvent être exécutés sur des CPU ou des GPU pour une flexibilité maximale et pour prendre en charge des exigences informatiques hétérogènes.
L'hébergement de plusieurs modèles basés sur GPU sur des points de terminaison multimodèles est pris en charge via le Serveur d'inférence SageMaker Triton. Le serveur d'inférence NVIDIA Triton a été étendu pour implémenter un Contrat API MME, à intégrer aux MME. Vous pouvez utiliser le serveur d'inférence NVIDIA Triton, qui crée une configuration de référentiel modèle pour différents backends de framework, pour déployer un MME avec mise à l'échelle automatique. Cette fonctionnalité vous permet de mettre à l'échelle des centaines de modèles hyper-personnalisés qui sont affinés pour répondre aux expériences uniques des utilisateurs finaux dans les applications d'IA. Vous pouvez également utiliser cette fonctionnalité pour obtenir les performances de prix nécessaires pour votre application d'inférence à l'aide de GPU fractionnaires. Pour en savoir plus, consultez Exécutez plusieurs modèles d'apprentissage en profondeur sur GPU avec les points de terminaison multimodèles d'Amazon SageMaker.
Le tableau suivant fournit des conseils sur l'évaluation des fonctions de remise en forme pour l'hébergement de modèles ML à l'aide de MME avec prise en charge GPU sur les conteneurs d'inférence Triton. Pour les points de terminaison à modèle unique et les évaluations de la fonction de remise en forme des points de terminaison sans serveur, reportez-vous aux sections précédentes de cet article.
Fonction de remise en forme | Description |
Prix | Les MME SageMaker avec prise en charge GPU utilisant Triton Inference Server offrent un moyen évolutif et rentable de déployer un grand nombre de modèles d'apprentissage en profondeur derrière un point de terminaison SageMaker. Avec les MME, plusieurs modèles partagent l'instance GPU derrière un point de terminaison. Cela vous permet de réduire l'augmentation linéaire des coûts d'hébergement de plusieurs modèles et de réutiliser l'infrastructure sur tous les modèles. Vous payez pour la disponibilité de l'instance. |
Latence d'inférence |
SageMaker avec Triton Inference Server est spécialement conçu pour maximiser le débit et l'utilisation du matériel avec une latence d'inférence ultra-faible (millisecondes à un chiffre). Il dispose d'une large gamme de frameworks ML pris en charge (y compris TensorFlow, PyTorch, ONNX, XGBoost et NVIDIA TensorRT) et de backends d'infrastructure, y compris les GPU NVIDIA, les CPU et Inférence AWS. Avec la prise en charge de MME pour GPU à l'aide de SageMaker Triton Inference Server, vous pouvez déployer des milliers de modèles d'apprentissage en profondeur derrière un point de terminaison SageMaker. SageMaker charge le modèle dans la mémoire du conteneur NVIDIA Triton sur une instance accélérée par GPU et sert la demande d'inférence. Le cœur du GPU est partagé par tous les modèles d'une instance. Si le modèle est déjà chargé dans la mémoire du conteneur, les requêtes suivantes sont servies plus rapidement car SageMaker n'a pas besoin de le télécharger et de le charger à nouveau. |
Cadence de production |
Les MME offrent des capacités pour exécuter plusieurs modèles d'apprentissage en profondeur ou ML sur le GPU, en même temps, avec Triton Inference Server. Cela vous permet d'utiliser facilement le service d'inférence hautes performances multi-framework NVIDIA Triton avec le déploiement de modèle entièrement géré SageMaker. Triton prend en charge toutes les inférences basées sur NVIDIA GPU, x86, Arm® CPU et AWS Inferentia. Il offre un traitement par lots dynamique, des exécutions simultanées, une configuration de modèle optimale, un ensemble de modèles et des entrées audio et vidéo en continu pour optimiser le débit et l'utilisation. D'autres facteurs tels que le réseau et la taille de la charge utile peuvent jouer un rôle minime dans la surcharge associée à l'inférence. |
Mise à l'échelle de la complexité de la configuration |
Les MME peuvent évoluer horizontalement à l'aide d'une stratégie de mise à l'échelle automatique et provisionner des instances de calcul GPU supplémentaires en fonction de métriques telles que Avec le serveur d'inférence Triton, vous pouvez facilement créer un conteneur personnalisé qui inclut votre modèle avec Triton et l'apporter à SageMaker. SageMaker Inference traitera les demandes et dimensionnera automatiquement le conteneur à mesure que l'utilisation augmente, ce qui facilitera le déploiement du modèle avec Triton sur AWS. |
Modèle de trafic |
Les MME sont idéales pour les modèles de trafic prévisibles avec des modèles exécutés en tant que DAG sur le même point de terminaison. SageMaker s'occupe de la mise en forme du trafic vers le point de terminaison MME et maintient des copies de modèles optimales sur les instances GPU pour des performances tarifaires optimales. Il continue d'acheminer le trafic vers l'instance où le modèle est chargé. Si les ressources de l'instance atteignent leur capacité en raison d'une utilisation élevée, SageMaker décharge les modèles les moins utilisés du conteneur afin de libérer des ressources pour charger les modèles les plus fréquemment utilisés. |
des pratiques d’excellence;
Tenez compte des bonnes pratiques suivantes :
- Cohésion élevée et faible couplage entre les modèles – Hébergez les modèles dans le même conteneur qui présente une cohésion élevée (fonctionnalité d'entreprise unique) et encapsulez-les ensemble pour faciliter la mise à niveau et la gérabilité. Dans le même temps, découplez ces modèles les uns des autres (hébergez-les dans un conteneur différent) afin de pouvoir facilement mettre à niveau un modèle sans affecter les autres modèles. Hébergez plusieurs modèles qui utilisent différents conteneurs derrière un point de terminaison et invoquez-les indépendamment ou ajoutez une logique de prétraitement et de post-traitement du modèle en tant que pipeline d'inférence en série.
- Latence d'inférence – Regroupez les modèles qui sont axés sur les fonctionnalités d'une seule entreprise et hébergez-les dans un conteneur unique pour minimiser le nombre de sauts et donc minimiser la latence globale. Il y a d'autres mises en garde, comme si les modèles groupés utilisent plusieurs frameworks ; vous pouvez également choisir d'héberger dans plusieurs conteneurs mais exécuter sur le même hôte pour réduire la latence et minimiser les coûts.
- Regrouper logiquement les modèles ML avec une forte cohésion – Le groupe logique peut être constitué de modèles homogènes (par exemple, tous les modèles XGBoost) ou hétérogènes (par exemple, quelques XGBoost et quelques BERT). Il peut s'agir de modèles partagés entre plusieurs fonctionnalités métier ou être spécifiques à la réalisation d'une seule fonctionnalité métier.
- Modèles partagés – Si le groupe logique se compose de modèles partagés, la facilité de mise à niveau des modèles et la latence joueront un rôle majeur dans l'architecture des terminaux SageMaker. Par exemple, si la latence est une priorité, il est préférable de placer tous les modèles dans un seul conteneur derrière un seul point de terminaison SageMaker pour éviter plusieurs sauts. L'inconvénient est que si l'un des modèles doit être mis à niveau, cela entraînera la mise à niveau de tous les points de terminaison SageMaker pertinents hébergeant ce modèle.
- Modèles non partagés – Si le groupe logique se compose uniquement de modèles spécifiques aux fonctionnalités métier et n'est pas partagé avec d'autres groupes, la complexité de l'empaquetage et les dimensions de latence deviendront essentielles à atteindre. Il est conseillé d'héberger ces modèles dans un seul conteneur derrière un seul point de terminaison SageMaker.
- Utilisation efficace du matériel (CPU, GPU) – Regroupez les modèles basés sur CPU et hébergez-les sur le même hôte afin que vous puissiez utiliser efficacement le CPU. De même, regroupez les modèles basés sur GPU afin de pouvoir les utiliser et les mettre à l'échelle efficacement. Certaines charges de travail hybrides nécessitent à la fois un CPU et un GPU sur le même hôte. L'hébergement des modèles CPU uniquement et GPU uniquement sur le même hôte doit être motivé par des exigences élevées en matière de cohésion et de latence des applications. De plus, le coût, la capacité d'évolutivité et le rayon de souffle lors de l'impact en cas de défaillance sont les dimensions clés à examiner.
- Fonctions de remise en forme – Utilisez les fonctions de mise en forme comme guide pour sélectionner une option d'hébergement ML.
Conclusion
En ce qui concerne l'hébergement ML, il n'y a pas d'approche unique. Les praticiens ML doivent choisir le bon modèle de conception pour relever leurs défis d'hébergement ML. L'évaluation des fonctions de fitness fournit des conseils normatifs sur la sélection de la bonne option d'hébergement ML.
Pour plus de détails sur chacune des options d'hébergement, reportez-vous aux articles suivants de cette série :
À propos des auteurs
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.
Deepali Rajale est responsable de compte technique spécialiste AI/ML chez Amazon Web Services. Elle travaille avec des entreprises clientes en fournissant des conseils techniques sur la mise en œuvre de solutions d'apprentissage automatique avec les meilleures pratiques. Dans ses temps libres, elle aime faire de la randonnée, aller au cinéma et sortir avec sa famille et ses amis.
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.
- Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
- Platoblockchain. Intelligence métaverse Web3. Connaissance Amplifiée. Accéder ici.
- La source: https://aws.amazon.com/blogs/machine-learning/model-hosting-patterns-in-amazon-sagemaker-part-1-common-design-patterns-for-building-ml-applications-on-amazon-sagemaker/
- 1
- 10
- 100
- 11
- 39
- 7
- 70
- a
- capacité
- Capable
- Qui sommes-nous
- accéléré
- accès
- accédé
- accessible
- accommoder
- Compte
- Avec cette connaissance vient le pouvoir de prendre
- atteindre
- la réalisation de
- à travers
- Action
- activement
- ajout
- Supplémentaire
- En outre
- propos
- avancer
- Avancée
- Avantage
- Numérique
- affecter
- Après
- agrégation
- Aggregator
- agressif
- accords
- AI
- AI / ML
- alarme
- algorithmes
- Tous
- Permettre
- permet
- déjà
- toujours
- Amazon
- Amazon EC2
- Amazon Sage Maker
- Amazon Web Services
- montant
- selon une analyse de l’Université de Princeton
- il analyse
- ainsi que
- et infrastructure
- annuel
- Une autre
- Apache
- api
- Apple
- Application
- applications
- une approche
- approprié
- applications
- architecture
- BRAS
- artificiel
- intelligence artificielle
- aspects
- Évaluation de risque climatique
- associé
- attributs
- acoustique
- audits
- auto
- Automatisation
- Automatique
- automatiquement
- disponibilité
- disponibles
- moyen
- AWS
- RETOUR
- soutenu
- Services bancaires
- base
- basé
- car
- devenez
- devient
- before
- derrière
- va
- profiter
- LES MEILLEURS
- les meilleures pratiques
- Améliorée
- jusqu'à XNUMX fois
- biomédical
- Block
- Emprunt
- frontières
- Box
- violation
- Pause
- apporter
- Apporte
- budgets
- construire
- Développement
- construit
- intégré
- la performance des entreprises
- applications commerciales
- PROCESSUS D'AFFAIRE
- entreprises
- Cache
- calculé
- Appelez-nous
- appelé
- demandeur
- candidats
- capacités
- Compétences
- les soins
- maisons
- cas
- catégories
- les causes
- certaines
- Support et maintenance de Salesforce
- globaux
- Change
- Modifications
- caractéristiques
- accusé
- Chatbot
- vérifier
- puce
- le choix
- choix
- Selectionnez
- choose
- classe
- classification
- Classer
- client
- CLIENTS
- Fermer
- le cloud
- Grappe
- code
- inventé
- collègues
- recueillir
- lutter contre la
- combinaison
- combiner
- combiné
- Commun
- Sociétés
- Société
- par rapport
- complet
- complètement
- complexe
- complexité
- conformité
- composants électriques
- composé
- compromis
- puissance de calcul
- calcul
- ordinateur
- Vision par ordinateur
- informatique
- concept
- PROBLÈMES DE PEAU
- concurrent
- configuration
- connexion
- cohérent
- consommées
- Les consommateurs
- Contenant
- Conteneurs
- contient
- continuer
- continue
- continu
- des bactéries
- Core
- Correspondant
- Prix
- les économies de coûts
- rentable
- Costs
- pourriez
- engendrent
- crée des
- critique
- crucial
- Courant
- Customiser
- des clients
- Clients
- JOUR
- données
- informatique
- science des données
- Data Scientist
- Base de données
- ensembles de données
- journée
- traitement
- décisions
- dévoué
- profond
- l'apprentissage en profondeur
- Réglage par défaut
- définir
- livrer
- Demande
- demandes
- Démocratiser
- Selon
- dépend
- déployer
- déployé
- déployer
- déploiement
- déploiements
- Conception
- modèles de conception
- un
- détail
- détails
- Détection
- Déterminer
- Développeur
- Développement
- diagrammes
- différent
- difficile
- dimensions
- distinct
- distribué
- informatique distribuée
- plusieurs
- Docker
- INSTITUTIONNELS
- Ne fait pas
- domaines
- Ne pas
- down
- download
- inconvénient
- entraîné
- chuté
- Goutte
- pendant
- Dynamic
- chacun
- Plus tôt
- plus facilement
- même
- Efficace
- de manière efficace
- efficacité
- efficacité
- efficace
- efficacement
- effort
- non plus
- l'élimination
- permettre
- permet
- chiffrement
- end-to-end
- Endpoint
- ENGINEERING
- Les ingénieurs
- assez
- assurer
- Assure
- Entreprise
- entreprises
- Tout
- Environment
- erreur
- Erreurs
- notamment
- évalué
- évaluations
- Pourtant, la
- événement
- peut
- évolution
- exemple
- exemples
- échange
- expositions
- attendre
- attendu
- Découvrez
- Expériences
- explorez
- expressions
- externe
- supplémentaire
- Visage
- facteurs
- Échec
- équitablement
- familles
- famille
- plus rapide
- Fonctionnalité
- Fonctionnalités:
- alimentation
- few
- finale
- Prénom
- première fois
- de l'aptitude
- FLOTTE
- Flexibilité
- flux
- fluctuer
- se concentre
- Abonnement
- suit
- Ford
- formulaire
- document
- fractionnaire
- Framework
- cadres
- fraude
- détection de fraude
- Test d'anglais
- La fréquence
- fréquemment
- amis
- de
- Fruitée
- plein
- d’étiquettes électroniques entièrement
- fonction
- fonctionnalités
- fonctions
- plus
- RGPD
- Général
- généré
- générateur
- obtenez
- Donner
- donné
- objectif
- Objectifs
- Bien
- GPU
- GPU
- graphique
- l'
- plus grand
- considérablement
- Réservation de groupe
- Groupes
- Croître
- guide
- manipuler
- Poignées
- pratique
- Matériel
- ayant
- Santé
- la médecine
- aider
- aider
- aide
- ici
- Haute
- haute performance
- haute résolution
- augmentation
- Frappé
- Horizontal
- hôte
- organisé
- hébergement
- frais d'hébergement
- services d'hébergement
- Comment
- Cependant
- HTML
- HTTPS
- Des centaines
- Hybride
- idéal
- Active
- Idle
- image
- Classification des images
- satellite
- immuable
- Impact
- impact
- Impacts
- Mettre en oeuvre
- mis en œuvre
- la mise en œuvre
- important
- améliorer
- l'amélioration de
- in
- comprendre
- inclut
- Y compris
- Nouveau
- Améliore
- increased
- Augmente
- croissant
- indépendant
- indépendamment
- individuel
- d'information
- Infrastructure
- initiale
- technologie innovante
- technologies innovantes
- contribution
- installer
- instance
- plutôt ;
- intégrer
- l'intégration
- Intelligence
- Interactif
- impliquer
- ISO
- seul
- IT
- Emploi
- Emplois
- ACTIVITES
- clés
- Savoir
- connu
- gros
- plus importantes
- Latence
- lancer
- lance
- lancement
- conduire
- conduisant
- Conduit
- APPRENTISSAGE
- apprentissage
- Laisser
- LED
- Niveau
- bibliothèques
- lifting
- limité
- limites
- Liste
- le travail
- charge
- chargement
- charges
- emplacement
- Location
- plus long
- Style
- pas à perdre
- Lot
- Faible
- click
- machine learning
- LES PLANTES
- Entrée
- maintenir
- maintient
- majeur
- faire
- FAIT DU
- Fabrication
- gérer
- gérés
- gestion
- manager
- gère
- les gérer
- de nombreuses
- Stratégie
- mathématique
- Matière
- Maximisez
- maximales
- veux dire
- Découvrez
- Mémoire
- méthode
- méthodes
- métrique
- Métrique
- pourrait
- minimal
- minimum
- Minutes
- Mixage audio
- ML
- Mode
- modèle
- numériques jumeaux (digital twin models)
- Surveiller
- Stack monitoring
- Mois
- mois
- PLUS
- (en fait, presque toutes)
- motivés
- Films
- Point de terminaison multimodèle
- plusieurs
- multitude
- Nature
- nécessaire
- Besoin
- Besoins
- réseau et
- Nouveauté
- next
- nlp
- déclaration
- Notifications
- nombre
- Nvidia
- objet
- objectif
- objectifs
- obtention
- occasionnel
- code
- Offres Speciales
- direct
- ONE
- en ligne
- open source
- fonctionner
- exploite
- d'exploitation
- opérationnel
- Opérations
- opérateurs
- optimaux
- à mettre en œuvre pour gérer une entreprise rentable. Ce guide est basé sur trois décennies d'expérience
- Optimiser
- optimisé
- Optimise
- l'optimisation
- Option
- Options
- Orange
- de commander
- organisations
- Autre
- exceptionnel
- global
- propre
- possession
- paquet
- l'emballage
- paramètres
- partie
- particulier
- les partenaires
- passé
- passionné
- Patches
- Patron de Couture
- motifs
- Payer
- Courant
- Effectuer
- performant
- effectuer
- période
- périodique
- périodes
- Personnalisation
- Personnalisé
- en particulier pendant la préparation
- pipeline
- Place
- Des endroits
- prévu
- plans
- plateforme
- Plateformes
- Platon
- Intelligence des données Platon
- PlatonDonnées
- Jouez
- plus
- politiques
- politique
- Populaire
- possible
- Post
- Poteaux
- power
- pratique
- pratiques
- Prévisible
- prévoir
- prédiction
- Prédictions
- préféré
- précédemment
- prix
- Directeur
- priorité
- Privé
- Problème
- d'ouvrabilité
- processus
- Traité
- les process
- traitement
- processeurs
- Produit
- chef de produit
- Vidéo
- Produits
- Profil
- correct
- fournir
- à condition de
- fournit
- aportando
- disposition
- procuration
- but
- Push
- pytorch
- vite.
- gamme
- allant
- rapidement
- Tarif
- Tarifs
- nous joindre
- atteint
- Lire
- solutions
- réal
- monde réel
- en temps réel
- recevoir
- reçu
- reçoit
- recommander
- Recommandation
- recommandations
- recommandé
- recommander
- recommande
- récurrent
- réduire
- réduit
- se réfère
- Indépendamment
- Standard
- en relation
- de Presse
- pertinent
- reste
- dépôt
- représenté
- représente
- nécessaire
- demandes
- exigent
- conditions
- exigence
- Exigences
- a besoin
- ressource
- Ressources
- réponse
- REST
- résultat
- résultant
- Résultats
- détail
- Retours
- Avis
- Analyse
- Rôle
- racine
- Itinéraire
- Règle
- Courir
- pour le running
- SaaS.
- sagemaker
- Inférence SageMaker
- salaire
- même
- Épargnez
- économie
- Épargnes
- évolutive
- Escaliers intérieurs
- Balance
- mise à l'échelle
- scénarios
- calendrier
- prévu
- Sciences
- Scientifique
- Deuxièmement
- secondes
- Section
- les sections
- en toute sécurité
- sécurité
- la sélection
- sélection
- supérieur
- sensible
- Séquence
- en série
- Série
- besoin
- Sans serveur
- Serveurs
- sert
- service
- Services
- service
- set
- mise
- plusieurs
- mise en forme
- Partager
- commun
- Changements
- devrait
- Spectacles
- significative
- de façon significative
- similaires
- De même
- étapes
- unique
- Taille
- tailles
- petit
- faibles
- So
- Logiciels
- sur mesure
- Solutions
- quelques
- Sources
- Space
- spécialiste
- spécialisé
- groupe de neurones
- spécifiquement
- spécifié
- vitesse
- Dépenses
- pointes
- stable
- empiler
- Combos
- Commencer
- j'ai commencé
- départs
- Commencez
- Startups
- stable
- étapes
- Étapes
- Encore
- Arrête
- storage
- Boutique
- les stratégies
- streaming
- Strict
- fortement
- ultérieur
- succès
- réussi
- tel
- suffisant
- convient
- Support
- Appareils
- Les soutiens
- se pose
- table
- Prenez
- prend
- Target
- des campagnes marketing ciblées,
- Tâche
- tâches
- équipe
- équipes
- TechCrunch
- Technique
- Les technologies
- locataire
- tensorflow
- tester
- Essais
- Les
- leur
- se
- ainsi
- donc
- milliers
- trois
- порог
- Avec
- tout au long de
- débit
- fiable
- fois
- à
- ensemble
- trop
- outil
- Total
- tps
- Tracking
- circulation
- Train
- qualifié
- Formation
- transactionnel
- Transactions
- Transformer
- De La Carrosserie
- transformer
- transit
- communication
- déclencher
- Triton
- TOUR
- types
- débutante
- typiquement
- sous
- sous-jacent
- comprendre
- unique
- unités
- imprévisible
- inutilisé
- Mises à jour
- Actualités
- améliorer
- mis à jour
- Stabilité
- Utilisation
- utilisé
- cas d'utilisation
- Utilisateur
- utilisateurs
- d'habitude
- utiliser
- utilisé
- VALIDER
- Plus-value
- Valeurs
- Variante
- divers
- via
- Vidéo
- Vidéos
- Voir
- Salle de conférence virtuelle
- vision
- le volume
- Vote
- votes
- Déchets
- web
- services Web
- semaine
- Quoi
- Qu’est ce qu'
- qui
- tout en
- large
- Large gamme
- sera
- dans les
- sans
- Activités principales
- travaillé
- travailleur
- ouvriers
- de travail
- vos contrats
- world
- pourra
- XGBoost
- an
- Vous
- Votre
- zéphyrnet
- zéro