L'un des modèles les plus populaires disponibles aujourd'hui est XGBoost. Avec la capacité de résoudre divers problèmes tels que la classification et la régression, XGBoost est devenu une option populaire qui entre également dans la catégorie des modèles arborescents. Dans cet article, nous plongeons profondément pour voir comment Amazon Sage Maker peut servir ces modèles en utilisant Serveur d'inférence NVIDIA Triton. Les charges de travail d'inférence en temps réel peuvent avoir différents niveaux d'exigences et d'accords de niveau de service (SLA) en termes de latence et de débit, et peuvent être satisfaites à l'aide de points de terminaison en temps réel SageMaker.
SageMaker fournit points de terminaison de modèle unique, qui vous permettent de déployer un seul modèle d'apprentissage automatique (ML) sur un point de terminaison logique. Pour les autres cas d'utilisation, vous pouvez choisir de gérer les coûts et les performances à l'aide de points de terminaison multimodèle, qui vous permettent de spécifier plusieurs modèles à héberger derrière un point de terminaison logique. Quelle que soit l'option que vous choisissez, les points de terminaison SageMaker permettent un mécanisme évolutif même pour les clients d'entreprise les plus exigeants tout en offrant de la valeur dans une pléthore de fonctionnalités, y compris variantes d'ombre, mise à l'échelle automatique, et intégration native avec Amazon Cloud Watch (pour plus d'informations, reportez-vous à Métriques CloudWatch pour les déploiements de points de terminaison multimodèles).
Triton prend en charge divers backends en tant que moteurs pour prendre en charge l'exécution et le service de divers modèles ML pour l'inférence. Pour tout déploiement Triton, il est crucial de savoir comment le comportement du backend affecte vos charges de travail et à quoi s'attendre pour que vous puissiez réussir. Dans cet article, nous vous aidons à comprendre Backend de la bibliothèque d'inférence forestière (FIL), qui est pris en charge par Triton sur SageMaker, afin que vous puissiez prendre une décision éclairée pour vos charges de travail et obtenir la meilleure optimisation des performances et des coûts possible.
Plongez dans le backend FIL
Triton soutient la Serveur FIL pour servir des modèles d'arbres, tels que XGBoost, LightGBM, scikit-apprendre Forêt aléatoire, Forêt aléatoire RAPIDS cuML, et tout autre modèle pris en charge par Arbrelite. Ces modèles sont utilisés depuis longtemps pour résoudre des problèmes tels que la classification ou la régression. Bien que ces types de modèles fonctionnent traditionnellement sur des processeurs, la popularité de ces modèles et les demandes d'inférence ont conduit à diverses techniques pour augmenter les performances d'inférence. Le backend FIL utilise bon nombre de ces techniques en utilisant des constructions cuML et est construit sur C++ et la bibliothèque principale CUDA pour optimiser les performances d'inférence sur les accélérateurs GPU.
Le backend FIL utilise les bibliothèques de cuML pour utiliser les cœurs CPU ou GPU afin d'accélérer l'apprentissage. Afin d'utiliser ces processeurs, les données sont référencées à partir de la mémoire hôte (par exemple, les baies NumPy) ou des baies GPU (uDF, Numba, cuPY ou toute bibliothèque prenant en charge le __cuda_array_interface__
) API. Une fois les données stockées en mémoire, le backend FIL peut exécuter le traitement sur tous les cœurs CPU ou GPU disponibles.
Les threads backend FIL peuvent communiquer entre eux sans utiliser la mémoire partagée de l'hôte, mais dans les charges de travail d'ensemble, la mémoire de l'hôte doit être prise en compte. Le diagramme suivant montre une architecture d'exécution du planificateur d'ensemble où vous avez la possibilité d'affiner les zones de mémoire, y compris la mémoire partagée adressable par le processeur qui est utilisée pour la communication inter-processus entre Triton (C++) et le processus Python (python backend) pour l'échange tenseurs (entrée/sortie) avec le backend FIL.
Triton Inference Server fournit des options configurables aux développeurs pour régler leurs charges de travail et optimiser les performances 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.
Il existe un certain nombre d'autres Options disponibles qui ont un impact sur les performances et le comportement. Nous suggérons de commencer par storage_type
. Lors de l'exécution du backend sur GPU, FIL crée une nouvelle structure mémoire/données qui est une représentation de l'arborescence pour laquelle FIL peut avoir un impact sur les performances et l'empreinte. Ceci est configurable via le paramètre d'environnement storage_type
, qui a les options dense, sparse et auto. Le choix de l'option dense consommera plus de mémoire GPU et ne se traduira pas toujours par de meilleures performances, il est donc préférable de vérifier. En revanche, l'option clairsemée consommera moins de mémoire GPU et peut éventuellement fonctionner aussi bien ou mieux que dense. Si vous choisissez auto, le modèle sera dense par défaut, à moins que cela ne consomme beaucoup plus de mémoire GPU que sparse.
En ce qui concerne les performances du modèle, vous pouvez envisager de mettre l'accent sur threads_per_tree
option. Une chose que vous pouvez ignorer dans des scénarios réels est que threads_per_tree
peut avoir un impact plus important sur le débit que tout autre paramètre. Le régler sur n'importe quelle puissance de 2 entre 1 et 32 est légitime. La valeur optimale est difficile à prédire pour ce paramètre, mais lorsque le serveur est censé gérer une charge plus élevée ou traiter des tailles de lots plus importantes, il a tendance à bénéficier d'une valeur plus élevée que lorsqu'il traite quelques lignes à la fois.
Un autre paramètre à prendre en compte est algo
, qui est également disponible si vous exécutez sur GPU. Ce paramètre détermine l'algorithme utilisé pour traiter les demandes d'inférence. Les options prises en charge pour cela sont ALGO_AUTO
, NAIVE
, TREE_REORG
et une BATCH_TREE_REORG
. Ces options déterminent la manière dont les nœuds d'une arborescence sont organisés et peuvent également entraîner des gains de performances. Le ALGO_AUTO
l'option par défaut est NAIVE
pour un stockage clairsemé et BATCH_TREE_REORG
pour un stockage dense.
Enfin, FIL est livré avec l'explicateur Shapley, qui peut être activé en utilisant le treeshap_output
paramètre. Cependant, vous devez garder à l'esprit que les sorties Shapley nuisent aux performances en raison de leur taille de sortie.
Présentation du modèle
Il n'existe actuellement aucun format de fichier standard pour stocker les modèles basés sur la forêt ; chaque framework a tendance à définir son propre format. Afin de prendre en charge plusieurs formats de fichiers d'entrée, FIL importe des données à l'aide de l'open-source Arbrelite bibliothèque. Cela permet à FIL de prendre en charge des modèles formés dans des frameworks populaires, tels que XGBoost ainsi que LumièreGBM. Notez que le format du modèle que vous fournissez doit être défini dans le model_type
valeur de configuration spécifiée dans le config.pbtxt
fichier.
Config.pbtxt
Chaque modèle dans un référentiel de modèles doit inclure une configuration de modèle qui fournit les informations requises et facultatives sur le modèle. Généralement, cette configuration est fournie dans un config.pbtxt
fichier spécifié comme Protobuf ModelConfig. Pour en savoir plus sur les paramètres de configuration, reportez-vous à Configuration du modèle. Voici quelques-uns des paramètres de configuration du modèle :
- max_batch_size – Cela détermine la taille de lot maximale qui peut être transmise à ce modèle. En général, la seule limite à la taille des lots transmis à un backend FIL est la mémoire disponible pour les traiter. Pour les exécutions GPU, la mémoire disponible est déterminée par la taille du pool de mémoire CUDA de Triton, qui peut être définie via un argument de ligne de commande lors du démarrage du serveur.
- contribution – Les options de cette section indiquent à Triton le nombre de fonctionnalités à attendre pour chaque échantillon d'entrée.
- sortie – Les options de cette section indiquent à Triton le nombre de valeurs de sortie qu'il y aura pour chaque échantillon. Si la
predict_proba
est définie sur true, une valeur de probabilité sera renvoyée pour chaque classe. Sinon, une seule valeur sera renvoyée, indiquant la classe prédite pour l'échantillon donné. - groupe_instance – Cela détermine le nombre d'instances de ce modèle qui seront créées et si elles utiliseront le GPU ou le CPU.
- type de modèle – Cette chaîne indique le format du modèle (
xgboost_json
dans cet exemple, maisxgboost
,lightgbm
et unetl_checkpoint
sont également des formats valides). - prédire_proba – Si la valeur est true, les valeurs de probabilité seront renvoyées pour chaque classe plutôt qu'une simple prédiction de classe.
- classe_sortie – Ce paramètre est défini sur vrai pour les modèles de classification et sur faux pour les modèles de régression.
- порог – Il s'agit d'un seuil de score pour déterminer la classification. Quand
output_class
est défini sur true, cela doit être fourni, bien qu'il ne soit pas utilisé sipredict_proba
est également défini sur vrai. - Type de stockage – En général, l'utilisation d'AUTO pour ce paramètre devrait répondre à la plupart des cas d'utilisation. Si le stockage AUTO est sélectionné, FIL chargera le modèle en utilisant une représentation clairsemée ou dense en fonction de la taille approximative du modèle. Dans certains cas, vous souhaiterez peut-être définir explicitement ce paramètre sur SPARSE afin de réduire l'empreinte mémoire des modèles volumineux.
Serveur d'inférence Triton sur SageMaker
SageMaker permet vous permet de déployer à la fois des terminaux à modèle unique et à modèles multiples avec NVIDIA Triton Inference Server. La figure suivante montre l'architecture de haut niveau du serveur d'inférence Triton. Le référentiel de modèles est un référentiel basé sur le système de fichiers des modèles que Triton mettra à disposition pour l'inférence. Les demandes d'inférence arrivent au serveur et sont acheminées vers le planificateur approprié par modèle. Outils Triton plusieurs algorithmes de planification et de traitement par lots qui peut être configuré sur une base modèle par modèle. Le planificateur de chaque modèle effectue éventuellement un traitement par lots des demandes d'inférence, puis transmet les demandes au backend correspondant au type de modèle. Le backend effectue une inférence à l'aide des entrées fournies dans les requêtes groupées pour produire les sorties demandées. Les sorties sont ensuite renvoyées.
Lors de la configuration de vos groupes de mise à l'échelle automatique pour les points de terminaison SageMaker, vous pouvez envisager SageMakerVariantInvocationsPerInstance
comme critères principaux pour déterminer les caractéristiques de mise à l'échelle de votre groupe de mise à l'échelle automatique. De plus, selon que vos modèles s'exécutent sur GPU ou CPU, vous pouvez également envisager d'utiliser CPUUtilization ou GPUUtilization comme critères supplémentaires. Notez que pour les points de terminaison à modèle unique, étant donné que les modèles déployés sont tous identiques, il est assez simple de définir des politiques appropriées pour respecter vos SLA. Pour les points de terminaison multimodèles, nous vous recommandons de déployer des modèles similaires derrière un point de terminaison donné pour obtenir des performances prévisibles plus stables. Dans les cas d'utilisation où des modèles de tailles et d'exigences différentes sont utilisés, vous souhaiterez peut-être séparer ces charges de travail sur plusieurs points de terminaison multimodèles ou passer du temps à affiner votre stratégie de groupe de mise à l'échelle automatique pour obtenir le meilleur équilibre entre les coûts et les performances.
Pour obtenir la liste des conteneurs d'apprentissage en profondeur NVIDIA Triton (DLC) pris en charge par l'inférence SageMaker, reportez-vous à Images de conteneurs de Deep Learning disponibles.
Présentation du bloc-notes SageMaker
Les applications ML sont complexes et peuvent souvent nécessiter un prétraitement des données. Dans ce bloc-notes, nous expliquons comment déployer un modèle ML basé sur une arborescence comme XGBoost à l'aide du backend FIL dans Triton sur un point de terminaison multimodèle SageMaker. Nous expliquons également comment implémenter un pipeline d'inférence de prétraitement de données basé sur Python pour votre modèle à l'aide de la fonctionnalité d'ensemble dans Triton. Cela nous permettra d'envoyer les données brutes du côté client et de faire en sorte que le prétraitement des données et l'inférence de modèle se produisent dans un point de terminaison Triton SageMaker pour des performances d'inférence optimales.
Fonction d'ensemble de modèles Triton
Triton Inference Server simplifie grandement le déploiement de modèles d'IA à grande échelle en production. Triton Inference Server est livré avec une solution pratique qui simplifie la création de pipelines de prétraitement et de post-traitement. La plate-forme Triton Inference Server fournit le planificateur d'ensemble, qui est responsable de la mise en pipeline des modèles participant au processus d'inférence tout en garantissant l'efficacité et l'optimisation du débit. L'utilisation de modèles d'ensemble peut éviter la surcharge de transfert des tenseurs intermédiaires et minimiser le nombre de requêtes qui doivent être envoyées à Triton.
Dans ce bloc-notes, nous montrons comment utiliser la fonctionnalité d'ensemble pour créer un pipeline de prétraitement de données avec l'inférence de modèle XGBoost, et vous pouvez en extrapoler pour ajouter un post-traitement personnalisé au pipeline.
Mettre en place l'environnement
Nous commençons par configurer l'environnement requis. Nous installons les dépendances nécessaires pour empaqueter notre pipeline de modèles et exécuter des inférences à l'aide de Triton Inference Server. Nous définissons également la Gestion des identités et des accès AWS (IAM) qui permettra à SageMaker d'accéder aux artefacts du modèle et au NVIDIA Triton Registre des conteneurs élastiques Amazon (Amazon ECR). Voir le code suivant :
Créer un environnement Conda pour le prétraitement des dépendances
Le backend Python dans Triton nous oblige à utiliser un Conda environnement pour toutes les dépendances supplémentaires. Dans ce cas, nous utilisons le backend Python pour prétraiter les données brutes avant de les alimenter dans le modèle XGBoost qui s'exécute dans le backend FIL. Même si nous avons initialement utilisé RAPIDS cuDF et cuML pour effectuer le prétraitement des données, nous utilisons ici Pandas et scikit-learn comme dépendances de prétraitement lors de l'inférence. Nous le faisons pour trois raisons :
- Nous montrons 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 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 ainsi que sur différentes configurations matérielles.
- Il met en évidence la compatibilité des bibliothèques RAPIDS (cuDF, cuML) avec leurs homologues CPU (Pandas, scikit-learn). Par exemple, nous pouvons montrer comment
LabelEncoders
créé dans cuML peut être utilisé dans scikit-learn et vice versa.
Nous suivons les instructions du Documentation Triton pour empaqueter les dépendances de prétraitement (scikit-learn et Pandas) à utiliser dans le backend Python en tant que fichier TAR de l'environnement Conda. Le script bash create_prep_env.sh crée le fichier TAR de l'environnement Conda, puis nous le déplaçons dans le répertoire du modèle de prétraitement. Voir le code suivant :
Après avoir exécuté le script précédent, il génère preprocessing_env.tar.gz
, que nous copions dans le répertoire de prétraitement :
Configurer le prétraitement avec le backend Triton Python
Pour le prétraitement, nous utilisons Triton's Back-end Python pour effectuer un prétraitement des données tabulaires (codage catégoriel) lors de l'inférence pour les demandes de données brutes entrant dans le serveur. Pour plus d'informations sur le prétraitement qui a été effectué pendant la formation, reportez-vous au cahier de formation.
Le backend Python permet d'implémenter le prétraitement, le post-traitement et toute autre logique personnalisée en Python et de les servir avec Triton. L'utilisation de Triton sur SageMaker nous oblige à configurer d'abord un dossier de référentiel de modèles contenant les modèles que nous voulons servir. Nous avons déjà mis en place un modèle de prétraitement de données Python appelé prétraitement dans cpu_model_repository
ainsi que gpu_model_repository
.
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. La valeur 1 représente la version 1 de notre modèle de prétraitement Python. Chaque modèle est exécuté par un backend spécifique, donc dans chaque sous-répertoire de version, il doit y avoir l'artefact de modèle requis par ce backend. Pour cet exemple, nous utilisons le backend Python, qui nécessite que le fichier Python que vous servez s'appelle model.py, et le fichier doit implémenter certaines fonctions. Si nous utilisions un backend PyTorch, un fichier model.pt serait requis, et ainsi de suite. Pour plus de détails sur les conventions de dénomination des fichiers de modèle, reportez-vous à Fichiers modèles.
La modèle.py Le fichier Python que nous utilisons ici implémente toute la logique de prétraitement des données tabulaires pour convertir les données brutes en fonctionnalités pouvant être introduites dans notre modèle XGBoost.
Chaque modèle Triton doit également fournir un config.pbtxt
fichier décrivant la configuration du modèle. Pour en savoir plus sur les paramètres de configuration, reportez-vous à Configuration du modèle. Notre config.pbtxt Le fichier spécifie le backend en tant que python et toutes les colonnes d'entrée pour les données brutes ainsi que la sortie prétraitée, qui se compose de 15 fonctionnalités. Nous spécifions également que nous voulons exécuter ce modèle de prétraitement Python sur le CPU. Voir le code suivant :
Configurer un modèle de ML basé sur une arborescence pour le backend FIL
Ensuite, nous configurons le répertoire de modèle pour un modèle ML basé sur une arborescence comme XGBoost, qui utilisera le backend FIL.
La mise en page attendue pour cpu_memory_repository
ainsi que gpu_memory_repository
sont similaires à celui que nous avons montré précédemment.
Ici, FIL
est le nom du modèle. Nous pouvons lui donner un nom différent comme xgboost
si nous le voulons. 1
est le sous-répertoire de la version, qui contient l'artefact du modèle. Dans ce cas, c'est le xgboost.json
modèle que nous avons sauvegardé. Créons cette mise en page attendue :
Nous avons besoin du fichier de configuration config.pbtxt
décrivant la configuration du modèle pour le modèle ML basé sur l'arborescence, afin que le backend FIL dans Triton puisse comprendre comment le servir. Pour plus d'informations, reportez-vous au dernier Options de configuration Triton et les options de configuration propres au Serveur FIL. Nous nous concentrons sur quelques-unes des options les plus courantes et les plus pertinentes dans cet exemple.
Création config.pbtxt
en model_cpu_repository
:
De même, installez config.pbtxt
en model_gpu_repository
(notez que la différence est USE_GPU = True
):
Configurer un pipeline d'inférence du backend Python de prétraitement des données et du backend FIL à l'aide d'ensembles
Nous sommes maintenant prêts à configurer le pipeline d'inférence pour le prétraitement des données et l'inférence de modèle basée sur l'arborescence à l'aide d'un modèle d'ensemble. Un modèle d'ensemble représente un pipeline d'un ou plusieurs modèles et la connexion des tenseurs d'entrée et de sortie entre ces modèles. Ici, nous utilisons le modèle d'ensemble pour créer un pipeline de prétraitement des données dans le backend Python suivi de XGBoost dans le backend FIL.
La mise en page attendue pour le ensemble
Le répertoire model est similaire à ceux que nous avons montrés précédemment :
Nous avons créé le modèle d'ensemble config.pbtxt suivant les indications de Modèles d'ensemble. Surtout, nous devons configurer le planificateur d'ensemble dans config.pbtxt
, qui spécifie le flux de données entre les modèles au sein de l'ensemble. Le planificateur d'ensemble collecte les tenseurs de sortie à chaque étape et les fournit comme tenseurs d'entrée pour les autres étapes selon la spécification.
Empaquetez le référentiel de modèles et chargez-le sur Amazon S3
Enfin, nous nous retrouvons avec la structure de répertoires de référentiel de modèles suivante, contenant un modèle de prétraitement Python et ses dépendances, ainsi que le modèle XGBoost FIL et l'ensemble de modèles.
Nous emballons le répertoire et son contenu comme model.tar.gz
pour télécharger sur Service de stockage simple Amazon (Amazon S3). Nous avons deux options dans cet exemple : utiliser une instance basée sur le CPU ou une instance basée sur le GPU. Une instance basée sur GPU est plus adaptée lorsque vous avez besoin d'une puissance de traitement plus élevée et que vous souhaitez utiliser des cœurs CUDA.
Créez et importez le package de modèle pour une instance basée sur le processeur (optimisée pour le processeur) avec le code suivant :
Créez et importez le package de modèle pour une instance basée sur GPU (optimisée pour GPU) avec le code suivant :
Créer un point de terminaison SageMaker
Nous avons maintenant les artefacts du modèle stockés dans un compartiment S3. Dans cette étape, nous pouvons également fournir 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
ainsi que SAGEMAKER_TRITON_THREAD_COUNT
pour optimiser le nombre de threads.
Nous utilisons le modèle précédent pour créer une configuration de point de terminaison où nous pouvons spécifier le type et le nombre d'instances que nous voulons dans le point de terminaison
Nous utilisons cette configuration de point de terminaison pour créer un point de terminaison SageMaker et attendre la fin du déploiement. Avec les MME SageMaker, nous avons la possibilité d'héberger plusieurs modèles d'ensemble en répétant ce processus, mais nous nous en tenons à un déploiement pour cet exemple :
Le statut passera à InService
lorsque le déploiement est réussi.
Appelez votre modèle hébergé sur le point de terminaison SageMaker
Une fois le point de terminaison en cours d'exécution, nous pouvons utiliser des exemples de données brutes pour effectuer une inférence en utilisant JSON comme format de charge utile. Pour le format de demande d'inférence, Triton utilise le KFServing
norme communautaire protocoles d'inférence. Voir le code suivant:
Le bloc-notes mentionné dans le blog se trouve dans le GitHub référentiel.
des pratiques d’excellence;
Outre les options permettant d'affiner les paramètres du backend FIL que nous avons mentionnés précédemment, les scientifiques des données peuvent également s'assurer que les données d'entrée pour le backend sont optimisées pour le traitement par le moteur. Dans la mesure du possible, saisissez les données au format ligne principale dans le tableau GPU. D'autres formats nécessiteront une conversion interne et des cycles de reprise, ce qui diminuera les performances.
En raison de la façon dont les structures de données FIL sont conservées dans la mémoire GPU, tenez compte de la profondeur de l'arborescence. Plus la profondeur de l'arborescence est profonde, plus l'empreinte mémoire de votre GPU sera importante.
Utilisez l'option instance_group_count
paramètre pour ajouter des processus de travail et augmenter le débit du backend FIL, ce qui entraînera une plus grande consommation de mémoire CPU et GPU. En outre, tenez compte des variables spécifiques à SageMaker qui sont disponibles pour augmenter le débit, telles que les threads HTTP, la taille de la mémoire tampon HTTP, la taille du lot et le délai maximal.
Conclusion
Dans cet article, nous avons approfondi le backend FIL que Triton Inference Server prend en charge sur SageMaker. Ce backend fournit à la fois l'accélération CPU et GPU de vos modèles arborescents tels que l'algorithme populaire XGBoost. Il existe de nombreuses options à prendre en compte pour obtenir les meilleures performances d'inférence, telles que la taille des lots, les formats d'entrée de données et d'autres facteurs qui peuvent être réglés pour répondre à vos besoins. SageMaker vous permet d'utiliser cette fonctionnalité avec des points de terminaison à un ou plusieurs modèles pour équilibrer les performances et les économies de coûts.
Nous vous encourageons à prendre les informations contenues dans cet article et à voir si SageMaker peut répondre à vos besoins d'hébergement pour servir des modèles arborescents, répondant à vos exigences en matière de réduction des coûts et de performances de la charge de travail.
Le bloc-notes référencé dans cet article se trouve dans les exemples SageMaker GitHub référentiel. De plus, vous pouvez trouver la dernière documentation sur le backend FIL sur GitHub.
À propos des auteurs
Raghu Ramesha est architecte principal de solutions ML au sein de l'équipe Amazon SageMaker Service. Il se concentre sur l'aide aux clients pour créer, déployer et migrer les charges de travail de production ML vers SageMaker à grande échelle. Il est spécialisé dans les domaines de l'apprentissage automatique, de l'IA et de la vision par ordinateur, et est titulaire d'une maîtrise en informatique de l'UT Dallas. Pendant son temps libre, il aime voyager et photographier.
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.
Dhawal Patel est architecte principal en apprentissage machine chez AWS. Il a travaillé avec des organisations allant des grandes entreprises aux startups de taille moyenne sur des problèmes liés à l'informatique distribuée et à l'intelligence artificielle. Il se concentre sur l'apprentissage en profondeur, y compris les domaines de la PNL et de la vision par ordinateur. Il aide les clients à obtenir une inférence de modèle hautes performances sur Amazon SageMaker.
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.
- Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
- PlatoAiStream. Intelligence des données Web3. Connaissance Amplifiée. Accéder ici.
- Frapper l'avenir avec Adryenn Ashley. Accéder ici.
- La source: https://aws.amazon.com/blogs/machine-learning/hosting-ml-models-on-amazon-sagemaker-using-triton-xgboost-lightgbm-and-treelite-models/
- :possède
- :est
- :ne pas
- :où
- $UP
- 1
- 100
- 11
- 13
- 200
- 23
- 24
- 7
- 8
- 9
- a
- capacité
- A Propos
- accélérer
- accéléré
- accélérer
- accélérateurs
- accès
- Selon
- en conséquence
- Compte
- atteindre
- à travers
- ajouter
- ajout
- Supplémentaire
- propos
- adressable
- L'adoption d'
- Après
- à opposer à
- accords
- AI
- algorithme
- Tous
- allocations
- permettre
- permet
- le long de
- déjà
- aussi
- Bien que
- toujours
- Amazon
- Amazon Sage Maker
- Amazon Web Services
- -
- montant
- an
- ainsi que
- tous
- api
- applications
- approprié
- architecture
- SONT
- domaines
- argument
- tableau
- artificiel
- intelligence artificielle
- AS
- aide
- At
- auto
- disponibles
- éviter
- AWS
- backend
- Balance
- basé
- bash
- base
- Basketball
- BE
- car
- devenez
- était
- before
- commencer
- derrière
- ci-dessous
- profiter
- LES MEILLEURS
- Améliorée
- jusqu'à XNUMX fois
- plus gros
- Blog
- corps
- tous les deux
- tampon
- construire
- Développement
- construit
- mais
- by
- C + +
- appelé
- CAN
- carte
- maisons
- cas
- Catégories
- Causes
- globaux
- Change
- caractéristiques
- vérifier
- puce
- Selectionnez
- choose
- Ville
- classe
- classification
- client
- CLIENTS
- le cloud
- code
- Colonnes
- COM
- vient
- Venir
- Commun
- communiquer
- Communication
- Communautés
- compatible
- complexe
- calcul
- ordinateur
- Informatique
- Vision par ordinateur
- informatique
- configuration
- connexion
- Considérer
- considéré
- consommer
- consommation
- Contenant
- Conteneurs
- contient
- contenu
- contraste
- des bactéries
- Pratique
- Conversion
- convertir
- Core
- Correspondant
- Prix
- réduction des coûts
- les économies de coûts
- couverture
- engendrent
- créée
- crée des
- critères
- crucial
- Lecture
- Customiser
- Clients
- cycles
- Dallas
- données
- Date
- journée
- affaire
- décision
- profond
- l'apprentissage en profondeur
- profond
- Réglage par défaut
- par défaut
- Degré
- retarder
- exigeant
- demandes
- Selon
- déployer
- déployé
- déployer
- déploiement
- profondeur
- Conception
- détails
- Déterminer
- déterminé
- détermine
- détermination
- mobiles
- différence
- différent
- distribué
- informatique distribuée
- Bricolage
- do
- Documentation
- Ne fait pas
- faire
- domaines
- fait
- où
- deux
- pendant
- chacun
- Plus tôt
- l'éducation
- efficace
- efficacement
- non plus
- mettant l'accent
- permet
- encourager
- fin
- Endpoint
- Moteur
- Moteurs
- assurer
- assurer
- Entreprise
- entreprises
- Tout
- Environment
- Erreurs
- Pourtant, la
- Chaque
- exemple
- exemples
- échanger
- attendre
- attendu
- Expériences
- Exporter
- facteurs
- équitablement
- Chutes
- non
- Fonctionnalité
- Fonctionnalités:
- Fed
- alimentation
- few
- Figure
- Déposez votre dernière attestation
- Fichiers
- Trouvez
- finition
- Prénom
- flux
- Focus
- se concentre
- suivre
- suivi
- Abonnement
- numérique
- Pour
- formulaire
- le format
- trouvé
- Framework
- cadres
- fraude
- Gratuit
- De
- En outre
- Gains
- Général
- génère
- obtenez
- Donner
- donné
- GPU
- considérablement
- Réservation de groupe
- Groupes
- l'orientation
- arriver
- Dur
- Matériel
- Vous avez
- he
- vous aider
- aider
- aide
- ici
- de haut niveau
- haute performance
- augmentation
- Faits saillants
- sa
- appuyez en continu
- détient
- hôte
- organisé
- hébergement
- Comment
- How To
- Cependant
- HTML
- http
- HTTPS
- Blesser
- Identite
- ids
- IDX
- if
- image
- Impact
- Impacts
- Mettre en oeuvre
- mis en œuvre
- met en oeuvre
- importations
- in
- comprendre
- Y compris
- Améliore
- indique
- d'information
- Actualités
- contribution
- installer
- instance
- Des instructions
- l'intégration
- Intelligence
- intérêt
- interne
- développement
- IT
- SES
- jpg
- json
- juste
- XNUMX éléments à
- ACTIVITES
- Genre
- Savoir
- gros
- Grandes entreprises
- plus importantes
- Latence
- Nouveautés
- Disposition
- APPRENTISSAGE
- apprentissage
- au
- LED
- légitime
- moins
- Niveau
- niveaux
- Levier
- bibliothèques
- Bibliothèque
- comme
- LIMIT
- Gamme
- Liste
- charge
- logique
- logique
- Location
- click
- machine learning
- a prendre une
- gérer
- de nombreuses
- maîtrise
- Match
- max
- maximales
- Mai..
- mécanisme
- Découvrez
- réunion
- Mémoire
- mentionné
- Commerçant
- Métrique
- pourrait
- émigrer
- l'esprit
- ML
- Mode
- modèle
- numériques jumeaux (digital twin models)
- Mois
- PLUS
- (en fait, presque toutes)
- Le Plus Populaire
- Bougez
- Point de terminaison multimodèle
- plusieurs
- must
- prénom
- nommage
- indigène
- Besoin
- Besoins
- Nouveauté
- nlp
- aucune
- nœuds
- cahier
- maintenant
- nombre
- numpy
- Nvidia
- obtenir
- of
- code
- Offres Speciales
- souvent
- on
- ONE
- et, finalement,
- uniquement
- open source
- optimaux
- à mettre en œuvre pour gérer une entreprise rentable. Ce guide est basé sur trois décennies d'expérience
- Optimiser
- optimisé
- l'optimisation
- Option
- Options
- or
- de commander
- organisations
- Organisé
- initialement
- OS
- Autre
- autrement
- nos
- ande
- sortie
- au contrôle
- propre
- paquet
- l'emballage
- pandas
- Parallèle
- paramètre
- paramètres
- participant
- particulier
- passé
- passes
- chemin
- Effectuer
- performant
- effectue
- autorisation
- photographie
- pipeline
- plateforme
- Platon
- Intelligence des données Platon
- PlatonDonnées
- jouer
- veuillez cliquer
- pléthore
- politiques
- politique
- pool
- Populaire
- popularité
- possible
- peut-être
- Post
- power
- prévoir
- Prévisible
- prédit
- prédiction
- Prédictions
- précédemment
- primaire
- Directeur
- d'ouvrabilité
- processus
- les process
- traitement
- Puissance de calcul
- processeurs
- produire
- Vidéo
- projets
- correct
- Proto
- fournir
- à condition de
- de voiture.
- fournit
- aportando
- Python
- pytorch
- aléatoire
- allant
- plutôt
- raw
- solutions
- monde réel
- en temps réel
- Les raisons
- recommander
- réduire
- visée
- Indépendamment
- région
- en relation
- pertinent
- remplacer
- dépôt
- représentation
- représentation
- représente
- nécessaire
- demandes
- exigent
- conditions
- Exigences
- a besoin
- réponse
- responsables
- résultat
- Résultats
- Rôle
- Courir
- pour le running
- s
- sagemaker
- Inférence SageMaker
- même
- Épargnes
- évolutive
- Escaliers intérieurs
- mise à l'échelle
- scénarios
- ordonnancement
- Sciences
- scientifiques
- scikit-apprendre
- But
- Section
- sur le lien
- recherche
- choisi
- envoyer
- supérieur
- séparé
- besoin
- service
- Prestataire de services
- Services
- service
- set
- mise
- Paramétres
- Forme
- commun
- devrait
- montrer
- Spectacles
- côté
- de façon significative
- similaires
- étapes
- unique
- Taille
- tailles
- So
- sur mesure
- Solutions
- RÉSOUDRE
- Résoudre
- quelques
- Identifier
- spécialise
- groupe de neurones
- spécification
- spécifié
- passer
- Standard
- Commencer
- Commencez
- Startups
- Région
- Statut
- stable
- étapes
- Étapes
- storage
- Boutique
- stockée
- simple
- Chaîne
- structure
- réussi
- tel
- suggérer
- convient
- Support
- Appareils
- Les soutiens
- Prenez
- équipe
- techniques
- Les technologies
- Technologie
- dire
- conditions
- que
- qui
- La
- les informations
- leur
- Les
- puis
- Là.
- Ces
- l'ont
- chose
- this
- ceux
- bien que?
- trois
- порог
- débit
- fiable
- à
- aujourd'hui
- ensemble
- haut niveau
- traditionnellement
- qualifié
- Formation
- Transfert
- Voyages
- arbre
- Trends
- Triton
- oui
- deux
- type
- types
- typiquement
- comprendre
- téléchargé
- Téléchargement
- us
- utilisé
- d'utiliser
- Utilisateur
- en utilisant
- utilise
- Utilisant
- Plus-value
- Valeurs
- divers
- version
- via
- vision
- W
- attendez
- souhaitez
- était
- personne(s) regarde(nt) cette fiche produit
- Façon..
- we
- web
- services Web
- WELL
- ont été
- Quoi
- quand
- chaque fois que
- que
- qui
- tout en
- sera
- comprenant
- dans les
- sans
- activités principales
- travaillé
- travailleur
- vos contrats
- pourra
- XGBoost
- an
- Vous n'avez
- Votre
- zéphyrnet
- Zip