Obtenez un hébergement à faible latence pour les modèles ML basés sur un arbre de décision sur le serveur d'inférence NVIDIA Triton sur Amazon SageMaker

Les déploiements de modèles d'apprentissage automatique (ML) peuvent avoir des exigences de performances et de latence très exigeantes pour les entreprises d'aujourd'hui. Les cas d'utilisation tels que la détection de fraude et le placement d'annonces 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, la logique de sélection de modèle, l'agrégation de modèles et le post-traitement. À grande échelle, cela signifie souvent maintenir un énorme volume de trafic tout en maintenant une faible latence. Les modèles de conception courants incluent les pipelines d'inférence en série, les ensembles (scatter-gather) et les workflows de logique métier, qui permettent de réaliser l'intégralité du workflow de la demande sous la forme d'un graphe acyclique dirigé (DAG). Cependant, à mesure que les flux de travail deviennent plus complexes, cela peut entraîner une augmentation des temps de réponse globaux, ce qui peut avoir un impact négatif sur l'expérience de l'utilisateur final et compromettre les objectifs commerciaux. Triton peut répondre à ces cas d'utilisation où plusieurs modèles sont composés dans un pipeline avec des tenseurs d'entrée et de sortie connectés entre eux, vous aidant à gérer ces charges de travail.

Lorsque vous évaluez vos objectifs par rapport à l'inférence de modèle ML, de nombreuses options peuvent être envisagées, mais peu sont aussi capables et éprouvées que Amazon Sage Maker comprenant Serveur d'inférence Triton. SageMaker avec Triton Inference Server a été un choix populaire pour de nombreux clients, car il 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. De plus, Triton Inference Server est intégré à SageMaker, un service ML de bout en bout entièrement géré, offrant des options d'inférence en temps réel pour l'hébergement de modèles.

Dans cet article, nous passons en revue le déploiement d'une charge de travail d'ensemble de détection de fraude sur SageMaker avec Triton Inference Server.

Vue d'ensemble de la solution

Il est essentiel pour tout projet d'avoir une liste d'exigences et une estimation de l'effort, afin d'estimer le coût total du projet. Il est important d'estimer le retour sur investissement (ROI) qui soutient la décision d'une organisation. Voici quelques considérations à prendre en compte lors du déplacement d'une charge de travail vers Triton :

L'estimation de l'effort est essentielle dans le développement de logiciels, et sa mesure est souvent basée sur des entrées incomplètes, incertaines et bruyantes. Les charges de travail ML ne sont pas différentes. Plusieurs facteurs affecteront une architecture pour l'inférence ML, dont certains comprennent:

• Budget de latence côté client – Il spécifie le temps d'attente maximal acceptable aller-retour côté client pour une réponse d'inférence, généralement exprimé en centiles. Pour les charges de travail qui nécessitent un budget de latence proche de quelques dizaines de millisecondes, les transferts réseau peuvent devenir coûteux, donc l'utilisation de modèles à la périphérie serait mieux adaptée.
• Taille de distribution de la charge utile des données – Charge utile, souvent appelée Corps du message, sont les données de requête transmises du client au modèle, ainsi que les données de réponse transmises du modèle au client. La taille de la charge utile a souvent un impact majeur sur la latence et doit être prise en considération.
• Format de données – Cela spécifie comment la charge utile est envoyée au modèle ML. Le format peut être lisible par l'homme, comme JSON et CSV, mais il existe également des formats binaires, qui sont souvent compressés et de plus petite taille. Il s'agit d'un compromis entre la surcharge de compression et la taille de transfert, ce qui signifie que les cycles et la latence du processeur sont ajoutés pour compresser ou décompresser, afin d'économiser les octets transférés sur le réseau. Cet article montre comment utiliser à la fois les formats JSON et binaires.
• Pile logicielle et composants requis – Une pile est un ensemble de composants qui fonctionnent ensemble pour prendre en charge une application ML, y compris le système d'exploitation, les runtimes et les couches logicielles. Triton est livré avec des frameworks ML populaires intégrés, appelés backends, tels que ONNX, TensorFlow, FIL, OpenVINO, Python natif et autres. Vous pouvez également créer un back-end personnalisé pour vos propres composants maison. Cet article passe en revue un modèle XGBoost et le prétraitement des données, que nous migrons respectivement vers les backends FIL et Python Triton fournis par NVIDIA.

