Cet article est co-écrit avec Jad Chamoun, directeur de l'ingénierie chez Forethought Technologies, Inc. et Salina Wu, ingénieure principale en ML chez Forethought Technologies, Inc.
Prévoyance est une suite d'IA générative de premier plan pour le service client. Au cœur de sa suite se trouve l'innovation SupportGPT™ technologie qui utilise l'apprentissage automatique pour transformer le cycle de vie du support client, en augmentant la déviation, en améliorant le CSAT et en augmentant la productivité des agents. SupportGPT™ s'appuie sur des systèmes de récupération d'informations (IR) de pointe et sur de grands modèles linguistiques (LLM) pour alimenter plus de 30 millions d'interactions avec les clients par an.
Le principal cas d'utilisation de SupportGPT consiste à améliorer la qualité et l'efficacité des interactions et des opérations d'assistance client. En utilisant des systèmes infrarouges de pointe alimentés par des intégrations et des modèles de classement, SupportGPT peut rechercher rapidement des informations pertinentes, en fournissant des réponses précises et concises aux requêtes des clients. Forethought utilise des modèles affinés par client pour détecter les intentions des clients afin de résoudre les interactions avec les clients. L'intégration de grands modèles de langage aide à humaniser l'interaction avec les agents automatisés, créant une expérience de support plus engageante et satisfaisante.
SupportGPT assiste également les agents du support client en proposant des suggestions de saisie semi-automatique et en élaborant des réponses appropriées aux tickets clients qui correspondent à celles de l'entreprise en fonction des réponses précédentes. En utilisant des modèles de langage avancés, les agents peuvent répondre aux préoccupations des clients plus rapidement et avec plus de précision, ce qui se traduit par une plus grande satisfaction client.
De plus, l'architecture de SupportGPT permet de détecter les lacunes dans les bases de connaissances du support, ce qui aide les agents à fournir des informations plus précises aux clients. Une fois ces lacunes identifiées, SupportGPT peut générer automatiquement des articles et d'autres contenus pour combler ces lacunes dans les connaissances, garantissant ainsi que la base de connaissances de l'assistance reste centrée sur le client et à jour.
Dans cet article, nous partageons comment Forethought utilise Amazon Sage Maker terminaux multi-modèles dans les cas d'utilisation de l'IA générative pour économiser plus de 66 % sur les coûts.
Défis liés aux infrastructures
Pour aider à mettre ces capacités sur le marché, Forethought fait évoluer efficacement ses charges de travail ML et fournit des solutions hyper personnalisées adaptées au cas d'utilisation spécifique de chaque client. Cette hyper-personnalisation est obtenue en affinant les modèles d'intégration et les classificateurs sur les données client, garantissant des résultats de récupération d'informations précis et une connaissance du domaine qui répond aux besoins uniques de chaque client. Les modèles de saisie semi-automatique personnalisés sont également affinés sur les données des clients pour améliorer encore la précision et la pertinence des réponses générées.
L'un des défis majeurs du traitement de l'IA est l'utilisation efficace des ressources matérielles telles que les GPU. Pour relever ce défi, Forethought utilise les terminaux multi-modèles (MME) SageMaker pour exécuter plusieurs modèles d'IA sur un seul terminal d'inférence et à une seule échelle. Étant donné que l'hyper-personnalisation des modèles nécessite la formation et le déploiement de modèles uniques, le nombre de modèles évolue de manière linéaire avec le nombre de clients, ce qui peut devenir coûteux.
Pour atteindre le bon équilibre entre performances pour l'inférence en temps réel et le coût, Forethought a choisi d'utiliser les MME SageMaker, qui prennent en charge l'accélération GPU. Les MME SageMaker permettent à Forethought de fournir des solutions hautes performances, évolutives et rentables avec une latence inférieure à la seconde, répondant à plusieurs scénarios de support client à grande échelle.
SageMaker et prévoyance
SageMaker est un service entièrement géré qui offre aux développeurs et aux data scientists la possibilité de créer, former et déployer rapidement des modèles ML. Les MME SageMaker fournissent une solution évolutive et rentable pour déployer un grand nombre de modèles pour l'inférence en temps réel. Les MME utilisent un conteneur de service partagé et une flotte de ressources qui peuvent utiliser des instances accélérées telles que des GPU pour héberger tous vos modèles. Cela réduit les coûts d'hébergement en maximisant l'utilisation des points de terminaison par rapport à l'utilisation de points de terminaison à modèle unique. Cela réduit également les frais généraux de déploiement, car SageMaker gère le chargement et le déchargement des modèles en mémoire et les met à l'échelle en fonction des modèles de trafic du terminal. De plus, tous les points de terminaison en temps réel SageMaker bénéficient de fonctionnalités intégrées pour gérer et surveiller les modèles, telles que l'inclusion 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).
Alors que Forethought s'est développé pour héberger des centaines de modèles qui nécessitaient également des ressources GPU, nous avons vu une opportunité de créer une architecture plus rentable, fiable et gérable via les MME SageMaker. Avant de migrer vers les MME SageMaker, nos modèles étaient déployés sur Kubernetes sur Service Amazon Elastic Kubernetes (Amazon EKS). Bien qu'Amazon EKS fournisse des fonctionnalités de gestion, il est immédiatement apparu que nous gérions une infrastructure qui n'était pas spécifiquement conçue pour l'inférence. Forethought a dû gérer nous-mêmes l'inférence de modèle sur Amazon EKS, ce qui a pesé sur l'efficacité de l'ingénierie. Par exemple, afin de partager des ressources GPU coûteuses entre plusieurs modèles, nous étions chargés d'allouer des fractions de mémoire rigides aux modèles spécifiés lors du déploiement. Nous voulions résoudre les problèmes clés suivants avec notre infrastructure existante :
- Coût élevé – Pour garantir que chaque modèle dispose de suffisamment de ressources, nous serions très prudents quant au nombre de modèles à adapter par instance. Cela a entraîné des coûts d'hébergement de modèles beaucoup plus élevés que nécessaire.
- Faible fiabilité – Bien qu'ils soient conservateurs dans notre allocation de mémoire, tous les modèles n'ont pas les mêmes exigences, et parfois certains modèles génèrent des erreurs de mémoire insuffisante (OOM).
- Gestion inefficace – Nous devions gérer différents manifestes de déploiement pour chaque type de modèle (tels que les classificateurs, les intégrations et la saisie semi-automatique), ce qui prenait du temps et était source d'erreurs. Nous avons également dû maintenir la logique pour déterminer l'allocation de mémoire pour différents types de modèles.
En fin de compte, nous avions besoin d'une plate-forme d'inférence pour assumer la lourde charge de la gestion de nos modèles au moment de l'exécution afin d'améliorer le coût, la fiabilité et la gestion du service de nos modèles. Les MME SageMaker nous ont permis de répondre à ces besoins.
Grâce à son chargement et déchargement de modèles intelligents et dynamiques et à ses capacités de mise à l'échelle, les MME SageMaker ont fourni une solution nettement moins coûteuse et plus fiable pour l'hébergement de nos modèles. Nous sommes désormais en mesure d'adapter beaucoup plus de modèles par instance et nous n'avons plus à nous soucier des erreurs OOM, car les MME SageMaker gèrent le chargement et le déchargement des modèles de manière dynamique. De plus, les déploiements sont désormais aussi simples que d'appeler les API Boto3 SageMaker et d'attacher les politiques de mise à l'échelle automatique appropriées.
Le schéma suivant illustre notre architecture héritée.
Pour commencer notre migration vers les MME SageMaker, nous avons identifié les meilleurs cas d'utilisation pour les MME et lequel de nos modèles bénéficierait le plus de ce changement. Les MME sont mieux utilisés pour les éléments suivants :
- Modèles censés avoir une faible latence mais pouvant supporter un temps de démarrage à froid (lors du premier chargement)
- Modèles qui sont appelés souvent et systématiquement
- Modèles nécessitant des ressources GPU partielles
- Modèles partageant des exigences et une logique d'inférence communes
Nous avons identifié nos modèles d'intégration et nos modèles de langage de saisie semi-automatique comme les meilleurs candidats pour notre migration. Pour organiser ces modèles sous MME, nous créerions un MME par type de modèle, ou tâche, un pour nos modèles d'intégration et un autre pour les modèles de langage de saisie semi-automatique.
Nous avions déjà une couche API au-dessus de nos modèles pour la gestion des modèles et l'inférence. Notre tâche consistait à retravailler la façon dont cette API déployait et gérait l'inférence sur les modèles sous le capot avec SageMaker, avec des changements minimes dans la façon dont les clients et les équipes produit interagissaient avec l'API. Nous devions également conditionner nos modèles et notre logique d'inférence personnalisée pour qu'ils soient compatibles avec le serveur d'inférence NVIDIA Triton utilisant les MME SageMaker.
Le schéma suivant illustre notre nouvelle architecture.
Logique d'inférence personnalisée
Avant de migrer vers SageMaker, le code d'inférence personnalisé de Forethought (prétraitement et post-traitement) s'exécutait dans la couche API lorsqu'un modèle était appelé. L'objectif était de transférer cette fonctionnalité au modèle lui-même pour clarifier la séparation des responsabilités, modulariser et simplifier leur code, et réduire la charge sur l'API.
embeddings
Les modèles d'intégration de Forethought se composent de deux artefacts de modèle PyTorch, et la demande d'inférence détermine le modèle à appeler. Chaque modèle nécessite un texte prétraité en entrée. Les principaux défis consistaient à intégrer une étape de prétraitement et à accueillir deux artefacts de modèle par définition de modèle. Pour répondre au besoin de plusieurs étapes dans la logique d'inférence, Forethought a développé un modèle d'ensemble Triton en deux étapes : un processus de prétraitement de backend Python et un appel de modèle de backend PyTorch. Les modèles d'ensemble permettent de définir et d'ordonner les étapes de la logique d'inférence, chaque étape étant représentée par un modèle Triton de n'importe quel type de backend. Pour assurer la compatibilité avec le backend Triton PyTorch, les artefacts de modèle existants ont été convertis au format TorchScript. Des modèles Triton distincts ont été créés pour chaque définition de modèle, et la couche API de Forethought était chargée de déterminer le TargetModel
à invoquer en fonction de la demande entrante.
Autocomplete
Les modèles de saisie semi-automatique (séquence à séquence) présentaient un ensemble distinct d'exigences. Plus précisément, nous devions activer la capacité de parcourir plusieurs appels de modèle et de mettre en cache des entrées substantielles pour chaque appel, tout en maintenant une faible latence. De plus, ces modèles nécessitaient à la fois des étapes de prétraitement et de post-traitement. Pour répondre à ces exigences et obtenir la flexibilité souhaitée, Forethought a développé des modèles MME à saisie semi-automatique en utilisant le backend Triton Python, qui offre l'avantage d'écrire le modèle sous forme de code Python.
Benchmarking
Une fois les formes du modèle Triton déterminées, nous avons déployé des modèles sur des points de terminaison intermédiaires et effectué une analyse comparative des ressources et des performances. Notre objectif principal était de déterminer la latence pour les modèles de démarrage à froid par rapport aux modèles en mémoire, et comment la latence était affectée par la taille de la demande et la simultanéité. Nous voulions également savoir combien de modèles pouvaient tenir sur chaque instance, combien de modèles entraîneraient la mise à l'échelle des instances avec notre politique de mise à l'échelle automatique et à quelle vitesse la mise à l'échelle se produirait. Conformément aux types d'instances que nous utilisions déjà, nous avons effectué notre analyse comparative avec les instances ml.g4dn.xlarge et ml.g4dn.2xlarge.
Résultats
Le tableau suivant résume nos résultats.
Taille de la demande | Latence de démarrage à froid | Latence d'inférence en cache | Latence simultanée (5 requêtes) |
Petit (30 jetons) | en 12.7 secondes | en 0.03 secondes | en 0.12 secondes |
Moyen (250 jetons) | en 12.7 secondes | en 0.05 secondes | en 0.12 secondes |
Grand (550 jetons) | en 12.7 secondes | en 0.13 secondes | en 0.12 secondes |
De manière notable, la latence des demandes de démarrage à froid est nettement supérieure à la latence des demandes d'inférence mises en cache. C'est parce que le modèle doit être chargé à partir du disque ou Service de stockage simple Amazon (Amazon S3) lorsqu'une demande de démarrage à froid est effectuée. La latence des demandes simultanées est également supérieure à la latence des demandes uniques. En effet, le modèle doit être partagé entre des requêtes simultanées, ce qui peut entraîner des conflits.
Le tableau suivant compare la latence des anciens modèles et des modèles SageMaker.
Taille de la demande | Modèles hérités | Modèles SageMaker |
Petit (30 jetons) | en 0.74 secondes | en 0.24 secondes |
Moyen (250 jetons) | en 0.74 secondes | en 0.24 secondes |
Grand (550 jetons) | en 0.80 secondes | en 0.32 secondes |
Dans l'ensemble, les modèles SageMaker constituent un meilleur choix pour héberger des modèles de saisie semi-automatique que les modèles hérités. Ils offrent une latence, une évolutivité, une fiabilité et une sécurité plus faibles.
L'utilisation des ressources
Dans notre quête pour déterminer le nombre optimal de modèles pouvant tenir sur chaque instance, nous avons effectué une série de tests. Notre expérience a impliqué le chargement de modèles dans nos points de terminaison à l'aide d'un type d'instance ml.g4dn.xlarge, sans aucune politique de mise à l'échelle automatique.
Ces instances particulières offrent 15.5 Go de mémoire, et nous visons à atteindre environ 80 % d'utilisation de la mémoire GPU par instance. Compte tenu de la taille de chaque artefact de modèle d'encodeur, nous avons réussi à trouver le nombre optimal d'encodeurs Triton à charger sur une instance pour atteindre notre utilisation cible de la mémoire GPU. De plus, étant donné que chacun de nos modèles d'intégrations correspond à deux modèles d'encodeurs Triton, nous avons pu héberger un nombre défini de modèles d'intégrations par instance. En conséquence, nous avons calculé le nombre total d'instances nécessaires pour servir tous nos modèles d'incorporation. Cette expérimentation a été cruciale pour optimiser l'utilisation de nos ressources et améliorer l'efficacité de nos modèles.
Nous avons effectué une analyse comparative similaire pour nos modèles de saisie semi-automatique. Ces modèles pesaient environ 292.0 Mo chacun. Lorsque nous avons testé le nombre de modèles pouvant tenir sur une seule instance ml.g4dn.xlarge, nous avons remarqué que nous ne pouvions adapter que quatre modèles avant que notre instance ne commence à décharger des modèles, malgré la petite taille des modèles. Nos principales préoccupations étaient :
- Cause du pic d'utilisation de la mémoire du processeur
- Cause du déchargement des modèles lorsque nous avons essayé de charger un modèle de plus au lieu du modèle le moins récemment utilisé (LRU)
Nous avons pu identifier la cause première du pic d'utilisation de la mémoire provenant de l'initialisation de notre environnement d'exécution CUDA dans notre modèle Python, qui était nécessaire pour déplacer nos modèles et nos données sur et hors du périphérique GPU. CUDA charge de nombreuses dépendances externes dans la mémoire du processeur lorsque le runtime est initialisé. Étant donné que le backend Triton PyTorch gère et extrait les données en mouvement sur et hors du périphérique GPU, nous n'avons pas rencontré ce problème pour nos modèles d'intégration. Pour résoudre ce problème, nous avons essayé d'utiliser des instances ml.g4dn.2xlarge, qui avaient la même quantité de mémoire GPU mais deux fois plus de mémoire CPU. De plus, nous avons ajouté plusieurs optimisations mineures dans notre code backend Python, notamment la suppression des tenseurs après utilisation, le vidage du cache, la désactivation des dégradés et le ramasse-miettes. Avec le type d'instance plus grand, nous avons pu adapter 10 modèles par instance, et l'utilisation de la mémoire CPU et GPU est devenue beaucoup plus alignée.
Le diagramme suivant illustre cette architecture.
Mise à l'échelle automatique
Nous avons attaché des politiques de mise à l'échelle automatique à nos intégrations et à nos MME de saisie semi-automatique. Notre politique pour notre point de terminaison d'intégration visait une utilisation moyenne de la mémoire GPU de 80 % à l'aide de métriques personnalisées. Nos modèles de saisie semi-automatique ont constaté un trafic élevé pendant les heures de bureau et un trafic minimal pendant la nuit. Pour cette raison, nous avons créé une règle de mise à l'échelle automatique basée sur InvocationsPerInstance
afin que nous puissions évoluer en fonction des modèles de trafic, en économisant sur les coûts sans sacrifier la fiabilité. Sur la base de notre analyse comparative de l'utilisation des ressources, nous avons configuré nos politiques de mise à l'échelle avec un objectif de 225 InvocationsPerInstance
.
Déployer la logique et le pipeline
La création d'un MME sur SageMaker est simple et similaire à la création de tout autre point de terminaison sur SageMaker. Une fois le point de terminaison créé, l'ajout de modèles supplémentaires au point de terminaison est aussi simple que de déplacer l'artefact de modèle vers le chemin S3 ciblé par le point de terminaison ; à ce stade, nous pouvons faire des demandes d'inférence à notre nouveau modèle.
Nous avons défini une logique qui prendrait en compte les métadonnées du modèle, formaterait le point de terminaison de manière déterministe en fonction des métadonnées et vérifierait si le point de terminaison existait. Si ce n'est pas le cas, nous créons le point de terminaison et ajoutons l'artefact du modèle Triton au correctif S3 pour le point de terminaison (également formaté de manière déterministe). Par exemple, si les métadonnées du modèle indiquaient qu'il s'agissait d'un modèle de saisie semi-automatique, elles créeraient un point de terminaison pour les modèles de saisie semi-automatique et un chemin S3 associé pour les artefacts de modèle de saisie semi-automatique. Si le point de terminaison existait, nous copierions l'artefact de modèle dans le chemin S3.
Maintenant que nous avions nos formes de modèle pour nos modèles MME et la fonctionnalité de déploiement de nos modèles sur MME, nous avions besoin d'un moyen d'automatiser le déploiement. Nos utilisateurs doivent spécifier le modèle qu'ils souhaitent déployer ; nous nous chargeons du packaging et du déploiement du modèle. Le code d'inférence personnalisé fourni avec le modèle est versionné et transmis à Amazon S3 ; dans l'étape d'empaquetage, nous extrayons le code d'inférence selon la version spécifiée (ou la dernière version) et utilisons des fichiers YAML qui indiquent les structures de fichiers des modèles Triton.
Une exigence pour nous était que tous nos modèles MME soient chargés en mémoire pour éviter toute latence de démarrage à froid lors des demandes d'inférence de production à charger dans les modèles. Pour y parvenir, nous fournissons suffisamment de ressources pour adapter tous nos modèles (selon le benchmarking précédent) et appelons chaque modèle dans notre MME à une cadence horaire.
Le diagramme suivant illustre le pipeline de déploiement du modèle.
Le diagramme suivant illustre le pipeline de préchauffage du modèle.
Appel de modèle
Notre couche API existante fournit une abstraction permettant aux appelants de faire des inférences sur tous nos modèles ML. Cela signifiait que nous n'avions qu'à ajouter des fonctionnalités à la couche API pour appeler le MME SageMaker avec le modèle cible correct en fonction de la demande d'inférence, sans aucune modification du code d'appel. Le code d'inférence SageMaker prend la demande d'inférence, formate les entrées Triton définies dans nos modèles Triton et appelle les MME à l'aide de Boto3.
Avantages en termes de coûts
Grâce à la migration vers les MME SageMaker, Forethought a fait des progrès significatifs dans la réduction des coûts d'hébergement des modèles et dans l'atténuation des erreurs de MOO des modèles. Avant cette modification, les instances ml.g4dn.xlarge s'exécutaient dans Amazon EKS. Avec la transition vers les MME, nous avons découvert qu'il pouvait héberger 12 modèles d'intégration par instance tout en atteignant 80 % d'utilisation de la mémoire GPU. Cela a entraîné une baisse significative de nos dépenses mensuelles. Pour mettre les choses en perspective, nous avons réalisé une économie de coûts allant jusqu'à 80 %. De plus, pour gérer un trafic plus important, nous avons envisagé de faire évoluer les répliques. En supposant un scénario où nous employons trois répliques, nous avons constaté que nos économies de coûts seraient encore substantielles même dans ces conditions, oscillant autour de 43 %.
Le voyage avec les MME SageMaker s'est avéré financièrement avantageux, réduisant nos dépenses tout en garantissant des performances optimales du modèle. Auparavant, nos modèles de langage de saisie semi-automatique étaient déployés dans Amazon EKS, ce qui nécessitait un nombre variable d'instances ml.g4dn.xlarge en fonction de l'allocation de mémoire par modèle. Cela entraînait un coût mensuel considérable. Cependant, grâce à notre récente migration vers les MME SageMaker, nous avons pu réduire considérablement ces coûts. Nous hébergeons désormais tous nos modèles sur des instances ml.g4dn.2xlarge, ce qui nous permet de compresser les modèles plus efficacement. Cela a considérablement réduit nos dépenses mensuelles et nous avons maintenant réalisé des économies de coûts de l'ordre de 66 à 74 %. Cette décision a démontré à quel point l'utilisation efficace des ressources peut entraîner d'importantes économies financières à l'aide des MME SageMaker.
Conclusion
Dans cet article, nous avons examiné comment Forethought utilise les points de terminaison multimodèles SageMaker pour réduire les coûts d'inférence en temps réel. SageMaker prend en charge le gros du travail indifférencié, donc Forethought peut augmenter l'efficacité de l'ingénierie. Cela permet également à Forethought de réduire considérablement le coût de l'inférence en temps réel tout en maintenant les performances nécessaires aux opérations critiques de l'entreprise. Ce faisant, Forethought est en mesure de fournir une offre différenciée à ses clients en utilisant des modèles hyper personnalisés. Utilisez SageMaker MME pour héberger vos modèles à grande échelle et réduire les coûts d'hébergement en améliorant l'utilisation des terminaux. Cela réduit également les frais généraux de déploiement, car Amazon SageMaker gère le chargement des modèles en mémoire et les met à l'échelle en fonction des modèles de trafic vers votre point de terminaison. Vous pouvez trouver des exemples de code sur l'hébergement de plusieurs modèles à l'aide de SageMaker MME sur GitHub.
À propos des auteurs
Jad Chamoun est directeur de l'ingénierie de base chez Forethought. Son équipe se concentre sur l'ingénierie de plate-forme couvrant l'ingénierie des données, l'infrastructure d'apprentissage automatique et l'infrastructure cloud. Vous pouvez le retrouver sur LinkedIn.
Salina Wu est ingénieur senior en infrastructure d'apprentissage automatique chez Forethought.ai. Elle travaille en étroite collaboration avec l'équipe d'apprentissage automatique pour créer et maintenir leurs infrastructures de formation, de service et de données de bout en bout. Elle est particulièrement motivée par l'introduction de nouvelles façons d'améliorer l'efficacité et de réduire les coûts dans l'espace ML. Lorsqu'elle n'est pas au travail, Salina aime surfer, faire de la poterie et être dans la nature.
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. Pendant son temps libre, il aime rechercher de nouvelles cultures, de nouvelles expériences et se tenir au courant des dernières tendances technologiques. Vous pouvez le trouver sur LinkedIn.
Sunil Padmanabhan est architecte de solutions de démarrage chez AWS. En tant qu'ancien fondateur de startup et CTO, il est passionné par l'apprentissage automatique et s'attache à aider les startups à tirer parti de l'IA/ML pour leurs résultats commerciaux et à concevoir et déployer des solutions ML/AI à grande échelle.
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.
- Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
- Financement EVM. Interface unifiée pour la finance décentralisée. Accéder ici.
- Groupe de médias quantiques. IR/PR amplifié. Accéder ici.
- PlatoAiStream. Intelligence des données Web3. Connaissance Amplifiée. Accéder ici.
- La source: https://aws.amazon.com/blogs/machine-learning/how-forethought-saves-over-66-in-costs-for-generative-ai-models-using-amazon-sagemaker/
- :possède
- :est
- :ne pas
- :où
- $UP
- 1
- 10
- 100
- 12
- 13
- 15%
- 24
- 250
- 30
- 32
- 7
- 80
- a
- capacité
- Capable
- A Propos
- abstraction
- résumés
- accéléré
- Selon
- précision
- Avec cette connaissance vient le pouvoir de prendre
- avec précision
- atteindre
- atteint
- la réalisation de
- à travers
- ajouter
- ajoutée
- ajoutant
- ajout
- Supplémentaire
- En outre
- propos
- adresser
- Avancée
- Avantage
- Après
- Agent
- agents
- AI
- cas d'utilisation de l'IA
- AI / ML
- Destinée
- aligner
- aligné
- Tous
- allocation
- permettre
- permet
- déjà
- aussi
- Bien que
- Amazon
- Amazon Sage Maker
- Amazon Web Services
- -
- montant
- an
- et les
- Annuellement
- Une autre
- réponses
- tous
- api
- Apis
- apparent
- approprié
- d'environ
- architecture
- SONT
- autour
- sur notre blog
- artificiel
- intelligence artificielle
- AS
- aide
- associé
- At
- auto
- automatiser
- Automatisation
- automatiquement
- moyen
- éviter
- et
- AWS
- backend
- Balance
- base
- basé
- BE
- est devenu
- car
- devenez
- était
- before
- commencer
- va
- analyse comparative
- avantageux
- profiter
- LES MEILLEURS
- Améliorée
- jusqu'à XNUMX fois
- stimuler
- tous les deux
- apporter
- construire
- intégré
- fardeau
- la performance des entreprises
- mais
- by
- Cache
- calculé
- Appelez-nous
- appelé
- appel
- Appels
- CAN
- candidats
- capacités
- maisons
- cas
- répond
- Causes
- challenge
- globaux
- Change
- Modifications
- vérifier
- le choix
- choisir
- CLIENTS
- étroitement
- le cloud
- infrastructure de cloud
- code
- du froid
- Collecte
- COM
- Venir
- Commun
- De l'entreprise
- par rapport
- compatibilité
- compatible
- ordinateur
- Vision par ordinateur
- informatique
- Préoccupations
- concurrent
- conditions
- menée
- configurée
- conservateur
- considérable
- considéré
- considérant
- Contenant
- contenu
- converti
- Core
- correct
- correspond
- Prix
- les économies de coûts
- rentable
- cher
- Costs
- pourriez
- couvrant
- engendrent
- créée
- La création
- crucial
- CTO
- Customiser
- des clients
- données client
- Satisfaction client
- Service à la clientèle
- Support à la clientèle
- Clients
- sont adaptées
- données
- Date
- Refuser
- diminuer
- profond
- l'apprentissage en profondeur
- défini
- définir
- livrer
- livrer
- démontré
- Selon
- déployer
- déployé
- déployer
- déploiement
- déploiements
- Conception
- voulu
- Malgré
- Déterminer
- déterminé
- détermine
- détermination
- développé
- mobiles
- dispositif
- DID
- différent
- différencié
- Directeur
- découvert
- distinct
- distribué
- informatique distribuée
- faire
- domaine
- domaines
- Ne pas
- Dramatiquement
- pendant
- Dynamic
- dynamiquement
- chacun
- efficace
- efficace
- efficacement
- enrobage
- permettre
- permet
- end-to-end
- Endpoint
- engageant
- ingénieur
- ENGINEERING
- de renforcer
- améliorer
- assez
- assurer
- assurer
- entreprises
- Environment
- Erreurs
- Pourtant, la
- Chaque
- exemple
- existant
- attendu
- dépenses
- cher
- d'experience
- Expériences
- expérience
- externe
- plus rapide
- Déposez votre dernière attestation
- Fichiers
- remplir
- la traduction de documents financiers
- financièrement
- Trouvez
- Prénom
- s'adapter
- FLOTTE
- Flexibilité
- se concentre
- Abonnement
- Pour
- le format
- Ancien
- trouvé
- fondateur
- quatre
- De
- d’étiquettes électroniques entièrement
- plus
- En outre
- lacunes
- générer
- généré
- génératif
- IA générative
- obtention
- gif
- donné
- Don
- objectif
- GPU
- GPU
- les gradients
- ait eu
- main
- manipuler
- Poignées
- Maniabilité
- arriver
- Matériel
- Vous avez
- ayant
- he
- lourd
- levage de charges lourdes
- aider
- aider
- aide
- Haute
- haute performance
- augmentation
- lui
- sa
- capuche
- hôte
- hébergement
- frais d'hébergement
- HEURES
- Villa
- Comment
- Cependant
- HTML
- http
- HTTPS
- Des centaines
- identifié
- if
- illustre
- immédiatement
- améliorer
- l'amélioration de
- in
- Inc
- Y compris
- Nouveau
- Améliore
- indiquer
- indiqué
- d'information
- Infrastructure
- infrastructures
- technologie innovante
- contribution
- entrées
- instance
- plutôt ;
- Intégration
- l'intégration
- Intelligence
- l'interaction
- interactions
- intérêt
- développement
- Découvrez le tout nouveau
- invoqué
- invoque
- impliqué
- aide
- IT
- SES
- lui-même
- chemin
- jpg
- juste
- en gardant
- ACTIVITES
- Savoir
- spécialisées
- langue
- gros
- Grandes entreprises
- plus importantes
- Latence
- Nouveautés
- couche
- conduire
- conduisant
- apprentissage
- au
- LED
- Legacy
- moins
- Levier
- les leviers
- lifting
- charge
- chargement
- charges
- logique
- Faible
- baisser
- click
- machine learning
- LES PLANTES
- Entrée
- maintenir
- Maintenir
- a prendre une
- gérer
- gérés
- gestion
- gère
- les gérer
- de nombreuses
- Marché
- maximisant
- signifiait
- Mémoire
- Métadonnées
- Métrique
- migrer
- migration
- million
- minimal
- mineur
- atténuer
- ML
- modèle
- numériques jumeaux (digital twin models)
- Surveiller
- mensuel
- PLUS
- Par ailleurs
- (en fait, presque toutes)
- motivés
- Bougez
- en mouvement
- beaucoup
- Point de terminaison multimodèle
- plusieurs
- must
- indigène
- Nature
- nécessaire
- Besoin
- nécessaire
- Besoins
- Nouveauté
- nlp
- maintenant
- nombre
- Nvidia
- objectif
- of
- de rabais
- code
- offrant
- Offres Speciales
- souvent
- on
- une fois
- ONE
- uniquement
- Opérations
- Opportunités
- optimaux
- l'optimisation
- or
- de commander
- organisations
- Autre
- nos
- nous-mêmes
- ande
- les résultats
- plus de
- du jour au lendemain
- PACK
- paquet
- emballé
- l'emballage
- particulier
- particulièrement
- passionné
- Pièce
- chemin
- Patron de Couture
- motifs
- performant
- objectifs
- pipeline
- plateforme
- Platon
- Intelligence des données Platon
- PlatonDonnées
- Point
- politiques
- politique
- Post
- power
- alimenté
- présenté
- précédent
- précédemment
- primaire
- Directeur
- Avant
- d'ouvrabilité
- processus
- traitement
- Produit
- Vidéo
- productivité
- correct
- proven
- fournir
- à condition de
- fournit
- disposition
- Poussé
- mettre
- Python
- pytorch
- qualité
- requêtes
- quête
- vite.
- gamme
- allant
- Classement
- nous joindre
- en temps réel
- réalisé
- récent
- récemment
- réduire
- réduit
- réduire
- en relation
- pertinence
- pertinent
- fiabilité
- fiable
- reste
- représenté
- nécessaire
- demandes
- conditions
- exigence
- Exigences
- a besoin
- ressource
- Resources
- réponses
- responsabilités
- responsables
- résultat
- résultant
- Résultats
- examiné
- bon
- rigide
- racine
- Courir
- pour le running
- sacrifier
- sagemaker
- Inférence SageMaker
- même
- client
- Épargnez
- économie
- Épargnes
- scie
- Évolutivité
- évolutive
- Escaliers intérieurs
- mise à l'échelle
- Balance
- mise à l'échelle
- scénario
- scénarios
- scientifiques
- Rechercher
- sécurité
- recherche
- supérieur
- séparé
- Séquence
- Série
- besoin
- service
- Services
- service
- set
- plusieurs
- Shadow
- formes
- Partager
- commun
- elle
- significative
- de façon significative
- similaires
- étapes
- simplifier
- unique
- Taille
- petit
- smart
- So
- sur mesure
- Solutions
- RÉSOUDRE
- quelques
- l'espace
- groupe de neurones
- spécifiquement
- spécifié
- épi
- mise en scène
- Commencer
- j'ai commencé
- Commencez
- Startups
- state-of-the-art
- étapes
- Étapes
- Encore
- storage
- simple
- progrès
- Ces
- tel
- suite
- Support
- Système
- table
- tacle
- Prenez
- prend
- Target
- des campagnes marketing ciblées,
- objectifs
- Tâche
- équipe
- équipes
- Les technologies
- Technologie
- examiné
- tests
- que
- Merci
- qui
- La
- leur
- Les
- Ces
- l'ont
- this
- trois
- Avec
- billets
- fiable
- long
- à
- Tokens
- top
- Total
- circulation
- Train
- qualifié
- Formation
- transférer
- Transformer
- transition
- Trends
- essayé
- Triton
- Twice
- deux
- type
- types
- sous
- expérience unique et authentique
- us
- Utilisation
- utilisé
- cas d'utilisation
- d'utiliser
- utilisateurs
- Usages
- en utilisant
- Utilisant
- version
- très
- vision
- vs
- souhaitez
- voulu
- était
- Façon..
- façons
- we
- web
- services Web
- ont été
- quand
- que
- qui
- tout en
- comprenant
- sans
- activités principales
- travaillé
- vos contrats
- s'inquiéter
- pourra
- écriture
- wu
- yaml
- Vous n'avez
- Votre
- zéphyrnet