Tous ces facteurs devraient jouer un rôle essentiel dans l'évaluation des performances de vos charges de travail, mais dans ce cas d'utilisation, nous nous concentrons sur le travail nécessaire pour déplacer vos modèles ML afin qu'ils soient hébergés dans SageMaker avec Triton Inference Server. Plus précisément, nous utilisons un exemple d'ensemble de détection de fraude composé d'un modèle XGBoost avec une logique de prétraitement écrite en Python.

Serveur d'inférence NVIDIA Triton

Triton Inference Server a été conçu dès le départ pour permettre aux équipes de déployer, d'exécuter et de mettre à l'échelle des modèles d'IA entraînés à partir de n'importe quel framework sur une infrastructure basée sur GPU ou CPU. En outre, il a été optimisé pour offrir une inférence hautes performances à grande échelle avec des fonctionnalités telles que le traitement par lots dynamique, les exécutions simultanées, la configuration optimale du modèle, l'ensemble de modèles et la prise en charge des entrées en continu.

Le schéma suivant montre un exemple de pipeline d'ensemble NVIDIA Triton.

Les charges de travail doivent prendre en compte les fonctionnalités fournies par Triton avec l'hébergement SageMaker afin de maximiser les avantages offerts. Par exemple, Triton prend en charge HTTP ainsi qu'un API C, qui permettent une flexibilité ainsi qu'une optimisation de la charge utile en cas de besoin. Comme mentionné précédemment, Triton prend en charge plusieurs frameworks populaires prêts à l'emploi, notamment TensorFlow, PyTorch, ONNX, XGBoost et NVIDIA TensorRT. Ces frameworks sont pris en charge par les backends Triton, et dans les rares cas où un backend ne prendrait pas en charge votre cas d'utilisation, Triton vous permet d'implémenter le vôtre et de l'intégrer facilement.

Le diagramme suivant montre un exemple de l'architecture NVIDIA Triton.

NVIDIA Triton sur SageMaker

Hébergement SageMaker Les services sont l'ensemble des fonctionnalités de SageMaker visant à faciliter le déploiement et le service des modèles. Il fournit une variété d'options pour déployer, mettre à l'échelle automatiquement, surveiller et optimiser facilement des modèles ML adaptés à différents cas d'utilisation. Cela signifie que vous pouvez optimiser vos déploiements pour tous les types de modèles d'utilisation, des besoins persistants et toujours disponibles avec des options sans serveur aux besoins transitoires, de longue durée ou d'inférence par lots.

Sous l'égide de l'hébergement SageMaker se trouve également l'ensemble des conteneurs d'apprentissage en profondeur (DLC) d'inférence SageMaker, qui sont préemballés avec le logiciel de serveur de modèle approprié pour leur cadre ML pris en charge correspondant. Cela vous permet d'obtenir des performances d'inférence élevées sans configuration de serveur de modèle, ce qui est souvent l'aspect technique le plus complexe du déploiement de modèle et ne fait généralement pas partie des compétences d'un data scientist. Le serveur d'inférence Triton est maintenant disponibles sur les DLC SageMaker.

Cette étendue d'options, la modularité et la facilité d'utilisation des différents frameworks de service font de SageMaker et de Triton une combinaison puissante.

Prise en charge du back-end NVIDIA FIL

Avec la Version 22.05 de Triton, NVIDIA prend désormais en charge les modèles de forêt entraînés par plusieurs frameworks ML populaires, notamment XGBoost, LightGBM, Scikit-learn et cuML. Lorsque vous utilisez le backend FIL pour Triton, vous devez vous assurer que les artefacts de modèle que vous fournissez sont pris en charge. Par exemple, FIL prend en charge model_type xgboost, xgboost_json, lightgbmou treelite_checkpoint, indiquant si le modèle fourni est au format binaire XGBoost, au format JSON XGBoost, au format texte LightGBM ou au format binaire Treelite, respectivement.

Ce support backend est essentiel pour nous dans notre exemple car FIL prend en charge les modèles XGBoost. La seule considération à vérifier est de s'assurer que le modèle que nous déployons prend en charge les formats binaires ou JSON.

En plus de vous assurer que vous disposez du format de modèle approprié, d'autres considérations doivent être prises en compte. Le backend FIL pour Triton fournit des options configurables aux développeurs pour régler leurs charges de travail et optimiser les performances d'exécution du modèle. La configuration dynamic_batching permet à Triton de conserver les requêtes côté client et de les regrouper côté serveur, afin d'utiliser efficacement le calcul parallèle de FIL pour déduire l'ensemble du lot. L'option max_queue_delay_microseconds offre un contrôle à sécurité intégrée du temps d'attente de Triton pour former un lot. FIL est livré avec l'explicateur Shapley, qui peut être activé par la configuration treeshap_output; cependant, vous devez garder à l'esprit que les sorties Shapley nuisent aux performances en raison de leur taille de sortie. Un autre aspect important est storage_type afin de trouver un compromis entre l'empreinte mémoire et le temps d'exécution. Par exemple, l'utilisation du stockage en tant que SPARSE peut réduire la consommation de mémoire, tandis que DENSE peut réduire les performances d'exécution de votre modèle au détriment d'une utilisation de mémoire plus élevée. Le choix du meilleur choix pour chacun d'entre eux dépend de votre charge de travail et de votre budget de latence. Nous vous recommandons donc d'examiner de plus près toutes les options du FAQ sur le back-end FIL et par liste des configurations disponibles dans FIL.

Étapes pour héberger un modèle sur triton

Examinons notre cas d'utilisation de détection de fraude comme exemple de ce qu'il faut prendre en compte lors du déplacement d'une charge de travail vers Triton.

Identifiez votre charge de travail

Dans ce cas d'utilisation, nous avons un modèle de détection de fraude utilisé lors du processus de paiement d'un client de détail. Le pipeline d'inférence utilise un algorithme XGBoost avec une logique de prétraitement qui inclut la préparation des données pour le prétraitement.

Identifier les mesures de performance actuelles et cibles et les autres objectifs qui peuvent s'appliquer

Vous constaterez peut-être que votre temps d'inférence de bout en bout prend trop de temps pour être acceptable. Votre objectif pourrait être de passer de dizaines de millisecondes de latence à une latence à un chiffre pour le même volume de requêtes et le même débit respectif. Vous déterminez que la majeure partie du temps est consommée par le prétraitement des données et le modèle XGBoost. D'autres facteurs tels que le réseau et la taille de la charge utile jouent un rôle minime dans la surcharge associée au temps d'inférence de bout en bout.

Travaillez en arrière pour déterminer si Triton peut héberger votre charge de travail en fonction de vos besoins

Pour déterminer si Triton peut répondre à vos besoins, vous devez prêter attention à deux principaux domaines de préoccupation. La première consiste à s'assurer que Triton peut servir avec une option frontale acceptable telle que HTTP ou C API.

Comme mentionné précédemment, il est également essentiel de déterminer si Triton prend en charge un backend pouvant servir vos artefacts. Triton prend en charge un certain nombre de backends qui sont conçus sur mesure pour prendre en charge divers frameworks tels que PyTorch et TensorFlow. Vérifiez que vos modèles sont pris en charge et que vous disposez du format de modèle approprié attendu par Triton. Pour ce faire, vérifiez d'abord quels formats de modèle sont pris en charge par le backend Triton. Dans de nombreux cas, cela ne nécessite aucune modification du modèle. Dans d'autres cas, votre modèle peut nécessiter une transformation vers un format différent. Selon le format source et cible, diverses options existent, telles que la transformation d'un Fichier de pickle Python pour utiliser le format de point de contrôle binaire de Treelite.

Pour ce cas d'utilisation, nous déterminons Serveur FIL peut prendre en charge le modèle XGBoost sans modifications nécessaires et que nous pouvons utiliser le Back-end Python pour le prétraitement. Avec la fonctionnalité d'ensemble de Triton, vous pouvez optimiser davantage votre charge de travail en évitant les appels réseau coûteux entre les instances d'hébergement.

Créez un plan et estimez l'effort requis pour utiliser Triton pour l'hébergement

Parlons du plan pour déplacer vos modèles vers Triton. Chaque déploiement Triton nécessite les éléments suivants :

• Artefacts de modèle requis par les backends Triton
• Fichiers de configuration Triton
• Un dossier de référentiel modèle avec la structure appropriée

Nous montrons un exemple de la façon de créer ces dépendances de déploiement plus loin dans ce post.

Exécuter le plan et valider les résultats

Après avoir créé les fichiers et les artefacts requis dans le référentiel de modèles correctement structuré, vous devez ajuster votre déploiement et le tester pour vérifier que vous avez maintenant atteint vos métriques cibles.

À ce stade, vous pouvez utiliser Recommandateur d'inférence SageMaker pour déterminer le type d'instance de point de terminaison qui vous convient le mieux en fonction de vos besoins. De plus, Triton fournit des outils pour optimiser les builds afin d'obtenir de meilleures performances.

Implémentation

Voyons maintenant les détails de mise en œuvre. Pour cela, nous avons préparé deux cahiers qui donnent un exemple de ce à quoi on peut s'attendre. La premier cahier montre la formation du modèle XGBoost donné ainsi que la logique de prétraitement utilisée à la fois pour la formation et le temps d'inférence. La deuxième cahier montre comment nous préparons les artefacts nécessaires au déploiement sur Triton.

Le premier bloc-notes montre un bloc-notes existant de votre organisation qui utilise le RAPIDES suite de bibliothèques et le noyau RAPIDS Conda. Cette instance s'exécute sur un type d'instance G4DN fourni par AWS, qui est accéléré par GPU à l'aide de processeurs NVIDIA T4.

Les tâches de prétraitement dans cet exemple bénéficient de l'accélération GPU et utilisent fortement les bibliothèques cuML et cuDF. Un exemple de ceci est dans le code suivant, où nous montrons l'encodage d'étiquette catégoriel à l'aide de cuML. Nous générons également un label_encoders.pkl fichier que nous pouvons utiliser pour sérialiser les encodeurs et les utiliser pour le prétraitement pendant le temps d'inférence.

Le premier cahier se termine par la formation de notre modèle XGBoost et la sauvegarde des artefacts en conséquence.

Dans ce scénario, le code de formation existait déjà et aucune modification n'est nécessaire pour le modèle au moment de la formation. De plus, bien que nous ayons utilisé l'accélération GPU pour le prétraitement pendant la formation, nous prévoyons d'utiliser des processeurs pour le prétraitement au moment de l'inférence. Nous expliquons plus tard dans le post.

Passons maintenant au deuxième cahier et rappelons ce dont nous avons besoin pour un déploiement réussi de Triton.

Tout d'abord, nous avons besoin des artefacts de modèle requis par les backends. Les fichiers que nous devons créer pour cet ensemble incluent :

• Artefacts de prétraitement (model.py, label_encoders.pkl)
• Artefacts du modèle XGBoost (xgboost.json)

Le backend Python dans Triton nous oblige à utiliser un environnement Conda comme dépendance. Dans ce cas, nous utilisons le backend Python pour prétraiter les données brutes avant de les alimenter dans le modèle XGBoost exécuté dans le backend FIL. Même si nous utilisions à l'origine les bibliothèques RAPIDS cuDF et cuML pour effectuer le prétraitement des données (comme indiqué précédemment à l'aide de notre GPU), nous utilisons ici Pandas et Scikit-learn comme dépendances de prétraitement pour le temps d'inférence (à l'aide de notre CPU). Nous le faisons pour trois raisons :

• Pour montrer comment créer un environnement Conda pour vos dépendances et comment le conditionner dans le format attendu par le backend Python de Triton.
• En montrant le modèle de prétraitement s'exécutant dans le backend Python sur le CPU tandis que le modèle XGBoost s'exécute sur le GPU dans le backend FIL, nous illustrons comment chaque modèle du pipeline d'ensemble de Triton peut s'exécuter sur un backend de framework différent et s'exécuter sur un matériel différent avec différents configurations.
• Il met en évidence la compatibilité des bibliothèques RAPIDS (cuDF, cuML) avec leurs homologues CPU (Pandas, Scikit-learn). De cette façon, nous pouvons montrer comment LabelEncoders créé dans cuML peut être utilisé dans Scikit-learn et vice-versa. Notez que si vous prévoyez de prétraiter de grandes quantités de données tabulaires pendant le temps d'inférence, vous pouvez toujours utiliser RAPIDS pour l'accélérer par GPU.

Rappelons que nous avons créé le label_encoders.pkl fichier dans le premier cahier. Il n'y a rien d'autre à faire pour l'encodage de catégorie que de l'inclure dans notre model.py fichier pour le prétraitement.

Pour créer le fichier model.py requis par le backend Triton Python, nous adhérons au formatage requis par le backend et inclure notre logique Python pour traiter le tenseur entrant et utiliser l'encodeur d'étiquette référencé précédemment. Vous pouvez revoir le filet utilisé pour le prétraitement.

Pour le modèle XGBoost, rien de plus n'a besoin d'être fait. Nous avons formé le modèle dans le premier notebook et le backend FIL de Triton ne nécessite aucun effort supplémentaire pour les modèles XGBoost.

Ensuite, nous avons besoin des fichiers de configuration de Triton. Chaque modèle de l'ensemble Triton nécessite un config.pbtxt dossier. De plus, nous créons également un config.pbtxt dossier pour l'ensemble dans son ensemble. Ces fichiers permettent à Triton de connaître les métadonnées sur l'ensemble avec des informations telles que les entrées et les sorties que nous attendons ainsi que d'aider à définir le DAG associé à l'ensemble.

Enfin, pour déployer un modèle sur Triton, nous avons besoin que notre dossier de référentiel de modèles ait la structure de dossiers appropriée. Triton a des exigences spécifiques pour la disposition du référentiel de modèles. Dans le répertoire du référentiel de modèles de niveau supérieur, chaque modèle possède son propre sous-répertoire contenant les informations du modèle correspondant. Chaque répertoire de modèle dans Triton doit avoir au moins un sous-répertoire numérique représentant une version du modèle. Pour notre cas d'utilisation, la structure résultante devrait ressembler à ce qui suit.

Une fois que nous avons ces trois conditions préalables, nous créons un fichier compressé comme emballage pour le déploiement et le téléchargeons sur Service de stockage simple Amazon (Amazon S3).

Nous pouvons maintenant créer un modèle SageMaker à partir du référentiel de modèles que nous avons chargé sur Amazon S3 à l'étape précédente.

Dans cette étape, nous fournissons également la variable d'environnement supplémentaire SAGEMAKER_TRITON_DEFAULT_MODEL_NAME, qui spécifie le nom du modèle à charger par Triton. La valeur de cette clé doit correspondre au nom du dossier dans le package de modèle chargé sur Amazon S3. Cette variable est facultative dans le cas d'un modèle unique. Dans le cas des modèles d'ensemble, cette clé doit être spécifiée pour que Triton démarre dans SageMaker.

De plus, vous pouvez définir SAGEMAKER_TRITON_BUFFER_MANAGER_THREAD_COUNT et SAGEMAKER_TRITON_THREAD_COUNT pour optimiser le nombre de threads. Les deux valeurs de configuration aident à régler le nombre de threads qui s'exécutent sur vos processeurs, de sorte que vous pouvez éventuellement obtenir une meilleure utilisation en augmentant ces valeurs pour les processeurs avec un plus grand nombre de cœurs. Dans la majorité des cas, les valeurs par défaut fonctionnent souvent bien, mais il peut être utile d'expérimenter pour voir si une efficacité supplémentaire peut être obtenue pour vos charges de travail.

Avec le modèle précédent, nous créons une configuration de point de terminaison dans laquelle nous pouvons spécifier le type et le nombre d'instances que nous voulons dans le point de terminaison.

Enfin, nous utilisons la configuration de point de terminaison précédente pour créer un nouveau point de terminaison SageMaker et attendre la fin du déploiement. Le statut passe à InService une fois le déploiement réussi.

C'est ça! Votre point de terminaison est maintenant prêt pour les tests et la validation. À ce stade, vous souhaiterez peut-être utiliser divers outils pour vous aider à optimiser vos types d'instance et votre configuration afin d'obtenir les meilleures performances possibles. La figure suivante fournit un exemple des gains qui peuvent être obtenus en utilisant le backend FIL pour un modèle XGBoost sur Triton.

Résumé

Dans cet article, nous vous avons expliqué comment déployer une charge de travail d'ensemble XGBoost sur SageMaker avec Triton Inference Server. Le déplacement des charges de travail vers Triton sur SageMaker peut être un retour sur investissement avantageux. Comme pour toute adoption de technologie, un processus et un plan de vérification sont essentiels, et nous avons détaillé un processus en cinq étapes pour vous guider dans les éléments à prendre en compte lors du déplacement de vos charges de travail. De plus, nous avons approfondi les étapes nécessaires pour déployer un ensemble qui utilise le prétraitement Python et un modèle XGBoost sur Triton sur SageMaker.

SageMaker fournit les outils permettant de supprimer les charges lourdes indifférenciées de chaque étape du cycle de vie ML, facilitant ainsi l'expérimentation et l'exploration rapides nécessaires pour optimiser pleinement vos déploiements de modèles. La prise en charge de l'hébergement SageMaker pour Triton Inference Server permet des charges de travail à faible latence et à transactions élevées par seconde (TPS).

Vous pouvez trouver les cahiers utilisés pour cet exemple sur GitHub.

---

A propos de l'auteure

James Park est architecte de solutions chez Amazon Web Services. Il travaille avec Amazon.com pour concevoir, construire et déployer des solutions technologiques sur AWS, et s'intéresse particulièrement à l'IA et à l'apprentissage automatique. Dans ses temps libres, il aime découvrir de nouvelles cultures, de nouvelles expériences et se tenir au courant des dernières tendances technologiques.

Jia Hong Liu est architecte de solutions au sein de l'équipe Cloud Service Provider de NVIDIA. Il aide les clients à adopter des solutions d'apprentissage automatique et d'IA qui tirent parti de l'informatique accélérée de NVIDIA pour relever leurs défis de formation et d'inférence. Dans ses temps libres, il aime l'origami, les projets de bricolage et jouer au basket.

Kshitiz Gupta est architecte de solutions chez NVIDIA. Il aime éduquer les clients du cloud sur les technologies GPU AI que NVIDIA a à offrir et les aider à accélérer leurs applications d'apprentissage automatique et d'apprentissage en profondeur. En dehors du travail, il aime courir, faire de la randonnée et observer la faune.

Bruno Aguiar de Melo est ingénieur en développement logiciel chez Amazon.com, où il aide les équipes scientifiques à créer, déployer et publier des charges de travail ML. Il s'intéresse à l'instrumentation et aux aspects contrôlables dans la phase de modélisation/conception ML qui doivent être pris en compte et mesurés avec l'idée que les performances d'exécution du modèle sont tout aussi importantes que les performances de qualité du modèle, en particulier dans les cas d'utilisation contraints par la latence. Dans ses temps libres, il aime le vin, les jeux de société et la cuisine.

Eliuth Triana est responsable des relations avec les développeurs chez NVIDIA. Il met en relation les chefs de produit, les développeurs et les scientifiques d'Amazon et d'AWS avec les technologues et les chefs de produit de NVIDIA pour accélérer les charges de travail Amazon ML/DL, les produits EC2 et les services AWS AI. De plus, Eliuth est un vététiste passionné, un skieur et un joueur de poker.